[RRG] Business incentives for LISP PTRs and Ivip OITRDs

[Robin Whittle <rw@firstpr.com.au>]

Hi Jari,

On 2008-07-24, in the thread "Six/One Router Design Clarifications",
you wrote, in part, referring to :

> The group has not been able to convince itself that the former has
> deployment incentives . . .

in reference to map-encap mechanisms for correctly tunneling packets
sent by hosts in networks without ITRs.

For LISP, the mechanism is "Proxy Tunnel Routers".  In Ivip the same
job is done by OITRDs (Open ITRs in the DFZ).

I wrote about deployment incentives for OITRDs:

  Ivip business models: fast push & OITRDs
  http://psg.com/lists/rrg/2008/msg01158.html  2008-04-15

There wasn't any reply.  So while I may not have convinced the
active RRG members, the arguments are there and remain to be discussed.

There are RUAS (Root Update Authorisation System) organisations, or
other organisations - whoever holds the MAB (Mapped Address Block)
space which they hire out as a much larger number of micronet spaced
(EID prefixes in LISP terminology) to end-user networks.   These
organisations have an incentive to pay for OITRDs.  The gain income
from renting out their address space, so some of this can be used to
pay for OITRDs which handle their MABs.  The better the OITRD
service, the more usable the micronet address space.


