Well, I understand what you say and strictly speaking per Occam's razor we could remove this if we write bauhaus specs ;-)
AFAIS it is however useful as guidance. It gives a guideline that is helpful to implement the protocol better. A developer that implements mp-tlv by putting every prefix into a single TLV will read this and understand that he SHOULD NOT do this. But you're correct, even if it says MUST I would not even know how to enforce or implement a MUST here. -- tony On Mon, Sep 9, 2024 at 10:59 PM Robert Raszuk <[email protected]> wrote: > > 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]
