Skip to main content

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 revision No specific revision (document currently at 05)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-01-15
Requested 2015-10-27
Authors Stewart Bryant , Siva Sivabalan , Sagar Soni
I-D 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 L. 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
Request Early review on draft-ietf-mpls-rfc6374-udp-return-path by Routing Area Directorate Assigned
Reviewed revision 04 (document currently at 05)
Result Has issues
Completed 2016-01-15
review-ietf-mpls-rfc6374-udp-return-path-04-rtgdir-early-ceccarelli-2016-01-15-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-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