Re: [lisp] WG Last Call draft-ietf-lisp-impact-01

[Dino Farinacci <[e-mail]>]

> Dino;
> 
> One point from your first email yesterday that I think might be worth making (although this might be partially OBE by more recent emails). 
> 
>> What ISPs want more than anything else is balanced load. And if they
>> have to vary from that point, they go more granular. And that usually
>> means by source or 5-tuple hashing in the data-plane.
> 
> I agree that a very common approach for balancing load involves hashing on the well known 5-tuple (source and destination IP addresses, etc...) to allow load splitting across multiple paths (plus techniques for setting up the multiple paths). This is fairly well known. However, this does not require announcing "more specific" addresses into BGP (nor into the LISP cache). As such it doesn't relate to the issue of whether or not the more specific addresses that are currently advertised into BGP will need to also correspond to separate entries in a LISP cache. 

Right, agree. I was referring to how ISPs load-split traffic. It is a combination of control-plane (the specifity of route advertisements) and data-plane (5-tuple hash to select one of many ECMP paths).

> The reason that I was mentioning the less common, but still sometimes used approach of announcing more specific addresses into BGP in order to have traffic arrive at your network "closer" to the ultimate destination, is specifically because this *is* a reason for announcing more specific addresses in to BGP. I have heard this approach referred to as "cold potato" routing (since it tries to get the previous network operator along a path to hold onto the packet longer). 

Right. With LISP you can do cold or hot potato with the same length prefix given to ITRs in different source sites. That can’t be done with a push protocol unless you do (source, dest) routing which kinda blows up the size of the RIB.

> Nonetheless, this is probably more easily discussed with a white board in front of us (and perhaps also a beer ;-).  

Definitely. Count on it.

Dino

> 
> Ross
> 
> -----Original Message-----
> From: Dino Farinacci [mailto:[e-mail]] 
> Sent: Monday, April 13, 2015 3:58 PM
> To: Ross Callon
> Cc: Darrel Lewis; LISP mailing list list; [e-mail]
> Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01
> 
>> Dino, I am not sure that you read my earlier email quite the way that I meant to explain the issue. One 
> 
> Well I read the words you wrote.  ;-)
> 
>> reason for more specifics being advertised is that some ISPs don't want incoming traffic split by source, but rather by destination. Probably to agree on how this would work with LISP we need to sit down in person and discuss this with white boards and pictures. 
> 
> What ISPs want more than anything else is balanced load. And if they have to vary from that point, they go more granular. And that usually means by source or 5-tuple hashing in the data-plane.
> 
>> To me it seems like there are two ways forward here: One option is to go with what Joel suggested earlier, and add to the document something along the lines that the scaling numbers are disputed and we don't actually know how it scales. The other option would be for at least the two of us to sit down in 
> 
> I agree. 
> 
> We don’t know how ANYTHING scales until it gets there. Where “there” is some point. Is BGP scaling? So this will always come down to subjective opinion and perspective from different points of view.
> 
>> person as soon as we get a chance (no later than Prague, hopefully earlier if either of us gets a trip to the other's neck of the woods). I don't currently have any trips planned to California, but could let you know if I do and try to plan to stay an extra day to go over this. 
> 
> We should do that in any case, but we shouldn’t block or slow down the process. We can do this in Prague but go with Joel’s suggestion for now.
> 
> Dino
> 
>> 
>> Thanks, Ross
>> 
>> -----Original Message-----
>> From: Dino Farinacci [mailto:[e-mail]] 
>> Sent: Friday, April 10, 2015 2:16 AM
>> To: Ross Callon
>> Cc: Darrel Lewis; LISP mailing list list; [e-mail]
>> Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01
>> 
>>> However, there is a reason that some more specific prefixes are advertised (in addition to a covering less specific prefix). One reason is that some service providers want incoming traffic delivered to them via different interconnects based on the destination. Even if you are doing traffic
>> 
>> Right but if you want that with LISP you can return a coarse prefix in a Map-Reply with different priority values to different ITRs. It doesn't require for more-specifics. 
>> 
>>> engineering with LISP, then this reason doesn't go away, and isn't solved by sending only the less specific prefix in the map reply. Of course there are other
>> 
>> Yes it is solved. With a push protocol to instruct traffic to come one way or the other is only done with multiple prefixes where with LISP it can be done with the same prefix but is tailored on a per source or request basis. 
>> 
>>> reasons to advertise more specific prefixes, and on the most part these don't go away either. I therefore feel that it was an error for the study discussed in [CCD12] to "... filter out more specific prefixes".
>> 
>> It doesn't follow at all to me. 
>> 
>> Dino
>