LDP Extensions for Multi-Topology
draft-ietf-mpls-ldp-multi-topology-12

Note: This ballot was opened for revision 11 and is now closed.

(Alia Atlas) Yes

Comment (2014-03-21 for -11)
No email
send info
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.

(Adrian Farrel) (was Discuss, Yes) Yes

Comment (2014-04-23)
No email
send info
I believe the new revision addresses the issues raised by IANA

(Jari Arkko) No Objection

(Benoît Claise) (was Discuss) No Objection

Comment (2014-04-23)
No email
send info
Thanks for addressing my DISCUSS.

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2014-03-23 for -11)
No email
send info
- 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.

(Brian Haberman) (was Discuss) No Objection

Comment (2014-03-24 for -11)
No email
send info
The RFC Editor's note proposed by Adrian addresses my confusion/concern.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

Comment (2014-03-25 for -11)
No email
send info
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!

(Kathleen Moriarty) No Objection

Comment (2014-03-24 for -11)
No email
send info
Thanks for addressing my comments int he SecDir review.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection