Re: [spring] Regaining Focus on SRv6 and SRv6+

[Tom Herbert <[e-mail]>]

On Mon, Sep 9, 2019 at 8:16 AM Robert Raszuk <[e-mail]> wrote:
>
>
>> In any case, I don't believe option number space being exhausted is why TLVs are in SRV6 (if it was a problem, we'd want a general solution instead of point solution just for SRV6). The reasons why TLVs were need in SRV6, as opposed to using DO or HBH, are unclear to me. I think it's some feeling that there are options inherent to the SID list, it makes it easier to ignore options, and maybe some amount of "not invented here"
>
>
> I think it is useful to keep new functionality under one type - if for nothing else then for easy filtering on the domian egress and ingress.
>
> If you split this into N EH types then further nest some functions even further it becomes very difficult by the operator to filter it.
>
> To your very last point - if getting new EH type takes over 5 years - sorry but this is not a velocity any operator can accept in order to make his service better then competition the new paradigm of easily programmable data plane.
>
Robert,

You might want to consider the possibility that the length of time it
takes to standardize a protocol is proportional to its complexity and
divergence from existing standards. I believe that was the case of SRH
judging by the long discussion of it in 6man where much of that was
focused on peripheral functionality like the aforementioned TLVs as
well as trying to nail down the mutability requirements of the
protocol.

Tom

> Many thx,
> Robert.
>
>
>
>
>
>
>