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
- [RAM] the separation of ID/RLOC Michael
- [RAM] Re: the separation of ID/RLOC Dino Farinacci
- [RAM] Re: the separation of ID/RLOC Michael
- [RAM] Re: the separation of ID/RLOC Dino Farinacci
- Re: [RAM] Re: the separation of ID/RLOC Christian Vogt
- Re: [RAM] Re: the separation of ID/RLOC Michael
- Re: [RAM] Re: the separation of ID/RLOC Dino Farinacci
- Re: [RAM] Re: the separation of ID/RLOC Christian Vogt
- Re: [RAM] Re: the separation of ID/RLOC Eliot Lear
- Re: [RAM] Re: the separation of ID/RLOC Christian Vogt
- Re: [RAM] Re: the separation of ID/RLOC Christian Vogt
- Re: [RAM] Re: the separation of ID/RLOC Noel Chiappa
- Re: [RAM] Re: the separation of ID/RLOC Tony Li
- Re: [RAM] Re: the separation of ID/RLOC Scott W Brim
- Re: [RAM] Re: the separation of ID/RLOC Christian Vogt
- [RAM] Detecting multihoming failures Robin Whittle
- Re: [RAM] Re: the separation of ID/RLOC Christian Vogt
- [RAM] ITR/ETR functions in hosts, NATs & servers … Robin Whittle
- Re: [RAM] Re: the separation of ID/RLOC Iljitsch van Beijnum
- Re: [RAM] Re: the separation of ID/RLOC Christian Vogt
- Re: [RAM] Re: the separation of ID/RLOC Iljitsch van Beijnum
- Re: [RAM] Re: the separation of ID/RLOC Tony Li
- Re: [RAM] Re: the separation of ID/RLOC Eliot Lear
- Provider Selection and Mapping Updates (Re: [RAM]… Christian Vogt
- Transport Protocol Adaptation (Re: [RAM] Re: the … Christian Vogt
- Re: [RAM] Re: the separation of ID/RLOC Christian Vogt
- Re: [RAM] Re: the separation of ID/RLOC Christian Vogt
- Re: [RAM] Re: the separation of ID/RLOC Christian Vogt
- Re: Provider Selection and Mapping Updates (Re: [… Iljitsch van Beijnum
- Re: Provider Selection and Mapping Updates (Re: [… Eliot Lear
- Re: [RAM] Re: the separation of ID/RLOC Tony Li
- Re: Provider Selection and Mapping Updates (Re: [… Iljitsch van Beijnum
- Re: [RAM] Re: the separation of ID/RLOC Dino Farinacci
- Re: Provider Selection and Mapping Updates (Re: [… Christian Vogt
- Re: [RAM] Re: the separation of ID/RLOC Christian Vogt
- Re: [RAM] Re: the separation of ID/RLOC Tony Li