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

[Eric Gray]

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  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> 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?
> 
> 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 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.
>
> 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
> >
> >
> >   
> >>> 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.
> >>>
> >>>       
> >> 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.
> >>     
> >
> > 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
> >
> > -----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-----
> >   
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>