[RRG] OITRDs & PTRs: "partial deployment" support of packets from non-ITR networks

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

Hi David,

Responding to Yakov in the "Long term clean-slate only for the RRG?"
thread, you wrote, in part:

>> (c) could one benefit with only a partial deployment,
> 
> I suppose it depends on what you mean by partial deployment.  One can
> imagine scenarios where you have incremental deployment amongst
> cooperating ISPs, but one of the hardest problems to solve is how you
> have asymmetrical deployment (that is, where an end/user site has
> migrated to the new system and wants to communicate with an end/user
> site that hasn't yet migrated).  

In principle, this problem was solved a year ago.

"Partial deployment" is going to be the case pretty much forever.
We may never reach the stage where every single network has its own
ITRs.

In order for a map-encap system to be attractive enough to be widely
deployed, it needs to be highly attractive to the very first
adopter, and the second etc. - without depending at all on how many
networks have ITRs.

I used to think this independence of benefits from the level of
adoption was called "incrementally deployable", but I found that
this term is generally recognised to mean something much less
stringent.  I tried to define my thoughts about a proposal needing
to provide solid benefits, no matter how few networks have so far
adopted it:

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


LISP with Proxy Tunnel Routers (PTRs) and Ivip with its OITRDs (Open
ITRs in the DFZ) both solve the problem.

APT can do it too, although if there are multiple APT islands, there
are some tricky restrictions about end-user networks having to stick
to the one Island for their ETRs if their space is within the one
BGP-advertised prefix: http://psg.com/lists/rrg/2008/msg00734.html

I should add this question how to handle packets sent by hosts in
networks without ITRs to the list of distinctions between the
map-encap schemes at:

  http://www.firstpr.com.au/ip/ivip/comp/


PTRs (according to my potentially faulty understanding of LISP) and
OITRDs both do the same job - they are both ITRs in the DFZ.  There
are typically many of them, all over the Net, and each advertises
one or more prefixes in the DFZ.  Within that prefix, all the
addresses are EID addresses (LISP) or micronet addresses (Ivip).
The PTR or OITRD is an ITR and encapsulates those packets, tunneling
them to the correct ETR.

There are several things which need to be achieved before this can
be done scalably.

Firstly, these PTRs or OITRDs need to scattered around the Net,
close enough to the non-upgraded networks that the total path from
the non-upgraded network, to the PTR/OITRD, and then to the ETR of
the destination host is not excessively long.

Secondly, these PTRs and OITRDs need to be able to cope with
whatever traffic levels they encounter - otherwise packets will be lost.

Thirdly, PTRs and OITRDs will not be a scalable approach to "partial
deployment" unless each prefix they advertise serves the needs of
many end-user networks.  If each end-user network had, for instance,
one EID (micronet) prefix, and each of these required a single
BGP-advertised prefix (Mapped Address Block - MAB - in Ivip) so PTRs
(OITRDs) would get the packets, then there would be no scalability
advantage (no reduction in the total number of BGP advertised
prefixes) compared to the end-user networks not using map-encap, but
using ordinary BGP-managed PI prefixes as they do today.

Ivip includes as part of its design the intention that MABs
generally be quite large, and contain the micronets of many
(potentially tens or hundreds of thousands) of end-user networks.
So by each MAB burdening the BGP system with a single advertised
prefix, each MAB can provide the space for tens to hundreds of
thousands of micronets to serve the needs of similarly large numbers
of end-user networks.

There also needs to be a business case for building and running
these PTRs or OITRDs.  This depends a lot on how the address space
is managed, the commercial arrangements of obtaining an EID prefix
or micronet etc.  This in turn depends on many factors I won't list
fully here, but which include the extent that end-user networks
obtain their EID (micronet) space from someone else, or whether they
convert their current PI space into LISP (Ivip) managed space.

Also, consider four end-user networks with separate PI space in a
contiguous block of address space, which could all be advertised as
a single prefix in BGP.  With LISP and Ivip (and I guess APT), the
four currently advertised prefixes could be replaced by a single
BGP-advertised prefix for the purpose of getting the packets to the
nearest PTR (OITRD).  This reduction in the number of BGP-advertised
prefixes makes it scalable - but involves the four networks having a
joint arrangement for running the PTRs or OITRDs.  (This could
easily be sub-contracted out, and in Ivip, would naturally be done
as part of a paid-for service by the organisation which manages the
mapping for the micronets in this MAB.)

In principle, every PTR or OITRD could advertise every MAB, so there
would effectively be one unified system of PTRs or OITRDs for the
whole Net.  However, this is not necessary - there could be multiple
such systems, each system handling one or more advertised prefixes.
 I wrote about the business case for Ivip's OITRDs in April:

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

Around that time there was some discussion (I wasn't involved) about
the business case for deploying LISP PTRs.  I recall that no such
business case had yet been developed.

  - Robin


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