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

Tom Herbert <> Wed, 27 May 2020 19:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 117C33A0903 for <>; Wed, 27 May 2020 12:08:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 QWYlvbzge_hV for <>; Wed, 27 May 2020 12:08:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 44FCF3A089D for <>; Wed, 27 May 2020 12:08:15 -0700 (PDT)
Received: by with SMTP id z80so683193qka.0 for <>; Wed, 27 May 2020 12:08:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T4dYjNXA90j+MgJsnfNcjvQs1fRqJpilk17KzWrsrQQ=; b=CoMpPAHg6Rm49NHuXBCXdEqeHUAVVSEz6qIFLEu0BmhkXDds0IxOqlcTbG0UHhA8mv UkEYz/TQpj3JWGVP/x5TbNXWXcyeMrkREyhIzpj4BTioPXC603M+HTNQtDzVEdzgVmV1 j0twDfF2O7RCFC87QU0XReHwtJc9Z6up4iOETY9DPiEPLeo1jEvE38PjAI8afQJS/toE 72NVQWhw9px5eYoDJHh3d6HKuh7i+80L+allpb5Rs4IwYeaop/nkdi99JFYkaQNsZv67 A9nuQGNVPERqrXD4DA8EMa2Qu3v/BID/CsQ1WHBRPBwsaPJ1aP50RoelOKLWoKZEpAZB GxPA==
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=T4dYjNXA90j+MgJsnfNcjvQs1fRqJpilk17KzWrsrQQ=; b=Fi4kHlGKBtcL3O7wi15sMbUfJGhP2TR7V1m9VNC2wsLmVuJ62UnMJHZquqaGDMCDma i7R4UeEPxs247bkox9Ogt9jh7tXJbHCIxJpNbG0nD3liLWIgQ2ANR/fGyt3XTbbRJ+nQ IpLvg5U/jdk4D1ATlQ56CdegN43xHSpgCUR0uk3aKmhREUfQgkv136tYMgfE3wkYyZHM SJPnhneuS1cM3hbIMvgzfDWlCPUqloTKjFctLe8mRblUAGnKwz7N3OECyV5nSDE6DPmY kCAlXDZQDHZ2I2IMman+eKO01xYQylx7Ore1iLntNFMVoCFmmsfsT7QTJ0KjJ1341Gpa ZxdQ==
X-Gm-Message-State: AOAM531NOTlBpwNhS9UQRytqZJUjDwheJksnk43yhGZXKN4qLuP44CG1 d9QZRA+ys1GXQx5rRM/fphblSSTKtyGmxkm7WmTaKQ==
X-Google-Smtp-Source: ABdhPJxl1pI89ATaRsR1Ud4Wf324zZHOFs/kPkx0OHp8y12Ie5MZZ6Yve/UWTog2PfzFmG0kbR6mSlaSQumdV99UlT0=
X-Received: by 2002:a37:445:: with SMTP id 66mr5469064qke.146.1590606493775; Wed, 27 May 2020 12:08:13 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Wed, 27 May 2020 12:08:02 -0700
Message-ID: <>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
To: Greg Mirsky <>
Cc: Gyan Mishra <>, Bob Hinden <>, IPv6 List <>
Content-Type: multipart/alternative; boundary="0000000000000a0d6d05a6a5ef17"
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 19:08:18 -0000

On Wed, May 27, 2020 at 11:47 AM Greg Mirsky <> wrote:

> 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
> close?


Per RFC8754, SRH flags "MUST be 0 on transmission and ignored on receipt".
That means if a Unified SID SRH is sent to a legacy implementation the
receiver will ignore the flags and hence incorrectly process the SRH as
being a list of 128 bits as specified in RFC8754. Similarly tag and TLVs
can be ignored on receipt. Fundamentally, SIDs in SRH are 128 bits and
there's really no way to change that since there's no field in the header
that could serve as a robust codepoint for SID size. I think this is going
to be an issue with any attempts to compress SIDs and still use the same
SRH routing type, however I also don't think this is really a problem since
there are plenty of available routing types left to be allocated, so the
routing type can be used to indicate the SID size (as CRH proposes with two
routing types for 16 and 32 bits).


> Regards,
> Greg
> 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:
>> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------