State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation.

2011-07-14

14

Dan Romascanu

[Ballot comment]This is a mature and well written document and I have no concerns about its quality and no special operational issues. However, as ...[show all]

[Ballot comment]This is a mature and well written document and I have no concerns about its quality and no special operational issues. However, as this is quite a significant extension of the LDP I would expect such a document to include a minimal set of operational considerations. Is a revision / extension of RFC 3815 considered for P2MP LDP? If not is there any other standard management interface considered? If all is proprietary at protocol level what initialization, configuration objects and operations, performance monitoring and/or notifications should be considered at minimum by a network operator in order to activate and manage properly a network that deploys this protocol? If this information belongs to some other document please point to it.

2011-07-14

14

Dan Romascanu

[Ballot Position Update] Position for Dan Romascanu has been changed to Abstain from Discuss

2011-07-14

14

Stephen Farrell

[Ballot comment]Maybe not really for this document, but this references 5036for security considerations, and 5036 says use TCP MD5 butthat when something ...[show all]

[Ballot comment]Maybe not really for this document, but this references 5036for security considerations, and 5036 says use TCP MD5 butthat when something better comes along that ought be used. Since we now have TCP-AO, (rfc 5926) is there a plan to move to that?

Are gopher: URIs really appropriate to be used now? (Definition of CRC32)

2011-07-14

14

Stephen Farrell

[Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss

2011-07-14

14

David Harrington

[Ballot Position Update] New position, No Objection, has been recorded

2011-07-14

14

Jari Arkko

[Ballot Position Update] New position, No Objection, has been recorded

2011-07-14

14

Adrian Farrel

State changed to IESG Evaluation from Waiting for AD Go-Ahead.

2011-07-14

14

Stephen Farrell

[Ballot comment]Are gopher: URIs really appropriate to be used now? (Definition of CRC32)

2011-07-14

14

Stephen Farrell

[Ballot discuss]Maybe not really for this document, but this references 5036for security considerations, and 5036 says use TCP MD5 butthat when something ...[show all]

[Ballot discuss]Maybe not really for this document, but this references 5036for security considerations, and 5036 says use TCP MD5 butthat when something better comes along that ought be used. Since we now have TCP-AO, (rfc 5926) is there a plan to move to that?

2011-07-14

14

Stephen Farrell

[Ballot Position Update] New position, Discuss, has been recorded

2011-07-14

14

Pete Resnick

[Ballot Position Update] New position, No Objection, has been recorded

2011-07-14

14

Dan Romascanu

[Ballot discuss]This is a mature and well written document and I have no concerns about its quality and no special operational issues. However, as ...[show all]

[Ballot discuss]This is a mature and well written document and I have no concerns about its quality and no special operational issues. However, as this is quite a significant extension of the LDP I would expect such a document to include a minimal set of operational considerations. Is a revision / extension of RFC 3815 considered for P2MP LDP? If not is there any other standard management interface considered? If all is proprietary at protocol level what initialization, configuration objects and operations, performance monitoring and/or notifications should be considered at minimum by a network operator in order to activate and manage properly a network that deploys this protocol? If this information belongs to some other document please point to it.

2011-07-14

14

Dan Romascanu

[Ballot Position Update] New position, Discuss, has been recorded

2011-07-13

14

Gonzalo Camarillo

[Ballot Position Update] New position, No Objection, has been recorded

2011-07-13

14

Wesley Eddy

[Ballot Position Update] New position, No Objection, has been recorded

2011-07-13

14

spt

[Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss

2011-07-13

14

Adrian Farrel

Ballot writeup text changed

2011-07-13

14

Adrian Farrel

Ballot writeup text changed

2011-07-13

14

Robert Sparks

[Ballot Position Update] New position, No Objection, has been recorded

2011-07-13

14

Adrian Farrel

Ballot writeup text changed

2011-07-13

14

Ron Bonica

[Ballot Position Update] New position, Yes, has been recorded

2011-07-13

14

spt

[Ballot comment]Expand FEC on first use (sec 2.1).

Section 5.2.2: r/RFC3036/[RFC5056]

Section 5.2.2: r/Optional/OPTIONAL in ...[show all]

[Ballot comment]Expand FEC on first use (sec 2.1).

Section 5.2.2: r/RFC3036/[RFC5056]

Section 5.2.2: r/Optional/OPTIONAL in the intro?

Section 10: r/configure/configured

2011-07-13

14

spt

[Ballot discuss]#1) In Sections 2.1, 3.1, 5, and 8.3, the U-bit is set to 1. Is there some text, which ...[show all]

[Ballot discuss]#1) In Sections 2.1, 3.1, 5, and 8.3, the U-bit is set to 1. Is there some text, which I may very well have missed, that addresses why this choice was made? RFC 5561 leaves it up to the capability document, but it seems like there ought to be some text to explain the choice.

#2) For the reserved bits in Sections 2.1, 3.1, and 8.3, all need to point an RFC/draft that describes how to handle reserved bits (e.g., RFC 5036? - 5561 should have said something about them but it doesn't) or state the following:

Reservered This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt.

#3) Section 2.4.1.1 (Determining one's 'upstream LSR') recommends using an operation based on CRC32 for selecting among candidate upstream LSRs. How important is it for the selection to be uniformly distributed? CRC32 is known to have poor avalanche properties that might make it unsuitable as a hash function, even for non-cryptographic purposes.

#4) In 8.2, it's interesting that you choose to not use something like the S-bit and reserved bits because there are only two status codes in the byte. Are there only ever going to be two status codes? If more are envisioned should there be an IANA registry for the status codes?

#5) You really need to add RFC 5561 to the security considerations because of the use of 5561 for advertisements.

#6) Add a normative reference for CRC32.

2011-07-13

14

spt

[Ballot Position Update] New position, Discuss, has been recorded

2011-07-12

14

Russ Housley

[Ballot comment]The Gen-ART Review by Joel Halpern on 23-June-2011 resulted in a small amount of discussion. The need for that discussion indicates ...[show all]

[Ballot comment]The Gen-ART Review by Joel Halpern on 23-June-2011 resulted in a small amount of discussion. The need for that discussion indicates to me that the document needs a better introduction. In particular, the reader needs to be told that the same TLVs are being used to reporting on the status of LSPs as well as a downstream device sending a request to an upstream device.

In addition, Section 3.3.1.3 describes two methods for installing the upstream path of a MP2MPLSP. After carefully describing both, it says to always use the second method. Would it not be better to describe the constraint (that the upstream path must be in place all the way to the root before it claims to be established), and then describe the one method that meets the requirement.

2011-07-12

14

Russ Housley

[Ballot Position Update] New position, No Objection, has been recorded

2011-07-12

14

Stewart Bryant

[Ballot comment]"The loops are transient and will disappear as soon as the unicast routing protocol converges. "

Strictly they disappear when both the unicast routing ...[show all]

[Ballot comment]"The loops are transient and will disappear as soon as the unicast routing protocol converges. "

Strictly they disappear when both the unicast routing converges AND THEN mLDP converges to use the new unicast topology. The point here is that the microloop time will be longer than the unicast routing protocols convergence time. Also one may note that the loop time is usually dominated by LFIB update time.

2011-07-12

14

Stewart Bryant

[Ballot Position Update] New position, Yes, has been recorded

2011-07-11

14

Peter Saint-Andre

[Ballot Position Update] New position, No Objection, has been recorded

2011-07-11

14

Adrian Farrel

[Ballot comment]Please address the following "minor issues" from the GenArt review by Joel Halpern:

The definition (section 1.2) of MP2MP LSPs should ...[show all]

[Ballot comment]Please address the following "minor issues" from the GenArt review by Joel Halpern:

The definition (section 1.2) of MP2MP LSPs should indicate that even though all nodes are allowed to send on the LSP, there is still a distinguished root node.

---

The LDP MP Opaque Value Element extended type (section 2.3, second definition) seems to be gratuitous complexity, adding extra matching cases in the LDP processing path for no stated value. Is there really believed to be a need for more than 254 types of Opaque values? If so, explain it in the document.

---

Section 3.3.1.3 begins by describing two methods for installing the upstream path of a MP2MPLSP. After carefully describing both, it says to only and always use the second method. Would it not be better to describe the constraint (that the upstream path must be in place all the way to the root before it claims to be established), and then describe the one method that meets taht. Just don't describe a method that is not to be used.

2011-07-11

14

Adrian Farrel

[Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel

2011-07-11

14

Adrian Farrel

Ballot has been issued

2011-07-11

14

Adrian Farrel

Created "Approve" ballot

2011-07-06

14

Amanda Baber

ANA understands that, upon approval of this document, there are sevenactions which IANA must complete.

The IESG has received a request from the Multiprotocol Label Switching WG(mpls) to consider the following document:- 'Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths' <draft-ietf-mpls-ldp-p2mp-14.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicitsfinal comments on this action. Please send substantive comments to theietf@ietf.org mailing lists by 2011-07-04. Exceptionally, comments may besent to iesg@ietf.org instead. In either case, please retain thebeginning of the Subject line to allow automated sorting.

Abstract

This document describes extensions to the Label Distribution Protocol for the setup of Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths in Multi-Protocol Label Switching networks. These extensions are also referred to as Multipoint LDP. Multipoint LDP constructs the P2MP or MP2MP Label Switched Paths without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such Label Switched Paths in a receiver-initiated manner. There can be various applications for Multipoint Label Switched Paths, for example IP multicast or support for multicast in BGP/MPLS L3VPNs. Specification of how such applications can use a LDP signaled Multipoint Label Switched Path is outside the scope of this document.

I review all drafts that I am responsible for before putting them forward for IETF last call. The main objective is to catch nits and minor issues that would show up during the last call or in IESG review. The intention is to help polish your document and make sure it is clean and shiny so that other reviewers will stick to the technical details.

Most of my comments are pretty trivial, but there are quite a few of them and a couple need a bit of discussion. I think this merits a quick respin of the document before I issue the IETF last call. As soon as I see a new revision posted, I'll set the ball in motion.

Of course, all of my issues are up for discussion.

Thanks for the work,Adrian

---

As noted in the write-up, RFC 4664 is an unused reference. I think it can simply be removed unless it was intended to be added to the final paragraph of Section 1.

---

Abstract

Some consistency in hyphenation, please. I think you need to adopt "point-to-multipoint" and "multipoint-to-multipoint" as in the title.

---

AcronymsNeed to expand them on first use in the main text (Abstract doesn't count). I find:

(LDP is a permitted acronym - no action needed)LSPLSR

---

Please s/draft/document/ in the text so that when it is published as an RFC the text is accurate.

---

Section 1

Only a single copy of the packet will be sent on any link traversed by the MP LSP (see note at end of Section 2.4.1).

Is this strictly true in all cases. are there not fringe cases, just as there were in P2MP RSVP-TE, where a branch is logically made upstream of a common link because of limited branching capabilities at the downstream end of the link?

---

Section 1.2

Leaf node: A Leaf node can be either an Egress or Bud LSR when referred in the context of a P2MP LSP. In the context of a MP2MP LSP, an LSR is both Ingress and Egress for the same MP2MP LSP and can also be a Bud LSR.

I think...s/an LSR is both Ingress and Egress/a leaf is both Ingress and Egress/

---

Section 2.1

The figure in this section appears to state that the S-bit must always be set to 1. That means that the capability cannot be withdrawn. I have no issue with that, but I think that if this is you intention, you must say that the S-bit must always be set to 1, the capability cannot be withdrawn, and the processing if S=0 is received. OTOH, if you allow withdrawal, you can leave "S" in the figure and refer to RFC5561 for the meaning.

---

Pedantic point I don't propose you address (unless you have more spare than you should have)...

The Opaque Value field is not truly opaque, since we can look into it and find a series of opaque elements.

---

Section 2.2

Can you explain to me why the working group wanted to allow the P2MP FEC to use any address family from IANA's "Address Family Numbers" registry to identify the root LSR?

OLD Type: The Type of the LDP MP Opaque Value Element basic type is to be assigned by IANA.NEW Type: The Type of the LDP MP Opaque Value Element. IANA maintains a registry of basic types (see Section 11).

---

2.3

We don't generally define empty TLVs and objects.

Can you convince me of the need for the Extended Type? Are you predicting a large number of FCFS opaque values?. You are surely not expecting many standards track types.

---

2.3

OLD Extended Type: The Extended Type of the LDP MP Opaque Value Element extended type is to be assigned by IANA.NEW Extended Type: The Extended Type of the LDP MP Opaque Value Element. IANA maintains a registry of extended types (see Section 11).

---

A point of pedantry, but you repeatedly refer to the "Label Map" message and (of course :-) it is really the "Label Mapping" message.

While you are at liberty to make this "MUST" requirement with the WGs support, it would be good if you gave the reason rather than "sneaking" it in. I assume that you want to do this to make FRR easier, but it is not immediately clear why P2MP is in any way different from P2P on upstream interfaces. Or maybe it is because you want to allow the choice of downstream interface to rest with the upstream LSR (per 2.4.1.2).

Can you add a short clause to say why the per-platform label space is used?

---

2.4.1

The remainder of this section specifies the procedures for originating P2MP Label Map messages and for processing received P2MP

s/The remainder of this/This/

---

You have two instances (spot the block copy!) of "label map" in lower case.

---

2.4.1.1

A node Z that wants to join a MP LSP <x, y=""> determines the LDP peer U which is Z's next-hop on the best path from Z to the root node X. If there is more than one such LDP peer, only one of them is picked. U is Z's "Upstream LSR" for <x, y="">.

When there are several candidate upstream LSRs, the LSR MAY select one upstream LSR.

The "MAY" seems to be in contradiction to the previous paragraph that appears to say that the LSR MUST select exactly one upstream LSR.

---

2.4.1.1

CRC32 is not a well-known acronym and would benefit from a reference.

---

2.4.1 and 2.4.1.1

It seems that it is important to be precise about what is meant by the "opaque value" (Y). This is particularly important in 2.4.1.1 because there is an interop dependency relying on the input to the hash function. You might mean:- the whole opaque value TLV- the opaque value field of the opaque value TLV (i.e., the concatenation of the whole opaque value elements)- the value field of the opaque value element- the concatenation of the value fields from each of the value fields of the opaque value elements

If a leaf node Z discovers (by means outside the scope of this document) that it has no downstream neighbors in that LSP, and that it has no need to be an egress LSR for that LSP, then it SHOULD send

Just some subtle re-wording needed. We *do* know the means by which Z discovers it has no downstream neighbors -- that is what this document is about! The parentheses apply to the second clause (that it has no need to be an egress).

---

2.4.2.2.

In the light of the procedure set out in 2.4.3 and 8., should you recommend that propagation of Label Withdraw should be delayed to prevent full LSP teardown when there is a small change in the path of the trunk of an LSP? Maybe a fringe case we can leave to implementations?

---

Section 3

Many of the nits in section 2 apply here, too.

---

Section 3

While it is possible that the root of an MP2MP LSP is also a leaf and can act as a data source, I think that...

An MP2MP LSP is much like a P2MP LSP in that it consists of a single root node, zero or more transit nodes and one or more leaf LSRs acting equally as Ingress or Egress LSR.

Should read "two or more leaf LSRs" since the semantic change from P2MP is that leaf nodes are ingresses as well as egresses, and it would make no sense to have only one.

---

Section 3

I can't help feeling that some figures would help understanding the path that packets are expected to take on an MP2MP LSP since this is key to working out what label state is installed.

----

5.1

OLD Type: The type of the LDP MP Status Value Element is to be assigned by IANA.NEW Type: The type of the LDP MP Status Value Element. IANA maintains a registry of status value types (see Section 11).

And in the figure s/Type(TBD)/Type/

---

5.2. LDP Messages containing LDP MP Status messages

The LDP MP status message may appear either in a label mapping message or a LDP notification message.

I think s/status message/status TLV/ throughout.

---

5.2.1

An LDP MP status TLV sent in a notification message must be accompanied with a Status TLV.

This is a statement of fact not a piece of new protocol spec, so you are correct to use lower case "must". But you should include a reference at this point.

---

7.1. Root node redundancy - procedures for P2MP LSPs

Since all leafs have set up P2MP LSPs to all the roots, they are prepared to receive packets on either one of these LSPs. However, only one of the roots should be forwarding traffic at any given time, for the following reasons: 1) to achieve bandwidth savings in the network and 2) to ensure that the receiving leafs don't receive duplicate packets (since one cannot assume that the receiving leafs are able to discard duplicates). How the roots determine which one is the active sender is outside the scope of this document.

The "should" seems strong since I know of deployed networks where 1+1 style P2MP transmission is performed and the application layer is responsible for sorting out duplicates that arise on failover. 1+1 is chosen in the face of network cost because of the high level of reliability that is wanted.

---

8.3

Same issue with the S-bit apparently always set meaning the capability cannot be withdrawn.

---

Section 9

This is not clear. The figure shows "Type=mLDP". There are two FEC Elements defined in the document so I think you need...

Type: The type of FEC Element Type. Either the P2MP FEC Element or the MP2MP FEC Element using the values defined for those FEC Elements when carried in the FEC TLV as defined in this document

---

Section 10

I am a bit disappointed by the Security Section. While it is true that the security relationships and techniques between LDP peers are not changed, and the imperatives are the same, you have introduced a new type of service that has a new attack vector.

In P2P LSPs, the sender has some control over the receiver, but this is less the case in leaf-initiated join to P2MP LSPs. I think this section should at least note that there is no way for a root to validate the leafs of the P2MP tree. Probably the only security you can offer is that;- the leafs all form part of the same trusted network- the opaque values could be made unguessably large- the opaque values could be distributed in a secure way

---

Section 11

Can you please add...

The requested code point values listed below have been allocated by IANA through early allocation.

...between...

The allocation policy for this space is 'Standards Action with Early Allocation'

...and...

This document requires allocation of three new code points from the IANA managed LDP registry "Forwarding Equivalence Class (FEC) Type Name Space". The values are:

2011-05-15

13

Adrian Farrel

State changed to AD Evaluation from Publication Requested.

2011-05-10

13

Cindy Morgan

> (1.a) Who is the Document Shepherd for this document? Has the> Document Shepherd personally reviewed this version of the> ...[show all]

> (1.a) Who is the Document Shepherd for this document? Has the> Document Shepherd personally reviewed this version of the> document and, in particular, does he or she believe this> version is ready for forwarding to the IESG for publication?

Loa Andersson is the Document Shepherd.He has reviewed the document and believes it is ready to beforwarded to the IESG for publication.

We know of implementations both drafts.

> (1.b) Has the document had adequate review both from key WG members> and from key non-WG members? Does the Document Shepherd have> any concerns about the depth or breadth of the reviews that> have been performed?

Yes the has had good review from key people. The document shepherd hasno concerns about the quality of the review.

> (1.c) Does the Document Shepherd have concerns that the document> needs more review from a particular or broader perspective,> e.g., security, operational complexity, someone familiar with> AAA, internationalization or XML?

No.

> (1.d) Does the Document Shepherd have any specific concerns or> issues 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. Has an IPR disclosure related to this document> been filed? If so, please include a reference to the> disclosure and summarize the WG discussion and conclusion on> this issue.

No such concerns.

> (1.e) 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?

Supported by the working group.

> (1.f) 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> entered into the ID Tracker.)

No threats or extreme discontent.

> (1.g) Has the Document Shepherd personally verified that the> document satisfies all ID nits? (See the Internet-Drafts Checklist> and http://tools.ietf.org/tools/idnits/). Boilerplate checks are> not enough; this check needs to be thorough. Has the document> met all formal review criteria it needs to, such as the MIB> Doctor, media type and URI type reviews?

The nits tool does report one nit (unused reference), suggest that we fix that together with the comments form the AD rev.

> (1.h) Has the document split its references into normative and> informative? 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> strategy for their completion? Are there normative references> that are downward references, as described in [RFC3967]? If> so, list these downward references to support the Area> Director in the Last Call procedure for them [RFC3967].

References are correctly split. But one informative is unused!

> (1.i) Has the Document Shepherd verified that the document IANA> consideration section exists and is consistent with the body> of the document? If the document specifies protocol> extensions, are reservations requested in appropriate IANA> registries? Are the IANA registries clearly identified? If> the document creates a new registry, does it define the> proposed initial contents of the registry and an allocation> procedure for future registrations? Does it suggest a> reasonable name for the new registry? See [RFC5226]. If the> document describes an Expert Review process has Shepherd> conferred with the Responsible Area Director so that the IESG> can appoint the needed Expert during the IESG Evaluation?

There is a correctly documented IANA section in the draft, setting up three new registries and requesting code points from theseas well as existing registries.

> (1.j) Has the Document Shepherd verified that sections of the> document that are written in a formal language, such as XML> code, BNF rules, MIB definitions, etc., validate correctly in> an automated checker?

No such formal language.

> (1.k) 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

This document specifies extensions to the Label Distribution Protocol (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. LDP with these extensions are also referred to as Multipoint LDP (mLDP). Runing mLDP will result in estgablishing P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be several applications for P2MP/MP2MP LSPs, but these are outside the scope of this document.

Working Group Summary

The document has been reviewed by the MPLS working group. This document has also been reviewed by a Rtg Area Directorate revieweriand all comments have been resolved.