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

Gyan Mishra <> Sat, 16 May 2020 23:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46E0F3A0BD6 for <>; Sat, 16 May 2020 16:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, 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 W7ivcA25Wg4e for <>; Sat, 16 May 2020 16:01:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 549943A0BD3 for <>; Sat, 16 May 2020 16:01:47 -0700 (PDT)
Received: by with SMTP id o5so6662824iow.8 for <>; Sat, 16 May 2020 16:01:47 -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=QyGMF2i3NUs2l/ArVfry5n+zvxRHxp6OfT6Pe2wqRrU=; b=ebTjYPjP2H/4DM2Q+7NT5HMGI3EjZGMipLbs5wRo01O/8z4UpXS5AkrV6eaJh6H71K rx43usRgJyxgqESgUtG7zXs3N4SBh1FE9cJE4Hyd+lYHL3my3ttYs7XWKc6ODlQsXrh6 5y7Ykqe8O21yjZqGw05SITgw6/7xMRtvtZPlvcTluJJKqQ2vuvNhN1PqNiIrTRp5rA8P r1CRVKAvogc1vHnjWO2VKdgfMPy17RsOxl2Yvtv7FVTfl9bpX6MJJRjpcOpciLZlS5dK XXoHjpGSVKDXTNMsg98zaKGRr6cvRMpH13MiCDoVhIgujM43l1kAzDaGMpMGB1E+bLMg OoIw==
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=QyGMF2i3NUs2l/ArVfry5n+zvxRHxp6OfT6Pe2wqRrU=; b=dwm7crGRvaAP59svSi9Fh2C5cacpAEFBYkEdq1cLIEcirKShsA3OZnS2CAX97MsXyg mLDf265MBaY5FPPcMvNLW3ZRs3zJvD6xWI3K7vA61EiafXgkCBpZy/p9JcYxCj+aBmoB 9QdaRfTLYQBNtQvAPc3k7/vmp5V6VKwr/0vrwH+GZR6eUqMwbewcsIQk5dZ1DPd+xaaY biUXYn6kgIWW9JF0VA0LPpK+1SoE50sw2nKF4PFGllsrFVm4mzopmFfOBscItfSNfRZS cC4u38TE5KtM8kQif63GS1RIA8SE6xU9kIU9fZY+w0mel5E+k3bdf1FQV5Yh39m26aI0 bJ3w==
X-Gm-Message-State: AOAM5324LnUSj8hi2X6GSdibDWA8bFjJ1BCK6/4Tyjo+fiyy8hlHjWsZ KvmkClVQtsg4wS0C8rQuP6WCla+h5AMmuULl9IM=
X-Google-Smtp-Source: ABdhPJzNB4B3xL7XaAd6tjlVZHqDNriW155gguAVPHFgN/PAxF+RELdQf9jPxB8Y+1tAxuNYrpquY9p+AbWnsbhQi9w=
X-Received: by 2002:a02:1c83:: with SMTP id c125mr9253574jac.112.1589670106337; Sat, 16 May 2020 16:01:46 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Sat, 16 May 2020 19:01:35 -0400
Message-ID: <>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
To: John Scudder <>
Cc: Bob Hinden <>, IPv6 List <>
Content-Type: multipart/alternative; boundary="000000000000ff976205a5cbe956"
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: Sat, 16 May 2020 23:01:49 -0000

Hi All,

As co-author and unbiased operators point of view I strongly and fully
support the CRH draft.

There has been a lot of discussion comparing CRH with SRH as well as with
the Spring document SRM6.  SRM6 is a another flavor or SR which is why it
falls in the Spring WG and is strictly and MPLS replacement technology as
is it’s competitor technologies SR-MPLS and SRv6

CRH introduces two new compact EH routing headers used with the IPv6 data
plane that does not have the security issues inherent with RH0.

The new RH CRH has ubiquitous use cases with its simplicity allows it to be
used for both public and private traffic steering as well as use with MPLS
replacement and non MPLS use cases.

