Robert – Sorry – but I really think you are taking this thread off topic.
Dynamic transition from P2P to multi-access has been defined in TRILL – see https://tools.ietf.org/html/rfc6325#section-4.4.2 and the discussion of the “bypass pseudo-node” bit. Without intending to insult anyone, I have never cared for this – and even if you like the idea it is clear that it isn’t backwards compatible and it isn’t something I would want to gate deployment of flooding optimizations. But I really think this isn’t relevant. The use of LANs in the flooding topology is only meaningful if we have a multi-access circuit which is used for transit traffic. And at least some of us are leaning to allowing for that possibility – which is not at all the same thing as saying you SHOULD run in LAN mode even if you don’t have to. Nor is it encouraging the use of multi-access LANs. If you want a way to more easily enable P2P mode by default – speak to your favorite vendor. That is a feature – not a protocol extension. Les From: Tony Li <tony1ath...@gmail.com> On Behalf Of tony...@tony.li Sent: Wednesday, April 03, 2019 8:20 AM To: Robert Raszuk <rob...@raszuk.net> Cc: Tony Przygienda <tonysi...@gmail.com>; Acee Lindem (acee) <a...@cisco.com>; Les Ginsberg (ginsberg) <ginsb...@cisco.com>; lsr@ietf.org Subject: Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology Hi Robert, > The fact that we use them in a point-to-point fashion today is somewhat > orthogonal, as from > the routing protocol layer, we cannot tell whether an interface is > point-to-point or not, and we > must be explicitly configured to be in point-to-point mode. Why we cannot tell ? That to me is a protocol specification bug. Well between any two Ethernet ports, there can be an arbitrary amount of layer 1 and layer 2 stuff. Bridges, hubs, repeaters, pseudo-wires, tunnels, etc. All of it is transparent to IS-IS PDUs and OSPF packets, so it’s not detectable. All it takes is one L2 switch in the path with a router plugged into it but powered off. Sorry if I was not very clear - My question was driven by the idea to actually redefine what LAN is for the purpose of LSR and specifically this discussion and perhaps even drop completely support of dynamic flooding when LAN is detected and present - based on a new definition of LANs. It should not matter if interface is multi access or not. Proposal: To consider LAN an interface on which you receive Hellos from more then one IGP peer. Well, that would create a significant stability problem. I presume that you would want the interface to default to point-to-point (PtP) mode. Let’s suppose that systems A and B form an adjacency in this way. Now, system C comes up. If it sees two PtP IIH’s, then it knows to send a LAN IIH. However, if it doesn’t wait long enough, it too sends a PtP IIH. I don’t know of a single implementation that’s ready for that. But let’s suppose that we hack to fix this. Once A and B see C’s IIH, then they have to swap over to using a LAN IIH. We haven’t done any DIS election, so we effectively have no adjacency to advertise and have to start DIS election from scratch. It could be done, but it’s likely to cause adjacencies to bounce. It’s messy. There’s no easy way to downgrade back to PtP without losing adjacencies again. In any case, this is wholly orthogonal to dynamic flooding. While it might address the issue of unintentional LANs, it does nothing to change the fact that there are intentional LANs and that we need to be able to signal them. Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
