Ketan/Zhibo –
It is worth reemphasizing that there are no protocol extensions used or
required for supporting multi-part-TLVs.
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). 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.
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 <huzh...@huawei.com>
Sent: Thursday, June 30, 2022 12:43 AM
To: Ketan Talaulikar <ketant.i...@gmail.com>; Les Ginsberg (ginsberg)
<ginsb...@cisco.com>
Cc: Tony Li <tony...@tony.li>; draft-pkaneria-lsr-multi-...@ietf.org; lsr
<lsr@ietf.org>
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:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar
Sent: Thursday, June 30, 2022 11:15 AM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Cc: Tony Li <tony...@tony.li<mailto:tony...@tony.li>>;
draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>;
lsr <lsr@ietf.org<mailto:lsr@ietf.org>>
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)
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> 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 <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>>
Sent: Wednesday, June 29, 2022 9:33 AM
To: Tony Li <tony...@tony.li<mailto:tony...@tony.li>>
Cc:
draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>;
lsr <lsr@ietf.org<mailto: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
