Subject: Re: [rbridge] Pseudonode minimization thoughts...

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 1 Feb 2008 00:47:35 -0800

Radia -

It seems you missed my point entirely. When I objected to your
characterization of the proposal as:

"I don't think it is complex. It costs 2 bits in Hellos."

I was not trying to demonstrate that the problem is insolvable - just
that the solution is not trivial - and requires care in both
specification and implementation. This raises the bar - at least to me -
in that the benefits have to be worth the cost. Obviously we differ on
that value judgment.

As to your questions:

> a) without configuration, would an IS-IS router today create a
> pseudonode if it is the only router on an Ethernet link?
> For instance, suppose R1 and R2
> are neighbors on an Ethernet, and R2 goes down. Will R1 will issue two
> LSPs, one saying the pseudonode is R1.25 with neighbor R1,
> and another saying R1 has neighbor R1.25? Or when R2 goes down, does
R1
> get rid of the pseudonode?

In order for a router to elect itself DIS on a circuit it MUST have at
least one ES or IS adjacency on that circuit in the UP state. (ISO
10589:2002 Section 8.4.5)

> 
> b) suppose R1 and R2 are both on the same Ethernet, and one is
> configured that that port is pt-to-pt and the other is not configured
> that way. What happens?

No adjacency will be formed as the router which is configured to be
Pt-Pt discards LAN IIHs it receives on that circuit.

> 
> c) suppose R1, R2, and R3 are all on the same Ethernet, and all are
> configured that that port is pt-to-pt. What happens?

No more than one adjacency will be formed on each router. Received
hellos whose system ID does not match an existing adjacency are
discarded.

See Section 4.5 of 

http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-over-lan-06.
txt

for further details.

   Les

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Fri, 1 Feb 2008 09:27:51 -0000

Hi Les,
 
Just for comparison: In the case a.)  then with OSPF, then yes it actually would issue a Psuedonode. (LSA type 2)
 
Matthew

________________________________

From: [email-masked] on behalf of Les Ginsberg (ginsberg)
Sent: Fri 01/02/2008 08:47
To: Radia Perlman
Cc: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Pseudonode minimization thoughts...

Radia -

R1

See Section 4.5 of

for further details.

   Les

---

From: mike shand <[email-masked]>
Date: Fri, 01 Feb 2008 10:50:56 +0000

On 31/01/2008 Radia Perlman wrote:
> You said that to report a neighbor it is 12 octets for narrow metrics, 
> and 1 octets for wide metrics. Is that backwards perhaps?
> I'd think it should take more space to report a side metric, but no 
> matter -- I'll use 12 octets per neighbor. (though it would
> be nice to get a clarification on that -- I could imagine that when 
> they redid the TLV for reporting metrics, they not only
> widened the metric but also compressed the format, or maybe got rid of 
> multiple metrics).
>
Excatly. 12 for narrow, 11 for wide, becuase although the metric istelf 
uses 3 octets rather than one, we only have the single metric, rather 
than 4 separate metrics.

    Mike

---

From: mike shand <[email-masked]>
Date: Fri, 01 Feb 2008 16:29:49 +0000

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

---

From: Radia Perlman <[email-masked]>
Date: Fri, 01 Feb 2008 10:48:27 -0800

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 1 Feb 2008 12:48:39 -0800

Radia -

> (Les confirmed my nightmare, that

Unless you are planning to run ES-IS on IP hosts, you won't have any ES
adjacencies.

Sleep peacefully. :-)

   Les

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Fri, 1 Feb 2008 21:59:10 -0000

Well unless you are running OSPF Les. If this is the case then the pseudonode is generated whether you have an adjacency or not. To turn it off would require removal of the network from the area or explicit Pt-to-Pt configuration/ and messing about. This proposal is accross the boards and covering ospf as well, so this is an issue. This is easily fixed though, by implementing this proposal suggested by Radia et al

MT

From: [email-masked] on behalf of Les Ginsberg (ginsberg)
Sent: Fri 01/02/2008 20:48
To: Radia Perlman; Developing a hybrid router/bridge.
Subject: Re: [rbridge] Pseudonode minimization thoughts...

Radia -

Sleep peacefully. :-)

   Les