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

[Xu Xiaohu <xuxh@huawei.com>]

> -----邮件原件-----
> 发件人: owner-rrg@psg.com [mailto:owner-rrg@psg.com] 代表 Robin Whittle
> 发送时间: 2007年12月7日 6:26
> 收件人: 'Routing Research Group list'
> 抄送: Xu Xiaohu; 'Stephen Sprunk'
> 主题: Re: [RRG] Run your own ETRs and ITRs, mobility, local anycast for
Query
> Servers
> 
> 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.
Not "either", but both ETR A and ETR B should send the mapping update
independently.
> 
> 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.
My opinion is the multihoming failure should be dealt with separately. One
case is the EID->RLOC mapping becomes unavailable, ETR should send an update
to the authoritative mapping server to reflect this event; the other case is
that ETR becomes unreachable, the tunneled packet to the ETR will cause an
ICMP unreachable packet to be sent to the tunnel source node(ITR in LISP or
PoP in CRIO). The EID-RLOC mapping with an unreachable RLOC will not be used
anymore.

> 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.
It's too complex. One ITR can reach the special ETR doesn't mean all of the
other ITR can also reach that ETR.

> 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 ITRs should not depend on the mapping information stored in a caching
server. It's hard to assure that mapping is in real-time.

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