Subject: Re: [mpls] MPLS-RT review of draft-jin-mpls-mldp-leaf-discovery

From: "Kamran Raza (skraza)" <[email-masked]>
Date: Tue, 24 Jul 2012 18:56:49 +0000

Hello authors/chairs,

As MPLS-RT process, I've reviewed the document. Please see below summary and details of my review:

Summary of review

=================

a. is the document coherent?

There are few areas which need more work / clarification.

b. is it useful?

Yes.

c. is technically sound ?

Need some more details and clarification on both LDP and BGP sections (items listed below under "Detailed comments").

d. is ready to be considered for WG adoption ?

IMO, the authors need to address/close the main comments [ see below ], and publish next rev before WG adoption call.

Detailed comments:

=================

1- The document proposed "leaf discovery" procedures. However, it is not clear to a reader about exactly what's being discovered:

Leaf address ? Leaf attributes/capabilities ? [ looking at the later sections, one deduces that it is just the leaf node address ].

2- Similar to #1 above:

   The document refers to "leaf node information" at several places without elaborating more about it.

   What exactly is this info ? is this just the sender LSR Id ? or is it encoded in opaque value of FEC ?

For #1 and #2, need to clarify exactly what does "leaf discovery" and "leaf node information" means in terms of contents.

3- The document states that leaf discovery is useful for both "root initiated" and "leaf initiated" applications.

Can you please specify/elaborate more on a use case for leaf discovery which benefits an "leaf initiated" app , and how ?

[ section 2 is not very clear to me for leaf initiated case ] . Moreover, later section 4 on "Leaf discovery" only talks about 'root initiated apps.

4- Although document's title/other text suggest applicability to both p2mp/mp2mp, it is not made clear in specific sections

  if procedure listed in those sections are just for p2mp or both for p2mp/mp2mp ? Moreover, need to clarify if there are any

differences in these procedures.

5- LDP capability:

   The document section 4.1 on T-LDP suggests using/sharing the existing mLDP "P2MP" capability [base mLDP RFC 6388].

   I've few comments in this regards:

   i) The document claims to address both p2mp/mp2mp cases so why "P2MP" only capability is negotiated here, whereas mLDP negotiates separate p2mp and mp2mp capabilities ?

   ii) I am not sure if piggybacking on existing mLDP capabilities is right thing .. it should define its own LDP capability.

6- Use of Label messages:

   Firstly, this section 4.1 is very thin on LDP protocol detail. Need more content.

   The document section 4.1 specifies use of LDP Label Mapping and Withdraw messages (with Imp-Null label) to indicate leaf join/leave.

   IMO, this is not a good idea to use LDP label messages to convey this info for following reasons:

    i) use of imp-null label in the message to mean something special may pose problems if in future imp-null is to be used by any application for other reasons.

    ii) you are making presence of "Label TLV" mandatory in your label-wdw messages – which is contrary to LDP spec RFC 5036 which specifies "Label TLV" as an optional param. If you need to enforce this, this is an "update" to RFC 5036.

    iii) If leaf and root are directly connected, there will be two set of Label mapping/wdw messages exchanged – one for MP LSP and other for Leaf-Discovery. These different set carrying "same" FEC but potentially different "labels" will be potentially confusing.

    iv) As per my comment # 2,  what/how would receiver extract leaf node info from the rcvd Label-mapping msg. This needs to be clarified.

Considering above points, the better solution is to use LDP Notification with MP Status — I.e. extend/use "MP Status" notification to convey leaf join/leave. [ Note : a MP Status Notification msg contains both the FEC and the Status code ]. If you agree with the use of LDP MP Status, then you should define new/separate LDP capability for this extension.

7- Leaf address:

   Refer to section 4.2.1, the "leaf node" information carried in BGP is "Leaf node address". Couple of comments:

    i) Similar information is needed under LDP section.

    Ii) This document is hardcoding address to an IP type, which is not correct. If mLDP root address is generic enough, why define

        mLDP leaf address as "IP" specific. You should define the leaf address in the same way as root address — I.e.

       [ Address Family, Address ] where Address and its length is dictated by the Addr-Family. Please note that your existing definition will NOT work for other address families – e.g. For "MT mLDP" (draft-iwijnand-mpls-mldp-multi-topology-02), the address is in the scope of a given topology.

