Subject: [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: [mpls] Please review the PALS/MPLS/DetNet Joint Session minutes)

From: <[email-masked]>
Date: Wed, 30 Mar 2022 08:16:39 +0000

As a follow up

> [Ketan]: WG should consider adopting the Bruno draft as interim
> [Kireeti]: suggest attending talk by Tony on danger of reusing ELI before making any decision.
https://notes.ietf.org/notes-ietf-113-pals

Done. The talk raised no "danger of reusing ELI" for draft draft-decraene-mpls-slid-encoded-entropy-label-id; quite the contrary.
I quote: "claims of backward compatibility apply to draft-decraene-mpls-slid-encoded-entropy-label-id-03". With more details on slide 18
https://datatracker.ietf.org/meeting/113/materials/slides-113-mpls-05-policy-on-mpls-special-purpose-labels-reuse-00

Thanks,
--Bruno

Orange Restricted
From: mpls <[email-masked]> On Behalf Of Andrew G. Malis
Sent: Tuesday, March 29, 2022 9:58 PM
To: [email-masked]; mpls <[email-masked]>; detnet WG <[email-masked]>
Subject: [mpls] Please review the PALS/MPLS/DetNet Joint Session minutes

Please review the PALS/MPLS/DetNet Joint Session minutes at https://notes.ietf.org/notes-ietf-113-pals . They are still editable, or you can let me know if you have any comments or issues. I plan to upload them this Friday April 1 as the final minutes.

Thanks,
Andy

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Tony Li <[email-masked]>
Date: Wed, 30 Mar 2022 07:08:17 -0700

> https://notes.ietf.org/notes-ietf-113-pals <https://notes.ietf.org/notes-ietf-113-pals>
>  
> Done. The talk raised no “danger of reusing ELI” for draft draft-decraene-mpls-slid-encoded-entropy-label-id; quite the contrary.
> I quote: “claims of backward compatibility apply to draft-decraene-mpls-slid-encoded-entropy-label-id-03”. With more details on slide 18
> https://datatracker.ietf.org/meeting/113/materials/slides-113-mpls-05-policy-on-mpls-special-purpose-labels-reuse-00 <https://datatracker.ietf.org/meeting/113/materials/slides-113-mpls-05-policy-on-mpls-special-purpose-labels-reuse-00>

Yes, the issue with this proposal is that it has no space for in-stack data and not enough space for possible expansion of additional actions.

Tony

---

From: <[email-masked]>
Date: Wed, 30 Mar 2022 16:59:40 +0000

From: Tony Li <[email-masked]> On Behalf Of Tony Li
Sent: Wednesday, March 30, 2022 4:08 PM

[Bruno] There are two steps:
- This proposal allows for carrying 8 Indicators and a slice ID while been backward compatible with egress LER hance providing faster deployment with incremental benefit.
- If more in-stack data is required the proposal is extensible (e.g. draft-jags-mpls-ext-hdr) but at the cost of losing the above benefits for the ASes & uses-cases requiring more than 8 Indicators per AS or In-Stack Data.
So we can have both worlds: simple first step and extensibility for those who need it.

Independently, we also/already have the post stack data option to carry ancillary data, which may limit the need for In-Stack data extension.

--Bruno

Tony

Orange Restricted

---

From: John E Drake <[email-masked]>
Date: Wed, 30 Mar 2022 17:12:56 +0000

Except that putting a slice ID in the Entropy Label field will break existing  ELI/EL Implementations because their hashing of the slice ID won’t necessarily place a packet on the correct outgoing I/F

Sent from my iPhone

On Mar 30, 2022, at 1:00 PM, [email-masked] wrote:

[External Email. Be cautious of content]

> [Kireeti]: suggest attending talk by Tony on danger of reusing ELI before making any decision.
https://notes.ietf.org/notes-ietf-113-pals<https://urldefense.com/v3/__https://notes.ietf.org/notes-ietf-113-pals__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcqrP3gOo$>

Done. The talk raised no “danger of reusing ELI” for draft draft-decraene-mpls-slid-encoded-entropy-label-id; quite the contrary.
I quote: “claims of backward compatibility apply to draft-decraene-mpls-slid-encoded-entropy-label-id-03”. With more details on slide 18
https://datatracker.ietf.org/meeting/113/materials/slides-113-mpls-05-policy-on-mpls-special-purpose-labels-reuse-00<https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/113/materials/slides-113-mpls-05-policy-on-mpls-special-purpose-labels-reuse-00__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcNEC7QKk$>

--Bruno

Tony

Orange Restricted

_______________________________________________
Pals mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pals__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcSqI60Zo$

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 30 Mar 2022 19:20:32 +0000

John, do you have evidence of this or is this a theoretical claim ?

From: mpls <[email-masked]> on behalf of John E Drake <jdrake=[email-masked]>
Date: Wednesday, 30 March 2022 at 19:13
To: [email-masked] <[email-masked]>
Cc: mpls <[email-masked]>, detnet WG <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)
Except that putting a slice ID in the Entropy Label field will break existing  ELI/EL Implementations because their hashing of the slice ID won’t necessarily place a packet on the correct outgoing I/F
Sent from my iPhone

> [Kireeti]: suggest attending talk by Tony on danger of reusing ELI before making any decision.
https://notes.ietf.org/notes-ietf-113-pals<https://urldefense.com/v3/__https:/notes.ietf.org/notes-ietf-113-pals__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcqrP3gOo$>

Done. The talk raised no “danger of reusing ELI” for draft draft-decraene-mpls-slid-encoded-entropy-label-id; quite the contrary.
I quote: “claims of backward compatibility apply to draft-decraene-mpls-slid-encoded-entropy-label-id-03”. With more details on slide 18
https://datatracker.ietf.org/meeting/113/materials/slides-113-mpls-05-policy-on-mpls-special-purpose-labels-reuse-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/113/materials/slides-113-mpls-05-policy-on-mpls-special-purpose-labels-reuse-00__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcNEC7QKk$>

--Bruno

Tony

Orange Restricted

Thank you.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 30 Mar 2022 12:47:33 -0700

Hi Bruno, et al.,
I have several questions and would greatly appreciate your thoughts:

   - Do you see the need for extensions to the routing protocols that now
   advertise the support of RFC 6790 to avoid the scenario that John has
   pointed out?
   - As I understand the draft, using EL and Slice ID in the same stack is
   mutually exclusive. If that is the case, how entropy can be created within
   the particular network slice?
   - I think that you've agreed that the draft does not address the
requirements
   for MIAD
   <https://datatracker.ietf.org/doc/draft-bocci-mpls-miad-adi-requirements/>.
   You've pointed out Jags' draft
   <https://datatracker.ietf.org/doc/draft-jags-mpls-ext-hdr/> as the
   possible solution that is based on the re-definition of the ELI and may
   address MIAD ADI requirements, To that, I can make two observations:
      - re-using ELI is only one optional approach discussed
      in draft-jags-mpls-ext-hdr. I think that is not guaranteed that
that would
      be the option used if the document is published.
      - And if draft-jags-mpls-ext-hdr continues with the solution based on
      the re-definition of the ELI, it appears to me that all Tony's
concerns are
      valid.

Thank you in advance for your consideration of my notes.

Regards,
Greg

On Wed, Mar 30, 2022 at 9:59 AM <[email-masked]> wrote:

>
>
>
>
> *From:* Tony Li <[email-masked]> *On Behalf Of *Tony Li
> *Sent:* Wednesday, March 30, 2022 4:08 PM
>
> Done. The talk raised no “danger of reusing ELI” for draft
> draft-decraene-mpls-slid-encoded-entropy-label-id; quite the contrary.
>
> I quote: “claims of backward compatibility apply to
> draft-decraene-mpls-slid-encoded-entropy-label-id-03”. With more details on
> slide 18
>
>
> Yes, the issue with this proposal is that it has no space for in-stack
> data and not enough space for possible expansion of additional actions.
>
>
>
> - This proposal allows for carrying 8 Indicators and a slice ID while been
> backward compatible with egress LER hance providing faster deployment with
> incremental benefit.
>
> - If more in-stack data is required the proposal is extensible (e.g.
> draft-jags-mpls-ext-hdr) but at the cost of losing the above benefits for
> the ASes & uses-cases requiring more than 8 Indicators per AS or In-Stack
> Data.
>
> Independently, we also/already have the post stack data option to carry
> ancillary data, which may limit the need for In-Stack data extension.
>
>
>
> --Bruno
>
>
>
> Tony
>
>
>
>
>
>
>
> Orange Restricted
>
> https://www.ietf.org/mailman/listinfo/pals
>

---

From: John E Drake <[email-masked]>
Date: Wed, 30 Mar 2022 20:02:36 +0000

Wim,

I think I would term it a thought experiment.  An RFC 6790 compliant node will take the value in the EL label field and use it to select an outgoing interface.  If the value in the EL field is a slice ID, such an node will select an outgoing interface which is not necessarily part of the slice in question and that outgoing interface will be to a node which is not necessarily part of the slice in question.

Yours Irrespectively,

John

Juniper Business Use Only
From: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>
Sent: Wednesday, March 30, 2022 3:21 PM
To: John E Drake <[email-masked]>; [email-masked]
Cc: mpls <[email-masked]>; detnet WG <[email-masked]>; [email-masked]
Subject: Re: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

From: mpls <[email-masked]<mailto:[email-masked]>> on behalf of John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>
Date: Wednesday, 30 March 2022 at 19:13
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>, detnet WG <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)
Except that putting a slice ID in the Entropy Label field will break existing  ELI/EL Implementations because their hashing of the slice ID won’t necessarily place a packet on the correct outgoing I/F
Sent from my iPhone

On Mar 30, 2022, at 1:00 PM, [email-masked]<mailto:[email-masked]> wrote:

From: Tony Li <[email-masked]<mailto:[email-masked]>> On Behalf Of Tony Li
Sent: Wednesday, March 30, 2022 4:08 PM

--Bruno

Tony

Orange Restricted

Thank you.
_______________________________________________
Pals mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pals__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcSqI60Zo$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/pals__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcSqI60Zo$>

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 31 Mar 2022 04:10:52 +0000

John,

We have 2 cases here in my view.

  *   A node that is not upgraded with the SW capabilities to support Bruno’s extension -> will still load-balance as before and might or might not take the bits into account that would be used for the slice ID
     *   I believe we are discussing this case when we discuss “we will break existing  ELI/EL Implementations”. Let’s say even if they take the slice id bit into account, they continue to hash/load-balance on the interface set assigned.
     *   Of course this node is not slice aware as the SW is not supporting this extension, but this has is not related to “breaking existing ELI/EL implementations”.
     *   Even when I did a quick test some HW does not even take into account these bits. So in my view we don’t break existing EL/ELI implementations.
     *   We should really validate the behavior of the existing systems to see the behavior if we make such claims.
  *   A node that is upgraded with the extension of Bruno’s draft will do the right thing. This can easily be resolved with an extension in the Control plane to say which nodes support and don’t support slicing.

From: John E Drake <[email-masked]>
Date: Wednesday, 30 March 2022 at 22:02
To: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>, [email-masked] <[email-masked]>
Cc: mpls <[email-masked]>, detnet WG <[email-masked]>, [email-masked] <[email-masked]>
Subject: RE: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)
Wim,

Yours Irrespectively,

John

--Bruno

Tony

Orange Restricted

Thank you.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 31 Mar 2022 00:30:07 -0400

I like Bruno’s idea of reusing the entropy label as indicator of MEH in the
label stack and is backwards compatibility for devices not supporting can
continue to use for ECMP load balancing.

I think this is a solid interim solution to get the ball rolling with
minimal software updates and being able to support ancillary data in the
label stack and as other solutions are progressed that may take longer or
implement and deploy at least in the near term we have a quick solution
that could be promising for operators.

I think we do have to vett out the backwards compatibility and scenario I
can think of is if you want to be able to use the entropy label for ECMP
load balancing and simultaneously want to also use as ancillary data
indicator I am guessing won’t work and that is something we would have to
be cognizant of if deployed.

Kind Regards

Gyan

On Wed, Mar 30, 2022 at 4:04 PM John E Drake <jdrake=
[email-masked]> wrote:

> Wim,
>
>
>
> I think I would term it a thought experiment.  An RFC 6790 compliant node
> will take the value in the EL label field and use it to select an outgoing
> interface.  If the value in the EL field is a slice ID, such an node will
> select an outgoing interface which is not necessarily part of the slice in
> question and that outgoing interface will be to a node which is not
> necessarily part of the slice in question.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> *From:* Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>
> *Sent:* Wednesday, March 30, 2022 3:21 PM
> *To:* John E Drake <[email-masked]>; [email-masked]
> *Cc:* mpls <[email-masked]>; detnet WG <[email-masked]>; [email-masked]
> *Subject:* Re: [mpls] [Pals]
> draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review
> the PALS/MPLS/DetNet Joint Session minutes)
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> *From: *mpls <[email-masked]> on behalf of John E Drake <
> jdrake=[email-masked]>
> *Date: *Wednesday, 30 March 2022 at 19:13
> *To: [email-masked] <[email-masked]>
> *Cc: *mpls <[email-masked]>, detnet WG <[email-masked]>, [email-masked] <
> [email-masked]>
> *Subject: *Re: [mpls] [Pals]
> draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review
> the PALS/MPLS/DetNet Joint Session minutes)
>
> Except that putting a slice ID in the Entropy Label field will break
> existing  ELI/EL Implementations because their hashing of the slice ID
> won’t necessarily place a packet on the correct outgoing I/F
>
> Sent from my iPhone
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
>
>
> <https://urldefense.com/v3/__https:/notes.ietf.org/notes-ietf-113-pals__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcqrP3gOo$>
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/113/materials/slides-113-mpls-05-policy-on-mpls-special-purpose-labels-reuse-00__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcNEC7QKk$>
>
>
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/pals__;!!NEt6yMaO-gk!Sw9ofU9AyD7Z-JKwyAqMlHk5xhNLxZNMSu31Yt6-K7yh-6JehvlSPLDcSqI60Zo$>
>
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: <[email-masked]>
Date: Thu, 31 Mar 2022 07:38:17 +0000

