IETF Logo Mail Archive

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

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Mon, 09 November 2015 16:43 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 A439B1B7F82; Mon, 9 Nov 2015 08:43:02 -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 pctEf_JcVBv5; Mon, 9 Nov 2015 08:43:00 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A54BC1B7F7D; Mon, 9 Nov 2015 08:42:57 -0800 (PST)
X-AuditID: c1b4fb2d-f79626d000004282-0a-5640cd0ff4ae
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 43.AD.17026.F0DC0465; Mon, 9 Nov 2015 17:42:55 +0100 (CET)
Received: from ESESSMB301.ericsson.se ([169.254.1.238]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Mon, 9 Nov 2015 17:42:55 +0100
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Thread-Topic: RtgDir review: draft-ietf-mpls-rfc6374-udp-return-path-04.txt
Thread-Index: AdEaUtd2K6cgJ/8lR9abU/b+Czm7rA==
Date: Mon, 09 Nov 2015 16:42:54 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE4812ACA49E@ESESSMB301.ericsson.se>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.146]
Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE4812ACA49EESESSMB301erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM+JvrS7/WYcwgyt/dC2uz2hitbi1dCWr xfM5M1ksFqx5yu7A4rFkyU8mjy+XP7MFMEVx2aSk5mSWpRbp2yVwZXya/I2loGsjU8WynWUN jD0rmboYOTkkBEwkdl0/wg5hi0lcuLeerYuRi0NI4AijxPltp1ghnMWMEjtfP2PsYuTgYBOw knhyyAekQUTAVKLv/wV2kBpmgZOMEv0XuphBEsICbhIrez4zQRR5S8xf9xbK1pM4veoQWA2L gIpE35xdjCA2r4CvxPbfP1lAbEYBWYkJuxeBxZkFxCVuPZkPdamAxJI955khbFGJl4//sULY ShI/NlxigajPl5i26DvUTEGJkzOfsExgFJ6FZNQsJGWzkJTNAnqNWUBTYv0ufYgSRYkp3Q/Z IWwNidY5c9mRxRcwsq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECIyqg1t+6+5gXP3a8RCj AAejEg/vh8v2YUKsiWXFlbmHGCU4mJVEeAt2OYQJ8aYkVlalFuXHF5XmpBYfYpTmYFES521h ehAqJJCeWJKanZpakFoEk2Xi4JRqYPQvyVuXNmlFs9kVx4MGj+1O3pA/8/Be+m9rt4ipK3QZ fJo5lJ/63Y2ykbFaYdz1K89LkX+O/w2lpIJjjI1GC3Wd3J7HK3G8vKN40sjvnN577dAG84kJ Vx49r78moFbZKLTx7xabB9wp+09c+PxEOoq7sVwkx8ixkVdYX1lU8wTzhNuvdpd/U2Ipzkg0 1GIuKk4EAO2ljfamAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/aC8ppAaV77PvRv-bIV4odHRNPtE>
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: [RTG-DIR] 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: Mon, 09 Nov 2015 16:43:02 -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

v2.23.0 | Report a Bug | By Email