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

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 9 Nov 2015 16:42:54 +0000

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.
  *   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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 9 Nov 2015 17:13:33 +0000

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.
>
> *Summary:*
> *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:*
>
> *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:*
>   * “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.
>  *
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
> [email-masked]
> 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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 10 Nov 2015 12:32:07 -0000

>> • 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.

Yes, I like this formulation which I interpret to mean: process them in order and use the first one in the list that it is able to use.

"Able" is perhaps suspect and subject to policy, but presumably the sender is happy for any URO in the list to be used, and all we are doing is expressing an ordered preference.
 
Adrian

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 10 Nov 2015 13:36:52 +0000

Hi Stewart,

Please find more comments in line.

BR
Daniele

From: Stewart Bryant [mailto:[email-masked]]
Sent: lunedì 9 novembre 2015 18:14
To: Daniele Ceccarelli; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-rfc6374-udp-return-path-04.txt

Daniele

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

Summary:

Comments:

Major Issues:

Minor Issues:

  *

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

  *
  *   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.

  *

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.

  *

Nits:

  *
  *   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

[email-masked]<mailto:[email-masked]>

--

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 10 Nov 2015 13:54:35 +0000

On 10/11/2015 13:36, Daniele Ceccarelli wrote:
> *From:*Stewart Bryant [mailto:[email-masked]]
> *Sent:* lunedì 9 novembre 2015 18:14
> *To:* Daniele Ceccarelli; [email-masked]
> *Cc:* [email-masked]; 
> [email-masked]; [email-masked]
> *Subject:* Re: [mpls] RtgDir review: 
> draft-ietf-mpls-rfc6374-udp-return-path-04.txt
>
> Daniele
>
>     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.
>
>     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:*
>
>         “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.
>
> 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.”
>
>  *
> 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.

> [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

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 10 Nov 2015 14:06:41 +0000

Hi Stewart,

As I said mine are just suggestions. If the WG is ok with keeping the text as it is I’m ok too.

BR
Daniele

Sent: martedì 10 novembre 2015 14:55

BR
Daniele

From: Stewart Bryant [mailto:[email-masked]]
Sent: lunedì 9 novembre 2015 18:14
To: Daniele Ceccarelli; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-rfc6374-udp-return-path-04.txt

Daniele

Hello,

Summary:

Comments:

Major Issues:

Minor Issues:

  *

  *
  *   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.

  *

  *

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:

  *

Thanks

Stewart

  *
BR
Daniele

mpls mailing list

--

--