A partial answer that has been suggested is that the oeprator who deploys the PITR is an EID allocator rather than a conventional / existing ISP. Unfortunately, if LISp succeeds it is not clear that the compensation levels can match the increasing demand for traffic in the critical periods.

Yours,
Joel

On 12/4/13 11:51 AM, Ronald Bonica wrote:
Dino,

I am not understanding your response. Let me ask the question another way.

Assume that an operator deploys a PITR. What policy can that operator enforce 
to ensure that it is compensated for all (or even most) of the traffic that it 
carries across that PITR?

                                                                         Ron


-----Original Message-----
From: Dino Farinacci [mailto:[email protected]]
Sent: Wednesday, December 04, 2013 11:44 AM
To: Ronald Bonica
Cc: Luigi Iannone; Geoff Huston; Sander Steffann; LISP mailing list
list
Subject: Re: [lisp] WGLC draft-ietf-lisp-eid-block-07

Luigi,

Is this really what is going to happen?

If a PITR announces the entire /32 into the global Internet, it puts
itself on the forwarding path for the entire /32, and incurs the cost
associated with transporting traffic towards every site in that /32.
This is supportable only if the PITR operator is somehow compensated
for carrying all of that traffic.

But maybe only from a few sources. But if the /32 needs to be divided
based on region, then maybe /40s could be advertised. But to the point
about "few sources", the more PITRs there are, the better the load is
shared.

And I envision PITRs will be deployed on on-path boxes anyways. Those
boxes right now can route to the entire Internet, they are called PE
boxes, are they not Ron?

Isn't it more likely that the PITR operator will advertise only
slices of the /32, with each of those slices being assigned to either
its customers (from whom it collects revenue) or the customers of other
operators with whom it has made financial arrangements?

No it won't be that way. EIDs are provider independent. If you do what
we suggest, we make no forward progress.

Dino


                                                      Ron


_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp




_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to