Re: [Lsr] WG Last Call for "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-06

[Shraddha Hegde <[e-mail]>]

This is a very useful feature for large L2 networks and I support the publication of this
document.


I have below nits/suggestions on the document.


1. Figure 1: Example Topology of L1 with L2 Borders
The diagram is not legible. The connections between L1 routers
can be removed from the diagram and a description can be added that
R1 layer routers are all connected to R2 layer and so on.
>From the diagram it appears that there is connectivity between R10 and R11
and R11 and R12. If so that link can flood L2 domains and L2 is not
fully disjoint. I would suggest to remove the R10->R11 link to show a pure clos topology
in L1.

2.
4.1 Flood reflection TLV
"On a given router, the same value
      of the Flood Reflection Cluster ID MUST be advertised across all
      interfaces advertising the Flood Reflection TLV in IIHs. "

Do we really need this restriction of one single cluster-id on a router?
I am imagining, this cluster-id mechanism can be used to segregate a single fabric
into two or more clusters if the fabric size becomes too huge.
The usecase itself is described out of scope for this document elsewhere
which is fine but too restrictive statements like above would discourage further
enhancements so may be worth considering these restrictions to be removed.

3.
4.2.  Flood Reflection Discovery Sub-TLV
" A router receiving multiple Flood Reflection
   Discovery sub-TLVs in TLV 242 MUST use the values in the first sub-
   TLV"

   first sub-TLV is not deterministic as multiple TLV 242 can come is different fragments.
   Suggest to change as below.
   " A router receiving multiple Flood Reflection
   Discovery sub-TLVs in TLV 242 MUST use the values in the first sub-
   TLV of the lowest numbered fragment"

   4.
   "flood reflection tunnel endpoint" and "L1 shortcut"
   terminology should be added to the glossary. These terms are used in sec 4.3
   and reader may not get the context of these terms.



   5. section 4.3

   do we need the F bit? Looks like this info can be derived from the
   C bit in Flood Reflection Discovery Sub-TLV. The ones with C bit set are possible shortcut endpoints.
   The ones with C bit cleared are the flood reflector tunnel endpoints.


   6. The tunnel encapsulation attribute has use outside of flood reflector
   (such as RFC 8663). I am more in favor of getting rid of the F bit from this sub-TLV
   as to avoid the confusions that may arise when it is used in the absence of flood reflectors.

   7.
   " A flood reflector receiving multiple Flood Reflection Discovery
   Tunnel Type sub-sub-TLVs in Flood Reflection Discovery sub-TLV with F
   flag set SHOULD use one or more of the specified tunnel endpoints to
   automatically establish one or more tunnels that will serve as flood
   reflection adjacency(-ies)."

   A flood reflector should establish tunnels with clients only and not with
   other flood reflectors. also the cluster id needs to match.
   This text as well as next para needs revision.

   8. sec 4.4

   "The Flood Reflection Adjacency sub-TLV SHOULD NOT appear more than
   once in a given TLV.  A router receiving multiple Flood Reflection
   Adjacency sub-TLVs in a TLV MUST use the values in the first sub-TLV
   and it SHOULD adequately log such violations subject to rate
   limiting."

   IMO should talk abt possibility of same TLV 22 in multiple fragments and
   MUST use first sub-TLV from lowest numbered fragment.

   9.

   "If the clients have a
   direct L2 adjacency they SHOULD use it instead of instantiating a new
   tunnel."

   above statement seems to contradict statement below in sec 4.5
   " A router acting as a flood reflector MUST NOT have any traditional L2
   adjacencies. "





Juniper Business Use Only
From: Lsr <[e-mail]> On Behalf Of Acee Lindem (acee)
Sent: Friday, December 3, 2021 9:22 PM
To: Antoni Przygienda <[e-mail]>
Cc: [e-mail]
Subject: [Lsr] WG Last Call for "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-06

[External Email. Be cautious of content]

Speaking as WG member:

I have already supported publication. I have a couple comments:


  1.  Can you add "leave" to the glossary in section 2?
  2.  Section 5.2 is a bit hard to read. I have some suggested changes in my

editorial comments but it would be good to expand the cases into smaller

chunks and make state the overall goals ahead rather than after the details.
          Your call though.

  1.  In section 7, would an IS-IS router really set the overload-bit in L1 but not L2?


I've also attached some suggested editorial changes. Some of these are very subjective
and I won't feel bad if you don't include them all.

Thanks,
Acee