[rrg] RRG to hibernation (resent)

heinerhummel@aol.com Tue, 04 December 2012 12:06 UTC

Return-Path: <heinerhummel@aol.com>
X-Original-To: rrg@ietfa.amsl.com
Delivered-To: rrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D1CDB21F86EE for <rrg@ietfa.amsl.com>; Tue, 4 Dec 2012 04:06:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.298
X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jiV647oqit7M for <rrg@ietfa.amsl.com>; Tue, 4 Dec 2012 04:06:16 -0800 (PST)
Received: from imr-ma06.mx.aol.com (imr-ma06.mx.aol.com []) by ietfa.amsl.com (Postfix) with ESMTP id C653A21F86EC for <rrg@irtf.org>; Tue, 4 Dec 2012 04:06:15 -0800 (PST)
Received: from mtaomg-mb01.r1000.mx.aol.com (mtaomg-mb01.r1000.mx.aol.com []) by imr-ma06.mx.aol.com (8.14.1/8.14.1) with ESMTP id qB4C67rK011113 for <rrg@irtf.org>; Tue, 4 Dec 2012 07:06:07 -0500
Received: from core-dqe005a.r1000.mail.aol.com (core-dqe005.r1000.mail.aol.com []) by mtaomg-mb01.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id 3B000E00008A for <rrg@irtf.org>; Tue, 4 Dec 2012 07:06:07 -0500 (EST)
References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <CAFgODJcP1zvwRJukJdnqjSR-78XAMB1nSxL32gjUQB+NqpgESg@mail.gmail.com> <50A18F75.8060001@joelhalpern.com> <CAFgODJcDAzaYPrWFEJhgeCjnN_M9tdd+pdHTiccd=Dz=1mYrLg@mail.gmail.com> <EC8FD781-E416-4AE6-BA99-F74FE2DDA14D@tony.li> <CAFgODJfMBJBxNJ_M1_L=K0f2DpbZvzOBUgLZ6sT+-y+JevGeSg@mail.gmail.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <CAFgODJfBX0R90oiYnxWrgC1oyr5ZPTZJA23WWu=Dbqu=xmyYTQ@mail.gmail.com> <EA48576E-4953-4408-982F-9D48497F8975@tony.li> <CAFgODJeae5EwSr8aC4b3tGBMxKPZRcfKarUuuwmA1LZKjge6ng@mail.gmail.com> <E613F100-93DE-4AB3-B71D-7250EB6D57BF@tony.li> <CAFgODJcXaCX9th9nkogLhkJu7pQE3=-Yc7DWkGNgX15Rh1UQ8g@mail.gmail.com> <957297EA-FFF8-408A-A181-E57028C9B8E1@tony.li> <CAFgODJfMZZioTNXOsST42kTP_BT4-RsjR_ysQTnZLG5pjoBEdg@mail.gmail.com> <50A2D6BC.602@joelhalpern.com> <CAFgODJfH6U9t17SW5XLSy5nbA380hQZkh7snway-XyiB9MQcNQ@mail.gmail.com> <CAFgODJfRxPqmArKMjgoegD+kYFqhvPGncZiX6jvZgYBRVDnHeg@mail.gmail.com> <8CFA01C40155D41-12C8-49F61@webmail-m180.sysops.aol.com> <8CFA01D531ECFEC-12C8-49FBC@webmail-m180.sysops.aol.com> <8CFA02E6231FFC6-1CD8-3CA@webmail-d166.sysops.aol.com>
To: rrg@irtf.org
In-Reply-To: <8CFA02E6231FFC6-1CD8-3CA@webmail-d166.sysops.aol.com>
X-MB-Message-Source: WebUI
MIME-Version: 1.0
From: heinerhummel@aol.com
X-MB-Message-Type: User
Content-Type: multipart/alternative; boundary="--------MB_8CFA02EE018862F_1CD8_D21_webmail-d166.sysops.aol.com"
X-Mailer: AOL Webmail 37242-STANDARD
Received: from by webmail-d166.sysops.aol.com ( with HTTP (WebMailUI); Tue, 04 Dec 2012 07:06:07 -0500
Message-Id: <8CFA02EE00A3DE3-1CD8-3FB@webmail-d166.sysops.aol.com>
X-Originating-IP: []
Date: Tue, 4 Dec 2012 07:06:07 -0500 (EST)
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1354622767; bh=hE8KscE8HwdZOhMeIVx03V1us9JZ3DRd+3X0GNs0qcY=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=EkzH3fgA0INgXkSnb2NywPUd9xpaK+RefBSUswgwNDQjKehzNsz57T7jngnxwTfSi uXLaWnajq9ucopO3fI8A+fnoH6NGqSAObPktNGLxYrmY1V3Gzd8i4R6bbNJwMf+YwL Huqg/wCEFTDMUgPGsvHXxg5Irg61aoaXC0I22y8U=
X-AOL-SCOLL-SCORE: 0:2:441982688:93952408
x-aol-sid: 3039ac1d294850bde72f25ce
Subject: [rrg] RRG to hibernation (resent)
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2012 12:06:16 -0000

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.

Hibernation is not the right answer.

rrg mailing list

rrg mailing list