Early Review of draft-ietf-mpls-rfc6374-udp-return-path-04
review-ietf-mpls-rfc6374-udp-return-path-04-rtgdir-early-ceccarelli-2016-01-15-00

Request Review of draft-ietf-mpls-rfc6374-udp-return-path
Requested rev. no specific revision (document currently at 05)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-01-15
Requested 2015-10-27
Draft last updated 2016-01-15
Completed reviews Genart Last Call review of -04 by Wassim Haddad (diff)
Secdir Last Call review of -04 by Sandra Murphy (diff)
Opsdir Last Call review of -04 by Éric Vyncke (diff)
Rtgdir Early review of -04 by Daniele Ceccarelli (diff)
Assignment Reviewer Daniele Ceccarelli
State Completed
Review review-ietf-mpls-rfc6374-udp-return-path-04-rtgdir-early-ceccarelli-2016-01-15
Reviewed rev. 04 (document currently at 05)
Review result Has Issues
Review completed: 2016-01-15

Review
review-ietf-mpls-rfc6374-udp-return-path-04-rtgdir-early-ceccarelli-2016-01-15






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-rfc6374-udp-return-path-04

.txt

 


Reviewer: Daniele Ceccarelli


Review Date: Nov 08 2015


IETF LC End Date: draft in AD evaluation state

 


Intended Status: Standard Track







Summary:

 




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




Comments:




The draft is pretty simple and straightforward, it is almost ready for publication. I appreciated the “note to reviewers” at the beginning of section 3.1, good idea.




Major Issues:





If you find no major issues, please write: "No major issues found.







Minor Issues:








Abstract: please consider improving readability. Suggestion: “RFC6374 defines a protocol for Packet Loss and Delay Measurement for MPLS networks (MPLS-PLDM). This document specifies the procedures to be used when sending and processing out-of-band MPLS performance
 management responses over an IP/UDP return path.


Section 3: My understanding is that if multiple URO are sent but the responder is configured to send a single reply, it replies to the first URO. Is any error message foreseen for this?


Why a single URO TLV Type is used for both IPv4 and IPv6? Wouldn’t it be clearer to use two different values?


I don’t think the “SHOULD” in section 4.2 (“The receipt of such a mal-formed request SHOULD be notified to the operator through the management system…”)  should be in capital letters, since it’s not defining a rule for the protocol. Same applies to section
 4.4.


Section 4.3. Why there is this strict requirement? “It MUST NOT be sent other than in response to an MPLS-PLDM query message.” If one day another type of query message is defined why do we want to impose that a MPLS-PM response MUST NOT be sent?




Nits:








Packet Loss and Delay Measurement are sometimes used with capital letters and sometimes not.


“In such systems the response may arrive via any interface in the LSR and need to internally forwarded…” I guess a verb is missing.


Some spelling mistakes are present in the document (e.g. Section 3, Section 4.1)




BR


Daniele