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

+1

Regards,
Jeff

> On Aug 29, 2020, at 10:03, Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org> wrote:
> 
> 
> I agree with Kireeti.
> Thanks,
> Acee
>  
> From: mpls <mpls-bounces@ietf.org> on behalf of Kireeti Kompella <kireeti=40juniper.net@dmarc.ietf.org>
> Date: Saturday, August 29, 2020 at 11:38 AM
> To: Loa Andersson <loa.pi.nu@gmail.com>, Stewart Bryant <stewart.bryant@gmail.com>
> Cc: mpls <mpls@ietf.org>, mpls-chairs <mpls-chairs@ietf.org>, Last Call <last-call@ietf.org>, "draft-ietf-mpls-spl-terminology@ietf.org" <draft-ietf-mpls-spl-terminology@ietf.org>, tom petch <daedulus@btconnect.com>
> Subject: Re: [mpls] [Last-Call] Last Call: <draft-ietf-mpls-spl-terminology-03.txt> (Special Purpose Label terminology) to Informational RFC
>  
> 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 <loa.pi.nu@gmail.com>
> Sent: Friday, August 28, 2020 11:57:55 PM
> To: Stewart Bryant <stewart.bryant@gmail.com>
> Cc: Adrian Farrel <adrian@olddog.co.uk>; tom petch <daedulus@btconnect.com>; Last Call <last-call@ietf.org>; draft-ietf-mpls-spl-terminology@ietf.org <draft-ietf-mpls-spl-terminology@ietf.org>; mpls <mpls@ietf.org>; mpls-chairs <mpls-chairs@ietf.org>; BRUNGARD, DEBORAH A <db3546@att.com>
> 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 <stewart.bryant@gmail.com> 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
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls