Subject: [RAM] the separation of ID/RLOC

From: Michael <[email-masked]>
Date: Thu, 28 Jun 2007 11:29:30 +0800

Hi, Dino,

As I spot, in LISP1, LISP1.5, there is no a complete separation bwtween ID/RLOC , because, within a site, a EID still play both roles at the same time, in LISP2 & LISP3, EIDs are said to be unroutable, I do not really understand, here I guess that you mean EIDs are not routable among ISPs, like Tier-1 etc, they are still routable inside a site. If I am wrong, how devices inside a site can be routed?  

best,

Michael
_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 28 Jun 2007 08:02:43 -0700

> As I spot, in LISP1, LISP1.5, there is no a complete separation  
> bwtween ID/RLOC , because, within a site, a EID still play both  
> roles at the same time, in LISP2 & LISP3, EIDs are said to be  
> unroutable, I do not really understand, here I guess that you mean  
> EIDs are not routable among ISPs, like Tier-1 etc, they are still  
> routable inside a site. If I am wrong, how devices inside a site  
> can be routed?

The ID/RLOC split is for global communication. Which means outside of  
the site. So yes, an EID is routeable within a site and there is no  
split because the packet hasn't hit an ITR yet. When the packet  
reaches an ITR, the packet is typically destined for a destination  
outside of the site. At that point the ITR prepends a header where  
the addresses in the outer header are RLOCs.

Dino

---

From: Michael <[email-masked]>
Date: Fri, 29 Jun 2007 09:46:49 +0800

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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 28 Jun 2007 21:31:11 -0700

> 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.

Yep, agree with everything you wrote.

Dino

---

From: Christian Vogt <[email-masked]>
Date: Fri, 29 Jun 2007 10:44:59 +0300

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.

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.

- Christian

Michael wrote:
> 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

---

From: Michael <[email-masked]>
Date: Fri, 29 Jun 2007 16:02:33 +0800

Hi, Christian,

----- Original Message ----- 
From: "Christian Vogt" <[email-masked]>
To: "Michael" <[email-masked]>
Cc: "Dino Farinacci" <[email-masked]>; <[email-masked]>
Sent: Friday, June 29, 2007 3:44 PM
Subject: Re: [RAM] Re: the separation of ID/RLOC

> when one goes down.  This is one of the main goals for multi-homing.

This is the basic requirement on the mapping mechanism.

> 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

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 29 Jun 2007 07:11:21 -0700

> for access network mobility.  Its also needed for provider fail-over.

It is needed as well for regular packet forwarding when nodes are  
stationary.

> when one goes down.  This is one of the main goals for multi-homing.

For what value of "quickly"? Please quantify.

> Fast provider fail-over requires a very agile mapping function,  

It all depends on change frequency and the level of granularity is  
required. So please quantify.

> trade-off between the two, can support this in a scalable manner.

Or just keep it out of the mapping service.

Dino