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. > 1. well, it's ASII. I'll redraw for the thing to look maybe more straightforward thought it may lead more folks astray to think it's a CLOS. The link R10-R11 is there on purpose, this is NOT a CLOS and flood reflection is not restricted by any topology constraints. I drew it CLOS like since that's what lots people do/start to do, thinking about it I probasbly change the picture for the thing to be much less CLOS like ;-) 10-11 and 11-12 are there on purpose to show L2 leaf shortcuts. > > > 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? > For operational simplicity very much so. For future possible things, maybe not but introducing multiple cluster IDs in same area and possibly same cluster ID in different areas leads to all kind of corner cases & configuration complications because cluster ID becomes de facto a property of an interface (or have to carry a set of possible Cluster IDs and that leads to "negotiation" scenarios with additional complications in case of dynamic tunnel establishment). We don't have in ISIS areas "per interface" for the same reason as we should not have a cluster ID per interface. Yes, some vendors support "multiple" areas per router but we know it's used only for merge/split and is a whole dance to get it right during transitions. Having said that, if enough people feel that way we _should_ move the MUST to a SHOULD I think it's livable and then let's hope some clever vendors can try to support multiple cluster IDs if they find an operationally acceptable way. > 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. > as said above, I'm ok with a SHOULD but generally all the procedures described & formats stay at a single cluster ID. > > > 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" > ok, thanks. good one. > > > 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. > ok, will add. thanks for comment. > > > > > > > 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. > nope, we can't since clients may have different endpoints for the FR tunnel & for the shortcut tunnels so whoever originates the tunnel has to be sure they shortcut to the correct endpoint. > > > > > 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. > as per 5. the bit is needed. > > > 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. > yes, thanks. will clarify. the cluster ID match is also a good one albeit it seems logical given adjacency restrictions. > > > 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. > yes, good catch again here. > > > 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. " > well, it probably slipped by you that clients can have shortcut in L2 client-2-client so there is no contradiction. But yes, good observation as to client-reflector rule. I clarify that a flood reflector SHOULD use a direct L2 interface adjacency to a client if it has one rather than a tunnel. -- tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
