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

Martin Horneffer <> Wed, 27 May 2020 20:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FEC03A0B87 for <>; Wed, 27 May 2020 13:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (public key: not available)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id koHIypbADqup for <>; Wed, 27 May 2020 13:33:10 -0700 (PDT)
Received: from (OldBailey.lab.DTAG.DE []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E6C853A0B7B for <>; Wed, 27 May 2020 13:33:09 -0700 (PDT)
Received: from [] (localhost []) by localhost (Mailerdaemon) with ESMTPSA id 2DEB4C968C for <>; Wed, 27 May 2020 22:33:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1590611585; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=je8VSJEkk5SaO2vvodG6wCv0/+F9jLmaj7dZSohY61A=; b=lYU+YgnpEMhzYJd3fNqZfBd9YqaV9CREkTKPKN7DaSWIIVii1NeUOrWX9Dh7ojoQdAPEDU 1kyHOcvbOCZYmS+batFlhnP57b0qxg+TNbPO/5d00Os3e7FT99/jFn4rAof/S0/Yvpiyyp YuouZ0L4AwcgvvRwSFUmNFC7V8tRj7OOjHxAvdOqhAgur6Ln5vBueAy+mGLtXMQLj7r4Qi xDAUqXNUFirPDedxvU9rizHzaUBGxRHXHXk8nxOID9XLVcM5yZQlAIbWKRK8JSlTlKcK1V 8JngWwtZKIA+PutlHdJNuVg/P6OQpmPazw8E+zA7XoxvSZ3LpF/pU3WQVQWScw==
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
References: <>
From: Martin Horneffer <>
Message-ID: <>
Date: Wed, 27 May 2020 22:33:04 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Last-TLS-Session-Version: TLSv1.3
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 20:33:19 -0000

Dear working group,

as an operator I am currently working on getting SR-MPLS into a 
multi-AS, multi-service global core network. Managing a SID mapping for 
all relevant nodes and services has been done, but definitely was a 
serious effort in our environment as many different (company internal) 
parties need to be coordinated.

SRv6 seems to me like a great opportunity for further network technology 
consolidation in the future, covering all kinds of network domains. This 
opportunity is, in my eyes, only based on the huge and universal address 
space offered by IPv6. Any continued or even additional need to map 
topological nodes or services to SIDs would, in my opinion, thwart the 
main opportunities of SRv6. In comparison to the relatively simple 
deployment of SR-MPLS in the mere core network, any end-to-end 
deployment of SRv6 throughout all core, aggregation and access network 
domains as well as data centers and service areas would require even 
more organizational units to agree on a new central SID registry. Thus I 
believe the many SRv6 use cases will only practically work when _not_ 
relying on new maps or tables for any kind of SID.

Also the CRH does not solve a problem that I would consider as serious. 
 From all scenarios we have seen so far and all research we have seen I 
seriously doubt that more than a few segments will be needed. And even 
if the number of segments needed came close to something like 10, I do 
_not_ consider the mere overhead of the SRH of 168 byte a serious problem.

Overall I don't see how CRH solves more problems than SR-MPLS with a 
IPv6 control plane would do. And that would really be a less complex 

I would truly prefer implementors to concentrate on everything that is 
need to complete use cases based on the plain SRH, rather than inventing 
a new routing header every other year.

Thus I do _not_ support wg adoption of this draft.

Best regards, Martin

Am 16.05.20 um 00:13 schrieb Bob Hinden:
> 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