The major gain from an operators perspective is that both CRH and SRM6
solve what SR  both SR-MPLS and SRV6 was touted to solve and was the
primary reason for any operator to migrate to this new technology “intent
based traffic steering” strict hop by hop strict path which has issues with
MSD(Maximum SID Depth).

So now with CRH compact 16 and 32 bit routing segment and SRM6 16 and 32
bit SID, steering can be accomplished without MSD issues and without
requiring another technology to make strict hop by hop steering even
remotely viable.

There is another  technology mentioned in some of the CRH threads namely
PPR (Preferred path routing) steering which uses the IGP path objects to
help both SR-MPLS and SRv6 with MSD issues to make those two technologies

1.3 <>.
Mitigation with MSD

   The number of SIDs in the stack a node can impose is referred as
   Maximum SID Depth (MSD) capability
which must be taken into
   consideration when computing a path to transport a data packet in a

Chunduri, et al.        Expires December 18, 2018               [Page 5]


   Preferred Path Routing (PPR) in IS-IS        June 2018

   network implementing segment routing.  [I-D.ietf-isis-mpls-elc
   defines another MSD type, Readable Label Depth (RLD) that is used by
   a head-end to insert Entropy Label pair (ELI/EL) at appropriate
   depth, so it could be read by transit nodes.  There are situations
   where the source routed path can be excessive as path represented by
   SR SIDs need to describe all the nodes and ELI/EL based on the
   readability of the nodes in that path.

   MSDs (and RLD type) capabilities advertisement help mitigate the
   problem for a central entity to create the right source routed path
   per application/operator requirements.  However the availability of
   actual paths meeting these requirements are still limited by the
   underlying hardware and their MSD capabilities in the data path.


On Sat, May 16, 2020 at 2:51 PM John Scudder <jgs=> wrote:

> Hi All,
> I support adoption of this document.
> Much of the discussion up to this point has focused on some variation of
> “we’ve already got one, it’s very nice”. And it’s true that we’ve already
> got more than one way to do source routing, so I think it’s reasonable to
> address why I think the WG should spend our time on yet another one.
> First, it’s self-evident at this point that source routing is of interest.
> This has always been true to some extent of course, that’s why we had RH0,
> and before that IPv4’s LSRR. But it’s increasingly true now.
> Second, there appears to be no serious dispute that doing source routing
> with big ol’ 128-bit IPv6 addresses in the source route is problematic, at
> least for some deployments.
> So that brings us to the “we’ve already got one” part. It’s true that
> there are proposals for more-or-less compact source routes. In all cases
> I’m aware of these bring with them a considerable amount of additional
> architectural and deployment baggage (uSID, for example) and may also drag
> along some extra layers of cruft that were introduced for expedient
> deployment (SRoMPLSoUDPoIPv6, say). CRH, by contrast, seems to me to be a
> minimalist building block; it does one thing, it’s small enough to spec on
> a napkin (well not quite) and describe in a short, simple, slide deck.
> Possibly most important for this WG, it’s a from-the-ground-up IPv6 design.
> It fits comfortably and naturally into the IPv6 paradigm. To me, none of
> the other solutions quite do this. Is it a complete architecture for
> deploying a service? Nope, and that’s fine. Neither is IPv6 itself.
> I don’t mean to turn this into a beauty contest, either, despite having
> mentioned certain examples above. You think your baby is beautiful?
> Stipulated, your baby is beautiful. But that doesn’t mean it should be the
> only baby the WG works on. Different tools for different problems.
> In short I think IPv6 should have a native, natural, minimal, composable
> way of doing packet steering. This document is a good starting point. Let’s
> do it.
> —John
> P.S.: Yes, I expect to actively participate in the development and review
> of the document.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------

Gyan  Mishra

Network Engineering & Technology


Silver Spring, MD 20904

Phone: 301 502-1347