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

[Loa Andersson <[e-mail]>]

Stewart,

Inline please

Sent from my iPhone

> On 28 Aug 2020, at 16:26, Stewart Bryant <[e-mail]> wrote:
> 
> 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:

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 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.

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

/Loa
> 
> 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
> 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls