Subject: Re: [spring] Beyond SRv6.

From: "Bernier, Daniel" <[email-masked]>
Date: Thu, 12 Sep 2019 18:25:42 +0000

That was precisely my point

Having been involved in pushing SRv6 END behaviours in various targets, I can first hand say that the primitives behind SRH processing is quite simple to extend. In your extensibility model, every predefined or custom behavior becomes a new DOH. On SRH, the EH does not change I just need to inform the data plane that when receiving a packet with a specific SID in SRH, do this internal processing.

On 2019-09-12, 12:34 PM, "Ron Bonica" <[email-masked]<mailto:[email-masked]>> wrote:

Mark,

I think that you may have exposed yet another elephant in the room……

IPv6 defines a robust extensibility architecture, that includes multiple extension headers. Initially, IPv6 adoption was slow and router vendors were not highly motivated commit extension headers to ASICs. Also, in those days, ASICs were not so capable as they are today.

From the above-mentioned data points, we should not infer that it is beyond the capability of a modern vendor to develop an ASIC that supports a more complete set of extension headers. Two things have changed. As IPv6 adoption progresses, vendors are becoming more committed to IPv6. Beyond that, ASICs have become more capable over the decades.

We shouldn’t abandon the IPv6 extensibility architecture based on a claim that ASICs cannot and will never be able to  process multiple extension headers.

                                                                                                  Ron

From: ipv6 <[email-masked]> On Behalf Of Mark Smith
Sent: Thursday, September 12, 2019 1:30 AM
To: EXT - [email-masked] <[email-masked]>
Cc: Rob Shakir <[email-masked]>; SPRING WG <[email-masked]>; 6man <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]; Tarek Saad <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

It's simple because IPv6 doesn't look past the fixed IPv6 header to perform its forwarding, and matches on the Destination Address to determine if to perform deeper packet host processing.

You're building much more complicated forwarding services if you're going to be marching on TLVs etc. past the IPv6 fixed header.

However vendors and carrier engineering groups like selling and deploying new gear, so I suppose that's ok. They don't have to operate it or fix it when it breaks.
On Thu, 12 Sep 2019, 13:41 Bernier, Daniel, <[email-masked]<mailto:[email-masked]>> wrote:

+1

The ability of using a single SRH to convey behaviour information wether they are per-segment or per-path has proven to be very simple and quick to define in various data plane targets.

At first analysis, trying to replicate with CRH + DOH variants, the logic required for service programs is more com​plex.

