Mailing List Archive

A poster off-list suggested BFD.

Can you clarify this a bit? I think you're looking at the problem
backwards.

+------+ /---------\ +-----+
| MLXe | -- Network -- | CER |
+------+ \---------/ +-----+
| |
+------+ +-----+
| A | | B |
+------+ +-----+

When the "Network" fails, devices A & B (both of them) need to see their
Ethernet links go down.

If A & B supported BFD then I wouldn't need this link state propagation
behavior at all. They're black boxes that, per the vendor, are meant to
be directly connected.

So what I need is for the MLXe and the CER to communicate in some way
(MPLS / Ethernet OAM) and when that communication is interrupted, drop
the Ethernet link on the ports facing the devices.

My next best solution is that the vendor knows of some third-party
devices that can do exactly this behavior. I'll go that route if I can't
do it with the gear we already have.

--
Richard

There might be something that can be done with IEEE 802.1ag CFM, which you
night be able to implement using a Ethernet demarcation device from someone
like Adva, Metrodata etc.

I seem to remember one of our engineers talking about single member LAG for
this.

Brocade MRP might also address this need.

Those are three ideas that could help.
On 21 Aug 2014 21:25, "Richard Laager" <rlaager@wiktel.com> wrote:

> A poster off-list suggested BFD.
>
> Can you clarify this a bit? I think you're looking at the problem
> backwards.
>
> +------+ /---------\ +-----+
> | MLXe | -- Network -- | CER |
> +------+ \---------/ +-----+
> | |
> +------+ +-----+
> | A | | B |
> +------+ +-----+
>
> When the "Network" fails, devices A & B (both of them) need to see their
> Ethernet links go down.
>
> If A & B supported BFD then I wouldn't need this link state propagation
> behavior at all. They're black boxes that, per the vendor, are meant to
> be directly connected.
>
> So what I need is for the MLXe and the CER to communicate in some way
> (MPLS / Ethernet OAM) and when that communication is interrupted, drop
> the Ethernet link on the ports facing the devices.
>
> My next best solution is that the vendor knows of some third-party
> devices that can do exactly this behavior. I'll go that route if I can't
> do it with the gear we already have.
>
> --
> Richard
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>

As I posted on the Calix Community for you today, Accedian NIDs and their link propagation feature that uses EVC status. =)

Frank

-----Original Message-----
From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Richard Laager
Sent: Thursday, August 21, 2014 3:51 PM
To: foundry-nsp@puck.nether.net
Subject: Re: [f-nsp] Link State Propagation over Ethernet

A poster off-list suggested BFD.

Can you clarify this a bit? I think you're looking at the problem
backwards.

+------+ /---------\ +-----+
| MLXe | -- Network -- | CER |
+------+ \---------/ +-----+
| |
+------+ +-----+
| A | | B |
+------+ +-----+

When the "Network" fails, devices A & B (both of them) need to see their
Ethernet links go down.

If A & B supported BFD then I wouldn't need this link state propagation
behavior at all. They're black boxes that, per the vendor, are meant to
be directly connected.

So what I need is for the MLXe and the CER to communicate in some way
(MPLS / Ethernet OAM) and when that communication is interrupted, drop
the Ethernet link on the ports facing the devices.

My next best solution is that the vendor knows of some third-party
devices that can do exactly this behavior. I'll go that route if I can't
do it with the gear we already have.

--
Richard


_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp