Re: [spring] Beyond SRv6.

[Stewart Bryant]

Zafar

Please can you clarify:

Is that all forwarding ASICs on all platforms or are there some 
restrictions?


- Stewart

On 16/09/2019 16:59, Zafar Ali (zali) wrote:

Dear Chairs and the WG,

As asked by the chairs ...

Cisco ASIC is capable of reading and writing an SRH of up to 9 (nine) 
“128-bit” SIDs at the line rate performance. Furthermore, SRv6 
performance is at par with that is observed during an IPv6 packet 
processing.


Thanks

Regards ... Zafar


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Zafar Ali (zali)]

Dear Chairs and the WG,

As asked by the chairs ...

Cisco ASIC is capable of reading and writing an SRH of up to 9 (nine) “128-bit” 
SIDs at the line rate performance. Furthermore, SRv6 performance is at par with 
that is observed during an IPv6 packet processing.

Thanks

Regards ... Zafar

From: spring  on behalf of Rob Shakir 

Date: Sunday, August 4, 2019 at 5:03 PM
To: SPRING WG List 
Subject: [spring] Beyond SRv6.


Hi SPRING WG,


Over the last 5+ years, the IETF has developed Source Packet Routing in 
NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6 
(SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE.


These encapsulations are past WG last call (in IESG or RFC Editor).


During the SPRING WG meeting at IETF 105, two presentations were related to the 
reduction of the size of the SID for IPv6 dataplane:

  *
  *   SRv6+ / CRH --
  *   https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04
  *
  *
  *   uSID --
  *   
https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01
  *


During the IETF week, two additional drafts have been proposed:

  *
  *   https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00
  *
  *
  *   https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03
  *


As we expressed during the meeting, it is important for the WG to understand 
what the aims of additional encapsulations are. Thus, we think it is important 
that the WG should first get to a common understanding on the requirements for 
a new IPv6 data plane with a smaller SID - both from the perspective of 
operators that are looking to deploy these technologies, and from that of the 
software/hardware implementation.


Therefore, we would like to solicit network operators interested in SR over the 
IPv6 data plane to briefly introduce their:

  *
  *   use case (e.g. Fast Reroute, explicit routing/TE)
  *
  *
  *   forwarding performance and scaling requirements
  *

 *
 *   e.g., (number of nodes, network diameter,
 *   number of SID required in max and average). For the latter, if 
possible using both SRv6 128-bit SIDs and shorter (e.g. 32-bit) SIDs as the 
number would typically be different (*).
 *

  *
  *   if the existing SRv6 approach is not deployable
  *   in their circumstances, details of the requirement of a different 
solution is required and whether this solution is needed for the short term 
only or for the long term.
  *


As well as deployment limitations, we would like the SPRING community to 
briefly describe the platform limitations that they are seeing which limit the 
deployment of SRv6  In particular limitations related to the number of SIDs 
which can be pushed and forwarded and how much the use of shorter SIDs would 
improve the deployments .


For both of these sets of feedback if possible, please post this to the SPRING 
WG. If the information cannot be shared publicly, please send it directly to 
the chairs & AD (Martin).


This call for information will run for four weeks, up to 2019/09/03. As a 
reminder, you can reach the SPRING chairs via 
spring-cha...@ietf.org and ADs via 
spring-...@ietf.org.


Thank you,

-- Rob & Bruno


(*) As expressed on the mailing list, a 128 bit SID can encode two instructions 
a node SID and an adjacency SID hence less SID may be required.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Bernier, Daniel]

Ron

On 2019-09-12, 10:57 AM, "Ron Bonica" 
mailto:rbon...@juniper.net>> wrote:

Dan,

Both good questions !!!

In Ole’s example, a segment endpoint that is not the SR egress node executes a 
service instruction. In SRv6+, this kind of service instruction is called a Per 
Segment Service Instruction (PSSI). It is encoded in a Destination Options 
header that precedes the Routing header. Because IPv6 processes extension 
header in the order that they appear in the packet, this Destination Options 
header is processed by each segment endpoint, including the SR Path egress node.

The Destination Options header includes one or more options. Options are 
processed in the order that they appear in the header. Each option has a unique 
type and the first two bits of the type identifier determine how the processing 
node will behave if it does not recognize the option.

SRv6+ defines a new IPv6 Option, called the PSSI option. The first two bits of 
its type identifier are 00. So, if the processing node does not recognize the 
option, or is not configured to process the option, it skips over the option 
and continues to process the packet. Typically, core routers won’t execute Per 
Segment Service Instructions. So, by default, they will be configured to skip 
over the PSSI option. However, devices that provide per segment services (e.g., 
firewall services , DPI services) will process the PSSI.

But the node still needs to load it and check if it should process before going 
forward. Even more so, when packet arrives at FW service for processing. It has 
the PSSI assigned to FW + the CRH. Once processed, the FW needs to now encap 
the traffic with DOH and a PSSI for the next service segment in the chain (ie 
DPI) how does it know what PSSI to apply ? This would require some end-to-end 
topological state to know what PSSI to apply and when to apply it.

The PSSI by no means attempts to replace the NSH.

In SRv6+, service instructions that are executed by the SR path egress node 
only are called Per Path Service Instructions (PPSI). These instructions are 
encoded in another Destination Options header that precedes the upper layer 
header. This Destination Options header is processed by the SR path egress node 
only.

SRv6+ defines another new IPv6 Option, called the PSSI option. The first two 
bits of its type identifier are 10. So, if the processing node does not 
recognize the option, it discards the packet and sends an ICMP message to the 
packet source.

The benefit of separating the Routing Header from the PPSI are as follows:


-  An AH or ESP header can be interposed between the Routing Header and 
the Destination Options header.  The AH or ESP can be used to protect PPSI.

-  The Routing header isn’t bloated with PPSI information. Therefore, 
ASIC based intermediate nodes don’t have to load PPSI information into on chip 
memory

But they would still need to process PSSI. Again in SRv6, the PPSI is either a 
standard SID entry and if your concerned about chip memory, uSID gives you the 
compressed version.


-  That there is no need to define a myriad of SID’s, some of which are 
valid only when SL is equal to 0 and others that are valid when SL > 0. If an 
instruction is valid only when SL = 0, it isn’t a SID. It is a PPSI.

Again SRH does not define a myriad of SIDs but forwarding behaviours that would 
need to be defined regardless in a SRv6+ device if it wanted to perform the 
same capabilities. Difference is SRH does not require to specify them in the EH 
while SRv6+ would through the PSSI or PPSI


 Ron







Juniper Business Use Only
From: spring  On Behalf Of Bernier, Daniel
Sent: Wednesday, September 11, 2019 11:41 PM
To: xie...@chinatelecom.cn; List 
Cc: Rob Shakir ; 6man <6...@ietf.org>; Tarek Saad 
; Robert Raszuk 
Subject: Re: [spring] Beyond SRv6.


+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!X44n64pmIbfHbV6M9TDLFFeeQIEn4zROUOebJ7V5MYncIU31g1sgm7aA1kXfbfNt$>
 correctly, we then need NSH for richer service c

Re: [spring] Beyond SRv6.

[Bernier, Daniel]

Ron,

But these are not SIDs … these are functions (i.e. processing logic) to be 
executed by a device when receiving a packet where the DA is bound to a Local 
SID associated to one of them.  No need to specify custom extensions per 
function.

With a PPSI, you will still need to specify a different unique identification 
so that when a device needs to process, it knows its needs to do a Layer 3 
lookup, Layer 3 cross-connect, Layer 2 operations, etc.


On 2019-09-12, 2:51 PM, "Ron Bonica" 
mailto:rbon...@juniper.net>> wrote:

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 
Sent: Thursday, September 12, 2019 2:26 PM
To: Ron Bonica ; Mark Smith 
Cc: Rob Shakir ; SPRING WG ; 6man 
<6...@ietf.org>; Robert Raszuk ; xie...@chinatelecom.cn; 
Tarek Saad 
Subject: RE: [spring] Beyond SRv6.

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" 
mailto:rbon...@juniper.net>> 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 mailto:ipv6-boun...@ietf.org>> On Behalf Of 
Mark Smith
Sent: Thursday, September 12, 2019 1:30 AM
To: EXT - daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>
Cc: Rob Shakir mailto:ro...@google.com>>; SPRING WG 
mailto:spring@ietf.org>>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>; Robert Raszuk 
mailto:rob...@raszuk.net>>; 
xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>; Tarek Saad 
mailto:tsaad@gmail.com>>
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, 
mailto:daniel.bern...@bell.ca>> 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 the

Re: [spring] Beyond SRv6.

[Xiejingrong]

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:spring-boun...@ietf.org] On Behalf Of Brian E Carpenter
Sent: Friday, September 13, 2019 6:32 AM
To: Robert Raszuk ; Ron Bonica 
Cc: xie...@chinatelecom.cn; Rob Shakir ; SPRING WG 
; 6man <6...@ietf.org>; Tarek Saad 
Subject: Re: [spring] Beyond SRv6.

Robert,

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

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:
> 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:
> 
>   oLayer 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.
&

Re: [spring] Beyond SRv6.

[Robert Raszuk]

Hi Tom,

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

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.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Tom Herbert]

On Thu, Sep 12, 2019, 4:15 PM Robert Raszuk  wrote:

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

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
> 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
>
>
> On Fri, Sep 13, 2019 at 12:32 AM Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
>
>> Robert,
>>
>> > 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.
>>
>> 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
>
> 
> IETF IPv6 working group mailing list
> i...@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Ron Bonica]

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


Juniper Business Use Only

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

Robert,

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

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:
> 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:
> 
>   oLayer 2 VPN (L2VPN) [RFC6624
> <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$
>  >].
>o  Virtual Private LAN Service (VPLS) [RFC4761 
> <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$
>  >].
> 
> 
> 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  wrote:
> 
>> 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 
>> *Sent:* Thursday, September 12, 2019 2:26 PM
>> *To:* Ron Bonica ; Mark Smith 
>> >>
>> *Cc:* Rob Shakir ; SPRING WG ; 
>> 6man < 6...@ietf.org>; Robert Raszuk 

Re: [spring] Beyond SRv6.

[Robert Raszuk]

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


On Fri, Sep 13, 2019 at 12:32 AM Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:

> Robert,
>
> > 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.
>
> 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
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Brian E Carpenter]

Robert,

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

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:
> 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:
> 
>   oLayer 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  wrote:
> 
>> 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 
>> *Sent:* Thursday, September 12, 2019 2:26 PM
>> *To:* Ron Bonica ; Mark Smith >>
>> *Cc:* Rob Shakir ; SPRING WG ; 6man <
>> 6...@ietf.org>; Robert Raszuk ; xie...@chinatelecom.cn;
>> Tarek Saad 
>> *Subject:* RE: [spring] Beyond SRv6.
>>
>>
>>
>> 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"  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 in

Re: [spring] Beyond SRv6.

[Ron Bonica]

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 
mailto:rob...@raszuk.net>> 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 
mailto:rbon...@juniper.net>> 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.

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

Ron

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Thursday, September 12, 2019 3:34 PM
To: Ron Bonica mailto:rbon...@juniper.net>>
Cc: EXT - daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>; Mark Smith 
mailto:markzzzsm...@gmail.com>>; Rob Shakir 
mailto:ro...@google.com>>; SPRING WG 
mailto:spring@ietf.org>>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>; 
xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>; Tarek Saad 
mailto:tsaad@gmail.com>>
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 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:

  oLayer 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 
mailto:rbon...@juniper.net>> wrote:
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


Juniper Business Use Only
From: Bernier, Daniel mailto:daniel.bern...@bell.ca>>
Sent: Thursday, September 12, 2019 2:26 

Re: [spring] Beyond SRv6.

[Robert Raszuk]

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  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.
>
>
>
> If it is a good idea in SR-MPLS, why is it a bad idea in SRv6+?
>
>
>
> Ron
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Thursday, September 12, 2019 3:34 PM
> *To:* Ron Bonica 
> *Cc:* EXT - daniel.bern...@bell.ca ; Mark Smith <
> markzzzsm...@gmail.com>; Rob Shakir ; SPRING WG <
> spring@ietf.org>; 6man <6...@ietf.org>; xie...@chinatelecom.cn; Tarek
> Saad 
> *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 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:
>
>
>
>   oLayer 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  wrote:
>
> 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
>
>
>
> Juniper Business Use Only
>
> *From:* Bernier, Daniel 
> *Sent:* Thursday, September 12, 2019 2:26 PM
> *To:* Ron Bonica ; Mark Smith  >
> *Cc:* Rob Shakir ; SPRING WG ; 6man <
> 6...@ietf.org>; Robert Raszuk ; xie...@chinatelecom.cn;
> Tarek Saad 
> *Subject:* RE: [spring] Beyond SRv6.
>
>
>
> That was precisely my point
>
>
&g

Re: [spring] Beyond SRv6.

[Ron Bonica]

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 
Sent: Thursday, September 12, 2019 3:34 PM
To: Ron Bonica 
Cc: EXT - daniel.bern...@bell.ca ; Mark Smith 
; Rob Shakir ; SPRING WG 
; 6man <6...@ietf.org>; xie...@chinatelecom.cn; Tarek Saad 

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

  oLayer 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 
mailto:rbon...@juniper.net>> wrote:
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


Juniper Business Use Only
From: Bernier, Daniel mailto:daniel.bern...@bell.ca>>
Sent: Thursday, September 12, 2019 2:26 PM
To: Ron Bonica mailto:rbon...@juniper.net>>; Mark Smith 
mailto:markzzzsm...@gmail.com>>
Cc: Rob Shakir mailto:ro...@google.com>>; SPRING WG 
mailto:spring@ietf.org>>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>; Robert Raszuk 
mailto:rob...@raszuk.net>>; 
xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>; Tarek Saad 
mailto:tsaad@gmail.com>>
Subject: RE: [spring] Beyond SRv6.

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" 
mailto:rbon...@juniper.net>> 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

Re: [spring] Beyond SRv6.

[Robert Raszuk]

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:

  oLayer 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  wrote:

> 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 
> *Sent:* Thursday, September 12, 2019 2:26 PM
> *To:* Ron Bonica ; Mark Smith  >
> *Cc:* Rob Shakir ; SPRING WG ; 6man <
> 6...@ietf.org>; Robert Raszuk ; xie...@chinatelecom.cn;
> Tarek Saad 
> *Subject:* RE: [spring] Beyond SRv6.
>
>
>
> 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"  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  *On Behalf Of *Mark Smith
> *Sent:* Thursday, September 12, 2019 1:30 AM
> *To:* EXT - daniel.bern...@bell.ca 
> *Cc:* Rob Shakir ; SPRING WG ; 6man <
> 6...@ietf.org>; Robert Raszuk ; xie...@chinatelecom.cn;
> Tarek Saad 
> *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, 
> wrote:
>
> +1
>
>
>
> The ability of using a single SRH to convey behaviour information wether
> they are per-segment or per-path has proven to 

Re: [spring] Beyond SRv6.

[Ron Bonica]

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 
Sent: Thursday, September 12, 2019 2:26 PM
To: Ron Bonica ; Mark Smith 
Cc: Rob Shakir ; SPRING WG ; 6man 
<6...@ietf.org>; Robert Raszuk ; xie...@chinatelecom.cn; 
Tarek Saad 
Subject: RE: [spring] Beyond SRv6.

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" 
mailto:rbon...@juniper.net>> 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 mailto:ipv6-boun...@ietf.org>> On Behalf Of 
Mark Smith
Sent: Thursday, September 12, 2019 1:30 AM
To: EXT - daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>
Cc: Rob Shakir mailto:ro...@google.com>>; SPRING WG 
mailto:spring@ietf.org>>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>; Robert Raszuk 
mailto:rob...@raszuk.net>>; 
xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>; Tarek Saad 
mailto:tsaad@gmail.com>>
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, 
mailto:daniel.bern...@bell.ca>> 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 mailto:spring-boun...@ietf.org>> on 
behalf of xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn> 
mailto:xie...@chinatelecom.cn>>
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 feature

Re: [spring] Beyond SRv6.

[Ron Bonica]

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  On Behalf Of Mark Smith
Sent: Thursday, September 12, 2019 1:30 AM
To: EXT - daniel.bern...@bell.ca 
Cc: Rob Shakir ; SPRING WG ; 6man 
<6...@ietf.org>; Robert Raszuk ; xie...@chinatelecom.cn; 
Tarek Saad 
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, 
mailto:daniel.bern...@bell.ca>> 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 mailto:spring-boun...@ietf.org>> on 
behalf of xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn> 
mailto:xie...@chinatelecom.cn>>
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:d...@lapishills.com>
Date: 2019-09-09 21:31
To: Gyan Mishra<mailto:hayabusa...@gmail.com>
CC: SPRING WG List<mailto:spring@ietf.org>; 
6...@ietf.org<mailto:6...@ietf.org>; Robert Raszuk<mailto:rob...@raszuk.net>; 
Rob Shakir<mailto:ro...@google.com>; Tarek Saad<mailto:tsaad@gmail.com>
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
 

Re: [spring] Beyond SRv6.

[Ron Bonica]

Dan,

Both good questions !!!

In Ole’s example, a segment endpoint that is not the SR egress node executes a 
service instruction. In SRv6+, this kind of service instruction is called a Per 
Segment Service Instruction (PSSI). It is encoded in a Destination Options 
header that precedes the Routing header. Because IPv6 processes extension 
header in the order that they appear in the packet, this Destination Options 
header is processed by each segment endpoint, including the SR Path egress node.

The Destination Options header includes one or more options. Options are 
processed in the order that they appear in the header. Each option has a unique 
type and the first two bits of the type identifier determine how the processing 
node will behave if it does not recognize the option.

SRv6+ defines a new IPv6 Option, called the PSSI option. The first two bits of 
its type identifier are 00. So, if the processing node does not recognize the 
option, or is not configured to process the option, it skips over the option 
and continues to process the packet. Typically, core routers won’t execute Per 
Segment Service Instructions. So, by default, they will be configured to skip 
over the PSSI option. However, devices that provide per segment services (e.g., 
firewall services , DPI services) will process the PSSI.

The PSSI by no means attempts to replace the NSH.

In SRv6+, service instructions that are executed by the SR path egress node 
only are called Per Path Service Instructions (PPSI). These instructions are 
encoded in another Destination Options header that precedes the upper layer 
header. This Destination Options header is processed by the SR path egress node 
only.

SRv6+ defines another new IPv6 Option, called the PSSI option. The first two 
bits of its type identifier are 10. So, if the processing node does not 
recognize the option, it discards the packet and sends an ICMP message to the 
packet source.

The benefit of separating the Routing Header from the PPSI are as follows:


  *   An AH or ESP header can be interposed between the Routing Header and the 
Destination Options header.  The AH or ESP can be used to protect PPSI.
  *   The Routing header isn’t bloated with PPSI information. Therefore, ASIC 
based intermediate nodes don’t have to load PPSI information into on chip memory
  *   That there is no need to define a myriad of SID’s, some of which are 
valid only when SL is equal to 0 and others that are valid when SL > 0. If an 
instruction is valid only when SL = 0, it isn’t a SID. It is a PPSI.


 Ron







Juniper Business Use Only
From: spring  On Behalf Of Bernier, Daniel
Sent: Wednesday, September 11, 2019 11:41 PM
To: xie...@chinatelecom.cn; List 
Cc: Rob Shakir ; 6man <6...@ietf.org>; Tarek Saad 
; Robert Raszuk 
Subject: Re: [spring] Beyond SRv6.


+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!X44n64pmIbfHbV6M9TDLFFeeQIEn4zROUOebJ7V5MYncIU31g1sgm7aA1kXfbfNt$>
 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 mailto:spring-boun...@ietf.org>> on 
behalf of xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn> 
mailto:xie...@chinatelecom.cn>>
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 complet

Re: [spring] Beyond SRv6.

[Tom Herbert]

On Wed, Sep 11, 2019 at 10:20 PM Xiejingrong  wrote:
>
> +1
>
> I think the need to ‘walk through the EH chain’ in fast-path is difficult, 
> for the last 2 decades, and will for the near future I guess.
>
> The SRv6 is very careful not to ‘walk through the EH chain’.
>
> Instead it just ‘handle the least leading header(s)’, with a preceding ‘FIB 
> lookup’ indication, and ‘FIB lookup’ is a step that will need to do in chip 
> anyway for any packet.
>
Jingrong,

You seem to be ignoring the fact that SRH includes its own TLV
mechanism. There is no reason to believe that TLVs in the segment
header can somehow be more efficiently processed than TLVs in
Destination Options or Hop-by-Hop Options. Considering that there
seems to be almost no implementation of segment routing TLVs (so far
only Linux is reported to support it and even then the implementation
is not conformant), I'm dubious of any claims that SRv6 is chip
friendly or works in fast-path. If the idea is that TLVs in SRH really
aren't needed and will never actually be used, then it would appear
that the considerable effort in 6man WG trying to fix them was wasted
on a mere academic exercise.

Tom

> This makes SRv6 deployable in chips for the first time of EH invention by ISO 
> and later by IPv6.
>
> This makes SRv6 the paradigm of handling any EH in chips In my opinion.
>
>
>
> One can check my understand on page 11 to 14 of the slides I prepared in 
> ietf105 (though got no time slot to present):
>
> https://datatracker.ietf.org/meeting/105/materials/slides-105-bier-bier-ipv6-encapsulation-00.pdf
>
>
>
> DOH has it benefits, and is recommended in 8200, but the mix of many 
> different EHs and different Option TLVs for a solution is obviously complex 
> in data-plane.
>
> Using a single EH to the best, with the appropriate preceding indication, is 
> simple, ordered, friendly to chip, direct, perfect.
>
> https://mailarchive.ietf.org/arch/msg/ipv6/SgkSGtSBmB4G51ajnBp3UbjJl8I
>
>
>
> Thanks
>
> Jingrong
>
>
>
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Bernier, Daniel
> Sent: Thursday, September 12, 2019 11:41 AM
> To: xie...@chinatelecom.cn; List 
> Cc: Rob Shakir ; 6man <6...@ietf.org>; Tarek Saad 
> ; Robert Raszuk 
> Subject: Re: [spring] Beyond SRv6.
>
>
>
> +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 complex.
>
>
>
> 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 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  on behalf of xie...@chinatelecom.cn 
> 
> 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
>
> Da

Re: [spring] Beyond SRv6.

[Mark Smith]

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,  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 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  on behalf of
> xie...@chinatelecom.cn 
> *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 
> *Date:* 2019-09-09 21:31
> *To:* Gyan Mishra 
> *CC:* SPRING WG List ; 6...@ietf.org; Robert Raszuk
> ; Rob Shakir ; Tarek Saad
> 
> *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 he

Re: [spring] Beyond SRv6.

[Xiejingrong]

+1
I think the need to ‘walk through the EH chain’ in fast-path is difficult, for 
the last 2 decades, and will for the near future I guess.
The SRv6 is very careful not to ‘walk through the EH chain’.
Instead it just ‘handle the least leading header(s)’, with a preceding ‘FIB 
lookup’ indication, and ‘FIB lookup’ is a step that will need to do in chip 
anyway for any packet.
This makes SRv6 deployable in chips for the first time of EH invention by ISO 
and later by IPv6.
This makes SRv6 the paradigm of handling any EH in chips In my opinion.

One can check my understand on page 11 to 14 of the slides I prepared in 
ietf105 (though got no time slot to present):
https://datatracker.ietf.org/meeting/105/materials/slides-105-bier-bier-ipv6-encapsulation-00.pdf

DOH has it benefits, and is recommended in 8200, but the mix of many different 
EHs and different Option TLVs for a solution is obviously complex in data-plane.
Using a single EH to the best, with the appropriate preceding indication, is 
simple, ordered, friendly to chip, direct, perfect.
https://mailarchive.ietf.org/arch/msg/ipv6/SgkSGtSBmB4G51ajnBp3UbjJl8I

Thanks
Jingrong

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Bernier, Daniel
Sent: Thursday, September 12, 2019 11:41 AM
To: xie...@chinatelecom.cn; List 
Cc: Rob Shakir ; 6man <6...@ietf.org>; Tarek Saad 
; Robert Raszuk 
Subject: Re: [spring] Beyond SRv6.


+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 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 mailto:spring-boun...@ietf.org>> on 
behalf of xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn> 
mailto:xie...@chinatelecom.cn>>
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:d...@lapishills.com>
Date: 2019-09-09 21:31
To: Gyan Mishra<mailto:hayabusa...@gmail.com>
CC: SPRING WG List<mailto:spring@ietf.org>; 
6...@ietf.org<mailto:6...@ietf.org>; Robert Raszuk<mailto:rob...@raszuk.net>; 
Rob Shakir<mailto:ro...@google.com>; Tarek Saad<mailto:tsaad@gmail.com>
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

Re: [spring] Beyond SRv6.

[Bernier, Daniel]

+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 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  on behalf of xie...@chinatelecom.cn 

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:d...@lapishills.com>
Date: 2019-09-09 21:31
To: Gyan Mishra<mailto:hayabusa...@gmail.com>
CC: SPRING WG List<mailto:spring@ietf.org>; 
6...@ietf.org<mailto:6...@ietf.org>; Robert Raszuk<mailto:rob...@raszuk.net>; 
Rob Shakir<mailto:ro...@google.com>; Tarek Saad<mailto:tsaad@gmail.com>
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 
mailto:hayabusa...@gmail.com>>:

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 th

Re: [spring] Beyond SRv6.

[Tom Herbert]

On Wed, Sep 11, 2019 at 5:58 PM xie...@chinatelecom.cn
 wrote:
>
>
> 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.
>
Chongfeng,

That presumes that SRv6 is a least common denominator in networks and
indispensable core functionality. It's not. As already pointed there
are existing alternatives that might be operative for adding services
like APN. SRv6 is one manifestation, but not the only one-- there's
NSH, SR-MPLS, other encapsulations, etc. From this POV, SRv6+, and
even SRv6, is just another mechanism. Naturally, we want solutions
that work across the broadest number of cases possible. So the
question is: what are the common functionalities that could work
across these different methods. In IPv6, it's DOH and HBH options that
are common across all forms of routing header and packets. So, IMO,
those should be considered first before investing in narrower
solutions (i.e. TLVs is the routing header). There is a similar
argument in security that AH should have been considered before
creating a point solution in the HMAC of SRv6.

Tom

> Best regards
> Chongfeng
>
>
> From: Dirk Steinberg
> Date: 2019-09-09 21:31
> To: Gyan Mishra
> CC: SPRING WG List; 6...@ietf.org; Robert Raszuk; Rob Shakir; Tarek Saad
> 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 :
>
> 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 stitchi

Re: [spring] Beyond SRv6.

[xie...@chinatelecom.cn]

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
Date: 2019-09-09 21:31
To: Gyan Mishra
CC: SPRING WG List; 6...@ietf.org; Robert Raszuk; Rob Shakir; Tarek Saad
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 :

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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Hirofumi Ichihara]

Hi Satoru,
​
Of course, okay. That sounds good.
​
Thanks,
Hirofumi

-Original Message-
From: "Satoru Matsushima"
To: "Hirofumi Ichihara"; "SPRING WG 
List";
Cc: "Ron Bonica"; <6...@ietf.org>; 
"Robert Raszuk"; "Rob Shakir"; "Tarek 
Saad";
Sent: 2019-09-11 (水) 10:31:12 (GMT+09:00)
Subject: Re: [spring] Beyond SRv6.
 
Excellent news.
 
I’d capture your case in the SRv6 deployment draft, in case you’d be okay.

Cheers,
--satoru

2019/09/11 9:55、Hirofumi Ichihara のメール:
 

Hi folks,
​
Let me mention my opinion as an operator.
​
Our company already has deployed and used SRv6 Network in our DC. Our use case 
is L3VPN to isolate network for each multi-tenant and we decided to use 
T.Encaps and End.DX4. Currently, we deployed hypervisors and gateway nodes 
which are aware of SRv6. Although there are many routers not supported SRv6 
between HVs and GW nodes, it works fine because of current SRH mechanism. We 
actually use one SID only between HV and HV, HV and GW so we don't face the 
issue like many SIDs now although we have a plan to use multiple SIDs for our 
SFC use case.
​
We don't have specific opinion to shorter SIDs. However, we operator hope 
strongly that new thing must configure backward compatibility or reasonable 
migration plan.
​
Thanks,
Hirofumi

-Original Message-
From: "Shraddha Hegde"
To: "Andy Smith (andsmit)"; "Ron 
Bonica";
Cc: "SPRING WG List"; "6...@ietf.org"<6...@ietf.org>; "Gyan 
Mishra"; "Robert Raszuk"; "Rob 
Shakir"; "Tarek Saad";
Sent: 2019-09-10 (火) 02:51:48 (GMT+09:00)
Subject: Re: [spring] Beyond SRv6.
 
Andy,
 
RFC 6119 defines ipv6 router-id .
It is not mandatory to advertise IPv4 router-id in ISIS.
 
Rgds
Shraddha
 
From: spring  On Behalf Of Andy Smith (andsmit)
Sent: Monday, September 9, 2019 10:07 PM
To: Ron Bonica 
Cc: SPRING WG List ; 6...@ietf.org; Gyan Mishra 
; Robert Raszuk ; Rob Shakir 
; Tarek Saad 
Subject: Re: [spring] Beyond SRv6.
 
Ron,
 
Doesn't ISIS require a quad octet / 32 bit / IPv4 address for it's router ID?
 
So you can't really build an ipv4 'free' network.   Not 100% anyway.
 
Andy
 
 



On Sep 9, 2019, at 12:21 PM, Ron Bonica  
wrote:
 
Hello Gyan,
 
Amplifying what you have said…..
 
There is no reason why SR-MPLS shouldn’t work over an IPv6 only infrastructure. 
So long as every node is MPLS capable, SR-MPLS should not require IPv4 to be 
enabled.
 
   
Ron
 
 
 
Juniper Business Use Only
From: Gyan Mishra  
Sent: Sunday, September 8, 2019 3:20 AM
To: Robert Raszuk 
Cc: Srihari Sangli ; SPRING WG List ; 
6...@ietf.org; Zafar Ali (zali) ; Rob Shakir 
; Ron Bonica ; Tarek Saad 

Subject: Re: [spring] Beyond SRv6.
 
As an operator of a Tier 1 provider with massive mpls networks I think our 
traditional bread and butter “mpls” will be around for a very very long time as 
is IPv4 if not longer.
 
Most all service provider cores run greater then or equal to MTU 9000 mpls 
cores to account for mpls overhead shims being tacked on plus edge overhead 
from possible GRE tunneling or IPSEC so in general making  the core the maximum 
Jumbo MTU supported by most vendors at 9216 is what is generally done out in 
the field.
 
