Subject: Re: [lisp] EID Address space

From: [email-masked] (Noel Chiappa)
Date: Mon, 23 May 2011 12:54:09 -0400 (EDT)

> From: Yakov Rekhter <[email-masked]>

    > How does this impact the need to advertise this prefix into *the DFZ* ?

Are you trying to say 'using LISP in this case does not decrease the size of
the DFZ routing table', or something like that? If so, please say so directly
(so it's clear to everyone what the issue is).

	Noel

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 23 May 2011 10:15:45 -0700

If a large site can procure short PI IPv6 prefixes
from an Internet registry, and then announce the
prefixes into the native IPv6 Internet routing
system on its own behalf, why would the site use
LISP instead of just using native IPv6?

Asked another way, is LISP only for small/medium
sized sites that cannot announce their PI IPv6
prefixes into the IPv6 Internet routing system
on their own behalf?

Fred
[email-masked]

---

From: Darrel Lewis <[email-masked]>
Date: Mon, 23 May 2011 10:56:29 -0700

> LISP instead of just using native IPv6?

LISP may provide other benefits to sites aside from simplified inter-AS Traffic Engineering (multi-homing).  A large connected site already using BGP may use LISP for some sites or for internal (non-internet) networking.  LISP is a fairly simple and flexible tool in that regard.

But when combined with per-source EID policy, I think LISP can actually provide finer grained control over ingress traffic policies than BGP, about the same level of flexibility of DNS based load balancing, using the routing system.

As an example of other benefits, Facebook found some value in Address Family traversal doing IPv6 (EID) over IPv4 (RLOC).

> prefixes into the IPv6 Internet routing system

No, its not only for them. 

-Darrel

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 23 May 2011 11:09:11 -0700

Hi Darrel, 

> -----Original Message-----
> From: Darrel Lewis [mailto:[email-masked]] 
> Sent: Monday, May 23, 2011 10:56 AM
> To: Templin, Fred L
> Cc: Darrel Lewis; [email-masked]
> Subject: Re: [lisp] LISP and IPv6
> 
> 
> LISP may provide other benefits to sites aside from 
> simplified inter-AS Traffic Engineering (multi-homing).  A 
> large connected site already using BGP may use LISP for some 
> sites or for internal (non-internet) networking.  LISP is a 
> fairly simple and flexible tool in that regard.

The multi-homed site (such as a major enterprise network)
could also advertise more-specific IPv6 prefixes into the
public IPv6 Internet routing system if it wanted to steer
incoming traffic into the site via specific BGP routers.
Also, once the traffic is inside the site the site can
do traffic engineering internally.

> But when combined with per-source EID policy, I think LISP 
> can actually provide finer grained control over ingress 
> traffic policies than BGP, about the same level of 
> flexibility of DNS based load balancing, using the routing system.

You are still paying the price for encapsulation.
Encapsulation is necessary for some functions such
as security and tunneling over unlike IP protocol
versions. It can also be helpful for certain functions
like traffic engineering, but there are tradeoffs wrt
the encapsulation overhead.
 
> As an example of other benefits, Facebook found some value in 
> Address Family traversal doing IPv6 (EID) over IPv4 (RLOC).

There are other (published) systems they could be
using for that purpose.

Fred

---

From: Darrel Lewis <[email-masked]>
Date: Mon, 23 May 2011 11:23:54 -0700

> do traffic engineering internally.

Yes fred, I've been injecting more specifics in IPv4 for ingress TE since 1991, and playing with BGP nobs since 1993.  And IPv6 doesn't change anything with regards to routing.

But those BGP nobs frankly arn't as powerful as LISP's TE tools:

 o LISP has priorities so I can easily have multiple layers of active/standby
	(2 links could be Priority 10, 3 others at priority 20)
 o LISP has weights so i don't have to chose between all or nothing
   for a given priority...
	(those 2 priority 10 links can load share 60/40 lets say)
 o LISP performs these operations PER requesting site,
   so policies can be tailored to provide different responses
   for different requesters.
	(so a site on the east coast US could get a different
         mapping than a site on the west coast).

> the encapsulation overhead.

I believe someone famous said there is no free lunch.  Some people find the value worth the cost, some don't.  You seem to be saying you are one of the latter.  I have no problem with you stating your opinion, though I admit to being puzzled about your motivations.  After all, this is why we have LISP-Interworking, since not every site on the internet is expected to implement LISP.

> There are other (published) systems they could be

They looked at their options, and decided on trying LISP, why is that so wrong?  All engineering choices involved trade-offs.  I'm not sure I am getting the point of your statement above.

-Darrel

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 23 May 2011 11:34:09 -0700

Noel,

> (so it's clear to everyone what the issue is).

Thanks for saying this for me !

Yakov.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 23 May 2011 11:43:26 -0700

LISP can decrease the core's routing table size.

LISP can slow the increase of the core's routing table size.

Dino

On May 23, 2011, at 11:34 AM, Yakov Rekhter wrote:

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 23 May 2011 12:02:11 -0700

Hi Darrel, 

> Sent: Monday, May 23, 2011 11:24 AM
> To: Templin, Fred L
> Yes fred, I've been injecting more specifics in IPv4 for 
> ingress TE since 1991, and playing with BGP nobs since 1993.  
> And IPv6 doesn't change anything with regards to routing.

Noe one is calling into question your experience or
longevity in your career.

>          mapping than a site on the west coast).

This view of inbound traffic engineering seems to favor
letting packets bounce around in the public Internet a
bit longer in some cases, while the native IPv6 approach
favors getting the packets into the site asap via the
shortest path. Any links and paths that are outside of
the site are beyond the site's control, so just letting
packets bounce around out there might not always be the
best option.
 
> I believe someone famous said there is no free lunch.  Some 
> people find the value worth the cost, some don't.  You seem 
> to be saying you are one of the latter.  I have no problem 
> with you stating your opinion, though I admit to being 
> puzzled about your motivations.  After all, this is why we 
> have LISP-Interworking, since not every site on the internet 
> is expected to implement LISP.

Don't get me wrong; I am all about tunneling and always
have been. Tunneling within the site and native outside
of the site when possible is what I am saying. Maybe
the inbound traffic engineering is a reason to consider
looking outside of the site, however. I'd be happy to
be surprised if it could be shown to be an advantage
in all cases. 

> They looked at their options, and decided on trying LISP, why 
> is that so wrong?  All engineering choices involved 
> trade-offs.  I'm not sure I am getting the point of your 
> statement above.

I didn't say its wrong. Tunneling IPv6 over IPv4 networks
is the only alternative when there is no other choice.

Fred