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

[Ross Callon <[e-mail]>]

Dino, I am not sure that you read my earlier email quite the way that I meant to explain the issue. One 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. 

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 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. 

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