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
1. whether this new work is redundant with respect to existing IETF
protocols,
2. 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.
1. fail to position CRH with respect to existing standard widely supported
by the industry (e.g., RFC8663)
2. 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://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8/__;!!NEt6yMaO-gk!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVl0PT0CIY$>
[2]
https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true<https://urldefense.com/v3/__https:/etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true__;!!NEt6yMaO-gk!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVl8aoFdbw$>
[3]
https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/__;!!NEt6yMaO-gk!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVlypBDeuG$>
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
