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

["Acee Lindem (acee)" <[e-mail]>]

I agree with Kireeti.
Thanks,
Acee

From: mpls <[e-mail]> on behalf of Kireeti Kompella <kireeti=[e-mail]>
Date: Saturday, August 29, 2020 at 11:38 AM
To: Loa Andersson <[e-mail]>, Stewart Bryant <[e-mail]>
Cc: mpls <[e-mail]>, mpls-chairs <[e-mail]>, Last Call <[e-mail]>, "[e-mail]" <[e-mail]>, tom petch <[e-mail]>
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 <[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