NTAC Peering Working Group

[Brad Fleming <>]

I've been thinking through the discussion topics from the call today and figured I'd give some thoughts and opinions.

+ IP to AL2S Interconnects

I like the "Backbone Split/Member Access Split" (the last one in the section) approach. It spreads the risk rather than pooling all services into a single risk domain. I don't know what failures we're most likely to see but as a Brocade NetIron shop we've seen the most likely hardware problem be switch fabrics which are linecard agonistic in their failure and cause all kinds of fun messes. The kinds of software failures I expect are difficult to describe and not well informed so they shouldn't drive a design decision.

+ Upcoming Topology and Architecture

I think general consensus was to start with the "Mirror Legacy Network" approach with a mind toward adding L2 paths between IP nodes as needed at a later date. I support that idea. If there's any concern about a specific AL2S path causing problems the NOC can simply move traffic back to the direct, WDM links and see if issues are magically resolved. Provides very clean fallbacks in the event something goes wrong. That ability should help troubleshooting while everyone gets their feet wet with this tiered connectivity approach.

It's probably worth putting thought now into how the need for a new bypass link will be discovered and "justified". Then how the information will be disseminated to groups and with how much notice. Example: crazy amount of traffic going LA<>Chi but is looping through Salt Lake, how quickly will I2 move to put a new LA<>Chi path in place, what groups (tech, C*O, everyone?) will be notified, and with how much notice? Does there need to be input from the NTAC before the new path is "approved"? I don't have any awesome ideas in this regard but these questions need answering before moving to production mainly to set expectation for network participants.

+ Possible Link Restoration Methods

The problem is really two-fold: 1) detecting a failure in the path and 2) rerouting traffic around the failure. To my understanding Loop-Free Alternatives will help speed along part #2 but still requires something discover the failure. Better IS-IS timers will help but a 3-9 second outage before /starting/ the process of selecting new paths, installing them, and forwarding traffic is a really long time in the VoIP world.

For this reason I think (unfortunately) we shouldn't move IP-atop-AL2S until BFD and LFA can be included in the design. I know that makes the rollout timeline longer but any other move would result in a significant step backward for dependability of services which depend on the IP network; enough so it's an unacceptable risk IMHO.

+ General Thought

- It's outside the specific scope of this discussion but we need a simple webpage to query the OpenFlow controller and ask for path details. And it really needs the ability to enter a time/date combo since the controller might change the path between problem occurrence and reporting/troubleshooting.

--
Brad Fleming
Senior Network Engineer
Kansas Research and Education Network
Office: 785-856-9805
Mobile: 785-865-7231
NOC: 785-856-9820

On Jun 7, 2013, at 12:10 PM, Chris Robb <> wrote:

All:

Just a reminder that we have our call at 2PM ET (in just under an hour) at the following bridge coordinates:

866-411-0013

0145454#

I'm re-attaching the document here so folks have it in front of them during the call. 

-Chris

<IP over AL2S 20130522.pdf>

On Jun 4, 2013, at 1:01 PM, Chris Robb <> wrote:

To be clear, that's 2-3PM Eastern. To repeat:

2-3 ET / 1-2 CT / 11-12 PT

866-411-0013

0145454#

On Jun 4, 2013, at 1:00 PM, Chris Robb <> wrote:

Thanks to everyone who filled out the doodle poll. It looks like the best time is going to be this Friday from 2-3PM. Let's use the following bridge:

866-411-0013

0145454#

Talk with everyone then. 

-Chris

On Jun 3, 2013, at 2:58 PM, Chris Robb <> wrote:

All:

To date, David Crowe is the only community member to weigh in with a response to the doodle poll. While I'm incredibly confident in Dave's ability to single-handedly help engineer this, I think we can all agree that a wider participation base would be more ideal. Please try and fill the poll out by noon tomorrow so we can pick a time later in the week. 

-Chris

On May 22, 2013, at 5:54 PM, Chris Robb <> wrote:

All:

One of the action items out of the February architecture discussion was to look at how we logically organize the Layer3 network on top the Layer2 equipment. There was some good back and forth discussion in the later calls about whether or not to implement a full mesh of IP router-to-router VLANs over the IP network, how to prioritize the different interconnect technologies, and how to load share traffic on the L3-L2 interconnects. 

We've pulled together a document that provides a starting point for discussion. We've thought through a few of the scenarios and have attempted to highlight the advantages and gotchas to some of the approaches. This is not a complete view of everything and is meant to spur discussion. 

We purposefully don't make a recommendation here. I'm interested in hearing about options and permutations we need to add to this document and other feedback on the pros and cons. 

I suggest we spend this next week iterating on this via e-mail and try to get together on a call the week of June 3rd to discuss. I've created a doodle pool with some potential times to chat. Hopefully we can find a time that works for a large number of interested parties. 

http://doodle.com/ibbpcu4h952uadwr

Given that we have equipment being installed in the next week to put most of this in place, we'd like to start thinking about beginning to stand pieces of this up in the mid-June timeframe. 

Thanks. Looking forward to the conversation! 

-Chris

<IP over AL2S 20130522.pdf>

-- 
Chris Robb, Internet2 Director of Operations and Engineering
O: 812.855.8604  C: 812.345.3188
****************
Visit our website: www.internet2.edu
Follow us on Twitter: www.twitter.com/internet2
Become a Fan on Facebook: www.internet2.edu/facebook

-- 
Chris Robb, Internet2 Director of Operations and Engineering
O: 812.855.8604  C: 812.345.3188
****************
Visit our website: www.internet2.edu
Follow us on Twitter: www.twitter.com/internet2
Become a Fan on Facebook: www.internet2.edu/facebook

-- 
Chris Robb, Internet2 Director of Operations and Engineering
O: 812.855.8604  C: 812.345.3188
****************
Visit our website: www.internet2.edu
Follow us on Twitter: www.twitter.com/internet2
Become a Fan on Facebook: www.internet2.edu/facebook

-- 
Chris Robb, Internet2 Director of Operations and Engineering
O: 812.855.8604  C: 812.345.3188
****************
Visit our website: www.internet2.edu
Follow us on Twitter: www.twitter.com/internet2
Become a Fan on Facebook: www.internet2.edu/facebook

-- 
Chris Robb, Internet2 Director of Operations and Engineering
O: 812.855.8604  C: 812.345.3188
****************
Visit our website: www.internet2.edu
Follow us on Twitter: www.twitter.com/internet2
Become a Fan on Facebook: www.internet2.edu/facebook