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

Kalyani Rajaraman <> Thu, 28 May 2020 00:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDDC23A0DEE for <>; Wed, 27 May 2020 17:22:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.837
X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tKTP2E3KvFv6 for <>; Wed, 27 May 2020 17:22:24 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F5183A0E0E for <>; Wed, 27 May 2020 17:22:24 -0700 (PDT)
Received: by with SMTP id z5so30182602ejb.3 for <>; Wed, 27 May 2020 17:22:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/wzgPsmyVjKav/kH0sJ8ttd6Ln3hEP+71jvfaKDXpr8=; b=O+e5b218pC5NeIfLTqbNQrnLn0XtfLsAAfc79DkbE0kUaRVcbDJC7WIiIkgxoijyIJ QVUjd2EDGn+gfD8fxHkJRNiS4L/DrjCyA/kexAEghCr+N9wBV4g7atA+CB2QbwB7c7PS sPmUCNvPI58OiilX6hznA4Cwums6YCQookzyVMWSr5x0WU4ug4lxfmrUdTZMYfOmFrk6 Wh+U8e22+TbI/s2mtHgFzSYcyq99NTnFt8l1x4AGyoXWmVzTtTWgHVIhKLtWw3PWKyA4 C3Pj5ITo9xrIp9TNbIxDkHWz2WmKt1KBedo44ZEpB44TKpgLUCBSN3FY6gj7yUuwcH4a e+Kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/wzgPsmyVjKav/kH0sJ8ttd6Ln3hEP+71jvfaKDXpr8=; b=Ae4WZ1rSUWm01yiIHAfBGdQz5IXDw1FBwXEEvVx1Ndg26GSBRjCqxQHvJixjUlcjYN Rv1iApOH1DvnIdCojLCMYbTO2IRnLwC8V6+EFv4BH1ALCtDcaz+6pQydyyn+vWn81SYY 6wt8iPIlfnqRsLqVYIAdBZB8zQDTYawYLAKa+Unr5drSfLSAwM3042pJmzZ1rku5uAQf TiM713HtWq5q2qbQLCOV2ZJNZRKylIoBmGtc0p1cQ+YHbOEL22WgLSgTBcoxx6aD/74t QF5TQTPZLI/QrkzBFcVc3NUcdva5s1wOsNsvGd4ovdA/UDzFy7ItOeEvic4HV4X8b1rZ LSrA==
X-Gm-Message-State: AOAM531O/1z1iTAHeZ6GGr8S2Dd91BAq4m5TLdgQEK0amBaCmqsKasma ouXIkrh8NBYXi5BU2suOgaWockrkX1uITihiIHQ=
X-Google-Smtp-Source: ABdhPJzc3H70Rut3yPfbRWOAW65bP1gneWvrU9vBDtp8kKHqHn6OUd3hV6NrbfP/ExNnTsmpvb48Ho//gBlaMO4UnaU=
X-Received: by 2002:a17:906:2e55:: with SMTP id r21mr753391eji.338.1590625342990; Wed, 27 May 2020 17:22:22 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Kalyani Rajaraman <>
Date: Wed, 27 May 2020 17:22:11 -0700
Message-ID: <>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
Content-Type: multipart/alternative; boundary="0000000000008a2c7105a6aa5243"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 May 2020 00:29:50 -0000

I do not support the adoption of this document.


On Wed, May 27, 2020 at 4:14 PM Tetsuya Murakami <>

> Agreed. I do not support the adoption of this document…
> Thanks,
> Tetsuya
> On May 22, 2020, at 4:07 AM, Pablo Camarillo (pcamaril) <
>> 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].-
> -----Original Message-----
> From: ipv6 <> On Behalf Of Bob Hinden
> Sent: sábado, 16 de mayo de 2020 0:14
> To: IPv6 List <>
> Cc: Bob Hinden <>
> 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
> 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
> Administrative Requests:
> --------------------------------------------------------------------