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

[Patrick Frejborg <[e-mail]>]

Hi Robin

On Mon, Jan 25, 2010 at 1:06 PM, Robin Whittle <[e-mail]> 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 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.

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.


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

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.

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

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

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

-- patte