Re: [spring] Beyond SRv6.

[Robert Raszuk <[e-mail]>]

Hi Brian,

> To what extent is this behind the present argument?

If you are calling elephant and ASIC/FPGA - that was not my reasoning at
all.

Regardless if you are processing packets by a fixed burned ASIC or
programmable NP the packet must be read into DRAM and its header stored in
SRAM during processing - that is I hope pretty clear to everyone. What
matters is the amount of SRAM you have at your disposal and then how far
apart are elements required for processing a given feature.

I am full supporter of NPs and actually just fyi in my MS thesis I designed
and prototyped Altera MAX FPGA based router :).  If one can afford for
required line rate speed rating and total box throughput using NP based
systems is much better investment. This is more for flexibility (field
programmability) and software updates for bug fixes and new features then
anything to do how we should or should not design the packet headers in
data plane protocols.

In the comment below I was not really making an observation that when you
separate multiple DOHs from CRH you can not process things - you sure can
as all such EHs actually carry opaque to each other elements. I was however
observing the fact that functions may require parameters which are not
supported by DOHs as well as observed earlier that if you are to make sure
packets entering your domain or leaving "escaping" your domain contain any
unexpected headers it is much easier to set such ACL onces instead of keep
updating it every time new draft gets published and new type gets allocated
for another SRv6+ Destination Option.

Many thx,
Robert


On Fri, Sep 13, 2019 at 12:32 AM Brian E Carpenter <
[e-mail]> wrote:

> Robert,
>
> > But what is most important that common hardware reads just entire
> > header then starts processing. So it really makes much more sense to
> > encode SR SIDs and related functions and their parameters in the same
> > EH rather then scatter them around.
>
> Sorry to get all philosophical, but it seems to me that there's another
> elephant in the room here (and he's been around for twenty years or so).
> There seems to be an assumption that we should design on the assumption
> that fast path processing is done by ASICs or FPGAs, so header formats
> should be rigid enough that conditional or linked-list processing can
> be largely avoided. I've been lectured on the bad design of IPv6 extension
> headers in a way that only makes sense from an ASIC or FPGA viewpoint.
>
> But anybody who's building the fast path using a network processor doesn't
> have that constraint and can use the existing extension header design
> happily enough.
>
> To what extent is this behind the present argument?
>
> Regards
>    Brian Carpenter