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

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

Hi Bob & Ole,



I am opposed to the WG adopting this draft and I am sharing the reasons for the same objectively based on the guidelines in https://tools.ietf.org/html/rfc7221#section-2.2



Reference: https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22



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



KT> No.



*  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."



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). Note that the authors have clarified that the target is not IPv6 Internet but some (yet undefined) "limited domain" in an operator's private network. The WG has not been made aware of any discussion with Routing ADs on how this solution work (and not just this RH document) is going to proceed.



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. It borrows (without any attribution) a lot of Spring architectural constructs (e.g. Prefix and Adjacency SID). So, the current document still leans on Spring work even if the authors have removed references from the previous versions. Therefore, it is not a new Source Routing solution but a new IPv6 data-plane that offers a reduced Segment Routing functionality.



*  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.



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.



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



KT> It would be odd if the 6man WG is going to own up the work of documenting the architecture - I request to chairs to clarify their position on this. This work will result in a lot of extensions being introduced for multiple protocols in the Routing Area. Unlike Spring WG, there is no WG to define the requirements and set the framework or context for those other protocol work. This would result in largely uncoordinated and ill-defined work across multiple WGs in the IETF.



*  What are the process or technical objections to adoption of the draft?



KT> Process objections are covered above - not in charter, not well specified. Technical objections have been shared on the list on multiple threads before the WG adoption started. Fundamentally, the documentation of the proposal is inadequate for a proper technical review.



*  Is the draft likely to be completed in a timely manner?



KT> Unable to determine at this juncture. The draft seems highly contentious at this point.



*  Does the intended status of the document seem reasonable to the working group?



KT> At best, this seems to be experimental work that is exploratory in nature and not fully defined as expected for standards development for a multi-vendor development and production deployment.



*  If not already in scope, is a simple modification to the charter feasible and warranted?



KT> Changing scope would require change of name of the WG. Instead if this is new Source Routing work and different from Spring WG charter then perhaps a BOF followed by a new WG in Routing Area would be more appropriate.



*  Does the draft carry known intellectual property rights issues?



KT> There is one IPR from a vendor/co-author.



*  Is there strong working group support for working on the draft?



KT> This would be something that is to be determined at the end of the ongoing poll.



In my conclusion, this work is intended to introduce a new data-plane for Spring architecture on IPv6 and we need to go back to the technical discussion on these options in Spring WG before this document is adopted by 6man.



If this work is unrelated to Spring (as claimed by the authors) and introducing a new Source Routing solution in the IETF, then the proponents of this solution need to follow the due IETF process by documenting its architecture, applicability, use-cases and requirements for other protocols to realize this new solution. That would help determine where the work should reside and how it should get done (perhaps a BoF?).



The motivation for following the IETF procedure like when introducing a new solution is to ensure a proper technical review from diverse expertise from whatever areas and WGs required and to provide a coordinated development of the solution across IETF (this is what was done by Spring and the other WGs that required new RHs).  Otherwise there is a chance for this adoption attempt being seen as a set of individuals getting a shortcut path for publishing their proposal as standards.



Thanks,

Ketan





-----Original Message-----
From: ipv6 <[e-mail]> On Behalf Of Bob Hinden
Sent: 16 May 2020 03:44
To: IPv6 List <[e-mail]>
Cc: Bob Hinden <[e-mail]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"



This message starts a two-week 6MAN call on adopting:



Title:          The IPv6 Compact Routing Header (CRH)

Authors:        R. Bonica, Y. Kamite, T. Niwa, A. Alston, L. Jalil

File Name:      draft-bonica-6man-comp-rtg-hdr-21

Document date:  2020-05-14



https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr



as a working group item. Substantive comments regarding adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.



Please note that this is an adoption call, it is not a w.g. last call for advancement, adoption means that it will become a w.g. draft.  As the working group document, the w.g. will decide how the document should change going forward.



This adoption call will end on 29 May 2020.



The chairs note there has been a lot of discussions on the list about this draft.   After discussing with our area directors, we think it is appropriate to start a working group adoption call.  The authors have been active in resolving issues raised on the list.



Could those who are willing to work on this document, either as contributors, authors or reviewers please notify the list.   That gives us an indication of the energy level in the working group

to work on this.



Regards,

Bob and Ole