Subject: [Isis-wg] Proposal to optimize out pseudonodes in most cases

From: Radia Perlman <[email-masked]>
Date: Tue, 06 Nov 2007 10:09:07 -0800

I was worried about TRILL's use of IS-IS, where amost all ports would be
1) Ethernet
2) and pt-to-pt

so it seemed wasteful to create a pseudonode for every port, especially 
since some of them
might even be ports with just a single endnode.

So here's a proposal, but first some observations.

Observations: A pseudonode is useful when there are a large number of 
router neighbors,
but things would work just fine with on a multiaccess link if there were 
just, say, 4 router
neighbors, R1, R2, R3, R4.

How a multiacess link works with 4 router neighbors:
. With pseudonode: 5 LSPs (R1.x, R1, R2, R3, R4). R1.x lists all of R1, 
R2, R3, R4. the
non-pseudonode LSPs are smaller, listing only R1.x. When one RBride, say 
R3 goes down,
only one LSP needs to be reissued (R1.x).

. Without pseudonode: 4 LSPs, but all of them list 3 neighbors. When R3 
goes down, all 3
remaining routers need to reissue their LSPs.

So...I'd claim with one or two routers on the link, it's clearly more 
efficient with no pseudonode.
With 3 or 4 routers on a link, probably still more efficient with no 
pseudonode but either with
or without works.
With 5-7 routers on a link, probably more efficient with a pseudonode 
but either with or
without a pseudonode works.
With more than 8 routers on a link, it's clearly more efficient with a 
pseudonode.

Still observing rather than proposing...We definitely want to avoid
configuration, especially configuration where if neighbors are
differently configured, things are confused.

********************************************************

So here's the proposal.

a) perform normal DR election. If R1 is the only router, R1 is the DR. 
Assuming there
are other routers on the link, say R1, R2, R3, and R4, let's say R1 is 
the DR.

b) R1 (DR) is the one that decides on behalf of the link whether there will
be a pseudonode or not.
R1 has some algorithm for deciding if there should be a pseudonode. In 
R1's Hello
it says "the name of the pseudonode is R1.x", which means that there 
will be a pseudonode.
The other routers issue LSPs claiming to be connected to R1.x. 
However....if R1
decides not to have a pseudonode, then R1's Hello says "the name of the 
pseudonode is 0"
in which case any routers on the link claim the other routers on the 
link as direct neighbors.

c) a reasonable strategy for DR R1 to decide when to have a pseudonode: 
If R1 has zero or
one router neighbors on the link, R1 puts the link into "no pseudonode" 
mode.
If R1 has at least 4 router neighbors, R1 puts the link into 
"pseudonode" mode.
If R1 has 2 or 3 router neighbors, R1 does not change the state of the 
link. (so 3 router
neighbors have to come up or go down before R1 switches the link between 
pseudonode
vs no pseudonode).

d) if you aren't DR, then you do as you are told.

I believe this proposal is
1) zero configuration
2) safe
3) simple
4) not disruptive if a router is going up and down
5) no danger of confusion
6) much more efficient than creating a pseudonode for every port

But I may be missing something. Comments?

Thanks,

Radia

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Radia Perlman <[email-masked]>
Date: Tue, 06 Nov 2007 14:25:36 -0800

Actually, with the proposal as stated, whether there is a pseudonode or 
not is not
affected by one or even two routers going up/down. As stated it requires
3 routers to go down (or up) before the DR decides to add/remove
the pseudonode. And I picked the algorithm
out of the air. The thresholds could be changed (for instance, add a 
pseudonode
only when there are 6 routers on the wire). Or there could be hysteresis 
(once
there is a pseudonode, don't get rid of it again ever, or after at least 
an hour with
only one router neighbor, or whatever).

But to explain why one (or even two) routers going up/down will not 
affect whether
there is a pseudonode or not (in the proposal where thresholds are 1 or 
2 routers: no
pseudnode, 5 or more: pseudode, 3 or 4: keep the pseudonode if there was 
one,
don't add a pseudonode if there was not any)

Let's look at a link with 5 routers (R1, R2, R3, R4, R5), with R1 being DR.

Let's say they come up one by one, starting with R1
a) R1 up -- no pseudonodes
b) R2 comes up -- no pseudonode -- R1 and R2 claim each other as neighbors
c) R3 comes up -- no pseudonode -- R1, R2, and R3 each claim 2 router 
neighbors
d) R4 comes up -- still no pseudnode, R1, R2, R3, and R4 all claim 3 
router neighbors
e) R5 comes up -- R1 decides it's time for a pseudonode. R1 mentions 
that in its LSP.
Note current routing still works (R2 and R3 *are* actually neighbors). 
All 5 routers --
R1, R2, R3, R4, and R5 -- all issue new LSPs, plus R1 issues one on 
behalf of R1.x
f) R5 goes down -- R1 keeps pseudonode, reissues R1.x without R5. R1, 
R2, R3, R4's LSP
unchanged
g) R4 goes down -- R1 keeps pseudonode, reissues R1.x without R4. R1, 
R2, R3's LSPs
unchanged.
h) R3 goes down -- R1 gets rid of pseudonode. LSPs R1 and R2 reissued 
changing neighbor
from "R1.x" to each other.
i) R2 comes up: go to step b).

I hope that's clearer now.

Thanks,

Radia

Russ White wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Some thoughts... :-)
>
>   
>> 1) zero configuration
>> 2) safe
>> 3) simple
> I tend to think this would be very disruptive in the case of a flapping
> or otherwise state changing IS--particularly if that IS is the third IS
> on the link. The link would change from being a pnode link and back each
> time the third IS changes state, causing a complete rerun of SPF in the
> entire domain, etc.
>
> This is compounded by the amount of time it takes to actually do the
> election--with the current emphasis on fast convergence, we'd have to
> wait 'til the DIS is elected, is certain no other IS' are on the link,
> and then wait 'til the DIS signals the new state.... Should the other
> IS' on link wait dead interval to advertise their link to the pnode? Or
> do they wait until they see the pnode issued?
>
> IMHO, it's better to leave this as a manual config, since the admin
> knows what the intended state of the link is....
>
> If the WG determines this is a good idea, then I would, at the least,
> recommend that this be advertised as part of some sort of "link local"
> capabilities LSP, rather than as part of the hello....
>
> :-)
>
> Russ
>
> - --
> [email-masked] CCIE <>< Grace Alone
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHMM9qER27sUhU9OQRAvrkAJ44JE6q13sKRbCKHWal7QJ0KFLShACgl6/P
> Bydb5TYGxqFBhKv265exbTs=
> =o/GY
> -----END PGP SIGNATURE-----
>

---

From: Tony Li <[email-masked]>
Date: Tue, 6 Nov 2007 15:46:09 -0800

Hi Radia

> Actually, with the proposal as stated, whether there is a  
> pseudonode or not is not
> out of the air. The thresholds could be changed (for instance, add  
> a pseudonode
> only when there are 6 routers on the wire). Or there could be  
> hysteresis (once
> there is a pseudonode, don't get rid of it again ever, or after at  
> least an hour with

I'm fine with your proposal in principle, but have some concerns  
about the low level implementation details and backward compatibility.

In particular, please recall that the correspondents normally need to  
list an adjacency to the LAN ID within their own LSPs.  The LAN ID is  
the system ID of the DIS along with a one byte pseudo-node number.

It's possible that there are implementations out there that are  
expecting only non-zero pseudo-node numbers.  Such implementations  
might react badly if the DIS advertised a pseudo-node number of zero.

It would seem reasonable to me that one way around this would be to  
create a new TLV to be included in LAN IIHs that would indicate a)  
that the system advertising the TLV was capable of this point-to- 
point behavior and b) that the DIS was requesting that "no pseudo- 
node mode" be active (or not).

This would allow the DIS to detect if there are legacy  
implementations out there on the Ethernet and not change behavior if  
so.  This would also allow the DIS to continue to advertise a  
syntactically normal LAN ID, even when no pseudo-node mode was in  
effect.

Thoughts?

Regards,
Tony

---

From: Radia Perlman <[email-masked]>
Date: Tue, 06 Nov 2007 16:49:07 -0800

Actually, there wouldn't be any legacy stuff that would be running IS-IS 
for RBridges.
We want to make it as easy as possible to modify an implementation of 
IS-IS for IP to
be IS-IS for TRILL, but a legacy device wouldn't even see the TRILL 
messages.

The legacy issue would come up if the IS-IS working group would like to 
adopt this
idea for IS-IS routers, which I think might be a good idea.

So, for that reason, it would be good as you said to come up with an 
encoding that
wouldn't freak out existing implementations. I think the following
is pretty much what you were sketching, or similar anyway.

The DIS (R1) could always advertise
a 7-byte pseudonode ID in its Hello, but also put in a TLV flag in the 
Hello saying "I'd prefer not
actually advertising an LSP for this pseudonode if all you guys on the 
link are cool with that".
Plus a flag in the Hello (whether or not you are DIS)
saying "I'm smart enough to not mention the pseudonode".

A legacy guy (say Fred) would ignore those flags and claim connectivity 
to the pseudonode. Once
Fred attaches, and sends a Hello without the "I'm smart enough not
to mention the pseudonode" flag, R1 would remove the "don't advertise 
the pseudonode" flag.
If Fred goes up and down, we'd want to minimize disruption, so the DIS 
should probably
stay in pseudonode mode for a long time even after Fred goes down.

Anyway....the encoding is something to think about. I think that's the 
IS-IS WG's job to
come up with exact encodings. TRILL should just say all the information 
they'd like
captured in Hellos and LSPs.

Thanks,

Radia

Tony Li wrote:
>
> Hi Radia
>
>> Actually, with the proposal as stated, whether there is a pseudonode 
>> or not is not
> I'm fine with your proposal in principle, but have some concerns about 
> the low level implementation details and backward compatibility.
>
> that the system advertising the TLV was capable of this point-to-point 
> behavior and b) that the DIS was requesting that "no pseudo-node mode" 
> be active (or not).
>
> This would allow the DIS to detect if there are legacy implementations 
> out there on the Ethernet and not change behavior if so.  This would 
> also allow the DIS to continue to advertise a syntactically normal LAN 
> ID, even when no pseudo-node mode was in effect.
>
> Thoughts?
>
> Regards,
> Tony

---

From: Russ White <[email-masked]>
Date: Tue, 06 Nov 2007 15:32:42 -0500

Some thoughts... :-)

---

From: Russ White <[email-masked]>
Date: Tue, 06 Nov 2007 15:32:42 -0500

Some thoughts... :-)

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Tue, 06 Nov 2007 18:55:09 -0500

entire domain, etc.

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Tue, 06 Nov 2007 18:55:09 -0500

> the pseudonode. 

So, you're thinking that you would always create a pnode when there are
4 routers on the link, and only remove the pnode when you reach 2
routers on the link? Actually, you would have to make it five and two, I
think....

:-)

Russ

- --

	from cisco.com/sjdkim2002 verified; ); 
Cc: [email-masked]

> the pseudonode. 

So, you're thinking that you would always create a pnode when there are
4 routers on the link, and only remove the pnode when you reach 2
routers on the link? Actually, you would have to make it five and two, I
think....

:-)

Russ

- --