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

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Tue, 10 November 2015 13:37 UTC

Return-Path: <daniele.ceccarelli@ericsson.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB801B37A4; Tue, 10 Nov 2015 05:37:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.2
X-Spam-Level:
X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOKhmAYiXCYo; Tue, 10 Nov 2015 05:36:57 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0591B37A1; Tue, 10 Nov 2015 05:36:55 -0800 (PST)
X-AuditID: c1b4fb25-f79a26d00000149a-66-5641f2f5f150
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AC.18.05274.5F2F1465; Tue, 10 Nov 2015 14:36:53 +0100 (CET)
Received: from ESESSMB301.ericsson.se ([169.254.1.238]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Tue, 10 Nov 2015 14:36:53 +0100
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: "stbryant@cisco.com" <stbryant@cisco.com>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-rfc6374-udp-return-path-04.txt
Thread-Index: AdEaUtd2K6cgJ/8lR9abU/b+Czm7rAAtr0CAACr5Y3A=
Date: Tue, 10 Nov 2015 13:36:52 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE4812ACB021@ESESSMB301.ericsson.se>
References: <4A1562797D64E44993C5CBF38CF1BE4812ACA49E@ESESSMB301.ericsson.se> <5640D43D.5090603@cisco.com>
In-Reply-To: <5640D43D.5090603@cisco.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.147]
Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE4812ACB021ESESSMB301erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM+Jvre7XT45hBl2TNC2uz2hitbi1dCWr xfM5M1ksFqx5ym5x7ukcRgdWjym/N7J6LFnyk8njy+XPbAHMUVw2Kak5mWWpRfp2CVwZrydZ FFxZyFTx+sdh1gbGjllMXYycHBICJhIv9lyEssUkLtxbz9bFyMUhJHCEUeLd5R1MEM4SRomm VVcZuxg5ONgErCSeHPIBMUUEkiR+PrAFKWEWOM0osX3ecXaQQcICwRJbfj1nBrFFBEIkTi8/ zA5RbyWx+CUPiMkioCrxZU4eSAWvgK/E9EcNYJ1CAjkSB37fBrM5BTQlFu+4ygpiMwrISkzY vYgRxGYWEJe49WQ+1MkCEkv2nGeGsEUlXj7+xwoyXkJASWLa1jSI8nyJxdd2M0OsEpQ4OfMJ ywRG0VlIJs1CUjYLSdksoEnMQFes36UPUaIoMaX7ITuErSHROmcuO7L4Akb2VYyixanFSbnp RsZ6qUWZycXF+Xl6eaklmxiBEXlwy2/VHYyX3zgeYhTgYFTi4f0w1TFMiDWxrLgy9xCjBAez kggv42ugEG9KYmVValF+fFFpTmrxIUZpDhYlcd5mpgehQgLpiSWp2ampBalFMFkmDk6pBkYx vdwUkZ/P83svO+xfXnvj8a3079zvddbmhbCt+BTodas2+sb1hHdmvHu81VcHWeSrrL5QErq1 ze9k4UWePJEz0YzpIgGnV65KupM1qTA977npi2Unvl96cEmytVBf/Oep0LTdhz17Dxnzm6w/ 7sOxWuDspaeli7vkbNz59X9EulhZ7PRcJKzEUpyRaKjFXFScCACZ/lMZxAIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/52b9E1fcnVnscovRXTegRt5HaH4>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-mpls-rfc6374-udp-return-path.all@tools.ietf.org" <draft-ietf-mpls-rfc6374-udp-return-path.all@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-rfc6374-udp-return-path-04.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2015 13:37:01 -0000

Hi Stewart,

Please find more comments in line.

BR
Daniele

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: lunedì 9 novembre 2015 18:14
To: Daniele Ceccarelli; rtg-ads@tools.ietf.org
Cc: rtg-dir@ietf.org; draft-ietf-mpls-rfc6374-udp-return-path.all@tools.ietf.org; mpls@ietf.org
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



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


  *

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

mpls@ietf.org<mailto:mpls@ietf.org>

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