Ballot for draft-ietf-lsr-isis-flood-reflection
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
Thanks for the work put into this. I just have some minor editorial things to consider. Section 4.1 contains this text: The Flood Reflection TLV SHOULD NOT appear more than once in an IIH. A router receiving one or more Flood Reflection TLVs in the same IIH MUST use the values in the first TLV and it SHOULD log such violations subject to rate limiting. There are several other instances of this pattern in later sections. In each case I'm wondering why an implementer might choose to disregard the SHOULD NOT. Is there ever a legitimate reason to do so? If so, could we include an example? If not, should this simply be a MUST? Several of the other SHOULDs leave me wondering the same thing. Thanks for a good IANA Considerations section. Section 2 defines "Tunnel Endpoint" and "Hot-Potato Routing", but those terms don't appear anywhere in the document.
Thank you to Rich Salz for the SECDIR review. ** Section 4.1 The Flood Reflection TLV SHOULD NOT appear more than once in an IIH. Why isn’t the guidance here “MUST NOT” appear since any subsequent, duplicate Flood Reflection TLVs are ignored? Same comment on the discovery Sub-TLV in Section 4.2, and Section 4.4 ** Section 4.3 Carries encapsulation type and further attributes necessary for tunnel establishment as defined in [RFC9012]. The Protocol Type sub-TLV as defined in [RFC9012] MAY be included. The first sentence suggests that the semantics of this field are defined by RFC9012. The second sentence suggests that it is optional to support the Protocol Type sub-TLV per Section 3.4.1 of RFC9012. This is confusing to me because RFC9012 supports a number of sub-TLVs to include the Protocol Type one explicitly called out. Is that the only sub-TLV supported for use? Editorial ** Section 1. Typo. s/Maintainance/Maintenance/ ** Section 1. Editorial. Consider using a less colloquial phrase than “Deployment-wise”. ** Section 4.2. Editorial. s/one ore more/one or more/
Thanks for the document, I found it clear and well-written. Thanks to the shepherd for the explanation regarding the experimental track.
The introduction was extremely clear and useful; thank you. This document could use some text about what Experiment is being conducted, success criteria, etc.
Hi, Thanks for this document, I found it pretty clear and easy to read (although, I skipped the TLV specifications). A couple of minor comments/nits that may help improve the doc: Minor level comments: (1) p 18, sec 9. Security Considerations subversion of the IS-IS level 2 information. Therefore, at tunnel level steps should be taken to prevent such injection. I didn't find the term "tunnel level" to be particularly clear, either here, or below. Nit level comments: (2) p 8, sec 3. Further Details One possible solution to this problem is to expose additional topology information into the L2 flooding domains. In the example network given, links from router 01 to router 02 can be exposed into L2 even when 01 and 02 are participating in flood reflection. This information would allow the L2 nodes to build 'shortcuts' when the L2 flood reflected part of the topology looks more expensive to cross distance wise. Should 01 and 02 be R1 and R2 respectively? Regards, Rob