Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
draft-ietf-mpls-ldp-p2mp-15

Network Working Group                                        C. Jennings
Internet-Draft                                                    Cisco
Intended status: Standards Track                              Z. Shelby
Expires: May 4, 2017                                                ARM
                                                                J. Arkko
                                                              A. Keranen
                                                                Ericsson
                                                              C. Bormann
                                                Universitaet Bremen TZI
                                                        October 31, 2016

            Media Types for Sensor Measurement Lists (SenML)
                        draft-ietf-core-senml-04

Abstract

  This specification defines media types for representing simple sensor
  measurements and device parameters in the Sensor Measurement Lists
  (SenML).  Representations are defined in JavaScript Object Notation
  (JSON), Concise Binary Object Representation (CBOR), eXtensible
  Markup Language (XML), and Efficient XML Interchange (EXI), which
  share the common SenML data model.  A simple sensor, such as a
  temperature sensor, could use this media type in protocols such as
  HTTP or CoAP to transport the measurements of the sensor or to be
  configured.

Status of This Memo

  This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF).  Note that other groups may also distribute
  working documents as Internet-Drafts.  The list of current Internet-
  Drafts is at http://datatracker.ietf.org/drafts/current/.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress."

  This Internet-Draft will expire on May 4, 2017.

Jennings, et al.          Expires May 4, 2017                  [Page 1]
Internet-Draft                    SenML                    October 2016

Copyright Notice

  Copyright (c) 2016 IETF Trust and the persons identified as the
  document authors.  All rights reserved.

  This document is subject to BCP 78 and the IETF Trust's Legal
  Provisions Relating to IETF Documents
  (http://trustee.ietf.org/license-info) in effect on the date of
  publication of this document.  Please review these documents
  carefully, as they describe your rights and restrictions with respect
  to this document.  Code Components extracted from this document must
  include Simplified BSD License text as described in Section 4.e of
  the Trust Legal Provisions and are provided without warranty as
  described in the Simplified BSD License.

Table of Contents

  1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  2.  Requirements and Design Goals . . . . . . . . . . . . . . . .  4
  3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  5
  4.  SenML Structure and Semantics . . . . . . . . . . . . . . . .  5
    4.1.  Base attributes . . . . . . . . . . . . . . . . . . . . .  6
    4.2.  Regular attributes  . . . . . . . . . . . . . . . . . . .  6
    4.3.  Considerations  . . . . . . . . . . . . . . . . . . . . .  7
    4.4.  Resolved Records  . . . . . . . . . . . . . . . . . . . .  8
    4.5.  Associating Meta-data . . . . . . . . . . . . . . . . . .  8
  5.  JSON Representation (application/senml+json)  . . . . . . . .  9
    5.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .  10
      5.1.1.  Single Datapoint  . . . . . . . . . . . . . . . . . .  10
      5.1.2.  Multiple Datapoints . . . . . . . . . . . . . . . . .  10
      5.1.3.  Multiple Measurements . . . . . . . . . . . . . . . .  11
      5.1.4.  Resolved Data . . . . . . . . . . . . . . . . . . . .  12
      5.1.5.  Multiple Data Types . . . . . . . . . . . . . . . . .  13
      5.1.6.  Collection of Resources . . . . . . . . . . . . . . .  13
      5.1.7.  Setting an Actuator . . . . . . . . . . . . . . . . .  14
  6.  CBOR Representation (application/senml+cbor)  . . . . . . . .  15
  7.  XML Representation (application/senml+xml)  . . . . . . . . .  17
  8.  EXI Representation (application/senml+exi)  . . . . . . . . .  19
  9.  Usage Considerations  . . . . . . . . . . . . . . . . . . . .  22
  10. CDDL  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  23
  11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
    11.1.  Units Registry . . . . . . . . . . . . . . . . . . . . .  25
    11.2.  SenML Label Registry . . . . . . . . . . . . . . . . . .  28
    11.3.  Media Type Registration  . . . . . . . . . . . . . . . .  29
      11.3.1.  senml+json Media Type Registration . . . . . . . . .  29
      11.3.2.  senml+cbor Media Type Registration . . . . . . . . .  31
      11.3.3.  senml+xml Media Type Registration  . . . . . . . . .  32
      11.3.4.  senml+exi Media Type Registration  . . . . . . . . .  33

Jennings, et al.          Expires May 4, 2017                  [Page 2]
Internet-Draft                    SenML                    October 2016

    11.4.  XML Namespace Registration . . . . . . . . . . . . . . .  34
    11.5.  CoAP Content-Format Registration . . . . . . . . . . . .  34
  12. Security Considerations . . . . . . . . . . . . . . . . . . .  35
  13. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  35
  14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  35
  15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
    15.1.  Normative References . . . . . . . . . . . . . . . . . .  35
    15.2.  Informative References . . . . . . . . . . . . . . . . .  37
  Appendix A.  Links Extension  . . . . . . . . . . . . . . . . . .  38
  Authors& from IESG Evaluation.

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

[Ballot comment]
Maybe not really for this document, but this references 5036
for security considerations, and 5036 says use TCP MD5 but
that 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)

