Hi Les, Please check inline below for a few responses with KT.
On Fri, Jul 1, 2022 at 10:35 AM Les Ginsberg (ginsberg) <[email protected]> wrote: > Ketan – > > > > You have the wrong idea about this draft. > > > > The draft is NOT introducing multi-part-TLV support to IS-IS – nor is it > altering the mechanisms available to be used when sending multi-part-TLVs. > > The protocol has always had the capability to support this and there are > multiple known implementations already deployed which have implemented > multi-part-TLV support and they are not subject to whatever restrictions > you (or anyone) might think should be used. > > It is too late (and unnecessary) to introduce such ideas. > > > > What this draft is doing is describing the correct procedures to be used > when advertising multi-part-TLVs – but it is not limiting any of the > existing valid options which may already be in use. > > > > As far as your proposal (which for me did not require clarification – I > already understood the intended scope), I would not choose to do things > that way even if we had the flexibility to do so. > > > > As an implementor, I would not want to encode the link identifiers one way > if I had only one TLV but another if I had more than one. That adds > additional complexity to the implementation. > > > > And your idea that link ids only could be used in “the > non-first-part-TLVs” has fatal flaws. > > For one thing, you can’t tell which of the TLVs is the “first one”. It > could be that you initially sent a TLV in LSP #10. Later, when you needed > additional space you created a second TLV but there was no room in LSP #10 > – but there was room in LSP #5. > > Point is, in IS-IS order of advertisement does not matter. > KT> My mistake. I should have said all identifiers in "one" of the part-TLVs while only Local-Remote-ID sub-TLV in all part-TLVs. > > > In order to be able to match the two TLVs on reception, it is necessary to > have at least one set of identifiers in common in the TLVs. If one of the > TLVs only has link ids, then all the TLVs have to have link ids. > KT> Yes, that was my proposal. Thanks, Ketan > Which forces all implementations to send link ids all the time. And not > all implementations today choose to send link ids all the time – no reason > to force them to do so. > > And I could go on… > > > > Hopefully I have made my point. > KT> Thanks for the discussion. It shares the views of the two of us with the WG and I'll let others in the WG share their as the document progresses. Thanks, Ketan > > > Les > > > > > > > > *From:* Ketan Talaulikar <[email protected]> > *Sent:* Thursday, June 30, 2022 8:57 PM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* Huzhibo <[email protected]>; Tony Li <[email protected]>; > [email protected]; lsr <[email protected]> > *Subject:* Re: [Lsr] Handling multiple Extended IS Reachability TLVs for > a link > > > > Hi Les, > > > > Please check inline below for some clarifications with KT2. > > > > > > On Thu, Jun 30, 2022 at 10:57 PM Les Ginsberg (ginsberg) < > [email protected]> wrote: > > Ketan – > > > > Inline. > > > > *From:* Ketan Talaulikar <[email protected]> > *Sent:* Thursday, June 30, 2022 10:12 AM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* Huzhibo <[email protected]>; Tony Li <[email protected]>; > [email protected]; lsr <[email protected]> > *Subject:* Re: [Lsr] Handling multiple Extended IS Reachability TLVs for > a link > > > > Hi Les, > > > > Please check inline below. > > > > On Thu, Jun 30, 2022 at 10:13 PM Les Ginsberg (ginsberg) < > [email protected]> wrote: > > Ketan/Zhibo – > > > > It is worth reemphasizing that there are no protocol extensions used or > required for supporting multi-part-TLVs. > > > > KT> I was referring to protocol behavior and requirements related to this > handling. In my view, that is an "extension" of the protocol behavior - but > we can agree to disagree on this point? :-) I see that the draft is > standards-track and I am good with it. > > > > This isn’t speculation – this is based on actual implementation. > > > > As to keys, the draft already discusses the key for prefix advertisements. > As the key in that case is the fixed portion of the TLV advertisement, any > omission would make the TLV syntactically invalid. > > > > For the link case, what is required is at least one of the link > identifiers (IPv4 endpoint addresses, IPv6 endpoint addresses, and/or Link > IDs). > > > > KT> Agree and this is something worth discussing. My suggestion would be > that Local-Remote-ID is recommended as the only "key" that is required to > be repeated across TLV instances to achieve the most compactness. Remote ID > could be 0 when it cannot be determined. IPv6 addresses would take up more > space and also, there can be multiple instances of the IP "endpoint" > addresses so using them as "key" might make implementations more complex. > > > > *[LES:] No – I absolutely don’t want to do that. You would be creating > interoperability problems by this proposal – and unnecessarily so.* > > *Some implementations today send Link IDs all the time. Some only send > them when an interface is unnumbered. It should not matter.* > > *And note that this applies to interoperability even without > multi-part-TLVs i.e., you would be defining a restriction that does not > apply today.* > > > > KT2> I am not suggesting that the link addresses are not considered "link > identifiers". So there is no cause for any issues for single-part-TLVs. My > point was that when we have multi-part-TLVs, only the local-remote-IDs be > the only sub-TLV that need repetition in all the non-first-part-TLVs. The > link addresses are still carried as link identifiers when available (i.e. > when not unnumbered) in the first part. > > > > Just want to make sure that my proposal is specific to multi-part. > > > > Thanks, > > Ketan > > > > > > * Les* > > These sub-TLVs were defined many years ago and are required for support of > all forms of TE as well as other technologies (e.g., Segment Routing). I > would not object to some discussion of this case in the draft, but the idea > that this is in some way “new” or might not be understood by implementors > is not credible to me. If you aren’t sending these identifiers already then > you would never be able to support TE, Segment Routing, etc. > > > > KT> I am glad to hear that these points will be discussed. > > > > Thanks, > > Ketan > > > > > > It is also worth noting that there are existing RFCs that have already > explicitly specified the use of multi-part-TLVs. These include: > > > > RFC 5307 SRLG TLV > > RFC 7981 Router Capability TLV > > > > Les > > > > *From:* Huzhibo <[email protected]> > *Sent:* Thursday, June 30, 2022 12:43 AM > *To:* Ketan Talaulikar <[email protected]>; Les Ginsberg (ginsberg) < > [email protected]> > *Cc:* Tony Li <[email protected]>; [email protected]; > lsr <[email protected]> > *Subject:* RE: [Lsr] Handling multiple Extended IS Reachability TLVs for > a link > > > > Hi Everyone: > > > > I think it is necessary to specify the key of the TLV and the information > that needs to be carried repeatedly in this document. I am not sure that > everyone has the same understanding of the key. If different vendors have > different understandings of the key, there may be interoperability problems. > > > > Thanks > > > > Zhibo > > > > *From:* Lsr [mailto:[email protected] <[email protected]>] *On > Behalf Of *Ketan Talaulikar > *Sent:* Thursday, June 30, 2022 11:15 AM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* Tony Li <[email protected]>; [email protected]; > lsr <[email protected]> > *Subject:* Re: [Lsr] Handling multiple Extended IS Reachability TLVs for > a link > > > > Hi Les, > > > > Please check inline below. > > > > On Wed, Jun 29, 2022 at 11:05 PM Les Ginsberg (ginsberg) < > [email protected]> wrote: > > 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. > > > > KT> I agree. > > > > Perhaps in the text you quote “MUST” should not be capitalized as we are > simply describing the generic logic required. > > > > KT> I think it would be better for the first part of the draft to just > describe the general rules/logic for handling these cases. This part should > stand on its own. Whether it needs to be normative or not, can be discussed > later. IMHO, if normative language is better and the text can be worked out > as the document progresses. > > > > > > It is also worth pointing out that this draft is not defining new behavior > nor is it extending the protocol in any way. > > > > KT> I don't fully agree with that ... > > > > The use of multiple TLVs for a given object is already implemented and > deployed by multiple vendors and does not require any protocol extensions. > > > > KT> I agree that this problem has been around for some time now. I agree > that there are implementations that have "worked out a solution" and that > they are also deployed. There aren't that many ways to tackle this after > all ;-) ... that said, this handling is not yet specified in an RFC or ISO > document, right? If not then, IMHO, this is an extension of the protocol > behavior. > > > > Given the increasing need for using multiple TLVs, it seemed prudent to > document the generic behavior – which is the motivation for this draft. > > > > KT> Agree. Also agree at a high level with the proposal. Again, there are > not too many different ways to go about this :-) > > > > But there is no intent to discuss all possible TLVs to which this behavior > might apply. > > > > KT> Agree > > > > 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). > > > > KT> For most TLVs/sub-TLVs, I believe the "keys" are part of the fixed > form and hence the problem (unspecified keys) that I mentioned in my first > email on this thread does not arise. There are though, some TLVs, where the > keys remain unspecified and I strongly believe that (at least the most > important of those?) need to be tackled in this document for it to help > implementors. > > > > Thanks, > > Ketan > > > > > > Les > > > > *From:* Ketan Talaulikar <[email protected]> > *Sent:* Wednesday, June 29, 2022 9:33 AM > *To:* Tony Li <[email protected]> > *Cc:* [email protected]; lsr <[email protected]> > *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 <[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
