comments addressed and new version posted -- tony
On Tue, Dec 7, 2021 at 7:24 AM Shraddha Hegde <shraddha= [email protected]> wrote: > 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 <[email protected]> *On Behalf Of *Acee Lindem (acee) > *Sent:* Friday, December 3, 2021 9:22 PM > *To:* Antoni Przygienda <[email protected]> > *Cc:* [email protected] > *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 > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
