Re: [Lsr] Open issues with Dynamic Flooding

["Les Ginsberg (ginsberg)" <[e-mail]>]

Tony -


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.

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?

[Les2:] I am not prepared to say at the moment – which is why I was suggesting it’s too soon to add this.


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?

[Les2:] Since our current encoding does not support LANs, AB can only mean P2P – meaning the non-present pseudo-node ID is assumed to be 0.
Nodes would need to understand that reachable LANs (as advertised in pseudo-node LSPs and the pseudo-node neighbors advertised in non-pseudo-node LSPs) are always part of the flooding topology.

    Les