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

[Ballot comment]
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!

[Ballot discuss]
Holding a Discuss for IANA's issues as below.

> ACTION 1:
> in the TLV Type Name Space subregistry in the Label Distribution
> Protocol (LDP) Parameters registry located at:
>
> http://www.iana.org/assignments/ldp-namespaces/
>
> a new TLV Type will be registered as follows:
>
> Value: [ TBD-at-registration ]
> Description: Multi-Topology Capability
> Reference: [ RFC-to-be ]
>
> QUESTION: Are the authors intended to have a value from the range
> 0x0001-0x07FF?
>
> ACTION 2:
> in the Status Code Name Space subregistry in the Label Distribution
> Protocol
> (LDP) Parameters registry located at:
>
> http://www.iana.org/assignments/ldp-namespaces/
>
> a new Status Code will be registered as follows:
>
> Range/Value: [ TBD-at-registration ]
> E: (blank)
> Description: Invalid Topology ID
> Reference: [ RFC-to-be ]
>
> QUESTIONs:
> 1) Authors, please confirm if this new Status Code should be added to
> the range 0x00000000-0x1FFFFFFF (IETF Consensus).
>
> 2) The authors have inconsistent terms, "TBA1" and "TBA2", in this
> section.  The current text reads:
>
> o  New Status Code: "Invalid Topology ID" (requested code point: TBA2
>      from LDP registry "Status Code Name Space").
>
>
>            Registry:
>            Range/Value          Description
>            --------------      ------------------------------
>            TBA1                Invalid Topology ID
>
> We are confused if TBA1 is a typo.  The authors uses "TBA1" for
> the New LDP Capability TLV.  Another possibility: are the authors
> requesting the same value for both the New LDP Capability TLV and the
> New Status Code?
>
>
> ACTION 3:
> in the Address Family Numbers registry located at:
>
> http://www.iana.org/assignments/address-family-numbers/
>
> two, new address family numbers will be registered as follows:
>
> Number: [ TBD-at-registration ]
> Description: MT IP: Multi-Topology IP version 4
> Reference: [ RFC-to-be ]
>
> IANA notes that the authors have requested codepoint 26 for this registration.
>
> Number: [ TBD-at-registration ]
> Description: MT IPv6: Multi-Topology IP version 6
> Reference: [ RFC-to-be ]
>
> IANA notes that the authors have requested codepoint 27 for this registration.
>
> ACTION 4:
> a new registry called "MPLS Multi-Topology Identifiers" is to be
> created as defined by this document.
>
> QUESTION: Is this a brand new top level registry with its own new URL,
> or a sub-registry of an exiting registry?  Please see a list of
> existing registries at iana.org/protocols.
>
> IANA understands that there are initial registrations in this new
> registry as
> follows:
>
> Range/Value Purpose Reference
> ----------- ------------------------------------- ---------
> 0 Default/standard topology [ RFC-to-be ]
> 1 IPv4 in-band management [ RFC-to-be ]
> 2 IPv6 routing topology [ RFC-to-be ]
> 3 IPv4 multicast topology [ RFC-to-be ]
> 4 IPv6 multicast topology [ RFC-to-be ]
> 5 IPv6 in-band management [ RFC-to-be ]
> 6-3995      Unassigned for future IGP topologies  [This.I-D]
>              Assigned by Standards Action          [This.I-D]
> 3996-4095    Experimental                          [This.I-D]
> 4096-65534  Unassigned for MPLS topologies        [This.I-D]
>              Assigned by Standards Action
> 65535        Wildcard Topology                      [This.I-D]
>
>
> ACTION 5:
> in the Sub-TLVs for TLV Types 1, 16, and 21 subregistry of the
> Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
> Parameters registry located at:
>
> http://www.iana.org/assignments/mpls-lsp-ping-parameters/
>
> two, new sub-TLV types will be registered as follows:
>
> Sub-Type: [ TBD-at-registration ]
> Sub-TLV Name: MT LDP IPv4 prefix
> Reference: [ RFC-to-be ]
>
> Sub-Type: [ TBD-at-registration ]
> Sub-TLV Name: MT LDP IPv6 prefix
> Reference: [ RFC-to-be ]
>
> IANA should allocate the next available numbers in the Sub-TLVs for
> TLV Types 1, 16, and 21 sub-registry.
>
> IANA understands that these are the only actions required to be
> completed upon approval of this document.
>
> Note: The actions requested in this document will not be completed
> until the document has been approved for publication as an RFC.
> This message is only to confirm what actions will be performed.
>
> Thank you,
>
> Pearl Liang

