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

Tetsuya Murakami <> Wed, 27 May 2020 22:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1784F3A0D37 for <>; Wed, 27 May 2020 15:42:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Status: No, score=-2.087 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_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 GAXLNv-VToHd for <>; Wed, 27 May 2020 15:42:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1CE0A3A0D2D for <>; Wed, 27 May 2020 15:42:20 -0700 (PDT)
Received: by with SMTP id j21so12476084pgb.7 for <>; Wed, 27 May 2020 15:42:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=1Iu9dwlXUtZl/tdQ0twN5TvwG73z+2uecOXxMajF8sY=; b=Q3915EyB6k8DtqSKlabFxbE0e01otmlS/4/uiJo42nKLJ8W0YfwtUU3umt3peIHIF0 RREyiNCKGlPEfHn292BlTNN0Woymc1UH5nV/0563O6/6AUyiUWceafgy8YAy/Butnxun nLicMcfnGk6szJ5Pps8hPBxZtlBm20x4Cz31erPtCE6bvjC0XJeBDqkejGYQ0DkSagPn CyPopqCyekgj2Na4goT+u/Ongvpj3msCemta0B9bMxLYLDlPBXkLv6NpPbYxH9ai/TpW qcmGu8oLiOwdqMPwAoP4M0kVEGNitJU9a+Srf8WLZlEN2gs0dx5ZVbfInyyu9JqyrKvK vnsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1Iu9dwlXUtZl/tdQ0twN5TvwG73z+2uecOXxMajF8sY=; b=UOxW22bMHkysKtA3DD+3wnBZ3H4y1ngoELq20qmfsG1nZqldf6yI7B0mR4WgSno14q wXR5Y48Ing1bfelsL+ebDfcsPLfZcoHk3LaZ0vLJ4E8QITSKQ8Fo89EoK7lKTBtZEPJt kf500ZowVYDtq2dKxS/mq4DN2iSQqlLXwyd+PvRdI3+1DX+KbmLDPhQiczjSVDD854q+ CqzlmF6v/D/cA7rZuDn2HBwiSv54QnvT9v/QJEL0fiDewRjdOn0KsxHgCNNqfKtMh4DQ T5JpkpVmET1ap8uwMdLgcJHmjWdT7PVl54rqAstfBetiqxD0fA7NVQyyz9NUU5mZKG+7 NNNQ==
X-Gm-Message-State: AOAM533w5WShHCqHPKjux7MiQ6UzyUpePv7GcDZjJxmK/TIallr+dxbP 8zIW4k3LHn80W23Q/D031r2PRrR1
X-Google-Smtp-Source: ABdhPJwuLkuo7Kiwjd9mFenwDOucNDdp7hY/t0PWVn4x7imMV/zN3GjOj9/YLleHTgRj1sZefvqGVg==
X-Received: by 2002:aa7:959b:: with SMTP id z27mr15764pfj.96.1590619339623; Wed, 27 May 2020 15:42:19 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id 62sm2965186pfc.204.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 May 2020 15:42:19 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_77CB0AFC-2A9A-49FD-B739-BD7503413343"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
From: Tetsuya Murakami <>
In-Reply-To: <>
Date: Wed, 27 May 2020 15:42:11 -0700
Cc: IPv6 List <>
Message-Id: <>
References: <> <>
To: Bob Hinden <>, Ole Troan <>, "Pablo Camarillo (pcamaril)" <>
X-Mailer: Apple Mail (2.3608.
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: Wed, 27 May 2020 22:42:22 -0000

Agreed. I do not support the adoption of this document…


> 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:
> --------------------------------------------------------------------