Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[Gyan Mishra <[e-mail]>]

On Thu, May 28, 2020 at 7:46 AM Ketan Talaulikar (ketant) <ketant=
[e-mail]> wrote:

> Hi Ron,
>
>
>
> Some of the operators may not care about the SR name, but it is clear to
> me that the proposal in the CRH draft is a subset of Segment Routing (i.e.
> a reduced portion of Spring Architecture) that only supports prefix and
> adjacency SIDs as indicated by the two "forwarding methods".
>
>
>
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22#section-4
>
>
>
>    o  Forward the packet to the next-hop along the least-cost path to *>>>
> Prefix SID*
>
>       the next segment endpoint.
>
>
>
>    o  Forward the packet through a specified interface to the next *>>>
> Adjacency SID*
>
>       segment endpoint.
>
>
>
> Given the use of mapping IDs and mapping FIB, the proposal is comparable
> more to SR-MPLS than SRv6. It is better to do a holistic analysis of any
> proposal such as CRH that is introducing an MPLS label like mapping
> construct into IPv6 architecture - doing so should be considered as a
> significant change to IPv6.
>
>  Gyan> Ketan - you are misunderstanding the CRH architecture.  It uses the
> IPv6 data plane so is a variant of SRV6 and not SR-MPLS.
>
SR-MPLS reused then MPLS  data plane to create  fec bindings and uses label
> stacking for steering cSPF static lsp using the MPLS forwarding plane.
>
Operators that want CRH don’t want to go backwards and use SR-MPLS and have
the baggage of MPLS data plane as in general these are green field
operators use cases.

SR-MPLS he it’s place and where it shines and works well is for brown field
operators with existing MPLS LDPv4 deployments it’s a simple migration to
SR-MPLS.

For operators that already have an IPV6 core  or are running MPLS LDPv6
brown field deployments,  then then SRV6 or now CRH or SRM6 are the viable
options.

    CRH introduces a new RH similar to RH0 or any of      the other new RH
introduces for simple source routing which has been around since IPv4.

> CRH does not use the segments in the RH  to build the actual static hop by
> hop steered path as does SR-MPLS via SRGB block label stacking.
>

     Remember CRH is just another IPV6 Routing header.  However now instead
of copying the routing  segment into the segment list to the IPv6
destination address as done with SRV6 their is one simple extra step.  A
CRH-FIB entry is created manually that is referenced by the routing segment
and that entry is the IPv6 address that is copied to the next hop
destination address to steer the packet hop by hop.

By not storing the IPV6 address in the CRH RH you save all the problem with
MSD(Maximum SID depth) issues that occur in with SRv6 which really makes
SRV6 not viable for long strict SR-TE paths using adjacency sid that are
more then a few hops due to MSD issue.  SRV6 has its complex programming
with end prefix sid and end.x adjacency sid instantiations overhead that
makes SRV6 not viable for operators that don’t want to add in all the
additional complexity of the many compression drafts 6+ that exist today to
resolve the MSD issue.

Speaking from an operator perspective, representing Verizon a Tier 1
carrier, we have use cases as other carriers for intra domain very very
long static per VRF coloring of L3 vpn instantiated strict paths using
SR-TE and flexalgo.  However SRv6 by itself does not stack up and requires
use of the compression techniques for SR-TE per VRF coloring.

Unfortunately for SRV6 it failed to start out of the gate natively and
could not deliver on per VRF coloring of long strict paths using SR-TE
binding SID which is what the industry has been clamoring for.

The major benefit for CRH is that natively it can have very very long
strict hop by hop steered paths without requiring additional complexity
component for compression techniques to make it work as does SRV6.

SRv6 has its place in the industry and works well with  short cSPF paths
using prefix sid and staying away from hop by hop long strict explicit
paths.  And if you are willing to add the complexity of one of the many
compression techniques then so be it and that makes SRV6 viable as well as
an option for operators requiring long strict paths.

For Verizon we would use SRM6 as it is the full blown version of CRH as it
has the IGP extensions and supports SR-TE binding sid.

For the many use cases where a very long strict hop by hop path is required
and you want to use your existing IPv6 data plane, then CRH is the answer
as it is a low overhead means of source routing and works plug-n-play out
of the box using the IPv6 data plane.  No need for any of the many
compression techniques as required by SRv6 for building strict paths.

CRH is no different then RFC 8138 RH used for 6lo devices.

https://tools.ietf.org/html/rfc8138

The comments related to SR-MPLS over IPv6 RFC 8663 using tunneling
techniques RFC 4023 MPLS over GRE in IPinIP w/o GRE using IPv6 outer header
similar to Universal SID draft used for SRV6 to SR-MPLS interworking.
There are use case for using RFC 8663 but that in my mind would be for
Mirsky Universal SID interoperability use cases where you require
interworking between SR-MPLS and SRv6 the tunneling of SR-MPLS in outer
IPV6 header with RFC 8663.

