Re: [Idr] WG adoption call for draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)

[Shawn Zhang <[e-mail]>]

Hi Susan,

Support the WG adoption.

/Shawn

John Scudder <jgs=[e-mail]> 于2022年9月20日周二 01:28写道：

> Hi Folks,
>
> I’m having a hard time untangling the conversation from the various
> deeply-nested quotes with different quoting conventions, but I think the
> only thing for me to address right now is to reiterate my earlier response
> from September 6 regarding implementation:
>
> > - I can tell you right now that there are not implementations of this
> version of the draft, strictly speaking, because it calls for a new path
> attribute, which hasn’t been allocated. [*]
> > - On the other hand, as the introduction discusses, Juniper’s earlier
> implementation, on top of a different attribute number but otherwise
> substantially the same, has been in the field for quite some time. I will
> be surprised if there’s a second such implementation, but there are many
> things I don’t know. :-)
>
>
> Of course I can’t speak for anyone else.
>
> —John
>
> > On Sep 16, 2022, at 12:32 PM, [e-mail] wrote:
> >
> > Sue,
> >
> > Please see inline [Bruno2]
> >
> >
> > Orange Restricted
> > From: Idr <[e-mail]> On Behalf Of Susan Hares
> > Sent: Friday, September 16, 2022 2:47 PM
> > To: DECRAENE Bruno INNOV/NET <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: [Idr] WG adoption call for
> draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)
> >
> > Bruno:
> >
> > I’m sorry that part of the email did not come through.  See below along
> with comments.
> >
> > From: [e-mail] <[e-mail]>
> > Sent: Friday, September 16, 2022 8:29 AM
> > To: Susan Hares <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > Subject: RE: [Idr] WG adoption call for
> draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)
> >
> >
> > Sue,
> >
> > Thank you for your reply.
> > Please see inline [Bruno]
> >
> >
> > Orange Restricted
> > From: Idr <[e-mail]> On Behalf Of Susan Hares
> > Sent: Friday, September 16, 2022 1:20 PM
> > To: DECRAENE Bruno INNOV/NET <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: [Idr] WG adoption call for
> draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)
> >
> > Bruno:
> >
> > I’m sorry this response is so delayed (M to Friday)
> > [Bruno] Definitely not an issue on my side.
> >
> > From: [e-mail] <[e-mail]>
> > Sent: Monday, September 12, 2022 8:09 AM
> > To: Susan Hares <[e-mail]>
> > Cc: Alvaro Retana <[e-mail]>; [e-mail];
> Dongjie (Jimmy) <[e-mail]>; [e-mail]
> > Subject: RE: [Idr] WG adoption call for
> draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)
> >
> >
> > Sue,
> >
> > Thank you for your clarification questions.
> > Please see inline.
> >
> >
> > Orange Restricted
> > From: Susan Hares <[e-mail]>
> > Sent: Friday, September 9, 2022 8:09 PM
> > To: DECRAENE Bruno INNOV/NET <[e-mail]>; [e-mail]
> > Subject: RE: [Idr] WG adoption call for
> draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)
> >
> > Bruno and John:
> >
> > The target for the adoption for draft-scudder-idr-entropy-label-01
> > is a bis draft for [RFC6790] to fix a bad RFC.
> >
> > The IDR chairs did start this call for draft-scudder-idr-entropy-label-01
> > to compete with draft-ietf-idr-next-hop-capability-08.txt or
> > other drafts regarding next hops or bgp attributes
> > (e.g. draft-scudder-idr-entropy-label-01 as a “bis” document).
> >
> >
> > Thanks for the info. Why is there a desire from IDR chairs to bring a
> second solution (draft-scudder-idr-entropy-label) to compete with the first
> (draft-ietf-idr-next-hop-capability)?
> > - Is this that in general two solutions are better than one?
> > - Is this that the WG expressed comments/limitations on
> draft-ietf-idr-next-hop-capability?
> >
> > [Sue]:  IDR has in the past standardized the existing solutions on its
> way to the final solution.  I see this as another case of that approach.
> My understanding is that John’s solution has multiple implementations to
> fix the “bis”.  Draft-ietf-idr-next-hop-capability has nice generic
> properties, but no implementations.
> > [Bruno2] Assuming that you are referring to the draft being called for
> adoption, my understanding is that ELCv3 has no implementation. (Note that
> it has no codepoint allocated)
> >
> > [Bruno] Your answer is not showing in my mailer. Would you be kind
> enough to retype it?
> > [Sue2]: let me know if you see it now.
> >
> > [Bruno2] I see it now. Thank you.
> >
> > Bruno argues that it would be better to include this in
> > draft-ietf-next-hop-capability-08.txt as a fix.
> >
> > For this shepherd to monitor this portion of the adoption call,
> > I need John and Bruno to provide additional input:
> >
> > John: you need to address Bruno’s comments on
> >
> > “So ELCv2 is not to be used. But this draft is more or less saying the
> opposite in Appendix A, therefore I object the content of Appendix A.
> > ELCv2 is a proprietary solution. Migrating away of ELCv2 may be handled
> without the IETF.”
> >
> > Bruno: if we are going to consider draft-ietf-next-hop-capability-08.txt
> > as alternate short term fix to [RFC 6790] I need to know the following:
> >
> > Why do you say that draft-ietf-next-hop-capability is a short term fix,
> while it 1) fixes the problem and 2) it provides a generic tools to
> advertise BGP Next-Hop dependent capability which will be needed for
> current MPLS WG evolutions (In Stack Data, Post Stack Data)?
> > Why are you considering draft-ietf-next-hop-capability as the possible
> alternate while it’s the solution been adopted by the IDR WG. In my opinion
> those qualifiers “alternate” and “if we are going to consider” would better
> apply to the recent individual draft (draft-scudder-idr-entropy-label)
> >
> > [Sue]: Bruno.  Perhaps it is my English.
> > Short term == are you ready to go to WG LC now?
> >
> > [Bruno] Why not if this helps, minus the fact that so I’m not familiar
> with the procedure that I’m assuming you’re meaning (WGLC then parking the
> document in the IDR WG while waiting for 2 implementations?)
> > But I’m not sure to see what this would change in term of
> implementations, publication of RFC, and period of time.
> >         [Sue2]:  My question should have been – does
> draft-ietf-next-hop-capability have 2 implementations?
> >         Does draft-ietf-next-hop-capability define an equivalent to
> draft-scudder-idr-entropy-label-01?
> >
> > [Bruno2] Both draft-scudder-idr-entropy-label and
> draft-ietf-idr-next-hop-capability have no codepoints, so a priori no
> implementations.
> > Personally I’d say that functionally draft-ietf-idr-next-hop-capability
> is a superset of draft-scudder-idr-entropy-label-01.
> >
> > A “bis” == a fix to an existing document’s text errors with no
> additional content.
> > Alternatives ==  alternatives to problem of broken existing document: 1)
> bis, or 2) bis fix + other
> >
> > [Bruno] The WG already has an alternative to the broken document (RFC
> 6790); it’s draft-ietf-idr-next-hop-capability Why would we need an
> alternative to this alternative?
> >     [Sue]: Because draft-ietf-idr-next-hop-capability does not have
> implementations now, and the draft-scudder-idr-entropy-label-01 does.
> >
> > [Bruno2] I’d be curious to know the implementations of
> draft-scudder-idr-entropy-label-01. They would be squatting on codepoints.
> >
> >
> > 1) Do you have a specific proposal for adding this fix to
> > draft-ietf-next-hop-capability?
> >
> > If the WG express the need for a non-transitive BGP attribute in order
> to avoid the software upgrade on the RR it seems straightforward for
> draft-ietf-next-hop-capability to replace the non-transitive attribute with
> a transitive attribute recording the latest BGP NH which has modified the
> attribute. I don’t recall such request from the IDR WG.
> >
> >              [Sue-2]: if you posit that it is straight-forward, I would
> suggest you write preliminary text.
> >
> > [Bruno2] I did. I have initiated an email thread on the list.
> https://mailarchive.ietf.org/arch/msg/idr/iSCnMtdzygqt8Opoq8eJvM2CeoM/
> I’ll update the draft after collecting the feedback from the WG.
> >
> > 2) what is the implementation status is for
> draft-ietf-next-hop-capability-08.txt.
> >  [how many implementations and how many features]?
> >
> > I’m not aware of any publically announced implementation.
> > [Sue]:
> > No implementations == longer term solution
> > in draft-ietf-next-hop-capability-08.txt
> >
> > [Bruno] Both draft-scudder-idr-entropy-label and
> draft-ietf-idr-next-hop-capability have no public implementation. So by
> this logic, both should be equally named as long-term, and not a reason to
> duplicate the solutions.
> >
> > [Sue]: I have two vendors giving me information on implementations of
> draft-scudder-idr-entropy-label.  I can take private information on
> draft-ietf-next-hop-capability-08.txt, if you have vendors implementing
> this draft.
> >
> > [Bruno2] Can the WG have this information public?
> draft-scudder-idr-entropy-label has no codepoint allocated so those
> implementations could only be squatting on codepoint.
> > So basically, one implementation may define whatever it wants in
> private, squat on codepoint, deploys the squatted codepoint in a mono
> vendor environment, and then uses this to have its solution rubber stamped
> by the WG, including in the presence of an existing solution adopted by the
> WG. Interesting.
> >
> > Regards,
> > --Bruno
> >
> >
> > How
> > MPLS transitioning away from “Entropy Label for the New Thing”
> > does not really impact a “bis” draft.  The focus here is publishing a fix
> > to a broken draft.
> >
> > - If the focus is publishing a fix for a broken draft, we already have a
> WG document for this: draft-ietf-idr-next-hop-capability
> > - IMO, as we know that we need the signal more than ELC, it looks more
> futureproof to work on a generic solution.
> draft-ietf-idr-next-hop-capability provides this generic solution,
> draft-scudder-idr-entropy-label does not
> >
> > [sue-2]: I will comment on this part of your email – once I have caught
> up to the mail threads.
> >
> > [Bruno] Ack. For the record, above comment is from Sue, not Bruno.
> > [Sue-2]: Agreed.  I really should have drunk more coffee this morning
> before typing this response (smile).  I’m afraid the typographical error
> comes from that point.
> >
> > Regards,
> > --Bruno
> >
> >
> > Thank you,
> > Regards,
> > --Bruno
> >
> > As shepherd, I expect that John Scudder and Bruno will answer
> > these questions as part of their upcoming posts.
> >
> > Cheerily, Sue
> >
> >
> >
> > From: [e-mail] <[e-mail]>
> > Sent: Thursday, September 8, 2022 10:20 AM
> > To: Susan Hares <[e-mail]>; [e-mail]
> > Subject: RE: [Idr] WG adoption call for
> draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)
> >
> >
> > Sue,
> >
> >
> >
> > Orange Restricted
> > From: Idr <[e-mail]> On Behalf Of Susan Hares
> > Sent: Tuesday, September 6, 2022 10:32 PM
> > To: [e-mail]
> > Subject: [Idr] WG adoption call for draft-scudder-idr-entropy-label-01
> (9/6/2022 to 9/20/2022)
> >
> > This begins a 2 week WG Adoption and IPR call for:
> > https://datatracker.ietf.org/doc/draft-scudder-idr-entropy-label/
> >
> > The co-authors should respond to this message with an IPR statement.
> >
> > The specification revised the BGP attribute for Entropy Label Capability.
> > The abstract of the document states:
> >
> >   “This specification defines the Entropy Label Capability Attribute
> >    version 3 (ELCv3), a BGP attribute that can be used to inform an LSP
> >    ingress router about an LSP egress router's ability to process
> >    entropy labels.  This version of the attribute corrects a
> >    specification error in the first version, and an improper code point
> >    reuse in the second.
> >
> >
> > 1)    We already have a solution for this; an IDR WG document.
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-next-hop-capability-08
> > “This document also defines a Next-Hop capability to advertise the
> >    ability to process the MPLS Entropy Label as an egress LSR for all
> >    NLRI advertised in the BGP UPDATE.  It updates RFC 6790 with regard
> >    to this BGP signaling.”
> >
> > I don’t recall that the WG expressed an issue on this solution. Nor
> asked for the use of a non-transitive attribute.
> > Now if there is a compelling reason to use a transitive attribute, this
> can be discussed by the WG as part of regular WG work on
> draft-ietf-idr-next-hop-capability. If needed, both drafts may also be
> merged.
> >
> >
> > 2) Initiating a technical comparison of transitive vs non-transitive
> attribute:
> >
> > Non-transitive:
> > - require the software upgrade of PE, ASBR, RR
> >
> > Transitive:
> > - require the software upgrade of PE, ASBR.
> > - require the re-implementation, test and debugging of the
> non-transitive-like filtering.
> >
> > All in all, small gain in term of deployability at a small cost in term
> of implementation. Obviously, “small” is in the eye of the beholder.
> > Regarding software upgrade, the only difference is the BGP Route
> Reflector which: is a small number of nodes (typically at least two order
> of magnitude smaller), control plane only / no impact on customers,
> typically centralized in a very small number of locations, control plane
> only so very possibly we are talking about a VM or container. I would not
> call this a ‘forklift upgrade’.
> >
> > Again, this is a discussion that we can have on the WG document that we
> have (draft-ietf-idr-next-hop-capability)
> >
> > 3) lack of feature coverage
> > draft-ietf-idr-next-hop-capability is a generic tool allowing the
> advertisement of different kind of BGP Next-hop dependent capabilities.
> Entropy label is one, but the MPLS WG is currently defining new data plane
> features (In Stack Data, Post Stack Data) which will require to advertise
> different type de capabilities, possibly with related parameters. Therefore
> the general tool is needed. (and some people in the MPLS WG have even
> proposed to deprecate the Entropy Label for the New Thing, so defining a
> new BGP Capability just for Entropy Label may seem a bit late). There are
> other usages for other dataplane such as IOAM (another IDR WG using
> draft-ietf-idr-next-hop-capability)
> >
> > 4) In all cases, I don’t think we need two solutions for this simple
> problem. (the operational differences are small, a few %)
> >
> >
> > In your comments consider:
> > 1) Does this specification fixes errors in versions 1 and 2?
> >
> > 2) Are there any additional errors or weakness in this specification
> > of version 3?  For example, has this specification clearly described what
> > happens if version 1, 2 and 3 exist in a network?
> >
> > Not really. As already expressed on the list, what happens if ELCv2 and
> ELCv1 exist in the network is BGP sessions reset with a major impact on the
> network.
> > So ELCv2 is not to be used. But this draft is more or less saying the
> opposite in Appendix A, therefore I object the content of Appendix A.
> > ELCv2 is a proprietary solution. Migrating away of ELCv2 may be handled
> without the IETF.
> >
> > 3) Will deployment of version 3 of Entropy Label Capability
> > BGP attribute aid in fixing problems in current networks?
> >
> > 4) Are there enough implementations that this draft should
> > Be moved quickly to WG LC?
> >
> > There are no implementations of ELCv3.
> >
> > Regards,
> > --Bruno
> >
> > Cheerily, Sue
> >
> >
> _________________________________________________________________________________________________________________________
> >
> > 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.
> >
> _________________________________________________________________________________________________________________________
> >
> > 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.
> >
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!ATraQ_f_erRjkrF2bBFUX8Emspe9E25t-P3R-5mMzGgM9LTmQEovOc_UZeeZXOs-r6Bz6vczBh2VHIimu0UnDyU$
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>