There was a discussion about business cases for LISP PTRs.  The
conclusion seems to have been that there was no obvious business
case.  Below is a summary of the PTR and LISP-NAT aspects of that
discussion you started:

  Comments on draft-lewis-lisp-interworking
  http://psg.com/lists/rrg/2008/msg00585.html  2008-03-05

   - Robin



   http://psg.com/lists/rrg/2008/msg00666.html

     Dino:

      > If a LISP sites wants non-LISP sites to connect to it,
      > which they will, they will figure out how to deploy a PTR.
      > So you, the non-LISP site doesn't have to care.

      > Is your point that there is no motivation for anyone to
      > deploy a PTR?
      >
      > . . .
      >
      > Not just one PTR. A bunch of them will advertise it for
      > compatibility sake. But if I had to choose I would error on
      > using NAT as the solution because I don't want any
      > additional infrastructure if I can avoid it.
      >
      > We put PTRs in there to allow a solution that doesn't use
      > NAT.


   http://psg.com/lists/rrg/2008/msg00667.html

     Darrel Lewis on PTRs and an alternative "NAT", which
     I think does not work:
     http://www.firstpr.com.au/ip/ivip/lisp-links/#NAT_probs

     > You can consider PTRs optional, but NAT is a core
     > requirement for any sensible interworking between LISP and
     > non LISP-NR sites.

     > ... PTRs are more attractive to me the more you can
     > aggregate EID space.



   http://psg.com/lists/rrg/2008/msg00882.html  2008-03-20

     You - Jari - questioning the business case for PTRs, which
     attract traffic from everywhere, and must handle it.


   http://psg.com/lists/rrg/2008/msg00883.html

     Dino:

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


   http://psg.com/lists/rrg/2008/msg00884.html

     Pekka Savola found it difficult to see why providers would want
     to deploy any PTRs which advertised widely enough to provide
     full coverage - or why end-sites would want to deploy PTRs.


   http://psg.com/lists/rrg/2008/msg00885.html

     Hannu Flinck:

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


   http://psg.com/lists/rrg/2008/msg00887.html

     Jari asks what others think of Dino's arguments about PTR
     deployment incentives.


   http://psg.com/lists/rrg/2008/msg00896.html

     Joel Halpern wrote, in part:

     > There may be a way to deploy PTRs that gets them paid for,
     > but I don't know what it is.
     >
     > Ignoring economic issues is a recipe for failure. If no one
     > can afford to deploy the solution if it catches on, then they
     > will avoid doing so. (Yes, anyone can afford PTRs in the
     > early stage. That's not the question.)
     >
     > And no, operators don't want to attract traffic. They may
     > want peering relationships (not all want them.) As Peter
     > sarcastically but accurately put it at the mike, they want to
     > be paid for traffic, but they don't actually want the
     > traffic.


  http://psg.com/lists/rrg/2008/msg00906.html

     Joel wrote, in part:

     > But when it comes to deployment analysis, ignoring the
     > question of who pays, and why, is just not going to work.
     > We don't need (don't want, and can't) to mandate a business
     > model. I would hope that a sensible recommendation allows for
     > multiple business models. But if we can not even imagine one
     > that works, then it fails.
     >
     > And with regard to wanting more traffic, operators only want
     > more traffic if they are going to get paid for it. That does
     > suggest a path for deployment of PTRs.


   http://psg.com/lists/rrg/2008/msg00909.html

     David Meyer agues against this, but I think not very
     convincingly.


   http://psg.com/lists/rrg/2008/msg00910.html

     Dino wrote, in part, repsonding to Jari:

     >> Ok, this is interesting. Not quite as concrete and clear-cut
     >> as I had hoped, but a start. What do others think of this?
     >> Is there a way for us to evaluate whether this is a
     >> sufficient incentive?
     >
     > The net is dirty and we don't have much options. It's PTRs or
     > NAT, pick one.


   http://psg.com/lists/rrg/2008/msg00916.html

     Tony Li can't see broad appeal for PTRs in terms of them
     attracting traffic.


   http://psg.com/lists/rrg/2008/msg00918.html

     Dino, responding to Tony:

     >> In effect, this gives a way for the provider to attract new
     >> traffic, both inbound and outbound, and not receive revenue
     >> for it. While I can see that it might be of interest to
     >> some, I don't see the broad appeal.
     >
     > I bet an exchange carrier would love to attract traffic.
     >
     > And why does every service provider want Google, Yahoo, MSN,
     > Facebook, EBAY, and MySpace to be their customer?
     >
     > There is appeal and I wish operators on this list would speak
     > up.


   http://psg.com/lists/rrg/2008/msg00920.html

     Tony is unconvinced by the above.  (Dino replies in
     http://psg.com/lists/rrg/2008/msg00924.html and Tony
     in http://psg.com/lists/rrg/2008/msg00929.html is
     unconvinced.)


   http://psg.com/lists/rrg/2008/msg00921.html
   http://psg.com/lists/rrg/2008/msg00922.html

     Darrel provides some detailed arguments for incentives, but
     I don't understand them in a way which convinces me.


   http://psg.com/lists/rrg/2008/msg00959.html

     Dino writes, in part, responding to Tony:

     > We can't be all things to all people. But there is a benefit
     > to transition to LISP so the providers can reduce their
     > routing tables at the same time as maintaining non-LISP site
     > to LISP site connectivity.


  http://psg.com/lists/rrg/2008/msg00960.html

    Tony to Dino:

    > So you admit then that your argument about the benefits of
    > hosting a PTR don't hold water?


  http://psg.com/lists/rrg/2008/msg00963.html

    Dino responds:

    > 1) We need solutions to a technical problem. We understand the
    >    problem and solution space.
    >
    > 2) We don't know the business benefits yet of deploying PTRs.
    >
    > 3) There are business benefits for deploying LISP.
    >
    > 4) You need to have interworking between upgraded sites and
    >    non- upgraded sites.
    >
    > We can't be sure of anything at this point. Therefore, we
    > can't be sure it won't hold water.


  http://psg.com/lists/rrg/2008/msg00965.html

    Tony:

    > And you can't be sure that it will...


  http://psg.com/lists/rrg/2008/msg00974.html

    Darrel:

    >> So you admit then that your argument about the benefits of
    >> hosting a PTR don't hold water?
    >
    > Sorry, I don't admit this at all.


  http://psg.com/lists/rrg/2008/msg00976.html

    Tony to Darrel:

    > Ok cool, so assuming you've been following the conversation,
    > is there a flaw in my argument?


  http://psg.com/lists/rrg/2008/msg00977.html

    Stephen Sprunk proposes two potential scenarios:

    > The RIRs pay the Tier 1s to all run PTRs, using fees charged
    > to people who get EID space from them*.  More people using
    > LISP, more traffic, more fees, more PTRs...
    >
    >    * I assume the RIRs would distribute EIDs. That also means
    >      there would likely be five different EID prefixes and
    >      five databases, but that's not a meaningful change to the
    >      technical model.)
    >
    > And another one:
    >
    > The Tier 1s decide that the cost of deploying PTRs is less
    > than the cost of upgrading routers to handle the routing table
    > growth that will happen if LISP doesn't get deployed widely.

    The first model has some resemblance to the Ivip model.


  http://psg.com/lists/rrg/2008/msg00979.html

    Bill Herrin doesn't like these two ideas, but sees some sense in
    a third idea of Stephen's:

    > As crazy as it sounds, this is probably the most realistic
    > scenario I've heard for deploying a LISP PTR: a small edge
    > organization deploys it to adjust some completely unrelated
    > traffic factor. Perhaps they even use it to justify peering in
    > the first place: we know we'd normally come in shy of your
    > qualifications Mr. Tier1 but if you add us as a peer at your
    > convenient data center, we'll take care of this whole LISP PTR
    > thing for you.
    >
    > Its a hell of a thing to hang a critical-path item on.

The rest of the thread doesn't add anything substantial concerning
incentives to deploy PTRs.

It is hard to debate in the absence of clear guidance from the LISP
team about how they expect EID space to be created, and by whom.  I
think they assume we all know what will happen, but I don't think we do.

At least with Ivip, I do write about how I intend the space to be
converted to Ivip management, such as in the four numbered points in:

  http://psg.com/lists/rrg/2008/msg01158.html


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