Subject: [rbridge] Can we ever have pt-to-pt links?

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 05 Nov 2007 22:10:39 -0800

Suppose the topology consisted only of RBridges with pt-to-pt links 
either to each other or
to endnodes, e.g., no bridges, no CSMA/CD. As specified,  we'd wind up 
creating
a pseudonode for each link. Not a total disaster, but it does seem 
suboptimal, especially
if we created a pseudonode for every port that contains an endnode.

I think we discussed this and said that there was no way of knowing for 
sure that a port
was a pt-to-pt link.

Do we want to try to optimize this case, for instance by:
a) allowing a port to be configured as "pt-to-pt", and freaking out (as 
in disabling
the port and declaring an error) if an RBridge sees multiple nodes on 
that port, or sees
a BPDU?
b) assuming if there is only one RBridge neighbors on a port that it is 
a pt-to-pt
link and there does not need to be a pseudonode? That makes me nervous 
because if
a third RBridge comes and goes, then things could get messy.
c) if there are zero RBridge neighbors on a port (just an endnode or
set of endnodes), do not create a pseudonode
for it
d) something else?

Or is it fine as is (if R1 and R2 are connected with a pt-to-pt link, R1 
will get elected DRB,
name the link R1.x, and issue two LSPs -- one for R1, one for R1.x, with 
R1.x claiming
connectivity to R1 and R2). Basically, there will be a pseudonode for 
every RBridge-RBridge
link. I hope we don't have to create a pseudonode for every port to 
every endnode.

Radia

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Mon, 5 Nov 2007 22:26:14 -0800

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Monday, November 05, 2007 10:11 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] Can we ever have pt-to-pt links?
> 
> Suppose the topology consisted only of RBridges with pt-to-pt 
> links either to each other or to endnodes, e.g., no bridges, 
> no CSMA/CD. As specified,  we'd wind up creating a pseudonode 
> for each link. Not a total disaster, but it does seem 
> suboptimal, especially if we created a pseudonode for every 
> port that contains an endnode.
> 
> I think we discussed this and said that there was no way of 
> knowing for sure that a port was a pt-to-pt link.

If you were using LLDP, you could be certain that the link
is a point to point link if the system information in LLDP
matches what you receive in the IS-IS hello.  Or you we could
identify RBridges as a type of device in LLDP itself.
 
> Do we want to try to optimize this case, for instance by:

I think it would be useful to optimize.

> a) allowing a port to be configured as "pt-to-pt", and 
> freaking out (as in disabling the port and declaring an 
> error) if an RBridge sees multiple nodes on that port, or sees a BPDU?
> b) assuming if there is only one RBridge neighbors on a port 
> that it is a pt-to-pt link and there does not need to be a 
> pseudonode? That makes me nervous because if a third RBridge 
> comes and goes, then things could get messy.
> c) if there are zero RBridge neighbors on a port (just an 
> endnode or set of endnodes), do not create a pseudonode for it
> d) something else?

Is a combination of (a) and (b) possible?  A node can
either use LLDP to discover it is point to point (and
that won't change as long as the link stays up), or 
it can be manually configured (in which case if a third
adjacency is discovered, then you switch to broadcast-media
mode and once in broadcast-media mode you never switch
back).

> Or is it fine as is (if R1 and R2 are connected with a 
> pt-to-pt link, R1 will get elected DRB, name the link R1.x, 
> and issue two LSPs -- one for R1, one for R1.x, with R1.x 
> claiming connectivity to R1 and R2). Basically, there will be 
> a pseudonode for every RBridge-RBridge link. I hope we don't 
> have to create a pseudonode for every port to every endnode.
> 
> Radia
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 05 Nov 2007 22:54:44 -0800

Hmm. I don't know what LLDP is, but here is a proposal.

Observation: It's actually OK to consider a link with n RBridges to be 
n*2 pt-to-pt
links as long as n isn't very large.

So here's a proposal:

The Designated RBridge, R1, gets to decide if a particular link is to 
have a pseudonode
or not. R1 specifies either a pseudonode name in its Hello, or some 
value (like 0) that
says "Hey, I don't want to bother with a pseudonode, so just report all 
your RBridge
neighbors as pt-to-pt links".

So if there is a link with R1, R2, R3, and R4, then R1 gets to decide 
whether to
a) create pseudonode R1.x, and R1, R2, R3, and R4 all claim just the 
neighbor R1.x,
and R1.x claims neighbors R1, R2, R3, and R4, or
b) don't create a pseudonode, so R1 claims neighbors R2, R3, and R4...R2 
claims
neighbors R1, R3, and R4, etc.

