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) <ddu...@cisco.com> 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 <rbon...@juniper.net> 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) <ddu...@cisco.com> >> Sent: Monday, September 16, 2019 4:38 PM >> To: Ron Bonica <rbon...@juniper.net> >> Cc: Mark Smith <markzzzsm...@gmail.com>; EXT - daniel.bern...@bell.ca >> <daniel.bern...@bell.ca>; xie...@chinatelecom.cn; SPRING WG >> <spring@ietf.org>; 6man <6...@ietf.org>; Robert Raszuk <rob...@raszuk.net>; >> Rob Shakir <ro...@google.com>; Tarek Saad <tsaad....@gmail.com> >> 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 >> <rbonica=40juniper....@dmarc.ietf.org> wrote: > > -------------------------------------------------------------------- > 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
