Subject: [lisp] The case for Map-Updates

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 21 Jan 2009 22:08:49 +0100

In the current LISP specification, two mapping messages are defined :

- Map-Request that allows to request the set of RLOCs corresponding to a
given EID
- Map-Reply that provides the mapping between an EID block and a set of
RLOCs

These two messages basically assume that the mapping database is built
by means that are outside of the LISP protocols (e.g. manual
configuration). I think that we should add a third message to add or
update entries in the mapping databases :

- Map-Update : this message is used when an entity needs to add a new
mapping in the database or update an existing entry in the mapping
database. There should, of course, be a way to authenticate the sender
of the mapping update

These Map-Update messages would be useful in different scenarios :
- an xTR needs to change its RLOC
- an xTR is being shutdown or will be shutdown in some time and need to
force a removal of the corresponding mapping entry
- load-balanced xTR are overloaded and their weight needs to be updated
- ...

I think that there would be other usages of such Map-Update messages.

Olivier

-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium
_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 21 Jan 2009 23:03:22 -0800

> database. There should, of course, be a way to authenticate the sender

The mapping database are distributed. It is not centralized. When a  
site becomes a LISP site, the new EID-to-RLOC mapping is configured in  
the ETRs that reside at the site.

So I don't know who would send the Map-Update and who would receive it.

If this model changes because there is a different mapping database  
employed, then the message can be introduced at that time.

> - an xTR needs to change its RLOC

We have Solicit-Map-Requests that do that.

> force a removal of the corresponding mapping entry

Today, the xTR can just go away. In fact, mappings that are cached by  
remote ITRs need to stay in tack because there are other xTRs at the  
site which are being used. The loc-reach-bit for the xTR coming out of  
service can be set to 0 immediately until the time an SMR is sent to  
remove the RLOC from the mapping.

> - load-balanced xTR are overloaded and their weight needs to be  

SMRs do this too. Or you can source-quench the source by advertising  
the RLOC as unreachable for a short period of time. There are already  
simple mechanisms in place that seem to work well.

Dino

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 22 Jan 2009 21:57:12 +0100

> The mapping database are distributed. It is not centralized. When a site
> becomes a LISP site, the new EID-to-RLOC mapping is configured in the
> ETRs that reside at the site.
>

I see two possible scenarios.

1- The mapping server does not reside on the ETR that serves the EID
(e.g. this is a redundant mapping server)

2- In a LISP site served by several ETRs, these ETRs will need to
exchange information so that they all maintain the same EID-to-RLOC
mapping for the local EID. When something changes in the mapping (e.g.
new RLOC, different weigth or different preferences), it should be
possible to dynamically inform all the mapping servers that are
responsible for this mapping.

> employed, then the message can be introduced at that time.

It would also be useful for different mapping systems than ALT.

> We have Solicit-Map-Requests that do that.

SMR allows to sollicit a new map request, it does not allow an xTR to
update the mapping on the other mapping servers that are responsible for
the same EID.

> remove the RLOC from the mapping.

The other xTRs of the site need to be informed about the shutdown of the
local xTR. If this is a sudden shutdown, they will be informed by e.g.
the IGP protocol, but if this is a planned shutdown, then it is useful
to inform the other xTRs and mapping servers in advance.

> SMRs do this too. Or you can source-quench the source by advertising the
> RLOC as unreachable for a short period of time. There are already simple
> mechanisms in place that seem to work well.

SMRs allow to sollicit a new Map-request, but this Map-Request will be
received by any of the mapping servers (e.g. xTR) that serve the site.
These mapping servers need to be coherent and advertise the same
EID-to-RLOC mappings.

Olivier

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 22 Jan 2009 22:16:42 -0800

> update the mapping on the other mapping servers that are responsible  

The point of soliciting a map-request is so you can return a map-reply  
with updated information. The way it works is like this:

o I am an ETR with a mapping change.
o I solicit at the rate I want to receive requests by setting the SMR- 
bit for the active sites
   I am talking to. Because those sites will need the new information  
sooner than the ones not
   talking to me.
