Subject: Re: [rrg] SIP will work fine with CES, CEE won't work with NAT

From: [email-masked] (Noel Chiappa)
Date: Tue, 2 Feb 2010 10:00:25 -0500 (EST)

> From: Patrick Frejborg <[email-masked]>

    >> Ah, no - LEID's are globally visible, and globally unique.

    > Do they really need to be globally visible and globally unique in the
    > future?

Yes - they need to be globally visible because they are the names that
endpoints use to identify each other, and you may want to talk to another
endpoint anywhere (hence the need for global scope).

    > Do we need network aliveness detection or is this functionality
    > something that an endpoint could take care of?
    > An endpoint is interested if the remote endpoint is alive or not

When you say "network aliveness detection" I gather you mean 'detection of
endpoint liveness by the network'? If so, yes, I agree, we should probably
not have the 'network' (by which I assume you mean routers) doing liveness
detection.

    > if there is a problem the endpoint could try another path to the remote
    > endpoint

The problem is that in the current state of the architecture (in particular,
the routing architecture), the host can't really do this. Yes, in those cases
where the destination has multiple locators (because of either site or host
multi-homing), use of another locator _may_ bypass the problem.

However, this is a degenerate case: not all endpoints will have multiple
locators; the problem may be close to the source, so that different
destination locators all still cross the same failure point, etc, etc. Thus,
in many cases where there is a usable alternative path, that path with not be
discoverable through use of an alternative locator for the destination.

So the real solution to that particular issue is a better routing
architecture.

    > IPv4 will be around for a very long time - especially in the old
    > economies

My point was stronger than that, actually - I was arguing that IPv4 addresses
will be _central_ for a long time to come.

    > But if you ease up the rule of globally uniqueness a little bit then
    > you could start to reuse the edge prefixes and perhaps reduce the
    > amount of NAT

Huh? NAT is _precisely_ 'making edge prefixes not globally unique'! This is
done so that a single prefix can be reused - the exact goal you list!

For example, the prefix 192.168.0.0 is already reused over and over again.

Are you talking about re-using the addresses on the other side of that NAT?
That's just double-NAT. NAT _is_ re-use of prefixes.

	Noel

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 2 Feb 2010 17:59:26 +0200

On Tue, Feb 2, 2010 at 5:00 PM, Noel Chiappa <[email-masked]> wrote:
>    > From: Patrick Frejborg <[email-masked]>
>
>    >> Ah, no - LEID's are globally visible, and globally unique.
>
>    > Do they really need to be globally visible and globally unique in the
>    > future?
>
If you take the core-edge philosophy and apply that on the address
space - creating a hierarchical address space the endpoints can still
be identified though they use the same edge space. With LISP terms, if
the RLOC is telling the attachment point to Internet and the EID is
telling the attachment point at the local network you have a two level
address space. And the local network address space can be reused if
the global address space is unique - similar as in PSTN but without
geographical boundaries, it should follow as much as possible the AS
and RIR structures that is in place (some trade offs are needed).

>
>    > Do we need network aliveness detection or is this functionality
>    > something that an endpoint could take care of?
>    > An endpoint is interested if the remote endpoint is alive or not
>

Right

>
>    > if there is a problem the endpoint could try another path to the remote
>    > endpoint
>
Agree, but instead of telling the world my edge prefix I tell to the
routing architecture my attachment points (in LISP, RLOC values - in
hIPv4 Area LOCator, ALOC). Then the routing architecture will have a
lot less prefixes to carry, the remote endpoints knows my attachment
points and in case of failure they can try different attachment points
but my endpoint value (In LISP EID, in hIPV4 Endpoint LOCator, ELOC)
remains unchanged. Less work for the routing architecture, little bit
more work for the endpoints but since MP-TCP is arriving anyway why
not use that resource to improve the routing architecture?
So my server could have the following address 192.168.1.1:10.10.10.10
and 172.16.1.1:10.10.10.10, the first is the ALOC value and the latter
is the ELOC value

>
>    > IPv4 will be around for a very long time - especially in the old
>    > economies
>

