Les, all Please see my 2 cents (operator's feedback) inline [Bruno] (to be clear, I'm not doing any comparison with any other proposal)
Orange Restricted From: Lsr <[email protected]> On Behalf Of Les Ginsberg (ginsberg) Sent: Monday, November 6, 2023 4:13 PM To: Christian Hopps <[email protected]> Cc: [email protected] Subject: Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility" Chris - Thanx for the reply - and glad to see we seem to be headed in the same direction. Just wanted to clarify that the MP draft does NOT advocate partial deployment. [Bruno] Speaking of clarity, I'd rephrase this as "does NOT support (enablement in) partial deployment" No support of partial deployment makes this very difficult to deploy in certain environments. You'd be surprised how old some platforms may be. And given that LSPs are flooded to all nodes (vs BGP attributes), in those environments, we are speaking of more than a decade between support on all implementation and deployment. Adding that some implementations may implement this latter, I'd say more than a decade (2 decades looks doable). https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-04.html#name-deployment-considerations recommends: * Implementations provide a knob to control the use of MP-TLV * Implementations report an alarm if an MP-TLV is received when use of MP-TLVs is disabled. * Implementations report an alarm if local LSP generation requires the use of MP-TLVs when generation of MP-TLVs is disabled. [Bruno] Good. Or minimal given the issues brought in case of partial deployment. Given that some implementors tends to skips "SHOULD", I'd rather call for REQUIRED. (and I believe REQUIRED is the right level, at least for the first item) Following these guidelines, MP-TLVs would only be present in a network when the control is set to use them AND the operator enters a config which requires sending more than 255 bytes. And violations of these conditions would be reported. [Bruno] I don't think that there is such "the operator enters a config which requires sending more than 255 bytes". In my environment, a provisioning tool or a human would not know whether a given config would "require sending more than 255 bytes" or not. This would be too much complexity. Not to mention that I guess that in the general case the config may be done on one node (e.g., a PE) and the advertisement requiring more than 255 octets could be done on a different node (e.g., ABR, L1/L2 router). Finally, I would also assume that with zero config change from the operator, a software upgrade could have the limit being exceeded. (e.g., the new software advertising new sub-TLV, such as RFC 7794 "Prefix Attributes for Extended IPv4 and IPv6 Reachability"). IOW, let's not put the blame on the operator when the issue is the spec (or feature) not supporting partial deployment. Draft says "Sending of MP-TLVs in the presence of nodes which do not correctly process such advertisements can result in interoperablity issues, including incorrect forwarding of packets." [Bruno] While correct, I find the sentence a bit on the understatement side. In particular :s/can result/is likely to result (if not "will result") :s/packets/a significant portion of the traffic resulting in persistent forwarding loops. And thanks to Christian for the nice summary and bridging the communication gap. --Bruno Les > -----Original Message----- > From: Christian Hopps <[email protected]<mailto:[email protected]>> > Sent: Monday, November 6, 2023 6:10 AM > To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> > Cc: Christian Hopps <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]> > Subject: Re: draft-pkaneria-lsr-multi-tlv and "backwards compatibility" > > > My point is that people are not using the same definition of backward > compatibility. This is why this argument over it is going in circles. I'm > suggesting that when you consider each persons definition of backward > compatibility, then neither side is wrong. So saying things like "No. You are > wrong" etc, is not helpful to moving things forward. > > In both cases, when you actually need multi-part-tlv, you have to deploy the > new software to all the routers that will use it; however the multi-part-tlv > draft > allows for a messy sort of "it still works as long as you don't need > multi-part- > tlv on routers that don't understand it" operation. So you hand craft your > software deployment to match your network config to make that work. > > The Big TLV solution does not allow for this "messy but functioning > deployment", and this is why I believe people prefer the multi-part TLV > solution. That should be enough to move things forward IMO. > > Thanks, > Chris. > [wg-member] > > "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>> > writes: > > > Chris (and everyone) - > > > > > > > > A more complete response to your comments regarding "backwards > > compatibility", routing loops, etc. > > > > > > > > It is absolutely true that until all nodes in the network support > > advertisement (meaning at least receive processing) of more than 255 > > bytes for a given object, that any attempt to deploy a configuration > > which requires the advertisement of more than 255 bytes for that > > object is likely to result in some type of failure. > > > > That failure could manifest itself as routing loops or blackholes or > > in other ways. This is explicitly stated in https://www.ietf.org/ > > archive/id/draft-pkaneria-lsr-multi-tlv-04.html# > > name-deployment-considerations : > > > > > > > > "Sending of MP-TLVs in the presence of nodes which do not correctly > > process such advertisements can result in interoperability issues, > > including incorrect forwarding of packets." > > > > > > > > No one has ever tried to state otherwise. > > > > > > > > But it is also true that encodings other than MP suffer from the same > > limitation. The authors of Big-TLV try to claim otherwise, but this > > does not stand up to scrutiny - see my replies to Huaimo for more > > details as to why. > > > > > > > > Would it be great if we could find a way to allow "incremental > > deployment"? Sure - but it isn't possible. As Tony Li stated at the > > last IETF (paraphrasing): > > > > > > > > "This isn't great - but it's the best we can do." > > > > > > > > As to why this particular problem is not amenable, it is because the > > content that is being advertised consists of existing sub-TLVs that > > all nodes in the network are required to process for correct > > operation. There isn't some information which is "old" and some > > information which is "new". It is all "old" - there is just more of > > it. > > > > > > > > I honestly thought we had gotten past this point with our discussions > > (both in the WG and some post WG 1-1 discussions) at IETF 117. But > > now you have raised this point again. > > > > I share your angst, but there is an undeniable deployment need to > > advertise more than 255 bytes per object - so we need to move > > forward. > > > > > > > > Les > > > > > > > > > > > > > > > > > > > > ____________________________________________________________________________________________________________ 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] https://www.ietf.org/mailman/listinfo/lsr
