1 Aug 2012 08:03
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
Hi Kamran,
Sorry for the late reply. Thank you for the detail review, please see inline below.
Regards
Lizhong
"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?
> 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.
[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
_______________________________________________ mpls mailing list mpls <at> ietf.org https://www.ietf.org/mailman/listinfo/mpls
RSS Feed