Subject: [rbridge] Access-only link

From: Radia Perlman <[email-masked]>
Date: Wed, 09 Jul 2008 10:56:45 -0700

I forget who mentioned to me at the last IETF the desire to have an 
"access only" port. At the time I found it
scary.

However, after thinking about it, I've convinced myself it's not scary, 
and relatively simple to provide.

We've already added in "trunk only" links, on which data is not 
encapsulated/decapsulated if there happened to
be endnodes present despite configuration to specify the link as "trunk 
only". That feature seemed simple to
provide and useful to me.

I'm a little less clear on why access-only links are as important, since 
it doesn't seem as though the traffic of
LSP propagation would be that much. But again, I think it's simple and 
safe, so if people think it's useful, I wouldn't
oppose it.

The idea is for the DRB to signal in its Hello "this is access-only". 
And in the LSP for the pseudonode, the DRB
can set the "database overflow" flag, which is a flag already in IS-IS 
for the purpose of dealing with a router that
can't hold the LSP database. That flag means "don't go through this node 
unless absolutely no other path exists".
If the "overflow" flag is set in the pseudonode's LSP, that would mean 
that that pseudonode would not be computed
in a path as a transit link.

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

---

From: James Carlson <[email-masked]>
Date: Wed, 9 Jul 2008 15:08:05 -0400

> safe, so if people think it's useful, I wouldn't

The case I remember discussing (Silvano, maybe?) was with a wiring
closet.  There's a set of "backbone" links interconnecting the
RBridges, but there are a pair of RBridges that are incidentally
connected through a local access-side wiring closet.  The owner of the
wiring closet doesn't want any backbone traffic traversing it, no
matter how attractive it might look as a path.

> in a path as a transit link.

I think the desire was for "no way, no how."  Not "go ahead and use
this to patch together the rest of the network if necessary."

Perhaps that's too strict a requirement, but that's what I *thought* I
understood from the lunch table discussion.  Perhaps the others
involved could pipe up and clarify whether overflow would be
sufficient.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 9 Jul 2008 16:10:05 -0400

I'm not sure if this is the case you are recalling, but Bridges that
are part of a blade chassis, a multi-function NIC, or a hypervisor
soft-bridge all have links (actual or virtual) that are inherently
internal and lead only to known end stations. Doing "discovery" on
those links is overkill.

It is already common to optimize spanning tree based on this knowledge.
Similar optimizations would certainly be done should any of those
bridges take on RBridge functionality. Whether this needs to be
in the standard or not is a separate question. It could easily
fall under the rule that an implementation can do whatever it
wants if it doesn't impact anybody else.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Radia Perlman
> Sent: Wednesday, July 09, 2008 10:57 AM
> To: [email-masked] >> "Developing a hybrid router/bridge."
> Subject: [rbridge] Access-only link
>