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]> 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]> > Date: Wednesday, May 27, 2020 at 4:33 PM > To: Andrew Alston <[email protected]>, Ron Bonica > <[email protected]>, "Zafar Ali (zali)" <[email protected]>, > "Henderickx, Wim (Nokia - BE/Antwerp)" <[email protected]>, Sander > Steffann <[email protected]> > Cc: "[email protected]" <[email protected]>, 6man <[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]>; Zafar Ali (zali) > <[email protected]>; Henderickx, Wim (Nokia - BE/Antwerp) > <[email protected]>; Sander Steffann <[email protected]> > Cc: [email protected]; 6man <[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]> on behalf of Ron Bonica > <[email protected]> > Date: Wednesday, 27 May 2020 at 23:07 > To: "Zafar Ali (zali)" <[email protected]>, "Henderickx, Wim (Nokia - > BE/Antwerp)" <[email protected]>, Sander Steffann <[email protected]> > Cc: 6man <[email protected]>, "[email protected]" <[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]> > Sent: Wednesday, May 27, 2020 3:19 PM > To: Henderickx, Wim (Nokia - BE/Antwerp) <[email protected]>; Sander > Steffann <[email protected]> > Cc: Mach Chen <[email protected]>; Ron Bonica <[email protected]>; > Chengli (Cheng Li) <[email protected]>; 6man <[email protected]>; [email protected]; > Zafar Ali (zali) <[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/ > > [2] > https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true > > [3] https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/ > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