[Ballot discuss]
Thanks for "Operation Considerations" section.
However, it ONLY speaks about LSP ping, which is a little bit weak.
I guess that all the existing MIB modules related to MPLS/TE/VRF (RFC 3812, RFC 3815, RFC 6445, RFC 3813, RFC 3814, ... if I get this right from a simple google search) won't be working because you miss an extra index: the MT ID.
If correct, that should be clearly mentioned: the existing MIB modules are useless with this extension.

[Ballot discuss]
I have no objection to the publication of this document, but I am confused by TLV description in section 3.5.1.  The specification for the U and F bit says: 

"MUST be 1 and 0, respectively, as per Section 3.
      (Signaling Extensions) of LDP Capabilities [RFC5561]."

1) I assume that the "." after Section 3 is extraneous.

2) Section 3 of RFC 5561 says that F MUST be 0, but that U can be either 0 or 1 and its value will be described in the Capability document defining the TLV.

So, RFC 5561 is not stating that U MUST be 1, this document is.  Is that correct?  If so, that should be clarified in the description.

[Ballot comment]

- 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.

[Ballot discuss]
Holding a Discuss for IANA's issues as below.

> ACTION 1:
> in the TLV Type Name Space subregistry in the Label Distribution
> Protocol (LDP) Parameters registry located at:
>
> http://www.iana.org/assignments/ldp-namespaces/
>
> a new TLV Type will be registered as follows:
>
> Value: [ TBD-at-registration ]
> Description: Multi-Topology Capability
> Reference: [ RFC-to-be ]
>
> QUESTION: Are the authors intended to have a value from the range
> 0x0001-0x07FF?
>
> ACTION 2:
> in the Status Code Name Space subregistry in the Label Distribution
> Protocol
> (LDP) Parameters registry located at:
>
> http://www.iana.org/assignments/ldp-namespaces/
>
> a new Status Code will be registered as follows:
>
> Range/Value: [ TBD-at-registration ]
> E: (blank)
> Description: Invalid Topology ID
> Reference: [ RFC-to-be ]
>
> QUESTIONs:
> 1) Authors, please confirm if this new Status Code should be added to
> the range 0x00000000-0x1FFFFFFF (IETF Consensus).
>
> 2) The authors have inconsistent terms, "TBA1" and "TBA2", in this
> section.  The current text reads:
>
> o  New Status Code: "Invalid Topology ID" (requested code point: TBA2
>      from LDP registry "Status Code Name Space").
>
>
>            Registry:
>            Range/Value          Description
>            --------------      ------------------------------
>            TBA1                Invalid Topology ID
>
> We are confused if TBA1 is a typo.  The authors uses "TBA1" for
> the New LDP Capability TLV.  Another possibility: are the authors
> requesting the same value for both the New LDP Capability TLV and the
> New Status Code?
>
>
> ACTION 3:
> in the Address Family Numbers registry located at:
>
> http://www.iana.org/assignments/address-family-numbers/
>
> two, new address family numbers will be registered as follows:
>
> Number: [ TBD-at-registration ]
> Description: MT IP: Multi-Topology IP version 4
> Reference: [ RFC-to-be ]
>
> IANA notes that the authors have requested codepoint 26 for this registration.
>
> Number: [ TBD-at-registration ]
> Description: MT IPv6: Multi-Topology IP version 6
> Reference: [ RFC-to-be ]
>
> IANA notes that the authors have requested codepoint 27 for this registration.
>
> ACTION 4:
> a new registry called "MPLS Multi-Topology Identifiers" is to be
> created as defined by this document.
>
> QUESTION: Is this a brand new top level registry with its own new URL,
> or a sub-registry of an exiting registry?  Please see a list of
> existing registries at iana.org/protocols.
>
> IANA understands that there are initial registrations in this new
> registry as
> follows:
>
> Range/Value Purpose Reference
> ----------- ------------------------------------- ---------
> 0 Default/standard topology [ RFC-to-be ]
> 1 IPv4 in-band management [ RFC-to-be ]
> 2 IPv6 routing topology [ RFC-to-be ]
> 3 IPv4 multicast topology [ RFC-to-be ]
> 4 IPv6 multicast topology [ RFC-to-be ]
> 5 IPv6 in-band management [ RFC-to-be ]
> 6-3995      Unassigned for future IGP topologies  [This.I-D]
>              Assigned by Standards Action          [This.I-D]
> 3996-4095    Experimental                          [This.I-D]
> 4096-65534  Unassigned for MPLS topologies        [This.I-D]
>              Assigned by Standards Action
> 65535        Wildcard Topology                      [This.I-D]
>
>
> ACTION 5:
> in the Sub-TLVs for TLV Types 1, 16, and 21 subregistry of the
> Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry located at:
>
> http://www.iana.org/assignments/mpls-lsp-ping-parameters/
>
> two, new sub-TLV types will be registered as follows:
>
> Sub-Type: [ TBD-at-registration ]
> Sub-TLV Name: MT LDP IPv4 prefix
> Reference: [ RFC-to-be ]
>
> Sub-Type: [ TBD-at-registration ]
> Sub-TLV Name: MT LDP IPv6 prefix
> Reference: [ RFC-to-be ]
>
> IANA should allocate the next available numbers in the Sub-TLVs for
> TLV Types 1, 16, and 21 sub-registry.
>
> IANA understands that these are the only actions required to be
> completed upon approval of this document.
>
> Note: The actions requested in this document will not be completed
> until the document has been approved for publication as an RFC.
> This message is only to confirm what actions will be performed.
>
> Thank you,
>
> Pearl Liang

