[rbridge] Pseudonode minimization thoughts...
Radia Perlman
Radia.Perlman at sun.com
Fri Feb 1 10:48:27 PST 2008
Here's a compromise proposal.
My goals:
a) no configuration required
b) no pseudonode if you have no router neighbors on the link (whether or
not there are endnodes).
c) avoid pseudonodes if easy to do so (explain in a minute) when there
are just 2 routers (with perhaps endnodes)
Before Mike's arithmetic, I was thinking that pseudonodes weren't
valuable until maybe 10 neighbors, and just was
embarrassed about the whole pseudonode thing in this brave new world
where "Ethernets" are usually pt-to-pt links, but
now I think it's fine to simply *always* get rid of pseudonodes in the
case of one router, and *almost always* in the case of
just two routers.
So, here's the proposal:
a) do not report a pseudonode unless there is at least one *IS*
adjacency. This eliminates my nightmare of an unconfigured
RBridge with 1000 ports, each with one endnode on it, reporting 1000
pseudonodes. (Les confirmed my nightmare, that
all it takes is a single ES adjacency on a port and IS-IS today would
create a pseudonode for that port. We *really* have to
fix that case, and without requiring configuration)
b) if there is just one IS adjacency, and you are the DR, and your other
IS is cool with this feature (as signalled in its Hello), don't use a
pseudonode.
Just have each of the two IS's report a link to the other.
If your neighbor IS isn't cool with it, go ahead and make an adjacency.
(Note: for TRILL, I'd hope we'd put this feature in from the
start, so that all RBridges would be cool with this, so that is simple)
c) if there are ever 2 IS adjacencies on the port, create a pseudonode
*and remember, as long as you are up,
that this link should have a pseudonode as long as there is at least one
IS adjacency*. In other words,
this is not really a pt-to-pt link, and it won't be wasteful to keep the
link with a pseudonode because there might be other
IS's that will come up in the future. I would drop the pseudonode (in
the case of TRILL especially, maybe not for CLNP),
if there is ever no other IS adjacencies.
This is kind of like the original proposal but with the threshold of "1"
and "3" rather than "2" and "5", except once you hit 3, the
threshold becomes "1" and "2". So in this case R1 would do the following
a) no IS neighbors: no pseudonode. R1 reports nothing about that port in
its LSP, and does not report a pseudonode.
b) neighbor R2 comes up: no pseudonode: R1 just reports a link to R2 in
its LSP. R2 reports a link to R1 in its LSP.
c) R3 comes up (two IS nbrs): R1 says "use pseudonode". R1, R2, and R3
claim neighbor R1.25. R1.25 (the pseudonode name)
reports an LSP with neighbors R1, R2, R3.
d) R3 dies, leaving just R1 and R2: still pseudonode. R1.25 reissued,
with just R1 and R2 reported. R3's LSP dies of old age.
e) R2 dies (so there is just R1): no pseudonode. R1 does not report any
adjacencies for that port. R1 reissues its LSP
without R1.25 in it. R1.25's LSP dies of old age (or is given a
premature death by R1)
f) R2 comes up: R1 says "use pseudonode". R2 issues its first LSP saying
it is connected to R1.25. R1 adds R1.25 to its LSP,
and issues R1.25's LSP with neighbors R1 and R2.
Note I think pseudonode minimization might not work for OSPF, since if I
remember correctly, OSPF reports some things in
the pseudonode LSA (type 2?) like the IP prefix for that link, that I
think cannot go in
a non-pseudonode LSA (type 1?). So I think OSPF needs a pseudonode for
every link. (is this true?). But TRILL IS-IS has *no* information in the
pseudonode LSP other than reporting router neighbors.
Radia
mike shand wrote:
> On 31/01/2008 mike shand wrote:
>
>> I'm not even convinced it simplifies the SPF, but since an SPF for a
>> several hundred node network takes < 1mS, I don't see this as a big
>> issue either way. However for a 15 node LAN, WITH pseudonode you explore
>> 1 hop to the PN then 14 hops to the other nodes, then check on back link
>> from each of the 14 to the PN (i.e 29 links). In the non PN case you
>> explore 14 hops, then another 14 hops back from each of those 14 (i.e.
>> 210 links). It would need a better analysis to determine exactly what
>> the relative merits are, but at best I would say it is a wash, and it
>>
>> might even be a pessimisation not to have a PN.
>>
>>
> I couldn't resist conducting the experiment:-) For what its worth, my
> simulation seems to indicate that the SPF is faster WITH the pseudonodes
> than without, at least for 4 node LANs and above.
>
> I constructed a network consisting of 4 LANs each containing 4 routers.
> The groups of routers were randomly interconnected with point to point
> links.
>
> The average time to run an SPF WITH pseudonodes was 52 uS, and without
> pseudonodes (i.e. each "LAN" of 4 routers was replaced by a fully meshed
> set of pt-pt links... each router connected to the 3 other routers on
> the "LAN", was 64uS.
>
> The absolute values are irrelevant, but it does seem to indicate that,
> for 4 node LANs, the SPF is faster with pseudonodes.
>
>
> As I said, I don't think this matters at all; it is lost in the noise,
> but it certainly can't be said that it is BETTER not to have the
> pseudonodes from the SPF point of view.
>
> Mike
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
More information about the rbridge
mailing list