On Thu, 19 Sep 2019, 09:40 Dirk Steinberg, <d...@lapishills.com> wrote:
> SRv6 does not require TLV processing for normal forwarding (use case: SP > core). > +1 The Internet scales because complexity is pushed towards the edges. > - Dirk > > On Wed, Sep 18, 2019 at 5:57 PM Tom Herbert <t...@herbertland.com> wrote: > >> On Wed, Sep 18, 2019 at 6:42 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.. >> > >> >> Darren, >> >> How does one escape the performance penalty of TLV processing in SRV6? >> >> Tom >> >> >> > 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 <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 >> > _______________________________________________ > 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
