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

Adrian Farrel <adrian@olddog.co.uk> Wed, 08 April 2020 08:39 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4853A0D90; Wed, 8 Apr 2020 01:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.401
X-Spam-Level:
X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=1.496, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 kvYX3arKRoKO; Wed, 8 Apr 2020 01:39:27 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112EA3A0D8D; Wed, 8 Apr 2020 01:39:26 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0388dAEY031472; Wed, 8 Apr 2020 09:39:11 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D650922044; Wed, 8 Apr 2020 09:39:10 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id C01C022042; Wed, 8 Apr 2020 09:39:10 +0100 (BST)
Received: from LAPTOPK7AS653V (81-174-202-163.bbplus.pte-ag2.dyn.plus.net [81.174.202.163] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0388d941023524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Apr 2020 09:39:10 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Mach Chen' <mach.chen@huawei.com>, 'Loa Andersson' <loa@pi.nu>, 'tom petch' <ietfc@btconnect.com>, "'Carlos Pignataro (cpignata)'" <cpignata@cisco.com>
Cc: 'mpls' <mpls@ietf.org>, draft-ietf-mpls-lsp-ping-registries-update@ietf.org
References: <0f5701d60847$ed2a2230$c77e6690$@olddog.co.uk> <021fe116-b0f2-25f4-b9ee-55bce86d61f5@pi.nu> <10a901d608df$c4cee170$4e6ca450$@olddog.co.uk> <A0D1AB10-6554-4A41-819B-9948014E6070@cisco.com> <728d3f0d-62ae-6cab-d482-d2dec440a3f4@pi.nu> <DB7PR07MB5657D964AD1C0AC210DF26B5A0C70@DB7PR07MB5657.eurprd07.prod.outlook.com> <676fc25e-b8ef-4828-8926-798f1e95fb73@pi.nu> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE297A665DB@dggeml510-mbx.china.huawei.com>
In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE297A665DB@dggeml510-mbx.china.huawei.com>
Date: Wed, 08 Apr 2020 09:39:09 +0100
Organization: Old Dog Consulting
Message-ID: <013801d60d81$2c65a710$8530f530$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKcr0WFnzuYDG284s/4phPYxZiQQgESRqIqAnB7yG8BgUPASQL15WsyAoK85G4Bhm1nkQLvJPrkpmoQ6TA=
Content-Language: en-gb
X-Originating-IP: 81.174.202.163
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25342.005
X-TM-AS-Result: No--30.639-10.0-31-10
X-imss-scan-details: No--30.639-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25342.005
X-TMASE-Result: 10--30.638500-10.000000
X-TMASE-MatchedRID: jFqw+1pFnMyWfDtBOz4q2x3Pziq4eLUfaMmm586o4gBYbPLopoBzQni1 9VmdeeTem+1fvYNhFyD9AoOUQOta/PC0efWAZXQdsgYw1+LBrk3FdEMoTK7bMd8WP1mLO29nvxu DJtfrlPWc4qYc1YSZbsEyRpjUonqUyTBgz6hl0dfM1jffIgQXhmQ+XtZQTuevR64C5ZrYJjTQp9 a0Z2eTbzVWRDKntSn9AXTviZ9V7WxBxk0KgEGnj/SG/+sPtZVkmIFNJhYZX2mvloAnGr4qhj4uP a5jZl9fV1y565SU0f0aAF0i3lwvcEkkO4zqprNOsTzXVHVB9Vo7GNv1BBu35FrXKFPCbXO5I3wS 2gWbZPRk2CMEGjTbR+LOYro10Zfk9ckR9dcPDoKaVoAi2I40/Uo/zHsuyNeLVI7KaIl9NhcXO0x PUrlObK/Xj/YbVtlfZWHShf8nCai45PqOLILUbdnDq+aDZjGZvAE5MUW6MmYnXBZmkoVhST2j/N 8mMgrkHRnuEIP5CIWLf/GJMA9X1tGhojt61Qb9TvKpZzlxUs8yta2MhCFQMbyAGK8mhnBmrZLAi MblSREHgKjg9Uo0qdLSdCKQ0vWo33y2DTfklpAvLP1C8DIeOi04j1lb8rc6FujNgNeS9UA/NuC2 gjWQuEkb7irTNEm1Coy5+GT40BW3YufuUZTu3Vlh7YbN9aMb6KPiBX2tI0iDy8d72OLzYpfCtVQ +mUkvN70XSPzqUc6zBhN7glbDhuSGx3PJaLF1uoibJpHRrFlaEfFgComdj1cn81OBopCmOmlcpc oxwYr3rXDqWtE33etCCat9VMiOpXG/54IfcneeAiCmPx4NwLTrdaH1ZWqC1n4UsocU0g4c4WL5J jd88P306Q4zhC4D3QfwsVk0Ubv+efAnnZBiLyF6bSSak9kx
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/eU_CHP-xqxODU_kb0rzDYEdtTj8>
Subject: Re: [mpls] Review of draft-ietf-mpls-lsp-ping-registries-update-01
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Apr 2020 08:39:30 -0000

Hi Mach,

I thought the whole reason we had this document was because what we have had
for so many years is wrong.

If the argument is that "we have been doing it for a long time and it hasn't
caused any problems" then let's abandon this draft and spend our time more
profitably!

However, I believe that Loa makes a good argument that the draft is needed,
and we should take that opportunity to work out what we really want.

Now, a very strong argument from anyone would be "we're already using code
points from this part of the registry, please don't mess with it".

Best,
Adrian

-----Original Message-----
From: Mach Chen <mach.chen@huawei.com>
Sent: 08 April 2020 03:10
To: Loa Andersson <loa@pi.nu>; tom petch <ietfc@btconnect.com>; Carlos
Pignataro (cpignata) <cpignata@cisco.com>; Adrian Farrel
<adrian@olddog.co.uk>
Cc: mpls <mpls@ietf.org>;
draft-ietf-mpls-lsp-ping-registries-update@ietf.org
Subject: RE: [mpls] Review of draft-ietf-mpls-lsp-ping-registries-update-01

Hi all,

Although I think the probability of using "Private Use" is low, I incline to
agree with Tom here. It's safer to keep both the "Private Use" and
"Experimental Use". And since we have been along with them for so many
years, seems it's no harm to keep keeping them.

Regards,
Mach

> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.nu]
> Sent: Monday, April 6, 2020 1:15 PM
> To: tom petch <ietfc@btconnect.com>; Carlos Pignataro (cpignata)
> <cpignata@cisco.com>; Adrian Farrel <adrian@olddog.co.uk>
> Cc: mpls <mpls@ietf.org>; draft-ietf-mpls-lsp-ping-registries-update@ietf.
org
> Subject: Re: [mpls] Review of
draft-ietf-mpls-lsp-ping-registries-update-01
>
> Tom,
>
> Interesting, looks like we need to continue the discussion on this for a
while.
>
> Working group,
>
> Please respond to this question:
>
> For the LSP Ping registries do we need both the "Experimental Use" and
> "Private Use" allocation policies? If we do not need both, which can be
> dropped?
>
> /Loa
>
> PS
>
> I have had a DOS attack against my mail server, it took us three days to
fix
> everything.
>
> On 04/04/2020 00:00, tom petch wrote:
> >
> > From: mpls <mpls-bounces@ietf.org> on behalf of Loa Andersson
> > <loa@pi.nu>
> > Sent: 03 April 2020 07:23
> >
> > Carlos and Adrian,
> >
> > So for the current draft I'll use "Experimental Use" and remove
> > "Private Use", my rationale for that is that I get questions about
> > "Experimental Use", but so far has had no question of "Private Use".
> >
> > Working Group,
> >
> > Please comment on this, either support or objections.
> >
> > <tp>
> >
> > I think that you should keep both since they have different uses.
> Experimental is for us, the IETF, if we cannot quite make up our minds how
to
> proceed yet.
> > Private use is for an organisation or group thereof to go their own way
and
> fork from the work of the IETF.  This is not desirable but history shows
that
> it happens and I think that MPLS OAM is an area where the chances of this
> are higher than with some IETF protocols.
> > If there is no private use, then such an organisation will camp on the
> Experimental which generates a problem for deployed code.
> >
> > TP
> >
> > /Loa
> > for the co-authors
> >
> > On 03/04/2020 02:38, Carlos Pignataro (cpignata) wrote:
> >>
> >>
> >>> 2020/04/02 午前7:13、Adrian Farrel <adrian@olddog.co.uk>のメール:
> >>>
> >>> 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.
> >>>
> >>
> >> +1
> >>
> >> Thanks,
> >>
> >> Carlos.
> >>
> >>> Best,
> >>> Adrian
> >>>
> >>> -----Original Message-----
> >>> From: Loa Andersson <loa@pi.nu>
> >>> Sent: 02 April 2020 11:31
> >>> To: adrian@olddog.co.uk;
> >>> draft-ietf-mpls-lsp-ping-registries-update@ietf.org
> >>> Cc: mpls@ietf.org
> >>> Subject: Re: Review of draft-ietf-mpls-lsp-ping-registries-update-01
> >>>
> >>> Adrian,
> >>>
> >>> 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,
> >>>>
> >>> <snip>
> >>>>
> >>>> 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.
> >>> <snip>
> >>>
> >>> 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).
> >>>
> >>>      Examples:
> >>>
> >>>         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.
> >>>
> >>>      Example:
> >>>
> >>>         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
> >>>
> >>> --
> >>>
> >>>
> >>> Loa Andersson                        email: loa@pi.nu
> >>> Senior MPLS Expert
> >>> Bronze Dragon Consulting             phone: +46 739 81 21 64
> >>>
> >>
> >
> > --
> >
> >
> > Loa Andersson                        email: loa@pi.nu
> > Senior MPLS Expert
> > Bronze Dragon Consulting             phone: +46 739 81 21 64
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
> >
>
> --
>
>
> Loa Andersson                        email: loa@pi.nu
> Senior MPLS Expert
> Bronze Dragon Consulting             phone: +46 739 81 21 64