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

[Tom Herbert <[e-mail]>]

On Wed, May 27, 2020, 1:33 PM Greg Mirsky <[e-mail]> wrote:

> Hi Tom,
> thank you for the suggestion. I think that is one of the possibilities if
> the WG decides to ask authors to work on the joint draft. At the same time,
> we need to recognize those other proposals to address the need (it seems
> that there's an implicit agreement) of a shorter SID in SR over IPv6 do
> change, as I understand them, the interpretation of the Segment field in
> the SRH.
>
Greg,

Yes, I've looked at the G-SID and vSID proposals also, and it does appear
they are also changing the format SRH without a using a new routing type. I
don't see these proposals are feasible in their current form since SRH has
no provision for extensibility that is also backwards compatible. This
would be a different story if flags field in SRH was defined to must be
checked to be zero at receiver instead of ignored.

Tom


Hence, the Unified SID isn't alone to propose a solution to the problem
> recognized by the community by updating RFC 8754.
>
> Regards,
> Greg
>
> On Wed, May 27, 2020 at 12:39 PM Tom Herbert <[e-mail]> wrote:
>
>>
>>
>> On Wed, May 27, 2020 at 12:18 PM Greg Mirsky <[e-mail]>
>> wrote:
>>
>>> 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.
>>>
>>> Greg,
>>
>> Then the format of a header in the datapath is no longer self-defining
>> and requires external information from the control plane just to be able to
>> parse it correctly. Why not just define new routing types for different
>> formats like CRH does, or even better why not try to unify Unified SID with
>> CRH given that the functionality of the proposals is very close as you
>> already pointed out?
>>
>> Tom
>>
>> 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
>>>>> --------------------------------------------------------------------
>>>>>
>>>>