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

[Tom Herbert <[e-mail]>]

On Wed, May 27, 2020 at 11:47 AM Greg Mirsky <[e-mail]> wrote:

> Hi Gyan,
> one comment to
>
> 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.
>
> I believe that is equally applicable to the Unified SID proposal
> <https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/> that
> is based on RFC 8754. The Unified SID does not introduce new RH types but
> rather explicitly expresses the length of SID/index in the Flags field of
> SRH. Would you agree that functionally CRH and the Unified SID are very
> close?
>

Greg,

Per RFC8754, SRH flags "MUST be 0 on transmission and ignored on receipt".
That means if a Unified SID SRH is sent to a legacy implementation the
receiver will ignore the flags and hence incorrectly process the SRH as
being a list of 128 bits as specified in RFC8754. Similarly tag and TLVs
can be ignored on receipt. Fundamentally, SIDs in SRH are 128 bits and
there's really no way to change that since there's no field in the header
that could serve as a robust codepoint for SID size. I think this is going
to be an issue with any attempts to compress SIDs and still use the same
SRH routing type, however I also don't think this is really a problem since
there are plenty of available routing types left to be allocated, so the
routing type can be used to indicate the SID size (as CRH proposes with two
routing types for 16 and 32 bits).

Tom


> Regards,
> Greg
>
> On Tue, May 26, 2020 at 8:40 PM Gyan Mishra <[e-mail]> wrote:
>
>>
>> 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
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>