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

Greg Mirsky <> Wed, 27 May 2020 18:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0DB1F3A0850 for <>; Wed, 27 May 2020 11:47:06 -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 2pJCPPiaUzfi for <>; Wed, 27 May 2020 11:47:04 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A6C3B3A0844 for <>; Wed, 27 May 2020 11:47:03 -0700 (PDT)
Received: by with SMTP id v16so30260562ljc.8 for <>; Wed, 27 May 2020 11:47:03 -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=Cwp0BKUYMS87TqnaJsZwYuiYn3soJMwoKlgQ6FroXrk=; b=Oc07bXvTN8+XaazZAv428QilzqmofNDqgmN0bV9QQnO/B4WqwCkeXCEdHFtB5LLb4v //QzcQezOzLbblRLaDGN8m6UmNVDm+M6sj9LKQ+rCBzTITZe6kwVabnqXVEI5IKGJUX8 JpQBz4AHbttQXv/KeC/Zfbzigz8jVil9NY2lfGCJS3MwRJ87SIV2rhxKgIMZ7WvH1dcj ikbUCrImO8Q/Cr0rR/PTFASuZ90p41hK1fTtNpmpA1DytpVWlsUwbsr2jBBI7ZqDLJ/z 7EwdPiOvmqipKPTeio5T73bs/0zkOE9126RQBVM9TsbpVi1tQLaCufXgx/gbiD0ACsQc WGpg==
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=Cwp0BKUYMS87TqnaJsZwYuiYn3soJMwoKlgQ6FroXrk=; b=QBZjYXbCLuxXrmtnuGzjjB0Plfkn6rky02YH7ifqiJyjHgoI9sH40GAfwvw3sPrHi2 5TDfS5UWwTOis/OAzPWJzYn53xQP7LrL/RpGdQK83qHM6GYCPpJhjcGQZYRWejoVCarH 8Qn1jhjCX69/cuFoDtUdta8Ivpp8friXNYiUtyPoh9Ya3fZCumzfO/H+k4X1vJlvtDAJ H6mfDDb0KiNJdXhvfXD8Ocn8wOYX14WAtbkIfN9/hz7xBKWQKQYpEV3nBinjLVq4Gejy MvWub0z3U+YPZvXWYe4m4XR8k3J9H8ZcDVtTwcUXJZ7uIrdHETmclr4X2IBBzDP+WY2R oRGA==
X-Gm-Message-State: AOAM533u3WG7qxh7YCSstiXWNiiQqv50cFcdMBzV9YypP5d+rrdd0nif sbq27LPi1VOYoveMKNux8oHpNk30QLvdCkfkQkU=
X-Google-Smtp-Source: ABdhPJw1hh96lVaVPExxT+exkY2xVTlO5d2FzHXZRpkCz7Hn5pC8/a58AmJ6ma+HH5vOdySj0dtt+h/rMBfp8bA6clM=
X-Received: by 2002:a2e:a30c:: with SMTP id l12mr3805219lje.428.1590605221711; Wed, 27 May 2020 11:47:01 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Wed, 27 May 2020 11:46:49 -0700
Message-ID: <>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
To: Gyan Mishra <>
Cc: Mach Chen <>, IPv6 List <>, Bob Hinden <>
Content-Type: multipart/alternative; boundary="00000000000037d42d05a6a5a387"
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 18:47:06 -0000

Hi Gyan,
one comment to

CRH uses a new CRH-16 or CRH-32 RH which has a list of routing segments.
The routing segment is an index which identifies a CRH-FIB entry contains
an IPv6 address of the next hop to steer the packet.  The CRH-FIB can be
populated via CLI locally or PCE controller centralized model  or
distributed model via IGP extension.

I believe that is equally applicable to the Unified SID proposal
<> that is
based on RFC 8754. The Unified SID does not introduce new RH types but
rather explicitly expresses the length of SID/index in the Flags field of
SRH. Would you agree that functionally CRH and the Unified SID are very


On Tue, May 26, 2020 at 8:40 PM Gyan Mishra <> wrote:

> CRH is not a mapping based solution like SR-MPLS where each segment or SID
> is a label allocated from the SRBB to build the dynamic path or binding sid
> to create a SR-TE per VRF tunnel color mapping.
> The only thing in common between CRH and SRv6 is they both utilize the
> IPv6 data plane and they both can be used for traffic steering.  How CRH
> achieves the traffic steering is completely different then SRv6.  SRv6
> performs steering natively using SRH and prefix SID end instantiation and
> adjacency SID end.x instantiation and for per VRF custom traffic coloring
> and use of flex algo utilizes SR-TE binding SID at the source node to
> instantiate the steered path.
> CRH does not use labels or index  for the segments in the SRH header as
> does SR-MPLS which uses MPLS labels as SID for hop by hop steering or uses
> an IPV6 128 bit address or a compressed or index based compressed IPv6
> address as the SID instruction for steering.
> CRH uses a new CRH-16 or CRH-32 RH which has a list of routing segments.
> The routing segment is an index which identifies a CRH-FIB entry contains
> an IPv6 address of the next hop to steer the packet.  The CRH-FIB can be
> populated via CLI locally or PCE controller centralized model  or
> distributed model via IGP extension.
> The CRH draft is a component of SRM6 Spring draft which is why it states
> that the CRH-FIB can be populated via IGP.  However the CRH draft can act
> independently and a lean low overhead steering method and in that scenario
> only CLI or PCE methods are available to populate the CRH-FIB.
> In the context of Spring,  SRM6 draft has the same capabilities as SRV6 or
> SR-MPLS and uses the same binding sid with SR-TE for per VRF coloring with
> flex algo for steering Inter or intra domain in a service provider network.
> CRH is a very lean draft that does not have those same capabilities of
> steering with SR-TE but it does support flex algo as that is IGP extension
> independent of SR.  All the steering by CRH is done natively using the new
> routing headers.
> Kind Regards
> Gyan
> On Tue, May 26, 2020 at 10:25 PM Mach Chen <> wrote:
>> If the draft intents to provide a mapping based Segment Routing solution,
>> there are SR-MPLS, SR-MPLS over IP exist, and there are implementations
>> that work very well; seems no need to define a new one;
>> If the draft intents to provide a header compression solution to SRv6,
>> there are several candidate solutions under discussion; seems it's
>> premature to consider just adopting one and ignoring others;
>> If the draft intents to be one of the building blocks of a new competing
>> IPv6 based Segment Routing solution, given the community has been working
>> on SRv6 for so many years, it needs to prove that the new solution has much
>> better merits than SRv6;
>> So, based on the above, I do not support the adoption at this moment.
>> Best regards,
>> Mach
>> > -----Original Message-----
>> > From: ipv6 [] On Behalf Of Bob Hinden
>> > Sent: Saturday, May 16, 2020 6:14 AM
>> > 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:
>> --------------------------------------------------------------------
> --
> <>
> *Gyan Mishra*
> *Network Solutions A**rchitect *
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------