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

[Robert Raszuk <[e-mail]>]

Hi Tony,

> 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.

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.

Thx,
R.


On Wed, Apr 3, 2019 at 2:09 AM <[e-mail]> wrote:

>
> 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).
>
> 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
>
>
>