Let me quote Brian on this – because I think he said it better and more succinctly than I could in my own words.
The use case is: some operators want this. That has been enough for the IETF since 1986 (and is of course much more important than vendor preferences). Thanks Andrew From: spring <[email protected]> On Behalf Of Ketan Talaulikar (ketant) Sent: Thursday, 28 May 2020 16:33 To: Erik Kline <[email protected]>; Zafar Ali (zali) <[email protected]> Cc: Ron Bonica <[email protected]>; [email protected]; 6man <[email protected]> Subject: Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option? Sometimes a known devil is better than an unknown one. I think we need to be very careful in considering the introduction of a new label/ID mapping technology into IPv6 Routing and it's ramifications. https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-5.1<https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-5.1> The maximum 16-bit SID value is 65,535. Because SIDs 0 through 15 are reserved for future use, a 16-bit SID offers 65,520 usable values. The maximum 32-bit SID value is 4,294,967,295. Because SIDs 0 through 15 are reserved for future use, a 32-bit SID offers 4,294,967,280 usable values. This is the same as https://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml<https://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml> So is this, then in fact, an attempt to reinvent MPLS in a new avatar? While some are talking about the CRH proposal as a brick, I see it as a tip of an iceberg. It is not just a new RH – it has significant impact across routing and ops areas. I would think one would expect a BoF for something like this? Therefore the request for proper documentation of the applicability, use-cases and architecture and their presentation (that too in the right areas/WGs) for the proper evaluation of this proposal. Thanks, Ketan -----Original Message----- From: ipv6 <[email protected]<mailto:[email protected]>> On Behalf Of Erik Kline Sent: 28 May 2020 03:11 To: Zafar Ali (zali) <[email protected]<mailto:[email protected]>> Cc: Ron Bonica <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; 6man <[email protected]<mailto:[email protected]>> Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option? There are actual, meaningful differences to be contemplated; folks with no operational MPLS in there networks might not want to be forced to start. On Wed, May 27, 2020 at 2:20 PM Zafar Ali (zali) <[email protected]<mailto:[email protected]>> wrote: > > Fred, > > > > Is there any IETF requirement document for OMNI and AERO (I am sorry I am not > aware of the technology but very much interested in learning)? > > Do we have some documents describing the scale you would need? > > Have the associated WG analyzed existing solutions? > > Have they feed the results of the above to 6man WG? > > > > All other routing header types have had requirements and designs from > dedicated working groups with expertise in the area. > > Why should CRH be an exception, especially when there are multiple competing > solutions in 6man and Spring? > > > > Thanks > > > > Regards … Zafar > > > > From: "Templin (US), Fred L" > <[email protected]<mailto:[email protected]>> > Date: Wednesday, May 27, 2020 at 4:33 PM > To: Andrew Alston > <[email protected]<mailto:[email protected]>>, > Ron Bonica > <[email protected]<mailto:[email protected]>>, > "Zafar Ali (zali)" > <[email protected]<mailto:[email protected]>>, "Henderickx, Wim (Nokia - > BE/Antwerp)" > <[email protected]<mailto:[email protected]>>, Sander Steffann > <[email protected]<mailto:[email protected]>> > Cc: "[email protected]<mailto:[email protected]>" > <[email protected]<mailto:[email protected]>>, 6man > <[email protected]<mailto:[email protected]>> > Subject: RE: Long-standing practice of due-diligence is expected - Re: > [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option? > > > > As I said, I want to use CRH for OMNI and AERO; I don't want the term > "MPLS" to appear > > either in my documents or in any documents mine cite. The 16-bit CRIDs > in CRH are very > > handy for coding ULA Subnet Router Anycast addresses such as > fd80::/16, fd81::/16, > > fd82::/16, etc., and the 32-bit CRIDs are very handy for coding the > administrative address > > suffixes of fd80::/96. So, CRH gives everything I need (and nothing I > don’t need) for > > successfully spanning the (potentially) multiple segments of the AERO link. > > > > Thanks - Fred > > > > From: ipv6 [mailto:[email protected]] On Behalf Of Andrew Alston > Sent: Wednesday, May 27, 2020 1:19 PM > To: Ron Bonica > <[email protected]<mailto:[email protected]>>; > Zafar Ali > (zali) <[email protected]<mailto:[email protected]>>; Henderickx, Wim (Nokia - > BE/Antwerp) > <[email protected]<mailto:[email protected]>>; Sander Steffann > <[email protected]<mailto:[email protected]>> > Cc: [email protected]<mailto:[email protected]>; 6man > <[email protected]<mailto:[email protected]>> > Subject: Re: Long-standing practice of due-diligence is expected - Re: > [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option? > > > > What I find so bizarre is – > > > > You have an multiple operators – who have clearly said – we want this – we > see advantage of this. Yet still the obstructionism and denialism continues. > The “not invented here” syndrome seems to run deep – and email after email > is patently ignored from the very people who have to buy the hardware. > Reference is made to Montreal – yet the emails that stated the use cases > after it went by with no response. No technical objections ever show up – > other than – we don’t want this and you haven’t given us this mythical > architecture document – which was yet another non-technical response that > seems so clearly designed to stall any innovation that doesn’t come from one > source. > > > > All I see from the operator perspective here is obstructionism and stalling > in a desperate attempt to block anything that could be a threat to what was > dreamed up by someone else. It is almost as if there is fear that the market > may choose something other than what was designed – and that fear is driving > this stance of throw everything we hav against the wall and hope that > something sticks – because the technical arguments have failed time and again. > > > > This pitbull approach certainly doesn’t garner any respect for me, does not > help to promote srv6 which seems to be what you want and in fact convinces me > more every day that CRH is the right move – where I can built on top of it > without the obstructionism of a vendor that seems to have zero interest in > what mysef and other operators are clearly stating over and over again. > > > > Yet again – I support crh – I’ve deployed CRH – CRH works for us – and we > still continue to support it. And irrespective of if it is adopted – the > development of it will continue – and it will exist – the only question is – > do we end up with something that the market wants outside of the auspices of > the IETF – or do we end up with something that is properly standardized, > because this level of obstructionism will not prevent the development. > > > > Can we actually get back to proper technical reasoning? > > > > Thanks > > > > Andrew > > > > > > From: ipv6 <[email protected]<mailto:[email protected]>> on behalf of > Ron Bonica > <[email protected]<mailto:[email protected]>> > Date: Wednesday, 27 May 2020 at 23:07 > To: "Zafar Ali (zali)" <[email protected]<mailto:[email protected]>>, "Henderickx, > Wim (Nokia - > BE/Antwerp)" <[email protected]<mailto:[email protected]>>, > Sander Steffann > <[email protected]<mailto:[email protected]>> > Cc: 6man <[email protected]<mailto:[email protected]>>, > "[email protected]<mailto:[email protected]>" > <[email protected]<mailto:[email protected]>> > Subject: RE: Long-standing practice of due-diligence is expected - Re: > [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option? > > > > Zafar, > > > > Why all the passion about stopping the CRH? Does it break any existing > standard? Does it consume any scarce resource? > > > > You might argue that there is a scarcity of Routing header type numbers. But > that would be a very short argument. You might argue that WG resources are > scarce, and that it would take too much time to review this fourteen page > document. But that argument might take more time than the document review. > > > > In your email, below, you mention “the hardware and software investment from > vendors”. Is that the scarce resource? > > > > Vendors are not obliged to implement every draft that is adopted as a WG > item. Generally, the marketplace drives product roadmaps. > > > > If the only resource we are protecting is vendor investment, the > long-standing practice of due diligence should be tempered by operator > demand. The IETF should not pretend to understand operator requirements > better than the operators themselves. > > > > Why not let the marketplace decide whether it needs a CRH? > > > > > Ron > > > > > > > > > > > > Juniper Business Use Only > > From: Zafar Ali (zali) <[email protected]<mailto:[email protected]>> > Sent: Wednesday, May 27, 2020 3:19 PM > To: Henderickx, Wim (Nokia - BE/Antwerp) > <[email protected]<mailto:[email protected]>>; > Sander Steffann <[email protected]<mailto:[email protected]>> > Cc: Mach Chen <[email protected]<mailto:[email protected]>>; Ron Bonica > <[email protected]<mailto:[email protected]>>; Chengli (Cheng Li) > <[email protected]<mailto:[email protected]>>; 6man > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]>; Zafar Ali (zali) > <[email protected]<mailto:[email protected]>> > Subject: Long-standing practice of due-diligence is expected - Re: [spring] > CRH is not needed - Re: How CRH support SFC/Segment Endpoint option? > > > > [External Email. Be cautious of content] > > > > WH> My position remains that RFC8663 is a valid alternative and is available; > I am against WG adoption of CRH. > > > > The industry widely supports RFC8663. > > > > Instead of denying the evidence, could the CRH authors and proponents finally > understand that people are not opposed to new ideas? > > > > People are reminding a long-standing practice of the IETF process. > Before tackling a new piece of work, a working group must perform a > due diligence on > > whether this new work is redundant with respect to existing IETF > protocols, whether this new work would deliver genuine benefits and use-cases. > > > > It is factually and logically clear to the working-group that the currently > submitted CRH documents. > > fail to position CRH with respect to existing standard widely > supported by the industry (e.g., RFC8663) fail to isolate new benefit > or use-case [1] > > > > This positive collaborative feedback was already given in SPRING. > > The CRH authors may change this analysis. They need to document 1 and 2. > > > > Why did the CRH authors not leverage this guidance in SPRING WG? > > This was also the chair's guidance in Montreal [2] and Singapore [3] > > > > All the lengthy discussions and debates on the mailing list could be avoided > if only the CRH authors would tackle 1 and 2. > > > > The CRH authors must tackle 1 and 2. > > > > This is the best way to justify a/the work from the IETF community and b/ the > hardware and software investment from vendors. > True benefits must be present to justify such a significant engineering > investment (new data-pane, new control-plane). > > > > Thanks > > > > Regards … Zafar > > > > [1] > https://mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8<https://mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8> > / > > [2] > https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFon<https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFon> > t=true > > [3] > https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg<https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg> > / > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected]<mailto:[email protected]> > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6> > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected]<mailto:[email protected]> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6> --------------------------------------------------------------------
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
