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

[Mark Smith <[e-mail]>]

On Thu, 19 Sep 2019 at 12:03, Ron Bonica <[e-mail]> wrote:
>
> If you want to push complexity to the edge, put it in a destination option that is processed at the edge.
>

Yes!

It might seem like "forwarding" is taking a packet in on one
interface, doing something to it, and then sending it out another.

RFC 8200's / IPv6's definition for forwarding or "routing" is much more strict:

" router       a node that forwards IPv6 packets not explicitly
                addressed to itself.  (See Note below.)

   host         any node that is not a router.  (See Note below.)

   node         a device that implements IPv6."


(Note at end for completeness; it doesn't contradict these definitions)

So when a packet reaches a device, which could be "in the network",
where the device has the address that matches the DA in the packet,
the packet is being host processed.

The processing to occur at that device with the packet's DA is
determined by a Destination Option and/or the upper transport layer
protocol headers in the packet's payload.

These RFC 8200 definitions are functional. That means that the device
we all probably imagine if we think of the term "router" is actually
performing both the above router function (forwarding plane) and the
host function (control plane).

ASICs could also perform some of these these host functions when the
packet arrives at the device with the packet's DA to get higher
performance than a general purpose CPU could provide.

Regards,
Mark.


"   Note: it is possible for a device with multiple interfaces to be
   configured to forward non-self-destined packets arriving from some
   set (fewer than all) of its interfaces and to discard non-self-
   destined packets arriving from its other interfaces.  Such a device
   must obey the protocol requirements for routers when receiving
   packets from, and interacting with neighbors over, the former
   (forwarding) interfaces.  It must obey the protocol requirements for
   hosts when receiving packets from, and interacting with neighbors
   over, the latter (non-forwarding) interfaces.")




> Ron
> Sent from my phone
>
>
> On Sep 18, 2019, at 8:33 PM, Mark Smith <[e-mail]> wrote:
>
>
>
> 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> 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