I agree as well.
Thanks,
Acee
On 4/2/19, 1:26 PM, "Lsr on behalf of [email protected]" <[email protected]
on behalf of [email protected]> 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) <[email protected]>
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 <[email protected]> On Behalf Of Les Ginsberg (ginsberg)
>> Sent: Tuesday, April 02, 2019 8:31 AM
>> To: [email protected]; [email protected]
>> 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 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.
>>
>>
>>
>> _______________________________________________
>> Lsr mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
