Re: [mpls] RtgDir review: draft-ietf-mpls-targeted-mldp-03.txt

[Lizhong Jin <[e-mail]>]

Hi Eric,
I am OK with all your reply and clarification.

Thanks
Lizhong

On Thu, Sep 5, 2013 at 12:09 AM, Eric Rosen <[e-mail]> wrote:

> Thank you for taking a close look at this draft again.
>
[Lizhong] my pleasure to reivew again. :)

>
> > 1. Section 1 is introduction, but section 1.2, 1.3, 1.4 seem to define
> the
> > specification, not overview introduction. It is suggest to have a
> separate
> > section to describe the introduction.
>
> Fair enough.  Sections 1.2, 1.3, and 1.4 will be "promoted" to sections 2,
> 3, and 4 respectively, leaving the old section 1.1 as the introduction.
>
[Lizhong] good.

>
> > 2. Section 1.1, the reference of mLDP RFC is indexed by [mLDP], not
> > [RFC6388] (same for [LDP-UP]). I am not quite sure IETF template allows
> > this, please check
>
> This style of cross-reference is very commonly used.
>
[Lizhong] I am OK now.

>
> > 3. Section 1.2.1, line 176, what if there is IGP neighbors, and there is
> > targeted LDP session between U and D? This is possible in some
> > deployments.
>
> The cited text:
>
>      - U is the "BGP next hop" on D's path to R, where U and D are not
>        IGP neighbors, and where there is a Targeted LDP session between
>        U and D.  In this case, we allow D to select U as the "upstream
>        LSR" for <R,X>.
>
> suggests that the targeted session cannot be used in this case.  Probably
> it
> is best to leave the handling of this case as a choice for the SP, so I
> will
> change it to ""where U and D are not necessarily IGP neighbors".  This
> would
> allow the targeted session to be used if so chosen.
>
 [Lizhong] I am OK now.

>
> > 4. Section 1.2.1, line 188, is there a precedence among the different
> > methods, and the operator could define the precedence?
>
> I think it is best to just say (as it does) "the method is chosen by
> provisioning".  Whether it is possible for an operator to configure an
> ordered list of methods to try is a local matter (i.e., doesn't have to be
> specified in the RFC).
>
[Lizhong] OK now.

>
> > 5. Section 3, line 356, how does D know to send label request, not label
> > mapping message? Multicast or unicast from U to D is determined by U, and
> > D could not get this information automatically. Then is there any static
> > configuration required here?
>
> As stated in section 1.3 (section 3 in the next revision):
>
>    "the choice between unicast replication and multicast tunneling is
>    determined by provisioning, or by other methods that are outside the
>    scope of this specification.  It is presupposed that all nodes will have
>    a priori knowledge of whether to use unicast replication or to use
>    multicast tunneling.  If the latter, it is presupposed that all nodes
>    will have a priori knowledge of the type of multicast tunneling to use."
>
[Lizhong] OK, I missed this.

>
> > 6. Section 3, line 358, the label request messages mentioned in the text
> > should be upstream label request message. It is better to explicit to say
> > this.
>
> I'll add that D1 and D2 follow the procedures of Section 4 of [LDP-UP] when
> requesting U to assign the label.
>
[Lizhong] OK.

>
> > 7. Section 3, line 382, it is said: While it is possible to do this, it
> is
> > highly RECOMMENDED that MP2MP LSPs be tunneled through MP2MP LSPs. I do
> > not quite understand this statement. This specification does not describe
> > the mechanism of MP2MP LSPs being tunneled through MP2MP LSPs. From my
> > view, MP2MP LSPs over MP2MP LSPs is not easy, and should resolve the
> > upstream label uniqueness among different upstream nodes. It should be
> > caution to have this recommendations here.
>
> Perhaps it would be best just to say:
>
>      Procedures for tunneling MP2MP LSPs through P2MP or MP2MP LSPs are
>      outside the scope of this document.
>
> [Lizhong] Agree