What happens if I need TLVs mid-point in a path but not at its end (e.g. referring to the Ole's ACME analogy) ? Would they now be defined in a seg-end-opt or a vpn-dest-opt ? If seg-end-opt then it means non-interested midpoint devices will have to lookup beyond the TLVs to get to CRH for next segment ?

Similar question would be on how would we implement proxy behaviours either dynamic or static ? If I read https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04__;!8WoA6RjC81c!WhasJYFTRmXzKd1g-oMU5hza4EoH-63AFe6qzFFZtlfTRAiabJjCZB0f5dp14y8L$> correctly, we then need NSH for richer service chains constructs (think Gi-LAN). This means I need CRH, some variants of DOH + NSH​.

I fail to see the simplicity there.

Dan B

________________________________
From: spring <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 11, 2019 8:57 PM
To: List
Cc: Rob Shakir; 6man; Tarek Saad; Robert Raszuk
Subject: [EXT]Re: [spring] Beyond SRv6.

Hi, folks,
Last year China Telecom begun to implement SRv6 trial in Sichun province for the bearing and interconnection of video platforms which are  located in different cities, service agilities,secure sepertion, traffic steering and other features of SRv6 have been demonstrated in this trial. Based on this, SRv6 will be implementated in larger-scale in CT.
No technologies is 100% perfect,I agree that compression mechanism is needed to reduce the the overhead of long SID in the long term, but it is better to be compatible withe SRH, instead of designing a complete new one. CRH is a complete new design, it move the complexities from SRH to DOH.
Moreover, I hope more efforts of SRv6 should be given on how to support new services,for instance, Application-aware network (APN). Meanwhile, we should consider more on how to implmement smooth transition and protect the network assetof carriers.

Best regards
Chongfeng

From: Dirk Steinberg<mailto:[email-masked]>
Date: 2019-09-09 21:31
To: Gyan Mishra<mailto:[email-masked]>
CC: SPRING WG List<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Robert Raszuk<mailto:[email-masked]>; Rob Shakir<mailto:[email-masked]>; Tarek Saad<mailto:[email-masked]>
Subject: Re: [spring] Beyond SRv6.
There seems to be some confusion regarding TI-LFA.
A couple of comments:

- Remote LFA tunnel is not used with SR, only TI-LFA which
  only operates on the node that is the PLR (point of local repair).

- Any encapsulation on the ingress PE with or without EH has nothing
  to do with TI-LFA except for the special case where the ingress PE
  itself is the PLR.

- TI-LFA is not an IGP extension and does not require one.
  It is a purely local computation based on IGP topology.

- The PLR for TI-LFA may need to insert some SIDs into the SID
  list to steer the packet around the failure. For the LFA base case
  no SIDs are needed at all. If SID insertion is needed, the PLR
  will push the required number of labels in the MPLS case.

  For SRv6, the equivalent operation to the label push is to
  insert an EH with the required SID list. The packet will already
  have been encapsulated on the ingress PE and in the most
  common Internet or VPN base use case it will not even have
  an EH so that this EH insertion will result only in a single EH..

  Alternatively, the PLR could also be configured to perform
  encapsulation with a new IPv6 header using the repair SID
  as IPv6 destination address, without needing any EH.
  This will work for the vast majority of cases.
  Remember that one 128-bit SID in SRv6 is in most cases
  equivalent to 2 MPLS labels, i.e. a node label plus an
  adjacency SID can be encoded in a single SRv6 SID.

  Only in extreme cases would the PLR need to add an
  EH to the new IPv6 header with more SIDs.

- EH insertion for TI-LFA has nothing to do with stitching SRv6 domains.

Hope it helps.

Cheers
Dirk

Am 08.09.2019 um 09:19 schrieb Gyan Mishra <[email-masked]<mailto:[email-masked]>>:

>From reading through all the discussion threads the SR insertion is two fold one being for FRR capabilities using Ti-LFA or remote LFA tunnel so end up requiring double EH insertions on the Ingress PE tunnel head end SRv6 source node and then second scenario being a possible EH insertions occurrence on intermediate nodes.  I have not read through the drafts or RFC regarding Ti-LFA with SR but since that is an IGP extension I am guessing an opaque LSA and is not the traditional MPLS FRR link/node/path protection that adds an additional mpls shim so not sure why an EH insertion needs to occur for Ti-LFA.  Can someone clarify that use case for me.  Also the EH insertion on intermediate node what is the use case or reason for that.  My guess is it’s for special use case of stitching SRv6 domains together.  Please clarify..

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!WhasJYFTRmXzKd1g-oMU5hza4EoH-63AFe6qzFFZtlfTRAiabJjCZB0f5aWDOXgb$>

Juniper Business Use Only

---

From: Ron Bonica <[email-masked]>
Date: Thu, 12 Sep 2019 18:50:53 +0000

Daniel,

Not really. A single IPv6 Option, the PPSI, replaces all of the following SIDs:

  *   END.DX2
  *   END.DX2V
  *   END.DX2U
  *   END.DX2M
  *   END.DT4
  *   END.DX4
  *   END.DT6
  *   END.DX6
  *   END.DT46
  *   END.T

                                                                               Ron

Juniper Business Use Only
From: Bernier, Daniel <[email-masked]>
Sent: Thursday, September 12, 2019 2:26 PM
To: Ron Bonica <[email-masked]>; Mark Smith <[email-masked]>
Cc: Rob Shakir <[email-masked]>; SPRING WG <[email-masked]>; 6man <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked]; Tarek Saad <[email-masked]>
Subject: RE: [spring] Beyond SRv6.

