Hi Andrew,

Re: “Yes, originally, CRH was heavily linked to SRm6.  But – over time, 
thinking and ideas evolve.”

I looked at the following diffs 
https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-comp-rtg-hdr-11.txt (rev. 
10 to rev. 11 in Feb. 2020).
All I find is surgical removal of SRm6 and positing of CRH as replacement of 
RH0.

When the WG played the “hide and seek”, all aspects of SRm6 came back on the 
table [1] and [I can cite MANY specific references to the ML, if you like].
I am sorry, I fail to see the evolution (except may be the RH0 replacement 
positioning).



Please realize that there are other competing solutions to CRH in Spring.

It is only fair and in best interest of industry/ IETF that all solutions are 
discussed and progress together.


I already REQUESTED: “could the CRH authors and proponents finally understand 
that people are not opposed to new ideas?”

[1] https://mailarchive.ietf.org/arch/msg/ipv6/zRZJe68FZX3X0wla-muo3IkCJv8/

Thanks

Regards … Zafar

From: Andrew Alston <[email protected]>
Date: Wednesday, May 27, 2020 at 6:26 PM
To: "Zafar Ali (zali)" <[email protected]>, Brian E Carpenter 
<[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?

Zafar,

It amazes me how totally selective you are with your reading.

I won’t even bother dignifying much of the word twisting and gaming and 
selective reading with a response – but what I will say is this.  Yes, 
originally, CRH was heavily linked to SRm6.  But – over time, thinking and 
ideas evolve.  And the realization was pretty clear that CRH served so many 
purposes outside of SRm6.  CRH is a brick, a building block, the tyre on a car 
– and yes – the normative reference to SRm6 was removed because – CRH is not 
normative to SRm6 – SRm6 is normative to CRH.  The realization that CRH had 
many many applications and could be used outside of the segment routing 
paradigm was simply an evolution in thinking – and that – is the nature of 
innovation.  To innovate you have to have a willingness to let your thoughts 
evolve and not remain wedded to something when you realize that the 
possibilities of something go beyond the original intention.

If you wish to remain tied to something no matter the findings – and no matter 
the progression through the process – both in terms of your own thinking and 
the comments and thoughts of others – you are no longer innovating – you are 
stuck in the mire.  So yes – the thinking evolved over time and new 
applications were seen.

And as for the claims it was positioned as a replacement for RH0 – that has 
been asked and answered – many times.  Yes – there were references to RH0 – it 
was never a like for like replacement and I dispute that that was ever said – 
but I guess no matter how many times things are repeated – selective reading 
still applies.

Andrew


  *   During IETF106. This is what the draft authors agreed on the mailing list 
[2].

o    “I accept your challenge to produce a document that describes the 
advantages of SRm6 over SRv6, as well as the differences between SRm6 and SRv6. 
Expect some operational hoarse-sense as well as some architectural deep-diving.”

·         No such document was produced.

  *   Instead, in Feb. 2020, authors removed normative reference to SRm6.
  *   Authors positioned CRH as a replacement of RH0
  *   RH0 replacement was later removed before the adoption call.
  *   There are other competing solutions that are discussed in Spring (and 
will come to 6man via the “routing area”).

Why CRH authors are trying to “skip the queue” and “skip the routing area”?

[1] https://mailarchive.ietf.org/arch/msg/ipv6/fasaPY3vGhMEmPreUFEJ4j7281o/
[2] https://mailarchive.ietf.org/arch/msg/spring/Su-5NFpETVGt5beWObmnCP4LoYs/

Thanks

Regards … Zafar

_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to