Hi, On 09/01/2013 12:04, Luigi Iannone wrote: > Hi, > > On 8 Jan. 2013, at 11:34 , SM <[email protected]> wrote:
... >> I suggest dropping the idea of calling it a very large-scale experiment. >> The unstated problem is about politics. I suggest taking a look at >> draft-lear-lisp-nerd-09. It contains a good discussion of operational >> models and the trade-offs. However, it isn't (even) a LISP WG Experimental document. I think the interesting operational questions are those raised or implied by http://tools.ietf.org/html/draft-ietf-lisp-interworking-06#section-5 > Thanks a lot, will do. What I would like to see discussed in -eid-block is how the use of the proposed prefix interacts with the scaling properties and routing policies associated with Proxy ITRs. The above citation includes: 1. The Proxy-ITR's aggregate routes might be selectively announced, giving a coarse way to control the quantity of traffic attracted by that Proxy-ITR. For example, some of the routes being announced might be tagged with a BGP community and their scope of announcement limited by the routing policy of the provider. 2. The same address might be announced by multiple Proxy-ITRs in order to share the traffic using IP Anycast. The asymmetric nature of traffic flows through the Proxy-ITR means that operationally, deploying a set of Proxy-ITRs would be very similar to existing Anycasted services like DNS caches. Will having a reserved EID prefix change these "might bes"? Will it change the incentives for BGP ASes to do the right thing? As was said earlier, we have *bad* experience on this point with 2002::/16, where the evidence is that operators simply didn't do what the deployment model called for. Just to be clear, here is the paragraph from RFC 3056 that operators failed on: 3. A relay router MUST advertise a route to 2002::/16 into the native IPv6 exterior routing domain. It is a matter of routing policy how far this routing advertisement of 2002::/16 is propagated in the native IPv6 routing system. Since there will in general be multiple relay routers advertising it, network operators will require to filter it in a managed way. Incorrect policy in this area will lead to potential unreachability or to perverse traffic patterns. You could pretty much use that paragraph for LISP ITRs. Why will it work any better than it did for 6to4? To be clear - we aren't talking about operators of ITRs. We're talking about BGP speakers many hops away from the ITRs. Brian _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
