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

From: tom petch <[email-masked]>
Date: Wed, 19 Aug 2020 17:24:30 +0100

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
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2020-08-26. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>     This document discusses and recommends a terminology that may be used
>     when MPLS Special Purpose Labels (SPL) are specified and documented.
>
>     This document updates RFC 7274 and RFC 3032.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-mpls-spl-terminology/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 23 Aug 2020 21:47:00 +0100

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

Best,
Adrian

-----Original Message-----
From: tom petch <[email-masked]> 
Sent: 19 August 2020 17:25
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: Last Call: <draft-ietf-mpls-spl-terminology-03.txt> (Special
Purpose Label terminology) to Informational RFC

I find this confusing.

Tom Petch

---

From: tom petch <[email-masked]>
Date: Mon, 24 Aug 2020 11:02:09 +0100

>          Label Values' registry do not need a name as they can never be

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

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 24 Aug 2020 17:28:20 +0000

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" <[email-masked]> wrote:

    [External Email. Be cautious of content]

    Yes, clearer.

    Perhaps
    "       The

    Tom Petch

    >>     <draft-ietf-mpls-spl-terminology-03.txt> as Informational RFC

Juniper Business Use Only

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 24 Aug 2020 18:43:49 +0100

> On 24 Aug 2020, at 11:02, tom petch <[email-masked]> wrote:
> 
>    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.
> 

There is no history in the Internet of anyone ever treating a "never to be used" value as an opportunity :) 

How about:

>    Label Values' registry do not need a name as they MUST NOT be used “

Alternatively:

>    Label Values’ registry are called the MUST NOT USE range range as they MUST NOT be used. "

- Stewart

---

From: Loa Andersson <[email-masked]>
Date: Tue, 25 Aug 2020 13:13:47 +0800

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

-- 

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

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 25 Aug 2020 08:09:45 +0100

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 <[email-masked]> wrote:
> 
> WG, co-authors, Deborah
> 
> 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".
> 
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 28 Aug 2020 09:24:00 +0100

First a procedurally point:

"This draft updates RFC7274"

RFC7274 is standards track, and so believe that this terminology draft also needs to be standards track.

Second technical matter:

In discussing this terminology draft there has been some confusion regarding the whether the construct XL/ELI/EL (or <15><7><xxx> as I have described it elsewhere in the thread) is permitted.
Re-reading RFC7274 there is text that seems to expressly forbids the construct XL/ELI/EL (or <15><7><xxx>).

The text 

"Values 0-15 of the "Extended Special-Purpose MPLS Label Values"
registry are set aside as reserved. "

Is quite clear that the whole of that range is reserved. 

In the IANA section it says:

   +---------------------+---------------------------------------------+
   | Range               | Allocation Policy                           |
   +---------------------+---------------------------------------------+
   | 0 - 15              | Reserved.  Never to be made available for   |
   |                     | allocation.                                 |

That text seem to imply never to be deliberately used.

The confusion arrises because of the text in RFC7274 that notes that legacy implementations might not notice that the construct XL/ELI/EL is present. It is perfectly reasonable to provide the exception for the legacy hardware, however the the text that does seems confusing. I would like to propose that we address this confusion by including a further update to RFC7274 in this terminology draft:

OLD
  Values 0-15 of the "Extended Special-Purpose MPLS Label Values"
  registry are set aside as reserved.  Furthermore, values 0-6 and 8-15
  MUST NOT appear in the data plane following an XL; an LSR processing
  a packet with an XL at the top of the label stack followed by a label
  with value 0-6 or 8-15 MUST drop the packet.

  Label 7 (when received) retains its meaning as Entropy Label
  Indicator (ELI) whether a regular special-purpose label or an ESPL;
  this is because of backwards compatibility with existing implemented
  and deployed code and hardware that looks for the ELI without
  verifying if the previous label is XL or not.  However, when an LSR
  inserts an entropy label, it MUST insert the ELI as a regular
  special-purpose label, not as an ESPL.
NEW
  Values 0-15 of the "Extended Special-Purpose MPLS Label Values"
  registry are set aside as reserved.  Furthermore, an implementation
  MUST NOT place a label with value 0-15 in the label stack immediately following
  an XL; an LSR processing a packet with an XL at the top of the label
  stack immediately followed by a label with value 0-15 MUST drop the packet.

  When inspecting a label stack to find an Entropy Label Indicator
  (ELI - label 7) a pre-existing implementation may fail to inspect the
  previous label, and so not notice that  it is an XL.  Such systems can
  continue to process the entropy information and forward the packet when the previous
  label is an XP without causing harm. However, the 
  packet will be dropped when the XL reaches the top of the stack at another LSR.
