On Mon, Sep 9, 2019 at 8:16 AM Robert Raszuk <rob...@raszuk.net> 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. > > > > > > > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
