[rrg] Updated version of hipv4 framework available

Patrick Frejborg <pfrejborg@gmail.com> Fri, 29 May 2009 13:42 UTC

Return-Path: <pfrejborg@gmail.com>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4C73A6987 for <rrg@core3.amsl.com>; Fri, 29 May 2009 06:42:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.141
X-Spam-Level:
X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9YlWirVUPzE for <rrg@core3.amsl.com>; Fri, 29 May 2009 06:42:48 -0700 (PDT)
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by core3.amsl.com (Postfix) with ESMTP id ABFED3A6B1D for <rrg@irtf.org>; Fri, 29 May 2009 06:42:48 -0700 (PDT)
Received: by an-out-0708.google.com with SMTP id d11so3285199and.37 for <rrg@irtf.org>; Fri, 29 May 2009 06:43:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=i6zdzi7IS5JFXDQpqxOKnZN8XFwLPMWG4OhpzZRgQeo=; b=J1JP/AYj47jGsZCBB4wv+M3z2c1m2F8U5unxIXFtijs/1arLmh1YICJY7RK32CrT/2 l9rwpceh337aCiQfF5OIgabNyRmdCPNV7HrLk9FsVOGoC3bVge6zLKuo7h5Q53jhKLff hYGbkt6oC2XEIJoWe0E0HJs+8YBUAk9r7pCuU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=tRZSMtPnIaBFAWvVKiNcWJ0CW4lexvfVmY3eBwAWpf0eB4CcxVpJ0IPi5zv3psXXfc ZGtapeUw6SARlC3HtFN+U+QCGhZX2rKse1Y3rF88kAp91HKdLa1g9f2BGV5h7BI/F15M CiyJiGWMM4Ly9TXCELmwTNkFl4sEWxT6SUNM8=
MIME-Version: 1.0
Received: by 10.100.3.13 with SMTP id 13mr3725987anc.75.1243601133054; Fri, 29 May 2009 05:45:33 -0700 (PDT)
Date: Fri, 29 May 2009 15:45:33 +0300
Message-ID: <5bc37fd40905290545q2e97e0c6xa2255b5cf3a97aae@mail.gmail.com>
From: Patrick Frejborg <pfrejborg@gmail.com>
To: RRG <rrg@irtf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [rrg] Updated version of hipv4 framework available
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/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: Fri, 29 May 2009 13:42:49 -0000

Hi,

after studying the material from Dagstuhl and the discussion about
locator/identifier on the RRG list I realized that I need to update my
draft to be in-line with the new definition of locator and identifier.
Therefore I changed the syntax in the draft to Area LOCator (ALOC) and
Endpoint LOCator (ELOC) to describe a two level hierarchical
addressing/routing structure.

I also tried to add an identifier to the framework - the reason is
that there are some issues that could be improved, but can't be
perfectly solved within the network layer. I believe the identifier
should be decoupled from the network layer - in order to create a true
separation. My conclusion is that a new protocol is needed between the
network and transport layer, an "endpoint" or "host" layer is needed.
When I was trying to find an identifier solution I stumbled over Host
Identity Protocol and it seems that they have been doing an excellent
work on an identifier solution. So I'll not describe HIP, instead I
mention in my draft where and why HIP could fit in the framework.

The hard part is the transition - why should service providers,
enterprises and residential users migrate from a solution that is good
enough and is still fully functional though it has been announced
several times to be in serious trouble??
Offering only technical arguments (address depletion, routing
scalability, etc) to the general public will not cause a wave of
upgrades. A locator/identifier solution should offer something new -
by using non-technical arguments - that could create a movement,  a
cause that will drive an upgrade. So I have added some "idealism" to
my draft.

http://tools.ietf.org/html/draft-frejborg-hipv4-02

I hope You can find some thoughts/ideas that can be useful in Your
research work.

-- patte