Subject: [rbridge] Ingress Rbridge address and BCN

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 27 Oct 2006 11:43:41 -0400

Manoj,

	Once again, the assumption that cores do not retain "addresses of
all the end-stations in [the] whole cluster" is a "convenient assumption"
for making the argument that another mechanism is required.

	Currently, there would be no requirement for retaining all such 
addresses as you have to be careful not to send BCN messages to those
end-stations that don't support them.  Moreover, as mentioned previously,
it is trivially easy to determine what address information should be kept.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Wadekar, Manoj K
--> Sent: Friday, October 27, 2006 11:21 AM
--> To: rbridge at postel.org
--> Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> 
--> Yes, for large clusters, if cores do not maintain addresses 
--> of all the
--> end-stations in whole cluster - then only way to get BCN 
--> back to ES, is
--> to send them to ingress rbridge-address and then have that ingress
--> rbridge forward BCN to end station with appropriate ES address.
--> 
--> If so, ingress rbdridge address seems to be requirement to me.
--> 
--> Thanks,
--> - Manoj
--> 
--> -----Original Message-----
--> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
--> Sent: Friday, October 27, 2006 8:00 AM
--> To: Radia.Perlman at sun.com; Wadekar, Manoj K
--> Cc: rbridge at postel.org
--> Subject: RE: [rbridge] Ingress Rbridge address and BCN
--> 
--> 
--> If the congestion is detected in the core of the TRILL 
--> network, how do
--> you signal back to the source host if you don't know which is the
--> ingresss RBridge? 
--> 
--> You cannot look-up the inner MAC address, because in the core of the
--> network you don't keep the inner MAC addresses in the 
--> table. Correct?
--> 
--> This is a clear reason while you need the ingress RBridge address.
--> 
--> -- Silvano
--> 
--> > -----Original Message-----
--> > From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]
--> On
--> > Behalf Of Radia.Perlman at sun.com
--> > Sent: Thursday, October 26, 2006 5:02 PM
--> > To: Wadekar, Manoj K
--> > Cc: rbridge at postel.org
--> > Subject: Re: [rbridge] Ingress Rbridge address and BCN
--> > 
--> > Hi Manoj,
--> > 
--> > I'm confused about BCN. Wouldn't congestion notification 
--> need to go to
--> the
--> > original endnode source,
--> > and not the ingress RBridge?
--> > 
--> > Radia
--> > 
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 27 Oct 2006 09:31:57 -0700

I think the intent is that RBridges not keep endnode information they 
don't need to keep. So for instance,
if the BCN is being sent to an endnode in VLAN A, an intermediate 
RBridge that does not have a
VLAN A link would not know about the endnodes in VLAN A. It would know 
which links are in VLAN A,
so it wouldn't have to send the BCN to every link, but it wouldn't know 
which VLAN A link had the endnode.
And also, it would be reasonable to have a core of RBridges that don'e 
have any endnodes.

Potential ways of dealing with BCN, and their costs:
a) make all RBridges know about all endnodes, just in case they want to 
send a BCN
b) flood BCNs to more links than necessary (the links in the VLAN) when 
the endnode is unknown
to the RBridge initiating the BCN
c) include the ingress RBridge in the shim header.

I'm not that excited about BCN---it's a new functionality, who knows if 
it will ever be widely deployed,
etc. However, what's interesting about it is that it does present a 
reason why it is useful to have
ingress RBridge there. Which means we might stumble on other things in 
the future.

I was a bit uncomfortable about overloading a field with "sometimes 
ingress sometimes egress".
Since we changed over to nicknames so we only need 2 bytes to specify 
each RBridge (rather than
6 bytes for each), I'm leaning to doing this. The cost is an extra 2 
bytes in the header, and not being
MPLS-like, but given that people have said being MPLS-like and not 
"exactly MPLS" is not that
much of an advantage, the cost then becomes 2 bytes, which seems worth 
it for what seems
like a more conventional design (encapsulating with both ingress and 
egress).

Radia

Gray, Eric wrote:

>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://mailman.postel.org/mailman/listinfo/rbridge
>  
>