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
