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

[Les Ginsberg (ginsberg)]

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  On Behalf Of tony...@tony.li
Sent: Wednesday, April 03, 2019 8:20 AM
To: Robert Raszuk 
Cc: Tony Przygienda ; Acee Lindem (acee) ; 
Les Ginsberg (ginsberg) ; 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

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

[Robert Raszuk]

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.

On Wed, Apr 3, 2019, 17:26 Tony Przygienda  wrote:

>
>
> On Wed, Apr 3, 2019 at 1:36 AM Robert Raszuk  wrote:
>
>> 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.
>>
>>
> 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
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Tony Przygienda]

On Wed, Apr 3, 2019 at 1:36 AM Robert Raszuk  wrote:

> 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.
>
>
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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Christian Hopps]

+1

Thanks,
Chris.

> On Apr 2, 2019, at 13:25, tony...@tony.li wrote:
> 
> 
> 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)  
>> wrote:
>> 
>> 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  On Behalf Of Les Ginsberg (ginsberg)
>>> Sent: Tuesday, April 02, 2019 8:31 AM
>>> To: tony...@tony.li; lsr@ietf.org
>>> Subject: [Lsr] Open issues with Dynamic Flooding: Including LANs in the
>>> Flooding Topology
>>> 
>>> (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.
>>> 
>>> 

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

[Les Ginsberg (ginsberg)]

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 
Sent: Tuesday, April 02, 2019 3:34 PM
To: Acee Lindem (acee) 
Cc: tony...@tony.li; Les Ginsberg (ginsberg) ; lsr@ietf.org
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 ...

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) 
mailto:a...@cisco.com>> wrote:
I agree as well.
Thanks,
Acee

On 4/2/19, 1:26 PM, "Lsr on behalf of tony...@tony.li<mailto:tony...@tony.li>" 
mailto:lsr-boun...@ietf.org> on behalf of 
tony...@tony.li<mailto:tony...@tony.li>> wrote:


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) 
mailto:ginsb...@cisco.com>> wrote:
>
> 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 mailto:lsr-boun...@ietf.org>> On Behalf 
Of Les Ginsberg (ginsberg)
>> Sent: Tuesday, April 02, 2019 8:31 AM
>> To: tony...@tony.li<mailto:tony...@tony.li>; 
lsr@ietf.org<mailto:lsr@ietf.org>
>> Subject: [Lsr] Open issues with Dynamic Flooding: Including LANs in the
>> Flooding Topology
>>
>> (I have altered the subject so we can discuss the two issues in T

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

[tony . li]

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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[tony . li]

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


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

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  wrote:

> 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)  wrote:
>
>> I agree as well.
>> Thanks,
>> Acee
>>
>> On 4/2/19, 1:26 PM, "Lsr on behalf of tony...@tony.li" <
>> lsr-boun...@ietf.org on behalf of tony...@tony.li> wrote:
>>
>>
>> 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) <
>> ginsb...@cisco.com> wrote:
>> >
>> > 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  On Behalf Of Les Ginsberg
>> (ginsberg)
>> >> Sent: Tuesday, April 02, 2019 8:31 AM
>> >> To: tony...@tony.li; lsr@ietf.org
>> >> Subject: [Lsr] Open issues with Dynamic Flooding: Including LANs
>> in the
>> >> Flooding Topology
>> >>
>> >> (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

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

[Acee Lindem (acee)]

I agree as well. 
Thanks,
Acee

On 4/2/19, 1:26 PM, "Lsr on behalf of tony...@tony.li"  wrote:


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)  
wrote:
> 
> 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  On Behalf Of Les Ginsberg (ginsberg)
>> Sent: Tuesday, April 02, 2019 8:31 AM
>> To: tony...@tony.li; lsr@ietf.org
>> Subject: [Lsr] Open issues with Dynamic Flooding: Including LANs in the
>> Flooding Topology
>> 
>> (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 

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

[tony . li]

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)  
> wrote:
> 
> 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  On Behalf Of Les Ginsberg (ginsberg)
>> Sent: Tuesday, April 02, 2019 8:31 AM
>> To: tony...@tony.li; lsr@ietf.org
>> Subject: [Lsr] Open issues with Dynamic Flooding: Including LANs in the
>> Flooding Topology
>> 
>> (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 

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

[Les Ginsberg (ginsberg)]

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  On Behalf Of Les Ginsberg (ginsberg)
> Sent: Tuesday, April 02, 2019 8:31 AM
> To: tony...@tony.li; lsr@ietf.org
> Subject: [Lsr] Open issues with Dynamic Flooding: Including LANs in the
> Flooding Topology
> 
> (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