So for SRv6 support of multiple or many EH insertions is really a non issue for 
most operators.
 
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.
 
I do agree with some of the other operators on the marketing hype and push for 
SR-MPLS and SRv6 is not for every service provider as goes the mantra ..”if 
it’s not broken..don’t try to fix it..leave it alone” and I think you can 
definitely say that for MPLS as it has had a SOLID run for service providers 
since the 90’s ever since ATM and frame relay were put to rest so I don’t think 
that it’s going away any time soon.
 
I think it would be a serious mistake and sad state of affairs for vendors to 
push SR-MPLS and SRv6 and stop development and support of MPLS as that would 
really pigeon hole all operators into one technology which does not fit the 
bi

Re: [spring] Beyond SRv6.

[Satoru Matsushima]

Excellent news.

I’d capture your case in the SRv6 deployment draft, in case you’d be okay.

Cheers,
--satoru

2019/09/11 9:55、Hirofumi Ichihara のメール:

> Hi folks,
> ​
> Let me mention my opinion as an operator.
> ​
> Our company already has deployed and used SRv6 Network in our DC. Our use 
> case is L3VPN to isolate network for each multi-tenant and we decided to use 
> T..Encaps and End.DX4. Currently, we deployed hypervisors and gateway nodes 
> which are aware of SRv6. Although there are many routers not supported SRv6 
> between HVs and GW nodes, it works fine because of current SRH mechanism. We 
> actually use one SID only between HV and HV, HV and GW so we don't face the 
> issue like many SIDs now although we have a plan to use multiple SIDs for our 
> SFC use case.
> ​
> We don't have specific opinion to shorter SIDs. However, we operator hope 
> strongly that new thing must configure backward compatibility or reasonable 
> migration plan.
> ​
> Thanks,
> Hirofumi
> 
> -Original Message-
> From: "Shraddha Hegde" 
> To: "Andy Smith (andsmit)"; "Ron 
> Bonica"; 
> Cc: "SPRING WG List"; "6...@ietf.org"<6...@ietf.org>; "Gyan 
> Mishra"; "Robert Raszuk"; "Rob 
> Shakir"; "Tarek Saad"; 
> Sent: 2019-09-10 (火) 02:51:48 (GMT+09:00)
> Subject: Re: [spring] Beyond SRv6.
>  
> Andy,
>  
> RFC 6119 defines ipv6 router-id .
> It is not mandatory to advertise IPv4 router-id in ISIS.
>  
> Rgds
> Shraddha
>  
> From: spring  On Behalf Of Andy Smith (andsmit)
> Sent: Monday, September 9, 2019 10:07 PM
> To: Ron Bonica 
> Cc: SPRING WG List ; 6...@ietf.org; Gyan Mishra 
> ; Robert Raszuk ; Rob Shakir 
> ; Tarek Saad 
> Subject: Re: [spring] Beyond SRv6.
>  
> Ron,
>  
> Doesn't ISIS require a quad octet / 32 bit / IPv4 address for it's router ID?
>  
> So you can't really build an ipv4 'free' network.   Not 100% anyway.
>  
> Andy
>  
>  
> 
> 
> On Sep 9, 2019, at 12:21 PM, Ron Bonica 
>  wrote:
>  
> Hello Gyan,
>  
> Amplifying what you have said…..
>  
> There is no reason why SR-MPLS shouldn’t work over an IPv6 only 
> infrastructure. So long as every node is MPLS capable, SR-MPLS should not 
> require IPv4 to be enabled.
>  
>               
>  Ron
>  
>  
>  
> Juniper Business Use Only
> From: Gyan Mishra  
> Sent: Sunday, September 8, 2019 3:20 AM
> To: Robert Raszuk 
> Cc: Srihari Sangli ; SPRING WG List ; 
> 6...@ietf.org; Zafar Ali (zali) ; Rob Shakir 
> ; Ron Bonica ; Tarek Saad 
> 
> Subject: Re: [spring] Beyond SRv6.
>  
> As an operator of a Tier 1 provider with massive mpls networks I think our 
> traditional bread and butter “mpls” will be around for a very very long time 
> as is IPv4 if not longer.
>  
> Most all service provider cores run greater then or equal to MTU 9000 mpls 
> cores to account for mpls overhead shims being tacked on plus edge overhead 
> from possible GRE tunneling or IPSEC so in general making  the core the 
> maximum Jumbo MTU supported by most vendors at 9216 is what is generally done 
> out in the field.
>  
> So for SRv6 support of multiple or many EH insertions is really a non issue 
> for 
> most operators.
>  
> 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.
>  
> I do agree with some of the other operators on the marketing hype and push 
> for SR-MPLS and SRv6 is not for every service provider as goes the mantra 
> ...”if it’s not broken..don’t try to fix it..leave it alone” and I think you 
> can definitely say that for MPLS as it has had a SOLID run for service 
> providers since the 90’s ever since ATM and frame relay were put to rest so I 
> don’t think that it’s going away any time soon.
>  
> I think it would be a serious mistake and sa

Re: [spring] Beyond SRv6.

[Hirofumi Ichihara]

Hi folks,
​
Let me mention my opinion as an operator.
​
Our company already has deployed and used SRv6 Network in our DC. Our use case 
is L3VPN to isolate network for each multi-tenant and we decided to use 
T.Encaps and End.DX4. Currently, we deployed hypervisors and gateway nodes 
which are aware of SRv6. Although there are many routers not supported SRv6 
between HVs and GW nodes, it works fine because of current SRH mechanism. We 
actually use one SID only between HV and HV, HV and GW so we don't face the 
issue like many SIDs now although we have a plan to use multiple SIDs for our 
SFC use case.
​
We don't have specific opinion to shorter SIDs. However, we operator hope 
strongly that new thing must configure backward compatibility or reasonable 
migration plan.
​
Thanks,
Hirofumi

-Original Message-
From: "Shraddha Hegde"
To: "Andy Smith (andsmit)"; "Ron 
Bonica";
Cc: "SPRING WG List"; "6...@ietf.org"<6...@ietf.org>; "Gyan 
Mishra"; "Robert Raszuk"; "Rob 
Shakir"; "Tarek Saad";
Sent: 2019-09-10 (火) 02:51:48 (GMT+09:00)
Subject: Re: [spring] Beyond SRv6.
 
Andy,
 
RFC 6119 defines ipv6 router-id .
It is not mandatory to advertise IPv4 router-id in ISIS.
 
Rgds
Shraddha
 
From: spring  On Behalf Of Andy Smith (andsmit)
Sent: Monday, September 9, 2019 10:07 PM
To: Ron Bonica 
Cc: SPRING WG List ; 6...@ietf.org; Gyan Mishra 
; Robert Raszuk ; Rob Shakir 
; Tarek Saad 
Subject: Re: [spring] Beyond SRv6.
 
Ron,
 
Doesn't ISIS require a quad octet / 32 bit / IPv4 address for it's router ID?
 
So you can't really build an ipv4 'free' network.   Not 100% anyway.
 
Andy
 
 



On Sep 9, 2019, at 12:21 PM, Ron Bonica  
wrote:
 
Hello Gyan,
 
Amplifying what you have said…..
 
There is no reason why SR-MPLS shouldn’t work over an IPv6 only infrastructure. 
So long as every node is MPLS capable, SR-MPLS should not require IPv4 to be 
enabled.
 
   
Ron
 
 
 
Juniper Business Use Only
From: Gyan Mishra  
Sent: Sunday, September 8, 2019 3:20 AM
To: Robert Raszuk 
Cc: Srihari Sangli ; SPRING WG List ; 
6...@ietf.org; Zafar Ali (zali) ; Rob Shakir 
; Ron Bonica ; Tarek Saad 

Subject: Re: [spring] Beyond SRv6.
 
As an operator of a Tier 1 provider with massive mpls networks I think our 
traditional bread and butter “mpls” will be around for a very very long time as 
is IPv4 if not longer.
 
Most all service provider cores run greater then or equal to MTU 9000 mpls 
cores to account for mpls overhead shims being tacked on plus edge overhead 
from possible GRE tunneling or IPSEC so in general making  the core the maximum 
Jumbo MTU supported by most vendors at 9216 is what is generally done out in 
the field.
 
So for SRv6 support of multiple or many EH insertions is really a non issue for 
most operators.
 
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.
 
I do agree with some of the other operators on the marketing hype and push for 
SR-MPLS and SRv6 is not for every service provider as goes the mantra ..”if 
it’s not broken..don’t try to fix it..leave it alone” and I think you can 
definitely say that for MPLS as it has had a SOLID run for service providers 
since the 90’s ever since ATM and frame relay were put to rest so I don’t think 
that it’s going away any time soon.
 
I think it would be a serious mistake and sad state of affairs for vendors to 
push SR-MPLS and SRv6 and stop development and support of MPLS as that would 
really pigeon hole all operators into one technology which does not fit the 
bill for every use case out there.
 
The mention of SR-MPLS pulling support for IPv6 and forcing operators to go 
with SRv6 is a wrong move for vendors and would really limit operators with 
flexibility to chose based on their use case to stay with traditional mpls or 
go with with SR-MPLS or SRv6 only if necessary with their unique use case 
warrants..
 
I think SR-MPLS and SRv6 should be marketed by vendors and the industry as yet 
another tool in our operator “design toolbox” to use as we see fit or not use 
but not be forced into it.
 
There are pa

Re: [spring] Beyond SRv6.

[Shraddha Hegde]

Andy,

RFC 6119 defines ipv6 router-id .
It is not mandatory to advertise IPv4 router-id in ISIS.

Rgds
Shraddha

From: spring  On Behalf Of Andy Smith (andsmit)
Sent: Monday, September 9, 2019 10:07 PM
To: Ron Bonica 
Cc: SPRING WG List ; 6...@ietf.org; Gyan Mishra 
; Robert Raszuk ; Rob Shakir 
; Tarek Saad 
Subject: Re: [spring] Beyond SRv6.

Ron,

Doesn't ISIS require a quad octet / 32 bit / IPv4 address for it's router ID?

So you can't really build an ipv4 'free' network.   Not 100% anyway.

Andy




On Sep 9, 2019, at 12:21 PM, Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>
 wrote:

Hello Gyan,

Amplifying what you have said…..

There is no reason why SR-MPLS shouldn’t work over an IPv6 only infrastructure. 
So long as every node is MPLS capable, SR-MPLS should not require IPv4 to be 
enabled.

   
Ron



Juniper Business Use Only
From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Sent: Sunday, September 8, 2019 3:20 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Srihari Sangli mailto:ssan...@juniper.net>>; SPRING WG 
List mailto:spring@ietf.org>>; 
6...@ietf.org<mailto:6...@ietf.org>; Zafar Ali (zali) 
mailto:z...@cisco.com>>; Rob Shakir 
mailto:ro...@google.com>>; Ron Bonica 
mailto:rbon...@juniper.net>>; Tarek Saad 
mailto:tsaad@gmail.com>>
Subject: Re: [spring] Beyond SRv6.

As an operator of a Tier 1 provider with massive mpls networks I think our 
traditional bread and butter “mpls” will be around for a very very long time as 
is IPv4 if not longer.

Most all service provider cores run greater then or equal to MTU 9000 mpls 
cores to account for mpls overhead shims being tacked on plus edge overhead 
from possible GRE tunneling or IPSEC so in general making  the core the maximum 
Jumbo MTU supported by most vendors at 9216 is what is generally done out in 
the field.

So for SRv6 support of multiple or many EH insertions is really a non issue for
most operators.

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.

I do agree with some of the other operators on the marketing hype and push for 
SR-MPLS and SRv6 is not for every service provider as goes the mantra ..”if 
it’s not broken..don’t try to fix it..leave it alone” and I think you can 
definitely say that for MPLS as it has had a SOLID run for service providers 
since the 90’s ever since ATM and frame relay were put to rest so I don’t think 
that it’s going away any time soon.

I think it would be a serious mistake and sad state of affairs for vendors to 
push SR-MPLS and SRv6 and stop development and support of MPLS as that would 
really pigeon hole all operators into one technology which does not fit the 
bill for every use case out there.

The mention of SR-MPLS pulling support for IPv6 and forcing operators to go 
with SRv6 is a wrong move for vendors and would really limit operators with 
flexibility to chose based on their use case to stay with traditional mpls or 
go with with SR-MPLS or SRv6 only if necessary with their unique use case 
warrants..

I think SR-MPLS and SRv6 should be marketed by vendors and the industry as yet 
another tool in our operator “design toolbox” to use as we see fit or not use 
but not be forced into it.

There are particular use cases for SR-MPLS for migration from existing LDP and 
the downside of having state maintained in the core is not a downside as the P 
and PE nodes have to be provisioned anyway so their is no savings in pulling 
mpls LDP/mLDP with SR-MPLS “Sr-prefer” and ditching LDP.

I think the major use case for SR-MPLS and SRv6 is coloring per-vrf TE feature 
for L3 VPNs steering without adding complexity of adding ibgp loopback egress 
PE FEC next hop to traffic engineer L3 VPN traffic.  That is a unique use case 
and not every major service provider has that requirement so if you don’t their 
really is no need to jump on the SR band wagon and you can stay put with the 
tried and true mpls that has been around for decades and is not going away any 
time soon.

SRv6 has a more ubiquitous all encompassing use case that could serve for MPLS 
core replacement

Re: [spring] Beyond SRv6.

[Andy Smith (andsmit)]

Ron,

Doesn't ISIS require a quad octet / 32 bit / IPv4 address for it's router ID?

So you can't really build an ipv4 'free' network.   Not 100% anyway.

Andy



> On Sep 9, 2019, at 12:21 PM, Ron Bonica 
>  wrote:
> 
> Hello Gyan,
>  
> Amplifying what you have said…..
>  
> There is no reason why SR-MPLS shouldn’t work over an IPv6 only 
> infrastructure. So long as every node is MPLS capable, SR-MPLS should not 
> require IPv4 to be enabled.
>  
>   
>  Ron
>  
>  
>  
> Juniper Business Use Only
> From: Gyan Mishra mailto:hayabusa...@gmail.com>> 
> Sent: Sunday, September 8, 2019 3:20 AM
> To: Robert Raszuk mailto:rob...@raszuk.net>>
> Cc: Srihari Sangli mailto:ssan...@juniper.net>>; SPRING 
> WG List mailto:spring@ietf.org>>; 6...@ietf.org 
> <mailto:6...@ietf.org>; Zafar Ali (zali)  <mailto:z...@cisco.com>>; Rob Shakir  <mailto:ro...@google.com>>; Ron Bonica  <mailto:rbon...@juniper.net>>; Tarek Saad  <mailto:tsaad@gmail.com>>
> Subject: Re: [spring] Beyond SRv6.
>  
> As an operator of a Tier 1 provider with massive mpls networks I think our 
> traditional bread and butter “mpls” will be around for a very very long time 
> as is IPv4 if not longer.
>  
> Most all service provider cores run greater then or equal to MTU 9000 mpls 
> cores to account for mpls overhead shims being tacked on plus edge overhead 
> from possible GRE tunneling or IPSEC so in general making  the core the 
> maximum Jumbo MTU supported by most vendors at 9216 is what is generally done 
> out in the field.
>  
> So for SRv6 support of multiple or many EH insertions is really a non issue 
> for 
> most operators.
>  
> 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.
>  
> I do agree with some of the other operators on the marketing hype and push 
> for SR-MPLS and SRv6 is not for every service provider as goes the mantra 
> ..”if it’s not broken..don’t try to fix it..leave it alone” and I think you 
> can definitely say that for MPLS as it has had a SOLID run for service 
> providers since the 90’s ever since ATM and frame relay were put to rest so I 
> don’t think that it’s going away any time soon.
>  
> I think it would be a serious mistake and sad state of affairs for vendors to 
> push SR-MPLS and SRv6 and stop development and support of MPLS as that would 
> really pigeon hole all operators into one technology which does not fit the 
> bill for every use case out there.
>  
> The mention of SR-MPLS pulling support for IPv6 and forcing operators to go 
> with SRv6 is a wrong move for vendors and would really limit operators with 
> flexibility to chose based on their use case to stay with traditional mpls or 
> go with with SR-MPLS or SRv6 only if necessary with their unique use case 
> warrants..
>  
> I think SR-MPLS and SRv6 should be marketed by vendors and the industry as 
> yet another tool in our operator “design toolbox” to use as we see fit or not 
> use but not be forced into it.
>  
> There are particular use cases for SR-MPLS for migration from existing LDP 
> and the downside of having state maintained in the core is not a downside as 
> the P and PE nodes have to be provisioned anyway so their is no savings in 
> pulling mpls LDP/mLDP with SR-MPLS “Sr-prefer” and ditching LDP.   
>  
> I think the major use case for SR-MPLS and SRv6 is coloring per-vrf TE 
> feature for L3 VPNs steering without adding complexity of adding ibgp 
> loopback egress PE FEC next hop to traffic engineer L3 VPN traffic.  That is 
> a unique use case and not every major service provider has that requirement 
> so if you don’t their really is no need to jump on the SR band wagon and you 
> can stay put with the tried and true mpls that has been around for decades 
> and is not going away any time soon.
>  
> SRv6 has a more ubiquitou

Re: [spring] Beyond SRv6.

[Ron Bonica]

Hello Gyan,

Amplifying what you have said.

There is no reason why SR-MPLS shouldn't work over an IPv6 only infrastructure. 
So long as every node is MPLS capable, SR-MPLS should not require IPv4 to be 
enabled.

   
Ron




Juniper Business Use Only
From: Gyan Mishra 
Sent: Sunday, September 8, 2019 3:20 AM
To: Robert Raszuk 
Cc: Srihari Sangli ; SPRING WG List ; 
6...@ietf.org; Zafar Ali (zali) ; Rob Shakir 
; Ron Bonica ; Tarek Saad 

Subject: Re: [spring] Beyond SRv6.

As an operator of a Tier 1 provider with massive mpls networks I think our 
traditional bread and butter "mpls" will be around for a very very long time as 
is IPv4 if not longer.

Most all service provider cores run greater then or equal to MTU 9000 mpls 
cores to account for mpls overhead shims being tacked on plus edge overhead 
from possible GRE tunneling or IPSEC so in general making  the core the maximum 
Jumbo MTU supported by most vendors at 9216 is what is generally done out in 
the field.

So for SRv6 support of multiple or many EH insertions is really a non issue for
most operators.

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

I do agree with some of the other operators on the marketing hype and push for 
SR-MPLS and SRv6 is not for every service provider as goes the mantra ..."if 
it's not broken..don't try to fix it..leave it alone" and I think you can 
definitely say that for MPLS as it has had a SOLID run for service providers 
since the 90's ever since ATM and frame relay were put to rest so I don't think 
that it's going away any time soon.

I think it would be a serious mistake and sad state of affairs for vendors to 
push SR-MPLS and SRv6 and stop development and support of MPLS as that would 
really pigeon hole all operators into one technology which does not fit the 
bill for every use case out there.

The mention of SR-MPLS pulling support for IPv6 and forcing operators to go 
with SRv6 is a wrong move for vendors and would really limit operators with 
flexibility to chose based on their use case to stay with traditional mpls or 
go with with SR-MPLS or SRv6 only if necessary with their unique use case 
warrants.

I think SR-MPLS and SRv6 should be marketed by vendors and the industry as yet 
another tool in our operator "design toolbox" to use as we see fit or not use 
but not be forced into it.

There are particular use cases for SR-MPLS for migration from existing LDP and 
the downside of having state maintained in the core is not a downside as the P 
and PE nodes have to be provisioned anyway so their is no savings in pulling 
mpls LDP/mLDP with SR-MPLS "Sr-prefer" and ditching LDP.

I think the major use case for SR-MPLS and SRv6 is coloring per-vrf TE feature 
for L3 VPNs steering without adding complexity of adding ibgp loopback egress 
PE FEC next hop to traffic engineer L3 VPN traffic.  That is a unique use case 
and not every major service provider has that requirement so if you don't their 
really is no need to jump on the SR band wagon and you can stay put with the 
tried and true mpls that has been around for decades and is not going away any 
time soon.

SRv6 has a more ubiquitous all encompassing use case that could serve for MPLS 
core replacement or on the public internet or for enterprise network traffic 
engineering of flows between data centers or access to data center and an 
alternative to SD WAN application based routing solutions.  But here as well 
the use case benefit has to exist.  Nobody wants to be forced into it if it's 
unnecessary added complexity.

My 2 1/2 cents

Regards,

Gyan Mishra
Verizon Communications
Cell- 301 502-1347

Sent from my iPhone

On Sep 6, 2019, at 10:17 AM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
I don't think so.

In OAM packets are on purpose made huge - even up to MTU to make sure real 
customer packets can go through or to detect and diagnose MTU issues. So adding 
SRH to it is nothing one can call inefficient.

Wrong tree :)

Cheers,
R.

On Fri, Sep 6, 2019 at 4:14 PM Srihari Sangli 
mailto:ssan...@j

Re: [spring] Beyond SRv6.

[Dirk Steinberg]

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 :
> 
> 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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Gyan Mishra]

As an operator of a Tier 1 provider with massive mpls networks I think our 
traditional bread and butter “mpls” will be around for a very very long time as 
is IPv4 if not longer.

Most all service provider cores run greater then or equal to MTU 9000 mpls 
cores to account for mpls overhead shims being tacked on plus edge overhead 
from possible GRE tunneling or IPSEC so in general making  the core the maximum 
Jumbo MTU supported by most vendors at 9216 is what is generally done out in 
the field.

So for SRv6 support of multiple or many EH insertions is really a non issue for 
most operators.

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.

I do agree with some of the other operators on the marketing hype and push for 
SR-MPLS and SRv6 is not for every service provider as goes the mantra ..”if 
it’s not broken..don’t try to fix it..leave it alone” and I think you can 
definitely say that for MPLS as it has had a SOLID run for service providers 
since the 90’s ever since ATM and frame relay were put to rest so I don’t think 
that it’s going away any time soon.

I think it would be a serious mistake and sad state of affairs for vendors to 
push SR-MPLS and SRv6 and stop development and support of MPLS as that would 
really pigeon hole all operators into one technology which does not fit the 
bill for every use case out there.

The mention of SR-MPLS pulling support for IPv6 and forcing operators to go 
with SRv6 is a wrong move for vendors and would really limit operators with 
flexibility to chose based on their use case to stay with traditional mpls or 
go with with SR-MPLS or SRv6 only if necessary with their unique use case 
warrants.

I think SR-MPLS and SRv6 should be marketed by vendors and the industry as yet 
another tool in our operator “design toolbox” to use as we see fit or not use 
but not be forced into it.

There are particular use cases for SR-MPLS for migration from existing LDP and 
the downside of having state maintained in the core is not a downside as the P 
and PE nodes have to be provisioned anyway so their is no savings in pulling 
mpls LDP/mLDP with SR-MPLS “Sr-prefer” and ditching LDP.   

I think the major use case for SR-MPLS and SRv6 is coloring per-vrf TE feature 
for L3 VPNs steering without adding complexity of adding ibgp loopback egress 
PE FEC next hop to traffic engineer L3 VPN traffic.  That is a unique use case 
and not every major service provider has that requirement so if you don’t their 
really is no need to jump on the SR band wagon and you can stay put with the 
tried and true mpls that has been around for decades and is not going away any 
time soon.

SRv6 has a more ubiquitous all encompassing use case that could serve for MPLS 
core replacement or on the public internet or for enterprise network traffic 
engineering of flows between data centers or access to data center and an 
alternative to SD WAN application based routing solutions.  But here as well 
the use case benefit has to exist.  Nobody wants to be forced into it if it’s 
unnecessary added complexity.

My 2 1/2 cents 

Regards,

Gyan Mishra
Verizon Communications 
Cell- 301 502-1347

Sent from my iPhone

> On Sep 6, 2019, at 10:17 AM, Robert Raszuk  wrote:
> 
> I don't think so. 
> 
> In OAM packets are on purpose made huge - even up to MTU to make sure real 
> customer packets can go through or to detect and diagnose MTU issues. So 
> adding SRH to it is nothing one can call inefficient. 
> 
> Wrong tree :) 
> 
> Cheers,
> R.
> 
>> On Fri, Sep 6, 2019 at 4:14 PM Srihari Sangli  wrote:
>>  
>> 
>> On 06/09/19, 4:32 PM Robert Raszuk from rob...@raszuk.net said >
>> 
>>  
>> 
>> Not really. Only SR OAM packets may need it. Is that a real problem ?
>> 
>>  
>> 
>> Thanks for clarification. Like Ron pointed out before, its inefficient 
>> encoding.
>> 
>>  
>> 
>> srihari…
>> 
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Robert Raszuk]

I don't think so.

In OAM packets are on purpose made huge - even up to MTU to make sure real
customer packets can go through or to detect and diagnose MTU issues. So
adding SRH to it is nothing one can call inefficient.

Wrong tree :)

Cheers,
R.

On Fri, Sep 6, 2019 at 4:14 PM Srihari Sangli  wrote:

>
>
> On 06/09/19, 4:32 PM Robert Raszuk from rob...@raszuk.net said >
>
>
>
> Not really. Only SR OAM packets may need it. Is that a real problem ?
>
>
>
> Thanks for clarification. Like Ron pointed out before, its inefficient
> encoding.
>
>
>
> srihari…
>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Ca By]

On Fri, Sep 6, 2019 at 1:40 AM Andrew Alston <
andrew.als...@liquidtelecom.com> wrote:

> An Zafar – I told by those words – I am pragmatic though as an operator.
> I know that srv6 in some form or another is coming – I stated as much on
> various blogs. I am not fool enough to believe that I am not going to be
> forced into a situation where I am going to be made to run some variant of
> this – because I  have been told very bluntly by certain vendors that mpls
> style development for v6 will cease at a control plane level – and we are
> already seeing situations where despite sr-mpls working just fine – certain
> vendors have actively chosen to not support this with IPv6.
>
>
Eh, i am also an operator of a non-trivial size network.  The above
statements make me concerned about your business.

1.   I consider SR to be a bit of flashy marketing push by vendors to do
things with no unique merit. One looks at a 1/2 page author list of these
SR draft and must note something here is fishy. Folks from my company who
have no idea what SRv6 is have been asked to add their names to the author
list of SPRING drafts.  It is a mirage, and poor form by the SR pushers to
engage in this fake grass roots movement.

2. IMO, SR is like lisp and nsh. Overly complicated protocols driven by
vendors, with plenty of astro turf, to make networks more complicated and
expensive.  Oh, and it is so simple ans great, but only runs on the newest
kit ...

3.  You are very confused. You give vendors requirements and they comply.
You pay them, they do stuff. They will even put your name on an I-D you
have not read.

4. SR is not coming to anyone who does not have the religion of SR. SR is
no more of a solid bet than LISP or OpenFlow or NSH or “SDN” or PCF 

My bet is MPLS will not die, it is 20 years mature and not going anywhere.
Let’s see a vendor launch a serious carrier router without MPLS


>
> That has put me in a position where I have to be pragmatic – because – as
> an operator with a massive network – I have to be able to continue to well,
> operate.  That leaves me needing something that finds a common ground
> between those who want MPLS to die – and the MPLS usage which is present,
> real and necessary in the world in which I operate.  That leaves me with
> needing a version of SRv6 which is usable, does not impose insane overhead,
> and does not fundamentally rewrite the IPv6 protocol.
>
>
>
> I have been extremely open and honest about this – I will however say –
> that the added functionality through the network programmability – all of
> which is catered for in CRH without the need to rewrite the IPv6
> specification to do it – does have other use cases – and hence – CRH
> actually works for us – very very well – because it retains that which I
> need – while adding some really nice advantages on top of it.  But again –
> we have asked – multiple times – for the technical problems behind CRH –
> and the ringing in my ears is deafening from the silence.
>
>
>
> Andrew
>
>
>
>
>
> *From:* Zafar Ali (zali) 
> *Sent:* Friday, 6 September 2019 11:28
> *To:* Robert Raszuk ; Andrew Alston <
> andrew.als...@liquidtelecom.com>
> *Cc:* Ron Bonica ; Srihari Sangli <
> ssan...@juniper.net>; Tarek Saad ; Rob Shakir <
> ro...@google.com>; SPRING WG List ; 6...@ietf.org; Zafar
> Ali (zali) 
> *Subject:* Re: [spring] Beyond SRv6.
>
>
>
> Hi Andrew,
>
>
>
> I agree with Robert.
>
> CRH is nothing else than IPv6 over SR-MPLS.
>
> In the vast majority of the deployments (single SP domain), one can deploy
> MPLS.
>
> In a minority of cases where some MPLS discontinuity in the domain could
> exist, SR-MPLS over IP/UDP is an adopted and deployed solution.
>
>
>
> As you stated in your original response”
>
> “Now – in that case SR-MPLS would have been just fine and frankly
> speaking – we were entirely happy with pure SR-MPLS and I’m on record
> saying that I didn’t see much of a use case for SRv6 at all.”
>
>
>
> I can see why you liked CRH.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> *From: *Robert Raszuk 
> *Date: *Friday, September 6, 2019 at 4:01 AM
> *To: *Andrew Alston 
> *Cc: *"Zafar Ali (zali)" , Ron Bonica ,
> Srihari Sangli , Tarek Saad ,
> Rob Shakir , SPRING WG List , "
> 6...@ietf.org" <6...@ietf.org>
> *Subject: *Re: [spring] Beyond SRv6.
>
>
>
> Hi Andrew,
>
>
>
> I can say that I may even agree with some of your points. But one question
> I asked which no one responded still stands ...
>
>
>
> SRv6+ is almost identical to SR-MPLS with IP transport between segment
> nodes. Both require mapping, both require changes to OAM, both require IGP
> ext

Re: [spring] Beyond SRv6.

[Srihari Sangli]

On 06/09/19, 4:32 PM Robert Raszuk from 
rob...@raszuk.net said >

Not really. Only SR OAM packets may need it. Is that a real problem ?

Thanks for clarification. Like Ron pointed out before, its inefficient encoding.

srihari…
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Tarek Saad]

Hi Zafar,

>> In the vast majority of the deployments (single SP domain), one can deploy 
>> MPLS.
>> In a minority of cases where some MPLS discontinuity in the domain could 
>> exist, SR-MPLS over IP/UDP is an adopted and deployed solution.
For an operator who has used MPLS, don’t you think SRv6+ will appeal more to 
them in this case? Given all the arguments that are being made that it does 
resemble MPLS in its mapping prefixes to short labels?

Regards,
Tarek