John,

Regarding existing implementations compliant with Entropy Label https://datatracker.ietf.org/doc/html/rfc6790 :
- Ingress is free to use any field and any function to generate the entropy label. E.g., incoming customer physical interface and virtual interface which are not fields in the packet. The only requirement is that the EL be constant for a given flow such as this value can be used for ECMP load-balancing. I think that we’ll probably agree that the slide ID is constant for a given flow.
- Transit is mostly free to not even do anything special with EL. Assuming it uses the MPLS label for load-balancing, it’s using the value in EL either as a general label (used part of hashing multiple labels) of after recognizing the ELI and using only the EL. How the EL value has been chosen.

So I’m not seeing a theoretical way to “break existing ELI/EL Implementations”.

Are you aware of a specific EL compliant specification which would be broken by the new behavior? If so please be specific.

Finally, a priori the risk of affecting existing implementations seems higher with proposal doing much larger change in the MPLS Label stack, such as trying to fit generic In Stack Data in a MPLS label stack (or LSE) which has not been designed for that. I’m not sure why you are not at least equally commenting on such proposals.

--Bruno

Orange Restricted
From: John E Drake <[email-masked]>
Sent: Wednesday, March 30, 2022 7:13 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]>
Cc: Tony Li <[email-masked]>; mpls <[email-masked]>; detnet WG <[email-masked]>; Andrew G. Malis <[email-masked]>; [email-masked]
Subject: Re: [Pals] [mpls] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

--Bruno

Tony

Orange Restricted

Thank you.

---

From: <[email-masked]>
Date: Thu, 31 Mar 2022 07:43:01 +0000

> - Transit  […] How the EL value has been chosen.

I meant to write : How the EL value has been chosen does not concern the transit node.

Sorry for the spam

--Bruno

Orange Restricted
From: mpls <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, March 31, 2022 9:38 AM
To: John E Drake <[email-masked]>
Cc: mpls <[email-masked]>; detnet WG <[email-masked]>; [email-masked]
Subject: Re: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

John,

--Bruno

Orange Restricted
From: John E Drake <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 30, 2022 7:13 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]<mailto:[email-masked]>>
Cc: Tony Li <[email-masked]<mailto:[email-masked]>>; mpls <[email-masked]<mailto:[email-masked]>>; detnet WG <[email-masked]<mailto:[email-masked]>>; Andrew G. Malis <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pals] [mpls] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

--Bruno

Tony

Orange Restricted

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 31 Mar 2022 07:59:03 +0000

Hi Greg,

Please see inline [Bruno] tentative replies to your questions.

Orange Restricted
From: Greg Mirsky <[email-masked]>
Sent: Wednesday, March 30, 2022 9:48 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]>
Cc: Tony Li <[email-masked]>; mpls <[email-masked]>; detnet WG <[email-masked]>; Andrew G. Malis <[email-masked]>; [email-masked]
Subject: Re: [Pals] [mpls] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

Hi Bruno, et al.,

  *   Do you see the need for extensions to the routing protocols that now advertise the support of RFC 6790 to avoid the scenario that John has pointed out?
[Bruno] No and so far I'm not even seeing any (negative) scenario in John's email.

  *   As I understand the draft, using EL and Slice ID in the same stack is mutually exclusive. If that is the case, how entropy can be created within the particular network slice?
[Bruno] Please reread the draft and more specifically sections 3 and 3.1. You are not correct: the use of EMCP entropy and slice ID is not mutually exclusive, in the stack but even in a single EL. In short, one part of the EL is used to encode the slide ID and the remaining part carry the entropy number. Legacy transit LSR may use the whole EL transparently as the whole EL _is_ an entropy value which may be used for load-balancing (how that EL value is constructed by the ingress is not the concern of the transit).

  *   I think that you've agreed that the draft does not address the requirements for MIAD<https://datatracker.ietf.org/doc/draft-bocci-mpls-miad-adi-requirements/>. You've pointed out Jags' draft<https://datatracker.ietf.org/doc/draft-jags-mpls-ext-hdr/> as the possible solution that is based on the re-definition of the ELI and may address MIAD ADI requirements, To that, I can make two observations:

     *   re-using ELI is only one optional approach discussed in draft-jags-mpls-ext-hdr. I think that is not guaranteed that that would be the option used if the document is published.
     *   And if draft-jags-mpls-ext-hdr continues with the solution based on the re-definition of the ELI, it appears to me that all Tony's concerns are valid.
[Bruno] I'm not sure what anything new your are bringing in addition to Tony's analysis and email. So I'll just copy past the same reply:
There are two steps:
- This proposal allows for carrying 8 Indicators and a slice ID while been backward compatible with egress LER hence providing faster deployment with incremental benefit.
- If more in-stack data is required the proposal is extensible (e.g. draft-jags-mpls-ext-hdr) but at the cost of losing the above benefits for the ASes & uses-cases requiring more than 8 Indicators per AS or In-Stack Data.
So we can have both worlds: simple first step and extensibility for those who need it.

Thank you in advance for your consideration of my notes.
[Bruno] You are very welcome. Thank you in advance for considering my answers.

Regards,
Bruno
Regards,
Greg

On Wed, Mar 30, 2022 at 9:59 AM <[email-masked]<mailto:[email-masked]>> wrote:

--Bruno

Tony

Orange Restricted

Thank you.

---

From: Rajesh Pandey <[email-masked]>
Date: Thu, 31 Mar 2022 14:40:10 +0530

Hi Bruno,

Yes, how the EL value has been chosen does not concern the transit node.
However, the value of EL does concern transit nodes.
It doesn't break ELI/EL implementation but certainly makes it weaker.

Consider an LSR node solely relying on EL and receiving most of the traffic
over LAG/single virtual interface.

- For a single LSR, 20 bits of entropy gets diluted by 40% (remaining 8
bits are the same for single flow) could cause weaker ECMP and LAG load
balancing decisions.
- With multiple LSR taken into consideration, it could cause traffic
polarization potentially.

Regards,
Rajesh

On Thu, Mar 31, 2022 at 1:14 PM <[email-masked]> wrote:

