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

Andrew Alston <> Fri, 22 May 2020 12:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34E8A3A0BA8 for <>; Fri, 22 May 2020 05:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HLpmhhL6aZ_1 for <>; Fri, 22 May 2020 05:42:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BF2343A0BAF for <>; Fri, 22 May 2020 05:42:51 -0700 (PDT)
Received: from ( []) (Using TLS) by with ESMTP id uk-mta-178-xDOcfGzOOk-uzR6S6Za0tw-1; Fri, 22 May 2020 13:42:45 +0100
X-MC-Unique: xDOcfGzOOk-uzR6S6Za0tw-1
Received: from (2603:10a6:803:bf::31) by (2603:10a6:803:c6::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23; Fri, 22 May 2020 12:42:44 +0000
Received: from ([fe80::ed68:9303:79e0:cc49]) by ([fe80::ed68:9303:79e0:cc49%4]) with mapi id 15.20.3021.026; Fri, 22 May 2020 12:42:43 +0000
From: Andrew Alston <>
To: "Pablo Camarillo (pcamaril)" <>, Bob Hinden <>, IPv6 List <>
Subject: RE: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
Thread-Topic: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
Thread-Index: AQHWKwY20Gv3GIPb+UeuPrnmxUhOiKiz/EeAgAAYHmA=
Date: Fri, 22 May 2020 12:42:43 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2c0f:fe40:3:2:5479:19f0:2967:32a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 6b243ee3-7e3a-4522-3cb2-08d7fe4d9f9a
x-ms-traffictypediagnostic: VI1PR03MB4990:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04111BAC64
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: MMFm0yM8CdfJNRpKkU5nL55QRIODb8LuoOXeCkUZ6AJorikxYfHi1Zr6esev+7tpq/d1OXjZodMZDjBK+hZE9ByEdKQpqk7SlaLoLeSvIV/VjBb58qumdPK//VbiXd9gbPNwhKTF3MNXd3V4k47yuKkapjrK5CjgROvJxnD9xTTVn48WnK0lUFl6Vr3wHU7S3SvF5vZqKoYKCgxRPK1v2rtcETF8uwIIQ30T2e6ypggFrgenBZ7IOcdMJAvtNp9/mO3N0Jv/L1XC1vuQbX04cfL6tNOjCtTPrhw4ZzgVip9Nx7FmFHFevtjk0w/C7N8rBqNfPbodQLRMJdqkKxPXyg==
x-forefront-antispam-report: CIP:; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM;; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(376002)(366004)(39860400002)(396003)(86362001)(8936002)(2906002)(76116006)(110136005)(64756008)(66476007)(66556008)(66946007)(66446008)(5660300002)(33656002)(66574014)(186003)(7696005)(71200400001)(6506007)(52536014)(8676002)(55016002)(9686003)(316002)(478600001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: nAak0tokXNe7rpSzAgTKbIg9lKvm43gwEFPg2iP4yixCskhqqeBZh9YyaUFj8bQFSv1HcvRqJ15UiCtPe+j8FjqhkCx5LWSh3mh39vxhHS6UlolYp2nDORA1D1LfX9FMFV2+x2ViDRYYLP/bOSx6Xwhf3aGdn0kWVfw6JzumHZhoImKGudVsRSRGJo66hs2x1xPIt+rKDWcJ/Bzj1ZlYt4fHqPW9sL6AG0fpILjOo1P6hqh1F+yFcyJ5OUGUxlQhlXlHBOVgx+ESYuzjoORxxgn+msYbc0+QTsBfkDE020x7JVJFQwdY/p15+m91e0XORn/+HMvvMnLmnghjMb1iErVbRaqoztWGWCHCPEJFg3ZiT05qmM2vlK7WmWI35gC+B2NYILz7A46wdeqel2GAw4peR6KJGx6ptCc9KrcVhOdfs2CzTBd4u3koYyi5W1XeLxOLsJaoLsf9K2TljA6fTCvrKeI9yII3zrIKsdcGMps09F9DnNBEtbnHXW4+CNHDljqCEoKDKyrukexvCB4yVbMRICCcUoO4c1e/YLOB6I8=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6b243ee3-7e3a-4522-3cb2-08d7fe4d9f9a
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2020 12:42:43.9227 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 5hDX+pZ6fzg5n+pB4OjCJURSR0+jq0RTErHwRH91D+6I/v7/w9sJ6k8XGfeZjOS+WLOdh6AhzBwfIURtiOa6ZLH/6A8LgEKFYdVmg0PelCQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB4990
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_VI1PR03MB50569538F51AB83A9766C70FEEB40VI1PR03MB5056eurp_"
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: Fri, 22 May 2020 12:42:54 -0000

Let me highlight the problem I have with what you are saying about the BCP.... Please note the italics.

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

Last I checked - an extensión header is not a protocol - it is a building block upon which protocols are built.  What would define a new protocol - is if we were coming out with something that fundamentally stepped out bounds of RFC8200 - or overloaded the address space in such a way that an address was no longer just an identifier - or inserted and removed headers on the wire in a way that another protocol wouldn't allow - or a host of other things - except - I don't see any of that happening here - have seen plenty of it in the context of other proposed work - but - not here.