+1 Agree. Sent from my iPhone
> On Sep 18, 2019, at 5:32 PM, Mark Smith <[email protected]> wrote: > > > >> On Thu, 19 Sep 2019, 09:40 Dirk Steinberg, <[email protected]> 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 <[email protected]> wrote: >>> On Wed, Sep 18, 2019 at 6:42 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.. >>> > >>> >>> 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 <[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 >> _______________________________________________ >> spring mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