From: "Zafar Ali (zali)" 
Date: Friday, September 6, 2019 at 4:28 AM
To: Robert Raszuk , Andrew Alston 

Cc: Ron Bonica , Srihari Sangli , 
Tarek Saad , Rob Shakir , SPRING WG List 
, "6...@ietf.org" <6...@ietf.org>, "Zafar Ali (zali)" 

Subject: Re: [spring] Beyond SRv6.

Hi Andrew,

I agree with Robert.
CRH is nothing else than IPv6 over SR-MPLS.
In the vast majority of the deployments (single SP domain), one can deploy MPLS.
In a minority of cases where some MPLS discontinuity in the domain could exist, 
SR-MPLS over IP/UDP is an adopted and deployed solution.

As you stated in your original response”
“Now – in that case SR-MPLS would have been just fine and frankly speaking – we 
were entirely happy with pure SR-MPLS and I’m on record saying that I didn’t 
see much of a use case for SRv6 at all.”

I can see why you liked CRH.

Thanks

Regards … Zafar

From: Robert Raszuk 
Date: Friday, September 6, 2019 at 4:01 AM
To: Andrew Alston 
Cc: "Zafar Ali (zali)" , Ron Bonica , 
Srihari Sangli , Tarek Saad , Rob 
Shakir , SPRING WG List , "6...@ietf.org" 
<6...@ietf.org>
Subject: Re: [spring] Beyond SRv6.

Hi Andrew,

I can say that I may even agree with some of your points. But one question I 
asked which no one responded still stands ...

SRv6+ is almost identical to SR-MPLS with IP transport between segment nodes. 
Both require mapping, both require changes to OAM, both require IGP extensions, 
both can use the same forwarding hardware and logic, both require almost 
identical operation etc  As you know even main author of SRv6+ agrees with 
all of this in the notes sent to the list.

So please help me to understand why entire industry who wants to be good IETF 
citizen and Industry player should now invest a lot of resources in 
development, testing, shipping and support of a solution which is just a poor 
mirror of something which is already available ?

Yes some folks were allergic to MPLS in the past and some are still allergic to 
MPLS. But as someone who have worked since Tag Switching early days on that 
piece of technology let me tell you that vast majority of those folks do not 
even understand the difference between MPLS used for transport and MPLS used as 
forwarding demux for the applications. They just treat it the very same way 
like an evil or devil protocol which does nothing else other then demonstrate 
their complete ignorance of the subject.

Yes MPLS to be used as a transport is a mistake. It was not a mistake in the 
past as when we rolled out services which required encapsulation most platforms 
in the field just could not do line rate IP encapsulation. But those days are 
gone. If in 1998 time frame routers could do IPv4 in IPv4 encap MPLS as a 
transport would have never succeeded.

Then of course there was more mistakes TDP later by IETF collaboration became 
LDP was a mapping protocol - yes another mistake instead of making up front 
domain wide labels and extended IGPs and BGP for that. Well the thought was 
that working on single protocol will be easier then extending ISIS, OSPFv2 (and 
v3 on the radar), RIPv2, EIGRP.

But this is MPLS transport which in spite of little group of folks still 
selling it around believe it or not it is going away.

But nothing is wrong about using 20 bit labels as demux for applications and 
services. Packet carry bits. Nowhere in the packet even if you decode it 
carefully it says "I am MPLS" ... forwarding on the boxes also uses bit lookup 
and if you ask your vendor they can paint it and abstract all the MPLS legacy 
in the CLI for you so you never see it.

Bottom line is that I see no reason at all to adopt a solution which walks like 
a duck, quacks like a duck and only carries a label "I am not a duck"

Best,
R.


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Robert Raszuk]

>
> Vanilla TRACEROUTE reveals all of the mapping information. RFC 5837 offers
> some nice extras, but isn't strictly required.
>

Really ?

If your traffic policy steers some TCP traffic for ports 4000-5000 to take
segment A-B-C-D and for ports 6000-7000 to take segment A-E-F-G-D how your
vanilla traceroute is going to discover it when running the traceroute from
outside of the network ?

Thx,
R.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Ron Bonica]

Steinar,

Vanilla TRACEROUTE reveals all of the mapping information. RFC 5837 offers some 
nice extras, but isn't strictly required.


Ron



Juniper Business Use Only

-Original Message-
From: sth...@nethelp.no  
Sent: Friday, September 6, 2019 2:42 AM
To: Ron Bonica 
Cc: spring@ietf.org; 6...@ietf.org
Subject: Re: [spring] Beyond SRv6.

> Nothing so complicated is required. At most, PING and TRACEROUTE with RFC 
> 5837 extensions.

Are there any vendors actually implementing RFC 5837? Ivan Pepelnjak commented 
"However, it looks like nobody implemented it in almost five years since it was 
published." at

   
https://urldefense.com/v3/__https://blog.ipspace.net/2016/01/are-unnumbered-interfaces-harmful.html__;!8WoA6RjC81c!RpF3DZprPGFaTqO0XZL8SzokiqeBSyo_ldL6rRhpOyJxiSJ0rtHM15msZ5hD9Fga$
 

Has the situation changed?

Steinar Haug, AS2116

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Robert Raszuk]

Not really. Only SR OAM packets may need it. Is that a real problem ?

Best
R

On Fri, Sep 6, 2019, 11:41 Srihari Sangli  wrote:

> Zafar,
>
>
>
> · The original segment list is maintained by using the
> non-Reduced flavor (in which case the SID list is fully preserved in the
> SRH).
>
>
>
> [RB] At the cost of encoding efficiency. 50% decrease !!
>
>
>
> If I understand it right, the IPv6 packet carrying uSIDs will also have
> full set SID carried in the SRH. The full SID list in SRH is to provide
> additional information ? Pls let me know if I got it right. Thanks.
>
>
>
> srhari…
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Srihari Sangli]

Zafar,



· The original segment list is maintained by using the non-Reduced 
flavor (in which case the SID list is fully preserved in the SRH).

[RB] At the cost of encoding efficiency. 50% decrease !!



If I understand it right, the IPv6 packet carrying uSIDs will also have full 
set SID carried in the SRH. The full SID list in SRH is to provide additional 
information ? Pls let me know if I got it right. Thanks.



srhari…
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Robert Raszuk]

> between those who want MPLS to die

Again you are putting an equal sign between MPLS used for transport and
MPLS used for application and services. While I know and agree that MPLS
for transport should die - I have not met anyone who says MPLS for
applications is a bad demux encoding.

> for the technical problems behind CRH

I pointed the need for mapping as architectural deficiency.

But this is not the point.

If next week there will be three more proposals of data plane encoding
(XRH, ZRH & YRH) and each asking for new IGP & BGP control plane extensions
for Segment Routing over v6 should IETF adopt all of them and should all
vendors work and deliver all of them ? Is this what you think is in best
interest of the industry ?

Many thx,
R,

On Fri, Sep 6, 2019 at 10:40 AM Andrew Alston <
andrew.als...@liquidtelecom.com> wrote:

> An Zafar – I told by those words – I am pragmatic though as an operator.
> I know that srv6 in some form or another is coming – I stated as much on
> various blogs. I am not fool enough to believe that I am not going to be
> forced into a situation where I am going to be made to run some variant of
> this – because I  have been told very bluntly by certain vendors that mpls
> style development for v6 will cease at a control plane level – and we are
> already seeing situations where despite sr-mpls working just fine – certain
> vendors have actively chosen to not support this with IPv6.
>
>
>
> That has put me in a position where I have to be pragmatic – because – as
> an operator with a massive network – I have to be able to continue to well,
> operate.  That leaves me needing something that finds a common ground
> between those who want MPLS to die – and the MPLS usage which is present,
> real and necessary in the world in which I operate.  That leaves me with
> needing a version of SRv6 which is usable, does not impose insane overhead,
> and does not fundamentally rewrite the IPv6 protocol.
>
>
>
> I have been extremely open and honest about this – I will however say –
> that the added functionality through the network programmability – all of
> which is catered for in CRH without the need to rewrite the IPv6
> specification to do it – does have other use cases – and hence – CRH
> actually works for us – very very well – because it retains that which I
> need – while adding some really nice advantages on top of it.  But again –
> we have asked – multiple times – for the technical problems behind CRH –
> and the ringing in my ears is deafening from the silence.
>
>
>
> Andrew
>
>
>
>
>
> *From:* Zafar Ali (zali) 
> *Sent:* Friday, 6 September 2019 11:28
> *To:* Robert Raszuk ; Andrew Alston <
> andrew.als...@liquidtelecom.com>
> *Cc:* Ron Bonica ; Srihari Sangli <
> ssan...@juniper.net>; Tarek Saad ; Rob Shakir <
> ro...@google.com>; SPRING WG List ; 6...@ietf.org; Zafar
> Ali (zali) 
> *Subject:* Re: [spring] Beyond SRv6.
>
>
>
> Hi Andrew,
>
>
>
> I agree with Robert.
>
> CRH is nothing else than IPv6 over SR-MPLS.
>
> In the vast majority of the deployments (single SP domain), one can deploy
> MPLS.
>
> In a minority of cases where some MPLS discontinuity in the domain could
> exist, SR-MPLS over IP/UDP is an adopted and deployed solution.
>
>
>
> As you stated in your original response”
>
> “Now – in that case SR-MPLS would have been just fine and frankly
> speaking – we were entirely happy with pure SR-MPLS and I’m on record
> saying that I didn’t see much of a use case for SRv6 at all.”
>
>
>
> I can see why you liked CRH.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> *From: *Robert Raszuk 
> *Date: *Friday, September 6, 2019 at 4:01 AM
> *To: *Andrew Alston 
> *Cc: *"Zafar Ali (zali)" , Ron Bonica ,
> Srihari Sangli , Tarek Saad ,
> Rob Shakir , SPRING WG List , "
> 6...@ietf.org" <6...@ietf.org>
> *Subject: *Re: [spring] Beyond SRv6.
>
>
>
> Hi Andrew,
>
>
>
> I can say that I may even agree with some of your points. But one question
> I asked which no one responded still stands ...
>
>
>
> SRv6+ is almost identical to SR-MPLS with IP transport between segment
> nodes. Both require mapping, both require changes to OAM, both require IGP
> extensions, both can use the same forwarding hardware and logic, both
> require almost identical operation etc  As you know even main author of
> SRv6+ agrees with all of this in the notes sent to the list.
>
>
>
> So please help me to understand why entire industry who wants to be good
> IETF citizen and Industry player should now invest a lot of resources in
> development, testing, shipping and support of a solution wh

Re: [spring] Beyond SRv6.

[Andrew Alston]

An Zafar – I told by those words – I am pragmatic though as an operator.  I 
know that srv6 in some form or another is coming – I stated as much on various 
blogs. I am not fool enough to believe that I am not going to be forced into a 
situation where I am going to be made to run some variant of this – because I  
have been told very bluntly by certain vendors that mpls style development for 
v6 will cease at a control plane level – and we are already seeing situations 
where despite sr-mpls working just fine – certain vendors have actively chosen 
to not support this with IPv6.

That has put me in a position where I have to be pragmatic – because – as an 
operator with a massive network – I have to be able to continue to well, 
operate.  That leaves me needing something that finds a common ground between 
those who want MPLS to die – and the MPLS usage which is present, real and 
necessary in the world in which I operate.  That leaves me with needing a 
version of SRv6 which is usable, does not impose insane overhead, and does not 
fundamentally rewrite the IPv6 protocol.

I have been extremely open and honest about this – I will however say – that 
the added functionality through the network programmability – all of which is 
catered for in CRH without the need to rewrite the IPv6 specification to do it 
– does have other use cases – and hence – CRH actually works for us – very very 
well – because it retains that which I need – while adding some really nice 
advantages on top of it.  But again – we have asked – multiple times – for the 
technical problems behind CRH – and the ringing in my ears is deafening from 
the silence.

Andrew


From: Zafar Ali (zali) 
Sent: Friday, 6 September 2019 11:28
To: Robert Raszuk ; Andrew Alston 

Cc: Ron Bonica ; Srihari Sangli ; 
Tarek Saad ; Rob Shakir ; SPRING WG List 
; 6...@ietf.org; Zafar Ali (zali) 
Subject: Re: [spring] Beyond SRv6.

Hi Andrew,

I agree with Robert.
CRH is nothing else than IPv6 over SR-MPLS.
In the vast majority of the deployments (single SP domain), one can deploy MPLS.
In a minority of cases where some MPLS discontinuity in the domain could exist, 
SR-MPLS over IP/UDP is an adopted and deployed solution.

As you stated in your original response”
“Now – in that case SR-MPLS would have been just fine and frankly speaking – we 
were entirely happy with pure SR-MPLS and I’m on record saying that I didn’t 
see much of a use case for SRv6 at all.”

I can see why you liked CRH.

Thanks

Regards … Zafar

From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Friday, September 6, 2019 at 4:01 AM
To: Andrew Alston 
mailto:andrew.als...@liquidtelecom.com>>
Cc: "Zafar Ali (zali)" mailto:z...@cisco.com>>, Ron Bonica 
mailto:rbon...@juniper.net>>, Srihari Sangli 
mailto:ssan...@juniper.net>>, Tarek Saad 
mailto:tsaad@gmail.com>>, Rob Shakir 
mailto:ro...@google.com>>, SPRING WG List 
mailto:spring@ietf.org>>, 
"6...@ietf.org<mailto:6...@ietf.org>" <6...@ietf.org<mailto:6...@ietf.org>>
Subject: Re: [spring] Beyond SRv6.

Hi Andrew,

I can say that I may even agree with some of your points. But one question I 
asked which no one responded still stands ...

SRv6+ is almost identical to SR-MPLS with IP transport between segment nodes. 
Both require mapping, both require changes to OAM, both require IGP extensions, 
both can use the same forwarding hardware and logic, both require almost 
identical operation etc  As you know even main author of SRv6+ agrees with 
all of this in the notes sent to the list.

So please help me to understand why entire industry who wants to be good IETF 
citizen and Industry player should now invest a lot of resources in 
development, testing, shipping and support of a solution which is just a poor 
mirror of something which is already available ?

Yes some folks were allergic to MPLS in the past and some are still allergic to 
MPLS. But as someone who have worked since Tag Switching early days on that 
piece of technology let me tell you that vast majority of those folks do not 
even understand the difference between MPLS used for transport and MPLS used as 
forwarding demux for the applications. They just treat it the very same way 
like an evil or devil protocol which does nothing else other then demonstrate 
their complete ignorance of the subject.

Yes MPLS to be used as a transport is a mistake. It was not a mistake in the 
past as when we rolled out services which required encapsulation most platforms 
in the field just could not do line rate IP encapsulation. But those days are 
gone. If in 1998 time frame routers could do IPv4 in IPv4 encap MPLS as a 
transport would have never succeeded.

Then of course there was more mistakes TDP later by IETF collaboration became 
LDP was a mapping protocol - yes another mistake instead of making up front 
domain wide labels and extended IGPs and BGP for that. Well the thought was 
that worki

Re: [spring] Beyond SRv6.

[Zafar Ali (zali)]

Hi Andrew,

I agree with Robert.
CRH is nothing else than IPv6 over SR-MPLS.
In the vast majority of the deployments (single SP domain), one can deploy MPLS.
In a minority of cases where some MPLS discontinuity in the domain could exist, 
SR-MPLS over IP/UDP is an adopted and deployed solution.

As you stated in your original response”
“Now – in that case SR-MPLS would have been just fine and frankly speaking – we 
were entirely happy with pure SR-MPLS and I’m on record saying that I didn’t 
see much of a use case for SRv6 at all.”

I can see why you liked CRH.

Thanks

Regards … Zafar

From: Robert Raszuk 
Date: Friday, September 6, 2019 at 4:01 AM
To: Andrew Alston 
Cc: "Zafar Ali (zali)" , Ron Bonica , 
Srihari Sangli , Tarek Saad , Rob 
Shakir , SPRING WG List , "6...@ietf.org" 
<6...@ietf.org>
Subject: Re: [spring] Beyond SRv6.

Hi Andrew,

I can say that I may even agree with some of your points. But one question I 
asked which no one responded still stands ...

SRv6+ is almost identical to SR-MPLS with IP transport between segment nodes. 
Both require mapping, both require changes to OAM, both require IGP extensions, 
both can use the same forwarding hardware and logic, both require almost 
identical operation etc  As you know even main author of SRv6+ agrees with 
all of this in the notes sent to the list.

So please help me to understand why entire industry who wants to be good IETF 
citizen and Industry player should now invest a lot of resources in 
development, testing, shipping and support of a solution which is just a poor 
mirror of something which is already available ?

Yes some folks were allergic to MPLS in the past and some are still allergic to 
MPLS. But as someone who have worked since Tag Switching early days on that 
piece of technology let me tell you that vast majority of those folks do not 
even understand the difference between MPLS used for transport and MPLS used as 
forwarding demux for the applications. They just treat it the very same way 
like an evil or devil protocol which does nothing else other then demonstrate 
their complete ignorance of the subject.

Yes MPLS to be used as a transport is a mistake. It was not a mistake in the 
past as when we rolled out services which required encapsulation most platforms 
in the field just could not do line rate IP encapsulation. But those days are 
gone. If in 1998 time frame routers could do IPv4 in IPv4 encap MPLS as a 
transport would have never succeeded.

Then of course there was more mistakes TDP later by IETF collaboration became 
LDP was a mapping protocol - yes another mistake instead of making up front 
domain wide labels and extended IGPs and BGP for that. Well the thought was 
that working on single protocol will be easier then extending ISIS, OSPFv2 (and 
v3 on the radar), RIPv2, EIGRP.

But this is MPLS transport which in spite of little group of folks still 
selling it around believe it or not it is going away.

But nothing is wrong about using 20 bit labels as demux for applications and 
services. Packet carry bits. Nowhere in the packet even if you decode it 
carefully it says "I am MPLS" ... forwarding on the boxes also uses bit lookup 
and if you ask your vendor they can paint it and abstract all the MPLS legacy 
in the CLI for you so you never see it.

Bottom line is that I see no reason at all to adopt a solution which walks like 
a duck, quacks like a duck and only carries a label "I am not a duck"

Best,
R.


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Robert Raszuk]

Hi Andrew,

I can say that I may even agree with some of your points. But one question
I asked which no one responded still stands ...

SRv6+ is almost identical to SR-MPLS with IP transport between segment
nodes. Both require mapping, both require changes to OAM, both require IGP
extensions, both can use the same forwarding hardware and logic, both
require almost identical operation etc  As you know even main author of
SRv6+ agrees with all of this in the notes sent to the list.

So please help me to understand why entire industry who wants to be good
IETF citizen and Industry player should now invest a lot of resources in
development, testing, shipping and support of a solution which is just a
poor mirror of something which is already available ?

Yes some folks were allergic to MPLS in the past and some are still
allergic to MPLS. But as someone who have worked since Tag Switching early
days on that piece of technology let me tell you that vast majority of
those folks do not even understand the difference between MPLS used for
transport and MPLS used as forwarding demux for the applications. They just
treat it the very same way like an evil or devil protocol which does
nothing else other then demonstrate their complete ignorance of the
subject.

Yes MPLS to be used as a transport is a mistake. It was not a mistake in
the past as when we rolled out services which required encapsulation most
platforms in the field just could not do line rate IP encapsulation. But
those days are gone. If in 1998 time frame routers could do IPv4 in IPv4
encap MPLS as a transport would have never succeeded.

Then of course there was more mistakes TDP later by IETF collaboration
became LDP was a mapping protocol - yes another mistake instead of making
up front domain wide labels and extended IGPs and BGP for that. Well the
thought was that working on single protocol will be easier then extending
ISIS, OSPFv2 (and v3 on the radar), RIPv2, EIGRP.

But this is MPLS transport which in spite of little group of folks still
selling it around believe it or not it is going away.

But nothing is wrong about using 20 bit labels as demux for applications
and services. Packet carry bits. Nowhere in the packet even if you decode
it carefully it says "I am MPLS" ... forwarding on the boxes also uses bit
lookup and if you ask your vendor they can paint it and abstract all the
MPLS legacy in the CLI for you so you never see it.

Bottom line is that I see no reason at all to adopt a solution which walks
like a duck, quacks like a duck and only carries a label "I am not a duck"

Best,
R.


On Fri, Sep 6, 2019 at 9:04 AM Andrew Alston <
andrew.als...@liquidtelecom.com> wrote:

> Zafar,
>
> One of the things I keep seeing below is you referring to the operators
> perspective.  So - as someone who actually is from an operator - and has
> done substantial testing of the proposed solution let me give you the
> perspective of an operator.
>
> Firstly - as an operator - on the table mapping - I've seen absolutely no
> problem with this - particularly if I add bgp crh signaling which lets me
> build a mapping table that can be understood in multiple systems which do
> not necessarily need to know about the rest of the network (this is
> particularly useful on inline DPI systems and other such things)
> Secondly - as an operator - the segregation between what is an address and
> how said address is directed - rather than a constant change in the address
> to us seems far safer.  In the uSID draft, a leak of a more specific prefix
> in the network because of finger trouble - can fundamentally break routing
> - and well, that could be rather interesting to start debugging.
> Thirdly - as an operator - without retaining the uncompressed list of
> SID's in the header, I have a debugging nightmare - and zero ability to
> figure out packet pathing through the network at intermediary points - and
> you keep saying that this is addressed by retaining the full SID list - but
> - if I do that - can you explain to me what the point of the micro sid is -
> since - I was under the impression that the point was to remove the
> overhead - the moment I take this approach - how am I not back at square
> one with the same overhead?
> Forth - as an operator - I am deeply uncomfortable with the fact that the
> proposal fundamentally redefines the semantics of the address with
> potential unintended consequences - and despite the fact that multiple
> times I have raised the redefinition of the semantics of the address when
> compared against RFC4291 - I have yet to see this addressed
> Fifth - as an operator - I have concerns about the inflation of the IGP,
> and this was raised in Montreal.  I was told that this could be addressed
> by renumbering my network - sorry - I hardly view this as viable
> Sixth - as an operator that has to apply for space from the RIR's - and
> has concerns about address space utilization - a request was made in
> Montreal for an evaluation 

Re: [spring] Beyond SRv6.

[Zafar Ali (zali)]

Hi Steinar,

I am glad you asked.

I am not aware of any implementation of RFC 5837.

Even if it is implemented, it never talks about providing information from a 
distributed “local label mapping table”, as defined by the CRH.

Thanks

Regards … Zafar

From: ipv6  on behalf of "sth...@nethelp.no" 

Date: Friday, September 6, 2019 at 2:42 AM
To: "rbonica=40juniper@dmarc.ietf.org" 

Cc: "spring@ietf.org" , "6...@ietf.org" <6...@ietf.org>
Subject: Re: [spring] Beyond SRv6.

Nothing so complicated is required. At most, PING and TRACEROUTE with RFC 5837 
extensions.

Are there any vendors actually implementing RFC 5837? Ivan Pepelnjak
commented "However, it looks like nobody implemented it in almost five
years since it was published." at

   https://blog.ipspace.net/2016/01/are-unnumbered-interfaces-harmful.html

Has the situation changed?

Steinar Haug, AS2116


IETF IPv6 working group mailing list
i...@ietf.org<mailto:i...@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[sthaug]

> Nothing so complicated is required. At most, PING and TRACEROUTE with RFC 
> 5837 extensions.

Are there any vendors actually implementing RFC 5837? Ivan Pepelnjak
commented "However, it looks like nobody implemented it in almost five
years since it was published." at

   https://blog.ipspace.net/2016/01/are-unnumbered-interfaces-harmful.html

Has the situation changed?

Steinar Haug, AS2116

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Zafar Ali (zali)]

Hi Ron,

MPLS tool kit was created as IP tool kit (ICMP) was not sufficient to debug an 
MPLS subsystem.

By bringing in the “label mapping table” in IPv6 network, you have inherited 
the same problem industry has solved for MPLS OAM during the last ~20 years.

Thanks

Regards … Zafar

From: Ron Bonica 
Date: Friday, September 6, 2019 at 2:23 AM
To: "Zafar Ali (zali)" , Srihari Sangli , 
Tarek Saad , Rob Shakir , SPRING WG List 
, "6...@ietf.org" <6...@ietf.org>
Subject: RE: [spring] Beyond SRv6.

Ali,

Nothing so complicated is required. At most, PING and TRACEROUTE with RFC 5837 
extensions.

 Ron




Juniper Business Use Only
From: Zafar Ali (zali) 
Sent: Friday, September 6, 2019 2:18 AM
To: Ron Bonica ; Srihari Sangli ; 
Tarek Saad ; Rob Shakir ; SPRING WG List 
; 6...@ietf.org
Cc: Zafar Ali (zali) 
Subject: Re: [spring] Beyond SRv6.

Hi Ron,

Please see in-line.

Thanks

Regards … Zafar

From: Ron Bonica mailto:rbon...@juniper.net>>
Date: Friday, September 6, 2019 at 1:57 AM
To: "Zafar Ali (zali)" mailto:z...@cisco.com>>, Srihari Sangli 
mailto:ssan...@juniper.net>>, Tarek Saad 
mailto:tsaad@gmail.com>>, Rob Shakir 
mailto:ro...@google.com>>, SPRING WG List 
mailto:spring@ietf.org>>, 
"6...@ietf.org<mailto:6...@ietf.org>" <6...@ietf.org<mailto:6...@ietf.org>>
Subject: RE: [spring] Beyond SRv6.

Inline…..



Juniper Business Use Only
From: Zafar Ali (zali) mailto:z...@cisco.com>>
Sent: Friday, September 6, 2019 1:42 AM
To: Srihari Sangli mailto:ssan...@juniper.net>>; Tarek 
Saad mailto:tsaad@gmail.com>>; Ron Bonica 
mailto:rbon...@juniper.net>>; Rob Shakir 
mailto:ro...@google.com>>; SPRING WG List 
mailto:spring@ietf.org>>; 6...@ietf.org<mailto:6...@ietf.org>
Cc: Zafar Ali (zali) mailto:z...@cisco.com>>
Subject: Re: [spring] Beyond SRv6.



Hi Srihari,

> DA manipulation along the hop (shifting as the draft proposes) on each router 
> and reconstructing the DA - can make it harder to debug when
  > there is problem.



It has been clarified during the Spring WG session in Montreal. Repeating the 
same –



  *   The original segment list is maintained by using the non-Reduced flavor 
(in which case the SID list is fully preserved in the SRH).

[RB] At the cost of encoding efficiency. 50% decrease !!


In reality, debugability is a huge issue in CRH proposal.

[RB] In reality, the debuggability characteristics of SRv6+ are very similar to 
those of SR-MPLS. We have the same mapping from a short identifier (SRv6+ SID 
or SR-MPLS Label) to an IPv6 address.

[RB] So, would you like to argue that debuggability is a huge issue in SR-MPLS?

[ZA] Not at all. SR-MPLS uses MPLS OAM tool kit defined in 
https://tools.ietf.org/html/rfc8029<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8029__;!8WoA6RjC81c!TkBkBFPiX8_HzpxayXHu3zPmLXGXoQv2JitOPuzsxDMSS0wZKsKN68a_insHhyXn$>.
[ZA] Are you suggesting you will introduce something similar to RFC8029?

  Ron


For example,
the CRH requires an IPv6 address to the “labels” mapping table (Yuck!).
An operator cannot determine the path packet will take by looking at CRH.
Have you realized how painful it will be for the operator to:

  *   Walk the CRH,
  *   Map each per-node "local labels" to its associated IPv6 address,
  *   Repeat the process for the entire label chain encoded in CRH.
Not to mention, this requires the operators to get the "mapping table" from 
each node in the network.



Thanks



Regards … Zafar




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Andrew Alston]

> This is absolutely false! 
 
> Have you forgotten the very strong arguments against it at the Spring session 
> in Montreal and the various emails on the list that echoed them 
> Not to mention comments from Robert R 
> (https://mailarchive.ietf.org/arch/msg/spring/6bdX_gb47uFYnd6ytwFLPYxXCYo). 

Arguments against a proposal in the IETF are meant to be judged on technical 
merit. Yes - I heard arguments in Montreal about previous work done on 
alternatives and about srv6+ supposedly being late to the party - but the 
technical arguments - those I didn’t hear, maybe I missed them, so, if I did, I 
apologize, and perhaps you can assist us it in telling us what they were.  

As I have said to others - if there are technical problems with the stuff we 
are working on here - put those issues on the table - and where possible 
speaking for myself here - every effort will be made to accommodate - but - you 
are late to the party - is not a valid argument.


> Yes, indeed Ron presented the proposal to every workgroup possible in 
> Montreal, only to find no interest from anyone. 
> I would advise you to read that silence differently.   

I would advise taking a close read on RFC7282 - specifically section 2.

And as a final thought:

One of the things that was being said - was that network programming took years 
to develop etc - well - in this industry years - is a lifetime - and sometimes 
if something takes years - an alternative will arise during that development 
cycle - that either addresses needs in a different manner that is more 
efficient, or addresses additional needs beyond those addresses by the original 
still in progress ideas.  That I would argue is the sign of a healthy 
developing industry that is getting contributions from people who have 
perspectives beyond that of the proposer of the original idea.  That - is 
called progress

Andrew

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Ron Bonica]

Ali,

Nothing so complicated is required. At most, PING and TRACEROUTE with RFC 5837 
extensions.

 Ron




Juniper Business Use Only
From: Zafar Ali (zali) 
Sent: Friday, September 6, 2019 2:18 AM
To: Ron Bonica ; Srihari Sangli ; 
Tarek Saad ; Rob Shakir ; SPRING WG List 
; 6...@ietf.org
Cc: Zafar Ali (zali) 
Subject: Re: [spring] Beyond SRv6.

Hi Ron,

Please see in-line.

Thanks

Regards ... Zafar

From: Ron Bonica mailto:rbon...@juniper.net>>
Date: Friday, September 6, 2019 at 1:57 AM
To: "Zafar Ali (zali)" mailto:z...@cisco.com>>, Srihari Sangli 
mailto:ssan...@juniper.net>>, Tarek Saad 
mailto:tsaad@gmail.com>>, Rob Shakir 
mailto:ro...@google.com>>, SPRING WG List 
mailto:spring@ietf.org>>, 
"6...@ietf.org<mailto:6...@ietf.org>" <6...@ietf.org<mailto:6...@ietf..org>>
Subject: RE: [spring] Beyond SRv6.

Inline.



