[rbridge] Ingress Rbridge address and BCN
Radia.Perlman at sun.com
Fri Oct 27 09:31:57 PDT 2006
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
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
Gray, Eric wrote:
> 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.
>--> -----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.
>--> - 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]
>--> > 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
>--> > original endnode source,
>--> > and not the ingress RBridge?
>--> > Radia
>--> rbridge mailing list
>--> rbridge at postel.org
>rbridge mailing list
>rbridge at postel.org
More information about the rbridge