Well we have postulated in many designs that if the use of an RTR is in place, that can help with all sorts of state-based scaling issues. We could have ITRs simply point a default or some /4, or /8 EID-prefixes to a set of RTRs that ARE on path.
So the map-cache can have very coarse entries and get everywhere on the network. Dino On Mar 20, 2013, at 12:02 PM, "Joel M. Halpern" <[email protected]> wrote: > Well, there are regular reports of folks taking down BGP sessions because > they exceed the number of prefixes they can handle. > And LISP EIDs are more granular and varied than BGP prefixes usually are. > So it does seem a reasonable question to ask how we will protect ourselves > against this sort of problem. > > It is true that a device with enough local memory for the whole mapping table > is, by definition, not subject to this kind of attack. But it seems doubtful > that we can expect most ITRs or ETRs to have that much memory. > > One of my concerns with the categorization is that the various practices > needed to counter different threats are not inherently consistent. or are > they always generally applicable. (Some of them are just plain good advice. > Some of them are good advice for internet deployment. Some are good advice > for VPN deployments.) So will the reader be able to tell whether he is at > risk for a given attack, and what he should be doing for his problem space > while still keeping an effective and operable LISP infrastructure? > > Yours, > Joel > > On 3/20/2013 2:55 PM, Dino Farinacci wrote: >>>> From: Ronald Bonica <[email protected]> >>> >>>> 3) query the map cache for each packet. If no entry exists, discard the >>>> packet and query the map server >>> >>>> If you choose Option 3, won't the victim ETR map cache overflow? >>> >>> We've been over this ground about 18 times, haven't we? >>> >>> Answer #5: Don't have a fixed-sized cache. Then it cannot overflow. >> >> Yep, you are right Noel. >> >> Just like the BGP RIB does not have a fixed-size cache. So what happens when >> there is no memory for BGP, ditto for LISP. There is no magic here folks. >> >> Dino >> >>> >>> Noel >>> _______________________________________________ >>> lisp mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp >> _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
