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

[Loa Andersson <[e-mail]>]

Kireeti,

Sent from my iPhone

> On 29 Aug 2020, at 23:38, Kireeti Kompella <[e-mail]> wrote:
> 
> 
> I’m in favor of updating this draft:
>  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
> 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 <[e-mail]>
> Sent: Friday, August 28, 2020 11:57:55 PM
> To: Stewart Bryant <[e-mail]>
> Cc: Adrian Farrel <[e-mail]>; tom petch <[e-mail]>; Last Call <[e-mail]>; [e-mail] <[e-mail]>; mpls <[e-mail]>; mpls-chairs <[e-mail]>; BRUNGARD, DEBORAH A <[e-mail]>
> Subject: Re: [mpls] [Last-Call] Last Call: <draft-ietf-mpls-spl-terminology-03.txt> (Special Purpose Label terminology) to Informational RFC
>  
> [External Email. Be cautious of content]
> 
> 
> 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
> 
> Juniper Business Use Only