Hi, Tom, On 8/4/21 00:51, Tom Herbert wrote:
Fernando, I will also point that the data of RFC7872 is not consistent with header length being the top reason for drops. If I'm reading the data correctly, the HBH options are drop at about 3-4 time that rate that Destination options in that analysis. Since there both the same size (8 bytes), it seems that the majotiy of HBH options are being dropped because they are hop-by-hop options, not because the header chain is too long. This makes sense, because of the original requirement that all intermediate nodes must process hop-by-hop options, and we know many vendors didn't implement then. That requirement was relaxed in RFC8200, and so we'd expect drop rates to drop as nodes move to ignoring HBH options instead of blindly dropping them.
Again: this document is not trying to explain the numbers in RFC7872. PLease do read the abstract and the disclaimer, because you keep trying to have this document do something that it's not meant to do.
You should also note that the possible impact on devices is dependent on the EH chain length. However, the decision to drop packets need not be based on the EH length -- among other reasons, because such information might not be readily available.
Folks running a network can't be bothered digging into how many bytes of EHs each device they use can handle, and then be expected to figure out if there'ś any way to let only packets of shorter EH-chain lengths through. There are other problems to tackle day-to-day -- and this one is not even a problem: If I have no practical requirement to support them, and on the other hand there'ś risk in supporting them, I don't need to explain what my decision will be. You'll have a hard time explaining your manager or CEO why your network was brought down for supporting something you didn't need to support ("didn't need" == "the folk that pays the bill didn't ask for or care about it")..
Thanks, -- Fernando Gont e-mail: fernando@xxxxxxxxxxx PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
