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

[Gyan Mishra <[e-mail]>]

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
viable.

https://tools.ietf.org/html/draft-chunduri-isis-preferred-path-routing-00#page-17


1.3 <https://tools.ietf.org/html/draft-chunduri-isis-preferred-path-routing-00#section-1.3>.
Mitigation with MSD

   The number of SIDs in the stack a node can impose is referred as
   Maximum SID Depth (MSD) capability
   [I-D.ietf-isis-segment-routing-msd
<https://tools.ietf.org/html/draft-chunduri-isis-preferred-path-routing-00#ref-I-D.ietf-isis-segment-routing-msd>],
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]

------------------------------

  <https://tools.ietf.org/html/draft-chunduri-isis-preferred-path-routing-00#page-6>Internet-Draft
   Preferred Path Routing (PPR) in IS-IS        June 2018


   network implementing segment routing.  [I-D.ietf-isis-mpls-elc
<https://tools.ietf.org/html/draft-chunduri-isis-preferred-path-routing-00#ref-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.




Gyan



On Sat, May 16, 2020 at 2:51 PM John Scudder <jgs=
[e-mail]> 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
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]