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

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 2 Apr 2019 15:31:26 +0000

(I have altered the subject so we can discuss the two issues in Tony's previous post separately.)

There are several  aspects to consider when discussing LAN support in the 
context of flooding optimizations:

1)Flooding topology advertisement (centralized mode only)

Support for encoding LANs when advertising the flooding topology requires that 
we include not only all routers in the set of "nodes" in the network but also 
(to use IS-IS terminology) all “pseudo-nodes” as well. This means when 
advertising the set of nodes and associated indeces used in calculating the 
flooding topology there needs to be an indication as to whether a given
entry is a node or a pseudo-node. The encoding for this is straightforward
in IS-IS (include pseudo-node ID in the node identifier) but more complex 
in OSPF.

However, this is a problem with a straightforward solution and is therefore
not a significant consideration.

2)Enablement/disablement of flooding on a LAN

Correct operation of flooding on a LAN requires all nodes connected to the
LAN perform their role when the LAN is enabled for flooding and conversely
all nodes suppress flooding via the LAN when flooding is disabled for
flooding. This applies to temporary enablement of flooding on a LAN in the 
event of a partitioned flooding topology i.e., if any node connected to the LAN
signals enablement of temporary flooding on the LAN all nodes connected to the
LAN MUST honor that request.

Selective enablement of flooding on a LAN based on whether it is part
of the calculated flooding topology therefore entails some additional
complexity.

Note that this discussion assumes that flooding operation on a LAN 
is not altered by the introduction of flooding optimizations. For example
there is no proposal to selectively enable transmission of LSPs/LSAs on
a LAN only by a subset of the nodes connected to the LAN. 

3)Use of LANs in flooding topology algorithms

When LANs are considered part of the flooding topology, any algorithm
used to compute the flooding topology has to consider how to use LANs.
For example, using a LAN might have an advantage in that by enabling
flooding on a single LAN multiple nodes are now connected to the flooding
topology. This might reduce the number of point-to-point edges required
in the flooding topology and/or decrease the diameter of the flooding topology. 

But use of a LAN might either increase the diameter of the flooding topology
and thereby affect convergence or unnecessarily increase the degree of 
connectivity of certain nodes to the flooding topology and thereby reduce 
the optimization achieved.

If LANs are always enabled for flooding but are not included in the set of
nodes considered as part of the flooding topology (see point #1 above) then
"false partitions" might occur during the calculation of the flooding
topology.

Whether LANs are considered part of the flooding topology or not, the presence
of a LAN introduces the possibility that there are "hidden nodes" to which
flooding is actually occurring but which are not explicitly mentioned in 
the calculated flooding topology.

4)Deployment Limitations

The significance of support for LANs depends upon their existence in a
deployment where the use of flooding optimizations is desired.

If all links are point-to-point then the question is irrelevant.

If all links are point-to-point but ethernet links have not been configured 
to operate in point-to-point mode then lack of support for LANs would
compromise the value of flooding optimizations. A counter argument to this
case is that unnecessary operation in LAN mode itself increases the number of 
LSPs/LSAs that need to be flooded by as much as 50% and therefore is
something which SHOULD be addressed by altering configuration. There should
then be motivation for network operators to enable point-to-point operation
where possible even if they have not done so before.

If LANs with more than 2 connected nodes are present and are used for 
transiting traffic then lack of support for LAN circuits for flooding 
optimizations will lead to diminished effectiveness of flooding optimizations.

Summary:

When forming an opinion on whether to include LANs in the flooding topology
it is prudent to consider the above points.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 2 Apr 2019 15:37:08 +0000

In reply to my own post, here is my opinion regarding including LANs in the Flooding Topology:

While I think it would be "nice" and simplifying to be able to ignore LANs, I think we are unable to do so because the possibility that LANs are actually in use as transit links in some topologies exists.

NOTE: I am not persuaded by the argument that some operators have LANs that could be operated in point-to-point mode but they simply don't configure the links to do so. If a customer is serious about flooding reduction then they need to also do what they can to reduce unnecessary LSPs/LSAs from even being generated.

Even if we treat LANs as always enabled for flooding , any algorithm to calculate the flooding topology would be sub-optimal if it did not consider the fact that flooding is occurring on the LANs.

Bottom line, unless we are confident that LANs will not exist in the topologies where flooding optimizations will be used, not supporting LANs seems to be an undesirable restriction.

   Les

> -----Original Message-----
> From: Lsr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
> Sent: Tuesday, April 02, 2019 8:31 AM
> To: [email-masked]; [email-masked]
> Subject: [Lsr] Open issues with Dynamic Flooding: Including LANs in the
> Flooding Topology
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: [email-masked]
Date: Tue, 2 Apr 2019 10:25:31 -0700

I am in complete agreement with both Les’s extensive analysis and opinion.  ;-)

Tony

> On Apr 2, 2019, at 8:37 AM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 2 Apr 2019 17:32:08 +0000

I agree as well. 
Thanks,
Acee

On 4/2/19, 1:26 PM, "Lsr on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    Tony

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 2 Apr 2019 15:33:46 -0700

Read it through (fairly slowly even ;-) and seems Les is for simply always
including LAN in the flood reduction topology. I would concur with that.
figuring whether a LAN is transit is basically calculation whether it's a
minimal cut. solving that is polynomial of course. When we have multiple
LANs to decide what is the maximum subset of LANs that can be cut without
paritioning the graph (i.e. how many LANs can we omit while still having
the graph connected) smells to me NP complet'ish but I don't think I ever
dealt with the problem. At worst it's combination of LANs * polynomial
computaton so about  sum_1_k (n over k) * polynomial  which looks tad chewy
to me ... then, LAN floods efficiently in terms of fanout compared to p2p
replication in IGPs so there's this unknown optimization constant that
affects overall solution ...

Obvioulsy, someone could implement a very clever algorithm how to avoid
LANs or account for their efficiency and so on so IMO the draft doesn't
even need to say anything normative if  no algorithm is given as intended
AFAIR

--- tony

On Tue, Apr 2, 2019 at 10:32 AM Acee Lindem (acee) <[email-masked]> wrote:

> I agree as well.
> Thanks,
> Acee
>
> On 4/2/19, 1:26 PM, "Lsr on behalf of [email-masked]" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>     > While I think it would be "nice" and simplifying to be able to
> ignore LANs, I think we are unable to do so because the possibility that
> LANs are actually in use as transit links in some topologies exists.
>     >
>     > NOTE: I am not persuaded by the argument that some operators have
> LANs that could be operated in point-to-point mode but they simply don't
> configure the links to do so. If a customer is serious about flooding
> reduction then they need to also do what they can to reduce unnecessary
> LSPs/LSAs from even being generated.
>     >
>     > Even if we treat LANs as always enabled for flooding , any algorithm
> to calculate the flooding topology would be sub-optimal if it did not
> consider the fact that flooding is occurring on the LANs.
>     >
>     > Bottom line, unless we are confident that LANs will not exist in the
> topologies where flooding optimizations will be used, not supporting LANs
> seems to be an undesirable restriction.
>     >
>     >   Les
>     >
>     >
>     >> (I have altered the subject so we can discuss the two issues in
> Tony's
>     >> previous post separately.)
>     >>
>     >>
>     >> Support for encoding LANs when advertising the flooding topology
> requires
>     >> that
>     >> event of a partitioned flooding topology i.e., if any node
> connected to the
>     >> LAN
>     >> signals enablement of temporary flooding on the LAN all nodes
> connected to
>     >> the
>     >> in the flooding topology and/or decrease the diameter of the
> flooding
>     >> topology.
>     >>
>     >> Whether LANs are considered part of the flooding topology or not,
> the
>     >> presence
>     >> case is that unnecessary operation in LAN mode itself increases the
> number
>     >> of

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 3 Apr 2019 00:53:13 +0200

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

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.

*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 ?

*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 ?

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

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 ?

Thx,
R.

On Wed, Apr 3, 2019 at 12:34 AM Tony Przygienda <[email-masked]> wrote:

>>     > Even if we treat LANs as always enabled for flooding , any
>> algorithm to calculate the flooding topology would be sub-optimal if it did
>> not consider the fact that flooding is occurring on the LANs.
>>     >
>>     > Bottom line, unless we are confident that LANs will not exist in
>> the topologies where flooding optimizations will be used, not supporting
>> LANs seems to be an undesirable restriction.
>>     >
>>     >   Les
>>     >
>>     >
>>     >> case is that unnecessary operation in LAN mode itself increases
>> the number
>>     >> of
>>     >> something which SHOULD be addressed by altering configuration.
>> There
>>     >> should

---

From: [email-masked]
Date: Tue, 2 Apr 2019 16:41:29 -0700

Hi Tony,

> Read it through (fairly slowly even ;-) and seems Les is for simply always including LAN in the flood reduction topology. I would concur with that.

Ok, I didn’t read that into it and I disagree.  There are many topologies where that approach is decidedly suboptimal.

Suppose you have a leaf-spine topology, except that the spines are layer 2 only.   You now have N leaves, with M LANs interconnecting them.  Do you flood in parallel on M LANs?  Wouldn’t it be more prudent just to flood on 2?

> figuring whether a LAN is transit is basically calculation whether it's a minimal cut. solving that is polynomial of course. When we have multiple LANs to decide what is the maximum subset of LANs that can be cut without paritioning the graph (i.e. how many LANs can we omit while still having the graph connected) smells to me NP complet'ish but I don't think I ever dealt with the problem. At worst it's combination of LANs * polynomial computaton so about  sum_1_k (n over k) * polynomial  which looks tad chewy to me ... then, LAN floods efficiently in terms of fanout compared to p2p replication in IGPs so there's this unknown optimization constant that affects overall solution ... 

It’s pretty clear to me that the optimal selection of the FT is ‘chewy’ if not NP-hard.  However, the very good news is that we don’t need optimal.  Only effective and reasonably efficient.

Dave Allan's proposal is a clear existence proof of a far less ‘chewy’ algorithm, albeit for a restricted set of topologies.  Other algorithms are likely to be not very ‘chewy’ on those topologies either, and only become ‘chewy’ as the topologies get more complex.  This seems entirely reasonable and appropriate.

> Obvioulsy, someone could implement a very clever algorithm how to avoid LANs or account for their efficiency and so on so IMO the draft doesn't even need to say anything normative if  no algorithm is given as intended AFAIR

This is exactly correct.  Since we are partitioning the algorithm development from signaling, we can set aside the question of how to optimally use LANs and focus on the question on the table: do we add enough signaling to specify LANs.

Regards,
Tony

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 2 Apr 2019 16:54:45 -0700

On Tue, Apr 2, 2019 at 4:41 PM <[email-masked]> wrote:

>
> Hi Tony,
>
>
> > Read it through (fairly slowly even ;-) and seems Les is for simply
> always including LAN in the flood reduction topology. I would concur with
> that.
>
>
> Ok, I didn’t read that into it and I disagree.  There are many topologies
> where that approach is decidedly suboptimal.
>
> Suppose you have a leaf-spine topology, except that the spines are layer 2
> only.   You now have N leaves, with M LANs interconnecting them.  Do you
> flood in parallel on M LANs?  Wouldn’t it be more prudent just to flood on
> 2?
>
>
> > figuring whether a LAN is transit is basically calculation whether it's
> a minimal cut. solving that is polynomial of course. When we have multiple
> It’s pretty clear to me that the optimal selection of the FT is ‘chewy’ if
> not NP-hard.  However, the very good news is that we don’t need optimal.
> Only effective and reasonably efficient.
>
> Dave Allan's proposal is a clear existence proof of a far less ‘chewy’
> algorithm, albeit for a restricted set of topologies.  Other algorithms are
> likely to be not very ‘chewy’ on those topologies either, and only become
> ‘chewy’ as the topologies get more complex.  This seems entirely reasonable
> and appropriate.
>
>
> This is exactly correct.  Since we are partitioning the algorithm
> development from signaling, we can set aside the question of how to
> optimally use LANs and focus on the question on the table: do we add enough
> signaling to specify LANs.
>
>
ok, agreed. maybe something to this effect could make it into the draft as
in "it's not simple to avoid LANs but nothing prevents you to do that" ...

I admit I may have over-interpreted Les's write-down which as far
(meaningfull) verbiage goes rivals some of the stuff I tend to produce ;-)

As to signalling, I think we have not much choice and need to signal the
PNODE as either being in or out topology which implies LAN is in or out it
... I would also consider optimizations to "sub-flood" the LAN (i.e.
disaggregate it to p2p floodings or nodes dropping received LSPs) as
jumping the shark due to complexity but that's just my small change ...

--- tony

---

From: [email-masked]
Date: Tue, 2 Apr 2019 17:08:58 -0700

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

---

From: [email-masked]
Date: Tue, 2 Apr 2019 17:10:37 -0700

Hi Tony,

> As to signalling, I think we have not much choice and need to signal the PNODE as either being in or out topology which implies LAN is in or out it ... I would also consider optimizations to "sub-flood" the LAN (i.e. disaggregate it to p2p floodings or nodes dropping received LSPs) as jumping the shark due to complexity but that's just my small change 

That is exactly where I think we are.  

In violent agreement.  

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 3 Apr 2019 00:19:08 +0000

Tony –

This is not what I was trying to say.

It is true that I still “kind of wish” we could just say “LANs always enabled for flooding” and be done with it. But as there are (or could be) cases where LANs are part of the deployment, I think it is more robust if we define the protocol extension in a way that supports LANs.

This means – at a minimum – that the defined encoding needs to allow pseudo-nodes to be assigned an index.

It is then up to the algorithm(s) to decide how to make use of LANs. One option would be to treat LANs as always on and always include them in the advertised flooding topology (centralized mode).

It would then be legitimate for one vendor to offer algorithm(s) which always use all LANs for flooding. Benefits of this might be simplicity. Drawbacks may be sub-optimal flooding reduction in some topologies.
Another vendor may offer an algorithm that  is more sophisticated in its use of LANs for flooding and tout the benefits while reassuring customers regarding the risk associated with complexity.

But if we don’t allow for support of LANs then we restrict the topologies in which it is possible to reap significant benefits. I think there is enough evidence to suggest that we might encounter LANs in some target topologies – so I am opting to agree with what Tony L has been advocating for quite a while now – let’s define extensions that leave open optimal support in a larger set of topologies.

Hope this is clear.

   Les

From: Tony Przygienda <[email-masked]>
Sent: Tuesday, April 02, 2019 3:34 PM
To: Acee Lindem (acee) <[email-masked]>
Cc: [email-masked]; Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

Read it through (fairly slowly even ;-) and seems Les is for simply always including LAN in the flood reduction topology. I would concur with that. figuring whether a LAN is transit is basically calculation whether it's a minimal cut. solving that is polynomial of course. When we have multiple LANs to decide what is the maximum subset of LANs that can be cut without paritioning the graph (i.e. how many LANs can we omit while still having the graph connected) smells to me NP complet'ish but I don't think I ever dealt with the problem. At worst it's combination of LANs * polynomial computaton so about  sum_1_k (n over k) * polynomial  which looks tad chewy to me ... then, LAN floods efficiently in terms of fanout compared to p2p replication in IGPs so there's this unknown optimization constant that affects overall solution ...

