Speaking as a WG member: Hi Aijun, Les, Bruno,
While my completely unbiased opinion is that the world would be a better place if everyone migrated to OSPFv3 (https://datatracker.ietf.org/doc/rfc5340/) with Extended LSAs (https://datatracker.ietf.org/doc/rfc8362/) and at the risk of further muddying the waters, I’ll offer a compromise here. Perhaps, we could just add RFC references to MP-TLVs, MP-sub-TLVs, and MP-sub-….TLVs in section 8.2. That way, if anybody had any questions as to the encoding of these MP-TLVs (including the keys), they could simply access the html version of the document and click their way to enlightenment. Thanks, Acee > On Aug 9, 2024, at 05:14, Aijun Wang <[email protected]> wrote: > > Hi, Les: > > Please reread Bruno’s questions and your responses。 I highlight the important > parts for your reference. > > It’s not clear to me whether you mean “all link identifiers” advertised in > the first part (which would seem to match your above definition of the key) > or “any (number) of links identifiers”. > > That’s the typical example where the lack of a formal definition of the key > for a (all) TLVs may brings interop issue. One implementer could believe that > all link identifiers are needed in all parts, while another could believe > that a subset is enough in some cases. > [LES:] We mean exactly what we say - "at least one". > It is not necessary to advertise all of the link identifiers in each TLV in > order to correctly identify the two TLVs as having the same key. > > You said “at least one”, but not “all link identifiers” is necessary. Then, > the sender can select any of them to be included. > Even one sender can keep selecting only the same link identifier as the > “key”, other sender from different vendor may select another, should the > receivers accept one, discard another? Or depend on their own justification? > Won’t these undefined possibilities lead no interoperability? > > Best Regards > > Aijun Wang > China Telecom > > 发件人: Les Ginsberg (ginsberg) [mailto:[email protected]] > 发送时间: 2024年8月9日 15:19 > 收件人: Aijun Wang <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]>; 'Yingzhen Qu' <[email protected] > <mailto:[email protected]>>; 'lsr' <[email protected] > <mailto:[email protected]>>; 'lsr-chairs' <[email protected] > <mailto:[email protected]>> > 主题: RE: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - > 7/15/2024) > > For the benefit of the WG…Aijun’s example is inconsistent with what the > muti-tlv draft states as well as the example I provided in my response to > Bruno. > > The key phrase is: “The following key information MUST be replicated…” > > In the example Aijun provided (which is NOT the same as the example I > provided) there is no replication of any of the possible identifiers: > > <snip> > …if some of the segmented TLV includes (B System ID, Local/Remote Link IDs) , > but other includes (B System ID, IPv4 neighbor address), > <end snip> > > So Aijun’s example is wrong and he is not quoting me – despite his claims of > doing so. > > Les > > > From: Aijun Wang <[email protected] > <mailto:[email protected]>> > Sent: Friday, August 9, 2024 12:01 AM > To: Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]>; 'Yingzhen Qu' > <[email protected] <mailto:[email protected]>>; 'lsr' > <[email protected] <mailto:[email protected]>>; 'lsr-chairs' <[email protected] > <mailto:[email protected]>> > Subject: 答复: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - > 7/15/2024) > > Hi, Chris: > > Let’s give you answer for your question, based on the responses from Les: > > > [WAJ] Ambiguity exists in almost for every multi-TLV capable code points. > > [Chris]I guess this goes with your assertion that no-one can figure this out. > I think people disagree with you here so perhaps a couple examples of the > readily available ambiguity would help? > > 【WAJ】Please see the following example provided by Les himself, and also > question to Les: > > How about the receiver to concatenate the multi-part TLVs together for one > link if some of the segmented TLV includes (B System ID, Local/Remote Link > IDs) , but other includes (B System ID, IPv4 neighbor address), and another > includes (B System ID, IPv6 interface address)? > Or treat them as for information for different links of the neighbor (B > System ID)? > > From this example, we can see there will be how much chaos will be emerged > for the undefined “key” field part of the one code point. > > Anyone understands the process of segment/concatenate process should be aware > the exact “key” field, why do we argue it constantly for this obvious > requirements? > > > Best Regards > > Aijun Wang > China Telecom > > > > > “The following key information MUST be replicated in each of the additional > Extended IS Reachability TLVs: > 7 octets of system ID and pseudonode number > At least one of the following identifiers” > It’s not clear to me whether you mean “all link identifiers” advertised in > the first part (which would seem to match your above definition of the key) > or “any (number) of links identifiers”. > > That’s the typical example where the lack of a formal definition of the key > for a (all) TLVs may brings interop issue. One implementer could believe that > all link identifiers are needed in all parts, while another could believe > that a subset is enough in some cases. > [LES:] We mean exactly what we say - "at least one". > It is not necessary to advertise all of the link identifiers in each TLV in > order to correctly identify the two TLVs as having the same key. > > There is a good deal that could be said here - but it is not the province of > this document to do so. The issue you raise is applicable to a single TLV as > well. > For example, A-B have an adjacency and advertise an IS-Neighbor TLV, the > following works for the purposes of doing TWCC: > > A advertises: (B system-id, IPv4 endpoint addresses, Local/Remote Link IDs) > B advertises: ( A system-id, Local/Remote IDs) > > If it takes two TLVs for A to advertise all of the link attribute information > associated with the adjacency to B, A could advertise: > > TLV #1: (B system-id, IPv4 endpoint addresses, Local/Remote Link IDs) > TLV #2: (B system-id, Local/Remote Link IDs) > > Receivers can still correctly identify the two TLVs as being associated with > the same adjacency to B. > You may wish this was written down in some document - but multi-tlv draft is > not the right place to do this. If needed, some update to RFC 5305 (et al) > could be done. That is a decision for the WG to make.
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