> *From:* mpls <[email-masked]> *On Behalf Of *
> [email-masked]
> *Sent:* Thursday, March 31, 2022 9:38 AM
> *To:* John E Drake <[email-masked]>
> Regarding existing implementations compliant with Entropy Label
> https://datatracker.ietf.org/doc/html/rfc6790 :
>
> - Ingress is free to use any field and any function to generate the
> entropy label. E.g., incoming customer physical interface and virtual
> interface which are not fields in the packet. The only requirement is that
> the EL be constant for a given flow such as this value can be used for ECMP
> load-balancing. I think that we’ll probably agree that the slide ID is
> constant for a given flow.
>
> - Transit is mostly free to not even do anything special with EL. Assuming
> it uses the MPLS label for load-balancing, it’s using the value in EL
> either as a general label (used part of hashing multiple labels) of after
> recognizing the ELI and using only the EL. How the EL value has been chosen.
>
>
>
> Are you aware of a specific EL compliant specification which would be
> broken by the new behavior? If so please be specific.
>
>
>
> Finally, a priori the risk of affecting existing implementations seems
> higher with proposal doing much larger change in the MPLS Label stack, such
> as trying to fit generic In Stack Data in a MPLS label stack (or LSE) which
> has not been designed for that. I’m not sure why you are not at least
> equally commenting on such proposals.
>
>
>
> --Bruno
>
>
>
>
>
> Orange Restricted
>
> *From:* John E Drake <[email-masked]>
> *Sent:* Wednesday, March 30, 2022 7:13 PM
> *To:* DECRAENE Bruno INNOV/NET <[email-masked]>
> *Cc:* Tony Li <[email-masked]>; mpls <[email-masked]>; detnet WG <
> [email-masked]>; Andrew G. Malis <[email-masked]>; [email-masked]
> *Subject:* Re: [Pals] [mpls]

-- 

Thanks and Regards,

Rajesh Pandey,
CISCO Systems,
Bangalore.
Mob. +91-9448252727

---

From: <[email-masked]>
Date: Thu, 31 Mar 2022 10:17:11 +0000

Hi Rajesh,

First of all, your point is specific to the slice aspect of the draft. It is not related to use of Indicators. (*)

In that context:
- I mostly agree with you on the theoretical side.
- However in practice it really depends on how many different ECMPs you have, how many slices you have, how many bits you allocate for the slicing parts (It’s very different whether you have 8 “transport” slices or 1 million), how many hops on the path, how the transit LSR is doing ECMP (e.g. how many labels, possibly how many bits it use from (each) labels…) since none of this is standardized and very platform specific, how many flows the ingress is able to “see” (or how much entropy it really has from the fields it’s looking at).

With the partial data that I have in mind, IMHO there is space to use it.

But again, my presentation in IETF 113, and hence the comments in the minutes, was related to the “Indicators” part

(*) You have not claim that, but I think it’s better to clarify this part.

Regards,
--Bruno

Orange Restricted
From: Rajesh Pandey <[email-masked]>
Sent: Thursday, March 31, 2022 11:10 AM
To: DECRAENE Bruno INNOV/NET <[email-masked]>
Cc: John E Drake <[email-masked]>; mpls <[email-masked]>; detnet WG <[email-masked]>; [email-masked]
Subject: Re: [Pals] [mpls] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

Hi Bruno,

Yes, how the EL value has been chosen does not concern the transit node. However, the value of EL does concern transit nodes.
It doesn't break ELI/EL implementation but certainly makes it weaker.

Consider an LSR node solely relying on EL and receiving most of the traffic over LAG/single virtual interface.

- For a single LSR, 20 bits of entropy gets diluted by 40% (remaining 8 bits are the same for single flow) could cause weaker ECMP and LAG load balancing decisions.
- With multiple LSR taken into consideration, it could cause traffic polarization potentially.

Regards,
Rajesh

Sorry for the spam

--Bruno

Orange Restricted
From: mpls <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, March 31, 2022 9:38 AM
To: John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>; detnet WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

John,

--Bruno

Orange Restricted

--Bruno

Tony

Orange Restricted

Thank you.

Thank you.

Thank you.

--

Thanks and Regards,

Rajesh Pandey,
CISCO Systems,
Bangalore.
Mob. +91-9448252727

---

From: <[email-masked]>
Date: Thu, 31 Mar 2022 11:14:44 +0000

John,

I understand that there may be different ways to create network slices, so may be some additional context may be useful.
draft-decraene-mpls-slid-encoded-entropy-label-id is proposing a way to encode the slice ID which is needed for some approaches e.g. the “Global Identifier Based Selector” from https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet#section-5.1.1
In short, the top label is defining the routing hence the (set of) outgoing interfaces on a given LSR. This routing is not altered by the slice ID.

Clearly, the “controller” defining the slice, need to enforce a route (hence the set of next-hops) which is compatible with the slice (ID) characteristics. This point would probably be better discussed as part of draft-bestbar-teas-ns-packet or more generally in the TEAS WG.
draft-decraene-mpls-slid-encoded-entropy-label-id is only providing a way to encode the slice ID in the MPLS packet.

--Bruno

Orange Restricted
From: John E Drake <[email-masked]>
Sent: Wednesday, March 30, 2022 10:03 PM
To: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; DECRAENE Bruno INNOV/NET <[email-masked]>
Cc: mpls <[email-masked]>; detnet WG <[email-masked]>; [email-masked]
Subject: RE: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

Wim,

Yours Irrespectively,

John

Juniper Business Use Only
From: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 30, 2022 3:21 PM
To: John E Drake <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: mpls <[email-masked]<mailto:[email-masked]>>; detnet WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

--Bruno

Tony

Orange Restricted

Thank you.

---

From: John E Drake <[email-masked]>
Date: Thu, 31 Mar 2022 13:08:10 +0000

Hi,

Comments inline below.

Yours Irrespectively,

John

Juniper Business Use Only
From: [email-masked] <[email-masked]>
Sent: Thursday, March 31, 2022 3:38 AM
To: John E Drake <[email-masked]>
Cc: Tony Li <[email-masked]>; mpls <[email-masked]>; detnet WG <[email-masked]>; Andrew G. Malis <[email-masked]>; [email-masked]
Subject: RE: [Pals] [mpls] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

John,

Regarding existing implementations compliant with Entropy Label https://datatracker.ietf.org/doc/html/rfc6790<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc6790__;!!NEt6yMaO-gk!Ud1zvIIaIXWqe-aLp48yFm4pbELCYyCbjygQ9tr0cs_Tdv_guebMxrHKWvddWf8$> :
- Ingress is free to use any field and any function to generate the entropy label. E.g., incoming customer physical interface and virtual interface which are not fields in the packet. The only requirement is that the EL be constant for a given flow such as this value can be used for ECMP load-balancing. I think that we’ll probably agree that the slide ID is constant for a given flow.
- Transit is mostly free to not even do anything special with EL. Assuming it uses the MPLS label for load-balancing, it’s using the value in EL either as a general label (used part of hashing multiple labels) of after recognizing the ELI and using only the EL. How the EL value has been chosen.

[JD]  As Rajesh pointed out, your proposal would dilute the effect of EL.  However, my email was discussing a different issue, viz, a down-level node would not properly handle the slice ID and would not necessarily put a packet on the correct outgoing interface.  The key selling point of your proposal is that not all nodes need to be upgraded and I was simply pointing out that if not all nodes are upgraded, your network will behave unpredictably

