|> That implies that the source addresses seen by the core are non- |> routable |> EIDs, and you would run into source address filtering issues. | |What are source address filtering issues. ACLs? uRPF? Say more.
uRPF is one example of an implementation of this type of sanity checking. You can also do it via ACLs. The concept is the same either way. If you generalize things, I think that you want to position the PTR functionality so that the PTR is nothing more than a giant ITR/ETR that LISP sites would use by 'default'. Conceptually you've worked out how to get one LISP site to talk to another. PTRs are one way of simply turning the entire rest of the Internet into a single giant LISP site. |> Relative to other exchanges, certainly. However an exchange would |> still |> have to have a way to deliver the attracted traffic. How? | |It deploys PTRs. That's how we started this conversation. Sorry, I was unclear. The exchange site still would have to deliver the traffic via some transit provider. While the exchange might want more traffic (relative to other exchanges), I'm not seeing the benefits to the transit providers. Again, hairpinning traffic doesn't seem like a win to anyone. |> Eyeball |> networks would like to balance their traffic load, so they want to |> attract |> content. | |And if they deploy LISP they can. That is the appeal of |deploying LISP |at the site. | |> PTRs are neutral: they attract customer traffic (not new) or non- |> customer |> traffic (hairpinned). What's the win? | |You associated customer traffic with non-LISP traffic. There is |customer traffic that can be LISP sites. Irrelevant to the ISP. The customer traffic is coming to the ISP regardless. Tony -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
