[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re: [RRG] Run your own ETRs and ITRs, mobility, local anycast for Query Servers
> > I'd rather run my own ETR(s). Since it's a brain-dead simple
> > function, I expect to see that make its way into even the
> > cheapest CPE. Ideally, I'd set my ETR(s) up with RLOCs from each
> > upstream ISP (perhaps obtained via PPP or DHCP), set the mappings
> > in the database, and be ready to rock. My ISPs wouldn't
> > necessarily even realize I was using one.
It's interesting to allow the ETR to issue the update of EID->RLOC mapping
dynamically, no matter that the ETR is owned either by ISPs or by users. In
this way, the burden on the ITR/mapper to detect the multihoming failure
event can also be reduced. That's to say, the ITR/mapper just need to know
the reachability of the ETR. Of course, the ITR/mapper is required to have
real-time EID-RLOC mapping info.
> I think this is a reasonable basis on which to continue the
> technical development of ITR-ETR schemes. Although a single ITR "of
> last resort" might be able cope with traffic for the one or multiple
> MABs (Mapped Address Blocks) which it handles, this would often
> involve longer paths - so multiple ITRs "of last resort" using
> "anycast" (all advertising the MABs in BGP) is a better option.
I don't think the full-database mapper is a good option. With the EID space
being splitted into more slices, IMO,the distributed mapping/forwarding
mapper is more ideal. PoP in CRIO is a good example. Of course, we can
optimize the CRIO concept further by using anycast mechanism, this is to
say, multiple PoP/mapper will be authoritative for some EID block. In this
way, the query/forwarding burden can be balanced further and the forwarding
path stretch can be shortened.
to unsubscribe send a message to email@example.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