RE: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Brian,



Please check inline below.



-----Original Message-----
From: Brian E Carpenter <[e-mail]>
Sent: 22 May 2020 03:03
To: Ketan Talaulikar (ketant) <[e-mail]>; Bob Hinden <[e-mail]>; IPv6 List <[e-mail]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"



Hi,

On 22-May-20 00:28, Ketan Talaulikar (ketant) wrote:

...

> **  Is there a charter milestone that explicitly calls for such a document?   ** ***

> KT> No.



That is not an exclusionary argument. If it *was* a milestone, that would be supportive. But the absence of a milestone is like any other absence of evidence.

[KT] I never said this statement/argument was exclusionary. Neither does RFC7221 that I took this from.

> **  Is the topic of the I-D within scope for the working group?   ** ***

>

> KT> No. This is 6man WG; not anymore IPNG or IPV6. The WG charter clearly says “It is not chartered to develop major changes or additions to the IPv6 specifications.”



That's a judgment call. IMHO a new routing header type is not "major". It's maintenance.

[KT] I was talking about the introduction of a new IPv6 Source Routing solution not just the CRH. If some other WG had defined this new Source Routing solution and 6man were doing just the CRH specification then it would be well within the scope of 6man and following precedence of how other RH work was done in the past. But we don’t have the solution as a reference, do we? So it would follow that 6man is taking the lead and defining a new IPv6 Source Routing solution which cannot be seen as maintenance work.

> KT> A new Source Routing technology (as claimed by the authors) is in the domain of expertise of the Routing Area (as the name suggests).



Nobody can deny that, but a new RH type is in 6MAN's competence, as proved by the SRH case.

[KT] And I am not arguing otherwise. My point is where is the solution description that 6man can refer to when designing the new RH?



I said the other day that advice from the Routing ADs is needed, and that remains true. But again, this is not an exclusionary argument.

[KT] Indeed, you had made this point earlier and it is very valid and pertinent. I would also look for response on this from the chairs and the ADs.



> KT> Contrary to the claims by the authors, I would assert that this work simply brings a new IPv6 data_-_plane proposal for the Spring WG’s Segment Routing solution.



Again, that's why this WG needs advice from the Routing ADs.

[KT] Indeed – we are not aware of what was done or the agreement for proceeding with this work.



But if it builds on SPRING work, so what? We build on each other's work constantly in the IETF, and that's a good thing. SPRING has no monopoly, and SRH has no monopoly.

[KT] Definitely. We constantly build on existing work. SRm6 was trying to do that. But the current document does not provide any attribution to Spring architecture and body or work. The authors in fact deny this has anything to do with Segment Routing. It would seem like the authors are not giving the due to years of work done in Spring. And that makes one wonder why so because the previous versions of this document did have such references to Spring work that was purposefully removed by the authors.

> **  Is the purpose of the draft sufficiently clear?   ** ***

>

> KT> The purpose is not clear since the new IPv6 Source Routing solution claimed by the authors is not documented in the draft in terms of its applicability, use-cases and requirements. The header format and simplistic forwarding rules documented do not describe the architectural concepts of what a SID is, it’s semantics, “forwarding methods”, “method specific parameters”, etc.



That's been discussed already with some new text proposed. But of course after the draft is adopted, we (the WG) own the the draft and can extend it as needed.

[KT] You see this is nothing but the new IPv6 Source Routing architecture being discussed and being developed – not just the CRH design. So is 6man chartered to develop new IPv6 Source Routing solution? That is my question.



> KT> As observed in the WG discussion, members seem to be guessing or speculating on what would be a good size for the SIDs and how they would be used/deployed. This is clear proof that the solution is not described clearly.



That's of no importance at the adoption stage. The WG can improve the draft as needed.

[KT] How can a work be considered for adoption when its scope, purpose and usage is not known. This kind of exploratory work is suitable to start a BOF and not new work in 6man that is chartered with maintenance. Not to mention the wide impact this work would result on other WGs in routing area.



> **  Does the document provide an acceptable platform for continued effort by the working group?   ** ***



6MAN's job is limited to specifying the routing header. After that, it's up to the Routing Area to do the rest.

[KT] And how does 6man do it’s job without having a specification that describes the architecture, use-case, applicability, … we come back to it.



Thanks,

Ketan



Your remaining questions are all irrelevant at the adoption stage. We are nowhere near talking about WG last call or submission to the IESG.



Regards

    Brian Carpenter