Re: [spring] “SRV6+” complexity in forwarding

[Mark Smith <[e-mail]>]

On Thu, 19 Sep 2019, 09:40 Dirk Steinberg, <[e-mail]> 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 <[e-mail]> wrote:
>
>> On Wed, Sep 18, 2019 at 6:42 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.
>> >
>>
>> 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 <[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]..org <[e-mail]>> wrote:
>> >
>> >
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > [e-mail]
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>>
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
>>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>