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