This CISCO LIVE dives deeper into Cisco’s SRv6 implementation. https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2019/pdf/BRKSPG-3001.pdf
They go through all the SRV6 programmability End SID and SR insertion. I have to read through to see if Cisco’s Ti-LFA implementation requires so many EH’s Gyan Sent from my iPhone > On Sep 18, 2019, at 7:56 PM, Gyan Mishra <[email protected]> wrote: > > Daren > > This is from 2019 CISCO Live presentation > > https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2019/pdf/BRKMPL-2132.pdf > > IETF Standardization > • The work started by Cisco in 2014 > • Significant industry collaboration > • There are over SRv6 50 IETF documents > • The work spans over 13 working groups > • SRv6 header has been last called > • Network Programming is a Working Group document • Multivendor Consensus > #CLUS © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public > > Cisco Deployments > • Softbank > • Cisco Supports SoftBank on First SRv6 Deployment in Prep for 5G • > Nationwide SRv6 network carrying live traffic > • Iliad > • Nationwide SRv6 network to provide a new mobile offering in Italy • The > SRv6 backbone is based on Cisco ASR 9000 and NCS 5500 • All the cell site > routers are SRv6 capable Iliad's NodeBox > • China Telecom > • Multi-city SRv6 network > > Gyan > > Sent from my iPhone > >> On Sep 18, 2019, at 9:41 AM, Darren Dukes (ddukes) <[email protected]> wrote: >> >> Hi Ron. >> >> I summarized my argument as follows: >> "Regardless of ASIC capabilities there are two performance penalties you >> will not escape with PSSI+CRH+PPSI: TLV parsing and multiple lookups.” >> >> You’ve confirmed this additional overhead for "SRv6+". Thanks. >> >> You then say "So long as the ASIC can process enough packets per second to >> saturate the line cards, we are forwarding at full line rate." >> >> Yes this is true, but we can conclude: The complexity of "SRv6+" requires >> ASICs do much more work per packet vs SRv6. >> >> Thanks >> Darren >> >> >>> On Sep 16, 2019, at 9:59 PM, Ron Bonica <[email protected]> wrote: >>> >>> Hi Darren, >>> >>> I think that your argument can be summarized as follows: >>> >>> SRv6 requires only two FIB searches >>> SRv6+ requires 4 or more FIB searches >>> Therefore, SRv6+ cannot possibly forward at line speed >>> >>> Have I summarized your argument correctly? If not, please set me straight. >>> If so, please read on. >>> >>> First, SRv6+ never requires more than 4 FIB searches. The DOH that precedes >>> the CRH contains, at most, one PSSI. Therefore SRv6+ requires four FIB >>> searches, at most. >>> >>> Second, SRv6+ only requires 4 FIB searches the following case: >>> >>> The packet contains two instances of the DOH. (Most use-cases require only >>> one.) >>> The processing node is configured to process the PSSI. (Many ASIC-based >>> devices, because of their role in the network, won’t support any per >>> segment service instructions. This nodes will be configured to ignore the >>> PSSI. That is why it is optional.) >>> >>> So, in most use-cases, SRv6+ requires only 3 FIB searches. >>> >>> So, you might now argue that: >>> >>> SRv6 requires only two FIB searches >>> SRv6+ requires three and sometimes four FIB searches >>> Therefore, SRv6+ cannot possibly forward at line speed >>> >>> Here, some slightly deeper thought might be required. A platform has two >>> relevant resources: >>> >>> A route lookup ASIC, that can process some number of packets per second >>> Some number of interfaces, that can forward some number of bits per second >>> >>> So long as the ASIC can process enough packets per second to saturate the >>> line cards, we are forwarding at full line rate. So long as a platform has >>> a sufficiently capable ASIC, it will be able to forward at line speed. But >>> it’s a matter of how the platform is designed. If the ASIC is not >>> sufficiently capable, of course, it will not forward at line speed. >>> >>> In your email, you say that I have been asked several times to report on >>> the state of Juniper’s SRv6+ implementation. While I cannot provide >>> details, you can assume that we wouldn’t be working on this if we thought >>> that performance was going to be sub-optimal. >>> >>> You also suggest that Juniper’s is the only implementation. Are you sure >>> that this is correct? >>> >>> >>> Ron >>> >>> >>> >>> >>> >>> Juniper Business Use Only >>> From: Darren Dukes (ddukes) <[email protected]> >>> Sent: Monday, September 16, 2019 4:38 PM >>> To: Ron Bonica <[email protected]> >>> Cc: Mark Smith <[email protected]>; EXT - [email protected] >>> <[email protected]>; [email protected]; SPRING WG >>> <[email protected]>; 6man <[email protected]>; Robert Raszuk <[email protected]>; >>> Rob Shakir <[email protected]>; Tarek Saad <[email protected]> >>> Subject: “SRV6+” complexity in forwarding >>> >>> Hi Ron, I agree ASICs are always improving, indeed this is evident in the >>> number of successful SRv6 deployments and multiple vendor implementations >>> at line rate on merchant silicon, and multiple vendor ASICs. >>> >>> Is “SRv6+” (PSSI+CRH+PPSI) implemented and deployed at line rate? >>> You’ve been asked this several times. Since you’re the only implementor(?) >>> and one operator is claiming deployment or testing, I am curious. >>> >>> Regardless of ASIC capabilities there are two performance penalties you >>> will not escape with PSSI+CRH+PPSI: TLV parsing and multiple lookups. >>> >>> Requiring all segments in a CRH segment list to process an arbitrary length >>> DOH+set of PSSI’s and other options is always very expensive. >>> - It is expensive in SRAM as previously discussed in these threads. >>> - It is expensive in parsing logic to know and process a set of TLVs in any >>> ASIC or NP. >>> >>> Spreading PSSI, CRH, PPSI operations in multiple headers and multiple >>> identifiers you now have multiple lookups at a node. >>> 1 - lookup destination address >>> 2 - lookup one or more PSSI and future destination options. >>> 3 - lookup the CRH label or PPSI label. >>> 4 - lookup new destination address >>> >>> Compare this with SRv6. >>> 1 - lookup destination address >>> 2 - lookup new destination address >>> >>> While ASICs are more capable and will continue to be more capable, these >>> technical performance problems you introduce with PSSI+CRH+PPSI will not go >>> away. >>> >>> Darren >>> >>> >>> On Sep 12, 2019, at 12:34 PM, Ron Bonica >>> <[email protected]> wrote: >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> --------------------------------------------------------------------
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
