Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP

From: Lixia Zhang <[email-masked]>
Date: Sat, 14 Apr 2007 07:59:02 -0700

From: [email-masked]
Date: April 12, 2007 9:41:23 PM PDT
Cc: "Templin, Fred L" <[email-masked]>,
  [email-masked]
From: Dino Farinacci <[email-masked]>
Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP
Date: Thu, 12 Apr 2007 21:41:21 -0700
To: marcelo bagnulo braun <[email-masked]>

> i have sent this question a while ago that described this exact
> situation, maybe you can describe how LISP deals with this
> situation....

Sure.

> I assume we are using LISP1
>
> Consider that we have a host A in a site a that has EID EIDA (which
> is globally routable in order to be able to bootstrap the initial
> EID-to-RLOC mapping) and RLOCA which is a different address.
> Suppose that site
>
> We have another host B located in a different site b that has a
> another locator RLOCB. Suppose that both site a and site b has
> multiple ISPs (at least two and they have several TR, for fault
> tolerance reasons)

Okay, first off the hosts don't have locators. The locators are
assigned to the ETRs.

> Suppose now that host B initiates a communication with Host A
>
> Host B sends a packet to host A
> The packet contains EIDA as dest add and EIDB as src addr
> The packet is processed by an ITRB1 close to site b
> Since we are in LISP1, the packet is forwarded as it is

No, not true. ITRB1 prepends an IP header to the host's packet. The
outer SA is ITRB1's locator address and the outer DA is the EIDA
(copied from the inner DA). This is only used to trigger a mapping
reply from the ETR that is responsible for the EID range associated
with host A. This happens in both LISP 1.0 and LISP 1.5.

> the packet reaches the ETRA1 close to site a and the ETR sends a
> ICMP packet back to the ITRB1 with the RLOCA information and the
> mapping between EIDA and RLOC is stored in ITRB1.

The source address in the ICMP reply is one of ETRA1's locator
addresses. The ICMP payload that describes the mapping indicates the
*EID-prefix* that ETRA1 is responsible for and a list of all locators
for this range (and their priority and weight values for each
locator). All locators means IP addresses assigned to it or any other
ETR in site A.

We have documented this in the spec.

> Now bad things start :-)

Oh good, the meat.

> First there is a failure and EIDA is no longer reachable
> No problem with that, since ITRB1 has the information about
> alternative locators for host A, it will start sending tunneled
> packets using RLOCA as dest address in the outer header and the
> communication is preserved through this outage.

Ah, no fair, you avoided the real problem. You didn't even try to ask
how does ITRB1 know the ETRA1 is not reachable.  ;-)

We do have answers for them though.  ;-)

> However, now a second bad thing happens, which is that ITRB1 fails
>
> I assume that it is possible in LISP, that an alternative ITR ITRB2
> is used for site B, so packets are rerouted to that backup ITRB1
> for site b.

Yes, of course. There are two ways an ITR determines a locator is not
reachable:

o It receives an ICMP Unreachable message.
o It stops seeing packets it decaps from the EID-prefix range coming
from one of
    the locators in the locator-set.

The later is better and more reliable. And I'm not worrying about
asymmetric paths.

> But the problem is that packets that host b is sending contain EIDA
> as destiantion address which is unfortunatelly unreachable at this
> time. this was not a problem

No, not true. EIDs are always reachable because they are not location
addresses. The only time you can't get packets to EIDA, is when all
locators are not reachable.

> before because ITRB1 had the alternative locator information, but
> it has failed. The backup router ITRB1 does not contain the
> alternative locator information for EIDa (i.e. RLOCA), so how can
> the communication survive this outage?

Yes it does. This is not that hard.

> I mean, i guess that fault tolerance is the key feature and the
> LISP boxes cannot become a single point of failure, so i guess it
> should be possible to survive this type of situations

If you deploy a single ETR, you have a single point of failure. So
you deploy two of them. And if you have two ISP connections, each ETR
has two locator addresses, one from each ISP block. Then when the
mapping is advertised for this site it is done with a single EID-
prefix advertisement with 4 locators.

See the section in the spec for locator selection. It is spec'ed to
be flexible for the ETR to choose what locators the ITR uses, or the
ETR allows the ITR to choose which ones.

Dino

From: [email-masked]
Subject: confirm af86831f93db598d55a443098b7a4569dbaf4b59

If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message.  Do this if the message is
spam.  If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list.  The Approved: header can also appear in the first line
of the body of the reply.

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram