Re: [rrg] Arguments in favour of Core-Edge Elimination vs. Separation?

[Robin Whittle <[e-mail]>]

Short version:      Discussion of placement of ITRs closer to the
                    sending hosts.

                    Why I think DITRs/PTRs will initially handle most
                    packets and why ISPs will increasingly be
                    motivated to install their won ITRs.


Hi patte,

You wrote:

> finally got an understanding of CES, sorry for taking so long. Let see
> if I got it right this time...
> 
> For a conventional host A (PA address) -> CES enabled B host:

Host A could be on a PI address too.

> Actually the closer the ITR functionality (DITR/PTR) is to the xDSL
> routers the better the cache scales, since most likely the residential
> users access the same services and the cache will not grow that much.

Yes.  Generally speaking, the smaller and cheaper you can make an
ITR, the more you can have of them, the closer they can be to the
sending hosts and so the less mapping each ITR will have to cache and
the fewer packets each one will need to tunnel.

Ivip is the only CES architecture to have optional ITR functions in
the sending host (ITFH).  (LISP-MN mobile hosts have this option, but
I think that this is the wrong approach to mobility.  The TTR
Mobility [1] architecture would work OK with LISP and would be far
better.)

If the sending host can have an ITR function added, and if it is:

  1 - On conventional (PA or PI) or SPI space - not behind NAT, and:

  2 - Has fast, reliable, low-cost access to one or ideally two
      full database QSDs.

then it would be good to put the ITR function there.

For Modified Header Forwarding (MHF) [2] to operate, all the routers,
including DFZ routers between this new ITR location and all ETRs
would need to be upgraded.  For the rest of this discussion I will
assume the ITRs use encapsulation rather than MHF.

I will probably add an option for an ITR or ITFH (to be behind NAT.
It would make a two-way tunnel to a caching query server QSC outside
NAT, on a conventional address, and use keepalives to maintain the
tunnel.

Placing the ITR in the sending host typically involves no hardware
costs at all.  One minor disadvantage is that there are map query and
response packets going back and forth, and occasionally a map update
packet to the ITR.  Also, the encapsulated packet is longer, and if
the shortest MTU between it and the ETR is the PPOE link which a DSL
modem uses, then this would result in slightly shorter packets being
able to be sent by the sending host applications.

I don't suggest putting an ITR function on a sending host which
relies on a wireless link, such as a 3G link.  Maybe it would be OK
on a WiFi or WiMAX link which was consistently fast, reliable and
inexpensive.

With these caveats, the best place to put the ITR function is in the
sending host.


> The more CES enabled sites a DITR/PTR has to handle the more stress it
> will put on the ITR cache - so here is a dependency between
> geographically distributed DITRs/PTRs and amount of CES enabled sites.
> The cache scalability is all about to get the DITRs/PTRs in optimal
> places.

When Ivip/LISP is first introduced, I think DITRs/PTRs will handle
most or all of the packets.

When an end-user network is using SPI/EID space (and so is using one
or two ETRs) it will presumably also have an ITR somewhere.  It may
have the ITR in the same box(es) as the ETR(s) but it may rely on
the ISP to have an ITR.   It doesn't really need an ITR, since it
could always let the packets to to DITRs/PTRs.

Over time, as the CES architecture becomes more widely used, I would
think that ISPs would want to introduce their own ITRs, partly to
ensure their customers' packets which are sent to SPI/EID addresses
are handled reliably, locally, rather than depending on potentially
busy DITRs/ITRs.

For any ISP which has ETRs in its network - or has any of its
customers running their own ETRs, such as at their own home or
office, using the the PA address which comes with the DSL etc.
service - then these ISPs have some SPI/EID using customers.

Presumably, some of their customers are going to be sending packets
to these SPI addresses.  The ISP doesn't necessarily need to provide
an ITR, but by doing so, it avoids the expense of those packets going
out to the DFZ to the nearest DITR/PTR and then coming back,
tunneled, to the ETRs in the ISP's network.

Over time, I would expect low cost ITRs made from ordinary servers
and freely available software would be common in ISP and larger
end-user networks.  Also, conventional routers may be upgraded to do
this, and new ones would probably have ITR functions built in.  At
the same time, host operating systems would either have ITR functions
built in and optionally enabled, or be available as separate packages
which could be installed.

Any hosting farm would be keen to get ITR functions in each such host
OS, since it has large volumes of outgoing packets, and a growing
proportion will be to hosts with SPI addresses.

In the long term, I expect DITRs/PTRs to handle a small proportion of
packets - but at the start, I think they would handle most of them.

If the DITR only handled MABs (Mapped Address Blocks - DFZ advertised
prefixes containing SPI space) containing micronets which were mapped
to ETRs in a certain area, such as Australia, then it would suffice
to have the one or more DITRs for these MABs in Australia.  However,
the whole idea of a CES architecture is to enable these SPI (EID for
LISP) addresses to be used anywhere.  So in general, DITRs/PTRs need
to be scattered around the Net, topologically speaking, to generally
minimise the extra path length between any ITR and any ETR, and to
spread the load reasonably evenly between them.


> In a nutshell, CES is all about taking out the multi-homed PI
> addresses from the DFZ - transforming them into PA-addresses (RLOCs,
> which are aggregated) and provide a multi-homing solution for IPv6 so
> it will not further expand the size of DFZ.

This is part of it.  I will write my attempt to summarise the purpose
of CES in a separate message.


> Thanks for your patient and education - my sincere apologizes for
> being slow on learning. But is has been useful for me, sorry for
> wasting yours and Noels time.

I don't think it is a waste of time, since I guess there are a few
lurkers who are also finding it hard to understand these things.

  - Robin


[1] http://www.firstpr.com.au/ip/ivip/#mobile

[2] http://tools.ietf.org/html/draft-whittle-ivip-etr-addr-forw
    http://www.firstpr.com.au/ip/ivip/PLF-for-IPv6/