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

[Loa Andersson <[e-mail]>]

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, [e-mail] wrote:
> Loa,
> 
>> From: Loa Andersson <[e-mail]>
>> Sent: Wednesday, January 26, 2022 3:11 AM
>>
>> 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.
> 
> 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
>> solution?
> 
> 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
>   
>> 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]
> 
> Orange Restricted
> 
> _________________________________________________________________________________________________________________________
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pals

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