1 Aug 08:03 2012
Re: MPLS-RT review of draft-jin-mpls-mldp-leaf-discovery
Lizhong Jin <lizhong.jin <at> zte.com.cn>
2012-08-01 06:03:58 GMT
2012-08-01 06:03:58 GMT
Sorry for the late reply. Thank you for the detail review, please see inline below.
"Kamran Raza (skraza)" <skraza <at> cisco.com> wrote 2012/07/25 02:56:49:
> 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?
> 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.
[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
> differences in these procedures.
[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'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 ?
[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.
> 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.
[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:
> 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.
[Lizhong] OK, will change to AF accordingly in next version.
> 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
[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
> different apps - which is currently not being done.
[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.
> -- Kamran
> From: Ross Callon <rcallon <at> juniper.net>
> Date: Thu, 12 Jul 2012 12:53:44 -0400
> To: "jeremy.whittaker <at> verizon.com" <jeremy.whittaker <at> verizon.com>,
> "Syed Kamran Raza (skraza)" <skraza <at> cisco.com>, Vero Zheng <vero.
> zheng <at> huawei.com>
> Cc: Loa Andersson <loa <at> pi.nu>, "George Swallow (swallow)" <swallow <at> cisco.com
> >, Martin Vigoureux <martin.vigoureux <at> alcatel-lucent.com>, Ross Callon <
> rcallon <at> juniper.net>, "lizhong.jin <at> zte.com.cn" <lizhong.jin <at> zte.com.cn>, "
> kebo.liu <at> nsn.com" <kebo.liu <at> nsn.com>, "sriganesh.kini <at> ericsson.com" <
> sriganesh.kini <at> ericsson.com>
> 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
> 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)
_______________________________________________ mpls mailing list mpls <at> ietf.org https://www.ietf.org/mailman/listinfo/mpls