yes, and given how complex and costly (in terms of calculation but also flooding) the sliding/repacking of TLVs is an implementation may end up in this very case intentionally though this should be discouraged by a SHOULD as Les says
On Fri, Aug 9, 2024 at 7:44 PM Les Ginsberg (ginsberg) <ginsberg= [email protected]> wrote: > Bruno – > > > > The reason for SHOULD rather than MUST has to do with the old axiom of > being “strict in what you send – but generous in what you receive”. > > Using two TLVs to send information when it could be sent in one TLV > introduces more overhead for the receiver – it would be best if this were > not done. > > But (assuming MP-TLV support is fully deployed of course) we do not want > the receiver to discard/ignore the information just because it was sent in > a sub-optimal way. > > > > Hope this makes sense. > > > > Les > > > > *From:* [email protected] <[email protected]> > *Sent:* Friday, August 9, 2024 7:50 AM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* Yingzhen Qu <[email protected]>; lsr <[email protected]>; > lsr-chairs <[email protected]>; DECRAENE Bruno INNOV/NET < > [email protected]> > *Subject:* RE: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv > (7/1/2024 - 7/15/2024) > > > > Les, authors, > > > > Sorry, one more comment > > *7.3. > <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-03#section-7.3>Restrictions > on Generation of MP-TLVs > <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-03#name-restrictions-on-generation-> > * > > “Implementations SHOULD NOT send multiple TLVs unless MP-TLV is > applicable to the TLV and the amount of information which is required to be > sent exceeds the capacity of a single TLV.” > > > > Do you have a reason/example in mind for not complying with this? > > If not, I would favor :s/SHOULD/MUST. At least for the second part (“not > enough space”). This would avoid that some implementation send MP-TLV while > not anticipated (and a priori for no reason since this could fit in a > single TLV). > > > > Thanks > > Regards, > > --Bruno > > > > *From:* [email protected] <[email protected]> > *Sent:* Friday, August 9, 2024 4:40 PM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* 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) > > > > Les, > > > > > > > > *From:* Les Ginsberg (ginsberg) <[email protected]> > *Sent:* Friday, August 9, 2024 6:11 AM > > Bruno – > > > > Thanx for the detailed comments. > > > > Thanks for taking the time to respond in detail. > > > > Note that we have not yet fully determined what text changes should be > made to the draft – but hopefully this discussion will help us move > forward. > > I appreciate that this discussion is time consuming – but hopefully worth > it for all of us. > > > > +1. > > > > BTW, I will be away for a few days the first part of next week (returning > on Thursday August 15) – so responses may be delayed. > > > > No problem, thanks Les. On my side, I’ll be away till August 26 > > > > Please see inline. > > > > *From:* [email protected] <[email protected]> > *Sent:* Wednesday, August 7, 2024 6:03 AM > *To:* 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 authors, > > > > Please see below some possible comments on the draft. > > > > 1) > > §3 says > > “TLVs sometimes contain information, called a key, that indicates the > applicability of the remaining contents of the TLV. If a router advertises > multiple TLV tuples with the same Type code in an IS-IS IIH packet or in > the set of LSPs for a level with the same key value, they are considered a > multi-part TLV (MP-TLV).” > > > > I’m reading this as: TLV not having a key can’t be a MP-TLV. > > If this is not the intention please clarify. (e.g. same key value if that > TLV has a key) > > If this is the intention, this seems to contradict with other text such as > > §4 “If a Multi-part TLV contains information that specifies the > applicability of its contents (i.e., a key), the key information MUST be > replicated” > > §6 “However, Multi-Part TLV procedures are potentially applicable to any > codepoint that allows sub-TLVs to be included as part of the information > advertised.” > > > > *[LES:] In order for MP-TLV to be applicable to a codepoint, there has to > be the potential for more than 255 bytes of information to be advertised. > (obvious **😊)* > > *And if multiple TLVs are sent, there has to be a way to identify them as > being associated with the same object (which is what the “key” does).* > > *This is consistent with the statement “TLV not having a key can’t be a > MP-TLV.”.* > > *But there are some subtleties.* > > *To use your example of the admin tag sub-TLVs, I agree that it is > conceivable (though unlikely) that one could need to advertise more than > 255 bytes of tags, yet the tag sub-TLVs themselves do not have a “key”.* > > *Functionally however, as they are associated with a single prefix, they > inherit the key from the parent codepoint.* > > *(More comments on admin tag below).* > > > > [Bruno] OK. The principle of the MP-TLV extension is clear. My concern is > that the sender be more subtle than the receiver and hence the receiver > gets surprised/lost. > > > > *In summary, I think we can do a better job of wording in this section – > we will work on that.* > > *But the existing text is correct in spirit.* > > > > [Bruno] OK, thanks. > > > > 2) > > §4.1 (TLV 22) > > > > “The key consists of the 7 octets of system ID and pseudonode number plus > the link identifiers.” > > OK. May be for extra clarify :s/the link identifiers/all links identifiers > which are present > > > > *[LES:] We will make this change.* > > > > “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)* > > > > [Bruno] Thanks for the example. Really useful. > > I’m fine so far, especially because A and B are different nodes so they > may advertise/be configured with different things. > > > > *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)* > > > > [Bruno] What about the following example advertised by A > > TLV #1: (B system-id, IPv6 Interface Address, Local/Remote Link IDs) > > TLV #2: (B system-id, IPv6 Interface Address) > > > > With B not supporting RFC 6119 (IPv6 Interface Address) > > > > Possibly this is obvious to everyone but me, but I’m a priori not > confident that the sender may be as creative as it want, and expect the > receiver to always figure out correctly. > > > > *Receivers can still correctly identify the two TLVs as being associated > with the same adjacency to B.* > > > > I agree that there are multiple cases where the receiver could correctly > identify the two TLVs. My concern is that some receivers may not, even if > they could. E.g. the one implementing the receiver feels like this is an > optional case and no bother implementing this case. > > > > *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.* > > 3) > > §5 Procedure for Receiving Multi-part TLVs > > “If the internals of the TLV contain key information, then replication of > the key information should be taken to indicate that subsequent data MUST > be processed as if the subsequent data were concatenated after a single > copy of the key information.” > > May be :s/should/MUST > > *[LES:] We will make this change.* > > [Bruno] Thanks. > > 4) > > §5 Procedure for Receiving Multi-part TLVs > > “A TLV may contain information in its fixed part that is not part of the > key. […] Having inconsistent information in different parts of a MP-TLV is > an error and is out of scope for this document.” > > > > I know that we have divergence on this aspect, but to me error handling is > part of the specification. At least so that all receivers make a consistent > choice. > > A typical simple behavior could be to discard the whole MP-TLV (all > parts). Alternatively the error handling defined in > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-12#sec_isis_gen_metric > > “advertisement in the lowest numbered fragment MUST be used and the > subsequent instances MUST be ignored.” > > Also I would welcome a more normative text. e.g. :s/is an error/ MUST be > treated as an error. > > > > *[LES:] In such scenarios there is no way to know which value is > "correct". Historically there have been two approaches:* > > *1)Implementations make a local decision as to which of the values they > use and/or whether to ignore both.* > > *2)Define a deterministic behavior e.g., use the first occurrence in the > lowest numbered LSP.* > > > > *In cases where behavior is specified, some RFCs have chosen #1 and some > have chosen #2.* > > > > *But multi-tlv does not introduce this problem and therefore it is out of > scope for this document to define the behavior.* > > > > [Bruno] To me multi-tlv introduces the possibility to advertise two TLV > with the same key. Because of a bug, those two TLV may sent with different > information in its fixed part. So it would be up to this document to handle > that case. > > Sorry if I’m missing something > > > > *Not least because we would have to be* > > *concerned with contradicting existing specifications no matter which > choice was made.* > > > > *If you feel this is important enough to address, then the codepoint > specific documents need to be updated.* > > > > *It is possible that we could say something like:* > > > > *“If the relevant RFC which defines a codepoint is not explicit as to how > to handle such situations, Option #2 SHOULD be followed.”* > > > > *This would establish a recommended default behavior while allowing > specific codepoints to override this behavior.* > > *If you think this is helpful we can add such text.* > > *??* > > > > [Bruno] I think that this would be helpful. At least for me. Thanks for > the suggestion. But the deterministic behavior would need to be specified > (,no?) > > > > 5) §7.1 Recommended Controls and Alarms > > > > Ideally I would like the addition of the below case: > > “* An MP-TLV Capability Advertisement is not received from a node when use > of MP-TLVs is enabled.” > > > > Because you can’t expect existing node to comply with “If an MP-TLV is > received when use of MP-TLVs is disabled” hence this is not enough to > detect the partial deployment issue. > > > > *[LES:] I am having trouble parsing this.* > > *If the receiver receives only one TLV for a given object, there is no way > for the receiver to know whether the sender had additional information to > send but suppressed it or if the sender simply didn't have any additional > information.* > > > > [Bruno] Let me rephrase. > > OLD: If local LSP generation requires the use of MP-TLVs when generation > of MP-TLVs is disabled > > NEW: If local LSP generation requires the use of MP-TLVs when generation > of MP-TLVs is disabled on this node or not supported on other nodes in the > flooding domain (as advertised by the MP-TLV Capability Advertisement). > > > > I understand that this is extra work so I’m not insisting. But if you > believe that this is not a significant extra work, I think it may help the > operator during initial deployment. > > > > > > *What we are recommending here is that implementations inform the operator > that MP-TLVs are being sent by some nodes even though the operator has > disabled it on the local node. If the operator has disabled the use of > MP-TLVs on a node, it is presumed that the operator had a reason to do so > i.e., the operator knows that at least some nodes in the network do not > support reception of MP-TLVs and so they should not be sent by any node.* > > > > *The only way the operator can avoid partial deployment issues is to > ensure that the configuration of any node does not require the sending of > MP-TLVs.* > > *Disabling the sending of MP-TLVs in the presence of configuration which > requires more than 255 bytes to be sent for an object means that not all > required info can be sent - and what will be excluded is unpredictable - so > the network will be compromised.* > > > > [Bruno] Let’s suppose that new configuration is added requiring more than > 255 bytes. I’m making a distinction between: > > a) Node does _*not*_ send MP-TLV hence some configuration is not > advertised in IS-IS (whether the CLI is shown as “active” or “inactive” > doesn’t seem to change anything for IS-IS). Agreed the node and the network > will not behave as expected, but all nodes have a consistent view of the > LSDB > > b) No sends MP-TLV while some other nodes do not support MP-TLV. à > different nodes have a different view of the LSDB. > > I feel that “b” is a bigger issue. > > > > *We could add some text to this effect in Section 7 if you think it would > be helpful.* > > > > 6) §7.2 MP-TLV Capability Advertisement > > > > “Nodes which support MP-TLV for codepoints for which existing > specifications do not explicitly define such support, but for which MP-TLV > is applicable, SHOULD include this sub-TLV in a Router Capability TLV.” > > > > Looks good, thank you. Yet “existing specifications” may be unclear in 5 > years from now. May be you could refer to the section 8.2 which > specifically list those codepoints. (since you did the effort of writing > §8.2, you could reference it) > > *[LES:] The point of adding the MP-TLV applicability column to registries > means that going forward, every new codepoint will be required to > explicitly indicate whether MP-TLV applies. This will be enforced by the WG > and IANA. So, it should not be possible for documents that become RFCs > after this draft becomes an RFC to be "unclear".* > > *Existing RFCs may never get updated, but hopefully we have covered those > cases in Section 8.2. * > > *So I do not share your concern.* > > > > [Bruno] ok, no problem. > > > > 7) 8.2.3. MP-TLV for IS-IS Sub-TLVs for TLVs Advertising Neighbor > Information > > > > Checking one random value. > > > > > > 17 > > Generic Metric > > Y > > > > Does this match the sub-TLV defined in > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-12#sec_isis_gen_metric > ? > > If so, > > - This seems to contradict the spec “For a particular metric type, > the Generic Metric sub-TLV MUST be advertised only once for a link when > advertised in TLV 22, 222, 23, 223 and 141.”, “If there are multiple > Generic Metric sub-TLVs advertised for a link for the same metric type (and > same application in case of ASLA) in one or more received LSPDUs, > advertisement in the lowest numbered fragment MUST be used and the > subsequent instances MUST be ignored.” > > - Also it’s length is hardcoded to 4 octets. Why would one need to > use MP-TLV? > > *[LES:] I agree – this is misidentified. We will correct that.* > > > > > > IINM, although I agree that sampling 1 TLV out of many is poor sampling, > it’s a bit disturbing to find an error out of one TLV. At minimum it seems > to indicate a lack of review from the WG. > > *[LES:] Disturbs me too. We tried hard to be accurate and complete, > but…obviously we still need good review (like yours).* > > > > [Bruno] I wish there would be more eyes / reviewers. It’s also why I > believed that adding, in this doc, the key for each TLV would allow more > eyes to check that we all agree on the key definition. But I got the > pusback 😉. I’m not trying to insist, but explain my initial motivation. > > > > Picking another value > > > > 1 > > 32-bit Administrative Tag Sub-TLV > > N > > > > Why a “No”? This sub TLV includes a set of tags and if the number of tags > is large enough, it seems like a good candidate for MP-TLV, no? > > *[LES:] :] Conceptually I agree.* > > [Bruno] Thank you. > > *RFC 5130 does not prohibit multiple sub-TLVs - though it also does not > explicitly allow them.* > > *One could argue that 50+ 32 bit tags can be advertised in a single > sub-TLV – which ought to be more than enough for any deployment.* > > [Bruno] +1. Especially when some implementations may only support one 😉. > > *But strictly speaking RFC 5130 does not prohibit this – so it could be > considered as possible.* > > *There are then two choices:* > > > > *1)Mark this codepoint as MP-TLV applicable* > > *2)Update RFC 5130 to prohibit multiple sub-TLVs/prefix* > > > > *#1 can be done in this draft* > > *#2 should be done as either an errata or bis to RFC 5130.* > > > > *Make sense to you?* > > [Bruno] Absolutely. #1 seems easier but totally up to you. Personally a 3 > rd option would also work for me “3) Maks this codepoint a non MP-TLV > applicable”. Because I think that MP-TLV is introduced by this document and > hence could make that choice. But I feel that your preference would be to > make MP-TLV applicable to all TLVs by default whenever it’s possible. > > > > Thank you > > --Bruno > > > > On a side note, thank you for the addition of §6 which definitely > simplifies and helps interop. > > > > *[LES:] Thanx.* > > > > * Les* > > Thanks, > > Regards, > > --Bruno > > > > > > *From:* Yingzhen Qu <[email protected]> > *Sent:* Tuesday, July 2, 2024 8:08 AM > *To:* lsr <[email protected]>; lsr-chairs <[email protected]> > *Subject:* [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - > 7/15/2024) > > > > *CAUTION* : This email originated outside the company. Do not click on > any links or open attachments unless you are expecting them from the > sender. > > *ATTENTION* : Cet e-mail provient de l'extérieur de l'entreprise. Ne > cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de > connaitre l'expéditeur. > > > > Hi, > > > > This email begins a 2 week WG Last Call for the following draft: > draft-ietf-lsr-multi-tlv-01 - Multi-part TLVs in IS-IS > <https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/> > > > > Please review the document and indicate your support or objections by July > 15th, 2024. > > Authors, > > > > Please indicate to the list, your knowledge of any IPR related to this work. > > > > Thanks, > > Yingzhen > > ____________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and delete > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > > Thank you. > > ____________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and delete > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > > Thank you. > > ____________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and delete > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > > Thank you. > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
