On Mon, Feb 1, 2010 at 10:14 PM, Noel Chiappa <j...@mercury.lcs.mit.edu> wrote:
>    > From: Patrick Frejborg <pfrejb...@gmail.com>
>
>    > Then the edge IP address space is only visible inside the local network
>    > (in LISP that is EID)
>
> Ah, no - LEID's are globally visible, and globally unique.
>
Do they really need to be globally visible and globally unique in the future?

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 - if
there is a problem the endpoint could try another path to the remote
endpoint - if that fails then the problem is most likely in the remote
endpoint and not in the network.
And with multi-path enabled transport protocols this endpoint
aliveness detection is sort of integrated there.


> And while I'm here anyway...
>
>    > The current address model is soon running out of addresses, what then?
>    > When you are there you have to go after the host stack
>
> Not necessarily. I suspect the answer is 'more NAT'.
>
> Because of the inertia of the IPv4 service interface, with the amazingly huge
> ball-and-chain of deployed base which speaks it, I think IPv4 addresses will
> be around for a very long time - even if, inside the network, we move to
> something else, e.g. between xTRs. In other words, TCP will continue to see
> IPv4 addresses - even if those are mapped into 'something else' shortly after
> leaving TCP.
>
> Whether the 'something else' is more IPv4 addresses (as with NAT44), or
> something different, will depend - it will be 'something different' only when
> that 'something different' has a sufficient economic incentive.
>

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

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

-- patte

>        Noel
>
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg

Reply via email to