Re: [rrg] RRG to hibernation

Patrick Frejborg <> Tue, 13 November 2012 10:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D72821F8676 for <>; Tue, 13 Nov 2012 02:06:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MsE58UfUL4jm for <>; Tue, 13 Nov 2012 02:06:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0191D21F861B for <>; Tue, 13 Nov 2012 02:06:53 -0800 (PST)
Received: by with SMTP id wz12so260161pbc.13 for <>; Tue, 13 Nov 2012 02:06:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gq04eJdqFw3WjFcq8vOq7a62UCcuCHreZEciZYaaHD8=; b=kPvn+PVb1KypE/7Sl5uvDV26Foa3YXxW2VNY5ZF3driBkEN/itVj975by2dvqVc/i2 qXEmI9ZdfrTX/whRGF8sXrjxhXkPjO8owXBm6bBxUQisJtrtf7u9I2kaB44knT8R+1EG YlSSrtS2EcKgx6JxoVu5ptcZyHpoJmy0553mkH02hFDFOkzZHosBq/G+dYe1F+/Vy6c8 CUyTXZf2yAgY87mn8pyU6fLpkEdJpzv+h4ObbHZStb49XmiOu8Br5lven5nVsnr+Crl9 9Zgq4CBqhmMM9wX9knNXz3Q18kqxw4DZYRA+J4spoNgSo0AXQvT5UxAJEKmzy/m9o42W WA4A==
MIME-Version: 1.0
Received: by with SMTP id p1mr56770080pax.20.1352801211743; Tue, 13 Nov 2012 02:06:51 -0800 (PST)
Received: by with HTTP; Tue, 13 Nov 2012 02:06:51 -0800 (PST)
In-Reply-To: <09cc01cdc173$71323cd0$5396b670$>
References: <> <> <> <> <> <> <> <09cc01cdc173$71323cd0$5396b670$>
Date: Tue, 13 Nov 2012 12:06:51 +0200
Message-ID: <>
From: Patrick Frejborg <>
To: Christian Huitema <>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [rrg] RRG to hibernation
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: Tue, 13 Nov 2012 10:06:55 -0000

On Tue, Nov 13, 2012 at 9:49 AM, Christian Huitema <> 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."
Outcome is that the networking people have to build larger L2 DC
networks so that applications don't break when a VM is moved between
locations - now the DC networks are becoming so large that we need
another layer (NVO3) to extend the VLAN range of the already very
large L2 DC networks.
Life would be so much easier to move a session from one VM to another
VM, with the help of a session identifier - instead the packets are
encaped with new headers on the "wire" and not at the hosts where the
encap/decap of the session layer should occur without changes for the
applications. Of course, some application will suffer; if all
applications are preserved as such then there is no true separation
between identifiers and locators because some of the applications make
use of the overload of Loc/ID (also transport protocol needs to evolve
in order to make multi-homing more convenient). However, it is a nice
starting point to apply the encap of a new header at the wire but it
shouldn't be the final goal, the goal should be to have a stack
containing a session layer.

Switching topic:
Danny and Shane had some thoughts about BGP, perhaps there is room for
improvement on inter-domain routing.  I agree there might some
unfinished topics for us, found an interesting paper on how BGP might
be improved.