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

"Voyer, Daniel" <> Thu, 28 May 2020 14:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3C3D3A0F22 for <>; Thu, 28 May 2020 07:50:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 41rfc0v2a5jE for <>; Thu, 28 May 2020 07:50:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 06D9B3A0DF3 for <>; Thu, 28 May 2020 07:50:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;;; q=dns/txt; s=ESAcorp; t=1590677425; x=1622213425; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=xD+pNTw5KJ51rKel46iHpwovdvet+51LUN5GtFcGk0g=; b=BW5gdr7xLa8eTJbtgROa+Gg+DHPDaqelTxROMNKNsFcoCRB1PH4f/zmg 8XGsQ4tMrEmzu7rhjztZYxF98C8virS11tmAh8qE67Wzd5ZS335bJ4R17 o6C7jHB5FaRrWFkzcmh+xkWzkFgcWiHvAbJNgCdfpu4v6+kXwUZBX2FhM YdSwHnw+dUUPsdYU06Icd9ooTR6NbJYC5AWVvOvEvRT9A7svRU5abHK2H 3uwaph+JGvInPULN3o/CrCxwHdEazPiAr3jMeTUDRt520aFfiVgCn4W3G CRK0gMYS6gvPqcbClZGg1SotYfexIcxeMSRpEVibWNwaHSylq3TjCg0sC Q==;
Subject: RE: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
Received: from unknown (HELO ([]) by with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 28 May 2020 10:50:23 -0400
Received: from (2002:8eb6:120b::8eb6:120b) by (2002:8eb6:1225::8eb6:1225) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 28 May 2020 10:50:23 -0400
Received: from (2002:8eb6:120e::8eb6:120e) by (2002:8eb6:120b::8eb6:120b) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 28 May 2020 10:50:22 -0400
Received: from ([fe80::985f:63a7:1da1:aa02]) by ([fe80::985f:63a7:1da1:aa02%22]) with mapi id 15.00.1497.006; Thu, 28 May 2020 10:50:22 -0400
From: "Voyer, Daniel" <>
To: Martin Horneffer <>, "" <>
Thread-Topic: [EXT]Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
Thread-Index: AQHWNGY1G640aasidES0uH9l7u2USai9ldEA
Date: Thu, 28 May 2020 14:50:22 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/16.37.20051002
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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 14:50:27 -0000

Hello Working Group,

I would like to echo Martin on this, as I observe that we have about the same track record for SR-MPLS into multi-AS - and huge effort to coordinate multi-network domain SRv6 Architecture. I haven't seen, yet, deployment use cases that can only be achieve by CRH - and not by SR-MPLS (w/ IPv6)and SRv6. 
It would be nice, and a good 5 years of effort investment, to finish standardizing SRv6 before adopting a somewhat  "similar but not quite" new proposal. 

So, at this point I do not support working group adoption of CRH.


On 2020-05-27, 4:34 PM, "ipv6 on behalf of Martin Horneffer" < on behalf of> wrote:

    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

    IETF IPv6 working group mailing list
    Administrative Requests:
    External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints