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 <[email protected]> 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 <[email protected]> > 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