[Ballot comment]
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.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  The MPLS working group request that:

              LDP Extensions for Multi Topology Routing
              draft-ietf-mpls-ldp-multi-topology-07.txt

  is published as an RFC on the Standards Track.

  Since the document specifies new protocol behavior, new protocol
  elements, new sub-TLVs and Information elements this meets the
  criteria to be an RFC on the Standards track.

  The implementations and intended implementations that we know of
  all intended for production networks.
 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:


Technical Summary

  Multi-Topology (MT) routing is supported in IP networks with the use
  of MT aware IGPs.  In order to provide MT routing within
  Multiprotocol Label Switching (MPLS) Label Distribution Protocol
  (LDP) networks new extensions are required.

  This document describes the LDP protocol extensions required to
  support MT routing in an MPLS environment.

Working Group Summary

Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

  There is a strong support for this document in the working group
  and it has been has been well reviewed.

  After IESG last call there were a number of questions and issues
  that resulted in a significant revision to the document. The
  document was returned to the WG for an additional last call that
  showed support for the current revision of the document.
 
Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

  We know of implementations and intended implementations,
  further a poll has been sent to the working group mailing list
  requesting information.
¨
  This poll has just resulted in that we know of two more implementations
    in progress.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?
 
  Loa Andersson is the document shepherd.

  Adrian Farrel is/will be the responsible AD.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd have reviewed the document several times,
  e.g. when the document was first published as an individual
  document, when it was polled to become a working group document,
  and just before working group last call.
 
  The document shepherd believes it is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No such concerns!

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  There are two IPR claims filed against this document.

  Before the working group last call started the working group
  chairs sent a mail to the working group and the authors, asking
  any members of the working group whom were aware of IPRs to speak
  up and requiring the authors either to indicate if they were
  aware of IPRs or say that they were not.

  The authors have all said that they are not aware of any other
  IPR claims than those diclosed.



