Subject: [rbridge] Ingress Rbridge address and BCN

From: manoj.k.wadekar at intel.com (Wadekar, Manoj K)
Date: Fri, 27 Oct 2006 08:20:59 -0700

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
>

---

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

Interesting. In theory, it is possible to send a packet to an unknown 
destination MAC by sending
through the ingress RBridge tree rooted at the RBridge that decided to 
send the BCN (or rooted
at the Designated RBridge on the link on which some legacy bridge 
decided to send the BCN).

But if there are going to lots of BCN's, then it would cut down on 
traffic to know the original
ingress RBridge, since the BCN's would never needed to be sent 
everywhere---just direct to
the ingress RBridge.

Just to make sure I do understand though, the intent is that the BCN 
does need to get to the
original source of the packet, and the ingress RBridge of the original 
packet will only forward the
BCN to the source, right?

Radia

Wadekar, Manoj K wrote:

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

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Fri, 27 Oct 2006 09:52:42 -0700

rbridge-bounces at postel.org wrote:
> Interesting. In theory, it is possible to send a packet to an
> unknown destination MAC by sending through the ingress
> RBridge tree rooted at the RBridge that decided to send the
> BCN (or rooted at the Designated RBridge on the link on which
> some legacy bridge decided to send the BCN).
> 
> But if there are going to lots of BCN's, then it would cut
> down on traffic to know the original ingress RBridge, since
> the BCN's would never needed to be sent everywhere---just
> direct to the ingress RBridge.
> 
> Just to make sure I do understand though, the intent is that
> the BCN does need to get to the original source of the
> packet, and the ingress RBridge of the original packet will
> only forward the BCN to the source, right?
> 
> Radia
> 
> 
> 

My analasys is that an 802.1au-capable RBridge could send
a BCN in three different ways:

1) RBridge encapsulated to the original source c/o its 
   source RBridge, which it already knew. The egress RBRidge
   would typically have this information.
2) non-RBridge encapsulated is sent to the outer source,
   which is the *prior* rbridge and not necessarily the
   source rbridge, and we specify that 802.1au-capable
   RBridges act as proxies for BCNs received that are
   not RBridge encapsulated.
3) RBridge encapsulated to the original source, but with
   an unknown destination RBridge.

I believe that #2 is required anyway, to deal with 802.1au
bridges that are not RBridges.

It is also worht pointing out that unless there are *four*
RBridges in the "rbridge path" that the immediate prior
rbridge to any core rbridge *will* be the source rbridge.

I believe these three options provide adequate solutions
to this problem without requiring the addition of the
source rbridge to the frame. But it does suggest that
the header format should be designed so that it stacks
efficiently with 802.1a headers.

Standardizing the 802.1au proxy role is also important
because otherwise you would have Rate Limited Frame
wrappers around RBridge encapsulation. I believe it 
is far better to ensure that the BCN is forwarded
to the original source so that RBridge encapsulates
the Rate Limited Frame.