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

 

​

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir







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-rfc4379bis-06


Reviewer: Daniele Ceccarelli

 


Review Date: 27/09/2016


IETF LC End Date: date-if-known

 


Intended Status: Standard Track




When I saw that the document was obsoleting 4 well known and widely deployed documents I was scared, but reading the shepherd write up it seems that the drafts got a wide consensus
 in the working group. 







Summary:

 




No issues found. This document is ready for publication.




Comments:




The document is well written and comprehensible, but I didn’t expect less from such a dream team of authors.




Major Issues:










"No major issues found."







Minor Issues:










Backward compatibility. I would expect to see a section with some backward compatibility issues. Probably since all the previously defined methods and extensions are deprecated no backward compatibility is expected? In any case it is worth
 mentioning it.




3.2.8.  FEC 128 Pseudowire - IPv4 (Deprecated) vs. 3.2.9.  FEC 128 Pseudowire - IPv4 (Current). I don’t understand this. Is there a deprecated version of the FEC 128 PW and a current one? Where is that deprecated? I don’t think there is the
 need to address both but just the current one. 




Nits:










I think this sentence can be removed from the Abstract “This document obsoletes RFCs 4379, 6424, 6829, and 7537.”




Introduction:  “An important consideration in this design is that MPLS echo requests follow the same data path that normal MPLS packets would traverse.” I guess this is mandated by other documents, please add a reference, otherwise this is
 a strong requirement that need to be specified with RFC2119 terminology.




Motivation: (ICMP echo request [RFC0792]. It’s nice to have all the references in 4 digits, but I guess the 0 is not needed at this time.




Section 2: “is a pure RSVP node and doe not run LDP” s/does/doe







BR


Daniele