(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are tw IPR claims filed against this document. IPR claims
  #1707 and #1875.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  The working group is behind this document. It has been well
  discussed and reviewed. 


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such threats.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


  The is a warning that the document lack a disclaimer for
  pre-RFC5378 work; however this has been discussed between the
  shepherd, responsible AD and the authors.

  The document extends RFC4379, but does not reporduce any text from
  RFC4379. The disclaimer is not necessary and is thus not present.

  No other nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  There are no such formal review criteria.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  Yes, all references (normative and informative )are to existing
  RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  No downward references.



(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  The publication will extend RFC4379, this is captured and
  discussed in all relevant places in the document.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


  The IANA consideration section is clear and well written.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.


  No new IANA registries.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No formal language.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  The MPLS working group request that:

              LDP Extensions for Multi Topology Routing
              draft-ietf-mpls-ldp-multi-topology-07.txt

  is published as an RFC on the Standards Track.

  Since the document specifies new protocol behavior, new protocol
  elements, new sub-TLVs and Information elements this meets the
  criteria to be an RFC on the Standards track.

  The implementations and intended implementations that we know of
  all intended for production networks.
 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:


Technical Summary

  Multi-Topology (MT) routing is supported in IP networks with the
  use of MT aware IGPs. This document specifies the LDP
  procedures and protocol extensions required to support MT routing
  in an MPLS environment.

  This document describes the LDP protocol extensions required to
  support MT routing in an MPLS environment.

Working Group Summary

Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

  There is a strong support for this document in the working group
  and it has been has been well reviewed.
 
Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

  We know of implementations and intended implementations,
  further a poll has been sent to the working group mailing list
  requesting information.
¨
  This poll has just resulted in that we know of two more implementations
    in progress.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?
 
  Loa Andersson is the document shepherd.

  Adrian Farrel is/will be the responsible AD.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd have reviewed the document several times,
  e.g. when the document was first published as an individual
  document, when it was polled to become a working group document,
  and just before working group last call.
 
  The document shepherd believes it is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No such concerns!

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  There are two IPR claims filed against this document.

  Before the working group last call started the working group
  chairs sent a mail to the working group and the authors, asking
  any members of the working group whom were aware of IPRs to speak
  up and requiring the authors either to indicate if they were
  aware of IPRs or say that they were not.

  The authors have all said that they are not aware of any other
  IPR claims than those diclosed.



(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are tw IPR claims filed against this document. IPR claims
  #1707 and #1875.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  The working group is behind this document. It has been well
  discussed and reviewed. 


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such threats.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


  The is a warning that the document lack a disclaimer for
  pre-RFC5378 work; however this has been discussed between the
  shepherd, responsible AD and the authors.

  The document extends RFC4379, but does not reporduce any text from
  RFC4379. The disclaimer is not necessary and is thus not present.

  No other nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  There are no such formal review criteria.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  Yes, all references (normative and informative )are to existing
  RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  No downward references.



(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  The publication will extend RFC4379, this is captured and
  discussed in all relevant places in the document.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


  The IANA consideration section is clear and well written.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.


  No new IANA registries.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No formal language.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  The MPLS working group request that:

              LDP Extensions for Multi Topology Routing
              draft-ietf-mpls-ldp-multi-topology-07.txt

  is published as an RFC on the Standards Track.

  Since the document specifies new protocol behavior, new protocol
  elements, new sub-TLVs and Information elements this meets the
  criteria to be an RFC on the Standards track.

  The implementations and intended implementations that we know of
  all intended for production networks.
 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:


Technical Summary

  Multi-Topology (MT) routing is supported in IP networks with the
  use of MT aware IGPs. This document specifies the LDP
  procedures and protocol extensions required to support MT routing
  in an MPLS environment.

  This document describes the LDP protocol extensions required to
  support MT routing in an MPLS environment.

Working Group Summary

Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

  There is a strong support for this document in the working group
  and it has been has been well reviewed.
 
Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

  We know of implementations and intended implementations,
  further a poll has been sent to the working group mailing list
  requesting information.
¨
  This poll has just resulted in that we know of two more implementations
    in progres.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?
 
  Loa Andersson is the document shepherd.

  Adrian Farrel is/will be the responsible AD.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd have reviewed the document several times,
  e.g. when the document was first published as an individual
  document, when it was polled to become a working group document,
  and just before working group last call.
 
  The document shepherd believes it is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No such concerns!

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  There are two IPR claims filed against this document.

  Before the working group last call started the working group
  chairs sent a mail to the working group and the authors, asking
  any members of the working group whom were aware of IPRs to speak
  up and requiring the authors either to indicate if they were
  aware of IPRs or say that they were not.

  The authors have all said that they are not aware of any other
  IPR claims than those diclosed.



(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are tw IPR claims filed against this document. IPR claims
  #1707 and #1875.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  The working group is behind this document. It has been well
  discussed and reviewed. 


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such threats.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


  The is a warning that the document lack a disclaimer for
  pre-RFC5378 work; however this has been discussed between the
  shepherd, responsible AD and the authors.

  The document extends RFC4379, but does not reporduce any text from
  RFC4379. The disclaimer is not necessary and is thus not present.

  No other nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  There are no such formal review criteria.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  Yes, all references (normative and informative )are to existing
  RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  No downward references.



(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  The publication will extend RFC4379, this is captured and
  discussed in all relevant places in the document.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


  The IANA consideration section is clear and well written.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.


  No new IANA registries.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No formal language.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mpls-ldp-multi-topology-09.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has a question about one of the IANA actions requested in this document.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are six actions which IANA must complete.

First, in the TLV Type Name Space subregistry in the Label Distribution Protocol (LDP) Parameters registry located at:

http://www.iana.org/assignments/ldp-namespaces/

a new TLV Type will be registered as follows:

Value: [ TBD-at-registration ]
Description: Multi-Topology Capability
Reference: [ RFC-to-be ]

Second, in the Status Code Name Space subregistry in the Label Distribution Protocol (LDP) Parameters registry located at:

http://www.iana.org/assignments/ldp-namespaces/

a new Status Code will be registered as follows:

Range/Value: [ TBD-at-registration ]
E: (blank)
Description: Multi-Topology Capability not supported
Reference: [ RFC-to-be ]

Third, also in the Status Code Name Space subregistry in the Label Distribution Protocol (LDP) Parameters registry located at:

http://www.iana.org/assignments/ldp-namespaces/

a new Status Code will be registered as follows:

Range/Value: [ TBD-at-registration ]
E: (blank)
Description: Invalid Topology ID
Reference: [ RFC-to-be ]

Fourth, in the Address Family Numbers registry located at:

http://www.iana.org/assignments/address-family-numbers/

two, new address family numbers will be registered as follows:

Number: [ TBD-at-registration ]
Description: MT IP: Multi-Topology IP version 4
Reference: [ RFC-to-be ]

IANA notes that the authors have requested codepoint 26 for this registration.

Number: [ TBD-at-registration ]
Description: MT IPv6: Multi-Topology IP version 6
Reference: [ RFC-to-be ]

IANA notes that the authors have requested codepoint 27 for this registration.

Fifth, a new registry is to be created under the Label Distribution Protocol (LDP) Parameters grouping at:

http://www.iana.org/protocols

called the "LDP Multi-Topology (MT) ID Name Space"

IANA Question -> Using the definitions available in RFC 5226, what are the registration policies for the new registry.

IANA understands that there are initial registrations in this new registry as follows:

Range/Value Purpose Reference
----------- ------------------------------------- ---------
0 Default/standard topology [ RFC-to-be ]
1 IPv4 in-band management [ RFC-to-be ]
2 IPv6 routing topology [ RFC-to-be ]
3 IPv4 multicast topology [ RFC-to-be ]
4 IPv6 multicast topology [ RFC-to-be ]
5 IPv6 in-band management [ RFC-to-be ]
6-3995 Reserved for future IGP topologies [ RFC-to-be ]
3996-4095 Reserved for IGP experimental topologies [ RFC-to-be ]
4096-4127 Reserved for LDP topologies [ RFC-to-be ]
4128-65534 Reserved for LDP experimental topologies [ RFC-to-be ]
65535 Wildcard Topology [ RFC-to-be ]

Sixth, in the Sub-TLVs for TLV Types 1 and 16 subregistry of the Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry located at:

http://www.iana.org/assignments/mpls-lsp-ping-parameters/

two, new sub-TLV types will be registered as follows:

Sub-Type: [ TBD-at-registration ]
Sub-TLV Name: MT LDP IPv4 prefix
Reference: [ RFC-to-be ]

Sub-Type: [ TBD-at-registration ]
Sub-TLV Name: MT LDP IPv6 prefix
Reference: [ RFC-to-be ]

IANA understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (LDP Extensions for Multi Topology Routing) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'LDP Extensions for Multi Topology Routing'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-11-06 (this is a 3 week last call to allow
extra time as people are preparing for IETF-88). Exceptionally, comments
may be sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  Multi-Topology (MT) routing is supported in IP networks with the use
  of MT aware IGPs.  In order to provide MT routing within
  Multiprotocol Label Switching (MPLS) Label Distribution Protocol
  (LDP) networks new extensions are required.

  This document describes the LDP protocol extensions required to
  support MT routing in an MPLS environment.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-multi-topology/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-multi-topology/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1875/
  http://datatracker.ietf.org/ipr/1707/

AD review
=======

Hi authors,

Thanks for this document.

I have done my usual AD review which is intended to catch any issues
that I see, and to smooth out the wrinkles before the I-D goes to IETF
last call and IESG review.

As you will see below, I have a number of editorial comments (nits and
larger changes) and also a few questions/issues.

The biggest issue concerns the MT-ID and spans sections 3.4, 3.8, and 9.
I suggest you read the comments against those sections all together.
Note that in my comment for section 9, I think I have worked out what
you need to do, and so the resolution to the comments for 3.4 and 3.8
may simply be documenting this change to the IANA registry.

As usual, all my comments are up for discussion, so please don't feel
you are required to make changes if you think there is a good reason why
things are the way they are.

At the moment it looks like a new revision will be needed to address the
review, so I have set the flag in the datatracker. Please work with your
document shepherd to produce and post a new revision.

Thanks,
Adrian

===

The document seems to end with a spurious page header.

---

The index seems to be considerably adrift from reality.
In particular, there is no Appendix in this document.

---

Why do you say that this updates RFC 4379? Is it your belief that an
implementation of RFC 4379 will not be complete/conformant without these
extensions? Or are you just defining extensions which an implementation
in an MPLS-MT environment will need to support?

I note that you (in my view, correctly) do not say that this document
updates RFC 5036, yet it defines extensions to LDP in a similar way.
                                                                   
---

Please expand all acronyms on first use unless they show with an
asterisk in the RFC Editor's list at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

I see:
CSP
LSP
QoS

---

Abstract and Introduction

"IGP protocol" is bad because the "P" in "IGP" is "protocol".

---

The RFC Editor prefers documents to have the Introduction as Section 1.

You may prefer to make this change yourself, because it will possibly
cause some expansions of terms and acronyms that the RFC Editor might
so in a way you don't like.

---

In section 1, the term "MT Topology" is odd because the "T" of "MT"
stands for "Topology". Surely you don't mean "Multi Topology Topology"?

---

Section 3.1

s/infers/implies/

---

Section 3.2

I prefer that you don't repeat protocol encodings that are defined
elsewhere. This can cause nasty problems if you make a mistake or if
the original definition is updated.

It is enough for you to write...

  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.

  To extend IP address families for MT, two new Address Families named
  "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes
  within a topology scope.

---

Section 3.2 Figure 2

This figure gives the impression that both IPv4 and IPv6 addresses are
four bytes long!

I think you need:

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                    IP Address                                ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Reserved            |        MT-ID                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: MT IP Address Family Format

...and...

  Where "IP Address" is a variable length field padded to a four octet
  boundary and containing an IPv4 or IPv6 address/prefix for the "MT
  IP" and "MT IPv6" AFs respectively.  The field "MT-ID" corresponds to
  the 16-bit Topology ID for given address.

...but you need to check I got that right!

However, before doing this work, see my comment on Section 3.3

---

Section 3.2

  The proposed FEC Elements with "MT IP" Address Family can be used in

You are not proposing any more, you are defining!

See also section 3.6, 3.8, 4.1, 4.3, and 8

---

Section 3.2

  [RFC5036] does not specify the handling of "Unknown" Address
  Families.  Therefore, [RFC5036] will need to be updated to include
  the handling procedure for unknown address families.

Ouch!

This had me really worried because it implied that you are breaking
existing LDP deployments. But I discussed it with Loa, and he pointed me
at Section 3.4.1.1 of RFC 5036

  "If in decoding a FEC TLV an LSR encounters a FEC Element with an
    Address Family it does not support, it SHOULD stop decoding the FEC
    TLV, abort processing the message containing the TLV, and send an
    "Unsupported Address Family" Notification message to its LDP peer
    signaling an error.

    If it encounters a FEC Element type it cannot decode, it SHOULD stop
    decoding the FEC TLV, abort processing the message containing the
    TLV, and send an "Unknown FEC" Notification message to its LDP peer
    signaling an error."

So I think you can just delete this paragraph.

Furthermore, Section 3.5 defines a capability advertisement that enables
you to know whether it is safe to use one of the new AFs.  So surely you
should also say "MUST NOT send an MT AF unless the peer has said it can
handle it."

See my re-write in the next comment.

---

Section 3.3 appears to be repeating a lot of Section 3.2, but in a
better and more concise way. For example, Figure 3 nicely shows how the
Prefix FEC element works with the new AFs.

This leads me to think that Section 3.2 could be reduced to just a few
lines that say...

  The LDP base specification [RFC5036] (Section 4.1) defines the
  the use of an "Address Family" (AF) field in FEC Elements to indicate
  the encoding of the "Prefix" or "Address" that follows, and to
  indicate how the FEC should be interpreted.

  This document defines two new AF values named "MT IP" and "MT IPv6"
  that are used to specify the use of IPv4 or IPv6 within a topology
  scope.  The data associated with these new AFs includes an "MT-ID"
  field that carries the 16-bit Topology ID for a topology.

  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.

  FEC Elements with the new AFs can be used in any LDP message and
  procedures that currently specify and allow the use of FEC Elements
  with the IP or IPv6 AFs, but MUST NOT be used unless the peer has
  indicated it can handle them as described in Section 3.5.  Note that
  behavior by an LDP speaker that receives a FEC element containing an
  unknown AF is described in Section 3.4.1.1 of [RFC5036].

---

Section 3.4 is perfectly clear except it doesn't say what "reserved",
"special", and "translating" mean.

This opens up a number of questions including why you need a registry
at all.  Presumably the "translation" needed is to ensure that the
values used in LDP have the same meaning as they do in the IGP. If that
is the case, why not simply use exactly the same value?

And looking at the registry further, it seems to say that only values
allocated by IANA and stored in the registry can be used. That means
that an operator that wants to use MT in their network cannot just
assign values to the MT-IDs for the topologies because the registry
has no space for this to happen.

Now, it is possible that you have simply used the wrong words in the
registry in section 9, and failed to provide any explanation in the
text.  Note that "unassigned" means "not yet assigned, but available
to be assigned by IANA".  And "Reserved" means "Do not assign until
a new RFC defines how they should be used."

But there are other questions:

Why do you need 16 bits when ISIS has only 12 bits and OSPF only 8 bits?
I guess 16 is convenient to hold either, but how are the top 4 bits to
be handled?

How do you handle the case where there are multiple instances of an IGP
(or different IGPs) running?

If you *do* expect there to be a mapping function between IGP MT-ID and
LDP MT-ID, how do you ensure the same function is used at both ends of
an LDP session?

But Section 3.8 really does seem to say that only MT-IDs in the registry
are allowed, which seems to make this I-D almost useless because you
have only defined "default" (which we have already), "ISIS IPv6", and
"all". Isn't an operator allowed to partition their network into
topologies?

So...

I think what you need in Section 9 is...

  o  New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP
      Parameter" namespace.  The allocation policies for this registry
      are:

      Range          Registration Policy
      ------          -------------------
      0-3995          Expert Review
      3996-4095      Private Use
      4096-4127      Expert Review
      4128-4255      Private Use
      4256-4351      Reserved (IANA does not assign)
      4352-4511      Expert Review
      4512-65535      Private Use

      IANA is requested to populate this registry as follows:


      Range/Value    Purpose                                Reference
      -----------    -------------------------------------  ---------
      0              Default/standard topology in IS-IS      [This.I-D]
      1              IPv4 in-band management in IS-IS        [This.I-D]
      2              IPv6 routing topology in IS-IS          [This.I-D]
      3              IPv4 multicast topology in IS-IS        [This.I-D]
      4              IPv6 multicast topology in IS-IS        [This.I-D]
      5              IPv6 in-band management in IS-IS        [This.I-D]
      6-3995        Unassigned (intended to mirror IS-IS) 
      3996-4095      Reserved for private use (from IS-IS)  [This.I-D]
      4096          Default/standard topology in OSPF      [This.I-D]
      4097          Default multicast topology in OSPF      [This.I-D]
      4098          IPv4 in-band management in OSPF        [This.I-D]
      4099-4127      Unassigned (intended to mirror OSPF)   
      4128-4255      Reserved for private use (from OSPF)    [This.I-D]
      4256-4351      Reserved (IANA does not assign)        [This.I-D]
      4352-4511      Unassigned                             
      4512-65535    Reserved for Private Use                [This.I-D]

This would address many of the issues in Sections 3.4 and 3.8, and needs
to be discussed in those sections.

---

In Section 3.5

  o  Length: The length (in octets) of TLV.

Are you sure it is not just the length in octets of the value?
Compare with RFC 5036 Section 3.3

---

Sections 3.5 and 3.6 need to be more closely grouped.

Suggest moving most of 3.5 into 3.5.1 and moving 3.6 into 3.5.2

---

Section 3.6

  To announce its MT capability for an IP address family, LDP FEC type,
  and Multi Topology, an LDP speaker MAY send an "MT Capability"
  including the exact Typed Wildcard FEC element with corresponding
  "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT
  IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e.,
  set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID".  To
  announce its MT capability for both IPv4 and IPv6 address family, or
  for multiple FEC types, or for multiple Multi Topologies, an LDP
  speaker MAY send "MT Capability" with one or more MT Typed FEC
  elements in it.

I don't think this is "MAY" in either case. This *is* how the LDP
speaker announces it. There is no other way to announce it. So...

  To announce its MT capability for an IP address family, LDP FEC type,
  and Multi Topology, an LDP speaker sends an "MT Capability" including
  the exact Typed Wildcard FEC element with corresponding
  "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT
  IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e.,
  set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID".  To
  announce its MT capability for both IPv4 and IPv6 address family, or
  for multiple FEC types, or for multiple Multi Topologies, an LDP
  speaker sends "MT Capability" with one or more MT Typed FEC elements
  in it.

---

Section 3.6

  o  If an LSR has not advertised MT capability, its peer must not send
      messages that include MT identifier to this LSR.

Isn't that "MUST NOT"?

---

Section 3.8

  Certain MT topologies are assigned to serve predetermined purposes:

It is not the topology that is assigned, but the MT-ID. Should read:

  Certain MT-ID values are assigned to indicate specific meanings:

---

Section 3.8

It is not helpful to "propose" numbers in this section and then to
also reference Section 9 for the definitive numbers.  I suggest you
remove all numbers from this section and simply point at Section 9.

---

Section 4.2

  This MAY allow an LDP speaker to signal its IP convergence...

What does 2119 MAY mean in this context?

---

Section 4.3

  [RFC4379] defines procedures to detect data-plane failures in MPLS
  LSPs via LSP ping.  The specification defines a "Target FEC Stack"
  TLV that describes the FEC stack being tested.

Ha, ha! You got me :-)
s/The specification/That specification/

---

Section 4.3.1

        Sub-Type      Length            Value Field
        --------      ------            -----------------
            TBA5            5            MT LDP IPv4 prefix
            TBA6          17            MT LDP IPv6 prefix

Are you sure you don't mean 8 and 20?

---

Section 4.3.4

  When detect data plane failures using LSP Ping for a specific topoly,
  the router will intiate an LSP Ping request with the targer FEC stack

I think

s/When/To/

s/topoly/topology/

s/intiate/initiate/

s/targer/target/

---

Section 4.3.4

  For the case that the LSP ping with return path not specified , the
  reply packet may go through the default topology instead of the
  topology where the Echo Request goes through.

Is that really "the default" or "any"?
If you mean "the default" then I think you need some "MUST NOT" text to
talk about other topologies.

---

Section 5

  The extensions defined in this document utilise the existing LDP
  error handling defined in [RFC5036].  If an LSR receives an error
  notification from a peer for an MPLS-MT session, it terminates the
  LDP session by closing the TCP transport connection for the session
  and discarding all MT-ID label mappings learned via the session.

There is nothing wrong with this text, but it does open a question that
is not addressed anywhere in the document: what is the relationship
between LDP sessions and MT-IDs?  1:1, 1:n, n:1, n:m?

This is somewhat assumable from the discussion of multiple MT-ID
wildcard FEC elements in the Multi-Topology Capability TLV, but it is
not explicit.

---

Shouldn't Section 6 comment on how each of the new protocol elements
will not be seen by a legacy implementation because they are only used
after successful capability negotiation?

But you do need to describe how a legacy node will react to attempted
MT capability negotiation.

You could also restate the reference to RFC 5036 section 3.4.1.1 since
this issue seemed to be a question for you.

---

I'm slightly doubtful about the value of Section 7, but I note that the
point you are trying to convey is not quite worded correctly. You have:

  and the specified
  signaling mechanisms do not provide any way for the data plane to
  associate a given packet with a context-specific label space.

I don't think the signaling mechanism is relevant, and I think "context-
specific" hides what you are trying to say.  Perhaps you should have:

  and there is no way
  for the data plane to associate a received packet with any one
  topology, meaning that topology-specific label spaces cannot be used.

---

Section 9

  o  New Status Code: "Multi-Topology Capability not supported"
      (requested code point: TBA2 from LDP registry "Status Code Name
      Space").

This status code does not appear to be mentioned in the draft. How is
it used? Is an implementation that does not know the new MT Capability
TLV supposed to generate this status code? Or are you referencing an
existing error code: in which case it should not appear in this section.

  o  New Status Code: "Unknown Address Family" (requested code point:
      TBA4 from LDP registry "Status Code Name Space").

This status code does not appear to be mentioned in the draft. How is
it used? Is a legacy implementation that does not know either of your
new MT AFs supposed to generate this status code? But I suspect you are
just referencing an existing error code (see Section 3.2) as defined in
RFC 5036, and so you should not mention it in this section.

Figure 10 does not show either of these status codes.

---

Figure 10 shows a specific value for the new status code. Is this a
request or demand? I don't think it has already been allocated.

---

Section 9

  o  New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP
      Parameter" namespace.

This registry is discussed earlier in my notes. but please be aware that
you will need to define the allocation policy because it is a new
registry.

---

Section 9

I want to ask Loa Andersson to look again at the LSP Ping TLV
allocations to check that they conform to the work he is currently
doing with that registry.

---

It would help considerably to add a Manageability Considerations section
to this document because the function being added here is not simple to
manage or operate, and will have impact on the way that the network is
run. Good guidance on such sections can be found in RFC 5706. Appendix A
is particularly helpful at summarising things to consider.

--------------------