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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Kireeti,

Sent from my iPhone

On 29 Aug 2020, at 23:38, Kireeti Kompella <kireeti@xxxxxxxxxxx> wrote:


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.

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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux