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

From: Lizhong Jin <[email-masked]>
Date: Tue, 3 Sep 2013 00:24:01 +0800

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review. The purpose of
the review is to provide assistance to the Routing ADs. For more
information about the Routing Directorate, please see
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.
Document: draft-ietf-mpls-targeted-mldp-03.txt
Reviewer: Lizhong Jin
Review Date: 2 September 2013
IETF LC End Date: 05 September 2013
Intended Status: Standards Track

o Summary:
I have some minor concerns about this document that I think should be
resolved before publication.

o Comments:
This document provides the specification for using the LDP P2MP/MP2MP
extensions over a Targeted LDP session. It is clearly written. I only have
some minor issues which need to be clarified.

o Major Issues:
No major issues found.

o Minor Issues:

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.
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.
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.
4. Section 1.2.1, line 188, is there a precedence among the different
methods, and the operator could define the precedence?
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?
 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.
 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.

Regards
Lizhong

---

From: Eric Rosen <[email-masked]>
Date: Wed, 04 Sep 2013 12:09:07 -0400

Thank you for taking a close look at this draft again.

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

> this, please check

This style of cross-reference is very commonly used.

> targeted LDP session between U and D? This is possible in some

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.

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

> 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

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

> should be upstream label request message. It is better to explicit to say
   
I'll add that D1 and D2 follow the procedures of Section 4 of [LDP-UP] when
requesting U to assign the label.

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