8- Typed Wildcard MP FEC:
  i) The document T-LDP section indicate use of MP FEC in LDP message for leaf discovery, but does not indicate Typed WC MP FEC.
  IMO, this is very important functionality it will be useful to use Typed WC MP FEC for "withdrawing" ALL the previous join by the leaf towards a root.

   ii) If you refine LDP label procedures and decide to continue using label msgs (and not Notification messages), then a root can also send Typed Wildcard MP FEC Label-Request message to all potential leafs to learn/re-learn leafs for MP FECs as leaf respond to Label-Request. This will

9- Minor comments:

- section 2 para 2: it can be rephrased - all it is trying to say is that an existing MP LSP can be shared amongst

  different apps - which is currently not being done.

- Terminology: need to fix some incorrect use of terminology - e,g, T-LDP is defined as "Target LDP" instead of "Targeted LDP". Moreover, the definition of "MP2MP FEC" is not accurate/precise enough.

Regards,

-- Kamran

From: Ross Callon <[email-masked]<mailto:[email-masked]>>
Date: Thu, 12 Jul 2012 12:53:44 -0400
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Syed Kamran Raza (skraza)" <[email-masked]<mailto:[email-masked]>>, Vero Zheng <[email-masked]<mailto:[email-masked]>>
Cc: Loa Andersson <[email-masked]<mailto:[email-masked]>>, "George Swallow (swallow)" <[email-masked]<mailto:[email-masked]>>, Martin Vigoureux <[email-masked]<mailto:[email-masked]>>, Ross Callon <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: MPLS-RT review of draft-jin-mpls-mldp-leaf-discovery

Jeremy, Kamran, Vero;

You have been selected as an MPLS Review team reviewers for
draft-jin-mpls-mldp-leaf-discovery

Note to authors: You have been CC’d on this email so that you can know that
this review is going on. However, please do not review your own document.

Reviews should comment on whether the document is coherent, is it useful
(ie, is it likely to be actually useful in operational networks), and is
the document technically sound?  We are interested in knowing whether the
document is ready to be considered for WG adoption (ie, it doesn’t have to
be perfect at this point, but should be a good start).

Reviews should be sent to the document authors, WG co-chairs and secretary,
and CC’d to the MPLS WG email list. If necessary, comments may be sent
privately to only the WG chairs.

Are you able to review this draft by July 27, 2012 (ie, prior to the IETF
meeting in Vancouver)?

Thanks, Ross
(as MPLS WG chair)

---

From: Lizhong Jin<[email-masked]>
Date: Wed, 1 Aug 2012 14:03:58 +0800

Hi Kamran,
Sorry for the late reply. Thank you for the detail review, please see 
inline below.

Regards
Lizhong

"Kamran Raza (skraza)" <[email-masked]> wrote 2012/07/25 02:56:49:

> Need some more details and clarification on both LDP and BGP 
> sections (items listed below under "Detailed comments"). 
> 
> IMO, the authors need to address/close the main comments [ see below
> ], and publish next rev before WG adoption call.
> 
> Detailed comments:
> =================
> 
> 1- The document proposed "leaf discovery" procedures. However, it is
> not clear to a reader about exactly what's being discovered:
> Leaf address ? Leaf attributes/capabilities ? [ looking at the later
> sections, one deduces that it is just the leaf node address ].
> 
> 2- Similar to #1 above:
> For #1 and #2, need to clarify exactly what does "leaf discovery" 
> and "leaf node information" means in terms of contents.
[Lizhong] good catch, it is leaf address discovery. We will fix this in 
next version.

> 
> 3- The document states that leaf discovery is useful for both "root 
> initiated" and "leaf initiated" applications. 
> Can you please specify/elaborate more on a use case for leaf 
> discovery which benefits an "leaf initiated" app , and how ? 
> [ section 2 is not very clear to me for leaf initiated case ] . 
> Moreover, later section 4 on "Leaf discovery" only talks about 'root
> initiated apps.
[Lizhong] accurately saying, leaf discovery is useful for mLDP based 
P2MP/MP2MP LSP multiplexing/aggregating between leaf and root initiated 
apps. The leaf discovery will not benefit if there is no root initiated 
apps. Please tell me which sentence leads to some misunderstanding.

> 
> 4- Although document's title/other text suggest applicability to 
> both p2mp/mp2mp, it is not made clear in specific sections
>   if procedure listed in those sections are just for p2mp or both 
> for p2mp/mp2mp ? Moreover, need to clarify if there are any 
[Lizhong] The procedure in sections are for both P2MP/MP2MP, and the two 
have no difference in procedures. We will explicitly say that in next 
version.

