[rbridge] Ingress Rbridge address and BCN

[Silvano Gai]

Eric,

If you plan to pragmatically force implementers to keep all the MAC
addresses in the core, then simply don't require the outer
encapsulations. That will be a big saving in term of bandwidth (14
bytes), not the 2 bytes required to carry the ingress RBridge address!

More inline

> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> Sent: Friday, October 27, 2006 8:38 AM
> To: Silvano Gai
> Cc: rbridge at postel.org; Radia.Perlman at sun.com
> Subject: RE: [rbridge] Ingress Rbridge address and BCN
> 
> Silvano,
> 
> 	Your assumption about retention of "inner MAC addresses" in
> RBridges at the core network would be an implementation choice.
> There is, and will be, no statement that "core RBridges MUST NOT
> retain advertisement information relating to MAC DA reachability.
> Nor is it the case that this information is not made available to
> RBridges in the core network.
> 
> 	Hence, if an RBridge implementation has not retained MAC DA
> reachability adsvertisements it receives, that is the choice made
> by that RBridge's implementers.
> 
> 	It is quite reasonable to assume that so-called core RBridges
> may elect not to retain MAC reachability information in cases where
> the "core RBridge" does not need this information.  Supposing that
> a "core RBridge" may need this MAC reachability information and yet
> not have retained it, is arguably a "dumb implementation" issue, as
> opposed to a protocol problem.
> 
> 	Note that an RBridge needs only to have one interface on which
> it has "delivery responsibility" (i.e. - is the designated RBridge)
> for a "native LAN" device (such as an 802.1X bridge), and it cannot
> be a "core RBridge."  With this qualification of what it means to be
> an RBridge in "core networks", this seems likely to be an exception
> case, and it is well known that it is not a good idea to design any
> protocol to be optimized for the exception case.
> 
> 	Already, we have discussed the fact that BCN capable devices
> are typically segregated onto "BCN capable VLANs."  That being the
> case, it is certainly possible for an implementer to retain MAC DA
> reachability advertisements for configured "BCN capable VLANS."

This is not the case, IEEE 802.1au will segregate BCN per VL (an
evolution of UP) not per VLAN.

-- Silvano


> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: rbridge-bounces at postel.org
> --> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
> --> Sent: Friday, October 27, 2006 11: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
> -->