Re: [RAM] Re: the separation of ID/RLOC

Christian Vogt <christian.vogt@nomadiclab.com> Wed, 04 July 2007 10:16 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61uh-00074i-DO; Wed, 04 Jul 2007 06:16:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61ug-00074d-89 for ram@iab.org; Wed, 04 Jul 2007 06:16:46 -0400
Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I61ub-0004Wy-Bo for ram@iab.org; Wed, 04 Jul 2007 06:16:46 -0400
Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BB330212D1E; Wed, 4 Jul 2007 13:16:40 +0300 (EEST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7A763212D16; Wed, 4 Jul 2007 13:16:40 +0300 (EEST)
Message-ID: <468B7388.3020306@nomadiclab.com>
Date: Wed, 04 Jul 2007 13:16:40 +0300
From: Christian Vogt <christian.vogt@nomadiclab.com>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: Tony Li <tli@cisco.com>
Subject: Re: [RAM] Re: the separation of ID/RLOC
References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <C03246BF-34A1-4C26-94B0-2E52BA1F0D69@cisco.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> <468A2065.1060200@nomadiclab.com> <3DD774EF-76E8-40BB-8B6F-22349CE91ABA@cisco.com>
In-Reply-To: <3DD774EF-76E8-40BB-8B6F-22349CE91ABA@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: RAM Mailing List <ram@iab.org>
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

>> Whether or not long update delays are an issue depends, as you say, on
>> the change frequency and granularity.  However, any assumptions that we
>> make in this regards should be very careful.  Our goal is to give edge
>> networks more freedom in traffic engineering and provider selection.
>> And it would be great if we could reach this goal without restrictions
>> -- such as in terms of change frequency or granularity.
> 
> Isn't this issue easily resolved by advertising more than one locator?

Tony,

if you want to an enable edge network to decide through which provider
ingress packets are received, then the edge network must be able to tell
remote edge networks one specific transit locator to which they should
send packets.

If an edge network advertises more than one transit locator, then it is
up to remote edge networks to select one of those.  This takes away the
ability for edge networks to select an ingress provider.  Additionally,
you still need a locator selection mechanism for the remote edge network
-- which may involve its own signaling overhead, delay, and packet loss.

With Six/One [1], edge networks can select both their ingress and egress
providers, and they can change them within 1 RTT without signaling.
There is also no packet loss if the old provider is still operational at
the time of the change.  And the granularity of provider selection (both
ingress and egress) is on a per-communication-session level.

[1] http://users.piuha.net/chvogt/pub/2007/draft-vogt-rrg-six-one-00.txt

- Christian


_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram