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. 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. 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. Les > -----Original Message----- > From: Christian Hopps <cho...@chopps.org> > Sent: Monday, November 6, 2023 6:10 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Christian Hopps <cho...@chopps.org>; 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 > > > > > > > > > > > > > > > > > > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
