I agree with Kireeti.
Thanks,
Acee
From:
mpls <mpls-bounces@xxxxxxxx> on behalf of Kireeti Kompella <kireeti=40juniper.net@xxxxxxxxxxxxxx>
Date: Saturday, August 29, 2020 at 11:38 AM
To: Loa Andersson <loa.pi.nu@xxxxxxxxx>, Stewart Bryant <stewart.bryant@xxxxxxxxx>
Cc: mpls <mpls@xxxxxxxx>, mpls-chairs <mpls-chairs@xxxxxxxx>, Last Call <last-call@xxxxxxxx>, "draft-ietf-mpls-spl-terminology@xxxxxxxx" <draft-ietf-mpls-spl-terminology@xxxxxxxx>, tom petch <daedulus@xxxxxxxxxxxxx>
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.
From: Loa Andersson <loa.pi.nu@xxxxxxxxx>
Sent: Friday, August 28, 2020 11:57:55 PM
To: Stewart Bryant <stewart.bryant@xxxxxxxxx>
Cc: Adrian Farrel <adrian@xxxxxxxxxxxx>; tom petch <daedulus@xxxxxxxxxxxxx>; Last Call <last-call@xxxxxxxx>; draft-ietf-mpls-spl-terminology@xxxxxxxx <draft-ietf-mpls-spl-terminology@xxxxxxxx>; mpls <mpls@xxxxxxxx>; mpls-chairs <mpls-chairs@xxxxxxxx>;
BRUNGARD, DEBORAH A <db3546@xxxxxxx>
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@xxxxxxxxx> 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
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
