At 08:02 AM 10/22/2004, mike shand wrote:
You are assuming I think, that the broadcast "link" is actually
made up of a full mesh of pt-pt links, and what you are describing is a
failure of 3 of those links simultaneously (don't forget the reverse
connectivity check), breaking connectivity of the triangle ABC. As such,
this is neither node failure nor single link failure, but probably comes
in the category of unrelated SRLG, so it is not surprising that an
incorrect ordering may occur (I haven't analyzed it yet to be sure, but
it seems likely).
Granted. I said it was very contrived. Could you please send me an
example where you believe it is correct to increase the delay (but not
decrease it)? That is the part that I am objecting to.
For this to matter in a scenario, it seems that one needs both ECMP, so
that the traffic is flowing across more than one link, and to have not
computed the RSPT from the node which merges the paths.
Clearly, you believe you have such a scenario where the proper behavior is
to increase delay, but not decrease it. Could you please send me that such
Do you have such an example? Could you explain why you believe it is safe
to increase the delay but not decrease it?
However, if the broadcast link were represented as it normally
would be as a pseudonode (or the OSPF equivalent), then the situation
would be rather different, and would depend on which router was DR. What
you describe would cause the loss of adjacencies between AB,AC and BC.
Yes, that was the idea :-)
If E were DR, there would be no change in the LSPs, since A,B &
C's links to and from the pseudonode would still be intact. In IS-IS (I
don't know for sure about OSPF), there would be no break in connectivity
either, since if (for example) A needed to send a packet to C it would
send it to the DR(E), which would in turn send it to C. This is how IS-IS
deals with partial adjacency formation on a LAN.
I put E in to be the DR. I believe that in OSPF, A, B and C would report
the different connectivity, regardless of who was the DR. I can certainly
SO now going back to your analysis of the pt-pt link case. I think you may
have misunderstood how the reverse SPF is used. Remember that it is ONLY
the portion of the RSPF which crosses the link under consideration which
It's only that portion which matters b/c it's only that traffic which is
So I think this gives the following values, for delay (which is horizon
hop count - hop count)
Node | delay | delay | max from | delay |
| from A | from B | A & B | from C |
A | 0 | 0 | 0 | 5
B | 3 | 0 | 3 | 5
C | 0 | 1 | 1 | 0
D | 0 | 0 | 0 | 0
E | 0 | 0 | 0 | 0
F | 2 | 0 | 2 | 4
G | 1 | 0 | 1 | 3
H | 0 | 0 | 0 | 2
S | 0 | 0 | 0 | 0
I | 0 | 0 | 0 | 1
This can't be correct. I is dependent on S to reach D via the broadcast link.
I don't THINK there is a conflict here, so despite the link failure not
being "related" (in the sense of all applying to the same node), at least
in this case I think it doesn't cause a problem.
The topology tried to have H and S on different unconnected branches of the
RSPT for the first LSP/LSA and then have them on a connected branch for the
But these things are somewhat tricky to evaluate by hand, and my simulator
doesn't (yet :-) deal with such "unrelated" failures. So it is possible I
have missed something here.
I'll try to do a proper analysis when I get time.
I'm not focused on this particular example, but on trying to understand
your rationale for believing it is acceptable to increase the delay and not
Intuitively, that doesn't make sense to me because what you are doing is
not removing a dependency as early as was required. That original
dependency doesn't go away.
Rtgwg mailing list