Subject: Re: [rrg] RRG to hibernation

From: [email-masked]
Date: Tue, 4 Dec 2012 04:52:48 -0500 (EST)

The recent storm in a glass of water has calmed down again. Silence has returned.
I think the outcome of the RRG doesn't satisfy most of the participants (besides few exceptions) and should not thrill the IAB at all.Precious time by the years has been wasted. The problem due to the IPv4 address depletion turns out to be much worse than the scalability problem. 
LISP appears to be a pull-variant replacing the legacy push-model. Loc-id-split is something else: E.g. my TARA model which  doesn't do EID-to-RLOC mapping nor  disseminate such info (neither by pull nor by push) to make sure that the packet is sent to the right ETR. It simple complies with Elvis Presley's "Return to sender, address unknown, noch such number, no such phone..." if it were sent to the wrong/ not anymore up-to-date  ETR -  
or would append a broadcast search inside the surrounding geopatch.
There is more missing: how to use TTL, peeping into the inner header ?:-( How to form and use a Multicast-Locator, or an Anycast-Locator ? How would it  handle a roaming Multicast-sender? 
Above all however there is no working strategy to deal with the situation where ipv4 is not globally unique anymore. Neither LISP nor ILNP have so far    presented a solution. And the RRG has never discussed the theoretical basics !!! In principle the 4 octet sized ipv4 address must be extended.My proposal: by two additional leading octets - in mind. This doesn't mean that they have to be placed directly in front of the 4 octets.  Particularly, the value = 0000H might be equivalent to "the two octets  aren't placed anywhere at all". But other values might be placed somewhere  (e.g. being part of the locator). 
In the (current) TARA concept it would be the geopatch number in the range 1:64800, resp. the number 64801 for well-known Anycast, and 64802 for well-known Multicast.
There are problems by the numbers. Enough for just the networking layer (TCP should take care by itself when ipv4 looses its globally uniqueness )!
I am not a friend of ipv6 either. Just to share my worries: Imagine a multicast instance where sender and receivers are roaming, where sender and receivers are a mix of ipv4 and ipv6 users, in a world where ipv4 has lost globally uniqueness. Brrrrh.
Hibernation is not the right answer.
Heiner

_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: [email-masked]
Date: Tue, 4 Dec 2012 07:06:07 -0500 (EST)

The recent storm in a glass of water has calmed down again. Silence has returned.
I think the outcome of the RRG doesn't satisfy most of the participants (besides few exceptions) and should not thrill the IAB at all.
Precious time by the years has been wasted. The problem due to the IPv4 address depletion turns out to be much worse than the scalability problem. 
LISP appears to be a pull-variant replacing the legacy push-model. Loc-id-split is something else: E.g. my TARA model which  doesn't do EID-to-RLOC
mapping nor  disseminate such info (neither by pull nor by push) to make sure that the packet is sent to the right ETR. It simple complies with 
Elvis Presley's "Return to sender, address unknown, noch such number, no such phone..." if it were sent to the wrong/ not anymore up-to-date  
ETR -  or would append a broadcast search inside the surrounding geopatch.
There is more missing: how to use TTL, peeping into the inner header ?:-( How to form and use a Multicast-Locator, or an Anycast-Locator ? 
How would it  handle a roaming Multicast-sender? 

Above all however there is no working strategy to deal with the situation where ipv4 is not globally unique anymore. 
Neither LISP nor ILNP have so far    presented a solution. And the RRG has never discussed the theoretical basics !!! 
In principle the 4 octet sized ipv4 address must be extended.My proposal: by two additional leading octets - in mind. 
This doesn't mean that they have to be placed directly in front of the  4 octets.  Particularly, the value = 0000H might be equivalent to 
"the two octets  aren't placed anywhere at all". But other values might be placed somewhere  (e.g. being part of the locator). 
In the (current) TARA concept it would be the geopatch number in the range 1:64800, resp. the number 64801 for well-known Anycast, 
and 64802 for well-known Multicast.

There are problems by the numbers. Enough for just the network layer (TCP should take care by itself when ipv4 looses its globally uniqueness )!
I am not a friend of ipv6 either. Just to share my worries: Imagine a multicast instance where sender and receivers are roaming, where sender 
and receivers are a mix of ipv4 and ipv6 users, in a world where ipv4 has lost globally uniqueness. Brrrrh.

---

From: William Herrin <[email-masked]>
Date: Tue, 4 Dec 2012 08:42:03 -0500

On Tue, Dec 4, 2012 at 4:52 AM,  <[email-masked]> wrote:
> Above all however there is no working strategy to deal with the situation
> where ipv4 is not globally unique anymore. Neither LISP nor ILNP have so far
> presented a solution. And the RRG has never discussed the theoretical basics
> !!! In principle the 4 octet sized ipv4 address must be extended.My
> proposal: by two additional leading octets - in mind. This doesn't mean that
> they have to be placed directly in front of the 4 octets.  Particularly, the
> value = 0000H might be equivalent to "the two octets  aren't placed anywhere
> at all". But other values might be placed somewhere  (e.g. being part of the
> locator).

Hi Heiner,

I think the day for this has past. For better or for worse IPv6 is
slowly happening. However, if we were going to extend IPv4 with more
bits, here's one strategy:

http://bill.herrin.us/network/ipxl.html

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: [email-masked]
Date: Tue, 4 Dec 2012 12:58:18 -0500 (EST)

Bill, you wrote:
"I think the day for this has past. For better or for worse IPv6 is
slowly happening". 
Well, without any concept how to fill 16 octets with routable information such that all users can be mobile while being involved in unicast or 
anycast or multicast.

"However, if we were going to extend IPv4 with more
bits, here's one strategy:"
http://bill.herrin.us/network/ipxl.html
 
I also thought about the option field, though not as fine-tuned as you did. And: that the leading octets might be placed 
there and eventually moved from there to some other place like to a locator and vice versa. First of all however  that  in the abstraction we have to
extend ipv4  with leading octets.                                                     
Regards,
Heiner

-----Original Message-----
From: William Herrin <[email-masked]>
To: heinerhummel <[email-masked]>
Cc: rrg <[email-masked]>
Sent: Tue, Dec 4, 2012 2:42 pm
Subject: Re: [rrg] RRG to hibernation

Hi Heiner,

Regards,
Bill Herrin

---

From: Scott Brim <[email-masked]>
Date: Tue, 04 Dec 2012 13:20:27 -0500

On 11/13/12 03:21, Tony Li allegedly wrote:
> 
> On Nov 12, 2012, at 11:49 PM, Christian Huitema <[email-masked]> wrote:
> 
>>> No.  Today if you have a set of PA prefixes and your address changes from
>> one
>>> to another, your TCP connections all break.
>>
>> That's true, has been for quite some time, and yet nobody seems to be doing
>> much about it. Which makes you wonder how big of a problem that is in
>> practice. If applications were really hurting, you would hear complaints
>> from application developers. But you don't. The applications that need
>> reliable long duration sessions incorporate some trivial checkpoint and
>> restart mechanism, or some pretty elaborate consistency protocols for big
>> databases. They probably would do that no matter what the reliability of
>> TCP, as long as it is not "perfect." And PA renumbering is probably not very
>> high in their list of "stuff that occasionally break TCP."
> 
> 
> They don't do PA renumbering.  They do PI instead.  Clearly checkpoint and restart are not sufficient, otherwise they could do PA easily.

I don't know who "they" is but applications that want to be robust
across network changes have their own identity-related functions.  They
have done their own loc/id split, for the identities that matter to them
(app/session level), and use it to sustain sessions.  They don't care
about or need what this list is talking about.

swb

---

From: Scott Brim <[email-masked]>
Date: Tue, 04 Dec 2012 13:26:52 -0500

On 11/13/12 20:17, Dae Young KIM allegedly wrote:
> OK, Shim6 is not an LIS. But, the shim is between L3 and L4 while a
> session shim would be between L4 and APP.

Usually that's handled in libraries used by apps.  We don't use X.200
layering much.

---

From: Tony Li <[email-masked]>
Date: Tue, 4 Dec 2012 11:16:37 -0800

> about or need what this list is talking about.

Hi Scott,

Doesn't that strike you as a layering violation?  Shouldn't a stack shield applications from having to create these mechanisms?

Regards,
Tony

---

From: Dae Young KIM <[email-masked]>
Date: Wed, 5 Dec 2012 08:02:37 +0900

> Usually that's handled in libraries used by apps.  We don't use X.200

Yes, session should be part of implementation issues.

Still, one would wish for a clearly declared session concept within the
TCP/IP suite, so that it is not done ad hac from one application to another
but is provided as a default interface visible to all APPs.

-- 
DY

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 5 Dec 2012 00:27:19 -0800

> Hi Scott,
> 
> Doesn't that strike you as a layering violation?  Shouldn't a stack shield
> applications from having to create these mechanisms?

Not really. Applications do have their own concept of identity, for very
good reasons -- think of the difference between managing corporate data,
your personal email, and an online game. They also have their own specific
"time line" -- anywhere between instant to forever. It is quite hard to
develop a "one size fits all" solution. Otherwise, "the market" probably
would have created one.

-- Christian Huitema

---

From: Tony Li <[email-masked]>
Date: Wed, 5 Dec 2012 09:09:04 -0800

> develop a "one size fits all" solution. Otherwise, "the market" probably

Yes, entirely reasonable.  When an application is going to be mobile across stacks, then another mechanism is necessary.  However, for the mobility of the stack itself, that support should be intrinsic.

Should apps have to know that the infrastructure has changed and that the active interface now has a different L3 name?

Tony

---

From: Eliot Lear <[email-masked]>
Date: Wed, 05 Dec 2012 18:32:32 +0100

Tony,

> Should apps have to know that the infrastructure has changed and that the active interface now has a different L3 name?

Applications may have cached state that needs to be invalidated (a good
example is DNS caching), but I don't know that this in particular
invalidates your point.

Eliot

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 5 Dec 2012 16:03:18 -0800

Good to see some activity on this list - I think?

A couple of posts have mentioned IRON, and that work did indeed
originate from this group. However, I have come to the realization
that IRON is really an interior routing solution and not an
Internetworking solution.

In particular, IRON does not use tunneling between the routers
of separate sites across the DFZ the way LISP does; it only uses
tunneling *within* a site, even if that "site" is distributed
across the global Internet.

Where IRON adds value is that it manages mobility and multi-homing
within the site without exposing de-aggregated prefixes to BGP.
The IRON relays can therefore advertise only a few short prefixes
into the BGP instead of lots of long prefixes.

I therefore think IRON is complimentary to either of LISP or ILNP.
It's just that IRON does well for "sites" that are geographically
distributed and/or have lots of mobility internally.

Thanks - Fred
[email-masked]

---

From: [email-masked]
Date: Thu, 6 Dec 2012 06:33:47 -0500 (EST)

Tunneling legacy routers a la LISP presumes global ipv4 address uniqueness, i.e. won't work as soon as that presumption doesn't hold anymore.

This is a major difference with TARA. Because TARA routers do not disseminate user reachability, each TARA router which replaces a legacy router would free a bunch of ipv4 addresses from the necessity to be globally unique.

LISP reminds me of MADCAP. As soon as MADCAP was accomplished it was OUT. And the above is one of the reasons why I expect LISP to share with it the same destiny.

Heiner

-----Original Message-----
From: Templin, Fred L <[email-masked]>
To: rrg <[email-masked]>
Sent: Thu, Dec 6, 2012 1:03 am
Subject: [rrg] Where IRON fits in

Thanks - Fred

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 7 Dec 2012 21:36:43 -0800

> > Should apps have to know that the infrastructure has changed and that the
> active interface now has a different L3 name?

Generally, no, albeit I am pretty sure that the apps that depend on NAT/firewall traversal do keep extensive data about the state of the network.

But most other apps are content to treat rare and weird network events as failures, and simply run through whatever reconnection process they have for the general failure case.

---

From: Scott Brim <[email-masked]>
Date: Mon, 10 Dec 2012 08:01:35 -0500

> Doesn't that strike you as a layering violation?  Shouldn't a stack shield applications from having to create these mechanisms?

(sorry for the delay)

First of all I'm talking about general Internet use, not special cases
like data centers.  In those cases it makes plenty of sense to treat all
higher layer functions in a block and use lower layer identification
mechanisms.

Identification is not limited to a particular layer or activity --
identities are used at multiple layers and in higher layers there can be
multiple independent identities (and identification functions).  There
is variation in what is being identified, how authentication and
authorization are done, what happens during events, lifetime, etc.
There was a time when everything used lower layer tuples for
identification and that _was_ a layer violation.  Now they have figured
out that they have to have their own mechanisms in order to be free of
location.

Could they all use the same mechanisms provided by lower layers?  The
variation in requirements says no.  Higher layer functions often need
independence in how they behave - the end-to-end argument applies up the
stack, not just in the network infrastructure.  Not only is there
variation in how identity is used already, we want to ensure that
freedom for flexibility and robustness (just as we do elsewhere in the
architecture).  In particular, nowadays some "sessions" can leap between
lower layer entities, independently of each other, while some remain and
all maintain identities. Higher layer functions related to identity
simply cannot depend on lower layers to provide it - they are now decoupled.

Scott

---

From: Scott Brim <[email-masked]>
Date: Mon, 10 Dec 2012 08:10:43 -0500

On 12/05/12 12:09, Tony Li allegedly wrote:
> Yes, entirely reasonable.  When an application is going to be mobile
> across stacks, then another mechanism is necessary.  However, for the
> mobility of the stack itself, that support should be intrinsic.

Sure.  The network layer entity can have its own identification
functions for its own purposes, and higher layer entities can and _will_
have their own.

> Should apps have to know that the infrastructure has changed and that
> the active interface now has a different L3 name?

They shouldn't have to but after years of having nothing to depend on in
L3, they are not going to trust the lower layers to take care of it for
them.