Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol
draft-ietf-mpls-mp-ldp-reqs-08

[Ballot discuss]
I don't intend to hold up publication over the matter, but I'd like to have a conversation about why this document is Historic, not Informational. RFC 2026 states:

  A specification that has been superseded by a more recent
  specification or is for any other reason considered to be obsolete is
  assigned to the "Historic" level.

As far as I can see, this document has not been superseded and is not to be considered obsolete.

[Ballot discuss]
The only indication *in the document* of why this thing is being put forward as "Historic" is because it is "documenting the work done". But normally if that were the case, the document would be published as Informational. Historic documents are supposed to be "superseded by a more recent specification or is for any other reason considered to be obsolete", and nowhere in this document does it indicate any newer specification that supersedes it nor any reason it is obsolete. In fact, it reads as if it *is* a set of requirements, and uses lots of RFC 2119 language to do so. That sounds to me like it is trying to be standards track.

However, when I go to the IESG Writeup, there is an indication that it is being published Historic because there is a specification that "already exists and there are deployed implementations" and that somehow this document might "conflict" with those. That reads to me like "the WG came up with this set of requirements for LDP extensions, but we didn't follow them". If *that's* true, then I want to hear about why these requirements weren't followed and why they shouldn't be. But when I try to figure out how the WG made the decision to go forward with this document, all I get in the writeup is:

Working Group Summary

  This document is an output from the MPLS working group and we have
  good support for it.

Document Quality

  The document is well reviewed.

I'm sorry, but that writeup is utterly content-free. I have no idea why the MPLS WG would have *any* support for this document, and the above does nothing to explain it. I want a real IESG writeup of this document before I can even attempt to understand what the WG thought it was doing with this document.

[Ballot discuss]
The only indication *in the document* of why this thing is being put forward as "Historic" is because it is "documenting the work done". But normally if that were the case, the document would be published as Informational. Historic documents are supposed to be "superseded by a more recent specification or is for any other reason considered to be obsolete", and nowhere in this document does it indicate any newer specification that supersedes it nor any reason it is obsolete. In fact, it reads as if it *is* a set of requirements, and uses lots of RFC 2119 language to do so. That sounds to me like it is trying to be standards track.

However, when I go to the IESG Writeup, there is an indication that it is being published Historic because there is a specification that "already exists and there are deployed implementations" and that somehow this document might "conflict" with those. That reads to me like "the WG came up with this set of requirements for LDP extensions, but we didn't follow them". If *that's* true, then I want to hear about why these requirements weren't followed and why they shouldn't be. But when I try to figure out how the WG made the decision to go forward with this document, all I get in the writeup is:

Working Group Summary

  This document is an output from the MPLS working group and we have
  good support for it.

Document Quality

  The document is well reviewed.

I'm sorry, but that writeup is utterly bogus and useless. I have no idea why the MPLS WG would have *any* support for this document, and the above does nothing to explain it. I want a real IESG writeup of this document before I can even attempt to understand what the WG thought it was doing with this document.

IANA notes that this document does not contain a standard IANA
Considerations section. After examining the draft, IANA understands
that, upon approval of this document, there are no IANA Actions that
need completion.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Requirements for Point-To-Multipoint Extensions to the Label Distribution Protocol) to Historic


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Requirements for Point-To-Multipoint Extensions to the Label
  Distribution Protocol'
  as a Historic

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 2011-05-26. 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

  This document lists a set of functional requirements that served as
  input to the design of Label Distribution Protocol (LDP) extensions
  for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP),
  in order to deliver point-to-multipoint applications over a Multi
  Protocol Label Switching (MPLS) infrastructure.

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

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-mp-ldp-reqs/

No IPR declarations have been submitted directly on this I-D.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
AD Review

Hi,                   

Don't panic!

I have performed my AD review of your draft. The purpose of the review
is to catch any nits or issues before the document goes forward to IETF
last call and IESG review. By getting these issues out at this stage we
can hope for a higher quality review and a smoother passage through the
process.

Thank you for a good analysis of the requirements for P2MP LDP. Most of
my issues are either relatively minor editorial changes or take the
form of questions. A few points, however, may take a little bit of new
textto resolve.

All of my comments (especially the questions) are up for discussion,
and you should not feel rail-roaded into making changes. But I do think
my comments need to be addressed before the draft moves forward, and I
would like to see a revised I-D to tidy up the editorial points.

I have moved the draft into "AD-review:Revised-ID-needed" state in the
datatracker, and I look forward to seeing the new revision which I can
put forward for IETF last call.

