Ketan – To add to what Tony has said…one thing which we did not want this draft to become was for it to be the place where a definition of the “key” for every TLV was defined. Perhaps in the text you quote “MUST” should not be capitalized as we are simply describing the generic logic required.
It is also worth pointing out that this draft is not defining new behavior nor is it extending the protocol in any way. The use of multiple TLVs for a given object is already implemented and deployed by multiple vendors and does not require any protocol extensions. Given the increasing need for using multiple TLVs, it seemed prudent to document the generic behavior – which is the motivation for this draft. But there is no intent to discuss all possible TLVs to which this behavior might apply. If you expect that then I think we are not in sync. It has been discussed that the most common cases where multiple TLVs are likely to be required are the Prefix Reachability TLVs and the IS Neighbor TLVs. As such, it might not be a bad idea to discuss these two cases (the draft already discusses Prefix Reachability). Les From: Ketan Talaulikar <ketant.i...@gmail.com> Sent: Wednesday, June 29, 2022 9:33 AM To: Tony Li <tony...@tony.li> Cc: draft-pkaneria-lsr-multi-...@ietf.org; lsr <lsr@ietf.org> Subject: Re: Handling multiple Extended IS Reachability TLVs for a link Hi Tony, No. It does not work. Take the following text from Sec 4. If this is insufficient sub-TLV space, then the node MAY advertise additional instances of the Extended IS Reachability TLV. The key information MUST be replicated identically and the additional sub-TLV space may be populated with additional information. The complete information for a given key in such cases is the joined set of all the carried information under the key in all the TLV instances. There is a normative MUST there, but the "key information" is unspecified. Without that information these rules would not be really useful for implementation, would they? I agree with the challenge of trying to catalog "keys" and "rules" on a per TLV/sub-TLV basis. Perhaps starting with the more widely used TLVs/sub-TLVs that are likely to exceed limits would be better than not covering any of them? Thanks, Ketan On Wed, Jun 29, 2022 at 9:53 PM Tony Li <tony...@tony.li<mailto:tony...@tony.li>> wrote: Hi Ketan, We are hoping to not be that detailed in this document. As soon as we become a catalog of LSPs, then the applicability of our statements is weakened with respect to TLVs that aren’t in the catalog. What we’re trying to accomplish is to write some general rules that we all understand that apply uniformly across all TLVs that don’t specify their own overflow mechanisms. Does this work for you? Tony > On Jun 29, 2022, at 6:47 AM, Ketan Talaulikar > <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>> wrote: > > Hello Authors, > > I was pointed to your draft while looking around for some clarifications on > how information for a single object can be split across multiple TLVs in ISIS. > > Having gone through your document, I believe it is very useful and I am glad > to see that you have taken on this work. > > While the problem is generic, there is some part of the solution that is not > generic - i.e. we may need to get into individual TLVs/sub-TLVs specifics. > > To take an example, the draft talks about "keys" and there is a challenge > that "keys" for certain objects are not formally specified in ISIS specs. > E.g., the "keys" for Extended IS Reachability would need to also include the > local/remote addresses and/or the local/remote link-IDs. > > I wanted to check if the authors of this document are planning to tackle > these aspects as well. > > Thanks, > Ketan >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
