Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

["Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>]

I agree that if you look into the details RFC8663 from a data-plane operation is very similar to CRH. It uses a tag and derives a destination ipv6 address from it.
On top it if you look at the requirements, the following is possible with RFC8663


  *   It can steer the packet through a specific path. Implementations exists which do well beyond 8
  *   No new VPN encapsulation is required
  *   No new service chaining needed and various options possible.
  *   Compliant to SPRING
  *   Uses MPLS but it is used here as a lookup tag, not any different than the CRH proposal. In essence if you look at the details you can implement this with a complete v6 infrastructure and use the tag as a steering function. And uses 32 bit.

As such I don’t see why we need another encap to achieve something we already can do and is available in various implementations and is as efficient on the wire (looking at 32 bit, which is what people agree upon)

From: spring <[e-mail]> on behalf of Mach Chen <[e-mail]>
Date: Tuesday, 26 May 2020 at 11:56
To: "Zafar Ali (zali)" <zali=[e-mail]>, Ron Bonica <rbonica=[e-mail]>, "Chengli (Cheng Li)" <[e-mail]>, 6man <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Hi,

If you follow the discussions of the past several months, you should know that CRH is the foundation of SRm6. In my understanding, SRm6 is another IPv6 based Segment Routing, it was originally motivated to address the SRH header compress issue.
Technically, SRm6 works (it has the same concept of SR-MPLS), even if it may not support some functions that SRv6 has already supported, it can be extended to support them if we want.

But, as many people said, we already have SRv6, SR-MPLS over IP, the community has spent so many years of energy and efforts on them, most of the major vendors have implemented it, many SPs have deployed and begin to deploy it. Given this, do we really want to have another try to define a new solution that will provide the same functions as SRv6, SR-MPLS over IP? No doubt, it will take years, the same amount of energy and efforts.

Take a step back, assume SRm6 is also adopted, there will be two solutions for the community to choose; there will be interop issues between the two solutions. The vendors will have to support both to make different customers happy, more money will be spent and will be finally payed by the SPs/customers.

Do we really want this?

My two cents.

Best regards,
Mach

From: ipv6 [mailto:[e-mail]] On Behalf Of Zafar Ali (zali)
Sent: Tuesday, May 26, 2020 3:02 PM
To: Ron Bonica <rbonica=[e-mail]>; Chengli (Cheng Li) <[e-mail]>; 6man <[e-mail]>; [e-mail]
Subject: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Hi,

It appears that some may have misunderstood the SRv6 solution and invented CRH.
It is good to clarify these points.

SRv6 offers the possibility to combine underlay and overlay instructions in a single SRH.
However,

  *   This is entirely optional
  *   If one would like to spread the source routed policy between multiple extension headers, one can use SRv6 to do this

     *   SRH to hold the topological endpoints
     *   Any combination of other extension headers to hold VPN and/or Service information. For example, SRH works seamlessly with NSH as documented in a WG document https://tools.ietf.org/html/draft-ietf-spring-nsh-sr-02.

Claiming that a new data plane is needed to achieve this separation is false.

Claiming that CRH is needed to decrease the overhead of source-routed policy in IPv6 is incorrect, too. Many members of the SPRING working group have produced documents to extend the SRv6 solution for the specific purpose of minimizing the MTU overhead and/or supporting very long SID-lists on legacy hardware.

Also, CRH is just a re-engineering of SR-MPLS Data Plane with IPv6 Control Plane [RFC8663] and RFC8663 is an already productized, deployed, proven, and standardized solution.

6man took 6 years to define SRH. The 6man WG spent a lot of efforts (1000s of email, dozens of document revision, dozens of IETF presentations, control plan work that is adopted by multiple workgroups, etc.).

There is no need to define a new data plane, new control plane and associated management plane for the same purpose the IETF across multiple areas has worked for years.

Thanks

Regards … Zafar


From: ipv6 <[e-mail]<mailto:[e-mail]>> on behalf of Ron Bonica <rbonica=[e-mail]<mailto:rbonica=[e-mail]>>
Date: Friday, May 22, 2020 at 10:17 AM
To: "Chengli (Cheng Li)" <[e-mail]<mailto:[e-mail]>>, 6man <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: How CRH support SFC/Segment Endpoint option?

Cheng,

The sole purpose of a Routing header is to steer a packet along a specified path to its destination. It shouldn’t attempt to do any more than that.

The CRH does not attempt to deliver service function information to service function instances. However, it is compatible with:


  *   The Network Service Header (NSH)
  *   The Destination Options header that precedes the Routing header

Both of these can be used to deliver service function information to service function instances.

                                                                                                                     Ron




Juniper Business Use Only
From: Chengli (Cheng Li) <[e-mail]<mailto:[e-mail]>>
Sent: Friday, May 22, 2020 2:56 AM
To: 6man <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Ron Bonica <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]

Hi Ron,

When reading the CRH draft, I have a question about how CRH support SFC?

For example, we have a SID List [S1, S2, S3, S4, S5], and S3 is a SFC related SID, how to indicate that? By PSSI? [1]

But how to know which segment endpoint node/egress node should process this PSSI? At the beginning of the SRm6 design, this is described in [2]. But you deleted the containers [2].

Without that, I don’t really understand how SFC can be supported.


Best,
Cheng



[1]. https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-4.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01*section-4.1__;Iw!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwP15i-Xa$>
[2]. https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt<https://urldefense.com/v3/__https:/tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt__;!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwNmXwyHT$>.