You wrote, quoting Stephen Sprunk:
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.
If an end-user network is multihoming with two ETRs in two ISPs - A
and B - and they currently have their mapping set to use ETR A, then
I understand your suggestion is for either ETR A or ETR B to send a
message to the mapping database system to change the mapping,
whenever there is a need to do so.
This would rely on very fast mapping data distribution, as Ivip
proposes to do. Unfortunately, a common cause of failure of ETR A
would be its ISP A being disconnected from the Net, or at least the
ETR itself somehow becoming unreachable. It is not necessarily able
to detect this reliably, instantly (without excessive continual
probing and reliance on devices outside its ISP). Most importantly,
if it is disconnected, it won't be able to send messages.