Re: [mpls] RtgDir review: draft-ietf-mpls-rfc6374-udp-return-path-04.txt

[Stewart Bryant <[e-mail]>]

Daniele

Thank you for the review, please see inline.

On 09/11/2015 16:42, Daniele Ceccarelli 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
>
> 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.
>
OK, will take a close look at this text.
>
>  *
>
>
>   * 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?
>
Actually I wonder if this should be the first URO that it is able to 
respond to.

The case in point would be if it found an IPv4 and an IPv6 USO (in that 
order) but could only sent IPv6.

I was not planning an error response. One can imagine cases (IPv4 and 
IPv6 for example) when there might be both type of URO in every message 
particularly during protocol migration.

>  *
>
>
>   * Why a single URO TLV Type is used for both IPv4 and IPv6? Wouldn’t
>     it be clearer to use two different values?
>
Both method are good protocol design. We tossed a dice and came down in 
favour of conserving Optional TLV types.
>
>  *
>
>
>   * 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.
>
SHOULD is an instruction to the implementer, which I think is valid use 
of RFC2119 language.
>
>  *
>
>
>   * 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?
>
This is as defined in RFC6374.

If some other protocol needs a MPLS-PM response it will specify that for 
itself.

>  *
>
>
> *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.
>
Yes - thanks.
>
>  *
>
>
>   * Some spelling mistakes are present in the document (e.g. Section
>     3, Section 4.1)
>
I will try me best to get them, but despite my very best endeavors 
spelling has never been one of my major skills. I am sure my friends in  
the RFC Editor office will pick up with any I miss.

Thanks

Stewart
>
>  *
>
> BR
> Daniele
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html