The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Jun> msg00156



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

WG last call on the FTN mib module and the TE mib module

  • From: "M. ELK" <elkou141061@hotmail.com>
  • Date: Sat, 28 Jun 2003 07:30:37 +0000
  • Cc: arun@gl.umbc.edu
  • X-OriginalArrivalTime: 28 Jun 2003 07:30:37.0918 (UTC) FILETIME=[2B8D9FE0:01C33D47]
  • X-Originating-Email: [elkou141061@hotmail.com]
  • X-Originating-IP: [57.250.229.136]

Arun

Reg mplsTunnelDescr

Quote
>mplsTunnelDescr
>Since this attribute cannot be signaled, please add a note to explain that
>the value of this object at transit and egress nodes will be automatically
>generated (or blank) according to the implementation and may not match the
>value at the ingress.
Unquote

As an option , why not using  "session Name" which is part of session 
attribute object .
this way the mplsTunnelDscr  have a common value across all LSR (Set by 
Headend and reflected at the transit and egress LSR ) .

Brgds

>From: Arun Satyanarayana <arun@gl.umbc.edu>
>Reply-To: arun@umbc.edu
>To: mpls@UU.NET
>CC: Arun Satyanarayana <arun@gl.umbc.edu>
>Subject: Re: WG last call on the FTN mib module and the TE mib module
>Date: Thu, 26 Jun 2003 17:12:48 -0400 (EDT)
>
>
>Hi Tom and co.,
>
>Regarding draft-ietf-mpls-te-mib-10.txt, please make some clarifications
>on how the configured parameters map to signalling:
>
>mplsTunnelIndex
>Please add to the description to say how this maps to signaled objects.
>Something like...
>"For tunnel LSPs signaled using RSVP-TE, this value should correspond to
>the Tunnel Id used for the RSVP-TE session."
>
>mplsTunnelInstance
>Description says...
>"For tunnel LSPs signaled using RSVP, this value should correspond to the
>RSVP source port used for the RSVP-TE session."
>There is no such field in RFC3209. Please change to say...
>"For tunnel LSPs signaled using RSVP-TE, this value should correspond to
>the LSP-ID used for the RSVP-TE sender."
>
>mplsTunnelIngressLSRId
>Surely this should be the source of the tunnel not the extended tunnel id.
>The description starts off right but goes wrong when it says...
>"When the MPLS signalling protocol is rsvp(2) this value SHOULD mimic the
>Extended Tunnel Id field in the SESSION object."
>Please change this to say...
>"When the MPLS signalling protocol is rsvp(2) this value should correspond
>  to the Tunnel Sender Address in Sender Template."
>
>mplsTunnelIngressLSRId and mplsTunnelEgressLSRId
>Why is there no support for IPv6 source and destinations?
>
>mplsTunnelDescr
>Since this attribute cannot be signaled, please add a note to explain that
>the value of this object at transit and egress nodes will be automatically
>generated (or blank) according to the implementation and may not match the
>value at the ingress.
>
>mplsTunnelSessionAttributes
>It would be helpful if these bits more closely matched the signaled
>Session Attribute flags from RFC3209 and so on. It is also helpful to have
>flags for triggering separate qualities of the tunnel. So... fastReroute
>(0) is useful but should be split into fastRerouteNodeProt and
>fastRerouteBWProt. recordRoute(4) is useful but we also need
>recordRouteLabels. Please state how each flag maps to a flag in the
>Session Attribute object.
>
>Thanks,
>_arun_
>============================================================
>From: "Loa Andersson" <loa@pi.se>
>To: "MPLS WG" <mpls@UU.NET>
>Cc: "George Swallow" <swallow@cisco.com>; "Bert Wijnen" 
><bwijnen@lucent.com>;
>"Alex Zinin" <zinin@psg.com>
>Sent: Tuesday, June 24, 2003 7:28 PM
>Subject: WG last call on the FTN mib module and the TE mib module
>
>
> > All,
> >
> > this mail starts a working group last call on
> >
> >        Multiprotocol Label Switching (MPLS) Traffic Engineering
> >                    Management Information Base
> >
> >                  <draft-ietf-mpls-te-mib-10.txt>
> >
> > This ID has just been sent to the Internet-Drafts for publication and
> > will show up shortly, in the mean time it will be found at:
> >
> > http://urax.utfors.net/~loa/draft-ietf-mpls-te-mib-10.txt
> >
> > This mail also the starts a working group last call on
> >
> >         Multiprotocol Label Switching (MPLS) Forwarding Equivalence
> >           Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE)
> >                         Management Information Base
> >
> >                       draft-ietf-mpls-ftn-mib-07.txt
> >
> > for this mib module the wg last call is limited to the changes since the
> > previous version version
> >
> > This ID has just been sent to the Internet-Drafts for publication and
> > will show up shortly, in the mean time it will be found at:
> >
> > http://urax.utfors.net/~loa/draft-ietf-mpls-ftn-mib-07.txt
> >
> > The last call will en June 29th 09.00 ET.
> >
> > --
> > /Loa
> >
> > mobile + 46 739 81 21 64
> > email: loa@pi.se
>

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus