Guys, if you want to throw around solutions and brainstorm on the list, you need to be open minded. We are not proposing anything, we are discussing pros and cons of possible ways to solve problem. Do not take this as "how LISP solves the problem". We have lots of options, but understand how they cannot be perfect.
Hence, why they are not documented right now. Dino On Jul 25, 2011, at 1:56 PM, Jeff Wheeler wrote: > On Mon, Jul 25, 2011 at 4:40 PM, Noel Chiappa <[email protected]> > wrote: >> I'm not so sure - a small/medium size site might have two ITRs (or a small >> number of them), and in those cases responsbility for covering the address >> space could be divided between them, but many smaller sites will only have >> one >> (their exit router). > > I agree. However, if the solution for ITR cache churn is to "Hail > Mary" the packets up to the native Internet (assuming native > connectivity for that Address Family is even available) then these > packets must find their way to an xTR that can handle the traffic, or > they will be dropped. This must be the very powerful router (or > cluster) that some have mentioned -- but you have to be able to build > and sell it at practical size, power/heat properties, and price. > > So saying this traffic can simply be forwarded natively and handled by > a PITR is not a solution unless there are practical PITRs with enough > capacity. The fundamental problem of data-plane/FIB scaling remains > the same. In addition, if there were no IPv6 connectivity available > to the ITR, it could not do native forwarding with hopes of reaching a > PITR. It's a good thing IPv6 will probably be deployed everywhere > long before LISP is a practical concern, but this exemplifies the fact > that the current design of LISP may not be able to live up to its > promise of an all-purpose encapsulation scheme able to carry any > protocol within the outer-headers, without native support for that > protocol/AF to the site. > > -- > Jeff S Wheeler <[email protected]> > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
