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

[Greg Mirsky <[e-mail]>]

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