IS-IS Flood Reflection
draft-ietf-lsr-isis-flood-reflection-12

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