Subject: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

From: "Zafar Ali (zali)" <[email-masked]>
Date: Tue, 26 May 2020 07:01:42 +0000

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 <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Date: Friday, May 22, 2020 at 10:17 AM
To: "Chengli (Cheng Li)" <[email-masked]>, 6man <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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) <[email-masked]>
Sent: Friday, May 22, 2020 2:56 AM
To: 6man <[email-masked]>; [email-masked]; Ron Bonica <[email-masked]>
Cc: [email-masked]
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$>.

---

From: Mach Chen <[email-masked]>
Date: Tue, 26 May 2020 09:56:09 +0000

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

Hi,

Thanks

Regards … Zafar

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

Cheng,

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

                                                                                                                     Ron

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

Hi Ron,

Best,
Cheng

---

From: Sander Steffann <[email-masked]>
Date: Tue, 26 May 2020 12:55:10 +0200

Hi,

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

Speaking as an operator: yes

Different (parts of) network use different IGPs, different architectures (leaf/spine, clos, core/edge/distribution/access, STP, MLAG, VXLAN, EVPN, VPLS, L2VPN Martini or Kompella) etc etc etc. There is no "one solution fits all", and there are many things besides the feature set that determine what an operator will use. And some technologies will become obsolete, and the networks move on. But as an operator I want to choose. I don't want my vendors or the IETF to choose for me.

Cheers,
Sander

---

From: Andrew Alston <[email-masked]>
Date: Tue, 26 May 2020 11:58:41 +0000

Speaking as an operator that operates in 15 countries – yes – yes and yes again.

SRv6 will never find a home on our network – it is complex, it has massive overhead, it overloads the address space in ways that make me cringe, it currently (in my view) violates RFC8200, the network programming draft is so overengineered that it is entirely inflexible – where as CRH – is simple, it gives me exactly what we need, it is a building block to many other things in the pipe line, and it has been tested and is functional.

I will not begrude anyone who wants to run SRv6 – each to his own – but as an operator – I 100% want CRH – and I 100% do not believe that SRv6 is in any way shape or form an alternative to it – or something that I will ever run across any of the countries we operate in.

Thanks

Andrew

Do we really want this?

My two cents.

Best regards,
Mach

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

Hi,

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
o   SRH to hold the topological endpoints
o   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<https://tools.ietf.org/html/draft-ietf-spring-nsh-sr-02>.

Thanks

Regards … Zafar

Cheng,

                                                                                                                     Ron

Hi Ron,

Best,
Cheng

---

From: James Guichard <[email-masked]>
Date: Tue, 26 May 2020 17:26:36 +0000

Hi Andrew,

Some of your comments about SRv6 are a little subjective.

  1.  You say SRv6 is complex and yet in its basic form it is simply a list of IPv6 addresses carried in a routing header which does not seem too difficult to understand especially in light of the fact that with CRH I have essentially the same thing albeit with another level of indirection to resolve the mappings.
  2.  You say SRv6 has massive overhead and yet there are several proposals in which that overhead can be compressed without having to implement a mapping system to resolve the indirection.
  3.  The overloading the IPv6 address space comment seems at best subjective given that the IPv6 address in the DA field for SRv6 on the wire looks no different than any other IPv6 packet; the fact that some router in the network locally defines a set of instructions to execute upon receipt of a packet using that IPv6 address is a local affair and of no particular concern to any other router. The same logic applies to things like policy-based routing where a router can implement some policy to direct a packet on a different path that no router upstream is aware of.
  4.  Given the long and quite exhausting email thread on violation of RFC8200 it is apparent that not everyone agrees with you on this point and in fact I would go as far as to say the current text is pretty clear from an English language point of view that I find it interesting how many different interpretations have sprung up.
  5.  Network programming is a tool (that you are free to use or not) to enable innovation through locally defined instructions; again, how is this over engineered and if it is over engineered how can it also be inflexible? Seem to me that the complete opposite is true.

Thanks!

Jim

From: spring <[email-masked]> On Behalf Of Andrew Alston
Sent: Tuesday, May 26, 2020 7:59 AM
To: Mach Chen <[email-masked]>; Zafar Ali (zali) <zali=[email-masked]>; Ron Bonica <rbonica=[email-masked]>; Chengli (Cheng Li) <[email-masked]>; 6man <[email-masked]>; [email-masked]
Subject: Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Thanks

Andrew

Do we really want this?

My two cents.

Best regards,
Mach

Hi,

o   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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-nsh-sr-02&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cd9fae6e4cd674180ef6c08d8016c6b3b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260912479599089&sdata=URxBgQ0Z4vJb54I04o4JXoFo%2BnGET6jjQzkH9gFWqms%3D&reserved=0>.

