Re: [rrg] Rebooting the RRG

heinerhummel@aol.com Mon, 18 November 2013 21:53 UTC

Return-Path: <heinerhummel@aol.com>
X-Original-To: rrg@ietfa.amsl.com
Delivered-To: rrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA89B1AE5D4 for <rrg@ietfa.amsl.com>; Mon, 18 Nov 2013 13:53:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.525
X-Spam-Level:
X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6GEXcfuyH4R for <rrg@ietfa.amsl.com>; Mon, 18 Nov 2013 13:53:13 -0800 (PST)
Received: from omr-d01.mx.aol.com (omr-d01.mx.aol.com [205.188.252.208]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDCF1AE5BC for <rrg@irtf.org>; Mon, 18 Nov 2013 13:53:13 -0800 (PST)
Received: from mtaomg-db01.r1000.mx.aol.com (mtaomg-db01.r1000.mx.aol.com [172.29.51.199]) by omr-d01.mx.aol.com (Outbound Mail Relay) with ESMTP id 2948770057A63; Mon, 18 Nov 2013 16:53:07 -0500 (EST)
Received: from core-dqb002c.r1000.mail.aol.com (core-dqb002.r1000.mail.aol.com [172.29.212.197]) by mtaomg-db01.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id C7FB7E00008A; Mon, 18 Nov 2013 16:53:06 -0500 (EST)
References: <5B131180-FA93-4A05-B3BE-3A23767EBD9D@netapp.com> <CAPv4CP_xs0Ki4Ada-CrBQftwtSfWVEK8gxohKTHEMHAEHP9s_A@mail.gmail.com> <CAG4d1rcXJzOC=tTqbCUK7i7a62vbiEyC9UCWLi0XvsXv8fW4qQ@mail.gmail.com> <FD7BEAB9-F967-4788-BBCA-6E06FBE585A8@tony.li> <CAPv4CP_tNAbE0MbY=kLPuNTdpnLkQ5ia7N=z_ibXfBqsVTXcAA@mail.gmail.com> <A61A0825-AE59-4442-85F7-6953E2487C8B@netapp.com> <8D0B1CA286334B8-EC0-1C5DC@webmail-d146.sysops.aol.com> <B339F343-B607-4F56-A50C-6B2CE37532C4@pi-coral.com>
To: tli@pi-coral.com
In-Reply-To: <B339F343-B607-4F56-A50C-6B2CE37532C4@pi-coral.com>
X-MB-Message-Source: WebUI
Received: from 178.26.195.50 by webmail-d250.sysops.aol.com (205.188.17.40) with HTTP (WebMailUI); Mon, 18 Nov 2013 16:53:06 -0500
MIME-Version: 1.0
From: heinerhummel@aol.com
X-MB-Message-Type: User
Content-Type: multipart/alternative; boundary="--------MB_8D0B2BFB271542F_186C_91C2D_webmail-d250.sysops.aol.com"
X-Mailer: Webmail 38203-STANDARD
Message-Id: <8D0B2BFB267CEAF-186C-2ABB2@webmail-d250.sysops.aol.com>
X-Originating-IP: [178.26.195.50]
Date: Mon, 18 Nov 2013 16:53:06 -0500 (EST)
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1384811587; bh=DoPP0Y2QT3RD81Ogz51/FEgy95qHoQIdfGxVuLH9LEw=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=TFIubMsOIvpHQue/56FDjcU+4dtw7PWbXVlTTmEeGLLTe8EXKfos6P7Woh4sX+iXb KdRq/E583fM/ri0vPlB9sKXmde6OGFbILWUBqytvWYUr3nG4Rq2O4y0+BWuARg2voB nNkSsgm24ZC8idbK4PyGjLr/5IhSkp/8g2jjM+l4=
x-aol-sid: 3039ac1d33c7528a8c42287b
Cc: rrg@irtf.org
Subject: Re: [rrg] Rebooting the RRG
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.15
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: Mon, 18 Nov 2013 21:53:15 -0000

Certainly - though the times are gone when routing and addressing where identical, i.e. when my means of the next dialled digit the next-hop trunk was selected electro-mechanically.
Just compare TARA-now ( http://www.igi-global.com/chapter/topology-aggregating-routing-architecture-tara/77501 ) and the long expired draft-hummel-tara-00:
I once had the same idea like Fuller  to  disseminate a prefix of length zero, so that a TARA-router closest to the ingress could attract traffic,  then prepend a TARA-header as to do TARA-forwarding to some TARA-ETR. But it was necessary to sacrifice this nice idea. Instead it is more important to involve the user side and
have  FQDN mapped to {IPv4; TARA-locator} by one single action. The gain: tons and tons of available IPv4-addresses.


All has to be taken into consideration. Whereas the LISP-supporters say "hey, addressing is not our problem; we just deal with the scalability issue".
Well, if you want to help IPv4, both issues must be of concern, and the address depletion is even the more serious issue, isn't it?


Heiner





-----Ursprüngliche Mitteilung----- 
Von: Tony Li <tli@pi-coral.com>;
An: heinerhummel <heinerhummel@aol.com>;
Cc: lars <lars@netapp.com>;; rrg <rrg@irtf.org>;
Verschickt: So, 17 Nov 2013 7:12 pm
Betreff: Re: [rrg] Rebooting the RRG



On Nov 17, 2013, at 8:35 AM, heinerhummel@aol.com wrote:

> When RRG was launched the driving force was the so-called scalability problem.
> Currently the biggest issue is the expiration of available IPv4 addresses.
> That however would be a non-issue if the FQDN were mapped to {IPv4 addr of 
destination user; locator of ETR} in a single strike based on DNS while taking 
care that IPv4 addresses of the same locator were mutually unique.
> LISP-DDT neither does so now, nor would be able to do so ever. Hence IPv4's 
lifetime is up to NAT as long as solutions like LISPv2.0 or my TARA are 
discarded/ignored. There are much more knowledgable folks around who know the 
disadvantages of the NAT sinfall better than myself. I can only add one 
disadvantage: With a network layer based on TCP (NAT) you can never enable 
Multicast with a roaming sender.
> 
> I think this IPv4-depletion issue is the most urgent problem at all.


Is that a routing problem?

Tony