Thanks,
Adrian

---

Having 7 authors listed on the front page is somewhat unusual and is
also likely to mean that the document is slow to progress through the
later stages of publication.

Would it be possible to consider moving everyone except for the editor
off the front page? You will still all be listed as authors at the end
of the document.

---

You need to add a couple of acronyms to Section 1.1

LSP
LSR
MP2P

---

Section 2

  and
  have already deployed LDP for P2P traffic                         

s/and/and who/

---

Section 3.1 seems to replicate a deal of text from Section 2.

---

Section 5.1

  Only one copy of a packet MUST be sent on a given
  link of a P2MP LSP.

I think you mean...

  Exactly one copy of a packet MUST be sent on a given
  link of a P2MP LSP.

...or better...

  More than one copy of a packet MUST NOT be sent on a given
  link of a P2MP LSP.

But really, the ambiguity is caused by the passive voice.
So...

  An LSR MUST NOT send more than one copy of a packet on any
  given link of a P2MP LSP.

---

Section 5.2

  As such, a new LDP FEC that is suitable for P2MP forwarding MUST be
  specified.

You are prejudging the solution by stating that existing FECs are not
suitable. How about:

  If existing FECs cannot be used for this purpose, a new LDP FEC
  that is suitable for P2MP forwarding MUST be specified.

---

Section 5.3

I have no issues with the assumption of bidirectional links, but maybe
you should state the assumption?

OLD
  It is RECOMMENDED that the P2MP LSP routing rely upon a shortest path
  to the Ingress LSR so as to setup an MPLS shortest path tree.
NEW
  It is RECOMMENDED that the P2MP LSP routing rely upon a shortest path
  to the Ingress LSR so as to setup an MPLS shortest path tree assuming
  all links are bidirectional.
END

But, are you sure you want shortest path trees? It is certainly the
easiest solution to build using the mechanism recommended, but I wonder
whether the requirement here is being driven by the solution you have
in mind, rather than being the real requirement.

Anyway, you said earlier in the document that an objective was to
optimise resource usage in network, and shortest path trees don't
guarantee that. So maybe you need to go back to that base requirement
and soften it to say "make better use of network resources."

---

Section 5.4

I think you need to add that the mechanisms by which an ingress can
discover the identities of the egresses attached to the P2MP LSP are
also out of scope.

---

Section 5.4

  The P2MP LDP mechanism MUST allow the dynamic addition and removal of
  leaves to and from a P2MP LSP, without any restriction (provided
  there is network connectivity).

I agree that the mechanism must allow this.

One of the issues we faced with P2MP RSVP-TE was a belief that there
might be limits to the branching capabilities in some nodes. This is
potentially both a physical limit for the node, and a practical limit
for the LSP (if round-robin replication is needed).

So the mechanism needs to allow a node to say "I can't be a branch
for any more spurs of this tree."

The solution to this situation might be in direct conflict to your
requirement in 5.1 about duplicate packets on a "link". Again, see
the way we got around this in P2MP RSVP-TE.

---

Section 5.7

  This may rely on extensions to the LDP Loop detection mechanism
  defined in [RFC5036].  A loop detection mechanism may require
  recording the set of LSRs traversed on the P2MP Tree.  The P2MP loop
  avoidance mechanism MUST NOT impact the scalability of the P2MP LDP
  solution.

I think both "may" should be "MAY"

---

Section 5.8

  Given that P2MP LDP routing should rely on the RIB, the achievement
  of the following requirements also implies the underlying routing
  protocols (IGP, etc.).

Something wrong with this sentence around "also implies".

---

Section 5.8.1


  A mechanism MUST be defined to prevent constant P2MP LSP teardown and
  rebuild which may be caused by the instability of a specific link/
  node in the network.  This will rely on IGP dampening but may be
  completed by specific dampening at the LDP level.

Again, this is driving the solution a bit hard.
If you really want to say "will rely" then you should convert it to
"MUST rely".
s/may/MAY/ in the last subclause.

---

Section 5.9

I am not sure why you limit this case to a LAN.

Would you consider replacing "LAN" with "multi-access network"?
Needs a little rewording around "LAN interface" but that looks easy
enough.

---

Section 5.16.

  A solution MUST avoid single points of failures provided there is
  enough network connectivity.

What does this mean?
It shows up again in section 6.1.

---

Section 5.18

  In order to allow for a smooth migration, the P2MP LDP mechanism
  SHOULD offer as much backward compatibility as possible.  In
  particular, the solution SHOULD allow the setup of a P2MP LSP along
  non-Branch Transit LSRs that do not support P2MP LDP extensions.

