> On Aug 9, 2024, at 10:44, Les Ginsberg (ginsberg) <[email protected]> wrote: > > Acee – > > Please note that the IS-IS registries already have a link to the RFC for each > and every codepoint – so what you suggest has already been done.
Of course I already know this (https://datatracker.ietf.org/person/[email protected]) and use the IANA registry as a resource when IETF document authors have been lazy and haven’t provided the attendant references. My suggestion is to add the references to make the document more consumable. From this protracted discussion, it seems that the MP-TLV encodings aren’t known to everyone. Acee > > Section 8.2 is only documenting the changes we want IANA to make (adding the > new column). > > Les > > From: Acee Lindem <[email protected] <mailto:[email protected]>> > Sent: Friday, August 9, 2024 6:49 AM > To: Aijun Wang <[email protected] <mailto:[email protected]>> > Cc: Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]>>; > Bruno Decraene <[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: Re: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - > 7/15/2024) > > 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] > <mailto:[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]