--- tony

On Tue, Apr 2, 2019 at 10:32 AM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
I agree as well.
Thanks,
Acee

On 4/2/19, 1:26 PM, "Lsr on behalf of [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Tony

    > On Apr 2, 2019, at 8:37 AM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
    >
    >> From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Les Ginsberg (ginsberg)
    >> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
    >> [email-masked]<mailto:[email-masked]>

    _______________________________________________
    Lsr mailing list
    [email-masked]<mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Christian Hopps <[email-masked]>
Date: Wed, 3 Apr 2019 00:02:20 -0400

+1

Thanks,
Chris.

> On Apr 2, 2019, at 13:25, [email-masked] wrote:
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 3 Apr 2019 10:36:22 +0200

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 <[email-masked]> wrote:

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

---

From: [email-masked]
Date: Wed, 3 Apr 2019 08:19:36 -0700

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 

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

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 3 Apr 2019 08:26:16 -0700

> To consider LAN an interface on which you receive Hellos from more then
leads to simple attack vectors, not possible on misconfiguration

adding something like OSPF capability saying (/31 is automatically
point-to-point) and enforcing that is possibly but will lead to lots of
backwards compatibility breaks ...  In ISIS there isn't a simple way to do
it given an interface may be on multiple subnets (TE TLVs) and so on ...

so yeah, routing protocols are hard, especially the older ones when one
implements and deploys ;-)

-- tony

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 3 Apr 2019 17:58:27 +0200

As far as attack if someone can attach to LAN and if he knows security
details he can do much better then hack IGP.

But oh well if we prefer to continue to ride on current type of roads while
complicating design of new vehicles to accomodate it that is fine too.

Best,
R.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 3 Apr 2019 16:08:19 +0000

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 <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, April 03, 2019 8:20 AM
To: Robert Raszuk <[email-masked]>
Cc: Tony Przygienda <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

Hi Robert,

Proposal:

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 3 Apr 2019 19:46:10 +0200

Hi Les,

If asking a question which is outside of the box is equal to thread
hijacking then sorry. But you won - subject line changed.

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

I guess this is the question ... is dynamic flooding a new flooding
paradigm in IGPs to be used everywhere or is it only applicable to densely
connected topologies ?

If this is former - by all means support of real LANs is must have. If this
is the latter - I doubt.

In fact if this is the latter more simplification in computing flooding
graph, less complexity in signalling and therefor less bugs will IMHO yield
much better outcome.

In such cases it may be actually a feature to limit dynamic flooding to p2p
topologies only.

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

Completely disagree. To detect how many IGP peers are on the interface  and
to do the switchover gracefully between 2 vs N or N vs 2 protocol extension
is needed. It is not a single side local hack.

Thx,
R.

---

From: [email-masked]
Date: Wed, 3 Apr 2019 10:56:17 -0700

Hi Robert,

> I guess this is the question ... is dynamic flooding a new flooding paradigm in IGPs to be used everywhere or is it only applicable to densely connected topologies ? 

It is only sensible in dense topologies.  In sparse topologies, such as you would find in a WAN, there is very little improvement to be had.  

For example, at Prague I showed an 8x8 grid.  The FT improvement was only 36%.  Given the computational cost, it’s probably not worth it.

> If this is former - by all means support of real LANs is must have. If this is the latter - I doubt. 
> 
> In fact if this is the latter more simplification in computing flooding graph, less complexity in signalling and therefor less bugs will IMHO yield much better outcome. 
> 
> In such cases it may be actually a feature to limit dynamic flooding to p2p topologies only. 

Well, I have to disagree.  While it’s nice to say that you will limit that feature to those topologies, real operators push the envelope all of the time.  Things happen operationally. Folks can definitely use LANs advantageously in dense topologies. It makes sense to support them.

