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]> 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
