Subject: [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id

From: Greg Mirsky <[email-masked]>
Date: Thu, 13 Jan 2022 14:41:06 -0800

Hi Bruno, et al.
Thank you for presenting this work at the MPLS Open DT meeting today. Below
please find the summary of my comments and questions with the additional
thoughts that came after we've closed the call. I greatly appreciate the
consideration and opinions of the authors and the group.

   - Compatibility with nodes that support only RFC 6790.
      - If the proposed indicators are used to signal the presence of an
      ISD, that seems to create a problem for an RFC6790-only node as it might
      not be able to process the ISD.
      - If one of the indicators is to be used to signal the presence of
      the extension, that, similarly to the scenario above, might not be
      correctly processed by an RFC6790-only node.
   - Scaling
      - If the proposed method to signal the ancillary data is used in, for
      example, a strict explicit routing environment, the Entropy Label is not
      needed. If that is the case, using the indicators, as described in the
      draft, seems to waste 20 bits in a label element compared to the
mechanism
      proposed in draft-kompella-mpls-mspl4fa.

Regards,
Greg

---

From: <[email-masked]>
Date: Mon, 17 Jan 2022 16:24:34 +0000

Hi Greg, all

Greg, thanks for taking the time to read the draft and comment.

WG, for context, we are discussing a subset of the draft: the ability to advertise indicator as part of the existing Entropy Label TTL as described in section 2 of the draft (it's 1 page):
https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-entropy-label-id-02#section-2

Please see inline [Bruno]

Orange Restricted
From: mpls <[email-masked]> On Behalf Of Greg Mirsky
Sent: Thursday, January 13, 2022 11:41 PM
To: mpls <[email-masked]>; [email-masked]; DetNet WG <[email-masked]>
Subject: [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id

Hi Bruno, et al.
Thank you for presenting this work at the MPLS Open DT meeting today. Below please find the summary of my comments and questions with the additional thoughts that came after we've closed the call. I greatly appreciate the consideration and opinions of the authors and the group.

  *   Compatibility with nodes that support only RFC 6790.

     *   If the proposed indicators are used to signal the presence of an ISD, that seems to create a problem for an RFC6790-only node as it might not be able to process the ISD.
[Bruno]
- Draft(*) extends the use of the Entropy Label TTL field which is essentially specified as a Reserved field in RFC 6790. Hence draft is backward compatible with RFC 6790.
- Draft does not specify ISD so this is out of scope of this draft. That been said:
-  You are right that before sending ISD in a new extension, the capability for the receiver/egress to support this ISD needs to be known by the sender. This is priori required by all ISD solution.
- You seemed to assume that ISD are always necessary but IMHO indicators and ISD are two different extensions and Indicators may be used without ISD extensions .e.g., cf sections 4, 5, 3 of the draft

     *   If one of the indicators is to be used to signal the presence of the extension, that, similarly to the scenario above, might not be correctly processed by an RFC6790-only node.
[Bruno] idem

  *   Scaling

     *   If the proposed method to signal the ancillary data is used in, for example, a strict explicit routing environment, the Entropy Label is not needed. If that is the case, using the indicators, as described in the draft, seems to waste 20 bits in a label element compared to the mechanism proposed in draft-kompella-mpls-mspl4fa.
[Bruno] And for all other cases, the scaling is very good as we carry indicators with zero extra label. So the net benefit is dependent of the relative usage of strict explicit routing traffic vs traffic which can be ECMP. In my environment, the latter is much more prevalent, hence the net benefit is positive.
PS : by < draft > I mean section 2 of the draft as this is the scope of the discussion.
Regards,
-Bruno
Regards,
Greg

_________________________________________________________________________________________________________________________

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: Greg Mirsky <[email-masked]>
Date: Thu, 20 Jan 2022 17:08:55 -0800

Hi Bruno,
thank you for your kind consideration of my comments. Please find follow-up
notes in-line below under the GIM>> tag.

Regards,
Greg

On Mon, Jan 17, 2022 at 8:24 AM <[email-masked]> wrote:

> WG, for context, we are discussing a subset of the draft: the ability to
> advertise indicator as part of the existing Entropy Label TTL as described
> in section 2 of the draft (it’s 1 page):
>
>
> *From:* mpls <[email-masked]> *On Behalf Of *Greg Mirsky
> *Sent:* Thursday, January 13, 2022 11:41 PM
> *To:* mpls <[email-masked]>; [email-masked]; DetNet WG <[email-masked]>
> *Subject:* [mpls] Continuing with my comments on
> draft-decraene-mpls-slid-encoded-entropy-label-id
>
>
>
> Hi Bruno, et al.
>
> Thank you for presenting this work at the MPLS Open DT meeting today.
> Below please find the summary of my comments and questions with the
> additional thoughts that came after we've closed the call. I greatly
> appreciate the consideration and opinions of the authors and the group.
>
> - Draft(*) extends the use of the Entropy Label TTL field which is
> essentially specified as a Reserved field in RFC 6790. Hence draft is
> backward compatible with RFC 6790.
>
GIM>> I agree, that if the mechanism is limited to re-use of the TTL
field of the label element that includes the entropy label, then there are
no possible issues. But then, how useful is a mechanism that allows for
only seven indicators of processing instructions? Of course, if the model
does not support a combination of instructions, then the new field might be
viewed not as a set of flags but as a scalar with each value defining a
different processing type.

- Draft does not specify ISD so this is out of scope of this draft. That
> been said:
>
> -  You are right that before sending ISD in a new extension, the
> capability for the receiver/egress to support this ISD needs to be known by
> the sender. This is priori required by all ISD solution.
>
> - You seemed to assume that ISD are always necessary but IMHO indicators
> and ISD are two different extensions and Indicators may be used without ISD
> extensions .e.g., cf sections 4, 5, 3 of the draft
>
GIM>> I agree, that in some scenarios the ability to signal processing in a
label stack is sufficient and useful. Though, having a method of doing a
subset of what can be done with Ancillary Data and Action indication seems
like an unnecessary overlap.

>
>    - If one of the indicators is to be used to signal the presence of the
>       extension, that, similarly to the scenario above, might not be correctly
>       processed by an RFC6790-only node.
>
> [Bruno] idem
>
>    - Scaling
>
>
>       draft, seems to waste 20 bits in a label element compared to the mechanism
> [Bruno] And for all other cases, the scaling is very good as we carry
> indicators with zero extra label. So the net benefit is dependent of the
> relative usage of strict explicit routing traffic vs traffic which can be
> ECMP. In my environment, the latter is much more prevalent, hence the net
> benefit is positive.
>
GIM>> I agree that there are cases and scenarios when seven indicators can
solve the operator's immediate problems. Though I believe that a
future-proof solution is preferable.

PS : by « draft » I mean section 2 of the draft as this is the scope of the
> discussion.

---

From: <[email-masked]>
Date: Fri, 21 Jan 2022 17:57:42 +0000

Hi Greg,

Thank you for the follow up. Please see inline [Bruno2]

Orange Restricted
From: Greg Mirsky <[email-masked]>
Sent: Friday, January 21, 2022 2:09 AM
To: DECRAENE Bruno INNOV/NET <[email-masked]>
Cc: mpls <[email-masked]>; [email-masked]; DetNet WG <[email-masked]>
Subject: Re: [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id

Hi Bruno,
thank you for your kind consideration of my comments. Please find follow-up notes in-line below under the GIM>> tag.

Regards,
Greg

On Mon, Jan 17, 2022 at 8:24 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg, all

Orange Restricted
From: mpls <[email-masked]<mailto:[email-masked]>> On Behalf Of Greg Mirsky
Sent: Thursday, January 13, 2022 11:41 PM
To: mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; DetNet WG <[email-masked]<mailto:[email-masked]>>
Subject: [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id

Hi Bruno, et al.

     *   If the proposed indicators are used to signal the presence of an ISD, that seems to create a problem for an RFC6790-only node as it might not be able to process the ISD.
[Bruno]
- Draft(*) extends the use of the Entropy Label TTL field which is essentially specified as a Reserved field in RFC 6790. Hence draft is backward compatible with RFC 6790.
GIM>> I agree, that if the mechanism is limited to re-use of the TTL field of the label element that includes the entropy label, then there are no possible issues. But then, how useful is a mechanism that allows for only seven indicators of processing instructions? Of course, if the model does not support a combination of instructions, then the new field might be viewed not as a set of flags but as a scalar with each value defining a different processing type.
[Bruno2] Thank you for acknowledging that it would work. In terms of possible usages, the draft lists 3 ones in sections 3, 4 and 5.

- Draft does not specify ISD so this is out of scope of this draft. That been said:
-  You are right that before sending ISD in a new extension, the capability for the receiver/egress to support this ISD needs to be known by the sender. This is priori required by all ISD solution.
- You seemed to assume that ISD are always necessary but IMHO indicators and ISD are two different extensions and Indicators may be used without ISD extensions .e.g., cf sections 4, 5, 3 of the draft
GIM>> I agree, that in some scenarios the ability to signal processing in a label stack is sufficient and useful. Though, having a method of doing a subset of what can be done with Ancillary Data and Action indication seems like an unnecessary overlap.
[Bruno2] Thank you for the agreement. If one/a use case wants to advertise more data, it's possible to extend the proposal (actually one should be published shortly)

  *   Scaling

     *   If the proposed method to signal the ancillary data is used in, for example, a strict explicit routing environment, the Entropy Label is not needed. If that is the case, using the indicators, as described in the draft, seems to waste 20 bits in a label element compared to the mechanism proposed in draft-kompella-mpls-mspl4fa.
[Bruno] And for all other cases, the scaling is very good as we carry indicators with zero extra label. So the net benefit is dependent of the relative usage of strict explicit routing traffic vs traffic which can be ECMP. In my environment, the latter is much more prevalent, hence the net benefit is positive.
GIM>> I agree that there are cases and scenarios when seven indicators can solve the operator's immediate problems. Though I believe that a future-proof solution is preferable.
[Bruno2] If needed, I believe that this proposal may be extended for the use cases that would require more. I see no reason for such extension to not be equally future-proof.

Regards,
--Bruno

Thank you.

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 22 Jan 2022 13:34:00 -0800

Hi Bruno,
thank you for your detailed response to my notes. I am looking forward to
the new version of the draft and continued discussion.

Regards,
Greg

On Fri, Jan 21, 2022 at 9:57 AM <[email-masked]> wrote:

> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Friday, January 21, 2022 2:09 AM
> *To:* DECRAENE Bruno INNOV/NET <[email-masked]>
> *Cc:* mpls <[email-masked]>; [email-masked]; DetNet WG <[email-masked]>
> *Subject:* Re: [mpls] Continuing with my comments on
> thank you for your kind consideration of my comments. Please
> find follow-up notes in-line below under the GIM>> tag.
>
>
>
> Regards,
>
> Greg
>
>
>
> [Bruno2] Thank you for acknowledging that it would work. In terms of
> possible usages, the draft lists 3 ones in sections 3, 4 and 5.
>
>
>
> GIM>> I agree, that in some scenarios the ability to signal processing in
> a label stack is sufficient and useful. Though, having a method of doing a
> [Bruno2] Thank you for the agreement. If one/a use case wants to
> advertise more data, it’s possible to extend the proposal (actually one
> should be published shortly)
>
>
> [Bruno2] If needed, I believe that this proposal may be extended for the
> use cases that would require more. I see no reason for such extension to
> not be equally future-proof.
>
>
>
> Regards,
>
> --Bruno
>
>
>
> PS : by « draft » I mean section 2 of the draft as this is the scope of
> the discussion.
>
> Regards,
>
> -Bruno
>
> Regards,
>
> Greg
>

---

From: Loa Andersson <[email-masked]>
Date: Wed, 26 Jan 2022 10:11:03 +0800

Bruno, Greg, wg,

The Open DT are working on a method for Indicators and Ancillary data, 
based mostly on draft-kompella-mpls-mspl4fa and 
draft-bocci-mpls-miad-adi-requirements.

why is it obvious that the "SPRING version" should not be part of that 
solution?

Kireeti,

BTW draft-kompella-mpls-mspl4fa has expired, plz revive.

/Loa

On 23/01/2022 05:34, Greg Mirsky wrote:
> Hi Bruno,
> thank you for your detailed response to my notes. I am looking 
> forward to the new version of the draft and continued discussion.
> 
> Regards,
> Greg
> 
> On Fri, Jan 21, 2022 at 9:57 AM <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Greg,____
> 
>     __ __
> 
>     Thank you for the follow up. Please see inline [Bruno2]____
> 
>     __ __
> 
>     __ __
> 
>     Orange Restricted____
> 
>     *From:*Greg Mirsky <[email-masked]
>     <mailto:[email-masked]>>
>     *To:* DECRAENE Bruno INNOV/NET <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* mpls <[email-masked] <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>; DetNet WG <[email-masked]
>     <mailto:[email-masked]>>
>     draft-decraene-mpls-slid-encoded-entropy-label-id____
> 
>     __ __
> 
>     Hi Bruno,____
> 
>     find follow-up notes in-line below under the GIM>> tag.____
> 
>     __ __
> 
>     Regards,____
> 
>     Greg____
> 
>     __ __
> 
>     On Mon, Jan 17, 2022 at 8:24 AM <[email-masked]
>     <mailto:[email-masked]>> wrote:____
> 
>         Hi Greg, all____
> 
>         ____
> 
>         Greg, thanks for taking the time to read the draft and comment.____
> 
>         ____
> 
>         WG, for context, we are discussing a subset of the draft: the
>         ability to advertise indicator as part of the existing Entropy
>         Label TTL as described in section 2 of the draft (it’s 1 page):____
> 
>         <https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-entropy-label-id-02#section-2>____
> 
>         ____
> 
>         Please see inline [Bruno]____
> 
>         ____
> 
>         ____
> 
>         Orange Restricted____
> 
>         *From:* mpls <[email-masked]
>         <mailto:[email-masked]>> *On Behalf Of *Greg Mirsky
>         *To:* mpls <[email-masked] <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>; DetNet WG <[email-masked]
>         <mailto:[email-masked]>>
>         draft-decraene-mpls-slid-encoded-entropy-label-id____
> 
>         ____
> 
>         Hi Bruno, et al.____
> 
>         Thank you for presenting this work at the MPLS Open DT meeting
>         today. Below please find the summary of my comments and
>         questions with the additional thoughts that came after we've
>         closed the call. I greatly appreciate the consideration and
>         opinions of the authors and the group.____
> 
>           * Compatibility with nodes that support only RFC 6790.____
> 
>               o If the proposed indicators are used to signal the
>                 presence of an ISD, that seems to create a problem for
>                 an RFC6790-only node as it might not be able to process
>                 the ISD.____
> 
>         [Bruno]____
> 
>         - Draft(*) extends the use of the Entropy Label TTL field which
>         is essentially specified as a Reserved field in RFC 6790. Hence
>         draft is backward compatible with RFC 6790.____
> 
>     field of the label element that includes the entropy label, then
>     there are no possible issues. But then, how useful is a mechanism
>     that allows for only seven indicators of processing instructions? Of
>     course, if the model does not support a combination of instructions,
>     then the new field might be viewed not as a set of flags but as a
>     scalar with each value defining a different processing type.____
> 
>     possible usages, the draft lists 3 ones in sections 3, 4 and 5. ____
> 
>     __ __
> 
>         - Draft does not specify ISD so this is out of scope of this
>         draft. That been said:____
> 
>         capability for the receiver/egress to support this ISD needs to
>         be known by the sender. This is priori required by all ISD
>         solution.____
> 
>         - You seemed to assume that ISD are always necessary but IMHO
>         indicators and ISD are two different extensions and Indicators
>         may be used without ISD extensions .e.g., cf sections 4, 5, 3 of
>         the draft____
> 
>     GIM>> I agree, that in some scenarios the ability to signal
>     processing in a label stack is sufficient and useful. Though, having
>     a method of doing a subset of what can be done with Ancillary Data
>     and Action indication seems like an unnecessary overlap.____
> 
>     advertise more data, it’s possible to extend the proposal (actually
>     one should be published shortly)____
> 
>               o If one of the indicators is to be used to signal the
>                 presence of the extension, that, similarly to the
>                 scenario above, might not be correctly processed by an
>                 RFC6790-only node.____
> 
>         [Bruno] idem ____
> 
>           * Scaling____
> 
>               o If the proposed method to signal the ancillary data is
>                 used in, for example, a strict explicit routing
>                 environment, the Entropy Label is not needed. If that is
>                 the case, using the indicators, as described in the
>                 draft, seems to waste 20 bits in a label element
>                 compared to the mechanism proposed in
>                 draft-kompella-mpls-mspl4fa.____
> 
>         [Bruno] And for all other cases, the scaling is very good as we
>         carry indicators with zero extra label. So the net benefit is
>         dependent of the relative usage of strict explicit routing
>         traffic vs traffic which can be ECMP. In my environment, the
>         latter is much more prevalent, hence the net benefit is
>         positive.____
> 
>     GIM>> I agree that there are cases and scenarios when seven
>     indicators can solve the operator's immediate problems. Though I
>     believe that a future-proof solution is preferable.____
> 
>     [Bruno2] If needed, I believe that this proposal may be extended for
>     the use cases that would require more. I see no reason for such
>     extension to not be equally future-proof.____
> 
>     __ __
> 
>     Regards,____
> 
>     --Bruno____
> 
>         __ __
> 
>         PS : by « draft » I mean section 2 of the draft as this is the
>         scope of the discussion.____
> 
>         Regards,____
> 
>         -Bruno____
> 
>         Regards,____
> 
>         Greg____
> 
>         _____________________________________________________________________________________________________________________________
> 
>         __  __
> 
>         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.____
> 
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

-- 
Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: <[email-masked]>
Date: Thu, 27 Jan 2022 09:58:29 +0000

Loa,

> From: Loa Andersson <[email-masked]>
> Sent: Wednesday, January 26, 2022 3:11 AM
> 
> Bruno, Greg, wg,
> 

Are you saying that the solution (draft-kompella-mpls-mspl4fa) has been selected and all others disregarded?

> why is it obvious that the "SPRING version" should not be part of that

What "SPRING version" are you referring to?

https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-entropy-label-id
and 
https://datatracker.ietf.org/doc/html/draft-jags-mpls-ext-hdr-entropy-lbl

Are targeting the MPLS WG and are not specific to SPRING as far as I can remember.

--Bruno
 
> ______________________________________________________________________
> _______________________________________________________
> >
> >         __  __
> >
> >         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,____
> >
> >         This message and its attachments may contain confidential or privileged
> information that may be protected by law;____
> >
> ______________________________________________________________________
> ___________________________________________________
> >
> >     Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> >     a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> >     This message and its attachments may contain confidential or privileged
> information that may be protected by law;

Orange Restricted

---

From: <[email-masked]>
Date: Thu, 27 Jan 2022 10:03:11 +0000

Hi Greg,

Thank you for the useful discussion (at least to me) on indicators within the stack as proposed by section 2 of draft-decraene-mpls-slid-encoded-entropy-label-id
The extension that I've been referring to encode data has just been published: https://datatracker.ietf.org/doc/html/draft-jags-mpls-ext-hdr-entropy-lbl

Review is equally welcomed.

Regards,
--Bruno

Orange Restricted
Sent: Saturday, January 22, 2022 10:34 PM

Hi Bruno,
thank you for your detailed response to my notes. I am looking forward to the new version of the draft and continued discussion.

Regards,
Greg

On Fri, Jan 21, 2022 at 9:57 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Orange Restricted
From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Friday, January 21, 2022 2:09 AM
To: DECRAENE Bruno INNOV/NET <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; DetNet WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id

Hi Bruno,

Regards,
Greg

Orange Restricted

Hi Bruno, et al.

  *   Scaling

Regards,
--Bruno

Thank you.

Thank you.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 27 Jan 2022 22:44:48 +0800

Bruno, et.al,

My apologies.

Going back and reading my mail, I can understand why you understand it 
as you do. If I received a similar mail I probably would have done the same.

No document has yet been picked as the solution. It is way to early to 
do so, as a matter of fact I don't think we ever will. What I see we 
need to do now is consolidate, usecase-, requirement- and framework, and 
based on that start merging solutions documents, with the intent to in 
the end converge (if possible) on one single document.

/Loa

On 27/01/2022 17:58, [email-masked] wrote:
> Pals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pals