Subject: [rbridge] FW: Discovering endnodes directly connected to an RBridge

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Fri, 7 Oct 2005 14:07:19 -0400

Previously sent to the wrong address: courtesy outlook :(

-----Original Message-----
From: Saikat Ray [mailto:saikat at seas.upenn.edu] 
Sent: Friday, October 07, 2005 2:04 PM
To: 'Radia Perlman'
Subject: RE: [rbridge] Discovering endnodes directly connected to an RBridge

I think I need a picture, but I think the question is what happens if 
there are two RBridges, W and X,
connected to the same link.

[Saikat] Yes, that was precisely the question.

If that's the question, then the answer is that only one of them gets 
elected "Designated RBridge", say W. Then W
is the only one that learns endnode information (from listening to 
unencapsulated packets, whether they
be data packets or ARP/ND replies). W announces the endnodes on that 
link in W's link state information.

[Saikat] Okay. Is this "RBridge election" process similar to the "designated
bridge election" process of the standard Ethernet? Of course the designation
can also be done after RBridges collect all the LSPs.

W is the only RBridge on that link that listens to unencapsulated 
packets, and the only one that decapsulates
packets when forwarding onto that link.

[Saikat] $X$ will however use the "link" for connectivity reasons (sending
encapsulated packets), right?

I'm confused about the "separate campuses" comment. If you connect 
RBridges, they'll all form one campus.
The only way to make it separate campuses is to partition them and only 
connect them through routers.

[Saikat] I also do not quite follow how Joe defines a "campus".

Radia

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Saikat Ray wrote:
>  
>
>>>>>Thanks for your answers. You have properly understood the question.
>>>>>However, I still have some doubts. Suppose a legacy bridge is connected
>>>>>to (perhaps through a LAN segment) two RBridges. To use my example: the
>>>>>legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports
>>>>>that connect $Z$ to $X$ and $W$, respectively, are in forwarding state.
>>>>>Now suppose a new endnode, $A$, joins a LAN segment connected only to
the
>>>>>legacy bridge $Z$, and the endnode sends out an ARP query. The legacy
>>>>>bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$
>>>>>and $X$ receives this packet. Then isn't it the case that both $W$ and
>>>>>$X$ will think that the new endnode $A$ is "directly" connected to
>>>>>itself?
>>>>>          
>>>>>
>>>>Yes. Which is why both will forward packets addressed to $A$ they
>>>>receive via other ports to the port they each have that attaches to the
>>>>legacy bridge $Z$, which ought to push that traffic - regardless of how
>>>>received - directly toward endnode $A$.
>>>>
>>>>I don't see the problem yet.
>>>>        
>>>>
>>>Two questions come to my mind:
>>>
>>>- Which node ends up in the routing tables of the other RBridges?
>>>      
>>>
>>All external nodes potentially end up in the edge encapsulation tables.
>>Only the egress nodes within a particular rbridge campus will end up in
>>the edge and interior IS-IS routing tables, however, since only
>>encapsulated packets need be forwarded.
>>
>>
>>[Saikat] $X$ and $W$ are individual RBridge Devices. I think the question
>>was that in this example both $X$ and $W$ will advertise "direct
>>connectivity" to endnode $A$ to the rest of the RBridges. Then if some
other
>>RBridge wants to send a packet to node $A$, which RBridge ($X$ or $W$)
will
>>it send the packet to?
>>
>>Could you also kindly answer the next question assuming that $X$ and $W$
are
>>individual RBridge Devices?
>>    
>>
>
>I did:
>
>	if they're in different campuses, there's no conflict
>
>	if they're in the same campus, the external bridge $A$ is
>	effectively connected twice to the same rbridge campus;
>	this is out of spec.
>
>I'm not sure how existing bridges handle this; I would expect that the
>spanning tree ought to pick only one of those ports, i.e., there would
>never be a case where any traffic would flow from $A$ to one of $X$ or
>$Y$, at which point only one of ($X$,$Y$) would advertize any node
>connected to $A$ anyway.
>
>Joe
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDRqi+E5f5cImnZrsRAm3jAKDoHTx2dj/hyUTh1VcBPMXkLScYgwCglOqC
>+NhyO76PXRZqIXW6x6P9q7U=
>=tG3e
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 07 Oct 2005 11:49:10 -0700

>can also be done after RBridges collect all the LSPs.
It is the same as the IS-IS "Designated Router" election on a link. 
IS-IS already has an election to determine
exactly one router to be what it calls "Designated Router". The IS-IS DR 
is the one that names the link,
advertises membership of the link, etc. This is exactly the same thing 
happening when IS-IS is running
with RBridges. One RBridge on the link will be elected.

It is not the same as the "designated bridge election" in the spanning 
tree. That's based on which bridge
is closest to the Root bridge, with ID of bridge breaking ties. And 
that's for a different purpose than IS-IS
Designated Router election. The IS-IS thing is totally local to a link, 
i.e., factors outside the link will
not determine who is elected...it is only a function of IDs and 
priorities of the routers on the link. In contrast,
the DB thing depends on outside things...if the location of the Root 
bridge changes, a different bridge will
become DB.

>encapsulated packets), right?

Correct. X will still use the link for forwarding encapsulated packets.

So I think we understand each other now (assuming I was coherent in the 
explanation of  how "Designated
Bridge" selection differs from "Designated Router" election in IS-IS).

Radia