[f-nsp] Link State Propagation over Ethernet

Justin Keery justin.keery at venus.co.uk
Thu Aug 21 17:46:16 EDT 2014


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 at 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 at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20140821/d32b338c/attachment.html>


More information about the foundry-nsp mailing list