Thank you Tony P. for confirming the assumption. If MUST can not be enforced then SHOULD will not be enforced either, leaving the behaviour to pretty much random.
So why keep pretending that the spec wording is useful ? I would much better see to state in the RFC that let's leave how the TLVs are filled to the discretion of the implementation and move on ... Forget about any normative language. Cheers, R, On Mon, Sep 9, 2024 at 10:52 PM Tony Przygienda <[email protected]> wrote: > I wrote it already once, I repeat, if you ever implemented large scale > ISIS you will understand that due to sliding a MUST cannot be enforced > without actually breaking other protocol guidelines and generate possibly > tons unnecessary fragments and transitory flooding bleeps due to > unnecessary shifting of TLVs around > > Imagine that we have fragment #1 with a TLV A len 250 and it filled in the > fragment mtu > > now if the spec says MUST then we MUST generate a fragment #max+1 and move > whole TLV in there to fill it to 255 and flood. Guess what, we may find > both fragments in transition and then the we MUST discard the whole first > TLV because if we don't I don't know what the MUST means? Thinking > furhther, so what is the rule now when multiple copies of the TLV are > around, the TLVs in all fragments have to be filled to 255 until the one in > the last fragment because otherwise, which one violates this MUST? Let's > play that out e.g. with redistribution changes causing things like few > prefixes across multiple fragments being withdrawn, now we have coiuple > copies of previously 255 len prefix tlv that all need repacking to follow > that rule and may start to flood tons stuff due to tlv changes and sliding > things around and in pathological cases basically end up basically > repacking all fragments (which causes normally a serious network > disturbance so it's avoided like the plague in good implementations) > > The SHOULD Les put in is exactly what is both pragmatically necessary and > enforceable > > -- tony > > > On Mon, Sep 9, 2024 at 10:33 PM Robert Raszuk <[email protected]> wrote: > >> Hi Tony, >> >> I understand the vendor position to protect the pre-standard >>> implementation. But I’m in the network operator position and I’m trying to >>> make the network as safe as possible. We’ll see what position the IETF will >>> take. >>> >>> You do not make the network safer by mandate. You make it safer by >>> writing more forgiving code. >>> >> >> Hope you agree that above all you make network interop safer by writing >> deterministic protocol specifications. >> >> Unfortunately the subject one is not very deterministic. >> >> The section 5 says: >> >> Although MP-TLVs SHOULD NOT be sent unless the >> capacity of a single TLV (255 octets) is exceeded, receivers MUST NOT >> reject MP-TLVs if senders do not strictly adhere to this constraint. >> See Section 7.3 for guidance when sending MP-TLVs. >> >> If you replace "SHOULD NOT" above with "MUST NOT" perhaps the request for >> MUST to be able to disable MP-TLV (on a per TLV basis) would make a bit of >> a weaker case. >> >> But for now keeping SHOULD in both places (section 5 and 7.1) just opens >> room for individual vendor's interpretation and behaviours and are soft >> while MUST in any of those paragraphs would IMO help protocol robustness. >> >> Kind regards, >> Robert >> _______________________________________________ >> Lsr mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
