Hi Aijun, >> Yes, I’m suggesting that you consider a way of using existing TLVs and >> adding subTLVs to them in order to convey the information. >> >> A big point of using TLV encoding in the first place is to provide >> extensibility. It would be a design error not to use it, when appropriate. >> Creating a new entity every time you add a feature leads to more complexity >> in the design and in the resulting code. > > [WAJ] If the proposed stub link follow the same rule as the existing link, we > can adding the new sub-TLV to achieve the goal. > But current it is not.
Could you please be more specific? AFAICT, the whole point is to inject stuff into the LSDB for TE purposes. > If we change or update the rule, we should consider the back compatibility or > the existing implementation. > The TLV type design assure it can be extended at the same TLV level, and if > the router can’t recognize, it just ignores. The process of existing TLV is > not influenced. Correct, if you use existing TLVs, and extend the semantics with subTLVs, you can be reasonably well assured of backward compatibility. New TLVs won’t do that for you. Tony _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
