None of that means there isn't room for improvement, or that lessons that can be learned and applied a second time around (just need to watch out for second system syndrome). The first version isn't always if ever the best version.
On Thu, 19 Sep 2019, 09:57 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 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > 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
