Re: [mpls] Review of draft-ietf-mpls-lsp-ping-registries-update-01

Adrian Farrel <> Fri, 17 April 2020 11:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 535B33A0916; Fri, 17 Apr 2020 04:06:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.422
X-Spam-Status: No, score=-0.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=1.496, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GAamR7D31o64; Fri, 17 Apr 2020 04:06:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 84A393A0913; Fri, 17 Apr 2020 04:06:19 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 03HB6GqJ027224; Fri, 17 Apr 2020 12:06:16 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id CC0FF22046; Fri, 17 Apr 2020 12:06:16 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS id B6D2122042; Fri, 17 Apr 2020 12:06:16 +0100 (BST)
Received: from LAPTOPK7AS653V ( [] (may be forged)) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 03HB6FB9018752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Apr 2020 12:06:16 +0100
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Loa Andersson'" <>, <>
Cc: <>
References: <0f5701d60847$ed2a2230$c77e6690$> <>
In-Reply-To: <>
Date: Fri, 17 Apr 2020 12:06:15 +0100
Organization: Old Dog Consulting
Message-ID: <043601d614a8$36d57b70$a4807250$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKcr0WFnzuYDG284s/4phPYxZiQQgKmG0DQptq4EQA=
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--16.463-10.0-31-10
X-imss-scan-details: No--16.463-10.0-31-10
X-TMASE-Result: 10--16.462900-10.000000
X-TMASE-MatchedRID: H0/uSqZo4D6WfDtBOz4q2x3Pziq4eLUfaMmm586o4gBIXJo+eGm+FNtu Lnl6rSi72ZioStL+28ons5CA/fyEcUWOm+gyGn4qhUy0TABax1wHgh3sKJBzP0vEK4FMJdoqO9Z u2UZqoB4GXVYxUsRe93btxm2jKR0WTkaqbB0m3sKCYB3gC22mf/fjx7YIT/BiM/fPG6YRJVG8M5 ZHiCfb4Nra12bj9Wo0gHVn5lM3XYR20R+WDMa+DEvTZT3Q86tjqb3/o5s+OcNGM2uNXRqsUsC3W ddby5q1LUxCQCxJptJ7asnh8w0AJUHGTQqAQaePMpVOsYwN78MRAd26BrSMwr0rWM4nIpJrtn2P 53ro+JOh8zamhwf7E3phkJQHW2b9J+JZYQfxoHy5UUv022NJAkYj0zDHPzJpkaEC8FJraL8NHIn SWVidKrRQnoUkx0n3krWwZLWRgfBbyxAy8+P9fFyuZHgmvm5oI+eq7xVYCezZHCPt2B5X5G6GZN BqGP6q986UAhNcrP61YBLoYZeOCMwbKYKwWdlU8pHTorDcPMqrXHPgDIHtLcuSXx71bvSLF6OZf e1LJUl/TryMvtdQ3J6UHTryHxNeGFmgT31DRsdbKUNQk650HX0tCKdnhB58GtkvK5L7RXGw7M6d yuYKg46HM5rqDwqtlExlQIQeRG0=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [mpls] Review of draft-ietf-mpls-lsp-ping-registries-update-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Apr 2020 11:06:22 -0000

Thanks Loa, the update is a considerable improvement and addresses many of my review comments. There will be a further pass needed to fix the Swenglish, but we can wait until we have addressed the remaining two big open issues.

> The suggested text for this is:
>    An implementation that does not understand or support a received
>    TLV or sub-TLV with Type greater than or equal to 32768 (i.e., with
>    the high-order bit equal to 1) SHOULD ignore and step over the TLV
>    or sub-TLV, however an implementation MAY send an echo response
>    with Return Code 2 ("One or more of the TLVs was not understood")
>    as it would have doen if the high order bit had been clear.
> The text should be added to section 4.1.

I see you have already done this.

> This needs to be discussed, the alternative would be to the
> SHOULD to a must.

I like the formulation you have, and I think that a change to "MUST" would be more difficult because it would need a survey of existing implementations to see whether anyone has deviated from the "SHOULD".

> Experimental and Private Use
> We also have an open discussion on the code point ranges for
> Experimental and Private Use.
> When the discussion matures a bit I will discuss with my co-chairs on
> a consensus call on Experimental and Private use.

I don't have much to add to this discussion having already stated my opinion. I don't want to just keep saying the same thing as that doesn't really advance the discussion.

I would like to hear from all of the co-authors as (presumably) they have an opinion about what the document currently contains.

Tom made his view very clear. I don't agree with his view about the principal usage of Experimental codepoints, but I do agree that he has identified a use case.
I think that the distinction of "use on the open Internet" is of limited value in choosing between Experimental and Private Use because in both cases precautions have to be taken to ensure that two distinct implementations don't clash when using a codepoint. Both ranges are safe when used in private networks, but if either is used on the open Internet then some coordination or other mechanism is needed to protect implementations. Often this is handled with a special coding (a signature) behind the codepoint if there is a perceived risk.

I would, of course, also like to know if anyone is using any of the Private Use ranges for anything?