> 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.
Ok that is a valid point I admit I did not even consider as the reason for SHOULD NOT to be there ... On Mon, Sep 9, 2024 at 11:06 PM Tony Przygienda <[email protected]> wrote: > 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]