Finally, a priori the risk of affecting existing implementations seems higher with proposal doing much larger change in the MPLS Label stack, such as trying to fit generic In Stack Data in a MPLS label stack (or LSE) which has not been designed for that.

[JD]   This is simply an assertion

I’m not sure why you are not at least equally commenting on such proposals.

[JD]  In the proposals that don’t re-use EL/ELI, a down-level node will never see the new SPL and in-stack ancillary data.

--Bruno

Orange Restricted

--Bruno

Tony

Orange Restricted

Thank you.

Thank you.

---

From: John E Drake <[email-masked]>
Date: Thu, 31 Mar 2022 13:10:59 +0000

Wim,

Please see my reply to Bruno.

Yours Irrespectively,

John

Sent: Thursday, March 31, 2022 12:11 AM

John,

To: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

Yours Irrespectively,

John

--Bruno

Tony

Orange Restricted

Thank you.

---

From: John E Drake <[email-masked]>
Date: Thu, 31 Mar 2022 13:18:06 +0000

Hi,

Please see my reply to your other email.  Comment inline.

Yours Irrespectively,

John

Juniper Business Use Only
From: [email-masked] <[email-masked]>
Sent: Thursday, March 31, 2022 7:15 AM
To: John E Drake <[email-masked]>
Cc: mpls <[email-masked]>; detnet WG <[email-masked]>; [email-masked]; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>
Subject: RE: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

John,

I understand that there may be different ways to create network slices, so may be some additional context may be useful.
draft-decraene-mpls-slid-encoded-entropy-label-id is proposing a way to encode the slice ID which is needed for some approaches e.g. the “Global Identifier Based Selector” from https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet#section-5.1.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet*section-5.1.1__;Iw!!NEt6yMaO-gk!WzZ9PSulA4P8AXbvllKlwd-T5wJMZ26-qBTUj_nL2ezLGqZfEHJM-ooZmb-nMsU$>
In short, the top label is defining the routing hence the (set of) outgoing interfaces on a given LSR. This routing is not altered by the slice ID.

[JD]  If you require paths that only transit LSRs that understand the slice ID in a re-purposed ELI/EL, then your proposal is effectively no different than using a different bSPL and hence your claimed advantages disappear.

--Bruno

Orange Restricted
To: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; DECRAENE Bruno INNOV/NET <[email-masked]<mailto:[email-masked]>>

Wim,

Yours Irrespectively,

John

--Bruno

Tony

Orange Restricted

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 31 Mar 2022 13:30:36 +0000

John,

Please see my comments inline [Bruno]

Orange Restricted
Sent: Thursday, March 31, 2022 3:18 PM

Hi,

Yours Irrespectively,

John

Juniper Business Use Only
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, March 31, 2022 7:15 AM
To: John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>; detnet WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

John,

[JD]  If you require paths that only transit LSRs that understand the slice ID in a re-purposed ELI/EL, then your proposal is effectively no different than using a different bSPL and hence your claimed advantages disappear.
[Bruno] Regarding the first part of your sentence: if and only if you need special (CoS) treatment on the transit LSR to perform slice specific treatment, then you need this LSR to be upgraded. This is clearly required in all cases/solution.
Regarding the second part of your sentence, you seem to have clearly missed the point: using a new bSPL can only be used by ingress and all transit LSR when the Egress LSR support this new bSPL (otherwise it will drop the packet). Using the existing ELI takes benefit of most if not all LER already supporting this bSPL (ELI)

--Bruno

Orange Restricted

Wim,

Yours Irrespectively,

John

--Bruno

Tony

Orange Restricted

Thank you.

Thank you.

---

From: John E Drake <[email-masked]>
Date: Thu, 31 Mar 2022 13:39:11 +0000

Hi,

Comments inline below.

Yours Irrespectively,

John

Sent: Thursday, March 31, 2022 9:31 AM

John,

Orange Restricted

Hi,

Yours Irrespectively,

John

John,

[JD]  My other email reply to you pointed out that you can’t depend on a down-level node to properly deliver a packet to an up-level node.

Regarding the second part of your sentence, you seem to have clearly missed the point: using a new bSPL can only be used by ingress and all transit LSR when the Egress LSR support this new bSPL (otherwise it will drop the packet).

[JD]   This is incorrect.  The new bSPL and  in-stack ancillary data will not be seen by a down-level transit node.

Using the existing ELI takes benefit of most if not all LER already supporting this bSPL (ELI)

--Bruno

Orange Restricted

Wim,

Yours Irrespectively,

John

--Bruno

Tony

Orange Restricted

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 31 Mar 2022 13:55:04 +0000

John,

Please see comments inline [Bruno]

Orange Restricted
Sent: Thursday, March 31, 2022 3:08 PM

Hi,

Comments inline below.

Yours Irrespectively,

John

John,

[JD]  As Rajesh pointed out, your proposal would dilute the effect of EL.  However, my email was discussing a different issue, viz, a down-level node would not properly handle the slice ID and would not necessarily put a packet on the correct outgoing interface.  The key selling point of your proposal is that not all nodes need to be upgraded and I was simply pointing out that if not all nodes are upgraded, your network will behave unpredictably
[Bruno] I’m not sure what you mean by “down-level node”. I will assume “downstream node”. Whether a downstream node does or does not handle the slice ID has no impact on routing/ set of outgoing interface. Set of outgoing interface is determined by the top label (transport label). Now regarding the choice of a specific outgoing interface out of the set of ECMP, there is no “correct” interface as they are equivalent. What matter is that all packets of the same flow use the same interface. This is the case whether or not the LSR support the extension: in both cases, it’s behavior is consistent across packets having the same entropy. (IOW the LSR is consistent with itself across packets/time)
The key selling point is discussed in the previous email.
No the network will not behave unpredictably in term or routing (with the exception that the choice of the outgoing interface out of the spec of ECMPs is not (easily) predictable regardless of the way load-balancing is performed.) In term of CoS (or whatever per slice treatment), LSR not supporting the slice ID (whatever its encoding) will behave like vanilla LSR. I would call this predictable, but in all cases, this is obviously the cases for all proposals.

[JD]   This is simply an assertion
[Bruno] Correct. Just like your original email. At least we could agree that some proposal are doing larger change in the MPLS label by trying to fit generic In Stack Data in a MPLS label stack (or LSE) which has not been designed for that. This seem factual.

[JD]  In the proposals that don’t re-use EL/ELI, a down-level node will never see the new SPL and in-stack ancillary data.
[Bruno] If the egress LER does not advertise the support of the new SPL (resp. ELI) the ingress LER can send the new SPL (resp. ELI). No difference. The key difference is that today 0% LER support the new SPL while a very large portion of LER supports the ELI. New SPL support will be behind for a significant period (decade if not forever)
Transit LSR, may look at the in-stack labels (e.g. new SPL, ELI) regardless of their support (of new SPL, ELI). If they support the SPL (new or ELI) can act upon.

