LDP Extensions for Multi-Topology
draft-ietf-mpls-ldp-multi-topology-12
Yes
No Objection
(Barry Leiba)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Spencer Dawkins)
Note: This ballot was opened for revision 11 and is now closed.
Adrian Farrel Former IESG member
(was Discuss, Yes)
Yes
Yes
(2014-04-23)
Unknown
I believe the new revision addresses the issues raised by IANA
Alia Atlas Former IESG member
Yes
Yes
(2014-03-21 for -11)
Unknown
1) In Sec 3.6, the text says "Since using different label spaces for different topologies would imply significant changes to the data plane, a single global label space is supported in this solution. There will be one session supported between a pair of peers, even if there are multiple topologies supported between these two peers." The heading and paragraph structure makes it appear that there is a connection between the number of sessions between the peers and the label space, which is not true. There could be multiple LDP sessions between the same peers (targeted and discovered/local) and that is completely orthogonal to the use of a single global label space. Could you please determine what you are trying to say in this section and reword it? I suspect the section heading becomes "Label Spaces" and the text is something like: "The use of multiple topologies for LDP does not require different label spaces for each topology. An LSR can use the same label space for all MT FECs as for the default topology. Similarly, signaling for different topologies can and should be done within a single LDP session." 2) In Sec 3.7, it says: " If an LSR receives a FEC element with an "MT-ID" value that is "Reserved" for future use (and not IANA allocated yet), the LSR MUST abort the processing of the FEC element, and SHOULD send a notification message with status code "Invalid Topology ID" to the sender." I am concerned that this makes it nearly impossible to use any newly allocated MT-ID values - since all the LSRs on the path would have to be upgraded first. Can you and Adrian come up with better error-handling? I also notice that in the IANA Considerations section, the values are all "Unassigned" rather than "Reserved" - so I'm not sure how this section applies.
Barry Leiba Former IESG member
No Objection
No Objection
(for -11)
Unknown
Benoît Claise Former IESG member
(was Discuss)
No Objection
No Objection
(2014-04-23)
Unknown
Thanks for addressing my DISCUSS.
Brian Haberman Former IESG member
(was Discuss)
No Objection
No Objection
(2014-03-24 for -11)
Unknown
The RFC Editor's note proposed by Adrian addresses my confusion/concern.
Jari Arkko Former IESG member
No Objection
No Objection
(for -11)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -11)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-03-24 for -11)
Unknown
Thanks for addressing my comments int he SecDir review.
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -11)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -11)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -11)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-03-23 for -11)
Unknown
- Intro: MT is expanded twice differently in the first paragraph. And that continues immediately below as the term seems to be used very loosely. That is probably ok, since the meaning becomes clear later, but seems like a pity. - I find 3.5.2 para 1 quite hard to follow. Maybe its clear to others though.
Ted Lemon Former IESG member
No Objection
No Objection
(2014-03-25 for -11)
Unknown
In section 1:
o A CSP may want to assign varying Quality of Service (QoS) profiles
to traffic, based on a specific MT.
Don't you mean "based on a specific topology in an MT network" or "per topology within an MT network" or something like that? I agree with Stephen that the use of "MT" in the introduction is muddy, and could stand to be clarified, for example by using "MT network" and "MT routing" rather than "MT" and "MT routing".
Also:
o Management traffic could be separated from customer traffic using
multiple MTs, where the management traffic MT does not use links
that carry customer traffic.
Here in particular it's not clear whether you mean to use different topologies for management traffic and customer traffic, or separate MT networks. This convention appears to derive from an unfortunate decision in RFC 4915 to abbreviate "MT topology" as "MT." I think you should break with this convention and either use "MTT" or "RT" (routing topology). I'm not raising this as a DISCUSS because I don't think it would be appropriate, but I think the current overloading of "MT" is needlessly confusing. This comment obviously carries forward to section 2...
In 3.2:
The LDP base specification [RFC5036] (Section 4.1) defines the
"Prefix" FEC Element. The "Prefix" encoding is defined for a given
"Address Family" (AF), and has length (in bits) specified by the
"PreLen" field.
Actually it's section 2.1, not 4.1.
Also in 3.2:
Where "IP Address" is an IPv4 and IPv6 address/prefix for "MT IP" and
"MT IPv6" AF respectively, and the field "MT-ID" corresponds to 16-
bit Topology ID for given address.
What does "an IPv4 and IPv6 address/prefix" mean? Given that it's 32 bits (according to Figure 1), it can't be an IPv6 prefix unless it's a /32, but this isn't talked about, so I am left wondering. Was the intention to make it a variable-length field?
Also:
The definition and usage of the rest fields in the FEC Elements are
same as defined for IP/IPv6 AF. The value of MT-ID 0 corresponds to
default topology and MUST be ignored on receipt so as to not cause
any conflict/confusion with existing non-MT procedures.
I'm assuming that "rest fields" in the first line was supposed to be "rest of the fields" but I wanted to check to be sure, because it could also be fields of the type "rest".
Aside from the terminology complaint and the few nits I mention above, the document looks good. Thanks for doing the work!