[prev in list] [next in list] [prev in thread] [next in thread]
List: mpls
Subject: Re: [mpls] [Pals] [Detnet] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-l
From: Loa Andersson <loa () pi ! nu>
Date: 2022-01-27 14:44:48
Message-ID: 69744e7b-3c9c-6f4f-df85-c8bdcb219422 () pi ! nu
[Download RAW message or body]
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, bruno.decraene@orange.com wrote:
> Loa,
>
> > From: Loa Andersson <loa@pi.nu>
> > 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 <bruno.decraene@orange.com
> > > <mailto:bruno.decraene@orange.com>> wrote:
> > >
> > > Hi Greg,____
> > >
> > > __ __
> > >
> > > Thank you for the follow up. Please see inline [Bruno2]____
> > >
> > > __ __
> > >
> > > __ __
> > >
> > > Orange Restricted____
> > >
> > > *From:*Greg Mirsky <gregimirsky@gmail.com
> > > <mailto:gregimirsky@gmail.com>>
> > > *Sent:* Friday, January 21, 2022 2:09 AM
> > > *To:* DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com
> > > <mailto:bruno.decraene@orange.com>>
> > > *Cc:* mpls <mpls@ietf.org <mailto:mpls@ietf.org>>; pals@ietf.org
> > > <mailto:pals@ietf.org>; DetNet WG <detnet@ietf.org
> > > <mailto:detnet@ietf.org>>
> > > *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 <bruno.decraene@orange.com
> > > <mailto:bruno.decraene@orange.com>> 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 <mpls-bounces@ietf.org
> > > <mailto:mpls-bounces@ietf.org>> *On Behalf Of *Greg Mirsky
> > > *Sent:* Thursday, January 13, 2022 11:41 PM
> > > *To:* mpls <mpls@ietf.org <mailto:mpls@ietf.org>>; pals@ietf.org
> > > <mailto:pals@ietf.org>; DetNet WG <detnet@ietf.org
> > > <mailto:detnet@ietf.org>>
> > > *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
> > > detnet@ietf.org
> > > https://www.ietf.org/mailman/listinfo/detnet
> >
> > --
> > Loa Andersson email: loa@pi.nu
> > Senior MPLS Expert loa.pi.nu@gmail.com
> > 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
> Pals@ietf.org
> https://www.ietf.org/mailman/listinfo/pals
--
Loa Andersson email: loa@pi.nu
Senior MPLS Expert loa.pi.nu@gmail.com
Bronze Dragon Consulting phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic