Re: [Detnet] [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id
Loa Andersson <[email protected]>
| Newsgroups | gmane.ietf.pwe3,gmane.ietf.mpls |
|---|---|
| Message-ID | <[email protected]> |
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 protected] wrote: > Loa, > >> From: Loa Andersson <[email protected]> >> 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 <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi Greg,____ >>> >>> __ __ >>> >>> Thank you for the follow up. Please see inline [Bruno2]____ >>> >>> __ __ >>> >>> __ __ >>> >>> Orange Restricted____ >>> >>> *From:*Greg Mirsky <[email protected] >>> <mailto:[email protected]>> >>> *Sent:* Friday, January 21, 2022 2:09 AM >>> *To:* DECRAENE Bruno INNOV/NET <[email protected] >>> <mailto:[email protected]>> >>> *Cc:* mpls <[email protected] <mailto:[email protected]>>; [email protected] >>> <mailto:[email protected]>; DetNet WG <[email protected] >>> <mailto:[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] >>> <mailto:[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 >>> <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] >>> <mailto:[email protected]>> *On Behalf Of *Greg Mirsky >>> *Sent:* Thursday, January 13, 2022 11:41 PM >>> *To:* mpls <[email protected] <mailto:[email protected]>>; [email protected] >>> <mailto:[email protected]>; DetNet WG <[email protected] >>> <mailto:[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.____ >>> >>> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/detnet >> >> -- >> Loa Andersson email: [email protected] >> Senior MPLS Expert [email protected] >> Bronze Dragon Consulting phone: +46 739 81 21 64 > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/pals -- Loa Andersson email: [email protected] Senior MPLS Expert [email protected] Bronze Dragon Consulting phone: +46 739 81 21 64 _______________________________________________ Pals mailing list [email protected] https://www.ietf.org/mailman/listinfo/pals