NTAC Peering Working Group

[Linda Roos <>]

Dear NTAC Peering and Routing Working Group,

Thanks for your thoughtful comments on the document.  We have updated the
document based on your suggestions and it is attached here.  We do
understand that some issues are relevant for consideration by both Network
Services and NET+.  On the recommendation of the NTAC Futures group, a
community group to focus on the issues at the intersection of Network
Services and NET+ is being convened shortly.  We will ensure that these
issues are discussed with them.  And, if you have additional comments,
please send them to the list.  Thanks.
Linda


-- 
Linda Roos
Director, State and Regional Networks
Internet2

desk: 812-558-0615
mobile: 614-209-8125







On 11/6/13 3:13 PM, "Ryan Harden" 
<>
 wrote:

>>> Regardless of how Net+ providers are connected, I suggest it¹s not
>>>correct, and potentially harmful, to depict TR-CPS as commodity
>>>connectivity, unless that¹s really how the service is managed now.
>
>
>Throwing my +1 in here.
>
>I don't pretend to understand fully what may or may not happen, but I'd
>hate to see a situation where we lose TR-CPS due to the carriers' recent
>sensitivity to an R&E network competing with their business model.
>
>/Ryan
>
>Ryan Harden
>Senior Network Engineer
>University of Chicago - AS160
>P: 773-834-5441
>
>
>
>
>On Nov 6, 2013, at 1:16 PM, David Pokorney 
><>
> wrote:
>
>> I agree Steven, why not make TR/CPS as an equal Net+ ³carrier² in
>>addition to the R&E network?  I hope the TR/CPS review team are looking
>>at how we can make all camps happy here.   thanks, -dave
>> 
>> On Nov 6, 2013, at 2:12 PM, Steven Wallace 
>> <>
>>  wrote:
>> 
>>> From the very beginning of the Commercial Peering Service (now
>>>TR-CPS), it was envisioned as providing better-than-commodty
>>>connectivity to commercial cloud providers. The current TR-CPS service
>>>description on the I2 web site says: ³...offers a low cost path with
>>>higher performance goals than commercial alternativesŠ². That¹s a large
>>>part of the initial motivation for CPS. In the beginning there was no
>>>difference in the underlying infrastructure between R&E and CPS,
>>>however that¹s changed substantially over the years.
>>> 
>>> Regardless of how Net+ providers are connected, I suggest it¹s not
>>>correct, and potentially harmful, to depict TR-CPS as commodity
>>>connectivity, unless that¹s really how the service is managed now.
>>> 
>>> ssw
>>> 
>>>> 
>>>> On Nov 5, 2013, at 2:37 PM, David Farmer 
>>>> <>
>>>>  wrote:
>>>> 
>>>>> On 11/5/13 12:49 , Michael H Lambert wrote:
>>>>>> On 18 Sep 2013, at 12:42, Linda Roos 
>>>>>> <>
>>>>>>  wrote:
>>>>>> 
>>>>>>> Dear NTAC Routing and Peering Committee,
>>>>>>> Attached, please find, a document on NET+ traffic on R&E routes.
>>>>>>>This document has been reviewed by the Network Architecture,
>>>>>>>Operations and Policy Program Advisory Group (NAOPpag).  Should you
>>>>>>>have any questions or comments on the document, please let me know.
>>>>>>> Thanks.
>>>>>> 
>>>>>> It's been a while and I've seen no comments, so I will do so now.
>>>>>>I have a couple of problems with this sentence:
>>>>>> 
>>>>>> "While these service providers may transport some ³non-research²
>>>>>>traffic to members over the network, reaching the providers over
>>>>>>commodity paths or TR-CPS paths which are provisioned like commodity
>>>>>>paths will not achieve what the community wants with NET+."
>>>>> 
>>>>> I would revise that to ..."not achieve what *some of* the community
>>>>>wants with *for some* NET+ *providers*."
>>>>> 
>>>>>> 1) Where are the data that support this claim about community
>>>>>>expectations for network performance for Net+?
>>>>> 
>>>>> I will give you an anecdote, or an existence proof;  We (NLG) want
>>>>>NET+ available through R&E, we don't provide TR-CPS to all our
>>>>>participants and think it is important to provide access to NET+
>>>>>through R&E.
>>>>> 
>>>>> But, I respect your right to think differently and not do so, as
>>>>>long as you respect our right to do so, hence my revisions above.
>>>>> 
>>>>>> 2) I view TR-CPS as being closer in performance to the R&E network
>>>>>>than to the commodity Internet.  If there is a prevailing view that
>>>>>>TR-CPS has become too "commodity-like", then perhaps what is needed
>>>>>>is a strategic review of the peer selection process, followed by a
>>>>>>review of individual peers in that context.
>>>>> 
>>>>> As I said, we don't even provide TR-CPS to all of our participants,
>>>>>but even if we did, I don't agree.  We are limited in the amount of
>>>>>TR-CPS traffic we can pull across our links from I2, this may or may
>>>>>not be an issue for everyone, but it is a difference.
>>>> 
>>>> I respect that there are limits.  If it make sense for to prefer
>>>>(some) Net+ services (for some connectors) via TR/CPS over R&E then we
>>>>should make that known to Internet2.  Perhaps we can get a report from
>>>>the TR/CPS study group at 4PM today?
>>>> 
>>>> -dave
>>>> 
>>>>> 
>>>>> Also, I disagree that we should ever limit who we peer with for
>>>>>TR-CPS, it serves a completely different purpose than R&E or even
>>>>>NET+.  Besides getting us good access to content we need for our
>>>>>network users, it serves the outreach mission of our institutions,
>>>>>ensuring the best experience for our content to the broadest possible
>>>>>set of users.
>>>>> 
>>>>> Limiting who we peer would result in curtailing the usefulness of
>>>>>one of these two important uses of TR-CPS.
>>>>> 
>>>>>> Michael
>>>>>> 
>>>>>> -----
>>>>>> Michael H Lambert, GigaPoP Coordinator         Phone: +1 412
>>>>>>268-4960
>>>>>> Pittsburgh Supercomputing Center/3ROX          FAX:   +1 412
>>>>>>268-5832
>>>>>> 300 S Craig St, Pittsburgh, PA  15213 USA      
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> -- 
>>>>> ================================================
>>>>> David Farmer               Email: 
>>>>> 
>>>>> Office of Information Technology
>>>>> University of Minnesota
>>>>> 2218 University Ave SE     Phone: 1-612-626-0815
>>>>> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
>>>>> ================================================
>>> 
>> 
>

Attachment: Memo on logic for NET+ over R&E routes 110613.docx
Description: Memo on logic for NET+ over R&E routes 110613.docx