NTAC Peering Working Group

[Jeff Bartig <>]

From reading through this thread, there is a strong desire for
connectors having a choice in how this traffic gets delivered to
them, some wanting it via TR/CPS and others via R&E paths.  This
seems reasonable.

Where I see an issue is that we are partitioning our capacity to
these commercial peers.  TR/CPS had 20G of capacity to Amazon in
Ashburn.  Now R&E has a separate 20G of capacity to Amazon in
Ashburn.  If we needed more capacity to Amazon, would it have made
more sense to get 40G of capacity rather than building a separate
path?

One option would be to have all Net+ peers connect to the existing
TR/CPS routers or simply expand capacity if it is already an existing
peer.  This would probably require provisioning a separate Net+ VRF
on the TR/CPS routers to implement cleanly.  AL3S could peer with
this VRF to get Net+ routes.  These Net+ routes could be allowed
into the main TR/CPS routing table for those connectors that want
to prefer a TR/CPS path.

I haven't thought about this long, so consider it a rough idea to
discuss.  I've been thinking primarily about the technical aspects
of this.  Are there business issues that may restrict our options?
For example, I've heard that Net+ Amazon cloud services may have
more attractive data transfer pricing than Amazon's traditional
pricing due to these new interconnects.

Jeff

On Fri, May 24, 2013 at 05:41:31PM +0000, Ryan Harden wrote:
> Grover,
> 
> Exactly, And since that definition may be different at each connector, and 
> each connector wants to make their own decisions, Maybe (and just maybe) 
> there is an argument to be made that certain Net+ services should be 
> available over both TR-CPS and Internet2 R&E, that way the connector can 
> decide which path they want to take. Of course a knob for telling the Net+ 
> service how to reach us would be necessary as well.
> 
> /Ryan
> 
> Ryan Harden
> Senior Network Engineer
> University of Chicago - AS160
> P: 773-834-5441
> 
> 
> 
> 
> On May 24, 2013, at 12:22 PM, Grover Browning 
> <>
>  wrote:
> 
> > Indeed, this gets to the real issues: what's commodity and what's R&E? If 
> > a genomics guy stores his sequencer data on AWS is that commodity because 
> > it's Amazon or research because he's doing research? And when the bursar 
> > at the same site uses AWS is it commodity or R&E?  
> > 
> > I suspect the answer is different at each site due to the different 
> > policies the membership wants to, or must, follow.
> > 
> > 
> > 
> > 
> > On May 24, 2013, at 12:52 PM, Ryan Harden 
> > <>
> >  wrote:
> > 
> >> I've viewed TR-CPS, perhaps incorrectly, as a commodity path via 
> >> Internet2 and prefer it only slightly above traditional commodity/ISP 
> >> paths and slightly below R&E paths like Internet2 R&E.
> >> 
> >> The question for me is whether we view this new session as a research 
> >> endpoint that also happens to serve commodity, or a commodity endpoint 
> >> that also happens to serve research.
> >> The amount of bandwidth used by the session is irrelevant. If we view it 
> >> commodity, home it to TR-CPS, and subsequently it takes up all available 
> >> bandwidth, we should add capacity to TR-CPS. The same would be true for 
> >> Internet2 R&E if we consider it a research endpoint.
> >> 
> >> I honestly don't have much of an opinion either way. I'm not hearing 
> >> much locally about the desire to use it for research, but that doesn't 
> >> mean it isn't happening or that other's aren't. I just don't want to 
> >> call it commodity but stick it on the R&E side to avoid adding capacity 
> >> to TR-CPS.
> >> 
> >> /Ryan
> >> 
> >> Ryan Harden
> >> Senior Network Engineer
> >> University of Chicago - AS160
> >> P: 773-834-5441
> >> 
> >> 
> >> 
> >> 
> >> On May 24, 2013, at 11:13 AM, "David Crowe, Jr." 
> >> <>
> >>  wrote:
> >> 
> >>> hi michael,
> >>> 
> >>> On 05/24/2013 08:55 AM, Michael H Lambert wrote:
> >>>> On 24 May 2013, at 11:25, Michael H Lambert wrote:
> >>>> 
> >>>>> Speaking pragmatically, I think I'm more concerned about congesting 
> >>>>> the TR-CPS links than removing too much headroom on the R&E links.  I 
> >>>>> won't argue that this view is *right*.
> >>>> 
> >>>> Replying to my own mail (sorry!)...
> >>>> 
> >>>> If there is a strong consensus that this view is flat-out wrong, then 
> >>>> maybe we as a community need to re-evaluate and re-justify the 
> >>>> existence of TR-CPS.  Perhaps we need to look at peering strictly on 
> >>>> the local and regional levels, even though that would mean more 
> >>>> collective effort and the loss of economy of scale.
> >>> 
> >>> in our community i think it has been shown time and time again that the 
> >>> collective choices of the connectors land with *both* (and probably 
> >>> more) views so they need to be accommodated.
> >>> 
> >>> that point notwithstanding, one big issue that will come to the fore if 
> >>> Net+ services are added to the TR-CPS side is the lack of overhead 
> >>> capacity available there.  the capacity made available to TR-CPS, both 
> >>> for customer attachment and intra-TR-CPS connections, is more frugally 
> >>> managed than on the R&E side; there is an explicit intent to control 
> >>> costs but it is also due to very slow allocation of resources.
> >>> 
> >>> since the available overhead capacity is much less generous than we've 
> >>> required on the R&E side adding more demand on the TR-CPS side will 
> >>> require adding more capacity to match or exceed current planning.
> >>> 
> >>> David
> >>> 
> > 

-- 
Jeff Bartig                  |  University of Wisconsin - Madison

          |  Division of Information Technology
(608) 262-8336               |  Network Services/WAN Engineering/AS59
GTalk/AIM/Yahoo: jbartig     |  WiscNet Backbone Engineering/AS2381