Subject: Re: [rbridge] Redundancy for appointed VLAN forwarder

From: Sambath Kumar Balasubramanian <[email-masked]>
Date: Mon, 4 Oct 2010 13:40:21 -0700 (PDT)

Hi Donald,

  Resending the mail with some corrections.

  Thanks for your response. Yes I am thinking of end stations 
multihomed to two or more Rbridges. What I meant in terms of 
flooding is that all the Rbridges in the campus will have to remove
the remote entries learnt through the failed appointed forwarder 
and till that time they relearn the MAC (assuming ESADI is not 
implemented), the unknown macs gets to all Rbridges. I have 
not thought of a complete solution, but I am thinking more in 
lines with VRRP where two Rbridges share the same nickname 
and provide redundancy to the end stations and also to the
remote Rbridges so that when the appointed forwarder fails,
the backup can takeover without any disruption.

There are issues with this especially if the link consists of bridges
since the appointed vlan forwarded is essentially proxying the remote
mac addresses (bridges in the link learn the remote mac address
as though they are located on the appointed forwarder), but before
putting effort into defining a solution I wanted to check if this is
a relevant problem to solve or does existing TRILL specification solves
this already (Maybe I missing something)

Regards,
Sambath

----- Original Message ----
From: Sambath Kumar Balasubramanian <[email-masked]>
To: Donald Eastlake <[email-masked]>
Cc: [email-masked]
Sent: Mon, October 4, 2010 1:38:46 PM
Subject: Re: [rbridge] Redundancy for appointed VLAN forwarder

Hi Donald,

  Thanks for your response. Yes I am thinking of end stations 
multihomed to two or more bridges. What I meant in terms of 
flooding is that all the Rbridges in the campus will have to remote 
the remote entries learnt through the failed appointed forwarder 
and till that time they relearn the MAC (assuming ESADI is not 
implemented), the unknown macs gets to all Rbridges. I have 
not thought of a complete solution, but I am thinking more in 
lines with VRRP where two Rbridges share the same nickname 
and provide redundancy to the end stations and also to the
remote Rbridges so that when the appointed forwarder fails,
the backup can takeover without any disruption.

There are issues with this especially if the link consists of bridges
since the appointed vlan forwarded is essentially proxying the remote
mac addresses (bridges in the link learn the remote mac address
as though they are located on the appointed forwarder), but before
putting effort into defining a solution I wanted to check if this is
a relevant problem to solve or does existing TRILL specification solves
this already (Maybe I missing something)

Regards,
Sambath

----- Original Message ----
From: Donald Eastlake <[email-masked]>
To: Sambath Kumar Balasubramanian <[email-masked]>
Cc: [email-masked]
Sent: Mon, October 4, 2010 10:59:55 AM
Subject: Re: [rbridge] Redundancy for appointed VLAN forwarder

Hi Sambath,

Yes, if an RBridge fails, you want to detect that failure quickly and
change the routing and, if relevant, forwarder appointment to adjust
to the failure. You can lose traffic until you have adjusted to the
failure. I'm not sure why their would be "flooding". What sort of
scenario are you thinking of?

If an end station has a point-to-point connection to an RBridge, you
don't have any alternative. So I assume you are thinking of something
like end stations connected to a bridge that is multi-homed to two or
more RBridges...

Thanks,
Donald

On Mon, Oct 4, 2010 at 12:50 PM, Sambath Kumar Balasubramanian
<[email-masked]> wrote:
> Hi,
>
>  I am going through the TRILL draft and I see that the failure of
> appointed VLAN forwarder has implications on the traffic network
> wide which will result in flooding of traffic and also traffic loss till
> the DRB appoints a new forwarder for the VLAN. Am I interpreting
> the draft correctly?
>
> If the above is true is there any work on adding redundancy features
> for appointed VLAN forwarder? From the view of the problem TRILL
> is trying to solve do we needthis redundancy?
>
>  Regards,
> Sambath
>
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Oct 2010 15:32:23 -0700

On 10/ 4/10 01:40 PM, Sambath Kumar Balasubramanian wrote:
> multihomed to two or more Rbridges.

That could correspond to two different topologies, depending on whether 
the network is bridged together between the Rbridges and the end stations.

The non-bridge case is e.g.,

	RB1               RB2
	 |                 |
	B1                B2
	 |                 |
	port1 End Station port2

The bridged case is e.g.,

	RB1               RB2
	 |                 |
	B1 -------------- B2
	 |                 |
	port1 End Station port2

In both cases I assume the end station is running something like Linux 
NIC bonding or Solaris IPMP to fail over between the NICs, but that is 
just layering on top of the fact that the end station has two NICs with 
different MAC addresses.

However, some of those host technologies might do MAC address movement 
on failure, while others only do IP address movement between the NICs.

Which is the above cases are you concerned about?

    Erik