[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures



Hi Eliot,

> If someone can explain to me how that is possible with APT

Let me take a shot ...

Assume you are allocating some address block /28 for customer from 240 pool. Today you are connected to two ISPs. Mapping entry list two ETRs for your block either your CE or your ISP PE router. When you need to switch one ISP with another all you do is to change the ETR address in the mapping database.

ETR address is a routable address in any of the schemes. Also in any of the schemes you will get it in some way from an upstream ISP if ETR is on CE.

Moreover scale*rate equation is happy ... proposed BGP to provide mapping services while does grow in scale ... goes very well down in rate. ETR addresses need to fast converge not mapping database.

If customer owns ETRs then transit ISPs may not even participate in the mapping business as long as they can route to ETRs.

Cheers,
R.

Hi Robert,

It was good seeing you last month.

The big problem with APT as I understood it from the RRG meeting was
that it was an SP-provided solution, when the SPs are not motivated to
actually fix the problem.  As I mentioned at the RRG, I believe that we
have different understandings of what provider independence is.  To me,
provider independence means that it should be possible to change
providers without permission or even coordination of either the old or
the new.  If someone can explain to me how that is possible with APT, it
wasn't clear at the RRG meeting in December.  As a bonus, it should be
possible to do all of this without adverse impact on the routing system.

Eliot



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