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

From: IJsbrand Wijnands <[email-masked]>
Date: Fri, 11 Feb 2011 20:31:23 +0100

Hi Eric,

Thanks for the comments, I've incorporated all of them.

I will also remove section 3 in the next revision if I don't get further comments from the list.

Thx,

Ice.

On 16 Nov 2010, at 17:30, Eric Rosen wrote:

> 
> 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?
> 
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls