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

[Stewart Bryant <[e-mail]>]

On 10/11/2015 13:36, Daniele Ceccarelli wrote:
>
> Hi Stewart,
>
> Please find more comments in line.
>
> BR
> Daniele
>
> *From:*Stewart Bryant [mailto:[e-mail]]
> *Sent:* lunedì 9 novembre 2015 18:14
> *To:* Daniele Ceccarelli; [e-mail]
> *Cc:* [e-mail]; 
> [e-mail]; [e-mail]
> *Subject:* Re: [mpls] RtgDir review: 
> draft-ietf-mpls-rfc6374-udp-return-path-04.txt
>
> 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>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.
>
> [DC] Good point. I was not considering just the case of IPv4 vs IPv6 
> UROs (where “able” makes sense) but also cases where multiple IPv4 or 
> IPv6 could be present. If the sender asks for a reply both using IPv4 
> and IPv6 I pretty much expect that it’s fine to receive one of them, 
> but in case of multiple IPv4 or IPv6 requests I would expect to see an 
> error for the ones I don’t receive a reply to. But if the WG didn’t 
> feel the need for that I’m fine.
>
> For the IPv4 vs IPv6 case I suggest to explicitly use Adrian’s 
> interpretation in the text: “process them in order and use the first 
> one in the list that it is able to use.”
>
>  *
>   * 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.
>
> [DC] I’ve seen quite rarely the usage of the same Type value for 
> different meanings. If it was just a dice tossing and it has no impact 
> on existing implementations I’d suggesting using different values, 
> otherwise it’s ok to keep it as it is
>
The meanings is exactly same, the object  carries the response address 
detail.

Within the parameters there are two address types supported and one 
parameter tells you which type of address is carried.

This is conceptually no different to sub-TLVs which are a well known 
hierarchical structure.

I can change it if that is the wish of the WG, but I cannot see why the 
change is needed since there is no ambiguity.

>
>
>  *
>   * 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.
> [DC] if it’s defined in RFC6374 there is no need to repeat it here 
> IMO. My comments applies in any case to RFC6374…but it’s too late.
>
It seems to me that the emphasis is not harmful.

It was applied to RFC6374 so that the sender did not receive unsolicited 
response messages, which is a reasonable protocol construct. If another 
protocol wants to use the RFC6374 TLVs it can modify their semantics, 
although it would be better to define its own TLV set.

- Stewart

>
>  *
>
> *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] <mailto:[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


-- 
For corporate legal information go to:

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