Re: [mpls] [Last-Call] Last Call: <draft-ietf-mpls-spl-terminology-03.txt> (Special Purpose Label terminology) to Informational RFC

Stewart Bryant <stewart.bryant@gmail.com> Tue, 25 August 2020 07:09 UTC

Return-Path: <stewart.bryant@gmail.com>
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 4B8B23A0B30; Tue, 25 Aug 2020 00:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.001
X-Spam-Level: *
X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, THIS_AD=1.199, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Dhw-eeUAVXLP; Tue, 25 Aug 2020 00:09:51 -0700 (PDT)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F723A0B2F; Tue, 25 Aug 2020 00:09:50 -0700 (PDT)
Received: by mail-wr1-x435.google.com with SMTP id a5so11591304wrm.6; Tue, 25 Aug 2020 00:09:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=mxHRwu6BvwogNzaLNaKr+gkN2TyuYEqTJj/9xVvJvzg=; b=LI95dpRMKfH6XECsgzh/J7/Ip2LhGm/gd5U00sxy6Jmfp9X2WuErMKxQstP6DuaBNJ mU77UjS6+0ATkK7BlPj2ZJ262DhEq2q7YxAnuGSdxA2ApWOrYyBY/pLd+YZQ26JGLp+M 1+2oXLwbJsTKqeWuBrJg2tnFyNU9ydfP6spvIUIc8AmuuDyKEMGNUqwaRjjU+QVZC5qo 0Q0b4trkJ/Hlyzh8rxYx5qw+I6bhGOy8WOOUmZqYcf9OVs7N0cNm5R9Q/4A7rBP/Vbni GbunR6lI32pA1ZmQVIuMOo5367hlpD9Rdd8+N2FDdSs7vn4HjYw/iPbN0nPCI3RsygHN Pn+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=mxHRwu6BvwogNzaLNaKr+gkN2TyuYEqTJj/9xVvJvzg=; b=PFIGd1GmDckzR9pM8og8+oO2K3qGRzcv+f0fOisj5rpU8MEHYwfMlxd7PRaV+BPZ3Y fAMgl2hzitogQzQ8UUkRMcL2EQF++1U8hY6/GJdCBBxmYVwsTw1hG7SK9O/xLL/iWQuo bxYHQlvcAuk0bVzOn6LLC8mJpEgo2h7U3TWonmq1icBWUJWRG2gEGRtYZtKxXvj4fc6h zDoaf8WOl5Rz+hsKOiYFwTmZ6LrV44567rsgIoBS5tCqOgIwItJt7Fysro2nGeyP8W1s LBdCt3qUjOTk0wB8ldBub3YVuh5cvLRXshRtbnnXOHL/g/SdtGgLp57yDglW5KmyvTIC FUPw==
X-Gm-Message-State: AOAM533uvgFfqNejvfzMve4lGVmPiWNiSdxFBmDESmXrJEgFEh6AVsND /6mgEyqpT86wh1kz35RE0Lg=
X-Google-Smtp-Source: ABdhPJw4pDDJhTKM8A31loCUi2ISZWvzILd9nnbsu/btuWbqVRzJHaaC9wzgqMDzNnjZd6s1WQ1owA==
X-Received: by 2002:adf:9561:: with SMTP id 88mr8935037wrs.240.1598339388824; Tue, 25 Aug 2020 00:09:48 -0700 (PDT)
Received: from [192.168.178.27] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id x133sm3974223wmg.39.2020.08.25.00.09.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Aug 2020 00:09:48 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <b52b31af-e0a6-3990-a33c-e2c819f63f93@pi.nu>
Date: Tue, 25 Aug 2020 08:09:45 +0100
Cc: Kireeti Kompella <kireeti=40juniper.net@dmarc.ietf.org>, tom petch <daedulus@btconnect.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "last-call@ietf.org" <last-call@ietf.org>, Kireeti Kompella <kireeti@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-spl-terminology@ietf.org" <draft-ietf-mpls-spl-terminology@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
Message-Id: <3AA1D563-9D16-4A0B-9AF5-D4BA2B55C40A@gmail.com>
References: <b52b31af-e0a6-3990-a33c-e2c819f63f93@pi.nu>
To: Loa Andersson <loa@pi.nu>
X-Mailer: iPad Mail (17G80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/q94w6anlfrLX2aUKe5_sVOi9P1g>
Subject: Re: [mpls] [Last-Call] Last Call: <draft-ietf-mpls-spl-terminology-03.txt> (Special Purpose Label terminology) to Informational RFC
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: Tue, 25 Aug 2020 07:09:53 -0000

Loa

Given history I don’t think “never to be assigned” is strong enough, they need to be “never to be used”, else someone is going to treat them as first come first served, and then squat on them, and then make them a de-facto standards allocated value.

Stewart

Sent from my iPad

> On 25 Aug 2020, at 06:14, Loa Andersson <loa@pi.nu> wrote:
> 
> WG, co-authors, Deborah
> 
> I think I made a mistake when using "range" as I did in the text.
> 
> We are in IANA rerritory and we need to use the words as IANA uses
> them.
> 
> A range is everything we lay claim to, so we say that we have this many
> code points and then we apply registration procedures to them.
> 
> For the bSPLs this is simple the range is 0-15, and there is only one registration procedure - "Standard Action".
> 
> For the eSPLs it is a bit more complicated, but I contribute to the complexity in the way I used "range".
> 
> The range for the eSPL is 0-1048575 (20 bits).
> 
> The regostration procedures are:
> 
> 0-15 Reserved (note never to be assigned).
> 16-239 Standard action
>   (code point 16 and 15 are assigned)
> 240-255 Experimental Use (note: Reserved not to be assigned)
> 256-1048575 Reserved (Note: To be made available for allocation only by
>                      a standards tarack RFC).
> 
> Modulo an agreement on this AD, co-authors, commentors) I think it is
> possible to clean up the draft and post a new version.
> 
> Deborah should I d that?
> 
> 
> /Loa
> 
>> On 25/08/2020 01:28, Kireeti Kompella wrote:
>> 
>> Thanks, Tom, for your feedback.
>> The two ranges (0-15, 16-1048575) have the unfortunate property of being contiguous and thus appearing related, but they are completely unrelated: one is for solo labels, the other is for the second label of a composite special purpose label.  This unintended confluence may be aggravated by referring to the ranges are "lower" and "upper".  I would get rid of these terms as follows:
>> NEW
>>      o  Collectively, the two (unrelated) ranges (0-15 and 16-1048575) are
>>           known as Special Purpose Labels (SPL).
>>      o  Special purpose labels from the range 0-15 are
>>          called Base Special Purpose Labels (bSPL).
>>      o  Special purpose labels from the range 16-1048575
>>           are called Extended Special Purpose Labels (eSPL).  The
>>           reserved values 0-15 from the 'Extended Special-Purpose MPLS
>>           Label Values' registry do not need a name as they are not available
>>           for allocation.
>> END
>> (change of tense, as readers of the RFC will be seeing a fait accompli.)
>> Kireeti.
>> On 8/24/20, 03:02, "tom petch" <daedulus@btconnect.com> wrote:
>>     [External Email. Be cautious of content]
>>     On 23/08/2020 21:47, Adrian Farrel wrote:
>>     > Hi Tom,
>>     >
>>     > You're right (a condition that must be scarily familiar for you).
>>     >
>>     > Probably...
>>     >
>>     > OLD
>>     >     o  Collectively, the two ranges are known as Special Purpose Labels
>>     >        (SPL).
>>     >
>>     >     o  The special purpose labels from the lower range will be called
>>     >        Base Special Purpose Labels (bSPL).
>>     >
>>     >     o  The special purpose labels from the higher range will be called
>>     >        Extended Special Purpose Labels (eSPL).
>>     > NEW
>>     >     o  Collectively, the two ranges (0-15, and 16-1048575) are known
>>     >         as Special Purpose Labels (SPL).
>>     >
>>     >     o  The special purpose labels from the lower range (0-15) will be
>>     >         called Base Special Purpose Labels (bSPL).
>>     >
>>     >     o  The special purpose labels from the higher range (16-1048575)
>>     >          will be called Extended Special Purpose Labels (eSPL).  The
>>     >          reserved values 0-15 from the 'Extended Special-Purpose MPLS
>>     >          Label Values' registry do not need a name as they can never be
>>     >          used.
>>     > END
>>     Yes, clearer.
>>     Perhaps
>>     "       The
>>          reserved values 0-15 from the 'Extended Special-Purpose MPLS
>>          Label Values' registry do not need a name as they are not available
>>     for allocation. "
>>     to tie in with the wording of IANA.  They SHOULD NOT or MUST NOT be used
>>     but I can see some independent-minded organisation deciding that because
>>     noone else will ever use them then they can and they will so I think
>>     'can never be used' is not quite right.  They can never be allocated so
>>     we do not need an identifier for them, which is what I am wanting to
>>     express.
>>     I note that this is Informational and so RFC2119 language is best avoided.
>>     Tom Petch
>>     > Best,
>>     > Adrian
>>     >
>>     > -----Original Message-----
>>     > From: tom petch <daedulus@btconnect.com>
>>     > Sent: 19 August 2020 17:25
>>     > To: last-call@ietf.org
>>     > Cc: mpls@ietf.org; draft-ietf-mpls-spl-terminology@ietf.org; db3546@att.com;
>>     > mpls-chairs@ietf.org
>>     > Subject: Re: Last Call: <draft-ietf-mpls-spl-terminology-03.txt> (Special
>>     > Purpose Label terminology) to Informational RFC
>>     >
>>     > I find this confusing.
>>     >
>>     > It specifies two ranges 0-15 and 0-1048575 the latter being subdivided
>>     > into ranges 0-15 16-239 etc and then talks of the lower range and the
>>     > higher range; is the higher range 0-1048575 or 16-239 or 16-1048575 or ...?
>>     > Lesser and greater or first and second or smaller and larger .. I might
>>     > find unambiguous but reading this with an innocent eye, I find higher
>>     > ambiguous.
>>     >
>>     > And in Security, 'It does not effect the forwarding ...' Well, no, it
>>     > would likely not affect it either:-)
>>     >
>>     > Tom Petch
>>     >
>>     >
>>     >
>>     > On 12/08/2020 19:48, The IESG wrote:
>>     >>
>>     >> The IESG has received a request from the Multiprotocol Label Switching WG
>>     >> (mpls) to consider the following document: - 'Special Purpose Label
>>     >> terminology'
>>     >>     <draft-ietf-mpls-spl-terminology-03.txt> as Informational RFC
>>     >>
>> Juniper Business Use Only
> 
> -- 
> 
> Loa Andersson                        email: loa@pi.nu
> Senior MPLS Expert                          loa.pi.nu@gmail.com
> Bronze Dragon Consulting             phone: +46 739 81 21 64
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls