Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers

[Robin Whittle <[e-mail]>]

Hi Sam,

Thanks for this.  Can you or anyone else point me to the RFCs or
whatever which give guidance on discussing "business models" within
an IETF WG?

Irrespective of what those restrictions are, I think there's no point
in devising a scalable routing solution without a thorough set of
possible business models to match everything which needs to be
adopted, changed deployed etc.

We can't force the solution on anyone.  We need to show, in theory,
at least one and ideally more plausible reasons why existing and new
organisations will want to do all the things which need to be done.

I recognise in an experimental WG such as this, we can't necessarily
come up with a perfectly satisfactory business model for adoption of
every element of the proposed solution, but the earlier we start
thinking about these things the better.

The business aspects of PETRs have a big impact on the design of the
protocols.  For instance:

  1 - Who is paying to access what PETR - or are all PETRs open
      for everyone - in which case, who pays for them?

  2 - How close are PETRs usually to the LISP sites which send
      them packets.  If they are close, then how does an end-user
      network move to a completely different network on the other
      side of the planet, and get access to PETRs there, if the
      PETRs are independent of the networks they are using for
      access?  They would presumably need to deal with a new
      company which runs PETRs in the other location.  Then
      there needs to be authentication so all this can happen
      securely without much administrative fuss.

If there are going to be ITRs behind NAT then how is the PETR going
to distinguish between multiple ITRs behind a single global unicast
address?

How is a PETR going to avoid accepting packets sent by other parties
than the authorised ITRs?  Anyone can send a packet to the PETR with
a tunnel protocol identical to LISP, but with a forged ITR address
matching that of an ITR which the PETR is authorised to handle
packets from.

 - Robin








  - Robin