Last Call Review of draft-ietf-mpls-rfc6374-udp-return-path-04
review-ietf-mpls-rfc6374-udp-return-path-04-opsdir-lc-vyncke-2016-01-04-00

Request Review of draft-ietf-mpls-rfc6374-udp-return-path
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-01-05
Requested 2015-12-04
Draft last updated 2016-01-04
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 Éric Vyncke
State Completed
Review review-ietf-mpls-rfc6374-udp-return-path-04-opsdir-lc-vyncke-2016-01-04
Reviewed rev. 04 (document currently at 05)
Review result Has Issues
Review completed: 2016-01-04

Review
review-ietf-mpls-rfc6374-udp-return-path-04-opsdir-lc-vyncke-2016-01-04




I have reviewed draft-ietf-mpls-rfc6374-udp-return-path as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the
 IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.














This is a standard track document of the MPLS WG and it the procedure to be used by the Packet Loss and Delay Measurement. A query can be sent over MPLS for measurement with a URO (UDP return object) forcing the reply to be sent over UDP (possibly outside of
 the MPLS domain). The URO can contain IPv4 or IPv4 addresses (good).
















This short I-D is quite clear and easy to understand, security & manageability sections are correct. I found nothing in this framework document which could cause operational issues EXCEPT:







as I am unsure of the usual PLDM procedures, what is the expected behavior when a PLDM message (incl a URO) is received by a PLDM node which does not support this object type? If it is well defined in PLDM, then there is no problem
 of course.

Can a reply be fragmented? Should the reply contains the DF bit for IPv4? Probably worth mentioning what to do over fragmentation.

What is the expected behavior when the URO contains an IPv6 address and the PLDM responder only has IPv4 address(es)?







Small nits:







in introduction, I guess you meant "

internally be forwarded" rather than "

internally
 forwarded"

Section 4.3, when selecting the source address, you may want to refer to RFC 6724





Hope this helps and (if it means something for you) Merry Christmas














-éric