re: [RRG] Run your own ETRs and ITRs, mobility, local anycast for Query Servers

[Xu Xiaohu <xuxh@huawei.com>]

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