[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [RRG] Comments on draft-lewis-lisp-interworking



Dino wrote
>It's the same answer I said when I was standing up at RRG. 
>Providers will do whatever they can to attract traffic. They 
>typically don't want to say no. The more traffic they attract 
>the more peering they can get. And the business opportunities 
>start from there.
>

Many times the peering ISPs do not want to share their uplink transport
connection with their peers, only their customer and peer links. The
topology and location of the PTR matters. The PTR provider doesn't want
to pay for traffic this not stemming from their customers but elsewhere.
(This is the very same issue that has hampered the deployment of
Internet wide multicast.)

Regards Hannu 

>-----Original Message-----
>From: owner-rrg@psg.com [mailto:owner-rrg@psg.com] On Behalf 
>Of ext Dino Farinacci
>Sent: Thursday, March 20, 2008 08:23
>To: Jari Arkko
>Cc: Brian E Carpenter; Darrel Lewis (darlewis); rrg; 
>draft-lewis-lisp-interworking@tools.ietf.org
>Subject: Re: [RRG] Comments on draft-lewis-lisp-interworking
>
>> Yes. But in the meeting you promised to come back to the 
>issue of how 
>> this can be made to work business-wise. The problem that I 
>can see is 
>> that if all PTRs announce the whole (or big chunks of it), they have 
>> no capability to say no to any customer. Anyone's packets can be 
>> routed to the nearest PTR, and once the PTR has a packet, it cannot 
>> refuse to tunnel it to the right place. So from a business point of 
>> view this makes it hard or perhaps impossible to contract with 
>> customers for this service. Presumably the motives for 
>deploying PTRs 
>> must then lie elsewhere, such as in improving your regular 
>customer's 
>> service, or some interaction with the business models of plain old 
>> Internet SP business models.
>
>There are only 2 technical solutions, NATs or PTRs. They can 
>solve the problem. If you choose something else that you think 
>makes business sense it could not even come close to solving 
>the problem.
>
>Let's first worry about solving the technical problem. Or else 
>we don't have to worry about any business models.
>
>> Have you thought more about this now, and can you say 
>something about 
>> it on the list?
>
>It's the same answer I said when I was standing up at RRG. 
>Providers will do whatever they can to attract traffic. They 
>typically don't want to say no. The more traffic they attract 
>the more peering they can get. And the business opportunities 
>start from there.
>
>Dino
>
>
>--
>to unsubscribe send a message to rrg-request@psg.com with the 
>word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
>

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg