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

[Robin Whittle <[e-mail]>]

Short version:   Clarifying how an ITR function in a box has nothing
                 to do with an ETR function in the same box - and how
                 ETRs don't cache anything.

                 Also, a new PPT file from patte about hIPv4 is at:

                 http://www.firstpr.com.au/ip/files/PF/


Hi patte,

You wrote:

>> In point 2 I should have written PA space.  There are two classes of
>> existing end-user network which might want portability, multihoming
>> and TE:
>>
>>  1 - Those who have it already with PI space.
>>
>>  2 - Those who don't have it since they have PA space.
>>
>> So my original 1 and 2 are not a choice an end-user network makes -
>> it is two types of transition for two classes of existing end-user
>> network.
> 
> Ok,
> 
> PI-addresses is the way to go, an enterprise should have PI-addresses
> - regardless if multi-homed or not. Drop PA addresses, they are suited
> only for residential users, IMHO.

I was not writing about a choice an end-user network could make -
just that before the scalable routing system is introduced, existing
networks fall into one of these two classes.

No matter whether an end-user network started with PI or PA space,
with Ivip it will use SPI (Scalable PI) space.  In case 1, it may let
its current PI space go, and adopt SPI space it rents from a MAB
(Mapped Address Block) company, or it may convert its own PI space
into a MAB and use it all for itself.  In case 2, it abandons its PI
space and rents SPI space from a MAB company.

In my previous message I wrote how in both cases, with a CEE
architecture, the new address space is of a different kind (different
namespace) then the IP addresses used for both PI and PA space - so
in both cases, the network's upgraded hosts have their applications
referring to that host, and addressing other hosts, by using the new
kind of Identifier addresses, no matter what IP addresses the hosts
may be using at the time.


>>> I prefer approach 2, think this is the best way to go since that what
>>> has been done in the cell-phone network - the subscriber owns the
>>> number and can choose which ever service provider he/she prefers. So
>>> we should keep this model in the Internet as well.
>>
>> That is my point 1 - the end-user network already has "their own" PI
>> space.  But in CEE, the new kind of scalable space is not IP
>> addresses of the original kind.  So they can't keep their space and
>> make it portable, multihomable.  All CEE schemes involve two separate
>> namespaces - one for Locator (physical) and one for Identifier (logical).
>>
>> As far as I know, for any CEE (I think including your hIPv4 proposal,
>> which I am yet to read in detail) no network at present has any space
>> of the new Identifier type which a CEE will provide.  So neither of
>> my two points involve the end-user network retaining their existing
>> address space as their new, portable, multihomable, Identifier space.
> 
> Think we have a misunderstanding here with syntax, perhaps you are
> referring to LISP's locator and identifier definition when I'm using
> RRG's syntax. For me an IP-address is a locator - is it an edge or
> core IP-address it is always a locator. In hIPv4 the identifier is
> found in the transport layer, a 32-bit value provided by SCTP or
> MPTCP.

I am yet to read hIPv4 so I can't be sure about this. I am attempting
to explain my understanding of CEE architecture, and I previously
decided that hIPv4 is a CEE architecture.

> HIP can provide a host identifier functionality and I see HIP's role
> more or less related to Cloud Computing - it could provide a mechanism
> to do the ultimate decoupling - instead of building network based VPNs
> why not build that with HIP? You could identify your workstations and
> server resources with HIP and if the computing resources
> (applications, storage, databases etc) is connected to HIP identifier
> perhaps you could move your computing resources from one data center
> provider to another without doing anything at the network layer - if
> the transport or application layer is encrypted, if needed.

I find cloud computing, such as at the Rackspace Cloud, quite
astounding.  More on this below my signature.


>> There's no such thing as "cache" in ETRs.  The ITR function is just
>> the same as before without multihoming and ETR functions.  The box
>> would also be making outgoing TE decisions about its outgoing
>> packets, since it has two uplinks.
>>
>> With encapsulation tunneling, the ITR function would have two
>> outgoing addresses - XX and YY.  It could decide which link to send
>> out encapsulated packets on as it chooses.  It doesn't matter to the
>> ETR at the destination network which ITR the packet comes through.
>> The host at the destination network doesn't know or care either.
>>
>> Perhaps your understanding of what CES involves is different from mine.
> 
> It might be the case, I'm no expert on the CES solutions and have
> studied a little bit LISP. But I'll try to explain my concern on the
> ETR cache issue. Having a look on the LISP header I think the ETR
> needs to remove the UDP and LISP header, also replace the Source and
> Destination Routing Locator values with the inner header's Source and
> Destination EID values so that the host receives a "normal" IPv4 (or
> IPv6)  header, right?

There's no replacement of anything.  Just strip off the outer IP
header, the UDP header and then the LISP header and what remains is
the exact packet which arrived at the ITR.  Then the ETR knows how to
forward this naked traffic packet to the destination network, which
is presumably topologically close-by.  I think the TTL is
decremented, with an appropriate alteration of the IPv4 header
checksum, but that happens on all routers anyway.

This is for a packet going from host-A to host-B


> If the ETR doesn't need to remove the non-IPv4 headers then host needs
> to understand LISP and then you have made changes to the host stack.

The destination host host-B has no alterations, and can't see any of
the tunneling operation.  It receives a packet identical to that
which the ITR received, apart from the TTL being decremented by the
ETR and any routers between the ETR and the destination host.  Apart
from the TTL value, this identical to the packet sent by host-A.


> For the returning traffic the host will use normal  IPv4 (or IPv6)
> headers and send it back to the ETR, which becomes an ITR now. 

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.


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


> That's why I think there is a cache in the ETRs for returning traffic,
> but the returning traffic doesn't need be looked up by a mapping
> solution, it is populated by the initiating traffic from e.g.
> broadband sites (if the broadband routers uses a CES solution).
> 
> But perhaps I miss something here...

The ITR operation is independent of any other packet which might have
passed through the box in the other direction, such as to an ETR
function.  In Ivip, if both host-A and host-B are on SPI addresses,
and if they both have their outgoing packets handled by nearby ITR-A
and ITR-B, then ITR-A does one lookup - and gets the mapping for the
micronet which encompasses host-B's address.  When the second packet
is sent, ITR-B does a similar lookup, but with host-A's address, and
gets mapping for the micronet which covers host-A's address.

It doesn't matter where the ETR functions are performed - and ETRs
don't cache anything.


>>> Will the content providers adapt to this technology - if the content
>>> sites becomes unreliable due to cache housekeeping will they adapt or
>>> do they rather stay with the current solution - so they don't risk
>>> their business model?
>> I don't understand the problem you are referring to.
>>
>>
>>> If the cache solution is not 100% reliable and proven the content
>>> providers will most likely not accept this technology and then the CES
>>> approaches will not be adapted.
>>
>> Maybe you are asking what happens if ITR caches are unreliable.
>> There's no reason why they should be unreliable.  Do you have any
>> specific problems in mind, for Ivip or for LISP?
>>
>>> Can you get a better story if you combine a CES with CEE from day one,
>>> explaining the benefits of it, also remove the address space
>>> constraints, so that the content providers can have simpler&cheaper
>>> Internet connectivity and they can reach more customers in the future?
>>>
>>> Only more questions....and I might misunderstand something...
>>
>> Maybe so - it is difficult discussing this stuff by email.
>> Face-to-face and pen and paper would be a lot easier!
> 
> Agree, a whiteboard would be great - think we also are mixing with the
> definition of locators and identifiers.
>
> I'll send you off-list a presentation  that I did back in December, it
> might get you up to speed with hIPv4 - I realized then that a host
> upgrade only is not preferable, need to team up with a CES
> (map&encpasulate) solution to speed up to the migration pace. Perhaps
> we can sort this out...

OK - I have made the new presentation available at

  http://www.firstpr.com.au/ip/files/PF/

which is where I put an earlier presentation from March last year.

  - Robin



A "server" (formerly a "slice") is a running instance of an operating
system, with its data and all, CPU registers, RAM - everything.  This
can be be moved from one physical server (which runs many of such
things) to another, with only a few seconds break - though the
end-user doesn't do this.  The OS and apps itself doesn't know its
happened, as far as I know.  The end-user can halt the "server" and
make a copy of it (all its hard drive contents) as a backup.  Then it
can be restarted and the the backup can be run as another "server" -
which is identical, but has a different global unicast address and
private LAN IP address.

So a single fully configured "server" can be cloned as often as
required, all via the HTTPS web interface - each one resulting in a
different server instance, probably (or if you want, definitely)
running on another physical server.  The "server" can be running any
one of many 64 bit OSes - I use CentOS.  There is some kind of API so
the creation of these "servers" can be under program control, from
another "server" of course.