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

[Kalyani Rajaraman <[e-mail]>]

I do not support the adoption of this document.

Regards,
Kalyani

On Wed, May 27, 2020 at 4:14 PM Tetsuya Murakami <[e-mail]>
wrote:

> Agreed. I do not support the adoption of this document…
>
> Thanks,
> Tetsuya
>
> On May 22, 2020, at 4:07 AM, Pablo Camarillo (pcamaril) <
> pcamaril=[e-mail]> wrote:
>
> Bob, Ole,
>
> I do not support the adoption of this document. Reasons below:
>
> 1.- 6man is an IPv6 maintenance group. This proposal is defining a new
> routing header with no sort of document, input or requirement from the
> Routing Area.
> While certainly this group does not need any sort of permission from
> routing, uncoordinated protocol development is harmful. This point has
> already been made by others.
>
> 2.- This is not a standalone document. Despite from the document stating
> that the CRH-FIB will be populated by means of CLI, I think everyone in
> this group would oppose to that; configuring all 2^16 labels manually in
> all routers is an operational burden…
> We will need control plane extensions such as
> draft-bonica-lsr-crh-isis-extensions, but again, we do not have the
> requirements or use-cases from Routing Area as to know what we need to
> support/build.
>
> 3.- The authors have not provided a document discussing applicability,
> use-cases or requirements. This approach of building a solution without
> understanding the problem is in my opinion utterly wrong.
> This is already causing confusion as for example in the 16b vs 32b
> discussion.
>
> Also, from BCP22:
> “*   Standards track documents must include a description of the
> protocol.*
> *   This description must address the protocol's purpose, intended*
> *   functions, services it provides, and, the arena, circumstances, or*
> *   any special considerations of the protocol's use.*
>
>    The authors of a protocol specification will have a great deal of
>    knowledge as to the reason for the protocol.  However, the reader is
>    more likely to have general networking knowledge and experience,
>    rather than expertise in a particular protocol.  An explanation of
>    it's purpose and use will give the reader a reference point for
>    understanding the protocol, and where it fits in the Internet.  The
>    STD 54/RFC 2328 was recommended to the STDGUIDE working group as
>    providing a good example of this in its "Protocol Overview" section.
>
>    The protocol's general description must also provide information on
>    the relationship between the different parties to the protocol. This
>    can be done by showing typical packet sequences.
>
>    This also applies to the algorithms used by a protocol.  A detailed
>    description of the algorithms or citation of readily available
>    references that give such a description is necessary.”
>
> In summary, we are polling whether to adopt a document that is ignoring
> BCPs, doing uncoordinated development within the IETF areas, and with a
> bunch of unanswered technical questions on the mailer.
> Additionally, I believe this proposal has issues with scalability, and
> requires additional ASIC resources as recognized by the authors [1].
>
> Thanks,
> Pablo.
>
> [1].-
> https://mailarchive.ietf.org/arch/msg/spring/aLhIQ2btTfNkJ4ghruuXbm3zY30/
>
>
> -----Original Message-----
> From: ipv6 <[e-mail]> On Behalf Of Bob Hinden
> Sent: sábado, 16 de mayo de 2020 0:14
> 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
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>