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

[Adrian Farrel <[e-mail]>]

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

 

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