https://datatracker.ietf.org/doc/html/draft-mirsky-6man-unified-id-sr-06

This is completely different from CRH.  If you need interworking you use
RFC 8663 with Mirsky draft or if you need a very simple low overhead
technique for source routing capability that works right out of the box
then CRH is the answer.

Kind Regards

> Ketan
>
>
>
> -----Original Message-----
>
> From: Ron Bonica <rbonica=[e-mail]>
>
> Sent: 25 May 2020 21:14
>
> To: Ketan Talaulikar (ketant) <[e-mail]>; Joel M. Halpern <
> [e-mail]>
>
> Cc: [e-mail]; [e-mail]; 6man <[e-mail]>
>
> Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR
> in CRH
>
>
>
> Ketan,
>
>
>
> It would not be fair to say that these operators  "wish to deploy a
> Traffic Engineering solution using a subset of Segment Routing".
>
>
>
> It would be fair to say that these operators  "wish to deploy IPv6 Traffic
> Engineering".  Some of these operators don't care about SR. Some are
> actively averse to SRv6. All they want is a Routing header.
>
>
>
>                                                                  Ron
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Juniper Business Use Only
>
>
>
> -----Original Message-----
>
> From: Ketan Talaulikar (ketant) <ketant=[e-mail]>
>
> Sent: Monday, May 25, 2020 5:21 AM
>
> To: Ron Bonica <[e-mail]>; Joel M. Halpern <[e-mail]
> >
>
> Cc: [e-mail]; [e-mail]; 6man <[e-mail]>
>
> Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR
> in CRH
>
>
>
> [External Email. Be cautious of content]
>
>
>
>
>
> Hi Ron,
>
>
>
> Thanks for that clarification.
>
>
>
> I note that you are not anymore saying "Are not interested in SR" like you
> had mentioned before the WG adoption call :
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/__;!!NEt6yMaO-gk!X2qW2zTZEbZRfBSE6c_KM-k7aIvZTIT9bycp3jyFJ3sTbf8MtGo4E_uGX7zYZ7lk$
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/__;!!NEt6yMaO-gk!X2qW2zTZEbZRfBSE6c_KM-k7aIvZTIT9bycp3jyFJ3sTbf8MtGo4E_uGX7zYZ7lk$>
>
>
>
> So, would it be fair to say that the operator that you are referring to
> below, wishes to deploy a Traffic Engineering solution using a subset of
> Segment Routing (i.e. a reduced portion of Spring Architecture) that only
> supports prefix and adjacency SIDs as indicated by the two "forwarding
> methods" that are referred to in draft-bonica-6man-comp-rtg-hdr?
>
>
>
> Thanks,
>
> Ketan
>
>
>
> -----Original Message-----
>
> From: Ron Bonica <rbonica=[e-mail]>
>
> Sent: 25 May 2020 09:03
>
> To: Ketan Talaulikar (ketant) <[e-mail]>; Joel M. Halpern <
> [e-mail]>
>
> Cc: [e-mail]; [e-mail]; 6man <[e-mail]>
>
> Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR
> in CRH
>
>
>
> Ketan,
>
>
>
> Please consider an operator who:
>
>
>
> - Wants a way to steer IPv6 packets through a specified path that includes
> many nodes (>8)
>
> - Does not want any of the following:
>
>         - A new VPN encapsulation technique
>
>         - A new service function chaining technique
>
>         - Network programming
>
>         - MPLS and uSID
>
>         - To encoding instructions in IPv6 addresses.
>
>
>
> These operators want a compact routing header, nothing more.
>
>
>
>
> Ron
>
>
>
>
>
> Juniper Business Use Only
>
>
>
> -----Original Message-----
>
> From: ipv6 <[e-mail]> On Behalf Of Ketan Talaulikar (ketant)
>
> Sent: Sunday, May 24, 2020 1:42 AM
>
> To: Joel M. Halpern <[e-mail]>
>
> Cc: [e-mail]; [e-mail]; 6man <[e-mail]>
>
> Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR
> in CRH
>
>
>
> [SNIP]
>
>
>
> I am looking for explanation of the "other ways" that CRH can be used
> (i.e. those outside the Spring architecture). I am trying to understand
> from the authors what would be the applicability of that solution, it's
> use-cases and it's requirements. That is what, I believe, will help us
> evaluate the CRH proposal in the context of this working call. That will
> help us answer these questions like the scope of the SID, 32-bit or 16-bit
> or something else and what the CRH-FIB is going to turn out like.
>
>
>
>
>
> [SNIP]
>
> ------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



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