Mark,

                                                                                                  Ron

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Mark Smith
Sent: Thursday, September 12, 2019 1:30 AM
To: EXT - [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: Rob Shakir <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Tarek Saad <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Beyond SRv6.

+1

Dan B

Hi, folks,

Best regards
Chongfeng

Hope it helps.

Cheers
Dirk

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Sep 2019 21:33:48 +0200

Dear Ron,

I was trying to stop responding but its pretty hard when I see such post
like your last one ...

> A single IPv6 Option, the PPSI, replaces all of the following SID

Please understand that this is like stating that:

"A single new additional airport replaces all the planes which operate to
the old airport. "

At most you could say that single new PPSI could contain 2^32 SR functions
which you call in your draft as "PPSI identifiers"  From your documents it
also seems that you are defining a service instruction identifier in a flat
space which can contain the demux for the following technologies:

      o    Layer 2 VPN (L2VPN) [RFC6624
<https://tools.ietf.org/html/rfc6624>].

   o  Layer 3 VPN (L3VPN) [RFC4364 <https://tools.ietf.org/html/rfc4364>].
   o  Virtual Private LAN Service (VPLS) [RFC4761
<https://tools.ietf.org/html/rfc4761>][RFC4762].
   o  Ethernet VPN (EVPN) [RFC7432 <https://tools.ietf.org/html/rfc7432>].
   o  Pseudowires [RFC8077 <https://tools.ietf.org/html/rfc8077>].

It also needs to be observed that putting all of those services into
single flat table lookup is not a sound design.

But what is most important that common hardware reads just entire
header then starts processing. So it really makes much more sense to
encode SR SIDs and related functions and their parameters in the same
EH rather then scatter them around.

Thank you,

R.

On Thu, Sep 12, 2019 at 8:51 PM Ron Bonica <[email-masked]> wrote:

>    - END.DX2
>    - END.DX2V
>    - END.DX2U
>    - END.DX2M
>    - END.DT4
>    - END.DX4
>    - END.DT6
>    - END.DX6
>    - END.DT46
>    - END.T
> *From:* Bernier, Daniel <[email-masked]>
> *Sent:* Thursday, September 12, 2019 2:26 PM
> *To:* Ron Bonica <[email-masked]>; Mark Smith <[email-masked]
> >
> *Cc:* Rob Shakir <[email-masked]>; SPRING WG <[email-masked]>; 6man <
> [email-masked]>; Robert Raszuk <[email-masked]>; [email-masked];
> Tarek Saad <[email-masked]>
> *Subject:* RE: [spring] Beyond SRv6.
>
>
>
> Having been involved in pushing SRv6 END behaviours in various targets, I
> can first hand say that the primitives behind SRH processing is quite
> simple to extend. In your extensibility model, every predefined or custom
> behavior becomes a new DOH. On SRH, the EH does not change I just need to
> inform the data plane that when receiving a packet with a specific SID in
> SRH, do this internal processing.
>
>
>
>
>
> On 2019-09-12, 12:34 PM, "Ron Bonica" <[email-masked]> wrote:
>
>
>
> Mark,
>
>
>
> IPv6 defines a robust extensibility architecture, that includes multiple
> extension headers. Initially, IPv6 adoption was slow and router vendors
> were not highly motivated commit extension headers to ASICs. Also, in those
> days, ASICs were not so capable as they are today.
>
>
>
> From the above-mentioned data points, we should not infer that it is
> beyond the capability of a modern vendor to develop an ASIC that supports a
> more complete set of extension headers. Two things have changed. As IPv6
> adoption progresses, vendors are becoming more committed to IPv6. Beyond
> that, ASICs have become more capable over the decades.
>
>
>
> We shouldn’t abandon the IPv6 extensibility architecture based on a claim
> that ASICs cannot and will never be able to  process multiple extension
> headers.
>
>
>
>
> Ron
>
>
>
>
>
>
>
>
>
> *From:* ipv6 <[email-masked]> *On Behalf Of *Mark Smith
> *Sent:* Thursday, September 12, 2019 1:30 AM
> *To:* EXT - [email-masked] <[email-masked]>
> *Cc:* Rob Shakir <[email-masked]>; SPRING WG <[email-masked]>; 6man <
> [email-masked]>; Robert Raszuk <[email-masked]>; [email-masked];
> Tarek Saad <[email-masked]>
> *Subject:* Re: [spring] Beyond SRv6.
>
>
>
> It's simple because IPv6 doesn't look past the fixed IPv6 header to
> perform its forwarding, and matches on the Destination Address to determine
> if to perform deeper packet host processing.
>
>
>
>
>
> You're building much more complicated forwarding services if you're going
> to be marching on TLVs etc. past the IPv6 fixed header.
>
>
>
> However vendors and carrier engineering groups like selling and deploying
> new gear, so I suppose that's ok. They don't have to operate it or fix it
> when it breaks.
>
> On Thu, 12 Sep 2019, 13:41 Bernier, Daniel, <[email-masked]>
> wrote:
>
> +1
>
>
>
> The ability of using a single SRH to convey behaviour information wether
> they are per-segment or per-path has proven to be very simple and quick to
> define in various data plane targets.
>
>
>
> At first analysis, trying to replicate with CRH + DOH variants, the logic
> required for service programs is more com​plex.
>
>
>
> What happens if I need TLVs mid-point in a path but not at its end (e.g.
> referring to the Ole's ACME analogy) ? Would they now be defined in a
> seg-end-opt or a vpn-dest-opt ? If seg-end-opt then it means non-interested
> midpoint devices will have to lookup beyond the TLVs to get to CRH for next
> segment ?
>
>
>
> Similar question would be on how would we implement proxy behaviours
> either dynamic or static ? If I read
> https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04__;!8WoA6RjC81c!WhasJYFTRmXzKd1g-oMU5hza4EoH-63AFe6qzFFZtlfTRAiabJjCZB0f5dp14y8L$>
> correctly, we then need NSH for richer service chains constructs (think
> Gi-LAN). This means I need CRH, some variants of DOH + NSH​.
>
>
>
> ------------------------------
>
> *From:* spring <[email-masked]> on behalf of
> [email-masked] <[email-masked]>
> *Sent:* Wednesday, September 11, 2019 8:57 PM
> *To:* List
> *Cc:* Rob Shakir; 6man; Tarek Saad; Robert Raszuk
> *Subject:* [EXT]Re: [spring] Beyond SRv6.
>
>
>
>
>
> Hi, folks,
>
>
> Moreover, I hope more efforts of SRv6 should be given on how to support new services,for instance, Application-aware network
> (APN). Meanwhile, we should consider more on
> how to implmement smooth transition and protect the network assetof carriers.
>
>
>
> Best regards
>
> Chongfeng
>
>
>
>
>
> *From:* Dirk Steinberg <[email-masked]>
>
> *Date:* 2019-09-09 21:31
>
> *To:* Gyan Mishra <[email-masked]>
>
> *CC:* SPRING WG List <[email-masked]>; [email-masked]; Robert Raszuk
> <[email-masked]>; Rob Shakir <[email-masked]>; Tarek Saad
> <[email-masked]>
>
> *Subject:* Re: [spring] Beyond SRv6.
>
> Am 08.09.2019 um 09:19 schrieb Gyan Mishra <[email-masked]>:
>
>
>
> >From reading through all the discussion threads the SR insertion is two
> fold one being for FRR capabilities using Ti-LFA or remote LFA tunnel so
> end up requiring double EH insertions on the Ingress PE tunnel head end
> SRv6 source node and then second scenario being a possible EH insertions
> occurrence on intermediate nodes.  I have not read through the drafts or
> RFC regarding Ti-LFA with SR but since that is an IGP extension I am
> guessing an opaque LSA and is not the traditional MPLS FRR link/node/path
> protection that adds an additional mpls shim so not sure why an EH
> insertion needs to occur for Ti-LFA.  Can someone clarify that use case for
> me.  Also the EH insertion on intermediate node what is the use case or
> reason for that.  My guess is it’s for special use case of stitching SRv6
> domains together.  Please clarify..
>
>
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!WhasJYFTRmXzKd1g-oMU5hza4EoH-63AFe6qzFFZtlfTRAiabJjCZB0f5aWDOXgb$>
>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 12 Sep 2019 19:38:37 +0000

Robert,

Think about how these things work in SR-MPLS. All of the  “END.D functions” are encoded in an MPLS service label (20 bits) or a VNI (24 bits). We merely moved those bits into the 32 bit Option Data field of the PPSI.

If it is a good idea in SR-MPLS, why is it a bad idea in SRv6+?

                                                                Ron

From: Robert Raszuk <[email-masked]>
Sent: Thursday, September 12, 2019 3:34 PM
To: Ron Bonica <[email-masked]>
Cc: EXT - [email-masked] <[email-masked]>; Mark Smith <[email-masked]>; Rob Shakir <[email-masked]>; SPRING WG <[email-masked]>; 6man <[email-masked]>; [email-masked]; Tarek Saad <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

Dear Ron,

I was trying to stop responding but its pretty hard when I see such post like your last one ...

"A single new additional airport replaces all the planes which operate to the old airport. "

At most you could say that single new PPSI could contain 2^32 SR functions which you call in your draft as "PPSI identifiers"  From your documents it also seems that you are defining a service instruction identifier in a flat space which can contain the demux for the following technologies:

      o    Layer 2 VPN (L2VPN) [RFC6624<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc6624__;!8WoA6RjC81c!Q0LqhRGndRvLABiWpZIc9aUdtjOsc_p_i-3pTF3fsnI_1woNeZgIJ2XEvKDlYwG3$>].

   o  Layer 3 VPN (L3VPN) [RFC4364<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4364__;!8WoA6RjC81c!Q0LqhRGndRvLABiWpZIc9aUdtjOsc_p_i-3pTF3fsnI_1woNeZgIJ2XEvJRj7V9K$>].

   o  Virtual Private LAN Service (VPLS) [RFC4761<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4761__;!8WoA6RjC81c!Q0LqhRGndRvLABiWpZIc9aUdtjOsc_p_i-3pTF3fsnI_1woNeZgIJ2XEvLKysv2n$>][RFC4762].

   o  Ethernet VPN (EVPN) [RFC7432<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7432__;!8WoA6RjC81c!Q0LqhRGndRvLABiWpZIc9aUdtjOsc_p_i-3pTF3fsnI_1woNeZgIJ2XEvNdnfcBj$>].

   o  Pseudowires [RFC8077<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8077__;!8WoA6RjC81c!Q0LqhRGndRvLABiWpZIc9aUdtjOsc_p_i-3pTF3fsnI_1woNeZgIJ2XEvGvQN6ft$>].

It also needs to be observed that putting all of those services into single flat table lookup is not a sound design.

But what is most important that common hardware reads just entire header then starts processing. So it really makes much more sense to encode SR SIDs and related functions and their parameters in the same EH rather then scatter them around.

Thank you,

R.

On Thu, Sep 12, 2019 at 8:51 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Daniel,

  *   END.DX2
  *   END.DX2V
  *   END.DX2U
  *   END.DX2M
  *   END.DT4
  *   END.DX4
  *   END.DT6
  *   END.DX6
  *   END.DT46
  *   END.T

                                                                               Ron

Juniper Business Use Only
From: Bernier, Daniel <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, September 12, 2019 2:26 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Mark Smith <[email-masked]<mailto:[email-masked]>>
Cc: Rob Shakir <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Tarek Saad <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] Beyond SRv6.

Mark,

                                                                                                  Ron

+1

Dan B

Hi, folks,

Best regards
Chongfeng

Hope it helps.

Cheers
Dirk

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Sep 2019 22:29:57 +0200

Ron,

Thank you for formally admitting that SRv6+ is just SR-MPLS over IPv6. As
you recall I was proposing to use exactly SR-MPLS
with draft-ietf-mpls-sr-over-ip to achieve all what you are cooking in the
SRv6+ pot.

The fact that you switched the lid of the pot does not change the taste nor
consistency of the soup !

So nothing is wrong using SR-MPLS but no one needs to go through all
proposed control plane and data plane development to accomplish to what has
been shipping for a while.

On the other hand SRv6 functions not only that they allow additional
parameters to be embedded in functions they also allow to completely depart
from keeping one global LFIB on the PEs towards more modern data plane
lookup and forwarding structures.

Many thx,
R.

On Thu, Sep 12, 2019 at 9:38 PM Ron Bonica <[email-masked]> wrote:

> Robert,
>
>
>
> Think about how these things work in SR-MPLS. All of the  “END.D
> functions” are encoded in an MPLS service label (20 bits) or a VNI (24
> bits). We merely moved those bits into the 32 bit Option Data field of the
> PPSI.
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Thursday, September 12, 2019 3:34 PM
> *To:* Ron Bonica <[email-masked]>
> *Cc:* EXT - [email-masked] <[email-masked]>; Mark Smith <
> [email-masked]>; Rob Shakir <[email-masked]>; SPRING WG <
> [email-masked]>; 6man <[email-masked]>; [email-masked]; Tarek
> Saad <[email-masked]>
> which you call in your draft as "PPSI identifiers"  From your documents
> it also seems that you are defining a service instruction identifier in a
> flat space which can contain the demux for the following technologies:
>
>
>
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc6624__;!8WoA6RjC81c!Q0LqhRGndRvLABiWpZIc9aUdtjOsc_p_i-3pTF3fsnI_1woNeZgIJ2XEvKDlYwG3$>
> ].
>
>    o  Layer 3 VPN (L3VPN) [RFC4364 <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4364__;!8WoA6RjC81c!Q0LqhRGndRvLABiWpZIc9aUdtjOsc_p_i-3pTF3fsnI_1woNeZgIJ2XEvJRj7V9K$>].
>
>    o  Virtual Private LAN Service (VPLS) [RFC4761 <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4761__;!8WoA6RjC81c!Q0LqhRGndRvLABiWpZIc9aUdtjOsc_p_i-3pTF3fsnI_1woNeZgIJ2XEvLKysv2n$>][RFC4762].
>
>    o  Ethernet VPN (EVPN) [RFC7432 <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7432__;!8WoA6RjC81c!Q0LqhRGndRvLABiWpZIc9aUdtjOsc_p_i-3pTF3fsnI_1woNeZgIJ2XEvNdnfcBj$>].
>
>    o  Pseudowires [RFC8077 <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8077__;!8WoA6RjC81c!Q0LqhRGndRvLABiWpZIc9aUdtjOsc_p_i-3pTF3fsnI_1woNeZgIJ2XEvGvQN6ft$>].
>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 12 Sep 2019 22:07:33 +0000

Robert,

At the risk of sounding like Lewis Carrol.....

I said that SRv6+ shares an attribute with SR-MPLS. You said that, therefore, SRv6+ is just SR-MPLS over IPv6.

The second statement is not a logical consequence of the first, because SRv6+ also shares some attributes with SRv6 that cannot be found in SR-MPLS.

In reality, SRv6+ merges the best attributes of both.

Returning to Lewis Carrol, saying that my children can swim like fish does not mean that they have gills😔

Ron
Sent from my phone

On Sep 12, 2019, at 4:30 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Ron,

Thank you for formally admitting that SRv6+ is just SR-MPLS over IPv6. As you recall I was proposing to use exactly SR-MPLS with draft-ietf-mpls-sr-over-ip to achieve all what you are cooking in the SRv6+ pot.

The fact that you switched the lid of the pot does not change the taste nor consistency of the soup !

So nothing is wrong using SR-MPLS but no one needs to go through all proposed control plane and data plane development to accomplish to what has been shipping for a while.

On the other hand SRv6 functions not only that they allow additional parameters to be embedded in functions they also allow to completely depart from keeping one global LFIB on the PEs towards more modern data plane lookup and forwarding structures.

Many thx,
R.

On Thu, Sep 12, 2019 at 9:38 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                                Ron

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, September 12, 2019 3:34 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: EXT - [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Mark Smith <[email-masked]<mailto:[email-masked]>>; Rob Shakir <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Tarek Saad <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Beyond SRv6.

Dear Ron,

Thank you,

R.

  *   END.DX2
  *   END.DX2V
  *   END.DX2U
  *   END.DX2M
  *   END.DT4
  *   END.DX4
  *   END.DT6
  *   END.DX6
  *   END.DT46
  *   END.T

                                                                               Ron

Mark,

                                                                                                  Ron

+1

Dan B

Hi, folks,

Best regards
Chongfeng

Hope it helps.

Cheers
Dirk

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Sep 2019 10:32:24 +1200

Robert,

> EH rather then scatter them around.

Sorry to get all philosophical, but it seems to me that there's another
elephant in the room here (and he's been around for twenty years or so).
There seems to be an assumption that we should design on the assumption
that fast path processing is done by ASICs or FPGAs, so header formats
should be rigid enough that conditional or linked-list processing can
be largely avoided. I've been lectured on the bad design of IPv6 extension
headers in a way that only makes sense from an ASIC or FPGA viewpoint.

But anybody who's building the fast path using a network processor doesn't
have that constraint and can use the existing extension header design
happily enough.

To what extent is this behind the present argument?

Regards
   Brian Carpenter

On 13-Sep-19 07:33, Robert Raszuk wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Sep 2019 01:15:12 +0200

Hi Brian,

> To what extent is this behind the present argument?

If you are calling elephant and ASIC/FPGA - that was not my reasoning at
all.

Regardless if you are processing packets by a fixed burned ASIC or
programmable NP the packet must be read into DRAM and its header stored in
SRAM during processing - that is I hope pretty clear to everyone. What
matters is the amount of SRAM you have at your disposal and then how far
apart are elements required for processing a given feature.

I am full supporter of NPs and actually just fyi in my MS thesis I designed
and prototyped Altera MAX FPGA based router :).  If one can afford for
required line rate speed rating and total box throughput using NP based
systems is much better investment. This is more for flexibility (field
programmability) and software updates for bug fixes and new features then
anything to do how we should or should not design the packet headers in
data plane protocols.

In the comment below I was not really making an observation that when you
separate multiple DOHs from CRH you can not process things - you sure can
as all such EHs actually carry opaque to each other elements. I was however
observing the fact that functions may require parameters which are not
supported by DOHs as well as observed earlier that if you are to make sure
packets entering your domain or leaving "escaping" your domain contain any
unexpected headers it is much easier to set such ACL onces instead of keep
updating it every time new draft gets published and new type gets allocated
for another SRv6+ Destination Option.

Many thx,
Robert

---

From: Ron Bonica <[email-masked]>
Date: Fri, 13 Sep 2019 00:40:20 +0000

Brian,

Those who lecture you on the poor design of IPv6 extension headers may need to rethink their position. Modern ASICs are perfectly capable of processing a packet that contains both a Routing Header and a Destination Header, so long as the length of each is kept within reason.

                                                                                                  Ron

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Thursday, September 12, 2019 6:32 PM
To: Robert Raszuk <[email-masked]>; Ron Bonica <[email-masked]>
Cc: [email-masked]; SPRING WG <[email-masked]>; 6man <[email-masked]>; Rob Shakir <[email-masked]>; Tarek Saad <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

Robert,

> EH rather then scatter them around.

Sorry to get all philosophical, but it seems to me that there's another elephant in the room here (and he's been around for twenty years or so).
There seems to be an assumption that we should design on the assumption that fast path processing is done by ASICs or FPGAs, so header formats should be rigid enough that conditional or linked-list processing can be largely avoided. I've been lectured on the bad design of IPv6 extension headers in a way that only makes sense from an ASIC or FPGA viewpoint.

But anybody who's building the fast path using a network processor doesn't have that constraint and can use the existing extension header design happily enough.

Regards
   Brian Carpenter

On 13-Sep-19 07:33, Robert Raszuk wrote:
> At most you could say that single new PPSI could contain 2^32 SR 
> functions which you call in your draft as "PPSI identifiers"  From 
> your documents it also seems that you are defining a service 
> instruction identifier in a flat space which can contain the demux for the following technologies:
> 
> <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc6624__;!8WoA6RjC81c!SNqTPRCFQIHgl4FsihCX-7UUQan5eXVi-Raiy6m1Cekp54qt3IjMBM2JP6CZEfxv$ >].
> 
>    o  Layer 3 VPN (L3VPN) [RFC4364 <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc4364__;!8WoA6RjC81c!SNqTPRCFQIHgl4FsihCX-7UUQan5eXVi-Raiy6m1Cekp54qt3IjMBM2JP0lKDPf5$ >].
> <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc4761__;!8WoA6RjC81c!SNqTPRCFQIHgl4FsihCX-7UUQan5eXVi-Raiy6m1Cekp54qt3IjMBM2JPyuNYiL8$ >][RFC4762].
>    o  Ethernet VPN (EVPN) [RFC7432 <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc7432__;!8WoA6RjC81c!SNqTPRCFQIHgl4FsihCX-7UUQan5eXVi-Raiy6m1Cekp54qt3IjMBM2JP51E8Fug$ >].
>    o  Pseudowires [RFC8077 <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8077__;!8WoA6RjC81c!SNqTPRCFQIHgl4FsihCX-7UUQan5eXVi-Raiy6m1Cekp54qt3IjMBM2JP3gMZTMl$ >].
> 
> 
>> Not really. A single IPv6 Option, the PPSI, replaces all of the 
>> following
>> SIDs:
>>
>>
>>
>>    - END.DX2
>>    - END.DX2V
>>    - END.DX2U
>>    - END.DX2M
>>    - END.DT4
>>    - END.DX4
>>    - END.DT6
>>    - END.DX6
>>    - END.DT46
>>    - END.T
>>
>>
>>
>>
>>
>>
>>                           Ron
>>
>>
>>
>>
>>
>> *Cc:* Rob Shakir <[email-masked]>; SPRING WG <[email-masked]>; 
>> 6man < [email-masked]>; Robert Raszuk <[email-masked]>; 
>> [email-masked]; Tarek Saad <[email-masked]>
>> Having been involved in pushing SRv6 END behaviours in various 
>> targets, I can first hand say that the primitives behind SRH 
>> processing is quite simple to extend. In your extensibility model, 
>> every predefined or custom behavior becomes a new DOH. On SRH, the EH 
>> does not change I just need to inform the data plane that when 
>> receiving a packet with a specific SID in SRH, do this internal processing.
>>
>>
>>
>>
>>
>> IPv6 defines a robust extensibility architecture, that includes 
>> multiple extension headers. Initially, IPv6 adoption was slow and 
>> router vendors were not highly motivated commit extension headers to 
>> ASICs. Also, in those days, ASICs were not so capable as they are today.
>>
>>
>>
>> beyond the capability of a modern vendor to develop an ASIC that 
>> supports a more complete set of extension headers. Two things have 
>> changed. As IPv6 adoption progresses, vendors are becoming more 
>> committed to IPv6. Beyond that, ASICs have become more capable over the decades.
>>
>>
>>
>> We shouldn’t abandon the IPv6 extensibility architecture based on a 
>> claim that ASICs cannot and will never be able to  process multiple 
>> extension headers.
>>
>>
>>
>>
>> Ron
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Cc:* Rob Shakir <[email-masked]>; SPRING WG <[email-masked]>; 
>> 6man < [email-masked]>; Robert Raszuk <[email-masked]>; 
>> [email-masked]; Tarek Saad <[email-masked]>
>> perform its forwarding, and matches on the Destination Address to 
>> determine if to perform deeper packet host processing.
>>
>>
>>
>>
>>
>> You're building much more complicated forwarding services if you're 
>> going to be marching on TLVs etc. past the IPv6 fixed header.
>>
>>
>>
>> However vendors and carrier engineering groups like selling and 
>> deploying new gear, so I suppose that's ok. They don't have to 
>> operate it or fix it when it breaks.
>>
>> The ability of using a single SRH to convey behaviour information 
>> wether they are per-segment or per-path has proven to be very simple 
>> and quick to define in various data plane targets.
>>
>>
>>
>> At first analysis, trying to replicate with CRH + DOH variants, the 
>> logic required for service programs is more com​plex.
>>
>>
>>
>> seg-end-opt or a vpn-dest-opt ? If seg-end-opt then it means 
>> non-interested midpoint devices will have to lookup beyond the TLVs 
>> to get to CRH for next segment ?
>>
>>
>>
>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-
>> 6man-seg-end-opt-04__;!8WoA6RjC81c!SNqTPRCFQIHgl4FsihCX-7UUQan5eXVi-R
>> aiy6m1Cekp54qt3IjMBM2JPyzmU2AP$ 
>> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-
>> 6man-seg-end-opt-04__;!8WoA6RjC81c!WhasJYFTRmXzKd1g-oMU5hza4EoH-63AFe
>> 6qzFFZtlfTRAiabJjCZB0f5dp14y8L$> correctly, we then need NSH for 
>> richer service chains constructs (think Gi-LAN). This means I need 
>> CRH, some variants of DOH + NSH​.
>>
>>
>>
>> Moreover, I hope more efforts of SRv6 should be given on how to 
>> support new services,for instance, Application-aware network (APN). 
>> Meanwhile, we should consider more on how to implmement smooth transition and protect the network assetof carriers.
>>
>>
>>
>> Best regards
>>
>> Chongfeng
>>
>>
>>
>>
>>
>> fold one being for FRR capabilities using Ti-LFA or remote LFA tunnel 
>> so end up requiring double EH insertions on the Ingress PE tunnel 
>> head end
>> SRv6 source node and then second scenario being a possible EH 
>> insertions occurrence on intermediate nodes.  I have not read through 
>> the drafts or RFC regarding Ti-LFA with SR but since that is an IGP 
>> extension I am guessing an opaque LSA and is not the traditional MPLS 
>> FRR link/node/path protection that adds an additional mpls shim so 
>> not sure why an EH insertion needs to occur for Ti-LFA.  Can someone 
>> clarify that use case for me.  Also the EH insertion on intermediate 
>> node what is the use case or reason for that.  My guess is it’s for 
>> special use case of stitching SRv6 domains together.  Please clarify..
>>
>>
>>
>>
>>
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spr
>> ing__;!8WoA6RjC81c!SNqTPRCFQIHgl4FsihCX-7UUQan5eXVi-Raiy6m1Cekp54qt3I
>> jMBM2JP8G1SR9t$ 
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spr
>> ing__;!8WoA6RjC81c!WhasJYFTRmXzKd1g-oMU5hza4EoH-63AFe6qzFFZtlfTRAiabJ
>> jCZB0f5aWDOXgb$>
>>
>>
>>
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!8WoA6RjC81c!SNqTPRCFQIHgl4FsihCX-7UUQan5eXVi-Raiy6m1Cekp54qt3IjMBM
> 2JPyyOEzqD$

---

From: Tom Herbert <[email-masked]>
Date: Thu, 12 Sep 2019 19:59:17 -0700

Robert,

Right, but isn't that precisely one of the arguments that 16 byte SIDs are
a problem? For instance, if my parsing buffer is 128 bytes then that allows
an SRH with at most four or maybe five SIDs if I'm not mistaken. It seems
like the smaller SID size of SRV6+, even with the DOH PSSI, option still
would produce smaller a header chain than SRV6 and thereby allow more
segments in the header.

Tom

> I am full supporter of NPs and actually just fyi in my MS thesis I
> designed and prototyped Altera MAX FPGA based router :).  If one can afford
> for required line rate speed rating and total box throughput using NP based
>> elephant in the room here (and he's been around for twenty years or so)..

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Sep 2019 11:33:14 +0200

Hi Tom,

Robert,
> would produce smaller a header chain than SRV6 and thereby allow more

Let me just send a ref to one of the IETF emails from eng of one of the
major NPU data plane vendor ...

He said:

    It clearly depends on the device capabilities. For a device with a
parsing buffer of *256 bytes*
    that should be plenty of room for HBH options, SR header,
transport layer, etc.

https://mailarchive.ietf.org/arch/msg/ippm/RapEwM8JcMZjFZtqcsF1NqXWDUI#

I also know from other direct discussions that 256 bytes is the defacto
standard in modern chips.

But the reality is and this has been already said as well that most use
cases use just a few SIDs say anywhere from 1-4. Beyond that while of
course you will find customer stating I need 10 you can use uSID or
draft-li-spring-compressed-srv6-np

Thx,
R.

---

From: Xiejingrong <[email-masked]>
Date: Sat, 14 Sep 2019 02:51:43 +0000

Hi Brian and Robert,

So it really makes much more sense to encode everything in the same EH rather than scatter them around. 
----[xjr1] I agree with Robert 100%.

so header formats should be rigid enough that conditional or linked-list processing can be largely avoided. 
----[xjr2] Sorry Brian, but I think this is truly important!

I've been lectured on the bad design of IPv6 extension headers in a way that only makes sense from an ASIC or FPGA viewpoint. 
----[xjr3] Brian I agree with your principle that it is bad design of IPv6 EH in a way *only* make sense from ASIC/FPGA.
----But in the case we are discussing, I have the strong opinion that "as less as possible EH for a solution" is better than "scatter them around" in any case. 

But anybody who's building the fast path using a network processor doesn't have that constraint and can use the existing extension header design happily enough.
----[xjr4] Brian, are you saying 'DOH before RH' and 'DOH after AH/ESP' as the 'existing extension header design' ? 
----I am afraid the recommended order of 'DOH before RH', 'DOH after AH/ESP' is not the 'existing extension header design'.
----Instead, 'DOH after RH' and 'DOH before AH/ESP' is more preferred. Need examples ?
----RFC8200 as an architecture of IPv6 is just very wisely open for EHs order, because 8200 doesn't know what is the best practice:
----RFC8200: When more than one extension header is used in the same packet, it is recommended that those headers appear in the following order. ----it is recommended, but I guess the 8200 is not sure.
----RFC8200: IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header. ----Except for HBH, relative order of other EHs is widely open.
----RFC8200: Nonetheless, it is strongly advised that sources of IPv6 packets adhere to the above recommended order until and unless subsequent specifications revise that recommendation. ----The subsequent spec can revise the order.
----The need of DOH+RH+AHESP+DOH as a solution is more like a flaunty showing of understand of 8200 rule, but 8200 doesn't have such rule IMO.

Best Regards,
Jingrong

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Friday, September 13, 2019 6:32 AM
To: Robert Raszuk <[email-masked]>; Ron Bonica <[email-masked]>
Cc: [email-masked]; Rob Shakir <[email-masked]>; SPRING WG <[email-masked]>; 6man <[email-masked]>; Tarek Saad <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

Robert,

Regards
   Brian Carpenter