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]