> Completely disagree. To detect how many IGP peers are on the interface  and to do the switchover gracefully between 2 vs N or N vs 2 protocol extension is needed. It is not a single side local hack. 

What extension are you proposing?

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 3 Apr 2019 18:10:14 +0000

[Les:] You are saying that customers today need to deploy circuits on which they are uncertain whether they will connect two nodes or more than two nodes?
This is the first I have heard of such a requirement.

If this really is a deployment requirement then such an extension could be considered. But since the extension isn’t trivial and isn’t backwards compatible I would not take this on without justification.
Be interested to hear if anyone else on the deployment side of things believes this is needed.

   Les

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 3 Apr 2019 20:11:52 +0200

> What extension are you proposing?

If you have only two routers on LAN based on IIH multicast discovery you
are still forming an adj between them (you do that anyway as one of them
will be DIS). But for flooding reduction point of view you can treat it as
p2p link (so it must be signaled as such).

When Nth (N >= 3) router comes up you fall back to LAN mode and here you
can support it or not.

I guess your take is that since you want to support it anyway when N >= 3
there is no point of building the special case for the N=2.

Thx,
R.

On Wed, Apr 3, 2019 at 7:56 PM <[email-masked]> wrote:

> It is only sensible in dense topologies.  In sparse topologies, such as
> you would find in a WAN, there is very little improvement to be had.
>
> For example, at Prague I showed an 8x8 grid.  The FT improvement was only
> 36%.  Given the computational cost, it’s probably not worth it.
>
>
> Well, I have to disagree.  While it’s nice to say that you will limit that
> feature to those topologies, real operators push the envelope all of the
> time.  Things happen operationally. Folks can definitely use LANs
> advantageously in dense topologies. It makes sense to support them.
>
> Completely disagree. To detect how many IGP peers are on the interface
> and to do the switchover gracefully between 2 vs N or N vs 2 protocol
> extension is needed. It is not a single side local hack.
>
>
>

---

From: [email-masked]
Date: Wed, 3 Apr 2019 11:15:45 -0700

> I guess your take is that since you want to support it anyway when N >= 3 there is no point of building the special case for the N=2. 

Exactly.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 3 Apr 2019 20:17:27 +0200

Well imagine I am building DMZ with two gateways and a firewall connected
to L2 switch. I run IGP between them so my iBGP next hops can resolve.

Later I may perhaps add third and fourth gateway.

I can not normally set it as p2p IGP day one, but it could operate fine for
the first few years as such.

Thx,
R.

On Wed, Apr 3, 2019 at 8:10 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> *[Les:] You are saying that customers today need to deploy circuits on
> which they are uncertain whether they will connect two nodes or more than
> two nodes?*
>
> *This is the first I have heard of such a requirement.*
>
>
>
> *If this really is a deployment requirement then such an extension could
> be considered. But since the extension isn’t trivial and isn’t backwards
> compatible I would not take this on without justification.*
>
> *Be interested to hear if anyone else on the deployment side of things
> believes this is needed.*
>
>
>
> *   Les*
>
>
>
> Thx,
>
> R.
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 3 Apr 2019 18:33:36 +0000

Robert –

Having one circuit (or even 2 or 3) run in LAN mode “unnecessarily” does not represent a significant scale issue.
The need for the extension you suggest would come only when there are many such circuits which could change from 2 nodes only to > 2 (and possibly back again). Unless that is a real world deployment case I would not consider the extension worth the trouble.

   Les

From: Robert Raszuk <[email-masked]>
Sent: Wednesday, April 03, 2019 11:17 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; [email-masked]
Subject: Re: [Lsr] LANs in IGPs

Well imagine I am building DMZ with two gateways and a firewall connected to L2 switch. I run IGP between them so my iBGP next hops can resolve.

I can not normally set it as p2p IGP day one, but it could operate fine for the first few years as such.

Thx,
R.

On Wed, Apr 3, 2019 at 8:10 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

   Les

Thx,
R.