>> ...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:[email protected]] > Sent: Monday, April 13, 2015 3:58 PM > To: Ross Callon > Cc: Darrel Lewis; LISP mailing list list; > [email protected] > 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:[email protected]] >> Sent: Friday, April 10, 2015 2:16 AM >> To: Ross Callon >> Cc: Darrel Lewis; LISP mailing list list; >> [email protected] >> 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 > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
