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

[Loa Andersson <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Hi Greg,____
> 
>     __ __
> 
>     Thank you for the follow up. Please see inline [Bruno2]____
> 
>     __ __
> 
>     __ __
> 
>     Orange Restricted____
> 
>     *From:*Greg Mirsky <[e-mail]
>     <mailto:[e-mail]>>
>     *Sent:* Friday, January 21, 2022 2:09 AM
>     *To:* DECRAENE Bruno INNOV/NET <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:* mpls <[e-mail] <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>; DetNet WG <[e-mail]
>     <mailto:[e-mail]>>
>     *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 <[e-mail]
>     <mailto:[e-mail]>> 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
>         <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 <[e-mail]
>         <mailto:[e-mail]>> *On Behalf Of *Greg Mirsky
>         *Sent:* Thursday, January 13, 2022 11:41 PM
>         *To:* mpls <[e-mail] <mailto:[e-mail]>>; [e-mail]
>         <mailto:[e-mail]>; DetNet WG <[e-mail]
>         <mailto:[e-mail]>>
>         *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.____
> 
>               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.____
> 
>     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)____
> 
>               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.____
> 
>     _________________________________________________________________________________________________________________________
> 
>     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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet

-- 
Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]