Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

[[e-mail]]

Hello Robert,

> For the purpose of this discussion can someone quote the definition of LAN ? 


Well, sure, if you insist.  I’m surprised as you’ve been around for (quite) awhile and I would have thought that you picked up on this stuff.  :-) :-) :-)

ISO 10589v2 defines a LAN as a “Local Area Network”, referencing ISO 8802-3 (https://www.iso.org/standard/72048.html <https://www.iso.org/standard/72048.html>).

It further goes on the specify that LANs are expected to be broadcast, multi-access subnetworks, “that support the capability of addressing a group of attached systems with a single NPDU” (Section 6.2). 
Section 6.7.3 explicitly requires multicast capability and documents that a variety of errors are rare.

In practical terms, a LAN today is an Ethernet (or Wi-Fi), as FDDI and Token Ring are effectively dead.  Sorry, fans.  The cellular services that I’ve used also present an Ethernet interface, and thus I would expect them to count as a LAN as well, tho I hope that they are only performing LAN emulation between the cell device and the IP terminating box in the cell tower.


> Why ?
> 
> *1*  In most modern data centers I do not see any LANs. Even compute nodes are L3 nodes connected over /31 or /30 to TORs. From fabric IGP this is passive interface. 


Actually, you see a ton of LANs.  Almost every router interface sold today is an Ethernet, and the hardware behind that port is set up explicitly to handle Ethernet framing plus address matching.  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.  All of the implementations that I know about today do NOT default to point-to-point, so if the network operator doesn’t configure things, we end up with an interface in LAN mode.  It happens.  


> *2* In slightly older DCs there are redundant L3 access routers connecting in an L2 /24 fashion to TORs and towards computes there is VRRP/HSRP. Is this LAN we need to worry about ? 


If there’s an IGP adjacency on that /24 (and there should be) then the IGP will be flooding on that LAN.  Yes, that counts.  That’s exactly what we’re worrying about.  Can the area leader say: flood on that LAN?  Can it say: don’t flood on that LAN?


> *3* Then we have non routing aware devices on say /29 subnets acting as NFVs - is this a LAN flooding computation needs to worry about ? 


Presumably there are some routing aware devices on the /29, otherwise there’s nothing to speak the IGP, so yes, those devices could flood on that LAN too.


> Or is LAN only when IGPs decide to compute DR/BDR ? 


Any interface where they compute DR/BDR/DIS is relevant.


> Maybe before we move on here it would be actually useful to propose a one page lsr draft stating that implementations should automagically enable ospf/isis point to point behavior when there is /31 or /30 subnet configured on the interface ? Is there a reason why this is still a manual knob ? 


As that doesn’t directly affect the bits on the wire, I suspect that would be taken as mandating implementation, and thus out of scope for the IETF.  However, I agree with the sentiment.

That said, the world is as it is, not as we wish it would be.  Our job is to deal with the situation as we find it.  That includes LANs, both intentional and unintentional.

Regards,
Tony