Juniper Business Use Only
From: Zafar Ali (zali) mailto:z...@cisco.com>>
Sent: Friday, September 6, 2019 1:42 AM
To: Srihari Sangli mailto:ssan...@juniper.net>>; Tarek 
Saad mailto:tsaad@gmail.com>>; Ron Bonica 
mailto:rbon...@juniper.net>>; Rob Shakir 
mailto:ro...@google.com>>; SPRING WG List 
mailto:spr...@ietf..org>>; 6...@ietf.org<mailto:6...@ietf.org>
Cc: Zafar Ali (zali) mailto:z...@cisco.com>>
Subject: Re: [spring] Beyond SRv6.



Hi Srihari,

> DA manipulation along the hop (shifting as the draft proposes) on each router 
> and reconstructing the DA - can make it harder to debug when
  > there is problem.



It has been clarified during the Spring WG session in Montreal. Repeating the 
same -



  *   The original segment list is maintained by using the non-Reduced flavor 
(in which case the SID list is fully preserved in the SRH).

[RB] At the cost of encoding efficiency. 50% decrease !!


In reality, debugability is a huge issue in CRH proposal.

[RB] In reality, the debuggability characteristics of SRv6+ are very similar to 
those of SR-MPLS. We have the same mapping from a short identifier (SRv6+ SID 
or SR-MPLS Label) to an IPv6 address.

[RB] So, would you like to argue that debuggability is a huge issue in SR-MPLS?

[ZA] Not at all. SR-MPLS uses MPLS OAM tool kit defined in 
https://tools.ietf.org/html/rfc8029<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8029__;!8WoA6RjC81c!TkBkBFPiX8_HzpxayXHu3zPmLXGXoQv2JitOPuzsxDMSS0wZKsKN68a_insHhyXn$>.
[ZA] Are you suggesting you will introduce something similar to RFC8029?

  Ron


For example,
the CRH requires an IPv6 address to the "labels" mapping table (Yuck!).
An operator cannot determine the path packet will take by looking at CRH.
Have you realized how painful it will be for the operator to:

  *   Walk the CRH,
  *   Map each per-node "local labels" to its associated IPv6 address,
  *   Repeat the process for the entire label chain encoded in CRH.
Not to mention, this requires the operators to get the "mapping table" from 
each node in the network.



Thanks



Regards ... Zafar




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Zafar Ali (zali)]

Hi Ron,

Please see in-line.

Thanks

Regards … Zafar

From: Ron Bonica 
Date: Friday, September 6, 2019 at 1:57 AM
To: "Zafar Ali (zali)" , Srihari Sangli , 
Tarek Saad , Rob Shakir , SPRING WG List 
, "6...@ietf.org" <6...@ietf.org>
Subject: RE: [spring] Beyond SRv6.

Inline…..



Juniper Business Use Only
From: Zafar Ali (zali) 
Sent: Friday, September 6, 2019 1:42 AM
To: Srihari Sangli ; Tarek Saad ; Ron 
Bonica ; Rob Shakir ; SPRING WG List 
; 6...@ietf.org
Cc: Zafar Ali (zali) 
Subject: Re: [spring] Beyond SRv6.



Hi Srihari,

> DA manipulation along the hop (shifting as the draft proposes) on each router 
> and reconstructing the DA - can make it harder to debug when
  > there is problem.



It has been clarified during the Spring WG session in Montreal. Repeating the 
same –



  *   The original segment list is maintained by using the non-Reduced flavor 
(in which case the SID list is fully preserved in the SRH).

[RB] At the cost of encoding efficiency. 50% decrease !!


In reality, debugability is a huge issue in CRH proposal.

[RB] In reality, the debuggability characteristics of SRv6+ are very similar to 
those of SR-MPLS. We have the same mapping from a short identifier (SRv6+ SID 
or SR-MPLS Label) to an IPv6 address.

[RB] So, would you like to argue that debuggability is a huge issue in SR-MPLS?

[ZA] Not at all. SR-MPLS uses MPLS OAM tool kit defined in 
https://tools.ietf.org/html/rfc8029.
[ZA] Are you suggesting you will introduce something similar to RFC8029?

  Ron


For example,
the CRH requires an IPv6 address to the “labels” mapping table (Yuck!).
An operator cannot determine the path packet will take by looking at CRH.
Have you realized how painful it will be for the operator to:

  *   Walk the CRH,
  *   Map each per-node "local labels" to its associated IPv6 address,
  *   Repeat the process for the entire label chain encoded in CRH.
Not to mention, this requires the operators to get the "mapping table" from 
each node in the network.



Thanks



Regards … Zafar




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Zafar Ali (zali)]

>SRv6+ is definitely a better proposal in terms
>  1.Adherence to IPv6 Architecture
>  2.Efficient encoding
>  3.Operational simplicity
>
>   There hasn't been a single mail denying the above advantages of SRv6+

This is absolutely false!

Have you forgotten the very strong arguments against it at the Spring session 
in Montreal and the various emails on the list that echoed them 
Not to mention comments from Robert R 
(https://mailarchive.ietf.org/arch/msg/spring/6bdX_gb47uFYnd6ytwFLPYxXCYo).

Yes, indeed Ron presented the proposal to every workgroup possible in Montreal, 
only to find no interest from anyone.
I would advise you to read that silence differently. 



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Sander Steffann]

Hi Reji,

> SRv6+  confirms to the V6 architecture, explains the rationale behind the 
> design and is non ambiguous to start with. Till now there has not been any 
> valid shortcomings brought forth with the Srv6+ design. I saw a mention that 
> SRv6+ needs to distribute the SID to address binding and hence require 
> extensions to protocols which is not what was intended by SR. Considering at 
> a bare minimum we would need a software/microcode update to support even the 
> SRH parsing, I didn’t understand why  protocol extension and mapping for SR 
> support with V6 is a bad idea. Please correct me if there is a gap in my 
> understanding.
> 
> In view of the above ,I support SRv6+ work to continue in the SPRING WG.

I agree with your arguments. +1 on work on this in SPRING, and preferably to 
focus on SRv6+ and not on SRv6/uSID/etc.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Reji Thomas]

Hi WG Folks,


Its not clear on why the SRv6 has to alter the address semantics and
push the service functions into v6 address space. Maybe rationale on
why this was done would help to appreciate why this path was chosen.
>From my understanding the SRv6+ spec shows these defined service
functions are best represented by destination options and is in line
with the IPv6 architecture document leaving the address space
semantics intact. In SRv6 the SID is defined as LOC:FUNCT:ARGS. It is
not clear on why this fixed address space would be sufficient for
arguments. I believe if the same cannot fit in 128 bit address space
it needs to be overflown into another SID or into a TLV. Doesn’t this
semantics suggest that TLV is the best place to encode this
information and should be in a destination option header in first
place?