Hooray for this, but note that if a legacy LSR is at a topological
branch, it will result in duplicate packets being sent by an upstream
LSR on some links that the P2MP LSP traverses. This would be in direct
conflict with your requirement in 5.1 about duplicate packets on a
"link". Maybe you need to redefine a "link of a P2MP LSP"?

---

Section 6.

  For traffic delivery between a group of N Leaf LSRs which are acting
  indifferently as Ingress or Egress LSRs, it may be useful to setup a
  shared tree connecting all these LSRs, instead of having N P2MP LSPs.

"acting indifferently" has some unfortunate overtones!

How about...

  For traffic delivery between a group of N LSRs that may be ingress
  and egress LSRs on different P2MP flows, it may be useful to setup a
  shared tree connecting all these LSRs, instead of having N P2MP LSPs.

Or did you mean

  For traffic delivery between a group of N LSRs that all act as
  ingress and egress LSRs on different P2MP flows, it may be useful to
  setup a shared tree connecting all these LSRs, instead of having N
  P2MP LSPs.

This shows up in 6.1 as well.

---

Section 6.1

  Requirements for P2MP LSPs, set forth in section 6, apply equally to
  MP2MP LSPs.  Particular attention should be given on the below
  requirements:

s/6/5/

---

Section 6.1

  o  Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that
      may trigger exponential growth of traffic.  Note that this
      requirement is more challenging with MP2MP LSPs as a LSR can
      receive traffic for a given LSP on multiple interfaces.

s/can receive/can legitimately receive/

---

Section 6.1

Are you sure that the following two requirements are not in conflict:

  o  It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths to a
      specific LSR called root LSR;

  o  The solution SHOULD avoid that all traffic between any pair of
      leaves is traversing a root LSR, and SHOULD as much as possible
      minimize the distance between two leaves (similarly to PIM-Bidir
      trees);

---

7.1.  Performances

s/Performances/Performance/

---

Section 7.1

I thought that optimality of the use of network resources was a
criterion

---

Section 8

More important than commenting on the security implications of *this*
document is to set security requirements for the P2MP solution. This
should include the normal control plane considerations, but should
also examine the risks of a leaf adding itself to a tree to which
it does not belong. I think there may be some specific additional
requirements on the solution in this regard.

---

Section 10

We don't normally name people's companies in the Acknowledgements
section. One reason (as in this case) is that some of them change jobs.

---

Section 11

According to the use in Section 5.1, RFC 4461 is a normative reference.

The MPLS WG requests that:
  Requirements for Point-To-Multipoint Extensions to the Label
  Distribution Protocol
  draft-ietf-mpls-mp-ldp-reqs-06

is published as an Historical RFC.


> (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 be
forwarded to the IESG for publication, given that we request publication
as an Historical RFC.

The document has been developed as an Informational RFC, but the
document was overtaken by events and there today exist implementations
that is not 100% aligned with these requirements, the working group
has neverteless agreed on perserving the document as an Historical RFC.


> (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?

The document has been reviewed in the MPLS working group. No concerns.

The shephered is convinced that this is sufficient review for this
document.


> (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. There is no IPR claim for this draft.



> (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?

The workig group want to perserve this work on ldp p2mp requirements,
the document will no longer be guiding develoopement of protocol
specifications, since there already exists stable protocol specifications?
implemetnations and deployment. There are potential discrepancies between
these requirments and the actual specification, that is why we want to
publish with historic status.



> (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 not report any nits, modulo the fact that is was
published 2010 and we have a warning "not current year". The document
shepherd thinks this as should be.


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

Note: The shepherd is uncertain what normative references means in
a informational document that is published with historic status!


> (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 are no request for IANA allocations in this document.


> (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 lists a set of functional requirements for Label
  Distribution Protocol (LDP) extensions for setting up point-to-
  multipoint (P2MP) Label Switched Paths (LSP), in order to deliver
  point-to-multipoint applications over a Multi Protocol Label
  Switching (MPLS) infrastructure.  It is intended that solutions that
  specify LDP procedures for setting up P2MP LSP satisfy these
  requirements.

  Most of these requirements are still valid and useful to document.
  However, since a specifiaction already exists and there are .eployed
  implementations, we want to avoid ptoential conflicts between
  requirements and specification and therefore asks for publication
  of this document as an Informational RFC with Historical status


Working Group Summary

  This document is an output from the MPLS working group and we have
  good support for it.

Document Quality

The document is well reviewed.