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 <lsr-boun...@ietf.org> On Behalf Of Acee Lindem (acee)
Sent: Friday, December 3, 2021 9:22 PM
To: Antoni Przygienda <p...@juniper.net>
Cc: lsr@ietf.org
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
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
