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

[Robin Whittle <[e-mail]>]

Short version:   Trying to clarify that putting an ITR function
                 in a DSL router does not mean the DSL customer
                 is using SPI space.  DSL etc. customers will
                 keep using PA space, except for a few who
                 want to multihome.

                 Any existing DSL etc. customer which wants to
                 multihome will still use their existing PA
                 address, and get another one from another
                 link such as WiMAX, HFC or fibre.  But then
                 their hosts will be using SPI addresses.

                 Very few home or SOHO customers will want or
                 need portability or multihoming, since their
                 existing service is quite reliable enough.


Hi patte,

You wrote:

>> Not necessarily.  The ITR function could be in the sending host
>> (Ivip, not LISP, except LISP-MN), or in any other router.  The packet
>> from host-B to host-A doesn't necessarily go back through, or even
>> near, the device which performed the ETR function on the first packet.
>>
>> If host-A is on a conventional address (ordinary PI or PA) then
>> there's no need for an ITR anyway.  If it is on SPI address (Ivip -
>> or for LISP "EID" space) then at some stage the host-B to host-A
>> packet will be encapsulated by an ITR.  In Ivip, if there is no ITR
>> function in host-B, then the packet may be processed by an ITR
>> function in the  host-B's network (perhaps the same device which did
>> the ETR function for the first packet) or a router in the ISP network
>> (likewise - maybe the ETR was in the ISP network, rather than
>> host-B's network).  If there is no ITR in that path, then the packet
>> will go out of the ISP and be forwarded to the nearest DITR (Default
>> ITR in the DFZ - which in LISP is called a Proxy Tunnel Router).
>> That encapsulates the packet and tunnels it to the correct ETR.
> 
> Ok, got it. An ETR has never a cache but for the returning traffic you
> might need an ITR (could be most likely the ETR for the initiating
> session). So, yes, there is no cache for an ETR -  the cache is always
> on the ITR.

Yes - the ITR and ETR functions are separate.  The ITR
caches mapping  and the ETR doesn't.  Ivip ETRs don't have
anything to do with mapping.

(LISP ETRs are typically the authoritative source of
mapping for the one or more end-user networks whose
packets they handle - so if there are two such ETRs in
different ISPs, both are typically authoritative for the
mapping of this end-user network's EID prefixes, as far
as I know.)


>>> Think
>>> there needs to be a cache table so that this ITR can assemble the
>>> outer, UDP and LISP headers - the host can not know those headers
>>> unless it is upgraded and if the host is upgraded it is no longer a
>>> full blown CES solution.
>>
>> ITR functions are much the same in principle no matter where it is
>> done.  The ITR caches mapping information, and if it doesn't have
>> mapping for a micronet covering the destination address, say of
>> host-A for the second packet in this example, then it sends a mapping
>> request to get this.
>>
>> In Ivip, the ITR buffers the packet for a few tens of milliseconds at
>> most, since the mapping comes quickly and reliably from a local full
>> database query server, such as in the same ISP or end-user network.
>>
>> With LISP-ALT, the ITR drops the packet and sends a request into the
>> global ALT overlay network, directly or via a local Map Resolver.
>> The reply comes back - via the Internet.  Since this is a global
>> network and the path in the ALT system could be longer than an RTT
>> across the the Earth and back, the ITR does not buffer the packet.
>> Instead, once it has received the mapping (which might take a short
>> time, but will often be 400ms to maybe a second or so - assuming no
>> packets are lost) then whenever the host sends another packet to the
>> same destination, the ITR encapsulates that one - and it is tunneled
>> to the ETR.
>>
>> An ITR function may be in the same box (a router or a server) as an
>> ETR function, but the two functions don't communicate in Ivip - or as
>> far as I know, in LISP.
> 
> Yes, agreed and that what is what I was referring to - an ITR in front
> of a popular server (that might be an ETR for the initiating traffic
> from a client). But I stop using that term, instead "ITR in front of a
> server" is the term.
> 
> Then to the issue. If you take the CES functionality to the xDSL
> routers you will get a lot more entries on the ITR in front of a
> server at a popular site. 

No - the DSL services will still be on conventional PA
space, as they today.  The ITRs in a popular site
(whether they are separate devices, or ITR functions
in the sending hosts) don't need to look up mapping or
tunnel packets for all this plethora of packets going
out to large numbers of these DSL PA IP addresses.

The addition of an ITR function in the DSL router
doesn't change this.  Just because a sending host has
an ITR function, or some router in a network X has
ITRs, doesn't mean that this host or any host in
network X is on SPI space (EID for LISP).

In my previous message I contemplated a special
router for a SOHO situation whereby it implemented
two ETRs, one for the DSL link and one for the HFC
cable link.  Then, the hosts on that SOHO network
would be on SPI addresses, since this is now a
multihomed end-user network.

ITRs in busy server sites will be tunneling packets
to such hosts - to whatever hosts are on SPI addresses.

Ordinary home and SOHO users are probably fine with
their current PI space.  So I am not suggesting that
they adopt SPI space either for portability or for
multihoming and/or inbound TE.

However, there will be hosts in many end-user networks
which do have SPI space, such as those of larger
businesses and other organisations which need
portability and/or multihoming.  So a significant
proportion of packets transacted across the DFZ will
be for SPI addresses - they will be tunneled across
the DFZ.

TTR mobility involves each mobile host having at least
one IPv4 address, which would be a single micronet -
or an IPv6 /64.   This is SPI space.  I am sure that in
the future, most Internet hosts will be hand-held mobile
devices (probably most on IPv6) and I believe the TTR
Mobility architecture is the only one which can provide
global mobility of these addresses, no matter where the
MN is connected, including behind NAT.

So this will be a lot of hosts on SPI addresses and in
general, in the long-term future, any busy web-site or
hosting company etc. is likely to be sending out a lot
of its packets addressed to SPI addresses and therefore
which will be tunneled to ETR addresses.

For most DSL, fibre, WiMAX etc. mass-market non-
physically-mobile customers, I believe the existing PI
space arrangements will remain just fine.

> The reason is that the xDSL prefixes are
> quite well aggregated in today's DFZ. But once you apply the CES
> solution on the xDSL router it will carve up the aggregated (PA)
> prefixes on the ITR in front of popular servers.

This is not the case.  I hope my explanation above
makes this clear.

> E.g. if an ISP uses today a /20 aggregate for their xDSL connections
> and the residential users are allocated /29 prefixes for their
> networks. If the residential users would deploy a CES solution in
> their xDSL routers you will have lot more entries in the ITR in front
> of popular servers - in the current architecture you have only /20
> entry in the FIB but in the CES architecture you can't predict how
> many entries you will have in the FIB - it depends if, when and how
> many xDSL users are accessing your server. And if your site is very
> popular do you need more FIB entries than today's router do have, just
> in case the CES solution gets very popular and deployed very close to
> the edge?
> 
> This is my concern and the reason why I think a CES solution also
> should include a CEE approach.
> 
> Or do I still miss something?

Yes.  Most DSL etc. customers will remain just as they
are today.  Putting an ITR in their DSL router is just
to save on the cost of the alternative - putting an ITR
in the ISP network (or not having such an ITR, and letting
the packets go out to a DITR in the DFZ).

Having an ITR function is to handle packets these DSL hosts
send to other hosts which are on SPI addresses.  It does not
necessarily mean that the DSL service or the hosts behind
its router are using SPI addresses.

  - Robin