[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
|(from the
|LISP site's point of view) which are routable addresses of the non-
|LISP site.
If you do that, then the return traffic can't be encapsulated in any way.
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 mapping database.
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.


|I bet an exchange carrier would love to attract traffic.
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.


|And why does every service provider want Google, Yahoo, MSN,
|Facebook,
|EBAY, and MySpace to be their customer?
In the words of peering negotiations, there are content networks and eyeball networks. All of the ones that you list above are content networks, where outbound is much higher than inbound. Eyeball networks are the reverse, 
where inbound is much higher than outbound (ignoring P2P ;-).  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. 

Dino



--
to unsubscribe send a message to rrg-request@psg.com 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