Subject: [lisp] Reachability bits and PE deployment

From: "Damian Lezama" <[email-masked]>
Date: Sat, 6 Jun 2009 21:33:34 -0700

Hi,

I'm trying to understand how the reachability bits can be controlled in an
scenario where the xTR's reside inside different ISPs for a multihomed site.
As an example if I have a site and 2 providers (A and B) and a host in my
site with EID E sends traffic that goes through A, the ITR at A should
include information about the reachability to E through provider B, how can
it possibly have that information?

I see three possible deployment scenarios explained in the draft, and there
are also combinations. When xTRs are deployed into the customer site I
assume that the site will need mechanisms to keep its xTRs consistent, but
when multiple providers enter the scene I don't get how this could work.

Thanks,

Damian

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 7 Jun 2009 14:24:02 -0700

> I’m trying to understand how the reachability bits can be controlled  
> in an scenario where the xTR’s reside inside different ISPs for a  
> multihomed site. As an example if I have a site and 2 providers (A

They cannot be controlled. The xTRs need to be in the same  
administrative domain.

As we have said before, the sweet-spot for deploying LISP routers is  
where they will be least disruptive to the existing network. That is  
in the CPE router.

If you feel LISP functionality can or you want it to be in PE/P  
routers within an ISP, then you have to use other reachability  
mechanism. One that is obvious is using BGP.

> and B) and a host in my site with EID E sends traffic that goes  
> through A, the ITR at A should include information about the  
> reachability to E through provider B, how can it possibly have that  
> information?

You should not use the loc-reach-bits for this application.

> I see three possible deployment scenarios explained in the draft,  
> and there are also combinations. When xTRs are deployed into the  
> customer site I assume that the site will need mechanisms to keep  
> its xTRs consistent, but when multiple providers enter the scene I  
> don’t get how this could work.

Yes, by configuration the xTRs at a site are kept consistent. And you  
use route-change notifications from the IGP protocol you run at the  
site to tell xTRs which other xTRs have gone down.

Dino

>
> Thanks,
> Damian
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 07 Jun 2009 17:40:33 -0400

If PE deployments catch on, and if the PEs are using IGPs to talk to the 
site, then one can imagine flooding extra (opaque) information through 
the IGP to provide xTR synchrony.
Alternatively, there are multiple mechanisms involving the xTRs peering 
over the Internet cloud and exchanging liveness information.

It probably would help us to decide either that we are going to focus on 
the CE deployment, or that we are explicitly going to address more 
deployment scenarios.  Given many of the goals, taking CE deployment as 
our first goal would seem quite sensible.

Yours,
Joel

Dino Farinacci wrote:
> where they will be least disruptive to the existing network. That is in 
> the CPE router.
> 
> If you feel LISP functionality can or you want it to be in PE/P routers 
> within an ISP, then you have to use other reachability mechanism. One 
> that is obvious is using BGP.
> 
>> I see three possible deployment scenarios explained in the draft, and 
>> there are also combinations. When xTRs are deployed into the customer 
>> site I assume that the site will need mechanisms to keep its xTRs 
>> consistent, but when multiple providers enter the scene I don’t get 
>> how this could work.
> 
> use route-change notifications from the IGP protocol you run at the site 
> to tell xTRs which other xTRs have gone down.
> 
> Dino
> 
>>
>> Thanks,
>> Damian
>>

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 7 Jun 2009 15:03:16 -0700

> It probably would help us to decide either that we are going to  
> focus on the CE deployment, or that we are explicitly going to  
> address more deployment scenarios.  Given many of the goals, taking  
> CE deployment as our first goal would seem quite sensible.

100% agree.

Dino

---

From: David Meyer <[email-masked]>
Date: Mon, 8 Jun 2009 07:47:38 -0700

> our first goal would seem quite sensible.

	Agreed Joel.

	Dave

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Jun 2009 07:54:04 -0700

> our first goal would seem quite sensible.

Hey - RANGER/VET/SEAL already have the CPE deployment scenario
well-covered. Those documents already define mechanisms well
suited to the CPE scenario (e.g., default router discovery,
secure redirection, address autoconfiguration, etc.) so what
would be the point of trying to push LISP into that space?

Fred
[email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 8 Jun 2009 12:13:37 -0700

LISP has always been in the CPE space. There seem to be others pushing  
it in the PE space.

Dino