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

[Dino Farinacci <[e-mail]>]

>> ...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.
> 
> Makes sense. I think that Florin's email hints at a very small edit to Joel's suggestion, which I will mention in reply to his email. 

Ack Ross. Thanks.

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
>