The only thing special we were doing with the pseudonode was reporting 
the bridge root.
So that means that R1, the DRB, would report the root bridge ID in its 
LSP if
R1 has decided not to create a pseudonode.

We could declare some threshold, like 4 RBridges, and if R1 is DRB and 
there are
every 3 RBridge neighbors on a port, then R1 declares a pseudonode, and 
perhaps
leaves the pseudonode even if one of the neighbors goes down. Maybe once 
a port
is a pseudonode, it stays a pseudonode.

That way R1 would definitely not create pseudonodes for ports with just 
endnodes, or
for ports that are just pt-to-pt links.

The default would be "no pseudonode", but once a port had 3 RBridge 
neighbors, R1 decides
that port should have a pseudonode.

Radia

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 05 Nov 2007 23:11:52 -0800

> R1 has decided not to create a pseudonode.
Actually, let me change that to: "Let's always report the root bridge ID 
in the DRB's
LSP, not the pseudonode LSP"

So I'm getting more comfortable with that proposal -- the DRB only 
declares a pseudonode
if there really are too many neighbors, and switching over from 
non-pseudonode to
pseudnode is really not very disruptive.

Radia

---

From: riw at cisco.com (Russ White)
Date: Tue, 06 Nov 2007 09:35:32 -0500

> pseudnode is really not very disruptive.

In most implementations of IS-IS, there is a way to manually configured
a link as point-to-point, no matter what the layer 2 part of the device
thinks it is. The IS-IS WG pretty much eschewed auto-detection schemes
when we went through this exercise.

:-)

Russ

- --
riw at cisco.com CCIE <>< Grace Alone

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Tue, 6 Nov 2007 09:39:03 -0600

Radia,

The usual approach to specifying the (optimized) behavior you 
describe would be to say something like:

"An implementation MAY be aware that a specific link is point-to-
 point, in which case <the DRB election process> MAY be omitted."

However, it is worth realizing that this relies on a common view
at both ends of the point-to-point link.  What happens if one end
tries to perform a DRB election and the other does not?

It then becomes necessary to specify the behavior in this case.

I suspect that - if one has valid reasons to think that a link is 
point-to-point - one might configure both ends to assume this is 
the case.  In the event that any RBridge on the link tries to do
DRB election, then this MUST become the common mode.

Using that approach, the only failure mode where RBridges will
become confused is if three (or more) RBridges are 1) connected
to the same shared media and 2) configured to assume P2P.

