> > 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. Best wishes, Xiaohu XU -- 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
