Hi Robert,
>> 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. No! I disagree completely. As soon as you make the specification 100% deterministic you block out all implementation lattitude and introduce unnecessary brittleness into the protocol. Should flooding be deterministic? Do you really want: “You must transmit LSPs are 10ms intervals.”? Or: “TLVs must appear in ascending numerical order, packed as tightly as possible.”? I want correctness. If everyone does the MUST and MUST NOTs, then things will work. SHOULDs will make it run better. I do NOT want to overconstrain things, especially for unnecessary reasons. > 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. Do you agree that receivers MUST NOT reject MP-TLVs if the senders do not strictly adhere to maximum packing? If you do agree, then why does it matter? There may be good reasons for not doing maximum packing, such as optimal LSP packing. A little lattitude here would be a good thing. Again, Postel’s law. > 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. I respectfully disagree. T
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