END

This text clearly demonstrates that legacy LSRs are not expected to police the  <15><7><xxx> construct and that nothing bad will happen of they do not.

Longer term, I think we might be better served by generating an explicit draft that defines the XL behaviour rather than mixing it in with text on deallocation policy and the naming of parts of the registry.

Best regards

Stewart

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 28 Aug 2020 10:58:15 +0100

I like Stewart's suggestion (no surprise, because he and I spent some time
discussing it).

I *think* that the text in 7274 was trying to protect pre-existing
implementations from the need to not process a label 7 that was found
'illegally' immediately after label 15. Two points apply:

1.	This should never arise because an implementation MUST NOT build
15,7
2.	It is not harmful to find and process the 7 wherever it is found

I believe that 7274 used some poorly chosen words (blame the authors:-) when
it said "MUST NOT appear in the data plane". The use of 2119 language needs
to be limited to specific implementations, not (as here) philosophical or
abstract concepts. 

Stewart's proposed change has several beneficial effects:

a.	Preserves the protection for pre-existing implementations
b.	Preserves the rules for building label stacks
c.	Is consistent with the IANA registry
d.	Does not need any fiddling with processing rules or the registry

There is a downside: the document clearly needs to be returned to the
working group to make this fix, tidy up the rest of the document, and
re-establish WG consensus.

Cheers,

Adrian

From: Stewart Bryant <[email-masked]> 
Sent: 28 August 2020 09:24
To: Adrian Farrel <[email-masked]>; tom petch <[email-masked]>;
Last Call <[email-masked]>; [email-masked];
mpls <[email-masked]>; mpls-chairs <[email-masked]>; BRUNGARD, DEBORAH
A <[email-masked]>
Cc: Stewart Bryant <[email-masked]>
Subject: Re: [Last-Call] Last Call: <draft-ietf-mpls-spl-terminology-03.txt>
(Special Purpose Label terminology) to Informational RFC

RFC7274 is standards track, and so believe that this terminology draft also
needs to be standards track.

Second technical matter:

In discussing this terminology draft there has been some confusion regarding
the whether the construct XL/ELI/EL (or <15><7><xxx> as I have described it
elsewhere in the thread) is permitted.

Re-reading RFC7274 there is text that seems to expressly forbids the
construct XL/ELI/EL (or <15><7><xxx>).

The text 

The confusion arrises because of the text in RFC7274 that notes that legacy
implementations might not notice that the construct XL/ELI/EL is present. It
is perfectly reasonable to provide the exception for the legacy hardware,
however the the text that does seems confusing. I would like to propose that
we address this confusion by including a further update to RFC7274 in this
terminology draft:

OLD

  MUST NOT place a label with value 0-15 in the label stack immediately
following
  stack immediately followed by a label with value 0-15 MUST drop the
packet.

  When inspecting a label stack to find an Entropy Label Indicator
  (ELI - label 7) a pre-existing implementation may fail to inspect the
  previous label, and so not notice that  it is an XL.  Such systems can
  continue to process the entropy information and forward the packet when
the previous
  label is an XP without causing harm. However, the 
  packet will be dropped when the XL reaches the top of the stack at another
LSR.
END

This text clearly demonstrates that legacy LSRs are not expected to police
the  <15><7><xxx> construct and that nothing bad will happen of they do not.

Longer term, I think we might be better served by generating an explicit
draft that defines the XL behaviour rather than mixing it in with text on
deallocation policy and the naming of parts of the registry.

Best regards

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 28 Aug 2020 12:07:31 +0100

> On 28 Aug 2020, at 10:58, Adrian Farrel <[email-masked]> wrote:
> 
> There is a downside: the document clearly needs to be returned to the working group to make this fix, tidy up the rest of the document, and re-establish WG consensus.
> 

I think that is a price worth paying to clear this up.

There is another alternative, but one which will take a while longer and that is to write a standalone document on XL and not muddle it up in label administrative procedure and naming semantics.

Indeed, given that we have all the text, it would not be difficult to craft three very short and to the point drafts that each did a single job.

If you need a ghost editor let me know.

Stewart

---

