Subject: [mpls] wglc on draft-ietf-mpls-ldp-p2mp-11

From: Loa Andersson <[email-masked]>
Date: Tue, 09 Nov 2010 15:50:22 +0800

Working Group,

this is to start a 2 week+ working group last call on
draft-ietf-mpls-ldp-p2mp-11.

Please review the document and send comments to the
[email-masked] mailing lsit.

The working group last call ends November 26 - 2010.

/Loa

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 16 Nov 2010 11:24:10 +0000

Loa, Authors,

I will split my comments into two e-mails: this one covering substantive comments and another covering purely editorial comments.

Non-editorial:

1) Section 2.1 - the "divider" between the "P2MP Capability" field and the Length field is not on a bit boundary making it unclear whether the P2MP Capability field is 14 bits or 15 bits (I assume it is meant to be 14 bits).

2) Section 2.1 - "If the peer has not advertised the corresponding capability, then no label messages using the P2MP FEC Element should be sent to the peer."

Is this really lowercase should or is it really a "SHOULD NOT be sent to"

3) Section 3, last paragraph 
"Another consideration is the various techniques that can be used to splice unicast LDP MP2P LSPs to the LDP P2MP LSP; these will be described in a later revision."

As this is in WG LC I suggest rewording to something like
"Another consideration is the technique to use to splice unicast LDP MP2P LSPs to the LDP P2MP LSP; this document does not mandate a specific technique, leaving it to each application to specify an appropriate technique to use."

or just leave it out of scope:

"Another consideration is the technique to use to splice unicast LDP MP2P LSPs to the LDP P2MP LSP; the specific technique to use is outside the scope of this document."

4) Section 4.1 (Same comment as for section 2.1, i.e) - "If the peer has not advertised the corresponding capability, then no label messages using the P2MP FEC Element should be sent to the peer."

Is this really lowercase should or is it really a "SHOULD NOT be sent to"

5) Section 12 - IANA Considerations:
The ocument creates 3 new name spaces to be managed by IANA but does not specify any guidelines for managing the number ranges and does not specify an allocation policy (or policies) to be used.

Ben
 
On 9 Nov 2010, at 07:50, Loa Andersson wrote:

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 16 Nov 2010 11:25:06 +0000

Loa, Authors,

Below are my editorial comments on draft-ietf-mpls-ldp-p2mp-11:

1) Abstract:

"These extensions are also referred to as mLDP Multicast LDP"

Should that be "These extensions are also referred Multicast LDP (mLDP)"?

2) Section 1 - Introduction:

Seems to mix root/leaf & ingress/egress. Should probably try and be consistent and pick on set of terms?

3) Section 1 - Introduction:

The last sentence seems a little strangely worded. Maybe something like "Related documents that may be of interest include  [I-D.ietf-mpls-mp-ldp-reqs], [I-D.ietf-l3vpn-2547bis-mcast] and [RFC4875].

[Note: I reordered the references as I think the reqs & l3vpn documents are more relevant to this document than P2MP RSVP-TE]

4) 2.4.1.1, para 2 s/amoung/among/

5) 2.4.2 s/The following lists/The following sections list/

6) Section 4.3, bullet 6, 2nd sentence s/Label L MUST/Label Lu MUST/

7) Section 4.3.1.3 bullet 1 s/bases/basis/

8) Section 4.3.1.3 bullet 2 s/build/built/

9) Section 4.4.2 s/The following lists/The following sections list/

10) Section 5 use LFT but it is not expanded anywhere.

11) Section 6.2.1 s/and an additional information/and any additional information/

12) Section 7.1.1 s/LSP label is send to the upstream LSR/LSP label is sent to the upstream LSR/

13) Section 7.1.1 s/installed the context/installed in the context/

14) Section 9.4.3 s/that an other/that another/

15) Section 9.4.4 s/is send to/is sent to/

16) Section 9.4.5 s/are send to/are sent to/

17) Section 15.1

draft-ietf-mpls-upstream-label-05 is now RFC5331

draft-ietf-mpls-ldp-upstream-02 is now draft-ietf-mpls-ldp-upstream-08

draft-ietf-mpls-ldp-capabilities-02 is now RFC5561

draft-ietf-mpls-ldp-typed-wildcard-07 is now RFC5918

18) Section 15.2

draft-ietf-mpls-mp-ldp-reqs-04 has expired

draft-ietf-l3vpn-2547bis-mcast-06 is now draft-ietf-l3vpn-2547bis-mcast-10

draft-ietf-mpls-multicast-encaps-09 is now RFC 5332

---

From: Thomas Morin <[email-masked]>
Date: Tue, 16 Nov 2010 16:09:35 +0100

Hi Ben,

Thomas Morin:
> Ben Niven-Jenkins :
>> Non-editorial:
>>
>> 1) Section 2.1 - the "divider" between the "P2MP Capability" field 
>> and the Length field is not on a bit boundary making it unclear 
>> whether the P2MP Capability field is 14 bits or 15 bits (I assume it 
>> is meant to be 14 bits).
>
> Half bits are hard to encode indeed!  ;-)
> But I think that this field is more likely just 2 bytes...(16 bits).

More exactly, the whole flags+capability TLV field is for sure two bytes 
(RFC5561).
Hence the field itself is 14 bits as you assumed.

My apologies...

-Thomas

---

From: Eric Rosen <[email-masked]>
Date: Tue, 16 Nov 2010 11:30:38 -0500

I am delighted to see this draft moving forward, but there are a few minor
things I think need to be fixed first.

1. Section 3

   I suggest removing this entire section, as it has no relevant content.
   
   All it says is that it is possible to send a packet to the root of an
   P2MP LSP and then for the root to distribute the packet down the LSP.
   While this is perfectly true, nothing is said about how to make this
   happen.   Apparently this section is really a placeholder for something
   that was supposed to be "described in a later revision".  Since that
   material was never provided, this section doesn't really say anything
   useful.

   The last two paragraphs of this section make unsubstantiated claims about
   the value or lack thereof of using a P2MP LSP in this manner.  The
   advantages of using one or another technique for some application depends
   on the application and is outside the scope of this document.

2. IANA Considerations: LDP MP Opaque Value Element

   The draft calls for IANA to create a new registry for "LDP MP Opaque
   Value Element types".  However, it fails to specify the allocation
   policy.  Also, the size of the field, as specified in section 2.3, is
   only one octet.  The use of a non-extensible one-octet type field is, I
   think, a bad practice.  I've made this mistake often, and have always
   ended up regretting it.

   I would suggest that we define a particular value of the octet, say 255,
   to mean that the next two bytes contain an "extended type code".  Let's
   ask IANA to create two registries:

   a. LDP MP Opaque Value Element Basic type

      The range will be 0-255, with the following values defined in this
      document:

         1: Generic LSP identifier
         255: Extended Type field is present in the following two bytes

      I propose that the allocation policy for this field should be
      "Standards Action with Early Allocation".

   b. LDP MP Opaque Value Element Extended type:

      The range will be 0-65335, with the following allocation policies:

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

   I would propose modifying section 2.3 to include a second diagram, i.e.:

      The LDP MP Opaque Value Element is encoded as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Type < 255    | Length                        | Value ...     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
       ~                                                               ~
       |                                                               |
       |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     or

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Type = 255    |        Extended Type          | Length (high) |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
       | Length (low)  |                Value                          |
       +-+-+-+-+-+-+-+-+
       ~                                                               ~
       |                                                               |
       |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     BTW the existing picture in the draft needs to have the two rows of bit
     numbers shifted one to the right, as done above.

     Also BTW, the IANA Considerations first paragraph and last paragraph
     seem to call for the creation of the same registry.

     The draft also calls for a second registry to be created by IANA for
     LDP MP Status Value Element type.  The same considerations may apply.

3. The acronym "mLDP".

   This acronym is defined only in the abstract, and then is used in
   sections 5 and 10.  I think it needs to be defined in section 1.2
   (terminology).  Even so, the RFC Editor is bound to ask why "LDP" is used
   in some places and "mLDP" in others; we might want to make this more
   uniform.

4. Section 2.1 diagram:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1|0| P2MP Capability (TBD IANA)|      Length (= 1)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1| Reserved    |
       +-+-+-+-+-+-+-+-+

   I believe the above is a corrected rendition.

5. Section 4.1 diagram:

   The diagram in the draft is:
   
        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1|0| MP2MP Capability (TBD IANA) |    Length (= 1)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1| Reserved    |
       +-+-+-+-+-+-+-+-+

   This shows 2 flags, a 15-bit capability value, and a 15-bit length field.

   Is that the intention?

---

From: Thomas Morin <[email-masked]>
Date: Tue, 16 Nov 2010 15:31:08 +0100

Hi Ben,

-Thomas

---

From: Thomas Morin <[email-masked]>
Date: Thu, 25 Nov 2010 14:14:40 +0100

Hi Loa, working group,

I did a review of the draft a few months ago, and most of the issues I 
had are now fixed.

There is still one issue pending that I think remains to be solved, 
related to how the specs handle the effects of transients unicast 
routing loops for P2MP LSPs (MP2MP already had satisfying text in this 
respect). Some discussion has already been done on the list (last email: 
http://www.ietf.org/mail-archive/web/mpls/current/msg05041.html ), and 
off the list, but without a conclusion yet.

A part from that, I think the document is overall in a pretty good shape.

-Thomas

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Fri, 26 Nov 2010 17:27:17 -0600

Dear all,
Below are my comments on this draft.

Regards,
Mustapha.
--------------------------------------------------------------------------------------------
1. Section 2.4.1.2. Determining the forwarding interface to an LSR
"
   Suppose LSR U receives a MP Label Map message from a downstream LSR
   D, specifying label L. Suppose further that U is connected to D over
   several LDP enabled interfaces or RSVP-TE Tunnel interfaces.   
"
MA> I am not sure what "RSVP-TE Tunnel interfaces" exactly means but it should be clarified that LSR U must have a targeted hello adjacency with LSR D since the RSVP-TE LSP may have multiple hops before terminating on LSR D. Otherwise LSR D will not accept packets received from LSR U with the ILM containing the RSVP LSP label followed by the LDP P2MP FEC label.

2. Section 2.4.1.5. Root Node Operation
"
   Suppose the root node Z receives a P2MP Label Map <X, Y, L> from LSR
   T. Z checks whether it already has forwarding state for <X, Y>.  If
   not, Z creates forwarding state to push label L onto the traffic that
   Z wants to forward over the P2MP LSP (how this traffic is determined
   is outside the scope of this document).

   If Z already has forwarding state for <X, Y>, then Z adds "push label
   L, send over interface I" to the nexthop, where I is the interface
   associated with LSR T and determined via the procedures in
   Section 2.4.1.2.
"
MA> The above two paragraphs are a bit fragmented and some details are missing. I suggest the following write-up:
"
   Suppose the root node Z receives a P2MP Label Map <X, Y, L> from LSR
   T. Z checks whether it already has forwarding state for <X, Y>.  If
   not, Z creates forwarding state to push label L over interface I 
   associated with LSR T. Interface I is determind via the procedures in 
   Section 2.4.1.2.

   If Z already has forwarding state for <X, Y>, it updates it with the 
   push operation of label L over interface I associated with LSR T. 
   Assuming its old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, 
   its new forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, L>}.

   The determination of which traffic is forwarded over the P2MP LSP at 
   the root node is  outside the scope of this document.
"

3. Section 3. Shared Trees
MA> It seems to me this is an application of the LDP P2MP LSP that requires additional forwarding mechanism for both L3 IP multicast and VPLS to make it work. Without those mechanisms well defined and because there is no new control plane procedure described here, it hard to justify why this section should be in this draft.  
I suggest this gets moved into an informative appendix.

4. Section 6.2.1. LDP MP Status sent in LDP notification messages

"
   The Status TLV status code is used to indicate that LDP MP status TLV
   and an additional information follows in the Notification message's
   "optional parameter" section.  Depending on the actual contents of
   the LDP MP status TLV, an LDP P2MP or MP2MP FEC TLV and Label TLV may
   also be present to provide context to the LDP MP Status TLV.  (NOTE:
   Status Code is pending IANA assignment).
"
MA> I suggest movig the NOTE into the first sentence to clarify that we are talking about the Status TLV status code:
"
   The Status TLV status code (pending IANA assignment) is used to indicate 
   that LDP MP status TLV and an additional information follows in the 
   Notification message's "optional parameter" section. Depending on the 
   actual contents of the LDP MP status TLV, an LDP P2MP or MP2MP FEC TLV and 
   Label TLV may also be present to provide context to the LDP MP Status TLV.
"

5. Section 6.2.2. LDP MP Status TLV in Label Mapping Message
"
   An example of the Label Mapping Message defined in RFC3036 is shown
   below to illustrate the message with an Optional LDP MP Status TLV
   present.
"
MA> I assume the reference was meant to be RFC 5036.

6. Section 8.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.
"
MA> I do not think we can mandate that a single root must be forwarding at any given time. In current deployment of IP multicast, with or without P2MP LSP, the option of having the leaf node pick up traffic from one of two P2MP LSPs exists. It is up to operators to select which is the most suitable for their application.
---------------------------------------------------------------------------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Tuesday, November 09, 2010 2:50 AM
To: [email-masked]; George Swallow; Adrian Farrel; Stewart Bryant
Subject: [mpls] wglc on draft-ietf-mpls-ldp-p2mp-11

Working Group,

this is to start a 2 week+ working group last call on draft-ietf-mpls-ldp-p2mp-11.

Please review the document and send comments to the [email-masked] mailing lsit.

/Loa

-- 

                                              +46 767 72 92 13 _______________________________________________