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

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 8 Feb 2011 09:08:33 +0100

Hi Ben,

Thanks for the 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).

I fixed it to be 14.

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

Changed to "SHOULD NOT"

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

Section 3 is underdeveloped and either needs to be modified or removed. This section is not mLDP specific and applies equally to RSVP-TE P2MP LSPs, so I think it does not really belong in this draft. I raised it with Rahul Aggarwal last IETF and I'm waiting for him to come back to me with a proposal.

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

Changed to "SHOULD NOT".

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

Got it, will add it,

Thx,

Ice.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 8 Feb 2011 09:46:32 +0100

Hi Ben,

Thanks for the detailed comments below. See inline.

> 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)"?

Changed it to "These extensions are also referred to as	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?

It looks correct to me. The term 'leaf' can be seen as a more generic way to describe a leg of a MP-LSP, since when it comes to MP2MP a leaf can be both ingress and egress. Also, root and ingress don't have to be the same when it comes to MP2MP LSPs.

> 3) Section 1 - Introduction:
> 
> The last sentence seems a little strangely worded. Maybe something like "

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

Sounds good.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

> 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

Fixed.

> 
> 
> 18) Section 15.2
> 
> draft-ietf-mpls-mp-ldp-reqs-04 has expired

Has been updated now.

> 
> draft-ietf-l3vpn-2547bis-mcast-06 is now draft-ietf-l3vpn-2547bis-mcast-10
> 
> draft-ietf-mpls-multicast-encaps-09 is now RFC 5332

Fixed.

Thx,

Ice.

> On 9 Nov 2010, at 07:50, Loa Andersson wrote:
> 
>> 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
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 8 Feb 2011 11:19:05 +0000

Ice,

> It looks correct to me. The term 'leaf' can be seen as a more generic way to describe a leg of a MP-LSP, since when it comes to MP2MP a leaf can be both ingress and egress. Also, root and ingress d…

Good point. I'm happy for you to ignore my previous comment.

Ben