You too, I hadn't the courage to state that :-)

>    > But if you ease up the rule of globally uniqueness a little bit then
>    > you could start to reuse the edge prefixes and perhaps reduce the
>    > amount of NAT
>

No, it is not really NAT though that is the first thought that many
have - you carry both source&destination ALOC/ELOC values with the
header all the time - but the API will see just legacy IPv4 addresses.
So no address hiding, the edge addresses (EID/ELOC) will never show up
in the DFZ and the ELOC can be PA and PI-addresses. PI-address
here=own by the enterprise and will not show up in the core-DFZ but it
will show up in the edge-DFZ.

-- patte

---

From: Scott Brim <[email-masked]>
Date: Tue, 02 Feb 2010 13:10:08 -0500

> So the real solution to that particular issue is a better routing

Noel, how would _routing_ determine whether a different path to a
particular individual endpoint should be tried (by either an endpoint or
an intermediate router)?

Scott

---

From: Florin Coras <[email-masked]>
Date: Tue, 02 Feb 2010 19:14:33 +0100

> and RIR structures that is in place (some trade offs are needed).

Maybe I'm missing something but what happens when a mobile endpoint 
changes its point of attachment in the hierarchical address space to a 
new location that might just be using the same "edge space address" to 
identify another endpoint?

Florin

---

From: Patrick Frejborg <[email-masked]>
Date: Wed, 3 Feb 2010 08:55:11 +0200

On Tue, Feb 2, 2010 at 8:14 PM, Florin Coras <[email-masked]> wrote:
>
> Maybe I'm missing something but what happens when a mobile endpoint changes
> its point of attachment in the hierarchical address space to a new location
> that might just be using the same "edge space address" to identify another
> endpoint?
>
> Florin
>
When you are changing location and you are moving from one network to
another MP-TCP takes care of your issue. At the new location you get a
new edge-address and if this happens on the fly, e.g. from WiFi to 3G
the MP-TCP token keeps the session alive - during roaming you have two
edge space addresses in use and if you are really unlucky you get two
exactly similar addresses. Don't know how the MP-TCP stack would react
to this, it could happen already today with RFC 1918 addresses.
The mobile device is not identified with something in the IP layer, so
when you are changing location you can receive whatever IP address
from the service provider - MP-TCP token keeps your session alive.
I.e. the mobile device doesn't take with it a given IP address from
one service provider to another service provider

-- patte

---

From: Robin Whittle <[email-masked]>
Date: Wed, 03 Feb 2010 19:15:14 +1100

Short version:    Interesting report on Internet traffic patterns.

                  Trying to use the EID/SPI address as a purely
                  local identifier, with the same value to be
                  re-used in various end-user networks, is
                  incompatible with CES, since it must be globally
                  unique.

                  IPv4 will be _central_ for a long time to come.

Hi patte,

You wrote:

>>> A cookie is an identifier that is decoupled from the address
>>> space and network layer, the more these kind of applications
>>> there is deployed the easier it would be to change the network
>>> and address architecture.
>>
>> Yes, but this is just client-server applications.
>
> Very true, it is just one application.
> But it is causing about 52% of the Internet traffic and increasing
> Have a look on slide 22 at
 http://www.nanog.org/meetings/nanog47/presentations/Monday/Labovitz_ObserveReport_N47_Mon.pdf

> But once you get into enterprises the traffic profile is different

Thanks for pointing me to this most interesting report.  I am glad to
see P2P traffic dropping in favour of "direct download" file sharing.
 Having all those bytes flowing upstream in DSL cable systems was
really bad.  DSL upstream links have limited RF bandwidth - 10 or 20
MHz or so - and are very low efficiency, such as 1 bit per Hz,
whereas downstream is 6 to 8 bits per Hz, with many 6 to 8MHz bands
available.  DSL upstream is less efficient and more constrained too,
but not as bad as HFC cable.

I am not surprised that "Web" traffic, at 52% and rising, dominates
the traffic stats.  But the volume of packets doesn't necessarily
correlate fully with the value of the application.

Quoting yourself, Noel, yourself and Noel again, you wrote:

> be identified though they use the same edge space. 

I wouldn't describe CES architectures such as LISP as involving
"hierarchical address space", so I am not sure what you are referring
to.  How could the "edge" addresses of LISP (EIDs) or Ivip (SPI
addresses) be used so that two hosts could be separately identified,
separately used for communications or whatever, when they are on the
same "edge" address?

The "edge" addresses are a subset of the global unicast address
space.  Unless used as anycast addresses, any such address - in
either the "core" or "edge" subset - can be used to identify only one
host.

> With LISP terms, if

Then you are no longer describing LISP or any other CES arrangement.

The EID is indeed used within the end-user network to specifically
identify the destination host, but the whole purpose of CES is to
make that address both globally reachable, and able to be used via
any ISP.

The first requirement - global reachability - means that the EID is
globally unique.

(Skipping some of what you wrote.)

> You too, I hadn't the courage to state that :-)

I agree with you both.

  - Robin

---

From: Patrick Frejborg <[email-masked]>
Date: Wed, 3 Feb 2010 11:04:09 +0200

Hi Robin

> either the "core" or "edge" subset - can be used to identify only one

I used the LISP terms to link it to hIPv4, to make it easier to
capture, but perhaps I'm just mixing up peoples mind by doing that

You are right about what you are saying about CES, there is no
"hierarchical address space" in a CES architecture - you are
preserving the flat, global unique address space there

I was inspired by LISP and had a little misunderstanding how it really
works :-)  Nevertheless I took the core-edge split philosophy from
there and applied it also on the address space (to see where it goes),
dividing the currently flat address space into one global unique
address space, called Area Locators (ALOC) and several regionally
unique edge-address spaces, called Endpoint Locators (ELOC).

This gives you the possibility to build a new routing architecture -
you will have two types of DFZ:
- a global DFZ that is containing only ALOC prefixes, only service
providers should have the possibility to apply for an ALOC prefix so
the size of this global DFZ should be less than 100k for a very very
long period
- several edge-DFZ, each service provider will have their own edge-DFZ
and the edge-DFZ will contain the following prefixes:
* the global ALOC prefixes
* the directly attached PA-addresses (mostly residential users and
small businesses)
* the directly attached PI-addresses from multi-homed enterprises.

As you can see, the directly attached PA/PI-addresses never goes into
the global DFZ and thus prefixes from one edge-DFZ doesn't go into
another edge-DFZ. Also if you have BGP churn in a edge-DFZ it is not
reflected to rest of the Internet.

So I claim that hIPv4 is providing a new routing architecture - it is
either not a CES or a CEE - it is something else. And it seems that
you have to do something to the address space in order to get a new
routing architecture. There are also challenges and issues, can they
be worked through or not reminds to be seen. An outcome of this
approach is also that IPv4 addresses can be reused, if hIPv4 is
adopted we should see less NAT in the future.
To speed up transition hIPv4 should cooperate with a CES approach, it
will take time before hosts' stacks are upgraded.
But first, is the hIPv4 technically correct, is there something that
is broken???
Then you have all the transition issues, hIPv4 will have an impact on
the service providers and RIRs so they should analyze and either
accept or deny the approach - but this step should be taken if hIPv4
is technical doable.
The final frontier is the end users, but I think MP-TCP will do the
job for us there
And for sure, hIPv4 is not perfect but is it good enough..?.

-- patte

---

From: Robin Whittle <[email-masked]>
Date: Wed, 03 Feb 2010 22:35:18 +1100

Hi patte,

In "Re: SIP will work fine with CES, CEE won't work with NAT"
(msg05919) you wrote:

> works :-)  

Misunderstandings can be useful.

There are occasions when the experts know something can't or
shouldn't be done.  Then a non-expert blunders in, not realising
this, does it anyway - and makes it work better than the experienced
folks could have imagined.

