NTAC Peering Working Group

[Paul Schopis <>]

Steve,
Understood, but there is a subtle difference between the intended path and the path taken. It's not like I have ever seen an IP/MPLS/Ethernet packet go somewhere unexpected ;-)

Paul

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

---

From: Steven Wallace []
Sent: Thursday, May 30, 2013 10:52 AM
To: Paul Schopis
Cc: Grover Browning; Routing WG
Subject: Re: [2013-l3-architecture] FOR DISCUSSION: IP over AL2S

Paul, 

I think you've hit on something that's going to require network engineers to re-think certain approaches to troubleshooting. IMO, the idea of an in-band probe to determine the path is simply not going to be a part of the SDN future (I could be wrong, but that's my prediction). The good news is that you no longer need it. What I mean is that the controller knows the entire path. I would be asking for an app where the engineer can easily  say to AL2S "what's the path for this flow" and the app responds with the complete path as it exists in realtime.

ssw

On May 30, 2013, at 10:42 AM, Paul Schopis <> wrote:

Grover, 
Yes I am specifically concerned about the lack of tools to see where things go. Sorry to sound curmudgeonly, but I don't see what a full mesh buys one except obscurity as to what is really going on. The packet still must transverse the same number of hops etc, the virtualization does not change that. I do acknowledge taking things all the way up to the router/IP Layer does add some overhead. 

The only way I can see getting similar functionality into OF is write an app that runs on the controller and insert a rule in a switch that if a packer contains an OF echo/traceroute request (mechanism TBD) punt to the controller to punt to the app to respond. Which intuitively suggests a similar amount of overhead (or more) as punting to MPLS tables or to a router. And in the context of production stable services the point was...???

I guess the notion I keep wrestling with is the schizophrenic nature of our mission. We want to do net+ and commodity peering service over the network (i.e. production requirements) yet want to be able to "get out front", which by definition is experimental (i.e. must be crashable to meaningful).

I may take up smoking pot.... 

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:58 AM
To:  Routing WG
Subject: Re: [2013-l3-architecture] FOR DISCUSSION: IP over AL2S

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)