Re: “SRV6+” complexity in forwarding

[Mark Smith <[e-mail]>]

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, <[e-mail]> 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) <[e-mail]>
> 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 <[e-mail]> 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) <[e-mail]>
> *Sent:* Monday, September 16, 2019 4:38 PM
> *To:* Ron Bonica <[e-mail]>
> *Cc:* Mark Smith <[e-mail]>; EXT - [e-mail] <
> [e-mail]>; [e-mail]; SPRING WG <
> [e-mail]>; 6man <[e-mail]>; Robert Raszuk <[e-mail]>;
> Rob Shakir <[e-mail]>; Tarek Saad <[e-mail]>
> *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=[e-mail]> wrote:
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>