Skip to Content.
Sympa Menu

ntacpeering - Re: [2013-l3-architecture] FOR DISCUSSION: IP over AL2S

Subject: NTAC Peering Working Group

List archive

Re: [2013-l3-architecture] FOR DISCUSSION: IP over AL2S


Chronological Thread 
  • From: Grover Browning <>
  • To: " Routing WG" <>
  • Subject: Re: [2013-l3-architecture] FOR DISCUSSION: IP over AL2S
  • Date: Thu, 30 May 2013 09:58:37 -0400
  • Authentication-results: sfpop-ironport05.merit.edu; dkim=neutral (message not signed) header.i=none

I believe so, yes.

Are you thinking we would want MPLS on current L2 nodes, or is this maybe in the context of of understanding the paths of the full mesh?


On May 30, 2013, at 9:23 AM, Paul Schopis <> wrote:

Do the brocade boxes support MPLS Traceroute? 



Paul Schopis
Chief Technology Officer
OARnet
1224 Kinnear Rd
Columbus, OH 43212
Ph. 614-292-1956
email: 

From:  [] on behalf of Grover Browning []
Sent: Thursday, May 30, 2013 9:20 AM
To: John Moore
Cc: 
Subject: Re: [2013-l3-architecture] FOR DISCUSSION: IP over AL2S

I agree. Maybe something like:

*) Total connector (member?)  availability (with a target of 100%)
*) Impaired availability (I had to fail over from my 100g to my 10g and ran that way for 4 hours)

This, within the context of a L3 full mesh using VLAN/SDN L2 paths and MPLS FRR. Does that sound like a decent plan to everyone?




On May 29, 2013, at 1:58 PM, John Moore <> wrote:

I think the member availability idea is important, certainly not a distraction. It's a good differentiator for us, particularly with new constituents like healthcare and public safety that some of the regionals are aggressively pursuing.

I'd be OK with counting a sub-100 ms restoration event as impaired but not down, so that the member availability number doesn't see a hit. A metric that indicates how long we were in the impaired (or non-optimal) state might be useful, perhaps from the latency matrix.

John M


On Wed, May 29, 2013 at 7:54 AM, Grover Browning <> wrote:
VLANs/Trill gets you the link failure faster but FRR gets you the path restoration faster, correct?

We seem to have three issues here, the topology, the L2 mechanism, and the L3 restoration mechanic. I believe the L2 mechanism was decided in the calls over the last couple of months; a combination of VLAN paths and SDN paths.

On the topology, I agree with the full mesh approach Michael. Mimicking the in/out behavior of L3 doesn't seem to have any real advantages and at least one major disadvantage.

L3 restoration is a more interesting discussion, I think. FRR gets the I2 L3 system up to the state of modern communication networks. If it's not a distraction then I'd also like to see a greater effort put in to a kind of "member availability" figure. Some way to calculate availability and "impaired but not down" figures for a set of BGP connections. IE: move the discussion from individual restoration technologies to a more holistic view of member availability. While reducing a path restoration to <100ms is a great goal I'd also like to see us move toward 100% member availability.



On May 24, 2013, at 11:50 AM, Michael H Lambert <> wrote:

> On 24 May 2013, at 10:04, Grover Browning wrote:
>
>> Full mesh with MPLS FRR/BFD.
>
> Trying to see past my knee-jerk, religious, "MPLS is Evil" initial reaction...
>
> Let's assume that at some point in the not-too-distant future we have solid, full-featured implementations of OpenFlow version x.y, where ((what we need) <= x.y < (what we want)).  What do we want the IP-over-AL2S topology to look like at that time?  If it's a full mesh of SDN-configured paths, then why not start out with a topology that mimics that goal.  If it's not, then we might want to go in some other direction in the interim.  I would conjecture that a full mesh is a reasonable approach, at least until we have a tight(er) coupling among SDN, routing protocols and real-time flow switching.
>
> As an alternative to MPLS/FRR/BFD, how about traditional VLANs on top of TRILL rather than spanning tree?
>
> Michael




-- 
John H. Moore
Senior Director, Innovation and Strategy 
Chief Security Officer
MCNC

919.248.4186 (desk)
434.284.3990 (mobile)






Archive powered by MHonArc 2.6.16.

Top of Page