NTAC Peering Working Group

[Ryan Harden <>]

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
>>> 
>