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

["Darrel Lewis (darlewis)" <darlewis@cisco.com>]

> 
> Have you thought more about this now, and can you say 
> something about it on the list?
> 
> Jari
> 
> 

The discussion about this has been good, but I think there are a couple
of points here that I want to clarify.  The gist of this discussion will
also be included in the 01 rev of the draft.  Thanks Jari for spurring
this discussion - your feedback that started all of this.

To summarize:

1) Large providers who are running a default free core will want to
attract traffic from their customers.  This is how they sell upgrades to
their customer links.  

2) Smaller providers who may not have full peering to enable a default
free core and therefore buy transit will want to avoid using that
transit link.  By deploying a PTR they route on RLOCs and if the RLOC is
reachable over a peering link they can avoid paying transit prices for
that traffic.

3) In both cases there is further benefit for deploying PTRs, that is
that post encapsulation you route towards RLOCs, so you can hot-potato
the traffic off your network.  That means that you would probably see
providers installing PTRs in every PoP.

4) There are some other (minor?) benefits along the lines of traffic
analysis and evaluation of traffic, as well as a controlling traffic.

Finally, lets remember exactly what a PTR is, it's an interface on a
router.  It just encapsulates, and many of the existing (and in
development) hardware out there will be able to perform this function.
So the opex cost of deployment is limited to configuration and
announcement of the route, and dedicating an interface(s) (possibly per
PoP) to handle the traffic.

Hope that helps give some more clarity to our ideas.  Feedback, as
always, welcome. 

-Darrel






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