It also seems that the TLV space in SR header might turn out to be a catch
all block wrt SR. For example  In-situ OAM IPv6 Options for Srv6 are
getting pushed to SR TLVs whereas for generic V6 I see there is another
draft (
https://tools.ietf.org/html/draft-ioametal-ippm-6man-ioam-ipv6-options-02)
 which
pushes them into destination options/hop-by-hop.  With the dilution of
semantics of headers are we looking at more conflicts of SRv6 model with
generic V6 features in future?.



 HMAC TLV is used to protect the SRH. It not clear on how the same would
interoperate with AH. When AH is included are we going to end with both AH
and HMAC TLV ?



The uSID draft for reducing the SRH overhead seems to be a hack at present
and its still not clear on how the same is going to be used with function
semantics.



SRv6+  confirms to the V6 architecture, explains the rationale behind the
design and is non ambiguous to start with. Till now there has not been any
valid shortcomings brought forth with the Srv6+ design. I saw a mention
that SRv6+ needs to distribute the SID to address binding and hence require
extensions to protocols which is not what was intended by SR. Considering
at a bare minimum we would need a software/microcode update to support even
the SRH parsing, I didn’t understand why  protocol extension and mapping
for SR support with V6 is a bad idea. Please correct me if there is a gap
in my understanding.



In view of the above ,I support SRv6+ work to continue in the SPRING WG.




Regards

Reji



> From: spring  on behalf of Ron Bonica 
> 
>
> Date: Monday, September 2, 2019 at 9:23 AM
> To: Rob Shakir , SPRING WG List <
> spring@ietf.org>, "6...@ietf.org" <6...@ietf.org>
> Subject: Re: [spring] Beyond SRv6.
>
> Rob,
>
> There may be an elephant in the room that needs addressing?.
>
> Over the years, the IPv6 community has specified a very tight architecture
> that encodes some information in IPv6 addresses, other information in
> Routing headers, and still other information in Destination Options
> headers. SRv6+ adheres strictly to this architecture. Because it reuses
> IPv6 machinery, its specification promises it be painless and its
> deployment promises to be safe. To date, there has been no significant
> technical criticism of SRv6+. Only a claim that SRv6 is nearly complete and
> good enough. (Both of those claims may require scrutiny).
>
> By contrast, SRv6 varies from the spirit, if not the letter of the IPv6
> architecture. It encodes things in IPv6 address that have never been
> encoded in IPv6 addresses before. It attempts to encode everything else in
> the Routing header, as if the other IPv6 extension headers didn?t exist. It
> frequently tests the limits of RFC 8200 compliance.
>
> This creates a situation in which each variance from IPv6 orthodoxy
> requires another. For example, because SRv6 encodes instructions in IPv6
> addresses, draft-ali-6man-spring-srv6-oam is required. And now,
> draft-ali-6man-spring-srv6-oam creates its own variances from the IPv6
> orthodoxy. OAM information is encoded in the Routing header and the Routing
> header must be examined, even when Segment Left is equal to zero.
>
> I invite everyone to consider how TI-LFA an uSID will interact.
>
> So, why would the IETF would want to prevent work on the more
> conservative, SRv6+ approach?  This brings us to the back to the elephant
> in the room?..
>
> Until very recently, relatively few router vendors have supported IPv6
> extension headers in ASICs. If an IPv6 packet contained any extension
> headers at all, it was sent to the slow path.
>
> SRv6+ encourages router vendors to support both the Routing and
> Destination Options header in ASICs. This sets vendors on a path on a path
> towards more complete implementation of the architecture that the IPv6
> community has developed so carefully over the years. It encourages vendors
> to commit more and more of RFC 8200 to ASICs.
>
> SRv6 encourages router vendors to support t

Re: [spring] Beyond SRv6.

[Nick Hilliard]

Rob,

Clarifying what I wrote previously, I don't think it would be 
appropriate for draft-filsfils-spring-net-pgm-extension-srv6-usid to 
progress further unless the authors can demonstrate that the volume of 
IPv6 addressing required can be satisfied in a way that works within the 
constraints that the operational community operates within.


If there is an expectation that this address space will be assigned from 
the global unicast address block via standard RIR allocation policies, 
then the authors will need to demonstrate that the RIRs are going to be 
comfortable changing their allocation policies to accommodate this.


Nick

Ron Bonica <mailto:rbonica=40juniper@dmarc.ietf.org>
1 September 2019 at 22:10
Hi Fernando,

6man participants should look at the following:

- 
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01 
(In particular, Sections 4 and 5)
- 
https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02


Ron


Juniper Business Use Only

-Original Message-
From: Fernando Gont 
Sent: Saturday, August 31, 2019 4:53 PM
To: Ron Bonica ; Rob Shakir ; 
SPRING WG List ; 6...@ietf.org

Subject: Re: [spring] Beyond SRv6.

Hi, Ron,

For those 6man-ers that have not been following the sprin work, could 
you please clarify what do you mean by "stretching the interpretation of

RFC8200 or RFC4291"?

In the past we have seen outright violation of RFC8200 (formerly 
RFC2460), so I'm curious if there are any documents trying to do the 
same, or what.


Thanks!

Cheers,
Fernando





--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




IETF IPv6 working group mailing list
i...@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6


Fernando Gont <mailto:fg...@si6networks.com>
31 August 2019 at 21:53
Hi, Ron,

For those 6man-ers that have not been following the sprin work, could
you please clarify what do you mean by "stretching the interpretation of
RFC8200 or RFC4291"?

In the past we have seen outright violation of RFC8200 (formerly
RFC2460), so I'm curious if there are any documents trying to do the
same, or what.

Thanks!

Cheers,
Fernando





Ron Bonica <mailto:rbonica=40juniper@dmarc.ietf.org>
31 August 2019 at 21:33

Rob,

The following are arguments for proceeding with SRv6+:

  * Efficient forwarding with deep SID lists
  * Operational Simplicity
  * SRv6+ work may finish before SRv6

Efficient forwarding with deep SID Lists



SR customers have stated a firm requirement to support SR paths that 
contain 8 to 12 segments. They have also stated a requirement for 
implementations to forward at line speed  and without consuming 
excessive overhead bandwidth.


SRv6, as defined in draft-ietf-6man-segment-routing-header, cannot 
satisfy these requirements. In order to support an SR path with 8 
segments, SRv6 would require a 128-byte SRH. Even if ASICs could 
process such a long SRH at line speed, the bandwidth overhead would be 
prohibitive.


Therefore, one of the four solutions  that you mention below is 
required to make SRv6 deployable. While 
draft-ietf-6man-segment-routing-header is close to maturity, the four 
competing solutions mentioned below are equally mature and should be 
given equal consideration.


The four solutions are SRv6+, uSID, draft-li and draft-mirsky.

Operational Simplicity

-

Network operators strive for operational simplicity. By loosely 
interpreting (and sometimes bending) the requirements of RFCs 4291 and 
RFC 8200, SRv6 introduces architectural quirks that introduce 
operational complexity. The following are architectural quirks of 
 draft-ietf-6man-segment-routing-header:


  * The Segment Routing Header (SRH) serves purposes other than
routing. Therefore, the SRH is sometimes required for packets that
traverse the least-cost path from source to destination
  * The SRH and the IPv6 Authentication Header are incompatible.
  * The IPv6 destination address determines whether an SRH is valid
and how it is processed. For example, if the IPv6 destination
address contains one locally instantiated value, the SRH might be
processed in one particular way, while if the IPv6 destination
address contains another locally instantiated value, the SRH might
be totally invalid.

Draft-ietf-spring-srv6-network-programming  promises more 
architectural quirks. For example:


  * Segment endpoints can insert and/or delete IPv6 extension headers
  * An IPv6 packet can contain two Segment Routing headers
  * IPv6 packets are no longer self-describing. For example, the Next
Header Field in the SRH can carry a value of No Next Header, even

Re: [spring] Beyond SRv6.

[Srihari Sangli]

Hi, WG Folks:

The segment routing solution leveraging the RFC8200 and the IPv6 architecture 
is better expressed in SRv6+. I support SRv6+.

The Destination Options header as defined in RFC8200 (section 4.6) is to inform 
the processing needed on the Destination device. The SRv6+ proposal (among 
other things) builds upon this and I think it is cleaner and clearer as 
compared to SRv6.

The issues I see with SRv6 proposals (uSID draft: 
draft-filsfils-spring-net-pgm-extension-srv6-usid-02 and the BGP extension 
draft: draft-dawra-bess-srv6-services-02) are the following.

  *   DA manipulation along the hop (shifting as the draft proposes) on each 
router and reconstructing the DA - can make it harder to debug when there is 
problem.
  *   To avoid prefix packing problem the BGP draft proposes to split the SID 
across different sections in the protocol PDU.

The above proposals for SRv6 seems like force-fit. My opinion is simpler 
encoding, proposal built upon well-defined architecture is good in longer run.
Thanks.

srihari…


On 03/09/19, 10:22 PM spring on behalf of Tarek Saad from 
spring-boun...@ietf.org<mailto:spring-boun...@ietf.org> on behalf of 
tsaad@gmail.com<mailto:tsaad@gmail.com> said >

Hi WG,

RFC8200 (section 4.4) defines the Routing Header as merely means to steer 
packets across topological elements. My understanding of the SRv6+’s proposal 
is that it strictly adheres to this and leaves any service or function 
instructions to be carried in other parts of IPv6 header. This (among other 
advantages) provides a clean delineation of the different layers of the network 
(underlay transport from overlay/services) and allows for possibility of 
different overlay technologies to be seamlessly carried over SRv6+.

This is in contrast to exposing overlays to a specific underlay technology and 
forcing it to understand and encode the required bits of information it 
requires within it.. Feel free to correct me if I got it wrong.

Regards,
Tarek


From: spring  on behalf of Ron Bonica 

Date: Monday, September 2, 2019 at 9:23 AM
To: Rob Shakir , SPRING WG List 
, "6...@ietf.org" <6...@ietf.org>
Subject: Re: [spring] Beyond SRv6.

Rob,

There may be an elephant in the room that needs addressing….

Over the years, the IPv6 community has specified a very tight architecture that 
encodes some information in IPv6 addresses, other information in Routing 
headers, and still other information in Destination Options headers. SRv6+ 
adheres strictly to this architecture. Because it reuses IPv6 machinery, its 
specification promises it be painless and its deployment promises to be safe. 
To date, there has been no significant technical criticism of SRv6+. Only a 
claim that SRv6 is nearly complete and good enough. (Both of those claims may 
require scrutiny).

By contrast, SRv6 varies from the spirit, if not the letter of the IPv6 
architecture. It encodes things in IPv6 address that have never been encoded in 
IPv6 addresses before. It attempts to encode everything else in the Routing 
header, as if the other IPv6 extension headers didn’t exist. It frequently 
tests the limits of RFC 8200 compliance.

This creates a situation in which each variance from IPv6 orthodoxy requires 
another. For example, because SRv6 encodes instructions in IPv6 addresses, 
draft-ali-6man-spring-srv6-oam is required. And now, 
draft-ali-6man-spring-srv6-oam creates its own variances from the IPv6 
orthodoxy. OAM information is encoded in the Routing header and the Routing 
header must be examined, even when Segment Left is equal to zero.

I invite everyone to consider how TI-LFA an uSID will interact.

So, why would the IETF would want to prevent work on the more conservative, 
SRv6+ approach?  This brings us to the back to the elephant in the room…..

Until very recently, relatively few router vendors have supported IPv6 
extension headers in ASICs. If an IPv6 packet contained any extension headers 
at all, it was sent to the slow path.

SRv6+ encourages router vendors to support both the Routing and Destination 
Options header in ASICs. This sets vendors on a path on a path towards more 
complete implementation of the architecture that the IPv6 community has 
developed so carefully over the years. It encourages vendors to commit more and 
more of RFC 8200 to ASICs.

SRv6 encourages router vendors to support the Routing header in ASICs, while 
doing everything possible to mitigate the need to support Destination Options 
in ASICs. This may be a necessary expedient for many platforms. However, it 
should not be the only approach, or even the long-term approach for the IETF.


   Ron




From: spring  On Behalf Of Rob Shakir
Sent: Sunday, August 4, 2019 5:04 PM
To: SPRING WG List 
Subject: [spring] Beyond SRv6.


Hi SPRING WG,


Over the last 5+ years, the I

Re: [spring] Beyond SRv6.

[Tarek Saad]

Hi WG,

RFC8200 (section 4.4) defines the Routing Header as merely means to steer 
packets across topological elements. My understanding of the SRv6+’s proposal 
is that it strictly adheres to this and leaves any service or function 
instructions to be carried in other parts of IPv6 header. This (among other 
advantages) provides a clean delineation of the different layers of the network 
(underlay transport from overlay/services) and allows for possibility of 
different overlay technologies to be seamlessly carried over SRv6+.

This is in contrast to exposing overlays to a specific underlay technology and 
forcing it to understand and encode the required bits of information it 
requires within it. Feel free to correct me if I got it wrong.

Regards,
Tarek


From: spring  on behalf of Ron Bonica 

Date: Monday, September 2, 2019 at 9:23 AM
To: Rob Shakir , SPRING WG List 
, "6...@ietf.org" <6...@ietf.org>
Subject: Re: [spring] Beyond SRv6.

Rob,

There may be an elephant in the room that needs addressing….

Over the years, the IPv6 community has specified a very tight architecture that 
encodes some information in IPv6 addresses, other information in Routing 
headers, and still other information in Destination Options headers. SRv6+ 
adheres strictly to this architecture. Because it reuses IPv6 machinery, its 
specification promises it be painless and its deployment promises to be safe. 
To date, there has been no significant technical criticism of SRv6+.. Only a 
claim that SRv6 is nearly complete and good enough. (Both of those claims may 
require scrutiny).

By contrast, SRv6 varies from the spirit, if not the letter of the IPv6 
architecture. It encodes things in IPv6 address that have never been encoded in 
IPv6 addresses before. It attempts to encode everything else in the Routing 
header, as if the other IPv6 extension headers didn’t exist. It frequently 
tests the limits of RFC 8200 compliance.

This creates a situation in which each variance from IPv6 orthodoxy requires 
another. For example, because SRv6 encodes instructions in IPv6 addresses, 
draft-ali-6man-spring-srv6-oam is required. And now, 
draft-ali-6man-spring-srv6-oam creates its own variances from the IPv6 
orthodoxy. OAM information is encoded in the Routing header and the Routing 
header must be examined, even when Segment Left is equal to zero.

I invite everyone to consider how TI-LFA an uSID will interact.

So, why would the IETF would want to prevent work on the more conservative, 
SRv6+ approach?  This brings us to the back to the elephant in the room…...

Until very recently, relatively few router vendors have supported IPv6 
extension headers in ASICs. If an IPv6 packet contained any extension headers 
at all, it was sent to the slow path.

SRv6+ encourages router vendors to support both the Routing and Destination 
Options header in ASICs. This sets vendors on a path on a path towards more 
complete implementation of the architecture that the IPv6 community has 
developed so carefully over the years. It encourages vendors to commit more and 
more of RFC 8200 to ASICs.

SRv6 encourages router vendors to support the Routing header in ASICs, while 
doing everything possible to mitigate the need to support Destination Options 
in ASICs. This may be a necessary expedient for many platforms. However, it 
should not be the only approach, or even the long-term approach for the IETF.


   Ron




From: spring  On Behalf Of Rob Shakir
Sent: Sunday, August 4, 2019 5:04 PM
To: SPRING WG List 
Subject: [spring] Beyond SRv6.


Hi SPRING WG,


Over the last 5+ years, the IETF has developed Source Packet Routing in 
NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6 
(SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE.


These encapsulations are past WG last call (in IESG or RFC Editor).


During the SPRING WG meeting at IETF 105, two presentations were related to the 
reduction of the size of the SID for IPv6 dataplane:
· SRv6+ / CRH -- 
https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus-2D04=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s=KUhAfjVsx_wK645uJk0FHzs2vxiAVr-CskMPAaEhEQQ=>
· uSID -- 
https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfilsfils-2Dspring-2Dnet-2Dpgm-2Dextension-2Dsrv6-2Dusid-2D01=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s=Aq1DK7fu73axZ1PXLIE8xnHE2AhTtNZy9LTHgWqx4CQ=>


During the IETF

Re: [spring] Beyond SRv6.

[Ron Bonica]

Robert,

I am afraid that won't fulfill customer requirements.

The customer is looking for an SR solution that whose efficiency and 
performance is comparable to SR-MPLS, but operates in an MPLS-free, IPv6 
environment.  It should abide, in both spirit and letter, to the requirements 
of RFC 4291 and RFC 8200.

Returning to your initial offer, is there some architectural statement that 
could be added to the SRv6+ overview document that would reduce the barrier to 
acceptance? If so, I would be happy to collaborate with you on that.


 Ron

From: Robert Raszuk 
Sent: Tuesday, September 3, 2019 11:00 AM
To: Ron Bonica 
Cc: Shraddha Hegde ; Rob Shakir ; 
SPRING WG List ; 6...@ietf.org
Subject: Re: [spring] Beyond SRv6.

Hi Ron,

You are spot on that SRv6+ conceptually and operationally is very similar to 
SR-MPLS. That is why calling it SRv6+ to me is not right.

Instead of producing comparisons with existing RFCs or trying to push new 
Routing Header type in 6man, new IGP extensions, new BGP extensions etc ...  
how about we do something else ?

We drop CRH and we take SR-MPLS as it is now - shipped and interoperable and we 
add IP forwarding to it. It could by using some elements from Vector Routing 
proposal 
(https://tools.ietf.org/html/draft-patel-raszuk-bgp-vector-routing-07<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dpatel-2Draszuk-2Dbgp-2Dvector-2Drouting-2D07=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8=zDo9AVnTkuCi4IHti-9EhZLUSvGeS-TkbCp3O8pNhVM=0P-4AxiQFqdUMdhUADvLEtSweCzPg4UBuxYd--JYWP8=>)
 or by verbatim using 
https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dmpls-2Dsr-2Dover-2Dip-2D07=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8=zDo9AVnTkuCi4IHti-9EhZLUSvGeS-TkbCp3O8pNhVM=yHbbMsnrtm_yaU9zVkeITY1ZY0iTzx60SukxXad9Yy8=>
 proposal.

That way you get all beauty and power of SR architecture, no impact/change to 
data plane and yet you get IP forwarding between SR nodes (either IPv4 or IPv6) 
to allow minimal data plane overhead deployments for networks which do not want 
to use LDP, MPLS as transport or get into RSVP-TE challanges ?

SRv6 can continue to progress as it offers much broader set of functionality. 
It also offers true direct IPv6 solution in that space.

Note that even in SR-MPLS some labels may embed pointers to local processing 
functions.

So the bottom line key question stands: Is there anything functionally and 
practically missing if we use SR-MPLS-over-IP as compared with SRv6+/CRH 
proposal ?

Best,
R.


On Tue, Sep 3, 2019 at 4:31 PM Ron Bonica 
mailto:rbon...@juniper.net>> wrote:
Robert,

In SRv6+, global SIDs work in a manner that is very similar SR-MPLS. If you 
compare the two relevant IS-IS drafts, you will see a striking similarity. This 
is why SRv6+ uses the term "global SID" as opposed to END SID.

In your message, below, you suggest that if we document the differences between 
the proposed architecture and that which is documented in RFC 8402, the barrier 
to acceptance could be much different.

Could we explore that option together? If you generate some bullet points, I 
can craft some text.

  Ron




From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Tuesday, September 3, 2019 8:13 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>
Cc: Ron Bonica mailto:rbon...@juniper.net>>; Rob Shakir 
mailto:ro...@google.com>>; SPRING WG List 
mailto:spring@ietf.org>>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: Re: [spring] Beyond SRv6.

Hi Shraddha,

The proposed architecture in CRH based drafts is a significant departure from 
Segment Routing Architecture as standardized in IETF.

The compression advantages the set of drafts propose are all based on the 
mapping of 16 or 32 bit bitstrings to IPv6 addresses and their flooding in IGPs 
and BGP via proposed extensions. Such mapping is not part of SR Architecture.

As you know I personally have no objections to support any control plane 
solution. Specifically if you would honestly admit that proposed architecture 
is not in line with Segment Routing Architecture as described in RFC8402, but 
solves some customer needs I am sure the acceptance barrier could be much 
different.

Taking your scheme - please kindly explain how can you provide the notion of 
Global Adj SIDs ref section 3.4 of RFC 8402 ?

With your scheme to operate IPv6 to SID mapping must be flooded in IGP domain 
wide so even if nodes do not need to participate in any IPv6 Segment Routing 
they will need to store in their control plane such additional state. Without 
mapping such additional state in SRv6 operation by non

Re: [spring] Beyond SRv6.

[Robert Raszuk]

Hi Ron,

You are spot on that SRv6+ conceptually and operationally is very similar
to SR-MPLS. That is why calling it SRv6+ to me is not right.

Instead of producing comparisons with existing RFCs or trying to push new
Routing Header type in 6man, new IGP extensions, new BGP extensions etc
  how about we do something else ?

We drop CRH and we take SR-MPLS as it is now - shipped and interoperable
and we add IP forwarding to it. It could by using some elements from Vector
Routing proposal (
https://tools.ietf.org/html/draft-patel-raszuk-bgp-vector-routing-07) or by
verbatim using https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07
 proposal.

That way you get all beauty and power of SR architecture, no impact/change
to data plane and yet you get IP forwarding between SR nodes (either IPv4
or IPv6) to allow minimal data plane overhead deployments for networks
which do not want to use LDP, MPLS as transport or get into RSVP-TE
challanges ?

SRv6 can continue to progress as it offers much broader set of
functionality. It also offers true direct IPv6 solution in that space.

Note that even in SR-MPLS some labels may embed pointers to local
processing functions.

So the bottom line key question stands: Is there anything functionally and
practically missing if we use SR-MPLS-over-IP as compared with SRv6+/CRH
proposal ?

Best,
R.


On Tue, Sep 3, 2019 at 4:31 PM Ron Bonica  wrote:

> Robert,
>
>
>
> In SRv6+, global SIDs work in a manner that is very similar SR-MPLS. If
> you compare the two relevant IS-IS drafts, you will see a striking
> similarity. This is why SRv6+ uses the term “global SID” as opposed to END
> SID.
>
>
>
> In your message, below, you suggest that if we document the differences
> between the proposed architecture and that which is documented in RFC 8402,
> the barrier to acceptance could be much different.
>
>
>
> Could we explore that option together? If you generate some bullet points,
> I can craft some text.
>
>
>
>   Ron
>
>
>
>
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Tuesday, September 3, 2019 8:13 AM
> *To:* Shraddha Hegde 
> *Cc:* Ron Bonica ; Rob Shakir ;
> SPRING WG List ; 6...@ietf.org
> *Subject:* Re: [spring] Beyond SRv6.
>
>
>
> Hi Shraddha,
>
>
>
> The proposed architecture in CRH based drafts is a significant departure
> from Segment Routing Architecture as standardized in IETF.
>
>
>
> The compression advantages the set of drafts propose are all based on the
> mapping of 16 or 32 bit bitstrings to IPv6 addresses and their flooding in
> IGPs and BGP via proposed extensions. Such mapping is not part of SR
> Architecture.
>
>
>
> As you know I personally have no objections to support any control plane
> solution. Specifically if you would honestly admit that proposed
> architecture is not in line with Segment Routing Architecture as described
> in RFC8402, but solves some customer needs I am sure the acceptance barrier
> could be much different.
>
>
>
> Taking your scheme - please kindly explain how can you provide the notion
> of Global Adj SIDs ref section 3.4 of RFC 8402 ?
>
>
>
> With your scheme to operate IPv6 to SID mapping must be flooded in IGP
> domain wide so even if nodes do not need to participate in any IPv6 Segment
> Routing they will need to store in their control plane such additional
> state. Without mapping such additional state in SRv6 operation by non SR
> nodes is optional - meaning that SRv6 can operate just fine without any IGP
> extensions required.
>
>
>
> Quote from "draft-ietf-lsr-isis-srv6-extensions-02":
>
>
>
>Segment Routing can be directly instantiated on the IPv6 data plane
>through the use of the Segment Routing Header defined in
>[I-D.ietf-6man-segment-routing-header].
>
>
>
> Can you kindly explain how SRv6+ proposal can be directly instantiated on
> the IPv6 data plane without any protocol extensions ?
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
> On Tue, Sep 3, 2019 at 12:44 PM Shraddha Hegde  40juniper@dmarc.ietf.org> wrote:
>
> SPRING WG,
>
>
>
> SRv6+ is definitely a better proposal in terms
>
>1.Adherence to IPv6 Architecture
>
>2.Efficient encoding
>
>3.Operational simplicity
>
>
>
>There hasn't been a single mail denying the above advantages of SRv6+
>
>The only argument has been the SRv6 in its present form has been
>
>deployed by a couple of operators and a handful interested in it.
>
>
>
>u-sid tries to solve point 2 above but the addressing architecture
>
>isn't very clear. Deploying this solution in 

Re: [spring] Beyond SRv6.

[Ron Bonica]

Fernando,

Please search for the work "insert" in Section 4 of 
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01. You 
will see several examples.

You will also see an example where a second Routing header is  inserted.

   Ron


Juniper Business Use Only

-Original Message-
From: Fernando Gont  
Sent: Tuesday, September 3, 2019 7:26 AM
To: Ron Bonica ; Rob Shakir ; SPRING WG 
List ; 6...@ietf.org
Subject: Re: [spring] Beyond SRv6.

On 2/9/19 00:10, Ron Bonica wrote:
> Hi Fernando,
> 
> 6man participants should look at the following:
> 
> - 
> - https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01 
> (In particular, Sections 4 and 5)
> - 
> https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02

The short version of the question would be:
Does any of these I-Ds, and in particular, 
draft-ietf-spring-srv6-network-programming (a wg item) propose or suggest to 
insert EHs in the network?

Thanks,




--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Ron Bonica]

Robert,

In SRv6+, global SIDs work in a manner that is very similar SR-MPLS. If you 
compare the two relevant IS-IS drafts, you will see a striking similarity. This 
is why SRv6+ uses the term "global SID" as opposed to END SID.

In your message, below, you suggest that if we document the differences between 
the proposed architecture and that which is documented in RFC 8402, the barrier 
to acceptance could be much different.

Could we explore that option together? If you generate some bullet points, I 
can craft some text.

  Ron




From: Robert Raszuk 
Sent: Tuesday, September 3, 2019 8:13 AM
To: Shraddha Hegde 
Cc: Ron Bonica ; Rob Shakir ; SPRING WG 
List ; 6...@ietf.org
Subject: Re: [spring] Beyond SRv6.

Hi Shraddha,

The proposed architecture in CRH based drafts is a significant departure from 
Segment Routing Architecture as standardized in IETF.

The compression advantages the set of drafts propose are all based on the 
mapping of 16 or 32 bit bitstrings to IPv6 addresses and their flooding in IGPs 
and BGP via proposed extensions. Such mapping is not part of SR Architecture.

As you know I personally have no objections to support any control plane 
solution. Specifically if you would honestly admit that proposed architecture 
is not in line with Segment Routing Architecture as described in RFC8402, but 
solves some customer needs I am sure the acceptance barrier could be much 
different.

Taking your scheme - please kindly explain how can you provide the notion of 
Global Adj SIDs ref section 3.4 of RFC 8402 ?

With your scheme to operate IPv6 to SID mapping must be flooded in IGP domain 
wide so even if nodes do not need to participate in any IPv6 Segment Routing 
they will need to store in their control plane such additional state. Without 
mapping such additional state in SRv6 operation by non SR nodes is optional - 
meaning that SRv6 can operate just fine without any IGP extensions required.

Quote from "draft-ietf-lsr-isis-srv6-extensions-02":

   Segment Routing can be directly instantiated on the IPv6 data plane
   through the use of the Segment Routing Header defined in
   [I-D.ietf-6man-segment-routing-header].

Can you kindly explain how SRv6+ proposal can be directly instantiated on the 
IPv6 data plane without any protocol extensions ?

Kind regards,
Robert


On Tue, Sep 3, 2019 at 12:44 PM Shraddha Hegde 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
SPRING WG,

SRv6+ is definitely a better proposal in terms
   1.Adherence to IPv6 Architecture
   2.Efficient encoding
   3.Operational simplicity

   There hasn't been a single mail denying the above advantages of SRv6+
   The only argument has been the SRv6 in its present form has been
   deployed by a couple of operators and a handful interested in it.

   u-sid tries to solve point 2 above but the addressing architecture
   isn't very clear. Deploying this solution in a running network
   hasn't been explained.

   There is clearly interest in the operator community for a better solution and
   I support SPRING WG to continue work on SRv6+.


Rgds
Shraddha



Juniper Business Use Only
From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Ron Bonica
Sent: Monday, September 2, 2019 6:53 PM
To: Rob Shakir 
mailto:40google@dmarc.ietf..org>>; 
SPRING WG List mailto:spring@ietf.org>>; 
6...@ietf.org<mailto:6...@ietf.org>
Subject: Re: [spring] Beyond SRv6.

Rob,

There may be an elephant in the room that needs addressing

Over the years, the IPv6 community has specified a very tight architecture that 
encodes some information in IPv6 addresses, other information in Routing 
headers, and still other information in Destination Options headers. SRv6+ 
adheres strictly to this architecture. Because it reuses IPv6 machinery, its 
specification promises it be painless and its deployment promises to be safe. 
To date, there has been no significant technical criticism of SRv6+.. Only a 
claim that SRv6 is nearly complete and good enough. (Both of those claims may 
require scrutiny).

By contrast, SRv6 varies from the spirit, if not the letter of the IPv6 
architecture. It encodes things in IPv6 address that have never been encoded in 
IPv6 addresses before. It attempts to encode everything else in the Routing 
header, as if the other IPv6 extension headers didn't exist. It frequently 
tests the limits of RFC 8200 compliance.

This creates a situation in which each variance from IPv6 orthodoxy requires 
another. For example, because SRv6 encodes instructions in IPv6 addresses, 
draft-ali-6man-spring-srv6-oam is required. And now, 
draft-ali-6man-spring-srv6-oam creates its own variances from the IPv6 
orthodoxy. OAM information is encoded in the Routing header and the Routing 
header must be examined, even when Segment Left is equal to zero.

I invite everyone to consider how TI-LFA an uSID will interact.

Re: [spring] Beyond SRv6.

[Robert Raszuk]

Hi Shraddha,

The proposed architecture in CRH based drafts is a significant departure
from Segment Routing Architecture as standardized in IETF.

The compression advantages the set of drafts propose are all based on the
mapping of 16 or 32 bit bitstrings to IPv6 addresses and their flooding in
IGPs and BGP via proposed extensions. Such mapping is not part of SR
Architecture.

As you know I personally have no objections to support any control plane
solution. Specifically if you would honestly admit that proposed
architecture is not in line with Segment Routing Architecture as described
in RFC8402, but solves some customer needs I am sure the acceptance barrier
could be much different.

Taking your scheme - please kindly explain how can you provide the notion
of Global Adj SIDs ref section 3.4 of RFC 8402 ?

With your scheme to operate IPv6 to SID mapping must be flooded in IGP
domain wide so even if nodes do not need to participate in any IPv6 Segment
Routing they will need to store in their control plane such additional
state. Without mapping such additional state in SRv6 operation by non SR
nodes is optional - meaning that SRv6 can operate just fine without any IGP
extensions required.

Quote from "draft-ietf-lsr-isis-srv6-extensions-02":

   Segment Routing can be directly instantiated on the IPv6 data plane
   through the use of the Segment Routing Header defined in
   [I-D.ietf-6man-segment-routing-header].

Can you kindly explain how SRv6+ proposal can be directly instantiated on
the IPv6 data plane without any protocol extensions ?

Kind regards,
Robert


On Tue, Sep 3, 2019 at 12:44 PM Shraddha Hegde  wrote:

> SPRING WG,
>
>
>
> SRv6+ is definitely a better proposal in terms
>
>1.Adherence to IPv6 Architecture
>
>2.Efficient encoding
>
>3.Operational simplicity
>
>
>
>There hasn't been a single mail denying the above advantages of SRv6+
>
>The only argument has been the SRv6 in its present form has been
>
>deployed by a couple of operators and a handful interested in it.
>
>
>
>u-sid tries to solve point 2 above but the addressing architecture
>
>isn't very clear. Deploying this solution in a running network
>
>hasn't been explained.
>
>
>
>There is clearly interest in the operator community for a better
> solution and
>
>I support SPRING WG to continue work on SRv6+.
>
>
>
>
>
> Rgds
>
> Shraddha
>
>
>
> *From:* spring  *On Behalf Of *Ron Bonica
> *Sent:* Monday, September 2, 2019 6:53 PM
> *To:* Rob Shakir ; SPRING WG List <
> spring@ietf.org>; 6...@ietf.org
> *Subject:* Re: [spring] Beyond SRv6.
>
>
>
> Rob,
>
>
>
> There may be an elephant in the room that needs addressing….
>
>
>
> Over the years, the IPv6 community has specified a very tight architecture
> that encodes some information in IPv6 addresses, other information in
> Routing headers, and still other information in Destination Options
> headers. SRv6+ adheres strictly to this architecture. Because it reuses
> IPv6 machinery, its specification promises it be painless and its
> deployment promises to be safe. To date, there has been no significant
> technical criticism of SRv6+. Only a claim that SRv6 is nearly complete and
> good enough. (Both of those claims may require scrutiny).
>
>
>
> By contrast, SRv6 varies from the spirit, if not the letter of the IPv6
> architecture. It encodes things in IPv6 address that have never been
> encoded in IPv6 addresses before. It attempts to encode everything else in
> the Routing header, as if the other IPv6 extension headers didn’t exist. It
> frequently tests the limits of RFC 8200 compliance.
>
>
>
> This creates a situation in which each variance from IPv6 orthodoxy
> requires another. For example, because SRv6 encodes instructions in IPv6
> addresses, draft-ali-6man-spring-srv6-oam is required. And now,
> draft-ali-6man-spring-srv6-oam creates its own variances from the IPv6
> orthodoxy. OAM information is encoded in the Routing header and the Routing
> header must be examined, even when Segment Left is equal to zero.
>
>
>
> I invite everyone to consider how TI-LFA an uSID will interact.
>
>
>
> So, why would the IETF would want to prevent work on the more
> conservative, SRv6+ approach?  This brings us to the back to the elephant
> in the room…..
>
>
>
> Until very recently, relatively few router vendors have supported IPv6
> extension headers in ASICs. If an IPv6 packet contained any extension
> headers at all, it was sent to the slow path.
>
>
>
> SRv6+ encourages router vendors to support both the Routing and
> Destination Options header in ASICs. This sets vendors on a path on a path
> towards more

Re: [spring] Beyond SRv6.

[Fernando Gont]

On 2/9/19 00:10, Ron Bonica wrote:
> Hi Fernando,
> 
> 6man participants should look at the following:
> 
> - https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01 
> (In particular, Sections 4 and 5)
> - 
> https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02

The short version of the question would be:
Does any of these I-Ds, and in particular,
draft-ietf-spring-srv6-network-programming (a wg item) propose or
suggest to insert EHs in the network?

Thanks,




-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Shraddha Hegde]

SPRING WG,

SRv6+ is definitely a better proposal in terms
   1.Adherence to IPv6 Architecture
   2.Efficient encoding
   3.Operational simplicity

   There hasn't been a single mail denying the above advantages of SRv6+
   The only argument has been the SRv6 in its present form has been
   deployed by a couple of operators and a handful interested in it.

   u-sid tries to solve point 2 above but the addressing architecture
   isn't very clear. Deploying this solution in a running network
   hasn't been explained.

   There is clearly interest in the operator community for a better solution and
   I support SPRING WG to continue work on SRv6+.


Rgds
Shraddha

From: spring  On Behalf Of Ron Bonica
Sent: Monday, September 2, 2019 6:53 PM
To: Rob Shakir ; SPRING WG List 
; 6...@ietf.org
Subject: Re: [spring] Beyond SRv6.

Rob,

There may be an elephant in the room that needs addressing

Over the years, the IPv6 community has specified a very tight architecture that 
encodes some information in IPv6 addresses, other information in Routing 
headers, and still other information in Destination Options headers. SRv6+ 
adheres strictly to this architecture. Because it reuses IPv6 machinery, its 
specification promises it be painless and its deployment promises to be safe. 
To date, there has been no significant technical criticism of SRv6+.. Only a 
claim that SRv6 is nearly complete and good enough. (Both of those claims may 
require scrutiny).

By contrast, SRv6 varies from the spirit, if not the letter of the IPv6 
architecture. It encodes things in IPv6 address that have never been encoded in 
IPv6 addresses before. It attempts to encode everything else in the Routing 
header, as if the other IPv6 extension headers didn't exist. It frequently 
tests the limits of RFC 8200 compliance.

This creates a situation in which each variance from IPv6 orthodoxy requires 
another. For example, because SRv6 encodes instructions in IPv6 addresses, 
draft-ali-6man-spring-srv6-oam is required. And now, 
draft-ali-6man-spring-srv6-oam creates its own variances from the IPv6 
orthodoxy. OAM information is encoded in the Routing header and the Routing 
header must be examined, even when Segment Left is equal to zero.

I invite everyone to consider how TI-LFA an uSID will interact.

So, why would the IETF would want to prevent work on the more conservative, 
SRv6+ approach?  This brings us to the back to the elephant in the room..

Until very recently, relatively few router vendors have supported IPv6 
extension headers in ASICs. If an IPv6 packet contained any extension headers 
at all, it was sent to the slow path.

SRv6+ encourages router vendors to support both the Routing and Destination 
Options header in ASICs. This sets vendors on a path on a path towards more 
complete implementation of the architecture that the IPv6 community has 
developed so carefully over the years. It encourages vendors to commit more and 
more of RFC 8200 to ASICs.

SRv6 encourages router vendors to support the Routing header in ASICs, while 
doing everything possible to mitigate the need to support Destination Options 
in ASICs. This may be a necessary expedient for many platforms. However, it 
should not be the only approach, or even the long-term approach for the IETF.


   Ron




From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Rob Shakir
Sent: Sunday, August 4, 2019 5:04 PM
To: SPRING WG List mailto:spring@ietf.org>>
Subject: [spring] Beyond SRv6.


Hi SPRING WG,


Over the last 5+ years, the IETF has developed Source Packet Routing in 
NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6 
(SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE.


These encapsulations are past WG last call (in IESG or RFC Editor).


During the SPRING WG meeting at IETF 105, two presentations were related to the 
reduction of the size of the SID for IPv6 dataplane:

  *   SRv6+ / CRH -- 
https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus-2D04=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s=KUhAfjVsx_wK645uJk0FHzs2vxiAVr-CskMPAaEhEQQ=>
  *   uSID -- 
https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfilsfils-2Dspring-2Dnet-2Dpgm-2Dextension-2Dsrv6-2Dusid-2D01=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s=Aq1DK7fu73axZ1PXLIE8xnHE2AhTtNZy9LTHgWqx4CQ=>


During the IETF week, two additional drafts have been proposed:

  *   
https://tool

Re: [spring] Beyond SRv6.

[Parag Kaneriya]

Completely agree with Ron.

SRv6+ is much more simpler ,  minimum config required and easy to implement..

Regards
Parag



Juniper Business Use Only
From: spring  On Behalf Of Ron Bonica
Sent: Sunday, September 1, 2019 2:04 AM
To: Rob Shakir ; SPRING WG List 
; 6...@ietf.org
Subject: Re: [spring] Beyond SRv6.

Rob,

The following are arguments for proceeding with SRv6+:


  *   Efficient forwarding with deep SID lists
  *   Operational Simplicity
  *   SRv6+ work may finish before SRv6

Efficient forwarding with deep SID Lists


SR customers have stated a firm requirement to support SR paths that contain 8 
to 12 segments. They have also stated a requirement for implementations to 
forward at line speed  and without consuming excessive overhead bandwidth.

SRv6, as defined in draft-ietf-6man-segment-routing-header, cannot satisfy 
these requirements. In order to support an SR path with 8 segments, SRv6 would 
require a 128-byte SRH. Even if ASICs could process such a long SRH at line 
speed, the bandwidth overhead would be prohibitive.

Therefore, one of the four solutions  that you mention below is required to 
make SRv6 deployable. While draft-ietf-6man-segment-routing-header is close to 
maturity, the four competing solutions mentioned below are equally mature and 
should be given equal consideration.


The four solutions are SRv6+, uSID, draft-li and draft-mirsky.

Operational Simplicity
-
Network operators strive for operational simplicity. By loosely interpreting 
(and sometimes bending) the requirements of RFCs 4291 and RFC 8200, SRv6 
introduces architectural quirks that introduce operational complexity. The 
following are architectural quirks of  draft-ietf-6man-segment-routing-header:


  *   The Segment Routing Header (SRH) serves purposes other than routing. 
Therefore, the SRH is sometimes required for packets that traverse the 
least-cost path from source to destination
  *   The SRH and the IPv6 Authentication Header are incompatible.
  *   The IPv6 destination address determines whether an SRH is valid and how 
it is processed. For example, if the IPv6 destination address contains one 
locally instantiated value, the SRH might be processed in one particular way, 
while if the IPv6 destination address contains another locally instantiated 
value, the SRH might be totally invalid.

Draft-ietf-spring-srv6-network-programming  promises more architectural quirks. 
For example:


  *   Segment endpoints can insert and/or delete IPv6 extension headers
  *   An IPv6 packet can contain two Segment Routing headers
  *   IPv6 packets are no longer self-describing. For example, the Next Header 
Field in the SRH can carry a value of No Next Header, even though the SRH is 
followed by Ethernet payload.

Other emerging drafts promise still more architectural quirks. For example, in 
draft-ali-6man-spring-srv6-oam, implementations need to examine the SRH even 
when Segment Left equals zero. This is because the SRH has been overloaded to 
carry OAM as well as routing information.

Furthermore, draft-filsfils-spring-net-pgm-extension-srv6-usid requires network 
operators to obtain address space and number their networks in a particular way 
to make routing work.

SRv6+ Work May Finish Before SRv6 work

SRv6+  has been implemented on LINUX and is being implemented on JUNOS. 
Implementation experience demonstrates that specification is fairly complete. 
For example, there is no need for an SRv6+ OAM document. It's just IPv6 and 
IPv6 OAM just works.

Furthermore, the SRv6+ specifications adhere to a strict interpretation of RFC 
8200. Therefore, as they progress through the working group, they won't need to 
overcome the objections that are inevitably encountered when stretching the 
interpretation of a specification that is so fundamental as RFC 8200.


  Thanks,

  Ron








From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Rob Shakir
Sent: Sunday, August 4, 2019 5:04 PM
To: SPRING WG List mailto:spring@ietf.org>>
Subject: [spring] Beyond SRv6.


Hi SPRING WG,


Over the last 5+ years, the IETF has developed Source Packet Routing in 
NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6 
(SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE.


These encapsulations are past WG last call (in IESG or RFC Editor).


During the SPRING WG meeting at IETF 105, two presentations were related to the 
reduction of the size of the SID for IPv6 dataplane:

  *   SRv6+ / CRH -- 
https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html

Re: [spring] Beyond SRv6.

[Kamran Raza (skraza)]

I agree; there is no need for a new encapsulation.

--
Kamran

From: spring  on behalf of "Voyer, Daniel" 

Date: Monday, September 2, 2019 at 10:25 AM
To: Dirk Steinberg , SPRING WG List , Rob 
Shakir 
Subject: Re: [spring] Beyond SRv6.

Hi,

I agree with Dirk. The SRv6 fulfills our requirements for vast majority of our 
use-cases. For some use cases requiring MTU efficiency, we have SRv6 uSID 
segments that are just a different pseudo code and is fully integrated with SRH.

I also concur, there is no need for the work group for define a new extension 
header.

Thanks,
dan

From: spring  on behalf of Dirk Steinberg 

Date: Sunday, September 1, 2019 at 10:20 AM
To: SPRING WG List , Rob Shakir 

Subject: [EXT]Re: [spring] Beyond SRv6.

Hi,

the introduction of SRv6 as alternate data plane in addition to MPLS
has been an important step in SPRING, providing an encapsulation
for SPRING traffic that is native to IPv6.

The question about the necessity of work on alternate encapsulations
was fueled by concerns about encapsulation overhead when using
full 128 bit SIDs in the SRv6 SRH.

Through the introduction of the uSID network instruction in SRv6
these concerns are now properly addressed and SRv6 with uSID
can now also be deployed in a very MTU-efficient manner.

Therefore I do not see a necessity for any additional encapsulations.

Cheers
Dirk

Am 31.08.2019 um 06:05 schrieb Zafar Ali (zali) 
mailto:z...@cisco.com>>:

Dear Chairs and the WG:

The SRv6 network programming solution and its SRH encapsulation is implemented 
on 12 hardware platforms including Merchant Silicon.
Multiple providers have deployed the SRv6 network programming solution and its 
SRH encapsulation with line-rate performance carrying a significant amount of 
commercial traffic.
Several independent interoperability reports documenting successful 
interoperability of implementation from multiple vendors exist.
Implementation, deployment, and interoperability status is publicly documented 
in 
https://www.ietf.org/id/draft-matsushima-spring-srv6-deployment-status-01.txt.

Most use-cases are expected to use very few SRv6 segments.

In some specific use-cases, one may desire to optimize the MTU usage further.
The SRv6 network programming solution and its SRH encapsulation also support 
for this Optimization, through the uSID network instruction.

I do not see the need for any new encapsulation work.

Thanks

Regards … Zafar

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Rob Shakir 
mailto:robjs=40google@dmarc.ietf.org>>
Date: Sunday, August 4, 2019 at 5:04 PM
To: SPRING WG List mailto:spring@ietf.org>>
Subject: [spring] Beyond SRv6.

Hi SPRING WG,

Over the last 5+ years, the IETF has developed Source Packet Routing in 
NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6 
(SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE.

These encapsulations are past WG last call (in IESG or RFC Editor).

During the SPRING WG meeting at IETF 105, two presentations were related to the 
reduction of the size of the SID for IPv6 dataplane:

  *
  *   SRv6+ / CRH --
  *   https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04
  *
  *
  *   uSID --
  *   
https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01
  *

During the IETF week, two additional drafts have been proposed:

  *
  *   https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00
  *
  *
  *   https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03
  *

As we expressed during the meeting, it is important for the WG to understand 
what the aims of additional encapsulations are. Thus, we think it is important 
that the WG should first get to a common understanding on the requirements for 
a new IPv6 data plane with a smaller SID - both from the perspective of 
operators that are looking to deploy these technologies, and from that of the 
software/hardware implementation.

Therefore, we would like to solicit network operators interested in SR over the 
IPv6 data plane to briefly introduce their:

  *
  *   use case (e.g. Fast Reroute, explicit routing/TE)
  *
  *
  *   forwarding performance and scaling requirements
  *

 *
 *   e.g., (number of nodes, network diameter,
 *   number of SID required in max and average). For the latter, if 
possible using both SRv6 128-bit SIDs and shorter (e.g. 32-bit) SIDs as the 
number would typically be different (*).
 *

  *
  *   if the existing SRv6 approach is not deployable
  *   in their circumstances, details of the requirement of a different 
solution is required and whether this solution is needed for the short term 
only or for the long term.
  *

As well as deployment limitations, we would like the SPRING community to 
briefly describe the platform limitations that they are seeing which limit the 
deployment of SRv6  In particular limitations related to the number of SIDs 
which can be pushed 

Re: [spring] Beyond SRv6.

[Henderickx, Wim (Nokia - BE/Antwerp)]

Adding my perspective here. The fact that some proposals come on the table 
shows that we have something to optimize. So far there has been little feedback 
on sizes required in real deployments. Personally I have seen request for small 
(1-2 sids) to other cases which require up to 9-10 sids deep. We know certain 
HW cannot cope with some of these requests. I cannot judge on how many 
customers or in small to medium range but it would be good we can define a 
solution that works for the majority of customers.

Now given that this is going on for some time in IETF and we have deployments 
it would be bad if we change direction all of a sudden. So I propose to flush 
out what we have and where the limits are and figure out a way forward based on 
this.

My 2 cents.


From: spring  on behalf of Rob Shakir 

Date: Sunday, 4 August 2019 at 22:04
To: SPRING WG List 
Subject: [spring] Beyond SRv6.


Hi SPRING WG,


Over the last 5+ years, the IETF has developed Source Packet Routing in 
NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6 
(SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE.


These encapsulations are past WG last call (in IESG or RFC Editor).


During the SPRING WG meeting at IETF 105, two presentations were related to the 
reduction of the size of the SID for IPv6 dataplane:

  *
  *   SRv6+ / CRH --
  *   https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04
  *
  *
  *   uSID --
  *   
https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01
  *


During the IETF week, two additional drafts have been proposed:

  *
  *   https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00
  *
  *
  *   https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03
  *


As we expressed during the meeting, it is important for the WG to understand 
what the aims of additional encapsulations are. Thus, we think it is important 
that the WG should first get to a common understanding on the requirements for 
a new IPv6 data plane with a smaller SID - both from the perspective of 
operators that are looking to deploy these technologies, and from that of the 
software/hardware implementation.


Therefore, we would like to solicit network operators interested in SR over the 
IPv6 data plane to briefly introduce their:

  *
  *   use case (e.g. Fast Reroute, explicit routing/TE)
  *
  *
  *   forwarding performance and scaling requirements
  *

 *
 *   e.g., (number of nodes, network diameter,
 *   number of SID required in max and average). For the latter, if 
possible using both SRv6 128-bit SIDs and shorter (e.g. 32-bit) SIDs as the 
number would typically be different (*).
 *

  *
  *   if the existing SRv6 approach is not deployable
  *   in their circumstances, details of the requirement of a different 
solution is required and whether this solution is needed for the short term 
only or for the long term.
  *


As well as deployment limitations, we would like the SPRING community to 
briefly describe the platform limitations that they are seeing which limit the 
deployment of SRv6  In particular limitations related to the number of SIDs 
which can be pushed and forwarded and how much the use of shorter SIDs would 
improve the deployments .


For both of these sets of feedback if possible, please post this to the SPRING 
WG. If the information cannot be shared publicly, please send it directly to 
the chairs & AD (Martin).


This call for information will run for four weeks, up to 2019/09/03. As a 
reminder, you can reach the SPRING chairs via 
spring-cha...@ietf.org and ADs via 
spring-...@ietf.org.


Thank you,

-- Rob & Bruno


(*) As expressed on the mailing list, a 128 bit SID can encode two instructions 
a node SID and an adjacency SID hence less SID may be required.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Andrew Alston]

Just another note on clashes – any company that deals with constant and 
frequent merges and acquisitions will know – uniqueness is paramount – unless 
you want integration headaches that will cause you weeks of sleepness nights.

And when you’re doing 3 or 4 M’s a year – this is very very very important

Andrew


From: spring  on behalf of Nick Hilliard 

Date: Monday, 2 September 2019 at 16:28
To: Robert Raszuk 
Cc: Ron Bonica , SPRING WG List 
, "6...@ietf.org" <6...@ietf.org>, Mark Smith 
, Rob Shakir , Fernando Gont 

Subject: Re: [spring] Beyond SRv6.

Robert Raszuk wrote on 02/09/2019 12:49:
> Yes you are 100% correct.
>
> The decision to inject any prefix into someone's IGP (or BGP) is a local
> operator's decision.

It is, and most operators take pains to avoid injecting shared
addressing resources into their routing domains. These days it usually
relates to policy, but that policy is rooted in the painful reality that
building infrastructure intended for second or third party tenancy on
the basis of overlapping number resources is something that can and will
cause catastrophic architectural problems once clashes occur.

So again, I suggest that if it's the intention for the draft to proceed,
the authors will need to reach out to RIR policy working groups because
the additional number resource requirements required do not fit in with
the current ipv6 resource assignment and allocation policies currently
in place.

Nick

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Nick Hilliard]

Robert Raszuk wrote on 02/09/2019 12:49:

Yes you are 100% correct.

The decision to inject any prefix into someone's IGP (or BGP) is a local 
operator's decision.


It is, and most operators take pains to avoid injecting shared 
addressing resources into their routing domains.  These days it usually 
relates to policy, but that policy is rooted in the painful reality that 
building infrastructure intended for second or third party tenancy on 
the basis of overlapping number resources is something that can and will 
cause catastrophic architectural problems once clashes occur.


So again, I suggest that if it's the intention for the draft to proceed, 
the authors will need to reach out to RIR policy working groups because 
the additional number resource requirements required do not fit in with 
the current ipv6 resource assignment and allocation policies currently 
in place.


Nick

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Voyer, Daniel]

Hi,

I agree with Dirk. The SRv6 fulfills our requirements for vast majority of our 
use-cases. For some use cases requiring MTU efficiency, we have SRv6 uSID 
segments that are just a different pseudo code and is fully integrated with SRH.

I also concur, there is no need for the work group for define a new extension 
header.

Thanks,
dan

From: spring  on behalf of Dirk Steinberg 

Date: Sunday, September 1, 2019 at 10:20 AM
To: SPRING WG List , Rob Shakir 

Subject: [EXT]Re: [spring] Beyond SRv6.

Hi,

the introduction of SRv6 as alternate data plane in addition to MPLS
has been an important step in SPRING, providing an encapsulation
for SPRING traffic that is native to IPv6.

The question about the necessity of work on alternate encapsulations
was fueled by concerns about encapsulation overhead when using
full 128 bit SIDs in the SRv6 SRH.

Through the introduction of the uSID network instruction in SRv6
these concerns are now properly addressed and SRv6 with uSID
can now also be deployed in a very MTU-efficient manner.

Therefore I do not see a necessity for any additional encapsulations.

Cheers
Dirk

Am 31.08.2019 um 06:05 schrieb Zafar Ali (zali) 
mailto:z...@cisco.com>>:

Dear Chairs and the WG:

The SRv6 network programming solution and its SRH encapsulation is implemented 
on 12 hardware platforms including Merchant Silicon.
Multiple providers have deployed the SRv6 network programming solution and its 
SRH encapsulation with line-rate performance carrying a significant amount of 
commercial traffic.
Several independent interoperability reports documenting successful 
interoperability of implementation from multiple vendors exist.
Implementation, deployment, and interoperability status is publicly documented 
in 
https://www.ietf.org/id/draft-matsushima-spring-srv6-deployment-status-01.txt.

Most use-cases are expected to use very few SRv6 segments.

In some specific use-cases, one may desire to optimize the MTU usage further.
The SRv6 network programming solution and its SRH encapsulation also support 
for this Optimization, through the uSID network instruction.

I do not see the need for any new encapsulation work.

Thanks

Regards … Zafar

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Rob Shakir 
mailto:robjs=40google@dmarc.ietf.org>>
Date: Sunday, August 4, 2019 at 5:04 PM
To: SPRING WG List mailto:spring@ietf.org>>
Subject: [spring] Beyond SRv6.

Hi SPRING WG,

Over the last 5+ years, the IETF has developed Source Packet Routing in 
NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6 
(SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE.

These encapsulations are past WG last call (in IESG or RFC Editor).

During the SPRING WG meeting at IETF 105, two presentations were related to the 
reduction of the size of the SID for IPv6 dataplane:

  *
  *   SRv6+ / CRH --
  *   https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04
  *
  *
  *   uSID --
  *   
https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01
  *

During the IETF week, two additional drafts have been proposed:

  *
  *   https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00
  *
  *
  *   https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03
  *

As we expressed during the meeting, it is important for the WG to understand 
what the aims of additional encapsulations are. Thus, we think it is important 
that the WG should first get to a common understanding on the requirements for 
a new IPv6 data plane with a smaller SID - both from the perspective of 
operators that are looking to deploy these technologies, and from that of the 
software/hardware implementation.

Therefore, we would like to solicit network operators interested in SR over the 
IPv6 data plane to briefly introduce their:

  *
  *   use case (e.g. Fast Reroute, explicit routing/TE)
  *
  *
  *   forwarding performance and scaling requirements
  *

 *
 *   e.g., (number of nodes, network diameter,
 *   number of SID required in max and average). For the latter, if 
possible using both SRv6 128-bit SIDs and shorter (e.g. 32-bit) SIDs as the 
number would typically be different (*).
 *

  *
  *   if the existing SRv6 approach is not deployable
  *   in their circumstances, details of the requirement of a different 
solution is required and whether this solution is needed for the short term 
only or for the long term.
  *

As well as deployment limitations, we would like the SPRING community to 
briefly describe the platform limitations that they are seeing which limit the 
deployment of SRv6  In particular limitations related to the number of SIDs 
which can be pushed and forwarded and how much the use of shorter SIDs would 
improve the deployments .

For both of these sets of feedback if possible, please post this to the SPRING 
WG. If the information cannot be shared publicly, please send it directly to 

Re: [spring] Beyond SRv6.

[Ron Bonica]

Rob,

There may be an elephant in the room that needs addressing

Over the years, the IPv6 community has specified a very tight architecture that 
encodes some information in IPv6 addresses, other information in Routing 
headers, and still other information in Destination Options headers. SRv6+ 
adheres strictly to this architecture. Because it reuses IPv6 machinery, its 
specification promises it be painless and its deployment promises to be safe. 
To date, there has been no significant technical criticism of SRv6+.. Only a 
claim that SRv6 is nearly complete and good enough. (Both of those claims may 
require scrutiny).

By contrast, SRv6 varies from the spirit, if not the letter of the IPv6 
architecture. It encodes things in IPv6 address that have never been encoded in 
IPv6 addresses before. It attempts to encode everything else in the Routing 
header, as if the other IPv6 extension headers didn't exist. It frequently 
tests the limits of RFC 8200 compliance.

This creates a situation in which each variance from IPv6 orthodoxy requires 
another. For example, because SRv6 encodes instructions in IPv6 addresses, 
draft-ali-6man-spring-srv6-oam is required. And now, 
draft-ali-6man-spring-srv6-oam creates its own variances from the IPv6 
orthodoxy. OAM information is encoded in the Routing header and the Routing 
header must be examined, even when Segment Left is equal to zero.

I invite everyone to consider how TI-LFA an uSID will interact.

So, why would the IETF would want to prevent work on the more conservative, 
SRv6+ approach?  This brings us to the back to the elephant in the room..

Until very recently, relatively few router vendors have supported IPv6 
extension headers in ASICs. If an IPv6 packet contained any extension headers 
at all, it was sent to the slow path.

SRv6+ encourages router vendors to support both the Routing and Destination 
Options header in ASICs. This sets vendors on a path on a path towards more 
complete implementation of the architecture that the IPv6 community has 
developed so carefully over the years. It encourages vendors to commit more and 
more of RFC 8200 to ASICs.

SRv6 encourages router vendors to support the Routing header in ASICs, while 
doing everything possible to mitigate the need to support Destination Options 
in ASICs. This may be a necessary expedient for many platforms. However, it 
should not be the only approach, or even the long-term approach for the IETF.


   Ron




From: spring  On Behalf Of Rob Shakir
Sent: Sunday, August 4, 2019 5:04 PM
To: SPRING WG List 
Subject: [spring] Beyond SRv6.


Hi SPRING WG,


Over the last 5+ years, the IETF has developed Source Packet Routing in 
NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6 
(SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE.


These encapsulations are past WG last call (in IESG or RFC Editor).


During the SPRING WG meeting at IETF 105, two presentations were related to the 
reduction of the size of the SID for IPv6 dataplane:

  *   SRv6+ / CRH -- 
https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04
  *   uSID -- 
https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01


During the IETF week, two additional drafts have been proposed:

  *   
https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00
  *   
https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03


As we expressed during the meeting, it is important for the WG to understand 
what the aims of additional encapsulations are. Thus, we think it is important 
that the WG should 

Re: [spring] Beyond SRv6.

[Darren Dukes (ddukes)]

Let’s not forget the SRv6 ecosystem includes several open-source implementations

• Linux: Kernel and srext module
• FD.io: VPP
• Apps: Snort, iptables and nftables, tcpdump and Wireshark.

Thanks,

  Darren

On Aug 31, 2019, at 12:06 AM, Zafar Ali (zali) 
mailto:z...@cisco.com>> wrote:

Dear Chairs and the WG:

The SRv6 network programming solution and its SRH encapsulation is implemented 
on 12 hardware platforms including Merchant Silicon.
Multiple providers have deployed the SRv6 network programming solution and its 
SRH encapsulation with line-rate performance carrying a significant amount of 
commercial traffic.
Several independent interoperability reports documenting successful 
interoperability of implementation from multiple vendors exist.
Implementation, deployment, and interoperability status is publicly documented 
in 
https://www.ietf.org/id/draft-matsushima-spring-srv6-deployment-status-01.txt.

Most use-cases are expected to use very few SRv6 segments.

In some specific use-cases, one may desire to optimize the MTU usage further.
The SRv6 network programming solution and its SRH encapsulation also support 
for this Optimization, through the uSID network instruction.

I do not see the need for any new encapsulation work.

Thanks

Regards … Zafar

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Rob Shakir 
mailto:robjs=40google@dmarc.ietf.org>>
Date: Sunday, August 4, 2019 at 5:04 PM
To: SPRING WG List mailto:spring@ietf.org>>
Subject: [spring] Beyond SRv6.


Hi SPRING WG,


Over the last 5+ years, the IETF has developed Source Packet Routing in 
NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6 
(SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE.


These encapsulations are past WG last call (in IESG or RFC Editor).


During the SPRING WG meeting at IETF 105, two presentations were related to the 
reduction of the size of the SID for IPv6 dataplane:

  *
  *   SRv6+ / CRH --
  *   https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04
  *
  *
  *   uSID --
  *   
https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01
  *


During the IETF week, two additional drafts have been proposed:

  *
  *   https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00
  *
  *
  *   https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03
  *


As we expressed during the meeting, it is important for the WG to understand 
what the aims of additional encapsulations are. Thus, we think it is important 
that the WG should first get to a common understanding on the requirements for 
a new IPv6 data plane with a smaller SID - both from the perspective of 
operators that are looking to deploy these technologies, and from that of the 
software/hardware implementation.


Therefore, we would like to solicit network operators interested in SR over the 
IPv6 data plane to briefly introduce their:

  *
  *   use case (e.g. Fast Reroute, explicit routing/TE)
  *
  *
  *   forwarding performance and scaling requirements
  *

 *
 *   e.g., (number of nodes, network diameter,
 *   number of SID required in max and average). For the latter, if 
possible using both SRv6 128-bit SIDs and shorter (e.g. 32-bit) SIDs as the 
number would typically be different (*).
 *

  *
  *   if the existing SRv6 approach is not deployable
  *   in their circumstances, details of the requirement of a different 
solution is required and whether this solution is needed for the short term 
only or for the long term.
  *


As well as deployment limitations, we would like the SPRING community to 
briefly describe the platform limitations that they are seeing which limit the 
deployment of SRv6  In particular limitations related to the number of SIDs 
which can be pushed and forwarded and how much the use of shorter SIDs would 
improve the deployments .


For both of these sets of feedback if possible, please post this to the SPRING 
WG. If the information cannot be shared publicly, please send it directly to 
the chairs & AD (Martin).


This call for information will run for four weeks, up to 2019/09/03. As a 
reminder, you can reach the SPRING chairs via 
spring-cha...@ietf.org and ADs via 
spring-...@ietf.org.


Thank you,

-- Rob & Bruno


(*) As expressed on the mailing list, a 128 bit SID can encode two instructions 
a node SID and an adjacency SID hence less SID may be required.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Robert Raszuk]

Hey Mark,

 I think the only place you can put uSIDs is in the IID field, and I went
> to the effort of providing RFC references.
>

I only tend to follow the rules which make sense or which violation even if
they do not make sense goes against best practices, common rules or could
endanger anyone or anything. RFCs you quote do not limit numer of ULAs to
be one per network or even one per person - so I am not breaking any RFC if
I use bunch of ULAs as it seems fit.

When SPRING comes up with an out of the ordinary idea
>

This is far beyond SPRING topic. Operators and end users use RFC1918
everywhere as it gives them freedom and flexibility to construct
their networks the way they like it. Sufficiently flexible min /8 private
range must be made available for anyone's use if you want to see wider IPv6
adoption. And /8 as proven is not about need for 2^112 addresses - it's
about constructing your network applications with well though addressing
structure and hierarchy.

This draft and the EH insertion draft show that this isn't and hasn't
> happened.
>

I am not going to comment on the insertion part beyond the observation that
when you apply new IPv6 header you are free to insert whatever you like
into it. Likewise per RFC8200 when I see myself in destination address
field of the outer IPv6 header I can process, insert or delete EHs as it
seems fit.

   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) *identified in the Destination Address field
   of the IPv6 header.*


I do not see any stretch of it in any SPRING related document.

Best,
R.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Nick Hilliard]

Robert Raszuk wrote on 02/09/2019 12:09:
If that is the only concern I think we are done then. The only issue is 
that if you happen to have hierarchical IGP you will not be able to 
summarize them - but I don't think that this would be a showstopper to 
any deployment.


Robert,

please correct me if I'm wrong but uSIDs would need to be injected into 
the provider's routing tables, so your suggestion that ULAs would be 
appropriate for the srv6-usid draft would be contingent on SRv6 
providers being ok about the idea of injecting ULAs into their core.


I'm not sure that this would necessarily be the case.

Nick

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Robert Raszuk]

Hi Nick,

Yes you are 100% correct.

The decision to inject any prefix into someone's IGP (or BGP) is a local
operator's decision.

Btw let me also self correct last note - It is actually pretty trivial to
pseudo-random generate ULAs such that blocks of it can actually be
aggregatable across areas or levels. It is just that such one time run
generation perl or python script will run a little bit longer :)

Cheers,
R.

On Mon, Sep 2, 2019 at 1:31 PM Nick Hilliard  wrote:

> Robert Raszuk wrote on 02/09/2019 12:09:
> > If that is the only concern I think we are done then. The only issue is
> > that if you happen to have hierarchical IGP you will not be able to
> > summarize them - but I don't think that this would be a showstopper to
> > any deployment.
>
> Robert,
>
> please correct me if I'm wrong but uSIDs would need to be injected into
> the provider's routing tables, so your suggestion that ULAs would be
> appropriate for the srv6-usid draft would be contingent on SRv6
> providers being ok about the idea of injecting ULAs into their core.
>
> I'm not sure that this would necessarily be the case.
>
> Nick
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Mark Smith]

