RE: [RRG] Comments on draft-lewis-lisp-interworking

["Tony Li" <tony.li@tony.li>]

|> 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 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