> 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.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
