Likewise, SP core routers would ignore the PSSI and wouldn’t even see the PPSI.
Ron
From: Dirk Steinberg <[email protected]>
Sent: Wednesday, September 18, 2019 7:40 PM
To: Tom Herbert <[email protected]>
Cc: Darren Dukes (ddukes) <[email protected]>; [email protected]; SPRING WG
<[email protected]>; 6man <[email protected]>; Robert Raszuk <[email protected]>; Ron
Bonica <[email protected]>; Rob Shakir <[email protected]>; Tarek Saad
<[email protected]>
Subject: Re: [spring] “SRV6+” complexity in forwarding
SRv6 does not require TLV processing for normal forwarding (use case: SP core).
- Dirk
On Wed, Sep 18, 2019 at 5:57 PM Tom Herbert
<[email protected]<mailto:[email protected]>> wrote:
On Wed, Sep 18, 2019 at 6:42 AM Darren Dukes (ddukes)
<[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>>
> Sent: Monday, September 16, 2019 4:38 PM
> To: Ron Bonica <[email protected]<mailto:[email protected]>>
> Cc: Mark Smith <[email protected]<mailto:[email protected]>>; EXT -
> [email protected]<mailto:[email protected]>
> <[email protected]<mailto:[email protected]>>;
> [email protected]<mailto:[email protected]>; SPRING WG
> <[email protected]<mailto:[email protected]>>; 6man
> <[email protected]<mailto:[email protected]>>; Robert Raszuk
> <[email protected]<mailto:[email protected]>>; Rob Shakir
> <[email protected]<mailto:[email protected]>>; Tarek Saad
> <[email protected]<mailto:[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]<mailto:[email protected]>>
> wrote:
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]<mailto:[email protected]>
> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!WrHuFvaysLbs0yJ61FHJgdG3Gs5uwrUZm7LBOvafWNAVhbtJL5grVfoU-RGWVqzi$>
> --------------------------------------------------------------------
_______________________________________________
spring mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!WrHuFvaysLbs0yJ61FHJgdG3Gs5uwrUZm7LBOvafWNAVhbtJL5grVfoU-Z5e9NFo$>
Juniper Business Use Only
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
