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

Gyan Mishra <> Tue, 26 May 2020 23:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 48BC73A00D9 for <>; Tue, 26 May 2020 16:41:09 -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_REMOTE_IMAGE=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 fhCTU314MCbX for <>; Tue, 26 May 2020 16:41:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3372D3A00AE for <>; Tue, 26 May 2020 16:41:07 -0700 (PDT)
Received: by with SMTP id b71so22255276ilg.8 for <>; Tue, 26 May 2020 16:41:07 -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=F/2f23t41JFMoo7K5O5RBMkaqtgH6JW1+0AtVgCLLnk=; b=XlA8JnvnU4T+VYkV5CEQyr6Z817xM3vKxgVdKDL6sI7RZNtKGl/k/iras0l4RtDwII l2Xhd+/joNFP493wj75d/cQ1YzJy1IY65wVdkG0NdtIcOM9j1vFA3kJzihjWPhme/pk/ 04VRcMXIz6xQJf9wWzckYta5NB1O+Qq/T9TpZMaO/WbsGZ1/GJx0SCwNbDhmtNnDFs9s BpKHSkAqZhyN2I44bdbSE/yWLJWNleFnWyqq6jC9BIKWK7gbOn7x9wFc52TjlADjhTmE bd7eq2uHoo4vRShH1f1hKtJkCo2s01txDzr+D+0DZnlAW+QmLysVz6IJM4M5JeV3VDuy EoLw==
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=F/2f23t41JFMoo7K5O5RBMkaqtgH6JW1+0AtVgCLLnk=; b=ISmOAzym0zMqfIJxghpClF2BMFQIzadYdf+b6exdpONSkHheIUms36dPUlpNNEDjL4 kHnCcnz1x52nCmXlSLaaR2rhCR3YL1QSG5ZiwogwulroRpr2svjMcRq/TZEUW9jfBby/ HjFpqAm3So1qzQq5bf2BgB6LhwjPlyggG2C8kNenUxolhCu7jezfD08l/7Nvni+G2L0Y 8Ee3aatmKkDVS/u6DI/3Z8um7SaqIrdbtcWBYAGZOJYyVvh0Q4A7+YbiIElRpU5Fchn+ Py9oFfgpgA0LELEtqdgDm1qoGqCY/tCOzjeyv0BFs9N+2RxDVAhz9rSWy0jSFRhfqIO9 K37Q==
X-Gm-Message-State: AOAM531arko79QTzf84bXpHlzfi4kZnr5qMR7CE4wxpdLkwCbdOqhAEn oAo2sTLAbZFFUhs3QsVDMLJVPbmc+pgYLtluAc0=
X-Google-Smtp-Source: ABdhPJzARHxyYUqaG6iWcB22CAk7T42ykdpd/B7gevEaVd3a2S2a6Tk0YpFcGPZMx397ZCZOUmavdEW/Op7SbsrbNhY=
X-Received: by 2002:a92:bad0:: with SMTP id t77mr3727125ill.82.1590536466149; Tue, 26 May 2020 16:41:06 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Tue, 26 May 2020 19:40:54 -0400
Message-ID: <>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <>
Cc: Bob Hinden <>, IPv6 List <>
Content-Type: multipart/alternative; boundary="00000000000011348f05a695a102"
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: Tue, 26 May 2020 23:41:09 -0000


SR-MPLS reuses the MPLS data plane.  That is a nice brown field migration
option for MPLS customers that want to eliminate ldp state.

Don’t get me wrong SR-MPLS has its place and its for brown field MPLS
deployments and SRv6 has its place as well for cases mostly intra domain
where you don’t have inter domain traffic steering with very long strict
paths which run into SR-TE MSD issues.

For deployments that want to use the IPv6 data plane and have ubiquitous
use cases inter or intra domain and not have the extra baggage 🧳 of SRv6
programming SID depth overhead with strict paths or  SR-MPLS - MPLS data
plane which also has MSD SID depth issue with long strict paths = CRH
shines and is the best solution



On Tue, May 26, 2020 at 10:27 AM Henderickx, Wim (Nokia - BE/Antwerp) <> wrote:

> if you look into the details RFC8663 from a data-plane operation is very
> similar to CRH. It uses a tag and derives a destination ipv6 address from
> it.
> On top it if you look at the requirements which are discussed on the
> mailing list, the following is possible with RFC8663
> It can steer the packet through a specific path. Implementations exists
> which do well beyond 8
> No new VPN encapsulation is required
> No new service chaining needed and various options possible.
> Compliant to SPRING
> Uses MPLS but it is used here as a lookup tag, not any different than the
> CRH proposal. In essence if you look at the details you can implement this
> with a complete v6 infrastructure and use the tag as a steering function.
> And uses 32 bit.
> As such I don’t see why we need another encap to achieve something we
> already can do and is available in various implementations and is as
> efficient on the wire (looking at 32 bit, which is what people agree upon).
> So I would vote against adoption.
> On 16/05/2020, 00:14, "ipv6 on behalf of Bob Hinden" <
> on behalf of> wrote:
>     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:
> --------------------------------------------------------------------


*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD