Re: [rrg] Rebooting the RRG Sun, 17 November 2013 16:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CA0D11E8176 for <>; Sun, 17 Nov 2013 08:37:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mBj6C4D8UKza for <>; Sun, 17 Nov 2013 08:37:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1821011E81AF for <>; Sun, 17 Nov 2013 08:35:30 -0800 (PST)
Received: from ( []) by (Outbound Mail Relay) with ESMTP id B6B69700000AB; Sun, 17 Nov 2013 11:35:28 -0500 (EST)
Received: from ( []) by (OMAG/Core Interface) with ESMTP id 540B1E000089; Sun, 17 Nov 2013 11:35:28 -0500 (EST)
References: <> <> <> <> <> <>
In-Reply-To: <>
X-MB-Message-Source: WebUI
MIME-Version: 1.0
X-MB-Message-Type: User
Content-Type: multipart/alternative; boundary=""
X-Mailer: Webmail 38203-STANDARD
Received: from by ( with HTTP (WebMailUI); Sun, 17 Nov 2013 11:35:27 -0500
Message-Id: <>
X-Originating-IP: []
Date: Sun, 17 Nov 2013 11:35:28 -0500 (EST)
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20121107; t=1384706128; bh=shOse75c5CBQCltIPr9nJrhTkTJrPzSbq/q1zOP6gBA=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=ne9Gl/TaqVdJ5Y7/dcVeJoq7eoSCYnBWsvzdAxewlsreXX5u4MikNhXphQLTghHe0 aVOG8RTy+Lfaz4sYCWq2Kpafk0Q22MxTg+2cWytL0CYferpRQvljAaHg0NNMgFvyOU njINxnjwAM39sXyTsYYDr5MQNL2fds259Vx0JWd4=
x-aol-sid: 3039ac1d294d5288f0504021
Subject: Re: [rrg] Rebooting the RRG
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IRTF Routing Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 17 Nov 2013 16:37:26 -0000

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.