--Bruno

Orange Restricted

--Bruno

Tony

Orange Restricted

Thank you.

Thank you.

---

From: John E Drake <[email-masked]>
Date: Thu, 31 Mar 2022 14:43:15 +0000

Hi,

Comments inline below.

Yours Irrespectively,

John

Sent: Thursday, March 31, 2022 9:55 AM

John,

Orange Restricted

Hi,

Comments inline below.

Yours Irrespectively,

John

John,

[JD]  As Rajesh pointed out, your proposal would dilute the effect of EL.  However, my email was discussing a different issue, viz, a down-level node would not properly handle the slice ID and would not necessarily put a packet on the correct outgoing interface.  The key selling point of your proposal is that not all nodes need to be upgraded and I was simply pointing out that if not all nodes are upgraded, your network will behave unpredictably
[Bruno] I’m not sure what you mean by “down-level node”.

[JD]  I mean a transit node that supports RFC 6790.

I will assume “downstream node”. Whether a downstream node does or does not handle the slice ID has no impact on routing/ set of outgoing interface. Set of outgoing interface is determined by the top label (transport label). Now regarding the choice of a specific outgoing interface out of the set of ECMP, there is no “correct” interface as they are equivalent. What matter is that all packets of the same flow use the same interface. This is the case whether or not the LSR support the extension: in both cases, it’s behavior is consistent across packets having the same entropy. (IOW the LSR is consistent with itself across packets/time)
The key selling point is discussed in the previous email.
No the network will not behave unpredictably in term or routing (with the exception that the choice of the outgoing interface out of the spec of ECMPs is not (easily) predictable regardless of the way load-balancing is performed.) In term of CoS (or whatever per slice treatment), LSR not supporting the slice ID (whatever its encoding) will behave like vanilla LSR. I would call this predictable, but in all cases, this is obviously the cases for all proposals.

[JD]  It is not necessarily the case that all outgoing interfaces support a given slice ID.  This means that a down-level node may select an outgoing interface that does not support the slice ID specified in the packet, which means that the packet has now left the slice

[JD]  Oopsie,  Perhaps I should have said:  if the slice ID is carried within the EL LSE label field, then the effect of EL is diluted and a down-level node may mis-route packets because it does not understand the slice ID

[JD]  If you are saying that incremental deployment of a new bSPL or a re-purposed ELI/EL are equivalent, i.e., that only the nodes that understand the new capabilities can act upon them, then I agree.  As we had indicated in our analysis, the only ELI/EL re-purposing proposal that doesn’t seem to have issues is your proposal to simply re-use the EL LSE TTL fields as indicators.  However, as Tony noted, that offers limited functionality.

--Bruno

Orange Restricted

--Bruno

Tony

Orange Restricted

Thank you.

Thank you.

Thank you.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 31 Mar 2022 10:58:05 -0400

Hi Bruno

Please provide clarification on how existing implementations using Entropy
Label ELI/EL RFC 6790 with your proposal to reuse the entropy label.

In section 2 you talk about the new entropy label control field in your
proposal to reuse the TTL field as the entropy label control field.

I have some questions related below that are concerning with your proposal.

RFC 6790 section 4 talks about the TTL processing below excerpt.

   If an ingress LSR X chooses to impose an EL, then Y will receive a
   tunnel termination packet with label stack <TL, ELI, EL> <remaining
   packet header>.  Y recognizes TL as the label it distributed to its
   upstreams for the tunnel and pops it.  (Note that TL may be the
   implicit null label, in which case it doesn't appear in the label
   stack.)  Y then recognizes the ELI and pops two labels: the ELI and
   the EL.  Y then processes the remaining packet header as normal; this
   may require further processing of tunnel termination, perhaps with
   further ELI+EL pairs.  When processing the final tunnel termination,
   Y MAY enqueue the packet based on that tunnel TL's or ELI's TC value
   and MAY use the tunnel TL's or ELI's TTL to compute the TTL of the
   remaining packet header.  The EL's TTL MUST be ignored.

So the TL or ELI is used to compute the TTL of the remaining packet
header.  States that EL’s TTL is ignored.

