[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Comments on draft-lewis-lisp-interworking
|The PTR just encapsulates. The return traffic uses the RLOCs
|LISP site's point of view) which are routable addresses of the non-
If you do that, then the return traffic can't be encapsulated in any
The return traffic isn't encapsulated. The LISP site returns traffic
to the non-LISP site without use of the PTR. The LISP site knows the
destination is a non-LISP site because it's addresses are not in the
That implies that the source addresses seen by the core are non-
EIDs, and you would run into source address filtering issues.
What are source address filtering issues. ACLs? uRPF? Say more.
|I bet an exchange carrier would love to attract traffic.
Relative to other exchanges, certainly. However an exchange would
have to have a way to deliver the attracted traffic. How?
It deploys PTRs. That's how we started this conversation.
|And why does every service provider want Google, Yahoo, MSN,
|EBAY, and MySpace to be their customer?
In the words of peering negotiations, there are content networks and
networks. All of the ones that you list above are content networks,
outbound is much higher than inbound. Eyeball networks are the
where inbound is much higher than outbound (ignoring P2P ;-). Eyeball
networks would like to balance their traffic load, so they want to
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-
traffic (hairpinned). What's the win?
You associated customer traffic with non-LISP traffic. There is
customer traffic that can be LISP sites.
to unsubscribe send a message to firstname.lastname@example.org 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