Hi Ron, <I copied the SPRING mailing list since some of my comments are also related with the SPRING WG. Hope it is ok.>
I have short experience in IETF compared with most of you with decades of experience, but still I believe that people do care about the motivations as well as the students in 25 years. From my observation and understanding, in IETF even to bring a small extension to the existing protocol the community will require proper justifications. People will ask why we need this extension, and why the existing solutions cannot solve the same issue. Don’t need to mention about the justifications that would be required for a general purpose routing header as you call it. There have been a few RHs already defined in IETF. For the one that I have experienced part of its standardization process, i.e. SRH, I have learned that there is an architecture (RFC8402) draft defined for it as well as related problem statement (RFC7855) and use cases (RFC8354, RFC8355) drafts in SPRING. There are so many other drafts active in SPRING and other working groups built upon the SRH in almost every aspect, which in the meantime also justify its value. For CRH, the IPv6 Compressed Routing Header (CRH), from the title wise, I don’t see why it should be called a general purpose routing header. Its use to me is pretty clear, that is for compression. Can we say compression is the use case of this routing header? Is there any other use cases for it? If we call it a general purpose, it would be better if it can be used in general case or to cover more general use cases. Regarding the justification of CRH, I did notice that in its version 10 there was a normative reference to a SPRING draft [I-D.bonica-spring-srv6-plus], but it was removed from version 11. I am not quite sure about your motivation to have this action. But I have been taken SRv6+ now SRm6 as the architecture and justification of CRH. Probably some people also had the same feeling. If compression is the use case and SRm6 is the justification, currently there have already been a few solutions on the table of SPRING. People are working together to evaluate those solutions to solve the size issue, the same as one of the purpose of CRH. So would it be better for CRH to join the discussion there and solve the lengthy header issue altogether? That would mean a lot to the community for now. My two cents. Thank you! Best regards, Shuping -----Original Message----- From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Ron Bonica Sent: Wednesday, May 13, 2020 4:13 AM To: Darren Dukes (ddukes) <ddu...@cisco.com> Cc: 6man <6...@ietf.org> Subject: RE: CRH and RH0 Hi Darren, The answer to your question is a bit nuanced. My goals were to build a general purpose routing header that overcomes the RH0's limitations. Those being: - Its size - Its security issues Now, is that a replacement for RH0? In one way, yes. RH0 and CRH are both general purpose routing headers. In another sense, no. RH0 is meant to traverse network boundaries. But RFC 5095 taught us that letting routing header traverse network boundaries might not be a wonderful idea. So, CRH is restricted to a network domain. And now I return to my original question. When engineering students read the CRH RFC in 25 years, will they really care what my motivation was? Why should we burden them with this detail? Ron Juniper Business Use Only -----Original Message----- From: Darren Dukes (ddukes) <ddu...@cisco.com> Sent: Tuesday, May 12, 2020 2:54 PM To: Ron Bonica <rbon...@juniper.net> Cc: 6man <6...@ietf.org> Subject: Re: CRH and RH0 [External Email. Be cautious of content] Hi Ron, The introduction spends its time likening CRH to RH0 and says it differs by “encoded in fewer bytes” and “addresses security vulnerabilities” I was left with the impression that you are attempting to recreate another general use IPv6 routing header for the internet. Like RH0. It's only in section 9 where there is a hint that is not the case, you say “Networks that process the CRH MUST…”. I could not find a definition of these networks. Darren > On May 12, 2020, at 2:32 PM, Ron Bonica <rbon...@juniper.net> wrote: > > Hi Darren, > > The second issue is already addressed in the Security Consideration section. > > I would be glad to add a sentence saying that CRH is not a replacement for > RH0, but I am not sure what value that sentence will have to someone who will > read the document in 25 years. Could you help me understand the benefit? Why > would the reader care? > > Ron > > > > Juniper Business Use Only > > -----Original Message----- > From: Darren Dukes (ddukes) <ddu...@cisco.com> > Sent: Tuesday, May 12, 2020 2:27 PM > To: Ron Bonica <rbon...@juniper.net> > Cc: 6man <6...@ietf.org> > Subject: CRH and RH0 > > [External Email. Be cautious of content] > > > Hi Ron, > > You mentioned in the 6man meeting that: > 1 - CRH is not intended to be a replacement for RH0 > 2 - CRH is not intended for use on the internet (i.e. only within a domain). > > Will you be updating draft-bonica-6man-comp-rtg-hdr to reflect that? > > Thanks > Darren -------------------------------------------------------------------- IETF IPv6 working group mailing list i...@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
