Subject: Re: [lisp] Fwd: New Version Notification fordraft-jakab-lisp-deployment-00

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 7 Oct 2010 19:28:53 +0300

Hello Lorand,

Thank you for a good draft that is comes for a clear need.  I read the draft with an interest. I have the following questions though.

I am wondering why do you say in section 3.1.2 that colocating P-ITR with the site's tunnel routers causes the downside of no decrease in global DFZ state? Shouldn't P-ITR announce "certain aggregated EID prefixes" as you write in section 3.1. Then, how is it that colocating the P-ITRs with the xTRs will cause the down side. Or do you suggest that the P-ITRs will start to advertise more specifics of EIDs when colocated? And why would they do that? Shouldn't they announce EIDs at level of the site they are colocated. Would here the techniques described in section 2.4 be useful, i.e. apply LISP recursively if a packet gets misrouted?  

A second thing that strikes me is the emphasis on the role of CDNs. I can see that CDNs might easily take a role in offering a mapping system service, but for packet routing I'm not sure. DNS-based request routing of CDNs is closer to mapping system functionality than P-ITR functionality that needs packet routing based on BGP routing tables and of course advertising "certain aggregated EID prefixes" into BGP core.

Best regards
Hannu 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Loránd Jakab
>Sent: Tuesday, September 28, 2010 22:01
>To: [email-masked]
>Subject: [lisp] Fwd: New Version Notification 
>fordraft-jakab-lisp-deployment-00
>
>
> FYI.
>
>-------- Original Message --------
>Subject: 	New Version Notification for 
>draft-jakab-lisp-deployment-00
>Date: 	Tue, 28 Sep 2010 11:48:22 -0700 (PDT)
>From: 	IETF I-D Submission Tool <[email-masked]>
>To: 	[email-masked]
>CC: 	[email-masked], [email-masked], 
>[email-masked],
>[email-masked]
>
>
>
>A new version of I-D, draft-jakab-lisp-deployment-00.txt has 
>been successfully submitted by Lorand Jakab and posted to the 
>IETF repository.
>
>Filename:	 draft-jakab-lisp-deployment
>Revision:	 00
>Title:		 LISP Network Element Deployment Considerations
>Creation_date:	 2010-09-28
>WG ID:		 Independent Submission
>Number_of_pages: 16
>
>Abstract:
>This document discusses the different scenarios in which the 
>LISP protocol may be deployed.  Changes or extensions to other 
>protocols needed by some of the scenarios are also highlighted.
>                                                               
>                   
>
>
>The IETF Secretariat.
>
>
>
>_______________________________________________
>lisp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Loránd Jakab <[email-masked]>
Date: Fri, 08 Oct 2010 12:07:58 +0200

Hi Hannu,

Many thanks for the feedback. See my replies inline.

On 10/07/2010 06:28 PM, Flinck, Hannu (NSN - FI/Espoo) wrote:
> I am wondering why do you say in section 3.1.2 that colocating P-ITR with the site's tunnel routers causes the downside of no decrease in global DFZ state? Shouldn't P-ITR announce "certain aggregated EID prefixes" as you write in section 3.1.

Suppose ISP1 has two stub AS clients C1 and C2 which have adjacent old
PI address space (or new EID address space) that can be aggregated.
Additionally, these clients are multihomed, with connectivity from ISP2
as well. Before migrating to LISP, both prefixes are present in the DFZ
with their respective originating ASNs. Suppose both sites migrate LISP,
and ISP1 offers them P-ITR service. Now the P-ITR can announce the
aggregate, with ISP1's ASN, and we have a decrease in DFZ. Both C1 and
C2 are still multihomed and receive traffic from other LISP sites
through either ISP1 or ISP2 depending on their TE policy in the
EID-to-RLOC mappings, but traffic from non-LISP sites has to transit
ISP1, unless ISP2 also deploys P-ITR. It would still enter the client
site on the ISP2 link, but ISP1 may not like the extra traffic, so
especially in the early days of LISP deployment may not have strong
incentives to deploy a P-ITR. This leads us to the solution in Section
3.1.2.

> Then, how is it that colocating the P-ITRs with the xTRs will cause the down side. Or do you suggest that the P-ITRs will start to advertise more specifics of EIDs when colocated? And why would they do that? Shouldn't they announce EIDs at level of the site they are colocated. 

Continuing the previous example, if P-ITRs are deployed at C1 and C2,
the original PI prefixes (or new EID prefixes) have to be announced
separately, resulting in no decrease in the DFZ.

So what I meant is not that they will disaggregate more, rather, they
maintain the status quo.

> Would here the techniques described in section 2.4 be useful, i.e. apply LISP recursively if a packet gets misrouted?  

What do you mean by the packet being misrouted?

> A second thing that strikes me is the emphasis on the role of CDNs. I can see that CDNs might easily take a role in offering a mapping system service, but for packet routing I'm not sure. DNS-based…

Well, my point here was that if a CDN can get enough stub AS clients for
its P-ITR service, which is completely orthogonal to the CDN service,
the chances of prefix aggregation increase. For each CDN there would be
a single (ever decreasing) set of prefixes in the DFZ, announced from
each of the high number of geographically well distributed P-ITRs. The
result is that any non-LISP site trying to reach on of the CDN's LISP
clients would be able to do so with minimum path stretch.

As I mentioned above, this is not actually related with the CDN service
per se. I suggested CDNs, because they already have the necessary
infrastructure (presence and connectivity in many PoPs, except the P-ITR
routers) to get into this business. Any organization that could gain
something from this scenario could do this (e.g., a large web search
provider, with a similarly well distributed infrastructure), but I
singled out CDNs, because they have a head start.

I hope this answers your questions. Do you think more clarifying text
would be needed?

Best regards,
-Lori