Skip to main content

Early Review of draft-ietf-teas-p2mp-loose-path-reopt-07

Request Review of draft-ietf-teas-p2mp-loose-path-reopt
Requested revision No specific revision (document currently at 09)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-11-28
Requested 2016-11-22
Authors Tarek Saad , Rakesh Gandhi , Zafar Ali , Robert H. Venator , Yuji Kamite
I-D last updated 2016-11-28
Completed reviews Rtgdir Early review of -07 by Joel M. Halpern (diff)
Genart Last Call review of -08 by Dan Romascanu (diff)
Secdir Last Call review of -08 by Leif Johansson (diff)
Assignment Reviewer Joel M. Halpern
State Completed
Request Early review on draft-ietf-teas-p2mp-loose-path-reopt by Routing Area Directorate Assigned
Reviewed revision 07 (document currently at 09)
Result Has issues
Completed 2016-11-28

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, and 

sometimes on special request. The purpose of the review is to provide 

assistance to the Routing ADs. For more information about the Routing 

Directorate, please see 


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-teas-p2mp-loose-path-reopt-07.txt
Reviewer: Joel M. Halpern
Review Date: 23-November-2016
IETF LC End Date: N/A
Intended Status: Standards Track

Summary: I have some moderate concerns about this document that I think 

should be resolved before publication is approved.



    The use of SHOULD and MAY in section 4.1 seems to lead to a device 

which ostensibly supports this document, but does the wrong things.

    First, with regard to the SHOULDs, in the absence of any indication 

as to why it would not do this, it appears that the SHOULD is really 

"MUST if the device supports this document" which is what MUST in a 

document actually means.

    Section 4.2 first bullet says that a mid-point LSR "SHOULD" check 

for a preferable P2MP-TE LSP Tree.  But if it doesn't, it is not 

supporting this document.  As written, it could decide to ignore the 

message, even though it claims to support this RFC.

    Looking at the handling when a preferable P2MP-TE LSP tree is 

found, according to the document, the LSR MAY send the PathErr response. 

 My assumption is that if it does not send the PathErr, it MUST 

propagate the request.  If it does not do either one, the protocol does 

not function.  It seems likely that if this is really intended to be 

optional (MAY), the document would be improved my giving implementors 

some hint as to when it is desirable or undesirable to send the message.

    Then in the third bullet, it is only a SHOULD to pass on the 

request.  Thus, a device which supports this mechanism, but chooses not 

to pass on the request, is compliant to this document while preventing 

other devices from properly supporting the mechanism.


    The abstract is much too long.  Much of the content of the abstract 

belongs in the introduction.  Even teh second paragraph has too much 

detail for an abstract.


    In the last paragraph of the introduction, it says that this 

document "proposes" solutions.  Given we are now in the position of 

evaluating publication as a Proposed Standard, I would say that this 

document "defines" solutions.