The MPLS WG Archive

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



[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: Arun Satyanarayana <arun@gl.umbc.edu>
  • Date: Thu, 26 Jun 2003 17:12:48 -0400 (EDT)
  • cc: Arun Satyanarayana <arun@gl.umbc.edu>
  • X-Avmilter: Message Skipped, too small
  • X-AvMilter-Key: 1056662270:e4213618247268fe72c6b5da9da60e5f
  • X-Processed-By: MilterMonkey Version 0.9 -- http://www.membrain.com/miltermonkey


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