Re: [mpls] RtgDir review: draft-ietf-mpls-rfc4379bis-06

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hello, Daniele,

Many thanks for your review! Please find my follow-ups inline.

Deborah,

-07 (just posted) addresses these comments.

On Sep 27, 2016, at 5:00 AM, Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>> wrote:


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

Thank you for the document summary above! :-)

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.

This is a good point. My take would be that as the deprecated elements are not part of the specification (they are moved down to a non-normative appendix for completeness), then as you say there is no backwards compatibility.

This document does not version++ the protocol.

One thing we should do is make more clear that Appendix A is non-normative for an implementation. I can add a sentence there, here’s one suggestion for the WG to consider:

  <section title="Deprecated TLVs and sub-TLVs (Non-normative)">
<t>
This appendix describes deprecated elements, which are non-normative for an implementation.
They are included in this document for historical and informational purposes.
</t>



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

Yes, this is coming from RFC 4379 because the originally defined FEC 128 without the Sender’s IP(v4) address, and was deprecated because it does not univocally identify the FEC — the “current” was then added, consequently. This document keeps the “deprecated” version’s title and IANA number, but moved the definition to an Appendix.


  *

Nits:

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

It’s necessary as per https://www.ietf.org/id-info/checklist.html#anchor6

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


A requirement does not need to come from a different (e.g., “Requirements”) document and I think that this document can include that design criteria up front, as long as it is clear and transparent, without finding a citation.

I am hesitant to artificially chase a citation that was not in RFC 4379. That said, if the WG wants we can find something and add it (like from 4377 maybe) — though I probably wouldn’t/

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

Whatever xml2rfc renders :-) The anchor in the bibxml includes the “0”. https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0792.xml


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

Fixed.

Thanks again!

— Carlos.


  *

BR
Daniele