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

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 26 May 2020 14:18:34 +0000

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 <[email-masked]> on behalf of Mach Chen <[email-masked]>
Date: Tuesday, 26 May 2020 at 11:56
To: "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: [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:[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,

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

[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: Sander Steffann <[email-masked]>
Date: Tue, 26 May 2020 16:30:41 +0200

Hi Wim,

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

RFC8663 doesn't work between domains that are not directly connected. I want a solution where the connectivity between the domains is plain IPv6 (e.g. the internet). I have tried this with Andrew using CRH and that works fine. Part of the SR domain was in Kenya, part of it was in The Netherlands, and we could use CRH without any problems. That isn't possible using MPLS.

Cheers,
Sander

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 26 May 2020 14:41:25 +0000

It does work across domains that are not directly connected, but that scenario is not well described I have to admit. The operation is as I said very similar to CRH. 
Think of the MPLS tag as the same as the SID tag in CRH. From a data-plane all packets on the wire will use v6 addresses, so inter-domain is possible.

This is no longer MPLS as people know it. Think of it as a tag that performs a steering function as you have in mind with CRH.

On 26/05/2020, 16:30, "Sander Steffann" <[email-masked]> wrote:

    Hi Wim,

    Cheers,
    Sander

---

From: Sander Steffann <[email-masked]>
Date: Tue, 26 May 2020 16:45:57 +0200

Hi Wim,

> This is no longer MPLS as people know it. Think of it as a tag that performs a steering function as you have in mind with CRH.

How would I get the MPLS tags over the IPv6 internet? All I can imagine is another layer of point to point tunneling...

Cheers,
Sander

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 26 May 2020 14:50:36 +0000

On 26/05/2020, 16:46, "Sander Steffann" <[email-masked]> wrote:

    Hi Wim,

WH> in the same way as you get CRH across the Internet. It is a tag encapsulated in an IPV6 header. It uses ipv6 encap based on RFC4023.

    Cheers,
    Sander

---

From: Sander Steffann <[email-masked]>
Date: Tue, 26 May 2020 18:11:38 +0200

Hi Wim,

> WH> in the same way as you get CRH across the Internet. It is a tag encapsulated in an IPV6 header. It uses ipv6 encap based on RFC4023.

That assumes that there is always a router that adds an encap to an existing packet. I want to look beyond that and allow for end nodes participating directly by adding their own CRH header. In such cases there is no encap that can contain the MPLS stack.

Cheers,
Sander

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 26 May 2020 16:20:06 +0000

On 26/05/2020, 18:11, "Sander Steffann" <[email-masked]> wrote:

    Hi Wim,

WH> Sander RFC8663  is supported in linux and various implementations. You can do the encap in the same way as you have done with CRH w/o a router doing the encap. 

    Cheers,
    Sander

---

From: Sander Steffann <[email-masked]>
Date: Tue, 26 May 2020 19:03:44 +0200

Hi Wim,

> WH> Sander RFC8663  is supported in linux and various implementations. You can do the encap in the same way as you have done with CRH w/o a router doing the encap. 

You misunderstand. I don't want any encap overhead, I just want IPv6 packets...

Cheers,
Sander

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 26 May 2020 17:13:00 +0000

Sander, inline

On 26/05/2020, 19:03, "Sander Steffann" <[email-masked]> wrote:

    Hi Wim,

WH> Why would it matter if I add the sids in an Extension Header, versus through a Next header. As long as we achieve the same goal why would you care? 

    Cheers,
    Sander

---

From: Sander Steffann <[email-masked]>
Date: Tue, 26 May 2020 19:20:06 +0200

Hi Wim,

> WH> Why would it matter if I add the sids in an Extension Header, versus through a Next header. As long as we achieve the same goal why would you care? 

I don't understand what you mean. If you're talking about encapsulation, I care because of the overhead. If you're talking about putting SIDs in the payload, I care because it messes with my payload and is therefore a layer violation.

Cheers,
Sander

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 26 May 2020 17:26:40 +0000

Sander,

On 26/05/2020, 19:20, "Sander Steffann" <[email-masked]> wrote:

    Hi Wim,

Wh> Nothing is put in the payload when using RFC8663. The SID list is put in a next header field as per RFC 4023, whereas in CRH you put them in an EH, but the payload is intact. I have not done the exact calculation on the wire, but they are almost the same in size wrt overhead when you compare 32bit.

    Cheers,
    Sander

---

From: Sander Steffann <[email-masked]>
Date: Tue, 26 May 2020 19:39:56 +0200

Hi Wim,

> Wh> Nothing is put in the payload when using RFC8663. The SID list is put in a next header field as per RFC 4023, whereas in CRH you put them in an EH, but the payload is intact. I have not done th…

But you're still encapsulating. Otherwise you're not making any sense to me...

Sander

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 26 May 2020 18:24:16 +0000

Sander,

On 26/05/2020, 19:40, "Sander Steffann" <[email-masked]> wrote:

    Hi Wim,

WH> We are either all encapsulating or not, but in essence the point is that the difference is you put the sids in the extension header versus next header. Lets leave it like this. All in all what I am saying is RFC8663 allows you to do what you intend with CRH.
. 

    Sander

---

From: Sander Steffann <[email-masked]>
Date: Tue, 26 May 2020 21:17:14 +0200

Hi Wim,

> WH> We are either all encapsulating or not, but in essence the point is that the difference is you put the sids in the extension header versus next header. Lets leave it like this. All in all what…

No, I can't. You're not reading what i wrote. I want packet steering without encapsulation: a plain IPv6 pakket with a RH and plain UDP, TCP etc in the payload.

Please stop telling me that RFC8663 is the answer, because it's not.

Sander

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 26 May 2020 19:25:11 +0000

Sander,

On 26/05/2020, 21:17, "Sander Steffann" <[email-masked]> wrote:

    Hi Wim,

    Please stop telling me that RFC8663 is the answer, because it's not.
WH> what you are saying I only want a CRH solution and you are not open to anything else, because the SIDs are not in the right place. So there is no point in further discussions. My position remains that RFC8663 is a valid alternative and is available; I am against WG adoption of CRH.

    Sander

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 26 May 2020 21:43:41 +0200

Hi Sander,

Ok your use case is indeed original and valid. No encapsulation at all.
Just plain end to end IPv6 header. Cool so far.

If so honestly for your use case I must observe that SRv6 with basic 128
bit SIDs is much easier to use.

Any scheme which requires mapping really works well in a limited domain or
at least over same control plane reach. How are you going to educate end
hosts as those would presumably apply CRH on the CRH content to impose ?

And how fast would that content get adjusted upon network changes ?

> RFC8663 doesn't work between domains that are not directly connected.

Oh it works just fine specifically over not directly connected domains. If
you can exchange mapping via some control plane between non connected
domains you will get next SID which you put in the DA of the packet.

Last just FYI you are violating CRH assumptions already ... draft says:

Is designed to operate within a network domain.

You said:

"I want a solution where the connectivity between the domains is plain IPv6
(e.g. the internet). "

CRH draft does not assume the use between domains over Internet. I think
such intended use case needs to be taken as consideration for the adoption
too.

Thx,
R.

---

From: Sander Steffann <[email-masked]>
Date: Tue, 26 May 2020 21:48:19 +0200

Hi,

> WH> what you are saying I only want a CRH solution and you are not open to anything else, because the SIDs are not in the right place.

No, that is not what I said. Please stop twisting my words. I want to steer a packet without needing to encapsulate it. Why is that so hard to understand?

SRH does that using IPv6 addresses, CRH does that using shorter identifiers. Both have their use cases. I'm not just talking about SRv6 and SRm6. I'm talking about CRH as a building block that can be used by many future protocols.

> So there is no point in further discussions. My position remains that RFC8663 is a valid alternative and is available; I am against WG adoption of CRH.

Your arguments don't make any sense...
Sander

---

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

Hi,

> draft says: 
Source and destination are in the same domain. Who says that the domain is contiguous? Let's change the example to main and branch offices. Same administrative domain, while still traversing the internet.

Cheers,
Sander

---

From: John Scudder <[email-masked]>
Date: Tue, 26 May 2020 20:44:21 +0000

On May 26, 2020, at 3:52 PM, Sander Steffann <[email-masked]<mailto:[email-masked]>> wrote:

This is an interesting point. You can protect it with AH to address security concerns about sending the CRH across the big-I Internet, too. I feel like it provides another illustration of the “look at the benefits you get if you work within an existing architecture instead of trying to invent a whole new one” case. You didn’t have to invent a whole new security architecture of your own — you fit into an existing architecture, and got to inherit its security properties.

$0.02,

—John

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 26 May 2020 23:17:04 +0200

Hi John,

That is indeed an interesting point. Honestly in all of my personal and
business interests I want to use any of those technologies (of course with
RbR preference) for engineering SDWANs. So clearly Internet transit
applies.

But then I have just one question:

- In what context have we spent so many emails discussing "escaping packets
to the Internet" or protecting infrastructure (SID addresses from "entering
your network from Internet" ?

Kind regards,
R.

On Tue, May 26, 2020 at 10:44 PM John Scudder <[email-masked]> wrote:

> On May 26, 2020, at 3:52 PM, Sander Steffann <[email-masked]> wrote:
>
>
> Source and destination are in the same domain. Who says that the domain is
> contiguous? Let's change the example to main and branch offices. Same
> administrative domain, while still traversing the internet.
>
>
> This is an interesting point. You can protect it with AH to address
> security concerns about sending the CRH across the big-I Internet, too. I
> feel like it provides another illustration of the “look at the benefits you
> get if you work within an existing architecture instead of trying to invent
> a whole new one” case. You didn’t have to invent a whole new security
> architecture of your own — you fit into an existing architecture, and got
> to inherit its security properties.
>
> $0.02,
>
> —John
>

---

From: John Scudder <[email-masked]>
Date: Tue, 26 May 2020 21:27:32 +0000

Robert,

On May 26, 2020, at 5:17 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

- In what context have we spent so many emails discussing "escaping packets to the Internet" or protecting infrastructure (SID addresses from "entering your network from Internet" ?

The difference is between packets that transit your network en route to their final destination vs. ones that are targeted at your network. The former is what Sander was talking about, they are no threat, the latter potentially are a threat.

—John

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 27 May 2020 03:22:01 +0000

Sander,

On 26/05/2020, 21:48, "Sander Steffann" <[email-masked]> wrote:

    Hi,

WH> When we defined RFC8663, we could have done what you said, but we didn’t and the reason is simple. New networking capabilities we have defined so far, are supported naturally, like SFC, OAM, VPN, G-SID/L-SID, etc. With your approach we will reinvent the wheel for these things and we have to define a new framework to support them. So far nothing has been identified that cannot be supported with RFC8663.

    Your arguments don't make any sense...
WH> Make sense to me though.
    Sander

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 27 May 2020 11:16:02 +0000

A powerful property of RFC8663: No need for kernel access by applications
For example, applications or workloads running in the DC can operate without kernel access or need for upgraded IP stacks and still steer traffic over a traffic-engineered path (with proven, secure and well known technology).

G/

From: spring <[email-masked]> On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: Tuesday, May 26, 2020 16:19
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?

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Mach Chen <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 26 May 2020 at 11:56
To: "Zafar Ali (zali)" <zali=[email-masked]<mailto:zali=[email-masked]>>, 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]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Hi,

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,

Thanks

Regards … Zafar

Cheng,

                                                                                                                     Ron

Hi Ron,

Best,
Cheng

---

From: Sander Steffann <[email-masked]>
Date: Wed, 27 May 2020 13:20:20 +0200

Hi Gunter,

> A powerful property of RFC8663: No need for kernel access by applications

That assumes that there won't be an API at some point in the future. That's not a good argument against any protocol.

Cheers,
Sander