On Mon., 2 Sep. 2019, 21:09 Robert Raszuk,  wrote:

>
> > Are uSID values going to be entirely pseudo-random?
>
> I see no reason why not ...
>
> Networks are managed by some form of NMS. NMS can generate such values and
> abstract it with a "node_name_usid" string for any additional processing
> and human abstraction.
>
> If that is the only concern I think we are done then.
>

No. You haven't dealt with the other issues I've highlighted in the email
link I provided earlier. As I pointed out there, I think the only place you
can put uSIDs is in the IID field, and I went to the effort of providing
RFC references.

I'm getting off this merry go round. When SPRING comes up with an out of
the ordinary idea, the first thing to do is check the IPv6 RFCs to see if
they will accommodate the idea.

This draft and the EH insertion draft show that this isn't and hasn't
happened.



The only issue is that if you happen to have hierarchical IGP you will not
> be able to summarize them - but I don't think that this would be a
> showstopper to any deployment.
>
> Best,
> R.
>
>
>
>
>
> On Mon, Sep 2, 2019 at 12:24 PM Mark Smith  wrote:
>
>>
>>
>> On Mon., 2 Sep. 2019, 17:58 Robert Raszuk,  wrote:
>>
>>> Hi Mark,
>>>
>>>
 The uSID proposal is taking the position that all the bits after the
 high order prefix are available for any purpose. This is not correct, and
 would violate a number of standards track RFCs, including the IPv6
 Addressing Architecture RFC (RFC 4291) and the ULA RFC (RFC 4193).

 In particular, 40 bits of a ULA prefix, between /8 and /48, the Gobal
 ID, must be pseudo random. This is the most critical property of ULA
 addresses and prefixes, as it is the solution to the problem ULAs are
 designed to solve.

>>>
>>> RFC 4193 says about Global_ID allocation:
>>>
>>>The local assignments are self-generated and do not need any central
>>>coordination or assignment, but have an extremely high probability of
>>>being unique.
>>>
>>>
>> Are uSID values going to be entirely pseudo-random?
>>
>> "
>>
>> 3.2.1 .  Locally Assigned 
>> Global IDs
>>
>>Locally assigned Global IDs MUST be generated with a pseudo-random
>>algorithm consistent with [RANDOM 
>> ]."
>>
>>
>>
>>> So in some the case operator may choose to make such "local assignment"
>>> of Global ID to be per router not per network. And that is all what is
>>> needed for uSID. uSID address blocks does not need to be continues.
>>>
>>> It also does not contradict with any RFC does it ? What breaks if I use
>>> more then one self generated Global ID in my network ?
>>>
>>> Note that the above question goes way beyond any SR related discussion
>>> so perhaps deserves a separate 6man thread.
>>>
>>> Best,
>>> R.
>>>
>>>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Robert Raszuk]

> Are uSID values going to be entirely pseudo-random?

I see no reason why not ...

Networks are managed by some form of NMS. NMS can generate such values and
abstract it with a "node_name_usid" string for any additional processing
and human abstraction.

If that is the only concern I think we are done then. The only issue is
that if you happen to have hierarchical IGP you will not be able to
summarize them - but I don't think that this would be a showstopper to any
deployment.

Best,
R.





On Mon, Sep 2, 2019 at 12:24 PM Mark Smith  wrote:

>
>
> On Mon., 2 Sep. 2019, 17:58 Robert Raszuk,  wrote:
>
>> Hi Mark,
>>
>>
>>> The uSID proposal is taking the position that all the bits after the
>>> high order prefix are available for any purpose. This is not correct, and
>>> would violate a number of standards track RFCs, including the IPv6
>>> Addressing Architecture RFC (RFC 4291) and the ULA RFC (RFC 4193).
>>>
>>> In particular, 40 bits of a ULA prefix, between /8 and /48, the Gobal
>>> ID, must be pseudo random. This is the most critical property of ULA
>>> addresses and prefixes, as it is the solution to the problem ULAs are
>>> designed to solve.
>>>
>>
>> RFC 4193 says about Global_ID allocation:
>>
>>The local assignments are self-generated and do not need any central
>>coordination or assignment, but have an extremely high probability of
>>being unique.
>>
>>
> Are uSID values going to be entirely pseudo-random?
>
> "
>
> 3.2.1 .  Locally Assigned 
> Global IDs
>
>Locally assigned Global IDs MUST be generated with a pseudo-random
>algorithm consistent with [RANDOM 
> ]."
>
>
>
>> So in some the case operator may choose to make such "local assignment"
>> of Global ID to be per router not per network. And that is all what is
>> needed for uSID. uSID address blocks does not need to be continues.
>>
>> It also does not contradict with any RFC does it ? What breaks if I use
>> more then one self generated Global ID in my network ?
>>
>> Note that the above question goes way beyond any SR related discussion so
>> perhaps deserves a separate 6man thread.
>>
>> Best,
>> R.
>>
>>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Mark Smith]

On Mon., 2 Sep. 2019, 17:58 Robert Raszuk,  wrote:

> Hi Mark,
>
>
>> The uSID proposal is taking the position that all the bits after the high
>> order prefix are available for any purpose. This is not correct, and would
>> violate a number of standards track RFCs, including the IPv6 Addressing
>> Architecture RFC (RFC 4291) and the ULA RFC (RFC 4193).
>>
>> In particular, 40 bits of a ULA prefix, between /8 and /48, the Gobal ID,
>> must be pseudo random. This is the most critical property of ULA addresses
>> and prefixes, as it is the solution to the problem ULAs are designed to
>> solve.
>>
>
> RFC 4193 says about Global_ID allocation:
>
>The local assignments are self-generated and do not need any central
>coordination or assignment, but have an extremely high probability of
>being unique.
>
>
Are uSID values going to be entirely pseudo-random?

"

3.2.1 .  Locally
Assigned Global IDs

   Locally assigned Global IDs MUST be generated with a pseudo-random
   algorithm consistent with [RANDOM
]."



> So in some the case operator may choose to make such "local assignment" of
> Global ID to be per router not per network. And that is all what is needed
> for uSID. uSID address blocks does not need to be continues.
>
> It also does not contradict with any RFC does it ? What breaks if I use
> more then one self generated Global ID in my network ?
>
> Note that the above question goes way beyond any SR related discussion so
> perhaps deserves a separate 6man thread.
>
> Best,
> R.
>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Robert Raszuk]

Hi Mark,


> The uSID proposal is taking the position that all the bits after the high
> order prefix are available for any purpose. This is not correct, and would
> violate a number of standards track RFCs, including the IPv6 Addressing
> Architecture RFC (RFC 4291) and the ULA RFC (RFC 4193).
>
> In particular, 40 bits of a ULA prefix, between /8 and /48, the Gobal ID,
> must be pseudo random. This is the most critical property of ULA addresses
> and prefixes, as it is the solution to the problem ULAs are designed to
> solve.
>

RFC 4193 says about Global_ID allocation:

   The local assignments are self-generated and do not need any central
   coordination or assignment, but have an extremely high probability of
   being unique.


So in some the case operator may choose to make such "local assignment" of
Global ID to be per router not per network. And that is all what is needed
for uSID. uSID address blocks does not need to be continues.

It also does not contradict with any RFC does it ? What breaks if I use
more then one self generated Global ID in my network ?

Note that the above question goes way beyond any SR related discussion so
perhaps deserves a separate 6man thread.

Best,
R.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Joel M. Halpern]

The introduction of alternatives was prompted by a number of concerns, 
not just the encapsulation overhead.
Having said that, we as a group have not adopted the uSID approach, and 
many of us have serious concerns about that.  Claiming that uSID is 
agreed and solves the size problems seems not to align with my 
understanding of the situation.


Yours,
Joel

On 9/1/2019 10:20 AM, Dirk Steinberg wrote:

Hi,

the introduction of SRv6 as alternate data plane in addition to MPLS
has been an important step in SPRING, providing an encapsulation
for SPRING traffic that is native to IPv6.

The question about the necessity of work on alternate encapsulations
was fueled by concerns about encapsulation overhead when using
full 128 bit SIDs in the SRv6 SRH.

Through the introduction of the uSID network instruction in SRv6
these concerns are now properly addressed and SRv6 with uSID
can now also be deployed in a very MTU-efficient manner.

Therefore I do not see a necessity for any additional encapsulations.

Cheers
Dirk

Am 31.08.2019 um 06:05 schrieb Zafar Ali (zali) >:


Dear Chairs and the WG:
The SRv6 network programming solution and its SRH encapsulation is 
implemented on 12 hardware platforms including Merchant Silicon.
Multiple providers have deployed the SRv6 network programming solution 
and its SRH encapsulation with line-rate performance carrying a 
significant amount of commercial traffic.
Several independent interoperability reports documenting successful 
interoperability of implementation from multiple vendors exist.
Implementation, deployment, and interoperability status is publicly 
documented 
inhttps://www.ietf.org/id/draft-matsushima-spring-srv6-deployment-status-01.txt.

Most use-cases are expected to use very few SRv6 segments.
In some specific use-cases, one may desire to optimize the MTU usage 
further.
The SRv6 network programming solution and its SRH encapsulation also 
support for this Optimization, through the uSID network instruction.

I do not see the need for any new encapsulation work.
Thanks
Regards … Zafar
*From:*spring > on behalf of Rob Shakir 
>

*Date:*Sunday, August 4, 2019 at 5:04 PM
*To:*SPRING WG List mailto:spring@ietf.org>>
*Subject:*[spring] Beyond SRv6.
Hi SPRING WG,
Over the last 5+ years, the IETF has developed Source Packet Routing 
in NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) 
and IPv6 (SRv6) data planes. SR-MPLS may also be transported over IP 
in UDP or GRE.

These encapsulations are past WG last call (in IESG or RFC Editor).
During the SPRING WG meeting at IETF 105, two presentations were 
related to the reduction of the size of the SID for IPv6 dataplane:


 *
  * SRv6+ / CRH --
  * https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04
 *
 *
  * uSID --
  * 
https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01

*

During the IETF week, two additional drafts have been proposed:

 *
  * https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00
 *
 *
  * https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03
*

As we expressed during the meeting, it is important for the WG to 
understand what the aims of additional encapsulations are. Thus, we 
think it is important that the WG should first get to a common 
understanding on the requirements for a new IPv6 data plane with a 
smaller SID - both from the perspective of operators that are looking 
to deploy these technologies, and from that of the software/hardware 
implementation.
Therefore, we would like to solicit network operators interested in SR 
over the IPv6 data plane to briefly introduce their:


 *
  * use case (e.g. Fast Reroute, explicit routing/TE)
 *
 *
  * forwarding performance and scaling requirements
*

 o
  o e.g., (number of nodes, network diameter,
  o number of SID required in max and average). For the latter, if
possible using both SRv6 128-bit SIDs and shorter (e.g.
32-bit) SIDs as the number would typically be different (*).
o

 *
  * if the existing SRv6 approach is not deployable
  * in their circumstances, details of the requirement of a different
solution is required and whether this solution is needed for the
short term only or for the long term.
*

As well as deployment limitations, we would like the SPRING community 
to briefly describe the platform limitations that they are seeing 
which limit the deployment of SRv6  In particular limitations related 
to the number of SIDs which can be pushed and forwarded and how much 
the use of shorter SIDs would improve the deployments .
For both of these sets of feedback if possible, please post this to 
the SPRING WG. If the information cannot be shared publicly, please 
send it directly to the chairs & AD (Martin).
This call for information will run for four weeks, up to 2019/09/03. 
As a reminder, you can reach the SPRING chairs 

Re: [spring] Beyond SRv6.

[Mark Smith]

On Mon., 2 Sep. 2019, 07:56 Robert Raszuk,  wrote:

>
> Yes Ron I saw this message from Bob and as you see from the mailer I
> responded with clarification on why this is not 2^112.
>
> While I do not understand why ULAs blocks must be globally unique (to me
> this is analogy of RFC1918 :)
>

RFC 3879, "Deprecating Site Local Addresses"



there are few more options on the table on what blocks to use for uSIDs
> addressing.
>

> Thx,
> R.
>
>
> On Sun, Sep 1, 2019 at 11:48 PM Ron Bonica  40juniper@dmarc.ietf.org> wrote:
>
>> Robert,
>>
>>
>>
>> Please see
>> https://mailarchive.ietf.org/arch/browse/spring/?gbt=1=BPXFbv5drFqv7k7nPIN3SDuifo0
>> .
>>
>>
>>
>> Ron
>>
>
>
>> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Mark Smith]

On Mon., 2 Sep. 2019, 07:30 Andrew Alston, 
wrote:

> Robert,
>
>
>
> CRH works just fine with the deep label depth in our testing of it.  As I
> stated in my previous emails – There are a number of issues with uSID that
> I can see – and I won’t repeat all of those here again.  There are a whole
> number of aspects going through that network map that do not give a full
> picture – multiple paths of unequal sizes – multiple circuits between
> locations that aren’t clearly shown there for diversity sake – and a whole
> heap of other issues.  You need to realize that steering in our case is not
> just about diversity – there are many reasons why we steer and why our
> customers wish us to steer – and glancing at a network map like that will
> not give you close to a full picture.  Those reasons can range from
> everything from latency to geopolitical issues.
>
>
>
> Then again – as an operator – I have always believed in having the choice
> – and as I stated in previous emails – in the networking world we have many
> alternatives to many things
>

Too much choice is a bad thing, because there is then too greater risk of
making a wrong choice. The least risky choice becomes make no choice.


– and I went as far as to propose writing an inter-op draft so that both
> CRH and uSID could move forward rather than both ending up stalled, or
> worse will, one or the other ending up as proprietary –
>
These are the sorts of problems you'll see with no clear consensus in a
single solution to a problem.

RFC 1958, "Architectural Principles of the Internet",

"3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements."


and I may well still get around to doing this – time has just been a little
> hectic of late.
>
>
>
> Andrew
>
> *From: *Robert Raszuk 
> *Date: *Sunday, 1 September 2019 at 22:28
> *To: *Andrew Alston 
> *Cc: *Ron Bonica , Rob Shakir <
> ro...@google.com>, SPRING WG List , "6...@ietf.org" <
> 6...@ietf.org>
> *Subject: *Re: [spring] Beyond SRv6.
>
>
>
> Hi Andrew,
>
>
>
> Looking at your network topology
> https://www.liquidtelecom.com/about-us/network-map.html yes indeed you
> need to pass via number of countries, but keep in mind that SR is not a
> routing protocol.
>
>
>
> Even focusing on your longest data paths say from Cairo to Cape Town I
> really see no use for more then optimally chosen 3 or 4 SIDs to well
> diversify the flows to traverse different end to end paths then your routed
> default.
>
>
>
> Now if your desire is to provide for all the possible data flows per each
> ECMP link group forwarding control then I see counting adj SIDs you can get
> to 10 SIDs or more. But is SRv6 then optimal tool in the toolkit to
> accomplish that ?
>
>
>
> But assume it is how about use of uSID combination with SRH such that you
> can have your requirements well satisfied in the current network regardless
> if alternative design or alternate network architecture exists or not ?
>
>
>
> Thx,
>
> Robert.
>
>
>
>
>
> On Sun, Sep 1, 2019 at 9:47 PM Andrew Alston <
> andrew.als...@liquidtelecom.com> wrote:
>
> I can state categorically that we have a solid case to use 8 to 12 SID’s –
>
>
>
> Let me put it this way – If I cross my own network – To get to certain
> countries I have to pass through no less than 5 separate countries in
> certain scenarios – and it’s not practically possible to avoid this.  When
> I add the various paths we need to steer across and the numbers of devices
> to do this in a granular way – with the amount of meshing we have to do to
> achieve redundancy – yes – it gets complex – and yes – the node depth gets
> deep.
>
>
>
> Our case of needing granular steering here – without necessarily going
> lose – is ironclad – and I can say that right now, 10 node steering for
> certain cases is 100% a reality for what we need.
>
>
>
> Andrew
>
>
>
>
>
> *From: *spring  on behalf of Ron Bonica  40juniper@dmarc.ietf.org>
> *Date: *Sunday, 1 September 2019 at 21:00
> *To: *Robert Raszuk 
> *Cc: *Rob Shakir , SPRING WG List , "
> 6...@ietf.org" <6...@ietf.org>
> *Subject: *Re: [spring] Beyond SRv6.
>
>
>
> Robert,
>
>
>
> I can only repeat what my customers’ requirements. They have asked for
> 8-12 SIDs in SR-MPLS and SRv

Re: [spring] Beyond SRv6.

[Mark Smith]

On Mon., 2 Sep. 2019, 07:39 Robert Raszuk,  wrote:

> Nick,
>
> How about using ULAs as defined in RFC4193 ?
>

I've analysed uSID in the context of all current IPv6 unicast address
formats in this email.

https://mailarchive.ietf.org/arch/msg/spring/Gsr-nJqzhyYIrj8mG6p3KZ_HZ5E

Short answer is you can only put uSIDs in the IID portion of any of those
address formats, and must also ensure that the resulting IID value formed
from the set of uSID values don't also match the reserved IID values.

The uSID proposal is taking the position that all the bits after the high
order prefix are available for any purpose. This is not correct, and would
violate a number of standards track RFCs, including the IPv6 Addressing
Architecture RFC (RFC 4291) and the ULA RFC (RFC 4193).

In particular, 40 bits of a ULA prefix, between /8 and /48, the Gobal ID,
must be pseudo random. This is the most critical property of ULA addresses
and prefixes, as it is the solution to the problem ULAs are designed to
solve.


3.2 .  Global ID

   The allocation of Global IDs is pseudo-random [RANDOM
].  They MUST
   NOT be assigned sequentially or with well-known numbers.  This is to
   ensure that there is not any relationship between allocations and to
   help clarify that these prefixes are not intended to be routed
   globally.  Specifically, these prefixes are not designed to
   aggregate.



> After all isn't local IPv6 FC00::/7 address block defined precisely for
> such private use cases like the one which uSID requires?
>
> Clearly RIRs will not allocate /22 blocks left and right and that v6
> prefix would be required if I have 1000 node network and my uSID is /32.
>
> Thx,
> R.
>
>
> On Sun, Sep 1, 2019 at 11:33 PM Nick Hilliard  wrote:
>
>> Ron Bonica wrote on 01/09/2019 22:10:
>> > -
>> https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02
>>
>> Ron,
>>
>> if this draft proposes using up to /32 per router in a SRv6 domain, or
>> even /40 to /48, it may be appropriate to solicit input from RIR address
>> policy groups about the impact this may have on ipv6 assignment /
>> allocation policies.
>>
>> Nick
>>
>> ___
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[James Guichard]

There are a number of techniques that could be used to reduce the depth without 
having to resort to a new encapsulation beyond SRv6; uSID is one of course, but 
there is also https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00 
and we could probably find others if those do not suffice.

Jim