o You are a site that is talking to me so I ask you to send me a Map- 
Request.
o You then send me a Map-Request and I return a Map-Reply.
o I remember I sent you the updated mapping data so the loc-reach-bits  
I send you reflect the
   new mapping.

That's all there is to it.

> to inform the other xTRs and mapping servers in advance.

They are all configured at the same time.

> These mapping servers need to be coherent and advertise the same

Right, but the xTR that is old will have loc-reach-bits relative to  
the locator-set it is sending.

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 23 Jan 2009 18:09:47 +0100

Dino Farinacci wrote:
> o I solicit at the rate I want to receive requests by setting the
> SMR-bit for the active sites
This implies that you have bidirectional traffic. What happens in the
case of unidirectional traffic? (at leats from that ETR perspective)

> o You are a site that is talking to me so I ask you to send me a
> Map-Request.
So the ETR has to remember the ITR talking to him that have already been
updated?

>>> the
Does this old mapping match with the new one on the ETR?

Luigi

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 24 Jan 2009 09:28:00 -0800

> Dino,

Well the SMR-bit is in both a data packet and a Map-Request. So if  
there is unidirectional traffic from a site that needs to be updated,  
the site that has the mapping change sends a Map-Request to one or  
more of the remote xTRs.

> So the ETR has to remember the ITR talking to him that have already  

Right. But look at the failure cases, and let's see how bad it is. If  
you mis-set the loc-reach-bits you are basically saying that some  
xTRs, which are up, you are erroneously reporting them as down. That,  
in and of itself is not that bad, because the ITRs at the remote sites  
can just choose another RLOC in the locator-set. This would only occur  
for a short period of time (i.e. the rate-limit time and propagation  
delay). And in the case where the xTR is reporting an RLOC up when in  
fact it is down suffers packet loss for that short period of time.

Remember, an ITR can switch to another RLOC in the locator-set  
anytime, as long as it's within the set of high-priority RLOCs so it  
can adhere to the policy of the destination site. An ITR can switch  
when it sees no packets from an alleged down RLOC.

I realize that in unidirectional traffic this might not be the case.  
But there are few cases where a site has absolutely no return traffic  
of any kind from any host at the site.

> Does this old mapping match with the new one on the ETR?

Umm, I don't quite understand the references. Can you restate?

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 26 Jan 2009 10:53:13 +0100

Dino,

comments inline

> the site that has the mapping change sends a Map-Request to one or
Ok, Map-Request, can be used to announce an update. With a Map-Update
message you will just save a Map-Reply message.

The question that comes to my mind now is how the ETR can understand
that the the ITR has an old mapping hence a Map-Request needs to be sent?

A simple solution would be to send a Map-Request+SMR to all ITRs you are
receiving  unidirectional traffic from.

> fact it is down suffers packet loss for that short period of time.
Yes. But what if the source of the packet with the mis-set
loc-reach-bits is an attacker? What if this attacker continously sends
packets with wrong loc-reach-bits?

My point here is that loc-reach-bits should not be trusted, but used as
an hint and confirmed by Map-Request/Map-Reply exchange.
Only if the updated mapping confirms the change in reachability, then
the traffic is shifted to different rlocs.

> of any kind from any host at the site.
You are right on the fact that host-to-host unidirectional traffic is
rare, but unidirectional flows are more common. There are several
protocols, typically for monitoring, that are "fire-and-forget". In the
inter-domain case it is not so uncommon to have asymmetric paths, which
means unidirectional flows.

[snip]
> Umm, I don't quite understand the references. Can you restate?
Sorry for that, I agree I was unclear ;-)

I was just stating that if it is an xTR with an old mapping that is
replying to the Map-Request, it will probably have a different set for
the loc-reach-bits. With this different setting for the loc-rech-bit you
can experience traffic disruption, at least for short periods.

However, this is more an issue related to the mapping system that needs
to guarantee as much as possible the coherence of
mappings  on the xTRs.

Thanks

Luigi

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 26 Jan 2009 12:02:34 -0800

> the traffic is shifted to different rlocs.

Yes, they are a hint.

Dino