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
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