From: spring  On Behalf Of Andrew Alston
Sent: Sunday, September 01, 2019 5:30 PM
To: Robert Raszuk 
Cc: Ron Bonica ; Rob Shakir 
; SPRING WG List ; 6...@ietf.org
Subject: Re: [spring] Beyond SRv6.

Robert,

CRH works just fine with the deep label depth in our testing of it.  As I 
stated in my previous emails – There are a number of issues with uSID that I 
can see – and I won’t repeat all of those here again.  There are a whole number 
of aspects going through that network map that do not give a full picture – 
multiple paths of unequal sizes – multiple circuits between locations that 
aren’t clearly shown there for diversity sake – and a whole heap of other 
issues.  You need to realize that steering in our case is not just about 
diversity – there are many reasons why we steer and why our customers wish us 
to steer – and glancing at a network map like that will not give you close to a 
full picture.  Those reasons can range from everything from latency to 
geopolitical issues.

Then again – as an operator – I have always believed in having the choice – and 
as I stated in previous emails – in the networking world we have many 
alternatives to many things – and I went as far as to propose writing an 
inter-op draft so that both CRH and uSID could move forward rather than both 
ending up stalled, or worse will, one or the other ending up as proprietary – 
and I may well still get around to doing this – time has just been a little 
hectic of late.

Andrew

From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Sunday, 1 September 2019 at 22:28
To: Andrew Alston 
mailto:andrew.als...@liquidtelecom.com>>
Cc: Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>,
 Rob Shakir mailto:ro...@google.com>>, SPRING WG List 
mailto:spring@ietf.org>>, 
"6...@ietf.org<mailto:6...@ietf.org>" <6...@ietf.org<mailto:6...@ietf.org>>
Subject: Re: [spring] Beyond SRv6.

Hi Andrew,

Looking at your network topology 
https://www.liquidtelecom.com/about-us/network-map.html<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.liquidtelecom.com%2Fabout-us%2Fnetwork-map.html=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cf0a022c330834a1e566608d72f239a10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637029702293736173=hYeOsxSIOnzzty%2FxD3XK%2FanUUKvPzu7UyP%2F3VWM1Kl0%3D=0>
 yes indeed you need to pass via number of countries, but keep in mind that SR 
is not a routing protocol.

Even focusing on your longest data paths say from Cairo to Cape Town I really 
see no use for more then optimally chosen 3 or 4 SIDs to well diversify the 
flows to traverse different end to end paths then your routed default.

Now if your desire is to provide for all the possible data flows per each ECMP 
link group forwarding control then I see counting adj SIDs you can get to 10 
SIDs or more. But is SRv6 then optimal tool in the toolkit to accomplish that ?

But assume it is how about use of uSID combination with SRH such that you can 
have your requirements well satisfied in the current network regardless if 
alternative design or alternate network architecture exists or not ?

Thx,
Robert.


On Sun, Sep 1, 2019 at 9:47 PM Andrew Alston 
mailto:andrew.als...@liquidtelecom.com>> wrote:
I can state categorically that we have a solid case to use 8 to 12 SID’s –

Let me put it this way – If I cross my own network – To get to certain 
countries I have to pass through no less than 5 separate countries in certain 
scenarios – and it’s not practically possible to avoid this.  When I add the 
various paths we need to steer across and the numbers of devices to do this in 
a granular way – with the amount of meshing we have to do to achieve redundancy 
– yes – it gets complex – and yes – the node depth gets deep.

Our case of needing granular steering here – without necessarily going lose – 
is ironclad – and I can say that right now, 10 node steering for certain cases 
is 100% a reality for what we need.

Andrew


From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Ron Bonica 
mailto:40juniper@dmarc.ietf.org>>
Date: Sunday, 1 September 2019 at 21:00
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Rob Shakir mailto:ro...@google.com>>, SPRING WG List 
mailto:spring@ietf.org>>, 
"6...@ietf.org<mailto:6...@ietf.org>" <6...@ietf.org<mailto:6...@ietf.org>>
Subject: Re: [spring] Beyond SRv6.

Robert,

I can only repeat what my customers’ requirements. They have asked for 8-12 
SIDs in SR-MPLS and SRv6 and SRv6+.

We didn’t question that requirement for SR-MPLS. Why should things be any 
different for SRv6 or SR

Re: [spring] Beyond SRv6.

[Robert Raszuk]

Yes Ron I saw this message from Bob and as you see from the mailer I
responded with clarification on why this is not 2^112.

While I do not understand why ULAs blocks must be globally unique (to me
this is analogy of RFC1918 :) there are few more options on the table on
what blocks to use for uSIDs addressing.

Thx,
R.


On Sun, Sep 1, 2019 at 11:48 PM Ron Bonica  wrote:

> Robert,
>
>
>
> Please see
> https://mailarchive.ietf.org/arch/browse/spring/?gbt=1=BPXFbv5drFqv7k7nPIN3SDuifo0
> .
>
>
>
> Ron
>


>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Gaurav Dawra]

Hi,

We are interested in the SRv6 solution as standardized by the working group. 
Thanks!
We see SRv6 solution may align with some of our production requirements for 
TE(and other use-cases) while potentially being inline within our needs for 
simplicity, performance, MTU overhead optimizations etc

Gaurav


> On Sep 1, 2019, at 1:19 AM, Sébastien Parisot  wrote:
> 
> Hi,
> 
> We deployed SRv6 as part of our new mobile network in Italy (Iliad Italy). 
> SRv6 with SRH is carrying commercial traffic of millions of subscribers for 
> several months, with line-rate performance and on several platforms and 
> operating systems.
> We also started to extend our deployment to our national network in France 
> (Free & Free Mobile), we already have significant inter-AS SRv6 traffic.
> 
> You can also read draft-matsushima-spring-srv6-deployment-status-01 section 
> 2.3.
> 
> Best regards,
> Sébastien
> 
> - Mail original -
>> De: "Satoru Matsushima" 
>> À: "SPRING WG List" 
>> Cc: "Zafar Ali, zali" , "Rob Shakir" 
>> 
>> Envoyé: Samedi 31 Août 2019 15:41:43
>> Objet: Re: [spring] Beyond SRv6.
> 
>> Hi,
>> 
>> As part of the 5G rollout, Softbank have deployed a nationwide SRv6 network
>> carrying commercial traffic with the linerate performance using Merchant
>> Silicon.
>> 
>> https://www.softbank.jp/corp/news/press/sbkk/2019/20190424_03/
>> 
>> # You can read it in your language through some translation service, e.g, 
>> google
>> translation.
>> 
>> draft-matsushima-spring-srv6-deployment-status captured that use case.
>> 
>> Best regards,
>> --satoru
>> 
>> 
>>> 2019/08/31 6:05、Zafar Ali (zali) のメール:
>>> 
>>> Dear Chairs and the WG:
>>> 
>>> The SRv6 network programming solution and its SRH encapsulation is 
>>> implemented
>>> on 12 hardware platforms including Merchant Silicon.
>>> Multiple providers have deployed the SRv6 network programming solution and 
>>> its
>>> SRH encapsulation with line-rate performance carrying a significant amount 
>>> of
>>> commercial traffic.
>>> Several independent interoperability reports documenting successful
>>> interoperability of implementation from multiple vendors exist.
>>> Implementation, deployment, and interoperability status is publicly 
>>> documented
>>> inhttps://www.ietf.org/id/draft-matsushima-spring-srv6-deployment-status-01.txt.
>>> 
>>> Most use-cases are expected to use very few SRv6 segments.
>>> 
>>> In some specific use-cases, one may desire to optimize the MTU usage 
>>> further.
>>> The SRv6 network programming solution and its SRH encapsulation also 
>>> support for
>>> this Optimization, through the uSID network instruction.
>>> 
>>> I do not see the need for any new encapsulation work.
>>> 
>>> Thanks
>>> 
>>> Regards … Zafar
>>> 
>>> From: spring  on behalf of Rob Shakir
>>> 
>>> Date: Sunday, August 4, 2019 at 5:04 PM
>>> To: SPRING WG List 
>>> Subject: [spring] Beyond SRv6.
>>> 
>>> Hi SPRING WG,
>>> 
>>> Over the last 5+ years, the IETF has developed Source Packet Routing in
>>> NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6
>>> (SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE.
>>> 
>>> These encapsulations are past WG last call (in IESG or RFC Editor).
>>> 
>>> During the SPRING WG meeting at IETF 105, two presentations were related to 
>>> the
>>> reduction of the size of the SID for IPv6 dataplane:
>>>•
>>>• SRv6+ / CRH --
>>>• https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04
>>>•
>>>•
>>>• uSID --
>>>•
>>>
>>> https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01
>>>•
>>> 
>>> During the IETF week, two additional drafts have been proposed:
>>>•
>>>• https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00
>>>•
>>>•
>>>• https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03
>>>•
>>> 
>>> As we expressed during the meeting, it is important for the WG to understand
>>> what the aims of additional encapsulations are. Thus, we think it is 
>>> important
>>> that the WG should first get t

Re: [spring] Beyond SRv6.

[Ron Bonica]

Robert,

Please see 
https://mailarchive.ietf.org/arch/browse/spring/?gbt=1=BPXFbv5drFqv7k7nPIN3SDuifo0.

Ron

From: Robert Raszuk 
Sent: Sunday, September 1, 2019 5:39 PM
To: Nick Hilliard 
Cc: Ron Bonica ; Rob Shakir ; Fernando 
Gont ; SPRING WG List ; 6...@ietf.org
Subject: Re: [spring] Beyond SRv6.

Nick,

How about using ULAs as defined in RFC4193 ?

After all isn't local IPv6 FC00::/7 address block defined precisely for such 
private use cases like the one which uSID requires?

Clearly RIRs will not allocate /22 blocks left and right and that v6 prefix 
would be required if I have 1000 node network and my uSID is /32.

Thx,
R.


On Sun, Sep 1, 2019 at 11:33 PM Nick Hilliard 
mailto:n...@foobar.org>> wrote:
Ron Bonica wrote on 01/09/2019 22:10:
> -https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfilsfils-2Dspring-2Dnet-2Dpgm-2Dextension-2Dsrv6-2Dusid-2D02=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8=7I4t7LyLvwwPPgSsY1oWMfea5dTE2YbuJyBi-ITbgp0=HaZUtfUO-zFP__49jfNHxb_YdFd2EZVxbt9q3Jbztuc=>

Ron,

if this draft proposes using up to /32 per router in a SRv6 domain, or
even /40 to /48, it may be appropriate to solicit input from RIR address
policy groups about the impact this may have on ipv6 assignment /
allocation policies.

Nick

___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8=7I4t7LyLvwwPPgSsY1oWMfea5dTE2YbuJyBi-ITbgp0=2wTKvWueDyZNNHloNNHK66vNruLD2Drj5FJDisgUQlE=>


Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Robert Raszuk]

Nick,

How about using ULAs as defined in RFC4193 ?

After all isn't local IPv6 FC00::/7 address block defined precisely for
such private use cases like the one which uSID requires?

Clearly RIRs will not allocate /22 blocks left and right and that v6 prefix
would be required if I have 1000 node network and my uSID is /32.

Thx,
R.


On Sun, Sep 1, 2019 at 11:33 PM Nick Hilliard  wrote:

> Ron Bonica wrote on 01/09/2019 22:10:
> > -
> https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02
>
> Ron,
>
> if this draft proposes using up to /32 per router in a SRv6 domain, or
> even /40 to /48, it may be appropriate to solicit input from RIR address
> policy groups about the impact this may have on ipv6 assignment /
> allocation policies.
>
> Nick
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Nick Hilliard]

Ron Bonica wrote on 01/09/2019 22:10:

-https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02


Ron,

if this draft proposes using up to /32 per router in a SRv6 domain, or 
even /40 to /48, it may be appropriate to solicit input from RIR address 
policy groups about the impact this may have on ipv6 assignment / 
allocation policies.


Nick

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Andrew Alston]

Robert,

CRH works just fine with the deep label depth in our testing of it.  As I 
stated in my previous emails – There are a number of issues with uSID that I 
can see – and I won’t repeat all of those here again.  There are a whole number 
of aspects going through that network map that do not give a full picture – 
multiple paths of unequal sizes – multiple circuits between locations that 
aren’t clearly shown there for diversity sake – and a whole heap of other 
issues.  You need to realize that steering in our case is not just about 
diversity – there are many reasons why we steer and why our customers wish us 
to steer – and glancing at a network map like that will not give you close to a 
full picture.  Those reasons can range from everything from latency to 
geopolitical issues.

Then again – as an operator – I have always believed in having the choice – and 
as I stated in previous emails – in the networking world we have many 
alternatives to many things – and I went as far as to propose writing an 
inter-op draft so that both CRH and uSID could move forward rather than both 
ending up stalled, or worse will, one or the other ending up as proprietary – 
and I may well still get around to doing this – time has just been a little 
hectic of late.

Andrew
From: Robert Raszuk 
Date: Sunday, 1 September 2019 at 22:28
To: Andrew Alston 
Cc: Ron Bonica , Rob Shakir 
, SPRING WG List , "6...@ietf.org" 
<6...@ietf.org>
Subject: Re: [spring] Beyond SRv6.

Hi Andrew,

Looking at your network topology 
https://www.liquidtelecom.com/about-us/network-map.html<https://www.liquidtelecom.com/about-us/network-map.html>
 yes indeed you need to pass via number of countries, but keep in mind that SR 
is not a routing protocol.

Even focusing on your longest data paths say from Cairo to Cape Town I really 
see no use for more then optimally chosen 3 or 4 SIDs to well diversify the 
flows to traverse different end to end paths then your routed default.

Now if your desire is to provide for all the possible data flows per each ECMP 
link group forwarding control then I see counting adj SIDs you can get to 10 
SIDs or more. But is SRv6 then optimal tool in the toolkit to accomplish that ?

But assume it is how about use of uSID combination with SRH such that you can 
have your requirements well satisfied in the current network regardless if 
alternative design or alternate network architecture exists or not ?

Thx,
Robert.


On Sun, Sep 1, 2019 at 9:47 PM Andrew Alston 
mailto:andrew.als...@liquidtelecom.com>> wrote:
I can state categorically that we have a solid case to use 8 to 12 SID’s –

Let me put it this way – If I cross my own network – To get to certain 
countries I have to pass through no less than 5 separate countries in certain 
scenarios – and it’s not practically possible to avoid this.  When I add the 
various paths we need to steer across and the numbers of devices to do this in 
a granular way – with the amount of meshing we have to do to achieve redundancy 
– yes – it gets complex – and yes – the node depth gets deep.

Our case of needing granular steering here – without necessarily going lose – 
is ironclad – and I can say that right now, 10 node steering for certain cases 
is 100% a reality for what we need.

Andrew


From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Ron Bonica 
mailto:40juniper@dmarc.ietf.org>>
Date: Sunday, 1 September 2019 at 21:00
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Rob Shakir mailto:ro...@google.com>>, SPRING WG List 
mailto:spring@ietf.org>>, 
"6...@ietf.org<mailto:6...@ietf.org>" <6...@ietf.org<mailto:6...@ietf.org>>
Subject: Re: [spring] Beyond SRv6.

Robert,

I can only repeat what my customers’ requirements. They have asked for 8-12 
SIDs in SR-MPLS and SRv6 and SRv6+.

We didn’t question that requirement for SR-MPLS. Why should things be any 
different for SRv6 or SRv6+?

  Ron




From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Sunday, September 1, 2019 11:03 AM
To: Ron Bonica mailto:rbon...@juniper.net>>
Cc: Rob Shakir mailto:ro...@google.com>>; SPRING WG List 
mailto:spring@ietf.org>>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: Re: [spring] Beyond SRv6.

Dear Ron,

> SR customers have stated a firm requirement to support SR paths that contain 
> 8 to 12 segments.

Let me make an observation that with 8 to 12 router hops I can reach most of my 
often visited destinations in the open Internet anywhere in the world.

With that let's also notice that proposed SRv6 (or for that matter SR-MPLS) is 
applicable to networks under same administrative control.

Therefor I do question the necessity to have such deep/long list of segments 
for any practical network application.

Perhaps some customers (or vendors) are treating SRv6 verbatim as an analogy

Re: [spring] Beyond SRv6.

[Ron Bonica]

Hi Fernando,

6man participants should look at the following:

- https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01 (In 
particular, Sections 4 and 5)
- 
https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02


 Ron


Juniper Business Use Only

-Original Message-
From: Fernando Gont  
Sent: Saturday, August 31, 2019 4:53 PM
To: Ron Bonica ; Rob Shakir ; SPRING WG 
List ; 6...@ietf.org
Subject: Re: [spring] Beyond SRv6.

Hi, Ron,

For those 6man-ers that have not been following the sprin work, could you 
please clarify what do you mean by "stretching the interpretation of
RFC8200 or RFC4291"?

In the past we have seen outright violation of RFC8200 (formerly RFC2460), so 
I'm curious if there are any documents trying to do the same, or what.

Thanks!

Cheers,
Fernando




On 31/8/19 23:33, Ron Bonica wrote:
> Rob,
> 
>  
> 
> The following are arguments for proceeding with SRv6+:
> 
>  
> 
>   * Efficient forwarding with deep SID lists
>   * Operational Simplicity
>   * SRv6+ work may finish before SRv6
> 
>  
> 
> Efficient forwarding with deep SID Lists
> 
> 
> 
>  
> 
> SR customers have stated a firm requirement to support SR paths that 
> contain 8 to 12 segments. They have also stated a requirement for 
> implementations to forward at line speed  and without consuming 
> excessive overhead bandwidth.
> 
>  
> 
> SRv6, as defined in draft-ietf-6man-segment-routing-header, cannot 
> satisfy these requirements. In order to support an SR path with 8 
> segments, SRv6 would require a 128-byte SRH. Even if ASICs could 
> process such a long SRH at line speed, the bandwidth overhead would be 
> prohibitive.
> 
>  
> 
> Therefore, one of the four solutions  that you mention below is 
> required to make SRv6 deployable. While 
> draft-ietf-6man-segment-routing-header is close to maturity, the four 
> competing solutions mentioned below are equally mature and should be given 
> equal consideration.
> 
>  
> 
> The four solutions are SRv6+, uSID, draft-li and draft-mirsky.
> 
>  
> 
> Operational Simplicity
> 
> -
> 
> Network operators strive for operational simplicity. By loosely 
> interpreting (and sometimes bending) the requirements of RFCs 4291 and 
> RFC 8200, SRv6 introduces architectural quirks that introduce 
> operational complexity. The following are architectural quirks of
>  draft-ietf-6man-segment-routing-header:
> 
>  
> 
>   * The Segment Routing Header (SRH) serves purposes other than routing.
> Therefore, the SRH is sometimes required for packets that traverse
> the least-cost path from source to destination
>   * The SRH and the IPv6 Authentication Header are incompatible.
>   * The IPv6 destination address determines whether an SRH is valid and
> how it is processed. For example, if the IPv6 destination address
> contains one locally instantiated value, the SRH might be processed
> in one particular way, while if the IPv6 destination address
> contains another locally instantiated value, the SRH might be
> totally invalid.
> 
>  
> 
> Draft-ietf-spring-srv6-network-programming  promises more 
> architectural quirks. For example:
> 
>  
> 
>   * Segment endpoints can insert and/or delete IPv6 extension headers
>   * An IPv6 packet can contain two Segment Routing headers
>   * IPv6 packets are no longer self-describing. For example, the Next
> Header Field in the SRH can carry a value of No Next Header, even
> though the SRH is followed by Ethernet payload.
> 
>  
> 
> Other emerging drafts promise still more architectural quirks. For 
> example, in draft-ali-6man-spring-srv6-oam, implementations need to 
> examine the SRH even when Segment Left equals zero. This is because 
> the SRH has been overloaded to carry OAM as well as routing information.
> 
>  
> 
> Furthermore, draft-filsfils-spring-net-pgm-extension-srv6-usid 
> requires network operators to obtain address space and number their 
> networks in a particular way to make routing work.
> 
>  
> 
> SRv6+ Work May Finish Before SRv6 work
> 
> 
> 
> SRv6+  has been implemented on LINUX and is being implemented on JUNOS.
> Implementation experience demonstrates that specification is fairly 
> complete. For example, there is no need for an SRv6+ OAM document. 
> It's just IPv6 and IPv6 OAM just works.

Re: [spring] Beyond SRv6.

[Robert Raszuk]

Hi Andrew,

Looking at your network topology
https://www.liquidtelecom.com/about-us/network-map.html yes indeed you need
to pass via number of countries, but keep in mind that SR is not a routing
protocol.

Even focusing on your longest data paths say from Cairo to Cape Town I
really see no use for more then optimally chosen 3 or 4 SIDs to well
diversify the flows to traverse different end to end paths then your routed
default.

Now if your desire is to provide for all the possible data flows per each
ECMP link group forwarding control then I see counting adj SIDs you can get
to 10 SIDs or more. But is SRv6 then optimal tool in the toolkit to
accomplish that ?

But assume it is how about use of uSID combination with SRH such that you
can have your requirements well satisfied in the current network regardless
if alternative design or alternate network architecture exists or not ?

Thx,
Robert.


On Sun, Sep 1, 2019 at 9:47 PM Andrew Alston <
andrew.als...@liquidtelecom.com> wrote:

> I can state categorically that we have a solid case to use 8 to 12 SID’s –
>
>
>
> Let me put it this way – If I cross my own network – To get to certain
> countries I have to pass through no less than 5 separate countries in
> certain scenarios – and it’s not practically possible to avoid this.  When
> I add the various paths we need to steer across and the numbers of devices
> to do this in a granular way – with the amount of meshing we have to do to
> achieve redundancy – yes – it gets complex – and yes – the node depth gets
> deep.
>
>
>
> Our case of needing granular steering here – without necessarily going
> lose – is ironclad – and I can say that right now, 10 node steering for
> certain cases is 100% a reality for what we need.
>
>
>
> Andrew
>
>
>
>
>
> *From: *spring  on behalf of Ron Bonica  40juniper@dmarc.ietf.org>
> *Date: *Sunday, 1 September 2019 at 21:00
> *To: *Robert Raszuk 
> *Cc: *Rob Shakir , SPRING WG List , "
> 6...@ietf.org" <6...@ietf.org>
> *Subject: *Re: [spring] Beyond SRv6.
>
>
>
> Robert,
>
>
>
> I can only repeat what my customers’ requirements. They have asked for
> 8-12 SIDs in SR-MPLS and SRv6 and SRv6+.
>
>
>
> We didn’t question that requirement for SR-MPLS. Why should things be any
> different for SRv6 or SRv6+?
>
>
>
>   Ron
>
>
>
>
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Sunday, September 1, 2019 11:03 AM
> *To:* Ron Bonica 
> *Cc:* Rob Shakir ; SPRING WG List ;
> 6...@ietf.org
> *Subject:* Re: [spring] Beyond SRv6.
>
>
>
> Dear Ron,
>
>
>
> > SR customers have stated a firm requirement to support SR paths that
> contain 8 to 12 segments.
>
>
>
> Let me make an observation that with 8 to 12 router hops I can reach most
> of my often visited destinations in the open Internet anywhere in
> the world.
>
>
>
> With that let's also notice that proposed SRv6 (or for that matter
> SR-MPLS) is applicable to networks under same administrative control.
>
>
>
> Therefor I do question the necessity to have such deep/long list of
> segments for any practical network application.
>
>
>
> Perhaps some customers (or vendors) are treating SRv6 verbatim as an
> analogy to RSVP-TE strict or loose ERO objects - but that is completely
> wrong way to think about it in light of segment routing architecture and
> its abilities.
>
>
>
> In RSVP-TE you nail down the path with hop by hop RESV-PATH msg signalling
> such that forwarding is using locally upstream assigned labels distributed
> by return RSVP-RESV msg.
>
>
>
> I would never suggest to do same with SR. The biggest advantage of SR
> (outside of its network programmability concept) is in the ability to
> encode very selected anchor node or nodes to which forwarding just flows
> natively using IPv6 address or domain wide MPLS label.
>
>
>
> So proper use of SR does require wise selection of such anchor points in
> the network. I am afraid CSPF is not the best tool for it. Much smarter
> algorithm is required to engineer your traffic using SR technology in any
> network especially in cases where the IGP topology is very dense and
> complex.
>
>
>
> Based on my personal experience with MPLS-TE deployments across biggest
> global networks I  can state that vast majority of true path steering can
> be easily accomplished with 1, 2 or max 3 properly selected anchor nodes
> across their domain(s). Add to that room for two SFC processing clusters
> and you get max 5.
>
>
>
> So even if some individual operators would like to use 8, 12 or maybe 16
> segments in their packe

Re: [spring] Beyond SRv6.

[Andrew Alston]

I can state categorically that we have a solid case to use 8 to 12 SID’s –

Let me put it this way – If I cross my own network – To get to certain 
countries I have to pass through no less than 5 separate countries in certain 
scenarios – and it’s not practically possible to avoid this.  When I add the 
various paths we need to steer across and the numbers of devices to do this in 
a granular way – with the amount of meshing we have to do to achieve redundancy 
– yes – it gets complex – and yes – the node depth gets deep.

Our case of needing granular steering here – without necessarily going lose – 
is ironclad – and I can say that right now, 10 node steering for certain cases 
is 100% a reality for what we need.

Andrew


From: spring  on behalf of Ron Bonica 

Date: Sunday, 1 September 2019 at 21:00
To: Robert Raszuk 
Cc: Rob Shakir , SPRING WG List , 
"6...@ietf.org" <6...@ietf.org>
Subject: Re: [spring] Beyond SRv6.

Robert,

I can only repeat what my customers’ requirements. They have asked for 8-12 
SIDs in SR-MPLS and SRv6 and SRv6+.

We didn’t question that requirement for SR-MPLS. Why should things be any 
different for SRv6 or SRv6+?

  Ron




From: Robert Raszuk 
Sent: Sunday, September 1, 2019 11:03 AM
To: Ron Bonica 
Cc: Rob Shakir ; SPRING WG List ; 
6...@ietf.org
Subject: Re: [spring] Beyond SRv6.

Dear Ron,

> SR customers have stated a firm requirement to support SR paths that contain 
> 8 to 12 segments.

Let me make an observation that with 8 to 12 router hops I can reach most of my 
often visited destinations in the open Internet anywhere in the world.

With that let's also notice that proposed SRv6 (or for that matter SR-MPLS) is 
applicable to networks under same administrative control.

Therefor I do question the necessity to have such deep/long list of segments 
for any practical network application.

Perhaps some customers (or vendors) are treating SRv6 verbatim as an analogy to 
RSVP-TE strict or loose ERO objects - but that is completely wrong way to think 
about it in light of segment routing architecture and its abilities.

In RSVP-TE you nail down the path with hop by hop RESV-PATH msg signalling such 
that forwarding is using locally upstream assigned labels distributed by return 
RSVP-RESV msg.

I would never suggest to do same with SR. The biggest advantage of SR (outside 
of its network programmability concept) is in the ability to encode very 
selected anchor node or nodes to which forwarding just flows natively using 
IPv6 address or domain wide MPLS label.

So proper use of SR does require wise selection of such anchor points in the 
network. I am afraid CSPF is not the best tool for it. Much smarter algorithm 
is required to engineer your traffic using SR technology in any network 
especially in cases where the IGP topology is very dense and complex.

Based on my personal experience with MPLS-TE deployments across biggest global 
networks I  can state that vast majority of true path steering can be easily 
accomplished with 1, 2 or max 3 properly selected anchor nodes across their 
domain(s). Add to that room for two SFC processing clusters and you get max 5.

So even if some individual operators would like to use 8, 12 or maybe 16 
segments in their packets I do not see this as fundamentally sufficient 
justification to proceed with yet one more SRv6 encoding proposal.

As both Rob & Bruno asked I will be looking for real technical justifications 
for such deep segment stacks. Note that we are at the end of 4 week pool window 
and there was none sent to the list so far.

Kind regards,
Robert.


On Sat, Aug 31, 2019 at 10:34 PM Ron Bonica 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
Rob,

The following are arguments for proceeding with SRv6+:


  *   Efficient forwarding with deep SID lists
  *   Operational Simplicity
  *   SRv6+ work may finish before SRv6

Efficient forwarding with deep SID Lists


SR customers have stated a firm requirement to support SR paths that contain 8 
to 12 segments. They have also stated a requirement for implementations to 
forward at line speed  and without consuming excessive overhead bandwidth.

SRv6, as defined in draft-ietf-6man-segment-routing-header, cannot satisfy 
these requirements. In order to support an SR path with 8 segments, SRv6 would 
require a 128-byte SRH. Even if ASICs could process such a long SRH at line 
speed, the bandwidth overhead would be prohibitive.

Therefore, one of the four solutions  that you mention below is required to 
make SRv6 deployable. While draft-ietf-6man-segment-routing-header is close to 
maturity, the four competing solutions mentioned below are equally mature and 
should be given equal consideration.


The four solutions are SRv6+, uSID, draft-li and draft-mirsky.

Operational Simplicity
-
Network operators s

Re: [spring] Beyond SRv6.

[Robert Raszuk]

Hi Ron,

The SR architecture is common to SR-MPLS and SRv6 as far as path
engineering is concerned ie. number of SIDs to impose.

I explained one pretty common misconception of how some people treat SR as
1:1 replacement of RSVP-TE. In fact there may even float around some slides
or white papers stating so - but if anything they are fundamentally
incorrect.

So here in SPRING you either present valid and convincing to WG technical
explanation why in specific network you see a need for 8-12+ SIDs or that
point simply can not be used as "push" argument for CRH ;). .

On the other hand you know that the most difficult to introduce any new
technology is not even respining an ASIC .. it is education and assistance
to your customers to make sure new technology is really deployed in the
right way.

Cheers,
Robert.

PS. Talking in the context of SRv6 architecture to one of the most common
of the shelf forwarding vendor I was told their hardware reads 256 bytes of
the packet header for flexible processing. So with that I am even more
assured that the bottleneck in line rate packet processing even with your
stated size of SRH is rather limited to legacy hardware which will happen
all the time and is normal when someone defines new data plane
enhancements. After all no one obsoletes SR-MPLS - it can be used as smooth
transition path to SRv6.



On Sun, Sep 1, 2019 at 8:59 PM Ron Bonica  wrote:

