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

[Gyan Mishra <[e-mail]>]

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 <[e-mail]> 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 [mailto:[e-mail]] On Behalf Of Bob Hinden
> > Sent: Saturday, May 16, 2020 6:14 AM
> > To: IPv6 List <[e-mail]>
> > Cc: Bob Hinden <[e-mail]>
> > 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
> >
> >  https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr
> >
> > 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
> [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