Bruno – Thanx for the thoughtful comments. Please see responses inline.
From: bruno.decra...@orange.com <bruno.decra...@orange.com> Sent: Thursday, November 16, 2023 6:40 AM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Christian Hopps <cho...@chopps.org> Cc: lsr@ietf.org Subject: RE: draft-pkaneria-lsr-multi-tlv and "backwards compatibility" 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 <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of Les Ginsberg (ginsberg) Sent: Monday, November 6, 2023 4:13 PM To: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>> Cc: lsr@ietf.org<mailto:lsr@ietf.org> 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” [LES:] I think we need to pay attention to “scope” here. The use cases related to Neighbor and Prefix Reachability TLVs are what has brought this issue to the forefront, but the scope of the MP-TLV draft is all codepoints to which MP applies. For TLVs which are processed by all nodes in the network, partial deployment of MP support is simply not going to work. But there are TLVs to which MP applies which may not be processed by all nodes in the network. In such cases, use of MP for those codepoints could be viable in the presence of nodes which don’t support MP so long as those nodes don’t need to process that codepoint at all. Making a statement that partial deployment won’t work in all cases therefore isn’t accurate. 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). [LES:] Actually, I am not surprised by this at all. 😊 Part of my job is supporting old releases – even though I would wish that the customer would “just upgrade”. 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) [LES:] In principle I agree. But making a configuration knob or an alarm mandatory has some practical limitations. One can (for example) say that a TLV format MUST follow certain constraints and enforce this on the receiver by saying if a malformed TLV is received it MUST be ignored. But there is no enforcement mechanism for configuration knobs/alarms. It is possible that a given implementation might define an alternate configuration mechanism that the owners believe meets the intention of the statements above but does not match the definitions – so the use normative language here makes me think we are overstepping. While I agree with you in spirit, I am not sure that making the change you suggest is justifiable. Happy to listen to WG feedback on this. 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. [LES:] No intention on my part to imply “blame”. The point I am trying to make is that MP is not sent just because an implementation is capable of doing it. It is only sent because the deployment requires more than 255 bytes to be advertised. An implementation which, for example, has 100 bytes to send and chooses to send it in two TLVs with 50 bytes each is unnecessarily risking interoperability issues – this should not be done. I also agree that it is difficult at best for an operator to deduce that a given configuration requires more than 255 bytes to be advertised – which is why we recommend the alarms. The operator is then explicitly informed that MP is required when it occurs. Note that the alarms cover both the sending and the receiving cases. 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. [LES:] Again, this depends on the codepoint. In the case of Neighbor/Prefix Reachability advertisements, the impact on forwarding is highly likely (as your wording states). But as the scope of the draft is broader that these two codepoints, I think the current language is appropriate. And thanks to Christian for the nice summary and bridging the communication gap. [LES:] I am also appreciative of Chris’s comments. But I do think his suggestion that MP draft was advocating “partial deployment” was misleading – which is why I hastened to point out that is not the case. If I have misinterpreted Chirs’s intent, my apologies. Les --Bruno Les > -----Original Message----- > From: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>> > Sent: Monday, November 6, 2023 6:10 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> > Cc: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>; > lsr@ietf.org<mailto:lsr@ietf.org> > 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)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> > 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
