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

[Greg Mirsky <[e-mail]>]

Hi Tom,
I agree that introduction of a new interpretation of a two bits-long field
in Flags creates a backward compatibility issue. We're planning to have
companion documents that explain how extensions to IGP and BGP-LS
advertise the new capability, i.e., support of the Unified SID.

Regards,
Greg

On Wed, May 27, 2020 at 12:08 PM Tom Herbert <[e-mail]> wrote:

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