Section 4.2 mentions that the TTL for the EL MUST be set to 0 so it’s not
used for forwarding.  The issue here is related to implicit null PHP case
where the TL is popped and ELI,EL are exposed and to ensure that the EL is
not used for forwarding the EL MUST be set to 0.

   4.  If, for the chosen tunnel, Y has not indicated that it can
       process ELs, push <TL> onto the packet.  If Y has indicated that
       it can process ELs for the tunnel, push <TL, ELI, EL> onto the
       packet.  X SHOULD put the same TTL and TC fields for the ELI as
       it does for TL.  X MAY choose different values for the TTL and TC
       fields if it is known that the ELI will not be exposed as the top
       label at any point along the LSP (as may happen in cases where
       PHP is used and the ELI and EL are not stripped at the
       penultimate hop (see Section 4.4
<https://datatracker.ietf.org/doc/html/rfc6790#section-4.4>).  The BoS
bit for the ELI MUST
       be zero (i.e., BoS is not set).  The TTL for the EL MUST be zero
       to ensure that it is not used inadvertently for forwarding.  The
       TC for the EL may be any value.  The BoS bit for the EL depends
       on whether or not there are more labels in the label stack.

The EL is not used for forwarding as long as the field is set to 0 which is
a MUST.  However if you reuse the TTL field as the entropy label control
field it will not be set to 0 and thus that could break implementations in
the PHP case where the ELI/EL are exposed.

Also the TTL being set to 0 is different then the field being actually a
Reserved or not applicable field.

I disagree with sentence below in section 2.

   Hence essentially the TTL field of the EL behaves as a reserved field
   which must be set to zero when sent and ignored when received.

The TTL field as I stated MUST be set to 0 so it’s not used for
forwarding.  So it’s not reserved and it’s read by the LSR looking for the
field to be set to 0 so it’s not used for forwarding.  I can’t see how that
won’t break existing implementations.

Kind Regards

Gyan

On Thu, Mar 31, 2022 at 12:30 AM Gyan Mishra <[email-masked]> wrote:

>
> I like Bruno’s idea of reusing the entropy label as indicator of MEH in
> the label stack and is backwards compatibility for devices not supporting
> can continue to use for ECMP load balancing.
>
>> - This proposal allows for carrying 8 Indicators and a slice ID while
>> been backward compatible with egress LER hance providing faster deployment
>> with incremental benefit.
>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 31 Mar 2022 08:29:58 -0700

Hi Wim,
my interpretation of bullet 4 in Section 4.2 RFC 6790 "The TTL for the EL
MUST be zero to ensure that it is not used inadvertently for forwarding"
leads me to believe that any other than zero value in the EL TTL field is
invalid per RFC 6790. Consequently, that packet MUST be dropped. If that is
not breaking the existing network, please help me understand what is it.

Regards,
Greg

On Wed, Mar 30, 2022 at 9:11 PM Henderickx, Wim (Nokia - BE/Antwerp) <
[email-masked]> wrote:

>    - A node that is not upgraded with the SW capabilities to support
>    Bruno’s extension -> will still load-balance as before and might or might
>    not take the bits into account that would be used for the slice ID
>       - I believe we are discussing this case when we discuss “we will
>       break existing  ELI/EL Implementations”. Let’s say even if they
>       take the slice id bit into account, they continue to hash/load-balance on
>       the interface set assigned.
>       - Of course this node is not slice aware as the SW is not
>       supporting this extension, but this has is not related to “breaking
>       existing ELI/EL implementations”.
>       - Even when I did a quick test some HW does not even take into
>       account these bits. So in my view we don’t break existing EL/ELI
>       implementations.
>       - We should really validate the behavior of the existing systems to
>       see the behavior if we make such claims.
>    - A node that is upgraded with the extension of Bruno’s draft will do
>    the right thing. This can easily be resolved with an extension in the
>    Control plane to say which nodes support and don’t support slicing.
>
>
>
> *From: *John E Drake <[email-masked]>
> *Date: *Wednesday, 30 March 2022 at 22:02
> *To: *Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>,
> [email-masked] <[email-masked]>
> *Subject: *RE: [mpls] [Pals]
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Tony Li <[email-masked]>
Date: Thu, 31 Mar 2022 08:43:21 -0700

Gentlebeings,

> On Mar 31, 2022, at 8:29 AM, Greg Mirsky <[email-masked]> wrote:
> 
> my interpretation of bullet 4 in Section 4.2 RFC 6790 "The TTL for the EL MUST be zero to ensure that it is not used inadvertently for forwarding" leads me to believe that any other than zero value in the EL TTL field is invalid per RFC 6790. Consequently, that packet MUST be dropped. If that is not breaking the existing network, please help me understand what is it.

Normally, we write clauses that describe such fields as “must be transmitted as zero and ignored upon receipt” just to avoid such ambiguity. It is unfortunate that RFC 6790 did not utilize this phrase. As it stands, it has certainly specified that the TTL field must be transmitted as zero. Yes, that implies that any other value is invalid. However, that does not guarantee that implementations will check.  In fact, the Law of Lethargy (people will do the least amount of work possible) suggests that most implementations will not check and will simply ignore the TTL field completely.

However, this is not a guarantee. Any design that attempts to reuse this TTL field does run a non-zero risk of being impacted by designs that do check and reject such entries.

IMHO, this by itself is not a serious risk, but risk evaluation is always subjective.

Designs should always acknowledge and articulate the risks that they undertake. It is then up to the collective wisdom of the group to weigh and evaluate the risks, benefits, and tradeoffs when making a decision.

Regards,
Tony

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 31 Mar 2022 08:47:53 -0700

Hi Bruno,
thank you for the expedient response to my notes. Please find a follow-up
in-lined below under the GIM>> tag.

Regards,
Greg

On Thu, Mar 31, 2022 at 12:59 AM <[email-masked]> wrote:

> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Wednesday, March 30, 2022 9:48 PM
> [Bruno] No and so far I’m not even seeing any (negative) scenario in
> John’s email.
>
GIM>>  I hope you can point me to the verbiage in RFC 6790 that supports
the following statement in your draft:
   Hence essentially the TTL field of the EL behaves as a reserved field
   which must be set to zero when sent and ignored when received.
I can only find the following text in Section 4.2 RFC 6790:
       The TTL for the EL MUST be zero
       to ensure that it is not used inadvertently for forwarding.
which says nothing about ignoring the EL TTL field value. Quite the
opposite, my understanding is that the value must be checked, and if it is
non-zero, the packet must be discarded. Based on that, I don't see how the
extended interpretation of ELI can be safely deployed without any
extensions in the control plane.

>
>    - As I understand the draft, using EL and Slice ID in the same stack
>    is mutually exclusive. If that is the case, how entropy can be created
>    within the particular network slice?
>
> [Bruno] Please reread the draft and more specifically sections 3 and 3.1.
> You are not correct: the use of EMCP entropy and slice ID is not mutually
> exclusive, in the stack but even in a single EL. In short, one part of the
> EL is used to encode the slide ID and the remaining part carry the entropy
> number. Legacy transit LSR may use the whole EL transparently as the whole
> EL _*is*_ an entropy value which may be used for load-balancing (how that
> EL value is constructed by the ingress is not the concern of the transit).
>
GIM>> Thank you for clarifying this use case for me. As that is the case, I
believe that there's even more reason for extensions in the control plane
to signal how the EL field is used.

>
>    - I think that you've agreed that the draft does not address the requirements
>    for MIAD
>       in draft-jags-mpls-ext-hdr. I think that is not guaranteed that that would
>       - And if draft-jags-mpls-ext-hdr continues with the solution based
>       on the re-definition of the ELI, it appears to me that all Tony's concerns
>       are valid.
>
> [Bruno] I’m not sure what anything new your are bringing in addition to
> Tony’s analysis and email. So I’ll just copy past the same reply:
>
> There are two steps:
>
> backward compatible with egress LER hence providing faster deployment with
> incremental benefit.
>
GIM>> As I don't agree with your assumption that EL TTL value must be
ignored and thus can be re-used for ADIs. I find that there are only three
flags that can be safely used with your proposal. And that is without any
ISD support.

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 31 Mar 2022 08:59:44 -0700

I agree that the wording in RFC 6790 is open to interpretation. It is quite
possible that a more pedantic developer would put a check for the zero
value of the EL TTL field "to ensure that it is not used inadvertently for
forwarding". Is it possible to check all existing implementations that
support ELI/EL? And I'm surprised that the authors of the draft claim
precisely the opposite:
   Hence essentially the TTL field of the EL behaves as a reserved field
   which must be set to zero when sent and ignored when received.

Regards,
Greg

On Thu, Mar 31, 2022 at 8:43 AM Tony Li <[email-masked]> wrote:

> Normally, we write clauses that describe such fields as “must be
> transmitted as zero and ignored upon receipt” just to avoid such ambiguity.
> It is unfortunate that RFC 6790 did not utilize this phrase. As it stands,
> it has certainly specified that the TTL field must be transmitted as zero.
> Yes, that implies that any other value is invalid. However, that does not
> guarantee that implementations will check.  In fact, the Law of Lethargy
> (people will do the least amount of work possible) suggests that most
> implementations will not check and will simply ignore the TTL field
> completely.
>
> However, this is not a guarantee. Any design that attempts to reuse this
> TTL field does run a non-zero risk of being impacted by designs that do
> check and reject such entries.
>
> Designs should always acknowledge and articulate the risks that they
> undertake. It is then up to the collective wisdom of the group to weigh and
> evaluate the risks, benefits, and tradeoffs when making a decision.
>
> Regards,
> Tony
>
>

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 31 Mar 2022 18:21:58 +0000

This is my point and this is what I verified on some systems that don’t care about the TTL and hence work as is, because the ambiguity in the RFC.

Now also we mix 2 discussions points in my view. One is backward compatibility and 2nd is leveraging current HW to support the extensions.
For me the 2nd is also very important as this is actually an important characteristic for the speed at which we can adopt solutions. If we can get extensions with the current HW this is a big pro of the proposals out there. This is why I am advocating to adopt Bruno’s draft as it allows to leverage the existing HW assets as is. Of course we need to do a SW upgrade, but this is still faster than swapping HW is most cases.

From: Greg Mirsky <[email-masked]>
Date: Thursday, 31 March 2022 at 17:59
To: Tony Li <[email-masked]>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>, detnet WG <[email-masked]>, mpls <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)
I agree that the wording in RFC 6790 is open to interpretation. It is quite possible that a more pedantic developer would put a check for the zero value of the EL TTL field "to ensure that it is not used inadvertently for forwarding". Is it possible to check all existing implementations that support ELI/EL? And I'm surprised that the authors of the draft claim precisely the opposite:
   Hence essentially the TTL field of the EL behaves as a reserved field
   which must be set to zero when sent and ignored when received.

Regards,
Greg

On Thu, Mar 31, 2022 at 8:43 AM Tony Li <[email-masked]<mailto:[email-masked]>> wrote:

Gentlebeings,

On Mar 31, 2022, at 8:29 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Tony

---

From: Tony Li <[email-masked]>
Date: Thu, 31 Mar 2022 11:34:13 -0700

Wim,

> For me the 2nd is also very important as this is actually an important characteristic for the speed at which we can adopt solutions. If we can get extensions with the current HW this is a big pro o…

Implicit in this is the assumption that a hardware upgrade is required. That is not at all clear. In fact, that runs counter to my understanding of what’s in the field: almost everything out there has some level of microcode capability.

If that’s accurate, then we are a software upgrade away, regardless of which solution we select. The true hardware limitations will arise as we define more complex actions, which require more data that is not readily accessible, either because there is too much in-stack data or access to the post-stack data that cannot be done without a performance penalty, if at all.

In short, Bruno’s draft offers us limitations that we want to avoid, and advantages that seem dubious.

Regards,
Tony

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 31 Mar 2022 18:47:35 +0000

Tony, inline

From: Tony Li <[email-masked]> on behalf of Tony Li <[email-masked]>
Date: Thursday, 31 March 2022 at 20:34
To: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>
Cc: Greg Mirsky <[email-masked]>, detnet WG <[email-masked]>, mpls <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

Wim,

WH> not all HW has this capability or is very constraint without another compromise. This is in my view an important consideration to select the proposal

WH> I don’t believe this is true with what we have on the table right now and this is why restate to start with Bruno’s proposal to start and go to a more advanced solution that can be supported with new HW capabiltiies.

Regards,
Tony

---

From: Haoyu Song <[email-masked]>
Date: Thu, 31 Mar 2022 19:51:48 +0000

Hi Wim,

I think introducing a new SPL as indicator can also leverage the existing hardware and requires only software upgrade. What's more important is how the new functions will be supported, but that's independent of how the indicator is specified.

Best,
Haoyu

From: mpls <[email-masked]> On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: Thursday, March 31, 2022 11:22 AM
To: Greg Mirsky <[email-masked]>; Tony Li <[email-masked]>
Cc: mpls <[email-masked]>; detnet WG <[email-masked]>; [email-masked]
Subject: Re: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

This is my point and this is what I verified on some systems that don't care about the TTL and hence work as is, because the ambiguity in the RFC.

Now also we mix 2 discussions points in my view. One is backward compatibility and 2nd is leveraging current HW to support the extensions.
For me the 2nd is also very important as this is actually an important characteristic for the speed at which we can adopt solutions. If we can get extensions with the current HW this is a big pro of the proposals out there. This is why I am advocating to adopt Bruno's draft as it allows to leverage the existing HW assets as is. Of course we need to do a SW upgrade, but this is still faster than swapping HW is most cases.

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 31 March 2022 at 17:59
To: Tony Li <[email-masked]<mailto:[email-masked]>>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>, detnet WG <[email-masked]<mailto:[email-masked]>>, mpls <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)
I agree that the wording in RFC 6790 is open to interpretation. It is quite possible that a more pedantic developer would put a check for the zero value of the EL TTL field "to ensure that it is not used inadvertently for forwarding". Is it possible to check all existing implementations that support ELI/EL? And I'm surprised that the authors of the draft claim precisely the opposite:
   Hence essentially the TTL field of the EL behaves as a reserved field
   which must be set to zero when sent and ignored when received.