For some reason I assumed LISP ITRs used the sending host's address
in the outer source address of the encapsulated packets.  Then I
found it was useful in Ivip for extending ISP BR filtering to the
ETR's decision of whether to forward or drop the inner packet - after
which I discovered that LISP uses the ITR address for the outer
source address.

> Nevertheless I took the core-edge split philosophy from

OK . . .

>    * the directly attached PA-addresses (mostly residential users
>      and small businesses)
>
> either not a CES or a CEE - it is something else. 

I look forward to reading about hIPv4 properly.  Based on a cursory
reading I thought it was a CEE architecture.

> And it seems that

I hope to read about it and write to you on the list with my
understanding, queries, etc. towards the end of the week.

> And for sure, hIPv4 is not perfect but is it good enough..?.

After discussing it with you on the list, I plan to write a critique
- since I think no-one has done so yet.

  - Robin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 03 Feb 2010 09:49:27 -0500

(Robin, I am using your headline as a hook for my comments.  This topic 
has been bouncing and I wanted to suggest another perspective on this. 
It probably has very little to do with what you were trying to get at in 
your note.)

IPv4 will clearly be around for a LONG time.
IPv4 will, I expect, continue to be used for a LOT of content for a LONG 
time.

However, I am not sure that matters for the RRG work.

The IPv4 Internet works.  The routers, and the routing system, cope with 
the current pressures.  To my way of looking at things, the question is 
how will the Internet routing system cope with growth.
But, definitionally, there really is not that much growth left in IPv4.

On the other hand, although IPv6 is tiny now, unless the entire Internet 
stops growing, v6 will become massive.  If we do not work out an 
architecture that can cope with growth, when that pass the current IPv4 
size, and keeps growing faster, we will be up the proverbial creek 
without any control whatsoever.
Hence, I think it is actually quite reasonable to have an architecture 
and approach which only addresses IPv6 Internet Scaling.  Without 
denying that IPv4 will be here, and important, for a very, very, long time.

Yours,
Joel M. Halpern

Robin Whittle wrote:
...
>                   IPv4 will be _central_ for a long time to come.
...

---

From: Scott Brim <[email-masked]>
Date: Wed, 03 Feb 2010 15:24:12 -0500

> denying that IPv4 will be here, and important, for a very, very, long time.

Joel, I don't quite get it.  First, if you only deal with v6 then would
you create two parallel Internets?  If so you need routing and
addressing interworking.  Second, there will be pressure for growth in
the number of IPv4 _prefixes_ and if we don't design a way to support
it, people will find ways we don't like.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 03 Feb 2010 15:40:02 -0500

1) There are a lot of ways to interwork IPv4 and IPv6, particularly for 
getting to content.  (The main problem with most such mechanisms is that 
they can not support new applications.  Requiring really new things to 
use the new infrastructure (IPv6 or something else) seems quite 
reasonable to me.

2) My point is that unless things fragment in very strange ways 
(possible, but difficult to actually see happening), the number of 
prefixes in the Internet can not grow very far.  90% of all addresses 
are already in the allocation cycle.  (Not all are allocated, and I am 
not saying we are within 10% of the top.)  Basically, new ISPs can not 
get enough IPv4 space to do business.  So they can not get space and 
fragment it, because even fragmented it simply won't do the job.
Yes, it is quite possible for economics to cause shifts in behavior, and 
it is possible for this to cause far more serious fragmentation.  But, 
in terms of planning, that does not seema  likely path.

Put differently,
1) If we (the IETF and related communities) do not solve the v4/v6 
interworking problem to a useful degree, then it does not matter what we 
do.  Economic and utilization pressures will force really unpleasant 
implementation hacks.  Discussing architecture for such an environment 
is probably useless, because the constraints are too tight.

2) If we do solve the itnerworking problem, while it is worth makign 
IPv4 work better, it is probably only strictly necessary to ensure that 
we have an architecture for IPv6 that can actually cope with the 
pressure we put on it.

Currently, the IETF is working very hard on point 1.
If we do not get a good answer to point 2, then we are going to simply 
give ourselves more rope to be hung with, and it won't be long before we 
are dangling and choking on our own mess.

Yours,
Joel