Early Review of draft-ietf-mpls-rfc4379bis-06
review-ietf-mpls-rfc4379bis-06-rtgdir-early-ceccarelli-2016-10-12-00

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