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.

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

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

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