Re: [spring] Beyond SRv6.

[Tom Herbert <[e-mail]>]

On Thu, Sep 12, 2019, 4:15 PM Robert Raszuk <[e-mail]> wrote:

> 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.
>

Robert,

Right, but isn't that precisely one of the arguments that 16 byte SIDs are
a problem? For instance, if my parsing buffer is 128 bytes then that allows
an SRH with at most four or maybe five SIDs if I'm not mistaken. It seems
like the smaller SID size of SRV6+, even with the DOH PSSI, option still
would produce smaller a header chain than SRV6 and thereby allow more
segments in the header.

Tom


> 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
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>