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

Adrian Farrel <> Thu, 02 April 2020 11:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 154703A07A9; Thu, 2 Apr 2020 04:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HHx_axt_0HEK; Thu, 2 Apr 2020 04:13:45 -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 1AD503A07A8; Thu, 2 Apr 2020 04:13:44 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 032BDgho004034; Thu, 2 Apr 2020 12:13:43 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 07C7C22048; Thu, 2 Apr 2020 12:13:43 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS id E698B22042; Thu, 2 Apr 2020 12:13:42 +0100 (BST)
Received: from LAPTOPK7AS653V ( [] (may be forged)) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 032BDgYR027161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Apr 2020 12:13:42 +0100
From: Adrian Farrel <>
To: 'Loa Andersson' <>,
References: <0f5701d60847$ed2a2230$c77e6690$> <>
In-Reply-To: <>
Date: Thu, 02 Apr 2020 12:13:41 +0100
Organization: Old Dog Consulting
Message-ID: <10a901d608df$c4cee170$4e6ca450$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQKcr0WFnzuYDG284s/4phPYxZiQQgESRqIqps/JTsA=
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--15.645-10.0-31-10
X-imss-scan-details: No--15.645-10.0-31-10
X-TMASE-Result: 10--15.644600-10.000000
X-TMASE-MatchedRID: hwsFDxVJcFmWfDtBOz4q2x3Pziq4eLUfaMmm586o4gBIXJo+eGm+FAre VeerV2qKi4HCqJY4pUa3U0269csg/O0CIVu0YpXSwtE16arXsSLdYVrFVbszaEyQ8hzF3nP2aXK zU8OFYuiNgmgyorf0T5WQV3iH3T+1mLp3zXC6jJTM1jffIgQXhvj4HFxuihXOBthzL1hCXp6E61 qMpT+jzA3D4NiLZlKuEvsg7x5dWvGtXYcEiVVUtIVMtEwAWsdcghehpAfYfg/k1kyQDpEj8AVM9 kPsaYx4nWjOP8n4VbVJELCZ+5bO3YMekhDD0e6G5Qo03mEdwAE0bM+gM8H/Ujx1n5z4DXMbW+ye tiFwGj4K0WPheEy1y81E1edvPwf6r3XE8Kt+l0LBjbyj5wYDmloR8WAKiZ2PVyfzU4GikKY6aVy lyjHBivetcOpa0Tfd60IJq31UyI6lcb/ngh9yd0hcTAvIrlKoS6mvV++TKmnbFQP2NkupsUBxOS 7OACFOTbuNMXZ5zJe98ECOwq5d2o+5h51Qor3GqjZ865FPtppdA4rYaKGKwu9FCyScBaYaBVBci h8ELjGeHhZZWe6wcF26LUCaK45JiAzEt7NPEk7TK3Menen4lgoXSOLC5a44e3wXTvBMUi7shjyc wIJEY/8mF3XRav/QGbIOO2VgHLVD3HUItz7G2m/GhVZSEqbiTsTCHtXv0PpE6qvV2uOcubdueLI /v15VSG97mLK1i6XNzZ8oS3Hjq6+/EguYor8cgxsfzkNRlfIrN8z0HohG3voLR4+zsDTthUfR2r vBju4D/dHyT/Xh7Q==
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: Thu, 02 Apr 2020 11:13:47 -0000

Thanks Loa,

I agree with your interpretation of 8126.

I think that the challenge with "experiments on the open Internet" is that the experiments have to have built into them some way to protect against two experiments using the same codepoint. That's not usually done in my experience, meaning that the two allocation classes are often pretty similar. Maybe there is some difference in duration of the use of a code point.

I'd certainly be happy with collapsing these registries to use just one range. I would say that keeping the resulting range small (just a few code points) is desirable.


-----Original Message-----
From: Loa Andersson <> 
Sent: 02 April 2020 11:31
Subject: Re: Review of draft-ietf-mpls-lsp-ping-registries-update-01


This is to address your comment on "Private Use" and "Experimental Use",
we will review the rest of the comments and update as needed.

On 02/04/2020 01:06, Adrian Farrel wrote:
> Hi all,
> I have a number of small editorials and some larger questions and issues
> set out below. I also have one question that has broader scope:
> For [IANA-MT] and [IANA-Sub-6] you now have both 'Private Use' and
> 'Experimental Use'. I struggle to see how this makes sense. The uses
> decribed in RFC 8126 are sufficiently similar that it is unusual to
> have both categories defined for a single registry. I don't see anything
> in the descriptive text in this document that makes clear why you need
> both categories and how an implementation would decide which range to
> select a code point from.

You are right I've been struggling with these two type of code points
also, but came to a slightly different conclusion than you did.

RFC 8126 says:

4.1.  Private Use

    Private Use is for private or local use only, with the type and
    purpose defined by the local site.  No attempt is made to prevent
    multiple sites from using the same value in different (and
    incompatible) ways.  IANA does not record assignments from registries
    or ranges with this policy (and therefore there is no need for IANA
    to review them) and assignments are not generally useful for broad
    interoperability.  It is the responsibility of the sites making use
    of the Private Use range to ensure that no conflicts occur (within
    the intended scope of use).


       Site-specific options in DHCP [RFC2939]
       Fibre Channel Port Type Registry [RFC4044]
       TLS ClientCertificateType Identifiers 224-255 [RFC5246]

4.2.  Experimental Use

    Experimental Use is similar to Private Use, but with the purpose
    being to facilitate experimentation.  See [RFC3692] for details.
    IANA does not record assignments from registries or ranges with this
    policy (and therefore there is no need for IANA to review them) and
    assignments are not generally useful for broad interoperability.
    Unless the registry explicitly allows it, it is not appropriate for
    documents to select explicit values from registries or ranges with
    this policy.  Specific experiments will select a value to use during
    the experiment.

    When code points are set aside for Experimental Use, it's important
    to make clear any expected restrictions on experimental scope.  For
    example, say whether it's acceptable to run experiments using those
    code points over the open Internet or whether such experiments should
    be confined to more closed environments.  See [RFC6994] for an
    example of such considerations.


       Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP
       Headers [RFC4727]

It seems to me that "Private Use" are intended for private networks,
where care is taken that the code points are not leaked into the
Internet, but there the network itself is a production network, that
will be run for an unforeseeable amount of time. And that "Experimental
Use" code points are for short lived experiments.

This is different.

I'm very uncertain whether it is sufficiently different to motivate two
different types. If the working group thinks there should be only one
code point, I would argue to keep the code points for "Experimental
Use". If we converge on "one type of code point only, I think this has
a wider impact than this document, and we should probably update RFC
8126 (again).

I'd like to invite comments on this on the mpls wg list.



Loa Andersson                        email:
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64