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

From: Kalyani Rajaraman <[email-masked]>
Date: Wed, 27 May 2020 17:22:11 -0700

I do not support the adoption of this document.

Regards,
Kalyani

On Wed, May 27, 2020 at 4:14 PM Tetsuya Murakami <[email-masked]>
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=[email-masked]> 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 <[email-masked]> On Behalf Of Bob Hinden
> Sent: sábado, 16 de mayo de 2020 0:14
> To: IPv6 List <[email-masked]>
> Cc: Bob Hinden <[email-masked]>
> 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
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

---

From: Wanxiaolan <[email-masked]>
Date: Thu, 28 May 2020 07:11:23 +0000

Hi,

About the goal of CRH, there are many documents, and these documents addressed the same problem.  I personally don't see the merit of CRH than others.
Thus I don't support adoption of this document.

Thanks,

Xiaolan

-----邮件原件-----
发件人: ipv6 [mailto:[email-masked]] 代表 Bob Hinden
发送时间: 2020年5月16日 6:14
收件人: IPv6 List <[email-masked]>
抄送: Bob Hinden <[email-masked]>
主题: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

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.

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

-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, which is
intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender
by phone or email immediately and delete it!

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 28 May 2020 17:59:23 +0800

Hi, 6man
 
I do not support the adoption of this work.
CRH defines a new data plane which is not compatible with SHR and SRv6. In addition, I think the use cases and security considerations are not clear enough.
I think it's not the right timing to adopt CRH. Until now，there are other SRv6 and SRH compatible solutions, we should  compare the advantages and disadvantages of different solutions and choose the best one.
 
Best regards
Cong Li
 
----------
收件人: IPv6 List
抄送: Bob Hinden

 

 

 
Regards,
Bob and Ole

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 29 May 2020 01:45:46 +0000

I cannot support this draft.

CRH has many associated control plane and data plane drafts. For example, draft-bonica-lsr-crh-isis-extensions, draft-bonica-6man-vpn-dest-opt, draft-bonica-6man-seg-end-opt, draft-alston-spring-crh-bgp-signalling, draft-ssangli-idr-bgp-vpn-srv6-plus, etc. However, it is unclear how these various pieces of work fit together. The working group needs to properly understand the overall architecture before adopting this draft.

Regards,
Jakob.

---

From: Kris Michielsen <[email-masked]>
Date: Fri, 29 May 2020 22:48:16 +0000

I do not support WG adoption of this CRH draft.

Despite the claims of the authors, for me this draft simply proposes another method to compress an SR Policy SID list in IPv6 networks using an alternative dataplane implementation.
As many people have already indicated in this thread, several other SID list compression proposals are being discussed in Spring WG. This CRH draft cannot be adopted in 6man WG before being discussed in Spring WG.

Regards,
Kris

On 16/05/2020 00:14, "ipv6 on behalf of Bob Hinden" <[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:

    to work on this.

    Regards,

    Bob and Ole