Subject: Re: WG last call on the FTN mib module and the TE mib module

From: Arun Satyanarayana <[email-masked]>
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" <[email-masked]>
To: "MPLS WG" <[email-masked]>
Cc: "George Swallow" <[email-masked]>; "Bert Wijnen" <[email-masked]>;
"Alex Zinin" <[email-masked]>
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: [email-masked]

---

From: "Arun Viswanathan" <[email-masked]>
Date: Fri, 27 Jun 2003 08:51:14 -0700

Its done now. Thanks for reminding one more time.

-arun

> -----Original Message-----
> From: Edward Harrison [mailto:[email-masked]] 
> Sent: Friday, June 27, 2003 2:25 AM
> To: MPLS WG
> Cc: Cisco - Thomas Nadeau; Cheenu Srinivasan; Arun Viswanathan
> Subject: RE: WG last call on the FTN mib module and the TE mib module
> 
> 
> Hi,
> 
> One thing I immediately notice in 
> draft-ietf-mpls-te-mib-10.txt is that the
> mplsTunnelEntry still includes an 
> mplsTunnelExcludeAllAffinity object as
> opposed to an mplsTunnelExcludeAnyAffinity (which is what is 
> used in RFC
> 3209).
> 
> Each time I've raised this in the past it has been agreed (by 
> Tom at the
> very least) that the object should be "Exclude-any", but the 
> mark-up keeps
> getting lost by the time the next version appears.
> 
> Any chance of fixing it before the draft goes to RFC?
> 
> Regards,
> 
> Ed
> 
> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: 25 June 2003 00:28
> To: MPLS WG
> Cc: George Swallow; Bert Wijnen; Alex Zinin

-- 
/Loa

mobile + 46 739 81 21 64
email: [email-masked]

---

From: Edward Harrison <[email-masked]>
Date: Fri, 27 Jun 2003 10:24:54 +0100

Hi,

One thing I immediately notice in draft-ietf-mpls-te-mib-10.txt is that the
mplsTunnelEntry still includes an mplsTunnelExcludeAllAffinity object as
opposed to an mplsTunnelExcludeAnyAffinity (which is what is used in RFC
3209).

Each time I've raised this in the past it has been agreed (by Tom at the
very least) that the object should be "Exclude-any", but the mark-up keeps
getting lost by the time the next version appears.

Regards,

Ed

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: 25 June 2003 00:28
To: MPLS WG
Cc: George Swallow; Bert Wijnen; Alex Zinin
Subject: WG last call on the FTN mib module and the TE mib module

All,

-- 
/Loa

mobile + 46 739 81 21 64
email: [email-masked]