Hi Tony, From: Tony Li <[email protected]> On Behalf Of Tony Li Sent: Monday, September 9, 2024 10:54 PM To: Robert Raszuk <[email protected]> Cc: DECRAENE Bruno INNOV/NET <[email protected]>; Les Ginsberg <[email protected]>; Yingzhen Qu <[email protected]>; lsr <[email protected]>; lsr-chairs <[email protected]> Subject: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)
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. I also want correctness and I’m fine with your definition of MUST. The issue with current text in -05 is that everyone can do MUST and MUST NOT and things may not work. e.g., one node is allowed to send MP-TLV for TLV 22 whatever is configured by the network operator. If other nodes do not support MP-TLV for TLV 22, things will not work. How do you propose to make this work? --Bruno 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 ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