Regards,
Greg

Gentlebeings,

Normally, we write clauses that describe such fields as "must be transmitted as zero and ignored upon receipt" just to avoid such ambiguity. It is unfortunate that RFC 6790 did not utilize this phrase. As it stands, it has certainly specified that the TTL field must be transmitted as zero. Yes, that implies that any other value is invalid. However, that does not guarantee that implementations will check.  In fact, the Law of Lethargy (people will do the least amount of work possible) suggests that most implementations will not check and will simply ignore the TTL field completely.

Regards,
Tony

---

From: Tony Li <[email-masked]>
Date: Thu, 31 Mar 2022 13:40:56 -0700

Wim,

> WH> not all HW has this capability or is very constraint without another compromise. This is in my view an important consideration to select the proposal

Understood, but without clear evidence of these limitations, it’s somewhat hard to justify limiting our approach.  The commonality of the hardware in relevant locations is key.  

If we find that Brand X has hardware limitations and there are a million deployed throughout service providers everywhere, that is worth noting.

If we find that Brand Y has hardware limitations, but is only deployed in 10 home offices world wide, it is inconsequential.

As always, we have to make tradeoffs using the data that we have at hand.  

> WH> I don’t believe this is true with what we have on the table right now and this is why restate to start with Bruno’s proposal to start and go to a more advanced solution that can be supported wi…

Well, I would appreciate hard data.  I have had a hand in MPLS since day one and have seen many hardware designs along the way. There are many hardware platforms that have limitations on label stack depth. That is definitely a concern, but that is already an issue for the entropy label today.  I’m unaware of any hardware implementation that cannot support the use of a different bSPL.  I welcome education, but without clear contradictory evidence, not just opinion or unsupported assertion, the data that I have suggests that we effectively have a small Turing-equivalent processor operating on some significant chunk of the label stack.

Tony

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 31 Mar 2022 19:25:26 -0400

Greg & Tony

+1

I am completely in agreement with your findings.

Kind Regards

Gyan
On Thu, Mar 31, 2022 at 12:01 PM Greg Mirsky <[email-masked]> wrote:

> I agree that the wording in RFC 6790 is open to interpretation. It is
> quite possible that a more pedantic developer would put a check for the
> zero value of the EL TTL field "to ensure that it is not used inadvertently
> for forwarding". Is it possible to check all existing implementations that
-- 

*Gyan Mishra*

*M 301 502-1347*