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

[Robin Whittle <rw@firstpr.com.au>]

Hello Xiaohu,

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.

ETR B may not be in a position to ascertain what has happened to ETR
A, so it cannot be relied upon as the source of new mapping information.

The non-Ivip ITR-ETR schemes build all the capabilities of
multihoming service restoration decision making into the ITRs and
the mapping data.

Ivip leaves the decisions to any system run or authorised by the
end-user.  In general, the best way to achieve this would be for the
end-user to hire the services of a specialist company which uses
continual challenge-response probes via its two or more ETRs to some
device in its own network, to determine reachability of the ETRs
from multiple points in the wider network.  Then, with whatever
logic the operator and/or the end-user desires, that system can
issue (with appropriate crypto credentials) the mapping changes
which are best able to restore traffic to the site.

Quoting me, you wrote:

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

Ivip's provides full database ITRs (ITRDs) and Query Servers QSDs,
with standalone caching ITRs (ITRCs) and caching ITR functions built
into hosts (not behind NAT - ITFH).  There are also caching Query
Servers (QSCs).  There is plenty of flexibility in placement of
these so that the costs of running full database devices are only
incurred to the point that it makes sense.

The idea is that there is one or more full database Query Servers
not too far away.  This is completely different from LISP-CONS,
LISP-ALT or TRRP - all of which involve a distributed set of Query
Servers, with the query having to go to an authoritative one - with
the closest authoritative Query Server quite possibly being located
on the other side of the planet.

  - Robin           http://www.firstpr.com.au/ivip/



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