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

[Robert Raszuk <[e-mail]>]

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

Many thx,
Robert.