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

[Mach Chen <[e-mail]>]

Hi Gyan,

Please see some responses inline…

Best regards,
Mach

From: Gyan Mishra [mailto:[e-mail]]
Sent: Wednesday, May 27, 2020 11:40 AM
To: Mach Chen <[e-mail]>
Cc: Bob Hinden <[e-mail]>; IPv6 List <[e-mail]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"


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.

[Mach] IMHO, except for the place where to put SIDs list, I don’t think there are essential difference between CRH and SR-MPLS over IPv6. For SR-MPLS, the label can be from SRGB or SRLB, for CRH, the SID can be domain wide unique or local significance.  From forwarding point of view, the label or SID is just an identifier, no matter for SR-MPLS over IP or CRH, a node just maps a label/SID to an IP address and forward the packet.

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.

[Mach] This is one of my concerns, both can provide the same functions but with different ways. Given that the community has spent a lot of energy on SRv6, why do we need to re-invent a new one? A straight forward way is to optimize/enhance the existing solution. If SRm6 and SRv6 change their places, I will have the same comment for SRv6.

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.

[Mach] IMHO, the above does not make CRH special and supper, it just define a new way to achieve the goal.

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.

[Mach] As above, I am not sure it’s necessary to define a new solution to provide the same capabilities that an existing solution already supported.


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]<mailto:[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]<mailto:[e-mail]>] On Behalf Of Bob Hinden
> Sent: Saturday, May 16, 2020 6:14 AM
> To: IPv6 List <[e-mail]<mailto:[e-mail]>>
> Cc: Bob Hinden <[e-mail]<mailto:[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]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD