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

[Aijun Wang <[e-mail]>]

Hi, Shraddha:

 

For large L2 networks, the solution
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-ttz is more
suitable.

For CLOS topology that is used to connect disjoint L2 area, as that
described in
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-01, the
area proxy solution is more straightforward. 

Is there any other scenario that the flood reflection solution be applied?

 

Best Regards

 

Aijun Wang

China Telecom

 

From: [e-mail] <[e-mail]> On Behalf Of Shraddha
Hegde
Sent: Tuesday, December 7, 2021 2:24 PM
To: Acee Lindem (acee) <acee=[e-mail]>; Antoni Przygienda
<[e-mail]>
Cc: [e-mail]
Subject: Re: [Lsr] WG Last Call for "IS-IS Flood Reflection"
-draft-ietf-lsr-isis-flood-reflection-06

 

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] <mailto:[e-mail]> > On Behalf Of
Acee Lindem (acee)
Sent: Friday, December 3, 2021 9:22 PM
To: Antoni Przygienda <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[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.

3.       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