[email protected]
[Top] [All Lists]

Re: ordered SPFs

Subject: Re: ordered SPFs
From: Alia Atlas
Date: Fri, 22 Oct 2004 09:10:54 -0400

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
a topology?
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 is interesting.
It's only that portion which matters b/c it's only that traffic which is
affected, sure.

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
decrease it.
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
[email protected]

<Prev in Thread] Current Thread [Next in Thread>