Thanks

Regards … Zafar

Cheng,

                                                                                                                     Ron

Hi Ron,

Best,
Cheng

[1]. https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-4.1<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Fdraft-bonica-spring-sr-mapped-six-01*section-4.1__%3BIw!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwP15i-Xa%24&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cd9fae6e4cd674180ef6c08d8016c6b3b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260912479599089&sdata=BToX91XT%2BlfL5xVfXbDTnE8Nt0%2F8x0PGbKx8mNd1UEY%3D&reserved=0>
[2]. https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Frfcdiff%3Furl2%3Ddraft-bonica-6man-seg-end-opt-04.txt__%3B!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwNmXwyHT%24&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cd9fae6e4cd674180ef6c08d8016c6b3b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260912479609080&sdata=AquUOTV8I2X86h97RnCgdz0kx6x47Yt6FUrsADofsnU%3D&reserved=0>.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 26 May 2020 12:53:28 -0700

On Tue, May 26, 2020 at 10:27 AM James Guichard
<[email-masked]> wrote:
> You say SRv6 is complex and yet in its basic form it is simply a list of IPv6 addresses carried in a routing header which does not seem too difficult to understand especially in light of the fact that with CRH I have essentially the same thing albeit with another level of indirection to resolve the mappings.

Jim,

I agree with the assessment that SRv6, specifically SRH, is complex.
It is more than simply a list of IPv6 addresses-- the protocol format
includes Flags fields, Tags, Last Entry, and TLVs one of which is
HMAC. Those "features" do not make for a simple dataplane protocol
that is amendable hardware and working through those was one of the
reasons it took so long to get SRH through 6man. Had SRH be defined as
just a list of IPv6 addresses and nothing else, I believe these
conversations would be quite different.

Tom

> You say SRv6 has massive overhead and yet there are several proposals in which that overhead can be compressed without having to implement a mapping system to resolve the indirection.
> The overloading the IPv6 address space comment seems at best subjective given that the IPv6 address in the DA field for SRv6 on the wire looks no different than any other IPv6 packet; the fact that some router in the network locally defines a set of instructions to execute upon receipt of a packet using that IPv6 address is a local affair and of no particular concern to any other router. The same logic applies to things like policy-based routing where a router can implement some policy to direct a packet on a different path that no router upstream is aware of.
> Given the long and quite exhausting email thread on violation of RFC8200 it is apparent that not everyone agrees with you on this point and in fact I would go as far as to say the current text is pretty clear from an English language point of view that I find it interesting how many different interpretations have sprung up.
> Network programming is a tool (that you are free to use or not) to enable innovation through locally defined instructions; again, how is this over engineered and if it is over engineered how can it also be inflexible? Seem to me that the complete opposite is true.
>
>
>
> Thanks!
>
>
>
> Jim
>
>
>
> o   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.
>
>
>
> [1]. https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-4.1
>
> [2]. https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt.
>
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Andrew Alston <[email-masked]>
Date: Tue, 26 May 2020 20:49:46 +0000

Jim,

I don’t disagree with your statement that some of my views are subjective.  They are however the subjective views of an operator when the question was asked do we want CRH.

The answer remains yes – because agree with my views or disagree with them – it is the perceptions that I have that will dictate my purchasing over my network and my purchasing decisions will not in any way shape or form include SRv6.  While I have spoken at length about each of the points below over many many emails over the last months, I won’t go into them again, but the answer remains the same.  Do I, as an operator, operating across 15 countries, with the largest fixed line fiber network on the African continent, want CRH.  Yes.  Do I want it because I believe it can give me advantages.  Yes.  Will I run SRv6 on this network.  No.  Have I tested, implemented and used CRH successfully on our network.  Yes.

So – subjective or not – I will not rehash the same things I have said over and over again covering each of the below points in detail, but my answer remains the same – yes, from my perspective, I want CRH, I need CRH and CRH works for us.

Thanks

Andrew

From: James Guichard <[email-masked]>
Date: Tuesday, 26 May 2020 at 20:26
To: Andrew Alston <[email-masked]>, Mach Chen <[email-masked]>, "Zafar Ali (zali)" <zali=[email-masked]>, Ron Bonica <rbonica=[email-masked]>, "Chengli (Cheng Li)" <[email-masked]>, 6man <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Hi Andrew,

Thanks!

Jim

Thanks

Andrew

Do we really want this?

My two cents.

Best regards,
Mach

Hi,

Thanks

Regards … Zafar

Cheng,

                                                                                                                     Ron

Hi Ron,

Best,
Cheng