> Robert,
>
>
>
> I can only repeat what my customers’ requirements. They have asked for
> 8-12 SIDs in SR-MPLS and SRv6 and SRv6+.
>
>
>
> We didn’t question that requirement for SR-MPLS. Why should things be any
> different for SRv6 or SRv6+?
>
>
>
>   Ron
>
>
>
>
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Sunday, September 1, 2019 11:03 AM
> *To:* Ron Bonica 
> *Cc:* Rob Shakir ; SPRING WG List ;
> 6...@ietf.org
> *Subject:* Re: [spring] Beyond SRv6.
>
>
>
> Dear Ron,
>
>
>
> > SR customers have stated a firm requirement to support SR paths that
> contain 8 to 12 segments.
>
>
>
> Let me make an observation that with 8 to 12 router hops I can reach most
> of my often visited destinations in the open Internet anywhere in
> the world.
>
>
>
> With that let's also notice that proposed SRv6 (or for that matter
> SR-MPLS) is applicable to networks under same administrative control.
>
>
>
> Therefor I do question the necessity to have such deep/long list of
> segments for any practical network application.
>
>
>
> Perhaps some customers (or vendors) are treating SRv6 verbatim as an
> analogy to RSVP-TE strict or loose ERO objects - but that is completely
> wrong way to think about it in light of segment routing architecture and
> its abilities.
>
>
>
> In RSVP-TE you nail down the path with hop by hop RESV-PATH msg signalling
> such that forwarding is using locally upstream assigned labels distributed
> by return RSVP-RESV msg.
>
>
>
> I would never suggest to do same with SR. The biggest advantage of SR
> (outside of its network programmability concept) is in the ability to
> encode very selected anchor node or nodes to which forwarding just flows
> natively using IPv6 address or domain wide MPLS label.
>
>
>
> So proper use of SR does require wise selection of such anchor points in
> the network. I am afraid CSPF is not the best tool for it. Much smarter
> algorithm is required to engineer your traffic using SR technology in any
> network especially in cases where the IGP topology is very dense and
> complex.
>
>
>
> Based on my personal experience with MPLS-TE deployments across biggest
> global networks I  can state that vast majority of true path steering can
> be easily accomplished with 1, 2 or max 3 properly selected anchor nodes
> across their domain(s). Add to that room for two SFC processing clusters
> and you get max 5.
>
>
>
> So even if some individual operators would like to use 8, 12 or maybe 16
> segments in their packets I do not see this as fundamentally sufficient
> justification to proceed with yet one more SRv6 encoding proposal.
>
>
>
> As both Rob & Bruno asked I will be looking for real technical
> justifications for such deep segment stacks. Note that we are at the end of
> 4 week pool window and there was none sent to the list so far.
>
>
>
> Kind regards,
>
> Robert.
>
>
>
>
>
> On Sat, Aug 31, 2019 at 10:34 PM Ron Bonica  40juniper@dmarc.ietf.org> wrote:
>
> Rob,
>
>
>
> The following are arguments for proceeding with SRv6+:
>
>
>
>- Efficient forwarding with deep SID lists
>- Operational Simplicity
>- SRv6+ work may finis

Re: [spring] Beyond SRv6.

[Ron Bonica]

Robert,

I can only repeat what my customers' requirements. They have asked for 8-12 
SIDs in SR-MPLS and SRv6 and SRv6+.

We didn't question that requirement for SR-MPLS. Why should things be any 
different for SRv6 or SRv6+?

  Ron




From: Robert Raszuk 
Sent: Sunday, September 1, 2019 11:03 AM
To: Ron Bonica 
Cc: Rob Shakir ; SPRING WG List ; 
6...@ietf.org
Subject: Re: [spring] Beyond SRv6.

Dear Ron,

> SR customers have stated a firm requirement to support SR paths that contain 
> 8 to 12 segments.

Let me make an observation that with 8 to 12 router hops I can reach most of my 
often visited destinations in the open Internet anywhere in the world.

With that let's also notice that proposed SRv6 (or for that matter SR-MPLS) is 
applicable to networks under same administrative control.

Therefor I do question the necessity to have such deep/long list of segments 
for any practical network application.

Perhaps some customers (or vendors) are treating SRv6 verbatim as an analogy to 
RSVP-TE strict or loose ERO objects - but that is completely wrong way to think 
about it in light of segment routing architecture and its abilities.

In RSVP-TE you nail down the path with hop by hop RESV-PATH msg signalling such 
that forwarding is using locally upstream assigned labels distributed by return 
RSVP-RESV msg.

I would never suggest to do same with SR. The biggest advantage of SR (outside 
of its network programmability concept) is in the ability to encode very 
selected anchor node or nodes to which forwarding just flows natively using 
IPv6 address or domain wide MPLS label.

So proper use of SR does require wise selection of such anchor points in the 
network. I am afraid CSPF is not the best tool for it. Much smarter algorithm 
is required to engineer your traffic using SR technology in any network 
especially in cases where the IGP topology is very dense and complex.

Based on my personal experience with MPLS-TE deployments across biggest global 
networks I  can state that vast majority of true path steering can be easily 
accomplished with 1, 2 or max 3 properly selected anchor nodes across their 
domain(s). Add to that room for two SFC processing clusters and you get max 5.

So even if some individual operators would like to use 8, 12 or maybe 16 
segments in their packets I do not see this as fundamentally sufficient 
justification to proceed with yet one more SRv6 encoding proposal.

As both Rob & Bruno asked I will be looking for real technical justifications 
for such deep segment stacks. Note that we are at the end of 4 week pool window 
and there was none sent to the list so far.

Kind regards,
Robert.


On Sat, Aug 31, 2019 at 10:34 PM Ron Bonica 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
Rob,

The following are arguments for proceeding with SRv6+:


  *   Efficient forwarding with deep SID lists
  *   Operational Simplicity
  *   SRv6+ work may finish before SRv6

Efficient forwarding with deep SID Lists


SR customers have stated a firm requirement to support SR paths that contain 8 
to 12 segments. They have also stated a requirement for implementations to 
forward at line speed  and without consuming excessive overhead bandwidth.

SRv6, as defined in draft-ietf-6man-segment-routing-header, cannot satisfy 
these requirements. In order to support an SR path with 8 segments, SRv6 would 
require a 128-byte SRH. Even if ASICs could process such a long SRH at line 
speed, the bandwidth overhead would be prohibitive.

Therefore, one of the four solutions  that you mention below is required to 
make SRv6 deployable. While draft-ietf-6man-segment-routing-header is close to 
maturity, the four competing solutions mentioned below are equally mature and 
should be given equal consideration.


The four solutions are SRv6+, uSID, draft-li and draft-mirsky.

Operational Simplicity
-
Network operators strive for operational simplicity. By loosely interpreting 
(and sometimes bending) the requirements of RFCs 4291 and RFC 8200, SRv6 
introduces architectural quirks that introduce operational complexity. The 
following are architectural quirks of  draft-ietf-6man-segment-routing-header:


  *   The Segment Routing Header (SRH) serves purposes other than routing. 
Therefore, the SRH is sometimes required for packets that traverse the 
least-cost path from source to destination
  *   The SRH and the IPv6 Authentication Header are incompatible.
  *   The IPv6 destination address determines whether an SRH is valid and how 
it is processed. For example, if the IPv6 destination address contains one 
locally instantiated value, the SRH might be processed in one particular way, 
while if the IPv6 destination address contains another locally instantiated 
value, the SRH might be totally invalid.

Draft-ietf-spring-srv6-network-programmin

Re: [spring] Beyond SRv6.

[Tom Herbert]

On Sat, Aug 31, 2019, 4:34 PM Ron Bonica  wrote:

> Rob,
>
>
>
> The following are arguments for proceeding with SRv6+:
>
>
>
>- Efficient forwarding with deep SID lists
>- Operational Simplicity
>- SRv6+ work may finish before SRv6
>
>
>
> Efficient forwarding with deep SID Lists
>
> 
>
>
>
> SR customers have stated a firm requirement to support SR paths that
> contain 8 to 12 segments. They have also stated a requirement for
> implementations to forward at line speed  and without consuming excessive
> overhead bandwidth.
>
>
>
> SRv6, as defined in draft-ietf-6man-segment-routing-header, cannot satisfy
> these requirements. In order to support an SR path with 8 segments, SRv6
> would require a 128-byte SRH. Even if ASICs could process such a long SRH
> at line speed, the bandwidth overhead would be prohibitive.
>

Hi Ron,

It's hard to say whether or not SRH satisfies the requirements without
first having quantified requirements. For instance, how much header
overhead does it take before it's considered prohibitive?

The 128 byte SRH would be one quantified requirement. Is this rooted in
some inherent implementation constraint? My understanding is that many
devices have a parsing buffer of some fixed size for processing packet
headers. If a packet's headers of interest don't fit into buffer that's a
problem. 128 and 256 bytes seem to be common sizes. But, this padding
buffer is for all headers (e.g. Ethernet, IPv6, SRH, etc.). So an SRH with
just 5 SIDs would overflow a 128 byte parsing buffer.

Tom


>
> Therefore, one of the four solutions  that you mention below is required
> to make SRv6 deployable. While draft-ietf-6man-segment-routing-header is
> close to maturity, the four competing solutions mentioned below are equally
> mature and should be given equal consideration.
>
>
>
> The four solutions are SRv6+, uSID, draft-li and draft-mirsky.
>
>
>
> Operational Simplicity
>
> -
>
> Network operators strive for operational simplicity. By loosely
> interpreting (and sometimes bending) the requirements of RFCs 4291 and RFC
> 8200, SRv6 introduces architectural quirks that introduce operational
> complexity. The following are architectural quirks of
>  draft-ietf-6man-segment-routing-header:
>
>
>
>- The Segment Routing Header (SRH) serves purposes other than routing.
>Therefore, the SRH is sometimes required for packets that traverse the
>least-cost path from source to destination
>- The SRH and the IPv6 Authentication Header are incompatible.
>- The IPv6 destination address determines whether an SRH is valid and
>how it is processed. For example, if the IPv6 destination address contains
>one locally instantiated value, the SRH might be processed in one
>particular way, while if the IPv6 destination address contains another
>locally instantiated value, the SRH might be totally invalid.
>
>
>
> Draft-ietf-spring-srv6-network-programming  promises more architectural
> quirks. For example:
>
>
>
>- Segment endpoints can insert and/or delete IPv6 extension headers
>- An IPv6 packet can contain two Segment Routing headers
>- IPv6 packets are no longer self-describing. For example, the Next
>Header Field in the SRH can carry a value of No Next Header, even though
>the SRH is followed by Ethernet payload.
>
>
>
> Other emerging drafts promise still more architectural quirks. For
> example, in draft-ali-6man-spring-srv6-oam, implementations need to examine
> the SRH even when Segment Left equals zero. This is because the SRH has
> been overloaded to carry OAM as well as routing information.
>
>
>
> Furthermore, draft-filsfils-spring-net-pgm-extension-srv6-usid requires
> network operators to obtain address space and number their networks in a
> particular way to make routing work.
>
>
>
> SRv6+ Work May Finish Before SRv6 work
>
> 
>
> SRv6+  has been implemented on LINUX and is being implemented on JUNOS.
> Implementation experience demonstrates that specification is fairly
> complete. For example, there is no need for an SRv6+ OAM document. It’s
> just IPv6 and IPv6 OAM just works.
>
>
>
> Furthermore, the SRv6+ specifications adhere to a strict interpretation of
> RFC 8200. Therefore, as they progress through the working group, they won’t
> need to overcome the objections that are inevitably encountered when
> stretching the interpretation of a specification that is so fundamental as
> RFC 8200.
>
>
>
>
>   
>  Thanks,
>
>
>  Ron
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* spring  *On Behalf Of *Rob Shakir
> *Sent:* Sunday, August 4, 2019 5:04 PM
> *To:* SPRING WG List 
> *Subject:* [spring] Beyond SRv6.
>
>
>
> Hi SPRING WG,
>
>
>
> Over the last 5+ years, 

Re: [spring] Beyond SRv6.

[Robert Raszuk]

Dear Ron,

> SR customers have stated a firm requirement to support SR paths that
contain 8 to 12 segments.

Let me make an observation that with 8 to 12 router hops I can reach most
of my often visited destinations in the open Internet anywhere in
the world.

With that let's also notice that proposed SRv6 (or for that matter SR-MPLS)
is applicable to networks under same administrative control.

Therefor I do question the necessity to have such deep/long list of
segments for any practical network application.

Perhaps some customers (or vendors) are treating SRv6 verbatim as an
analogy to RSVP-TE strict or loose ERO objects - but that is completely
wrong way to think about it in light of segment routing architecture and
its abilities.

In RSVP-TE you nail down the path with hop by hop RESV-PATH msg signalling
such that forwarding is using locally upstream assigned labels distributed
by return RSVP-RESV msg.

I would never suggest to do same with SR. The biggest advantage of SR
(outside of its network programmability concept) is in the ability to
encode very selected anchor node or nodes to which forwarding just flows
natively using IPv6 address or domain wide MPLS label.

So proper use of SR does require wise selection of such anchor points in
the network. I am afraid CSPF is not the best tool for it. Much smarter
algorithm is required to engineer your traffic using SR technology in any
network especially in cases where the IGP topology is very dense and
complex.

Based on my personal experience with MPLS-TE deployments across biggest
global networks I  can state that vast majority of true path steering can
be easily accomplished with 1, 2 or max 3 properly selected anchor nodes
across their domain(s). Add to that room for two SFC processing clusters
and you get max 5.

So even if some individual operators would like to use 8, 12 or maybe 16
segments in their packets I do not see this as fundamentally sufficient
justification to proceed with yet one more SRv6 encoding proposal.

As both Rob & Bruno asked I will be looking for real technical
justifications for such deep segment stacks. Note that we are at the end of
4 week pool window and there was none sent to the list so far.

Kind regards,
Robert.


On Sat, Aug 31, 2019 at 10:34 PM Ron Bonica  wrote:

> Rob,
>
>
>
> The following are arguments for proceeding with SRv6+:
>
>
>
>- Efficient forwarding with deep SID lists
>- Operational Simplicity
>- SRv6+ work may finish before SRv6
>
>
>
> Efficient forwarding with deep SID Lists
>
> 
>
>
>
> SR customers have stated a firm requirement to support SR paths that
> contain 8 to 12 segments. They have also stated a requirement for
> implementations to forward at line speed  and without consuming excessive
> overhead bandwidth.
>
>
>
> SRv6, as defined in draft-ietf-6man-segment-routing-header, cannot satisfy
> these requirements. In order to support an SR path with 8 segments, SRv6
> would require a 128-byte SRH. Even if ASICs could process such a long SRH
> at line speed, the bandwidth overhead would be prohibitive.
>
>
>
> Therefore, one of the four solutions  that you mention below is required
> to make SRv6 deployable. While draft-ietf-6man-segment-routing-header is
> close to maturity, the four competing solutions mentioned below are equally
> mature and should be given equal consideration.
>
>
>
> The four solutions are SRv6+, uSID, draft-li and draft-mirsky.
>
>
>
> Operational Simplicity
>
> -
>
> Network operators strive for operational simplicity. By loosely
> interpreting (and sometimes bending) the requirements of RFCs 4291 and RFC
> 8200, SRv6 introduces architectural quirks that introduce operational
> complexity. The following are architectural quirks of
>  draft-ietf-6man-segment-routing-header:
>
>
>
>- The Segment Routing Header (SRH) serves purposes other than routing.
>Therefore, the SRH is sometimes required for packets that traverse the
>least-cost path from source to destination
>- The SRH and the IPv6 Authentication Header are incompatible.
>- The IPv6 destination address determines whether an SRH is valid and
>how it is processed. For example, if the IPv6 destination address contains
>one locally instantiated value, the SRH might be processed in one
>particular way, while if the IPv6 destination address contains another
>locally instantiated value, the SRH might be totally invalid.
>
>
>
> Draft-ietf-spring-srv6-network-programming  promises more architectural
> quirks. For example:
>
>
>
>- Segment endpoints can insert and/or delete IPv6 extension headers
>- An IPv6 packet can contain two Segment Routing headers
>- IPv6 packets are no longer self-describing. For example, the Next
>Header Field in the SRH can carry a value of No Next Header, even though
>the SRH is followed by Ethernet payload.
>
>
>
> Other emerging drafts promise still 

Re: [spring] Beyond SRv6.

[Dirk Steinberg]

Hi,

the introduction of SRv6 as alternate data plane in addition to MPLS
has been an important step in SPRING, providing an encapsulation
for SPRING traffic that is native to IPv6.

The question about the necessity of work on alternate encapsulations
was fueled by concerns about encapsulation overhead when using 
full 128 bit SIDs in the SRv6 SRH.

Through the introduction of the uSID network instruction in SRv6
these concerns are now properly addressed and SRv6 with uSID
can now also be deployed in a very MTU-efficient manner. 

Therefore I do not see a necessity for any additional encapsulations.

Cheers
Dirk 

> Am 31.08.2019 um 06:05 schrieb Zafar Ali (zali) :
> 
> Dear Chairs and the WG: 
>  
> The SRv6 network programming solution and its SRH encapsulation is 
> implemented on 12 hardware platforms including Merchant Silicon.
> Multiple providers have deployed the SRv6 network programming solution and 
> its SRH encapsulation with line-rate performance carrying a significant 
> amount of commercial traffic.
> Several independent interoperability reports documenting successful 
> interoperability of implementation from multiple vendors exist.
> Implementation, deployment, and interoperability status is publicly 
> documented in 
> https://www.ietf.org/id/draft-matsushima-spring-srv6-deployment-status-01.txt 
> .
>  
> Most use-cases are expected to use very few SRv6 segments.
>  
> In some specific use-cases, one may desire to optimize the MTU usage further.
> The SRv6 network programming solution and its SRH encapsulation also support 
> for this Optimization, through the uSID network instruction.
>  
> I do not see the need for any new encapsulation work.
>  
> Thanks
>  
> Regards … Zafar 
>  
> From: spring mailto:spring-boun...@ietf.org>> on 
> behalf of Rob Shakir  >
> Date: Sunday, August 4, 2019 at 5:04 PM
> To: SPRING WG List mailto:spring@ietf.org>>
> Subject: [spring] Beyond SRv6.
>  
> Hi SPRING WG,
>  
> Over the last 5+ years, the IETF has developed Source Packet Routing in 
> NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6 
> (SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE.
>  
> These encapsulations are past WG last call (in IESG or RFC Editor).
>  
> During the SPRING WG meeting at IETF 105, two presentations were related to 
> the reduction of the size of the SID for IPv6 dataplane:
>  
> SRv6+ / CRH --
> https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04 
> 
>  
>  
> uSID --
> https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01
>  
> 
>  
>  
>  
> During the IETF week, two additional drafts have been proposed:
>  
> https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00 
>  
>  
>  
> https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03 
>  
>  
>  
> As we expressed during the meeting, it is important for the WG to understand 
> what the aims of additional encapsulations are. Thus, we think it is 
> important that the WG should first get to a common understanding on the 
> requirements for a new IPv6 data plane with a smaller SID - both from the 
> perspective of operators that are looking to deploy these technologies, and 
> from that of the software/hardware implementation.
>  
> Therefore, we would like to solicit network operators interested in SR over 
> the IPv6 data plane to briefly introduce their:
>  
> use case (e.g. Fast Reroute, explicit routing/TE)
>  
>  
> forwarding performance and scaling requirements
>  
>  
> e.g., (number of nodes, network diameter,
> number of SID required in max and average). For the latter, if possible using 
> both SRv6 128-bit SIDs and shorter (e.g. 32-bit) SIDs as the number would 
> typically be different (*).
>  
>  
> if the existing SRv6 approach is not deployable
> in their circumstances, details of the requirement of a different solution is 
> required and whether this solution is needed for the short term only or for 
> the long term.
>  
>  
> As well as deployment limitations, we would like the SPRING community to 
> briefly describe the platform limitations that they are seeing which limit 
> the deployment of SRv6  In particular limitations related to the number of 
> SIDs which can be pushed and forwarded and how much the use of shorter SIDs 
> would improve the deployments .
>  
> For both of these sets of feedback if possible, please post this to the 
> SPRING WG. If the information cannot be shared publicly, please send it 
> directly to the chairs & AD (Martin).
>  
> This call for information will run for four weeks, 

Re: [spring] Beyond SRv6.

[Sébastien Parisot]

Hi,

We deployed SRv6 as part of our new mobile network in Italy (Iliad Italy). SRv6 
with SRH is carrying commercial traffic of millions of subscribers for several 
months, with line-rate performance and on several platforms and operating 
systems.
We also started to extend our deployment to our national network in France 
(Free & Free Mobile), we already have significant inter-AS SRv6 traffic.

You can also read draft-matsushima-spring-srv6-deployment-status-01 section 2.3.

Best regards,
Sébastien

- Mail original -
> De: "Satoru Matsushima" 
> À: "SPRING WG List" 
> Cc: "Zafar Ali, zali" , "Rob Shakir" 
> 
> Envoyé: Samedi 31 Août 2019 15:41:43
> Objet: Re: [spring] Beyond SRv6.

> Hi,
> 
> As part of the 5G rollout, Softbank have deployed a nationwide SRv6 network
> carrying commercial traffic with the linerate performance using Merchant
> Silicon.
> 
> https://www.softbank.jp/corp/news/press/sbkk/2019/20190424_03/
> 
> # You can read it in your language through some translation service, e.g, 
> google
> translation.
> 
> draft-matsushima-spring-srv6-deployment-status captured that use case.
> 
> Best regards,
> --satoru
> 
> 
>> 2019/08/31 6:05、Zafar Ali (zali) のメール:
>> 
>> Dear Chairs and the WG:
>>  
>> The SRv6 network programming solution and its SRH encapsulation is 
>> implemented
>> on 12 hardware platforms including Merchant Silicon.
>> Multiple providers have deployed the SRv6 network programming solution and 
>> its
>> SRH encapsulation with line-rate performance carrying a significant amount of
>> commercial traffic.
>> Several independent interoperability reports documenting successful
>> interoperability of implementation from multiple vendors exist.
>> Implementation, deployment, and interoperability status is publicly 
>> documented
>> inhttps://www.ietf.org/id/draft-matsushima-spring-srv6-deployment-status-01.txt.
>>  
>> Most use-cases are expected to use very few SRv6 segments.
>>  
>> In some specific use-cases, one may desire to optimize the MTU usage further.
>> The SRv6 network programming solution and its SRH encapsulation also support 
>> for
>> this Optimization, through the uSID network instruction.
>>  
>> I do not see the need for any new encapsulation work.
>>  
>> Thanks
>>  
>> Regards … Zafar
>>  
>> From: spring  on behalf of Rob Shakir
>> 
>> Date: Sunday, August 4, 2019 at 5:04 PM
>> To: SPRING WG List 
>> Subject: [spring] Beyond SRv6.
>>  
>> Hi SPRING WG,
>>  
>> Over the last 5+ years, the IETF has developed Source Packet Routing in
>> NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6
>> (SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE.
>>  
>> These encapsulations are past WG last call (in IESG or RFC Editor).
>>  
>> During the SPRING WG meeting at IETF 105, two presentations were related to 
>> the
>> reduction of the size of the SID for IPv6 dataplane:
>>  •
>>  • SRv6+ / CRH --
>>  • https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04
>>  •
>>  •
>>  • uSID --
>>  •
>>  
>> https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01
>>  •
>>  
>> During the IETF week, two additional drafts have been proposed:
>>  •
>>  • https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00
>>  •
>>  •
>>  • https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03
>>  •
>>  
>> As we expressed during the meeting, it is important for the WG to understand
>> what the aims of additional encapsulations are. Thus, we think it is 
>> important
>> that the WG should first get to a common understanding on the requirements 
>> for
>> a new IPv6 data plane with a smaller SID - both from the perspective of
>> operators that are looking to deploy these technologies, and from that of the
>> software/hardware implementation.
>>  
>> Therefore, we would like to solicit network operators interested in SR over 
>> the
>> IPv6 data plane to briefly introduce their:
>>  •
>>  • use case (e.g. Fast Reroute, explicit routing/TE)
>>  •
>>  •
>>  • forwarding performance and scaling requirements
>>  •
>>  •
>>  • e.g., (number of nodes, network diameter,
>>  • number of SID required in max and average). For the latter, 
>> if possible us

Re: [spring] Beyond SRv6.

[Mark Smith]

On Sun., 1 Sep. 2019, 10:53 Fernando Gont,  wrote:

> On 1/9/19 03:32, Mark Smith wrote:
> > +1
> >
> > The value in using a commodity protocol like RFC 8200 compliant IPv6
> > for something like SR is that you're gaining from IPv6 being well
> > understood, widely implemented, widely deployed, widely interoperable,
> > widely tested, and the major bugs have very likely already been
> > discovered. It's cheaper to use something that it is already widely in
> > use.
> >
> > However, if you then try to stretch or go beyond expected use and
> > semantics, and violate protocol definitions, you're decommodifying the
> > commodity. You've lost significant or all of the value of using the
> > commodity protocol in the first place.
>
> I think it's simpler than that: it would be quite "interesting" to have
> one wg specify protocol A, and another wg that specifies protocol B that
> uses protocol A while violating the very spec of protocol A.
>


Well what I've described is the fundamental reason why that shouldn't
happen and why everybody should agree that it shouldn't happen.

At the point where an apparent limitation or constraint in one WG's
protocol is discovered by another WG, the latter WG should then consult
with the first WG on how to solve the problem that would be consistent with
the first WG's protocol and architecture.

If the behaviour doesn't comply with RFC 8200, it isn't IPv6 anymore.
Instead it is a proprietary and unofficial variant of it.

There's an RFC about this sort of thing. It also applies to different IETF
WGs.

Uncoordinated Protocol Development Considered Harmful

https://tools.ietf.org/html/rfc5704



Regards,
Mark.


>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fg...@si6networks.com
> PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Fernando Gont]

On 1/9/19 03:32, Mark Smith wrote:
> +1
> 
> The value in using a commodity protocol like RFC 8200 compliant IPv6
> for something like SR is that you're gaining from IPv6 being well
> understood, widely implemented, widely deployed, widely interoperable,
> widely tested, and the major bugs have very likely already been
> discovered. It's cheaper to use something that it is already widely in
> use.
> 
> However, if you then try to stretch or go beyond expected use and
> semantics, and violate protocol definitions, you're decommodifying the
> commodity. You've lost significant or all of the value of using the
> commodity protocol in the first place.

I think it's simpler than that: it would be quite "interesting" to have
one wg specify protocol A, and another wg that specifies protocol B that
uses protocol A while violating the very spec of protocol A.


-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Mark Smith]

+1

The value in using a commodity protocol like RFC 8200 compliant IPv6
for something like SR is that you're gaining from IPv6 being well
understood, widely implemented, widely deployed, widely interoperable,
widely tested, and the major bugs have very likely already been
discovered. It's cheaper to use something that it is already widely in
use.

However, if you then try to stretch or go beyond expected use and
semantics, and violate protocol definitions, you're decommodifying the
commodity. You've lost significant or all of the value of using the
commodity protocol in the first place.





On Sun, 1 Sep 2019 at 06:34, Ron Bonica
 wrote:
>
> Rob,
>
>
>
> The following are arguments for proceeding with SRv6+:
>
>
>
> Efficient forwarding with deep SID lists
> Operational Simplicity
> SRv6+ work may finish before SRv6
>
>
>
> Efficient forwarding with deep SID Lists
>
> 
>
>
>
> SR customers have stated a firm requirement to support SR paths that contain 
> 8 to 12 segments. They have also stated a requirement for implementations to 
> forward at line speed  and without consuming excessive overhead bandwidth.
>
>
>
> SRv6, as defined in draft-ietf-6man-segment-routing-header, cannot satisfy 
> these requirements. In order to support an SR path with 8 segments, SRv6 
> would require a 128-byte SRH. Even if ASICs could process such a long SRH at 
> line speed, the bandwidth overhead would be prohibitive.
>
>
>
> Therefore, one of the four solutions  that you mention below is required to 
> make SRv6 deployable. While draft-ietf-6man-segment-routing-header is close 
> to maturity, the four competing solutions mentioned below are equally mature 
> and should be given equal consideration.
>
>
>
> The four solutions are SRv6+, uSID, draft-li and draft-mirsky.
>
>
>
> Operational Simplicity
>
> -
>
> Network operators strive for operational simplicity. By loosely interpreting 
> (and sometimes bending) the requirements of RFCs 4291 and RFC 8200, SRv6 
> introduces architectural quirks that introduce operational complexity. The 
> following are architectural quirks of  draft-ietf-6man-segment-routing-header:
>
>
>
> The Segment Routing Header (SRH) serves purposes other than routing. 
> Therefore, the SRH is sometimes required for packets that traverse the 
> least-cost path from source to destination
> The SRH and the IPv6 Authentication Header are incompatible.
> The IPv6 destination address determines whether an SRH is valid and how it is 
> processed. For example, if the IPv6 destination address contains one locally 
> instantiated value, the SRH might be processed in one particular way, while 
> if the IPv6 destination address contains another locally instantiated value, 
> the SRH might be totally invalid.
>
>
>
> Draft-ietf-spring-srv6-network-programming  promises more architectural 
> quirks. For example:
>
>
>
> Segment endpoints can insert and/or delete IPv6 extension headers
> An IPv6 packet can contain two Segment Routing headers
> IPv6 packets are no longer self-describing. For example, the Next Header 
> Field in the SRH can carry a value of No Next Header, even though the SRH is 
> followed by Ethernet payload.
>
>
>
> Other emerging drafts promise still more architectural quirks. For example, 
> in draft-ali-6man-spring-srv6-oam, implementations need to examine the SRH 
> even when Segment Left equals zero. This is because the SRH has been 
> overloaded to carry OAM as well as routing information.
>
>
>
> Furthermore, draft-filsfils-spring-net-pgm-extension-srv6-usid requires 
> network operators to obtain address space and number their networks in a 
> particular way to make routing work.
>
>
>
> SRv6+ Work May Finish Before SRv6 work
>
> 
>
> SRv6+  has been implemented on LINUX and is being implemented on JUNOS. 
> Implementation experience demonstrates that specification is fairly complete. 
> For example, there is no need for an SRv6+ OAM document. It’s just IPv6 and 
> IPv6 OAM just works.
>
>
>
> Furthermore, the SRv6+ specifications adhere to a strict interpretation of 
> RFC 8200. Therefore, as they progress through the working group, they won’t 
> need to overcome the objections that are inevitably encountered when 
> stretching the interpretation of a specification that is so fundamental as 
> RFC 8200.
>
>
>
>   
> Thanks,
>
>   
> Ron
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: spring  On Behalf Of Rob Shakir
> Sent: Sunday, August 4, 2019 5:04 PM
> To: SPRING WG List 
> Subject: [spring] Beyond SRv6.
>
>
>
> Hi SPRING WG,
>
>
>
> Over the last 5+ years, the IETF has developed Source Packet Routing in 
> NetworkinG (SPRING) aka Segment Routing for both the