Les - > On Aug 9, 2024, at 1:16 PM, Les Ginsberg (ginsberg) <[email protected]> > wrote: > > Acee – > There is no such thing as “MP-TLV encodings”.
Let's not play semantic games - the multi-TLV document refers to MP-TLVs. > There are only the encodings for each TLV which are defined in the respective > RFCs that defined that code point. > As has been emphasized the multi-tlv draft makes no changes to TLV encodings. > (I am sure you understand this – but I needed to repeat in order to fully > respond to your comment.) > The IANA section is only providing instructions to IANA as to what changes > are required to the registries. > It is not a replacement for the registry nor intended to be a duplicate of > the registry. > This is standard practice. > So I don’t see the point of duplicating information which is already in the > registry. Well, then put them in a new section that only includes the MP-TLVs and the references. Since you are so dead set on anything specified more than once, I was just trying to save you work on this Herculean task. Acee > Les > From: Acee Lindem <[email protected]> > Sent: Friday, August 9, 2024 8:01 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Aijun Wang <[email protected]>; Bruno Decraene > <[email protected]>; Yingzhen Qu <[email protected]>; lsr > <[email protected]>; lsr-chairs <[email protected]> > Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - > 7/15/2024) > > > 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]> > Sent: Friday, August 9, 2024 6:49 AM > To: Aijun Wang <[email protected]> > Cc: Les Ginsberg (ginsberg) <[email protected]>; Bruno Decraene > <[email protected]>; Yingzhen Qu <[email protected]>; lsr > <[email protected]>; lsr-chairs <[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]> 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]>; [email protected]; > 'Yingzhen Qu' <[email protected]>; 'lsr' <[email protected]>; 'lsr-chairs' > <[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]> > Sent: Friday, August 9, 2024 12:01 AM > To: Les Ginsberg (ginsberg) <[email protected]>; [email protected]; > 'Yingzhen Qu' <[email protected]>; 'lsr' <[email protected]>; 'lsr-chairs' > <[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]
