Hi, Tony: Aijun Wang China Telecom
> On Jan 13, 2022, at 02:16, Tony Li <[email protected]> wrote: > > > Hi Aijun, > >> >> It would seem to me that if you re-used existing TLVs, you could be adding >> subTLVs to carry any additional information. This would probably be a lot >> cleaner. >> [WAJ] Then we should update RFC5316, RFC5292, RFC3630 etc. It may also >> influence the existing deployment. >> There are also other situations that the RFC5316 and RFC5292 does not cover, >> for example, for the associated information that the edge computing wants to >> utilize etc. >> Start from the clean slate will be more acceptable? > > > 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. 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. > > Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