[Ballot discuss]
Maybe not really for this document, but this references 5036
for security considerations, and 5036 says use TCP MD5 but
that 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?

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

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

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

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

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

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

First, in the Label Distribution Protocol (LDP) Parameters located at:

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

a new registry is to be created as follows:

The name of the registry is: "LDP MP Opaque Value Element basic type"

The range is values in the registry is 0-255 inclusive.  The initial
values for the registry are as follows:

Type  Description                                            Reference
----  ----------------------------------------------------  -----------
1    Generic LSP identifier                                [RFC-to-be]
255  Extended Type field is present in the following two  [RFC-to-be]
      bytes

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

Second, also in the Label Distribution Protocol (LDP) Parameters located at:

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

a new registry is to be created as follows:

The name of the registry is "LDP MP Opaque Value Element extended type"

The values in this registry range from 0-65335 inclusive.  There are no
initial values in this registry.  The registration policy for this
registry is:

0-32767: Standards Action with Early Allocation
32768-65535: First Come, First Served

Third, also in the Label Distribution Protocol (LDP) Parameters located at:

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

a new registry is to be created as follows:

The name of the registry is "LDP MP Status Value Element type"

The range of values in the registry is 0-255 inclusive.  There is a
single, initial allocation as follows;

Type  Description                                      Reference
----  -----------------------------------------------  -----------
1    MBB Status                                      [ RFC-to-be ]

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

Fourth, in the Forwarding Equivalence Class (FEC) Type Name Space in the
Label Distribution Protocol (LDP) Parameters located at:

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

the following three identifiers will have early allocations made
permanent and their reference point to the new [ RFC-to-be ]:

P2MP FEC type
MP2MP-up FEC type
MP2MP-down FEC type

IANA will make every effort to not disturb the existing values assigned
in early allocation.

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

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

the following three identifiers will have early allocations made
permanent and their reference point to the new [ RFC-to-be ]:

P2MP Capability Parameter - requested value 0x0508
MP2MP Capability Parameter - requested value 0x0509
MBB Capability Parameter - requested value 0x050A

IANA will make every effort to not disturb the existing values assigned
in early allocation.

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

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

the following identifier will have its early allocation made permanent
and their reference point to the new [ RFC-to-be ]:

LDP MP status - requested value 0x00000040

IANA will make every effort to not disturb the existing value assigned
in early allocation.

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

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

the following identifier will early allocations made permanent and their
reference point to the new [ RFC-to-be ]:

LDP MP Status TLV Type - requested value 0x096F

IANA will make every effort to not disturb the existing value assigned
in early allocation.

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

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:  (Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths) to Proposed Standard


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'
  as a 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 2011-07-04. 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 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.




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

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


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

  http://datatracker.ietf.org/ipr/1064/
  http://datatracker.ietf.org/ipr/1285/
  http://datatracker.ietf.org/ipr/1086/
  http://datatracker.ietf.org/ipr/1454/

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

Hi,

I have performed an AD review of your draft.

Don't panic!

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.

---

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

(LDP is a permitted acronym - no action needed)
LSP
LSR

---

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?

---

Section 2.2

  The combination of (Root Node Address,
  Opaque Value) uniquely identifies a P2MP LSP within the MPLS network.

With the current specification as shown in the figure, this is not completely accurate since two addresses from different families could have the same root node address value.

So your text should refer to the combination of {Root Node Address type, Root Node Address, Opaque Value).

---

2.3

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.

---

2.4

  2.  P2MP Label Map : a Label Map message with a FEC TLV with
      a single P2MP FEC Element  and Label TLV with label L.                 
      Label L MUST be allocated from the per-platform label space (see
      [RFC3031] section 3.14) of the LSR sending the Label Map 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  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 .     

  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

Please add text to clarify (at least for the CRC32 case).

---

2.4.1.4

Trivially...

  Assuming its old forwarding state was
  L'-> {  ..., }, its new forwarding state
  becomes L'-> {  ..., , }.

Misses the case that I=Ii for some value of i.

---

2.4.2.1

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

OLD

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Typed Wcard  | Type = mLDP  |  Len = 2    |      AFI      ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~              |
      +-+-+-+-+-+-+-+-+

  Type Wcard:  As specified in [RFC5918]


  Type:  mLDP FEC Element Type as documented in this draft.

NEW

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Typed Wcard  |    Type      |  Len = 2    |      AFI      ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~              |
      +-+-+-+-+-+-+-+-+

  Type Wcard:  As specified in [RFC5918]


  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:

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


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 has
no 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 these
as 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.

Document Quality

The document is well reviewed by the MPLS working group.