Clever implementations MAY deal with that scenario in some robust
way - but we should not need to specify how that may be done (it
is always possible to misconfigure yourself into a hole, so there
is little point in trying to prevent that).

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Tuesday, November 06, 2007 1:11 AM
> knowing for 
> freaking out (as 
> that it is 
> pt-to-pt link, R1

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 06 Nov 2007 09:44:07 -0800

I'm going to ask on the IS-IS list. Manual configuration is actually 
scarier (and harder) because different
RBridges can be configured differently. With this proposal (the DRB
switches over to pseudonode once there are, say, 3 other RBridges on the 
link, and perhaps
stays that way forever, or until there is ever a time when there is just 
one (or zero) RBridge neighbors.
It's not disruptive to take away the pseudonode when there are very few 
neighbors, since
the coming or going of an RBridge neighbor would require reissuing the 
pseudonode LSP
anyway. So if there were three guys, R1, R2, and R3, with pseudonode 
R1.x, then if
R3 went away, and we kept the pseudonode, then the pseudonode (R1.x) 
would reissue its
LSP saying it now had just two neighbors (R1 and R2), whereas if R1 
decided to
go with "no pseudonode now", then R1 would change its Hello to be "no 
pseudonode",
and R1 and R2 would reissue their LSPs to say their only neighbor was 
eachother (R1 would
remove R1.x as a neighbor and say it is connected to R2....similarly R2).

There is no confusion about whether or not there is a pseudonode because 
the DRB decides.
The exact algorithm for deciding doesn't have to be standardized even, 
though we certainly
should recommend something.

Radia

Russ White wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>   
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHMHu0ER27sUhU9OQRAgyEAKC3ic9tS1kROaWxVSWuwnrr2HUh9gCeJJss
> wNbLsz14yV/oQ3FCO6Xh2Pg=
> =vYAd
> -----END PGP SIGNATURE-----
>

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 06 Nov 2007 11:07:37 -0800

FYI: This is the proposal I'm running by the IS-IS list. Summary: DRB 
chooses whether
or not to create a pseudonode on the port, and tells the other RBridges 
whether to
claim pt-to-pt links to the other RBridges on the link, or attachment to 
a pseudonode.
Algorithm: if R1 has zero or one RBridge neighbor, no pseudonode. If R1 has
4 or more RBridge neighbors, R1 creates pseudonode for the port. If R1 
has 2 o3
3 RBridge neighbors, R1 leaves the state of the link (pseudonode or not) 
alone.

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

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

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Tue, 6 Nov 2007 13:51:42 -0600

Radia,

	I think taking this to the IS-IS mailing list is a great idea.
I'd hate to think we were trying to "fix" something to do with IS-IS
generally, in this working group.

	However, as a general observation, the argument that putting
complexity into protocol - to avoid some types of configuration
errors - is often used, and frequently either wrong or irrelevant.

	As the paraphrased saying goes, people who think anything can 
be made proof against configuration error are under-estimating the
ability, inventiveness and - possibly - evil intentions of the person 
doing the configuration.

	Also, in many cases, it is better for a misconfigured network
to not work at all, than it is to have it working in some unexpected
way.

	In my opinion, implementers want to build equipment that 
behaves reasonably under misconfigured operating conditions, and
that may simply mean that it doesn't fail in some spectacular way.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Tuesday, November 06, 2007 12:44 PM
> To: Russ White
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Can we ever have pt-to-pt links?
> 
> scarier (and harder) because different RBridges can be configured 
> differently. With this proposal (the DRB switches over to pseudonode
> once there are, say, 3 other RBridges on the link, and perhaps stays
> that way forever, or until there is ever a time when there is just 
> It's not disruptive to take away the pseudonode when there are very
> few neighbors, since the coming or going of an RBridge neighbor would
> require reissuing the pseudonode LSP anyway. So if there were three
> guys, R1, R2, and R3, with pseudonode R1.x, then if R3 went away, and
> we kept the pseudonode, then the pseudonode (R1.x) would reissue its
> decided to go with "no pseudonode now", then R1 would change its
> Hello to be "no pseudonode", and R1 and R2 would reissue their LSPs 
> to say their only neighbor was each other (R1 would remove R1.x as a
> neighbor and say it is connected to R2....similarly R2).
> 
> There is no confusion about whether or not there is a pseudonode
> because the DRB decides.
>

> though we certainly should recommend something.
> 
> Radia
> 
> 
> 
> 
> Russ White wrote:

---

From: riw at cisco.com (Russ White)
Date: Tue, 06 Nov 2007 15:19:43 -0500

> RBridges can be configured differently. With this proposal (the DRB

I'm pretty certain the worst that is going to have with two ends
configured differently is that the link won't be used for transit. One
end will be transmitting a pnode, but the other end won't be advertising
a connection to it--instead, it will be advertising a connection to the
other is on the link. This means the twcc won't work, and the tree won't
build through that link.

The only other possibility is that the link could be configured for
p-2-p, while there are actually three devices on it. A good
implementation would shut down all adj's on such a link, but that's
implementation specific, though perhaps we should have suggested in the
p-2-p draft.... Even if it tries to form, the twcc across the 0 cost
backlinks to the pnode are going to cause the tree to fail to build
through the link, I think. It might build for the pair that do build an
adjacency, but the third is on the link will just be left out in
everyone else's tree.....

Hence, I think the manual configuration option is pretty safe.... And,
the protocol can't tell if the link was intended to be a p-2-p or not.
If you have a link with three is', and one fails, auto detecting the
link has now become p-2-p makes everyone in the domain run SPF. If you
don't do the auto-detection, they can run a partial, just slicing off
the link that failed.

:-)

Russ

- --