From: Loa Andersson <[email-masked]>
Date: Sat, 29 Aug 2020 14:23:59 +0800

Stewart,

Inline plz

Sent from my iPhone

> On 28 Aug 2020, at 16:26, Stewart Bryant <[email-masked]> wrote:
> 

I’m afraid you are right. Is it only when a Standards Track document references an Informational document we can make a note in the Last Call write up?

Maybe we should ask the IESG for advice. My concern is that the document is typically Informational.  I’d like to avoid this discussion late in the process. 
 
/Loa

---

From: Loa Andersson <[email-masked]>
Date: Sat, 29 Aug 2020 14:57:55 +0800

Stewart,

Inline please

Sent from my iPhone

> RFC7274 is standards track, and so believe that this terminology draft also needs to be standards track.

I think this is correct, it also motivates making this a Standards Track document and sending it back to the wg. The wg never discussed this and we need wg consensus call.  
> In the IANA section it says:

Some (shorter) version of this text should go into the document. 

/Loa

---

From: Kireeti Kompella <[email-masked]>
Date: Sat, 29 Aug 2020 15:37:59 +0000

I’m in favor of updating this draft:

  1.   making it PS;
  2.  clarifying terminology and ranges;
  3.  adding Stewart’s text on legacy processing of label 7;
  4.  renaming the draft (at least remove “Terminology”);
  5.  sending it back to the WG.

I don’t think we need three new drafts to deal with this, but we do need to deal with the issues raised.

Cheers,
Kireeti
________________________________
From: Loa Andersson <[email-masked]>
Sent: Friday, August 28, 2020 11:57:55 PM
To: Stewart Bryant <[email-masked]>
Cc: Adrian Farrel <[email-masked]>; tom petch <[email-masked]>; Last Call <[email-masked]>; [email-masked] <[email-masked]>; mpls <[email-masked]>; mpls-chairs <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>
Subject: Re: [mpls] [Last-Call] Last Call: <draft-ietf-mpls-spl-terminology-03.txt> (Special Purpose Label terminology) to Informational RFC

Stewart,

Inline please

Sent from my iPhone

> This text clearly demonstrates that legacy LSRs are not expected to police the  <15><7><xxx> construct and that nothing bad will happen of they do not

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 29 Aug 2020 17:02:58 +0000

I agree with Kireeti.
Thanks,
Acee

From: mpls <[email-masked]> on behalf of Kireeti Kompella <kireeti=[email-masked]>
Date: Saturday, August 29, 2020 at 11:38 AM
To: Loa Andersson <[email-masked]>, Stewart Bryant <[email-masked]>
Cc: mpls <[email-masked]>, mpls-chairs <[email-masked]>, Last Call <[email-masked]>, "[email-masked]" <[email-masked]>, tom petch <[email-masked]>
Subject: Re: [mpls] [Last-Call] Last Call: <draft-ietf-mpls-spl-terminology-03.txt> (Special Purpose Label terminology) to Informational RFC

Cheers,
Kireeti

Stewart,

Inline please

Sent from my iPhone

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 29 Aug 2020 10:33:34 -0700

+1

Regards,
Jeff

> On Aug 29, 2020, at 10:03, Acee Lindem (acee) <acee=[email-masked]> wrote:
> 
> 
> I agree with Kireeti.
> Thanks,
> Acee
>

---

From: Loa Andersson <[email-masked]>
Date: Sun, 30 Aug 2020 16:32:19 +0800

Kireeti,

Sent from my iPhone

> On 29 Aug 2020, at 23:38, Kireeti Kompella <[email-masked]> wrote:
> 
> 
>  making it PS;
> clarifying terminology and ranges;
> adding Stewart’s text on legacy processing of label 7;
> renaming the draft (at least remove “Terminology”);
> sending it back to the WG.

Yes, I agree to the content of this list, but I think #5 comes first, then the working group decide what to do (I don’t expect any surprises).

Deborah,
I guess this is on your table. 

/Loa

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 31 Aug 2020 07:37:31 +0100

Sent from my iPad

> I don’t think we need three new drafts to deal with this, but we do need to deal with the issues raised. 
Hi Kireeti

Technically you are right, and of course this is the least work for the authors, IESG and the RFC editor. The question is what is best for the reader?

My preference is to separate the technical description of XL from the IANA related work as I think it allows the implementer to focus on protocol, but I accept that I may be I the rough.

Stewart