*Dear Alexander, * On Thu, Sep 5, 2019 at 10:38 AM Alexander Vainshtein < alexander.vainsht...@ecitele.com> wrote:
> Robert, > > I fully agree with you that RFC 8200 does not prevent a node that owns the > destination address of the IPv6 header to insert EH. > Great - Are we done with this "EH insertion" debate now ? :) > However, RFCV 8200 recommends (?) not to have more than one EH header of > any type (excluding the Destination Options header that can occur no more > than twice > – once before the Routing header and once again – before the upper layer > header). I.e., two Routing Headers (of any type) in the same packet are, if > not prohibited, then, at least, not recommended. > SRH is TLV based could be as long as needed. However sometimes it could be useful from processing pov to decouple some functions to be placed in separate SRHs for example to clearly filter/boost processing just by looking at the flags field. But it is just optimization. Sure one could ask for new type (or bunch of types) if this makes any technical merit. Btw since you point out that Destination Options also only allow to be present twice we have the same problem there. *Dear Zhenqiang, * Would you recommend to define new type of EH for FRR protection ? Say PRH (Protection Routing Header) extension header with type say 5 ? Does it make really sense to define a new type just from bureaucracy pov for each possible application - even if all functionality would still be identical if we would have the same type 4 carry the data ? Does it make any sense to do that from hardware processing point of view - to modify it to recognize bunch of types and still do exact same processing on them ? Cheers, R.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
