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]<mailto:[email protected]>>
wrote:
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
