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: [email protected] <[email protected]> On Behalf Of Shraddha Hegde Sent: Tuesday, December 7, 2021 2:24 PM To: Acee Lindem (acee) <[email protected]>; Antoni Przygienda <[email protected]> Cc: [email protected] 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 <[email protected] <mailto:[email protected]> > On Behalf Of Acee Lindem (acee) Sent: Friday, December 3, 2021 9:22 PM To: Antoni Przygienda <[email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[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. 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
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
