Les,
> Let me propose that we add something to sections 6.7.5, 6.7.9, and 6.7.11
> like:
>
> Addition of temporary flooding should be done with caution, as the addition
> of excessive connectivity to the flooding topology may trigger unwanted
> behavior. Routers SHOULD add temporary flooding in a rate limited manner, if
> not configured otherwise.
>
> [Les:] The first sentence is OK with me.
Great!
> The second one I think goes beyond anything on which we can claim consensus.
Ok, thank you for saying so. Silence is assent, so what should it say?
> Whether adding the first sentence alone is worth a new revision I think is
> questionable – but I certainly would not oppose it.
The cost of a new revision is trivial, given that the system is automated.
> Regarding LANs, the encoding for OSPF is more problematic – basically we
> need to identify the value as a router id or a network LSA id (or something
> like that).
> So, committing to this without consensus has a downside that we might live to
> regret.
>
> I am in agreement with Peter’s position. LANs introduce additional complexity
> and it is not clear that including that support is a real benefit in the
> topologies in which we expect the flooding optimizations to be used.
> I know you believe real deployments may need this support – but what I don’t
> know is whether we have hard evidence to support that position.
>
> I am also wondering whether the following serves us better:
>
> a)We keep LANs always enabled for flooding
> b)The algorithms consider this and are biased towards using LANs when
> possible as this is a cheaper way to enable flooding to multiple nodes than
> many P2P interfaces.
>
> IN this way we keep the simplicity of not having to define LAN
> behavior/encoding, yet reap benefits in topologies where LANs have a
> significant presence.
>
> Let me know what problems you see with this approach.
Again, there are lots of cases where having LANs enabled is sub-optimal.
Parallel LANs, for example.
Yes, LANs MAY be a useful way of covering the topology, but without algorithm
specifics, it’s difficult to discuss. In the simulation work that we’ve done,
it’s pretty much a wash. Sometimes it’s helpful, sometimes it’s redundant. It
very much depends on the topology.
You can imagine a LS network where ALL links are still in LAN mode. By your
rules, that completely disabled dynamic flooding. I don’t think that’s
tractable.
Not being able to describe the flooding topology precisely is a significant
hindrance and is going to cause misbehavior one way or another. Suppose that
we have nodes A, B, and C. Suppose that AB is a P2P link and {A, B, C} is a
LAN. Now suppose that the topology requests path AB. What do A and B do? If
the LAN was intended, then C is included. How does C know that?
So, I don’t think LANs on all of the time works. And then we need to be able
to specify what’s going on, so that means naming LANs somehow.
Tony
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
