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

[Michael <mahuaiyuan at huawei.com>]

Hi, Christian,

----- Original Message ----- 
From: "Christian Vogt" <christian.vogt at nomadiclab.com>
To: "Michael" <mahuaiyuan at huawei.com>
Cc: "Dino Farinacci" <dino at cisco.com>; <ram at iab.org>
Sent: Friday, June 29, 2007 3:44 PM
Subject: Re: [RAM] Re: the separation of ID/RLOC


> Michael,
> 
> update speed and reliability of the mapping function are not just needed
> for access network mobility.  Its also needed for provider fail-over.
> 
> Access network operators want to be able to switch providers quickly
> when one goes down.  This is one of the main goals for multi-homing.
> 

This is the basic requirement on the mapping mechanism.


> Fast provider fail-over requires a very agile mapping function, however.
> To me, it is not clear how either a pull or a push model, or a
> trade-off between the two, can support this in a scalable manner.

This is the key part of the mapping mechanism. I believe that at the first step some prototype systems based on DNS (pull model) and DHT (Push model)  or some hybrid model respectively must be deployed and test their performance,  then  decide which mechanism is a good one.

The mobility support has some impact on which model will be adopted. 

Michael

> 
> - Christian
> 
> 
> Michael wrote:
>> Hi, Dino,
>> 
>> This is a overlay model, ISPs can be treated as a tranport network.
>> If we do not consider the mobility too much in this phrase, this
>> proposal works fine. If the mobility must be supported in the future,
>> the mapping becomes complicated, of course, the candidate solutions
>> will be based on the some basic assumption: the dimension of moving
>> network, that is, whether the majority part of  the Internet can move
>> arbitarily or just a small part can be allowed to move. Anyway, if
>> the mobility will be well supported, the reliability and timeliness
>> of the mapping mechanisms would be the critical issue.
>> 
>> Michael
> 
> 
>

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