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

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 protected]> wrote:

> Hi Greg,
>
>
>
> Thank you for the follow up. Please see inline [Bruno2]
>
>
>
>
>
> Orange Restricted
>
> *From:* Greg Mirsky <[email protected]>
> *Sent:* Friday, January 21, 2022 2:09 AM
> *To:* DECRAENE Bruno INNOV/NET <[email protected]>
> *Cc:* mpls <[email protected]>; [email protected]; DetNet WG <[email protected]>
> *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 protected]> 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 protected]> *On Behalf Of *Greg Mirsky
> *Sent:* Thursday, January 13, 2022 11:41 PM
> *To:* mpls <[email protected]>; [email protected]; DetNet WG <[email protected]>
> *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.
>
> 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)
>
>
>    - 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.
>
> 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.
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>

_______________________________________________
Pals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pals