> 
> 5- LDP capability:
>    The document section 4.1 on T-LDP suggests using/sharing the 
> existing mLDP "P2MP" capability [base mLDP RFC 6388]. 
>    i) The document claims to address both p2mp/mp2mp cases so why 
> "P2MP" only capability is negotiated here, whereas mLDP negotiates 
> separate p2mp and mp2mp capabilities ? 
[Lizhong] should negotiate p2mp and mp2mp capabilities separately. Will 
fix this in next version.

>    ii) I am not sure if piggybacking on existing mLDP capabilities 
> is right thing .. it should define its own LDP capability.
> 
>    The document section 4.1 specifies use of LDP Label Mapping and 
> Withdraw messages (with Imp-Null label) to indicate leaf join/leave.
>     i) use of imp-null label in the message to mean something 
> special may pose problems if in future imp-null is to be used by any
> application for other reasons.
>     ii) you are making presence of "Label TLV" mandatory in your 
> label-wdw messages – which is contrary to LDP spec RFC 5036 which 
> specifies "Label TLV" as an optional param. If you need to enforce 
> this, this is an "update" to RFC 5036.
>     iii) If leaf and root are directly connected, there will be two 
> set of Label mapping/wdw messages exchanged – one for MP LSP and 
> other for Leaf-Discovery. These different set carrying "same" FEC 
> but potentially different "labels" will be potentially confusing.
>     iv) As per my comment # 2,  what/how would receiver extract leaf
> node info from the rcvd Label-mapping msg. This needs to be clarified.
> 
> Considering above points, the better solution is to use LDP 
> Notification with MP Status — I.e. extend/use "MP Status" 
> notification to convey leaf join/leave. [ Note : a MP Status 
> Notification msg contains both the FEC and the Status code ]. If you
> agree with the use of LDP MP Status, then you should define 
> new/separate LDP capability for this extension.
[Lizhong] in the 01 version, we use notification to do the discovery. By 
using notification, when root node receive the notification message, it is 
possible that the root node does not have corresponding FEC information 
(T-LDP session message is faster than direct session message), then the 
notification message would be discard. That's why we change the discovery 
by sending label mapping message. I am considering to define a new type of 
FEC to do leaf discovery, in that case, the problem you raised above would 
be resolved, and also avoid the problem of notification message.

> 
> 7- Leaf address:
>    Refer to section 4.2.1, the "leaf node" information carried in 
> BGP is "Leaf node address". Couple of comments:
>     Ii) This document is hardcoding address to an IP type, which is 
> not correct. If mLDP root address is generic enough, why define
>         mLDP leaf address as "IP" specific. You should define the 
> leaf address in the same way as root address — I.e.
>        [ Address Family, Address ] where Address and its length is 
> dictated by the Addr-Family. Please note that your existing 
> definition will NOT work for other address families – e.g. For "MT 
> mLDP" (draft-iwijnand-mpls-mldp-multi-topology-02), the address is 
> in the scope of a given topology.
[Lizhong] OK, will change to AF accordingly in next version.

>   i) The document T-LDP section indicate use of MP FEC in LDP 
> message for leaf discovery, but does not indicate Typed WC MP FEC.
>   IMO, this is very important functionality it will be useful to use
> Typed WC MP FEC for "withdrawing" ALL the previous join by the leaf 
> towards a root. 
> 
>    ii) If you refine LDP label procedures and decide to continue 
> using label msgs (and not Notification messages), then a root can 
> also send Typed Wildcard MP FEC Label-Request message to all 
> potential leafs to learn/re-learn leafs for MP FECs as leaf respond 
> to Label-Request. This will
[Lizhong] right, will add WC MP FEC. Thanks.

> 
> 9- Minor comments:
> 
> - section 2 para 2: it can be rephrased - all it is trying to say is
> that an existing MP LSP can be shared amongst 
[Lizhong] will make this more clear.

> 
> - Terminology: need to fix some incorrect use of terminology - e,g, 
> T-LDP is defined as "Target LDP" instead of "Targeted LDP". 
> Moreover, the definition of "MP2MP FEC" is not accurate/precise enough.
[Lizhong] will fix the two terminology.

> 
> Regards,
> -- Kamran
> 
> From: Ross Callon <[email-masked]>
> To: "[email-masked]" <[email-masked]>, 
> "Syed Kamran Raza (skraza)" <[email-masked]>, Vero Zheng <vero.
> [email-masked]>
> Cc: Loa Andersson <[email-masked]>, "George Swallow (swallow)" 
<[email-masked]
> >, Martin Vigoureux <[email-masked]>, Ross Callon <
> [email-masked]>, "[email-masked]" <[email-masked]>, 
"
> [email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>