Subject: [lisp] Membership test draft

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 2 Mar 2010 10:58:14 +0200

Hello 

I have submitted a proposal for improving the map resolution gain. The
idea behind the draft is that in the Map -reply message the ETR tells
more than just the requested mapping information about the mappings that
it is hosting. The information is compressed in a form of membership
test which we see very powerful tool for this specific use case. The use
of membership test is at its best when an ETR is hosting EIDs that do
not aggregate under a prefix. 

Please have a look at the draft and tell me what do you thing? Would
this be something to be worked as part of the base LISP protocol? This
is not tied to any mapping system architecture at all, so it could be
possibly part of the base line if so considered. 

http://tools.ietf.org/html/draft-flinck-lisp-membertest-00

Best regards
Hannu

------------------

A new version of I-D, draft-flinck-lisp-membertest-00.txt has been
successfuly submitted by Hannu Flinck and posted to the IETF repository.

Filename:	 draft-flinck-lisp-membertest
Revision:	 00
Title:		 Membership test for Mapping Information optimization
Creation_date:	 2010-03-01
WG ID:		 Independent Submission
Number_of_pages: 12

Abstract:
This document defines how a membership test can be used to convey all or
some of the EID-to-RLOC mappings from an Egress Tunnel Router to
requesting Ingress Tunnel Router.  This draft proposes that an
authoritative ETR MAY return a group membership test in the LISP Map-
Reply Message that indicates if a given EID is served by the ETR.
The membership test is implemented as a Bloom filter.  A Bloom filter is
compact data structure to represent a set of elements.  The membership
test "aggregates" EIDs beyond prefix based aggregation.
Membership test decreases the load of the mapping system and distributes
the EID-to-RLOC resolution between an ITR and an ETR.

The IETF Secretariat.

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 2 Mar 2010 12:04:35 -0700

Hi Hannu,

I am reading your draft and have two questions please:

- If I understand correctly your proposal, when an ITR hits a false positive then it should remove the entire membership test which is associated to it. Am I correct? 

- You mention in page 8 that the ETR should remove the previously sent Membership test from the ITR... or by providing a new membership test.
I am confused as to why the new membership test would be different than the previous one since this is false positive. Can you please clarify?

Regards,

Wassim H.

On Mar 2, 2010, at 1:58 AM, Flinck, Hannu (NSN - FI/Espoo) wrote:

> Hello
> 
> I have submitted a proposal for improving the map resolution gain. The idea behind the draft is that in the Map -reply message the ETR tells more than just the requested mapping information about the mappings that it is hosting. The information is compressed in a form of membership test which we see very powerful tool for this specific use case. The use of membership test is at its best when an ETR is hosting EIDs that do not aggregate under a prefix.
> 
> Please have a look at the draft and tell me what do you thing? Would this be something to be worked as part of the base LISP protocol? This is not tied to any mapping system architecture at all, so it could be possibly part of the base line if so considered.
> 
> A new version of I-D, draft-flinck-lisp-membertest-00.txt has been successfuly submitted by Hannu Flinck and posted to the IETF repository.
> 
> This document defines how a membership test can be used to convey all or some of the EID-to-RLOC mappings from an Egress Tunnel Router to requesting Ingress Tunnel Router.  This draft proposes that an authoritative ETR MAY return a group membership test in the LISP Map- Reply Message that indicates if a given EID is served by the ETR.
> 
> The membership test is implemented as a Bloom filter.  A Bloom filter is compact data structure to represent a set of elements.  The membership test "aggregates" EIDs beyond prefix based aggregation.
> 
> Membership test decreases the load of the mapping system and distributes the EID-to-RLOC resolution between an ITR and an ETR.
> 
>                                                                                   
> 
> The IETF Secretariat.
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

Regards,

Wassim H.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 02 Mar 2010 14:19:16 -0500

[Commenting as an individual contributor.]
Having looked at at this draft, and having recently been prompted by 
other work to look at bloom filters, I am somewhat confused.

First, there seems to be an assumption that if an EID request to an ETR 
from an ITR matches one EID block that the ETR serves, that there is 
likely to be traffic to that ITR for other EIDs served by that ETR.  If 
one assumes cache space, and control message space, are of value, I do 
not see this as likely.

Secondly, and more importantly, as I understand it bloom filters are 
very good at selecting for exact matches.  However, in general with 
LISP, the EID blocks served by an ETR are a range (prefix) not a full 
length EID.  As such, I do not see how that can give rise to a useful 
bloom filter.  (For use in prefix based routing, the actual suggestion I 
saw was to have a separate filter for every prefix length.  That worked 
because it also assumed hardware support.)

In general, bloom filters are efficient to check in suitable hardware. 
Having to do N hash operations and N bit test operations is not a 
particularly friendly operation in software.

Yours,
Joel

Flinck, Hannu (NSN - FI/Espoo) wrote:
> <http://tools.ietf.org/html/draft-flinck-lisp-membertest-00>
> 
> 
> Best regards
> Hannu
> 
> ------------------
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 3 Mar 2010 08:56:12 +0200

Hello Wassim

This is a good question an requires clarification. 

In general, removing a failed membership test is the simplest and best
error handling case. However, it could be so that the destination EID
was originally part of the calculated Membership test but has now moved
away, or shutdown, or the reachability has disappeared. In those cases
ETR may have more accurate (recent) membership test and could tell that
to the ITR while removing the previous one. Even in this case the ITR
must revert to the map resolution process.

There is also an other case where new membership test could make sense.
This adds to complexity of error handling and therefore I do not think
it should be included to the procedure without thorough experimentation.
But for the shake of completeness I am mentioning it, with the risk of
begging more questions. Anyway, the false positive rate depends on the
number of hashes, size of the test vector and the inserted entries. To
get a more accurate membership test, ETR may choose to inset less
entries to the new membership test. In fact the calculation of the test
could be constructed in blocks. For example: (hash of 70 EIDs) OR (hash
of 70 EIDs) = has of 140 EIDs. Now with this the ETR knows which part of
the membership test failed based on the destination EID and could send
that block that is not causing the problem. This is only an idea, which
I would not yet to recommend.

I hope I answered your question, but I see that I also implanted seeds
of new confusion with the last part of the answer. As I final remark,
false positive are rear so having a complicated error handling for an
event occurring 10^-6 probability may not be worth it. 

Best regards
Hannu  

>-----Original Message-----
>From: ext Wassim Haddad [mailto:[email-masked]] 
>Sent: Tuesday, March 02, 2010 21:05
>To: Flinck, Hannu (NSN - FI/Espoo)
>Cc: Wassim Haddad; [email-masked]
>Subject: Re: [lisp] Membership test draft
>
>Hi Hannu,
>
>- If I understand correctly your proposal, when an ITR hits a 
>false positive then it should remove the entire membership 
>test which is associated to it. Am I correct? 
>
>- You mention in page 8 that the ETR should remove the 
>previously sent Membership test from the ITR... or by 
>providing a new membership test.
>I am confused as to why the new membership test would be 
>different than the previous one since this is false positive. 
>Can you please clarify?
>
>
>Regards,
>
>Wassim H.
>
>
>> I have submitted a proposal for improving the map resolution 
>gain. The idea behind the draft is that in the Map -reply 
>message the ETR tells more than just the requested mapping 
>information about the mappings that it is hosting. The 
>information is compressed in a form of membership test which 
>we see very powerful tool for this specific use case. The use 
>of membership test is at its best when an ETR is hosting EIDs 
>that do not aggregate under a prefix.
>> 
>> Please have a look at the draft and tell me what do you 
>thing? Would this be something to be worked as part of the 
>base LISP protocol? This is not tied to any mapping system 
>architecture at all, so it could be possibly part of the base 
>line if so considered.
>> 
>> A new version of I-D, draft-flinck-lisp-membertest-00.txt 
>has been successfuly submitted by Hannu Flinck and posted to 
>the IETF repository.
>> 
>> This document defines how a membership test can be used to 
>convey all or some of the EID-to-RLOC mappings from an Egress 
>Tunnel Router to requesting Ingress Tunnel Router.  This draft 
>proposes that an authoritative ETR MAY return a group 
>membership test in the LISP Map- Reply Message that indicates 
>if a given EID is served by the ETR.
>> 
>> The membership test is implemented as a Bloom filter.  A 
>Bloom filter is compact data structure to represent a set of 
>elements.  The membership test "aggregates" EIDs beyond prefix 
>based aggregation.
>> 
>> Membership test decreases the load of the mapping system and 
>distributes the EID-to-RLOC resolution between an ITR and an ETR.
>> 
>>                                                              
>                     
>> 
>> The IETF Secretariat.
>>

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 3 Mar 2010 09:32:20 +0200

Hello Joel,

Thank you for your questions. Please see below my answers/questions.

Best regards
Hannu

>From: ext Joel M. Halpern [mailto:[email-masked]] 
>Sent: Tuesday, March 02, 2010 21:19
>Cc: [email-masked]
>[Commenting as an individual contributor.] Having looked at at 
>this draft, and having recently been prompted by other work to 
>look at bloom filters, I am somewhat confused.
>
>First, there seems to be an assumption that if an EID request 
>to an ETR from an ITR matches one EID block that the ETR 
>serves, that there is likely to be traffic to that ITR for 
>other EIDs served by that ETR.  If one assumes cache space, 
>and control message space, are of value, I do not see this as likely.

I am not sure I can follow this logic. Could you please elaborate more? 
If an enterprise is hosting multiple servers, it is likely that same ETR
(RLOC) can reach the other servers as well. Why not? The membership test
is minimizing the use of control messages. Less Map-requests to the
mapping system and to the ETR. (I do not know what do you mean by value
"control message space". Number of messages? Length of messages?
Bandwidth? CPU? We intend optimize all of them.)  

>
>Secondly, and more importantly, as I understand it bloom 
>filters are very good at selecting for exact matches.  

Yes. As I answered to Wassim, 10-^6 error rate may not justify too
complicated error recovery process even if they would be doable.

>However, in general with LISP, the EID blocks served by an ETR 
>are a range (prefix) not a full length EID.  As such, I do not 
>see how that can give rise to a useful bloom filter.  (For use 
>in prefix based routing, the actual suggestion I saw was to 
>have a separate filter for every prefix length.  That worked 

This is really a key issue what you are pointing out. Do we strictly
require continuous EIDs blocks to be served by an ETR? I know this is
what is assumed right now. However, if that would be the case LISP, will
have EIDs that are tight to ETRs and to the provider of the ETR.
Topology independence is lost. I think that we should do better and
allow EID portability. And that breaks the EID-prefix arrangement. 

>Having to do N hash operations and N bit test operations is 
>not a particularly friendly operation in software.

This depends on the hash functions and the number of hashes as you say.
The commonly used TLS is run as SW quite a lot without any HW boosting.
It is also using MD5 (or SHA-1 which is heavier than MD5). 

The calculation burden of the proposed scheme is in ETR that constructs
the membership test, but that calculation not to be done in real time,
but in background. The checking if an EID belongs to the set is much
simpler, you ITR calculates the hashes (MD5) over one EID, not many as
in the ETR. Real time processing need is very low.
    
>gain. The 
>> more than just the requested mapping information about the mappings 
>> that it is hosting. The information is compressed in a form of 
>> membership test which we see very powerful tool for this 
>specific use 
>> case. The use of membership test is at its best when an ETR 
>is hosting 
>> EIDs that do not aggregate under a prefix.
>> 
>convey all 
>> or some of the EID-to-RLOC mappings from an Egress Tunnel Router to 
>Bloom filter 
>> is compact data structure to represent a set of elements.  The 
>> membership test "aggregates" EIDs beyond prefix based aggregation.
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 03 Mar 2010 07:44:31 -0500

Yes, as currently defined, and enterprise is expected to get a single 
block of EIDs allocated.  The Enterprise might carve this into several 
blocks for distinct locaitons.

While one could imagine a system where the enterprise gets separate EIDs 
for each devie, there are multiple reasons why that is not envisioned:
1) EIDs are need for all machines in the enterprise, not just servers. 
So a lot of values are needed
2) The Enterprise is much better off managing its EID usage itself. 
Therefore, it it gets a block (represented as a prefix), then Enterprise 
IT can do its job, without needing to go upstream for each new machine.

3) In order to use BGP effectively for resolving EIDs to RLOCs (to ETRs 
which provide RLOCs, or to MS which do this on behalf of ETRs), it is 
necessary that some degree of aggregation occur.  This is more specific 
to the ALT (or probably DNS based EID lookup), rather than to LISP as a 
whole.  If the first two issues did not apply, and one really wanted to 
give out individual, scattered, IDs, then one could use a different 
mechanism, such as DHTs or quasi-compact routing.

The other side of the coin is that there is no advantage to using 
scattered lookups.  It just complicates the system, for no apparent 
benefit.

Yours,
Joel

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 3 Mar 2010 15:49:26 +0200

Agreed. But as time evolves the devices and servers with their EIDs will
migrate under other RLOCs breaking the original EID block allocation.
This has happen in the past, and it is more than likely to repeat itself
with the EID prefixes. DHT is one extremity of the spectrum supporting
fully flat EIDs. Between these two cases of EID-blocks and flat EIDs,
fits our proposal. So, we are not saying that the EID space should be
flat, we say that there will be cases where ETR is hosting host EIDs
that do not aggregate. In fact, the smaller the domain the likelier the
case. I agree that scattered looksups are a problem and should be
avoided particularly if there is not benefit with them. So both extreme
cases are troublesome.

To be clear the draft doesn't scatter any lookups. It just adds a hint
from the ETR what else it is hosting. That's all. There is nothing to
the mapping system in there. 

Best regards
Hannu

>Sent: Wednesday, March 03, 2010 14:45
>Yes, as currently defined, and enterprise is expected to get a 
>single block of EIDs allocated.  The Enterprise might carve 
>this into several blocks for distinct locaitons.
>
>While one could imagine a system where the enterprise gets 
>separate EIDs for each devie, there are multiple reasons why 
>that is not envisioned:
>Therefore, it it gets a block (represented as a prefix), then 
>Enterprise IT can do its job, without needing to go upstream 
>for each new machine.
>
>3) In order to use BGP effectively for resolving EIDs to RLOCs 
>(to ETRs which provide RLOCs, or to MS which do this on behalf 
>of ETRs), it is necessary that some degree of aggregation 
>occur.  This is more specific to the ALT (or probably DNS 
>based EID lookup), rather than to LISP as a whole.  If the 
>first two issues did not apply, and one really wanted to give 
>out individual, scattered, IDs, then one could use a different 
>The other side of the coin is that there is no advantage to 
>using scattered lookups.  It just complicates the system, for 
>no apparent benefit.
>
>Yours,
>Joel
>
>
>>> [Commenting as an individual contributor.] Having looked at at this 
>>> draft, and having recently been prompted by other work to look at 
>>> bloom filters, I am somewhat confused.
>>>
>>> First, there seems to be an assumption that if an EID request to an 
>>> ETR from an ITR matches one EID block that the ETR serves, 
>that there 
>>> is likely to be traffic to that ITR for other EIDs served by that 
>>> ETR.  If one assumes cache space, and control message space, are of 
>>> value, I do not see this as likely.
>> 
>> (RLOC) can reach the other servers as well. Why not? The membership 
>> test is minimizing the use of control messages. Less Map-requests to 
>> the mapping system and to the ETR. (I do not know what do 
>you mean by 
>> value "control message space". Number of messages? Length of 
>messages?
>filters are 
>>> very good at selecting for exact matches.
>> 
>>> However, in general with LISP, the EID blocks served by an 
>ETR are a 
>>> range (prefix) not a full length EID.  As such, I do not 
>see how that 
>>> can give rise to a useful bloom filter.  (For use in prefix based 
>>> routing, the actual suggestion I saw was to have a separate filter 
>>> for every prefix length.  That worked because it also assumed 
>>> hardware support.)
>> 
>> what is assumed right now. However, if that would be the case LISP, 
>> will have EIDs that are tight to ETRs and to the provider of the ETR.
>> The calculation burden of the proposed scheme is in ETR that 
>> constructs the membership test, but that calculation not to 
>be done in 
>> real time, but in background. The checking if an EID belongs to the 
>> set is much simpler, you ITR calculates the hashes (MD5) 
>over one EID, 
>> not many as in the ETR. Real time processing need is very low.
>>     
>>> Yours,
>>> Joel
>>>
>thing? Would 
>---------------------------------------------------------------------
>>> -
>>>> --
>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 03 Mar 2010 09:59:32 -0500

Attempted amplification, as I understand things, below.

> Bandwidth? CPU? We intend optimize all of them.)  

There are two different kinds of cases I could think of.  There could be 
an ETR taking care of several companies.  That is an unlikely 
deployment, but it is what prompted my question.  In that case, there is 
no expectation of correlation of traffic across sites.
The reason i assumed this in commenting to you was that it was the only 
way I could see having scattered EIDs.

It is reasonable that if someone goes to one server at a site, they are 
likely to go to another server.  It is even reasonabley likely that if a 
remote server is talking to one client at a site, it is also likely to 
talk to other clients at that site.

But, we have normally assumed block allocation.  As such, the single 
answer from teh ETR takes care of all those cases.
I will leave it to others to comment on the section about scattered 
addresses I have elided from this message (so that they respond directly 
to your earlier note.)

Yours,
Joel

---

From: Damien Saucez <[email-masked]>
Date: Sun, 7 Mar 2010 12:10:28 +0100

Hannu,

The idea of having bloom filters seems to be interesting, but I think it should be better to 
take more time on the mapping system itself (and how to deploy it) than taking time to
find trick to reduce the cost of using it.

What you propose is to have a bloom filter to test wether or not the ETR is in charge 
of the EID or not. This test becomes interesting iif the ETR is in charge of several
prefixes. This is likely to be the cases, but maybe not because the ETR is really in
charge of several prefixes, but because the ETR has decided to do deaggregation
for TE purpose (I do not say here that it is a good idea, but we can certainly find a
case where the operator will decide to do  it ;-) ) In this case, or any other case
where an ETR has several mappings under its responsibility, I wonder if asking
the ETR to send all its mapping would not be a better idea. Joel said that is is likely
that the prefixes will not be correlated but just an example to show you that there
exists at least one case where sending the different mappings makes sense:

UCL use case:
--------------------
We, at UCL, have two campuses, one at Louvain and one at Woluwe. Both campuses
are leaded by the university. As the two campuses are in different cities, they have
different xTR. Let say one in Louvain and one in Woluwe. Because we are the same
entity, we will have the same big EID prefix (let say for the example 130.104/16).
This prefix will be divided into two prefixes, 130.104/17 for Louvain and 130.104.127/17
for Woluwe. At a first glance, it seems that, if some request arrives for 130.104.5.100, we
only need to send the mapping for 130.104/16. But now, imagine, 130.104.5.100 is
the main webserver for UCL and that the website give you information about all the
UCL activities (from both Louvain and Woluwe), then, it is possible that one click
makes a  redirection to a server in Woluwe. If the two mapping are given at the same
time, the cost of using the mapping system will not be seen for the "click" as the cache
is pre-fetched with the mapping.

Let's have a second use case of multiple prefixes at one ETR

DDoS mitigation:
-----------------------
Consider that UCL has one very important cluster which must be always reachable,
and that the Louvain site has two ETRs. The global EID prefix for Louvain is 
130.104/17 and the cluster has the 130.104.1.1/32 address. To avoid that an attack
on Louvain DDoS the cluster, the two prefixes may use different mappings. Therefore,
if one prefix is overloaded, it is possible to avoid the other being overloaded too. To
do so, the /17 prefix will mainly point to ETR 1 while the /32 will ask for using ETR 2.
This deaggregation allows the operator to control the load on each ETR based on the
destination. In this case, we definitely have a gain  of "announcing" the two prefixes for
any request to UCL.

To conclude, as Joel said, I believe it is not really important to take into account the case
where one ETR is in charge of several unrelated EID prefixes. If there is no correlation
between the two, why do we need to do so (if we extend the idea to its paroxysm, we
obtain a full push system, what we do not need I think...). But if one ETR is in charge of
several EIDs, then, maybe the best is to give all the mappings directly. Now, if we
consider that there is temporal locality between the requests, we can say: ok, if first
give you all my mappings and after the TTL is expired, you will only refresh the 
mappings that have been used, therefore, you will not keep entries in your cache for
the mapping you do not need. To now if it is a request of not, it seems to be simple.
If the request arrives via the mapping system, you give all the mappings, if the
request is directly addressed to the ETR, then it is a refresh and you only give the
mapping (and all its more specific of course) or we can add a refresh bit in the requests ;-)

Cheers, 

Damien Saucez

On 03 Mar 2010, at 15:59, Joel M. Halpern wrote:

>>> From: ext Joel M. Halpern [mailto:[email-masked]] Sent: Tuesday, March 02, 2010 21:19
>>> [Commenting as an individual contributor.] Having looked at at this draft, and having recently been prompted by other work to look at bloom filters, I am somewhat confused.
>>> 
>>> First, there seems to be an assumption that if an EID request to an ETR from an ITR matches one EID block that the ETR serves, that there is likely to be traffic to that ITR for other EIDs served by that ETR.  If one assumes cache space, and control message space, are of value, I do not see this as likely.
>> I am not sure I can follow this logic. Could you please elaborate more? If an enterprise is hosting multiple servers, it is likely that same ETR
> There are two different kinds of cases I could think of.  There could be an ETR taking care of several companies.  That is an unlikely deployment, but it is what prompted my question.  In that case, there is no expectation of correlation of traffic across sites.
> The reason i assumed this in commenting to you was that it was the only way I could see having scattered EIDs.
> 
> It is reasonable that if someone goes to one server at a site, they are likely to go to another server.  It is even reasonabley likely that if a remote server is talking to one client at a site, it is also likely to talk to other clients at that site.
> 
> But, we have normally assumed block allocation.  As such, the single answer from teh ETR takes care of all those cases.
> I will leave it to others to comment on the section about scattered addresses I have elided from this message (so that they respond directly to your earlier note.)
> 
> Yours,
> Joel

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 7 Mar 2010 22:58:52 -0800

> UCL use case:

Damien, another way to do this so the mapping database can scale  
better is to have both ETRs configured with the /16 and have policy in  
each to respond with different priorities depending on what  
destination EID is being requested. If the EID is in Louvain, then the  
ETR in Louvain can decide to make itself active and the other one  
backup (or not used with priority 255). Counter-wise with Woluwe.

So, yes you can segment the EID-prefix for UCL but you don't have to.

Another way to do this is to register the /16 with the map-servers and  
use the same policy above and return just the /17. So the mapping  
database has less entries but the cachers can have specific prefixes,  
created on demand.

Dino

---

From: Damien Saucez <[email-masked]>
Date: Mon, 8 Mar 2010 09:01:25 +0100

Dino,
On 08 Mar 2010, at 07:58, Dino Farinacci wrote:

> Damien, another way to do this so the mapping database can scale better is to have both ETRs configured with the /16 and have policy in each to respond with different priorities depending on what destination EID is being requested. If the EID is in Louvain, then the ETR in Louvain can decide to make itself active and the other one backup (or not used with priority 255). Counter-wise with Woluwe.
In the example I gave, Louvain and Woluwe are at different places but are from the same
organization and some servers are in Louvain and others are in Woluwe. So we do not
want to have traffic to Woluwe going through Louvain and vice-versa, so that I do not 
understand how you can deal with the problem by using only the /16 and priorities different
 if it is from Woluwe or Louvain. Indeed, if you send the Map-Request to Louvain's ETR, you
 will have the priority for going to Louvain's ETR, even if the traffic is for Woluwe. So I do not
 see how to avoid having deaggregation in the case, could you clarify? 
> Another way to do this is to register the /16 with the map-servers and use the same policy above and return just the /17. So the mapping database has less entries but the cachers can have specific prefixes, created on demand.
> 

In this case, if you provide only a /17, it will be necessary to have a second map-request if
 the traffic has to go to the other campus (it is happening frequently if you are browsing the
 global website of UCL). 

Our suggestion is simple: send the Map-Reply with the longest prefix and all the longest
 prefixes covered by the prefix, by definition, these prefixes do not cover the EID in the request.
 Example: request for 130.104.1.1, prefixes in the mapping: 130.104/16 and 
130.104.128/24, then, Map-Reply with 130.104/16 and 130.104.128/24. On the contrary, if the
 request is for 130.104.128.2, the map-reply is only with 130.104.128/24. In this example, we 
see that the cost is less important by doing this than by saying that one prefix cannot cover 
another. 

Regards,

Damien Saucez

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 8 Mar 2010 08:11:40 -0800

>> better is to have both ETRs configured with the /16 and have policy  
>> in each to respond with different priorities depending on what  
>> destination EID is being requested. If the EID is in Louvain, then  
>> the ETR in Louvain can decide to make itself active and the other  
>> one backup (or not used with priority 255). Counter-wise with Woluwe.

Yes, I understand that. I wanted to offer a general reference for both  
the active/backup case and your case of active/none.

> see how to avoid having deaggregation in the case, could you clarify?

If you send a Map-Request to *either* they will respond the same way.  
For instance, if there is an EID behind me (I'm an ETR), and if the  
Map-Request comes to me or to you, we would both respond with "me/you  
is active/none".

We want either ETR to reply to the Map-Request because we want to  
distribute Map-Request load across the ETRs. Now if both you and me  
*proxy-reply* registered to the same Map-Servers, the Map-Server could  
answer consistently. This later functionality though is not encoded in  
the packet formats but could be. Architecturally, we don't prohibit  
it. The Map-Server just has to be configured with "merge semantics"  
rather than "overwrite" semantics.

I plan to experiment with this in the next month or so.

>> Another way to do this is to register the /16 with the map-servers  
>> and use the same policy above and return just the /17. So the  
>> mapping database has less entries but the cachers can have specific  
>> prefixes, created on demand.
>>
>

No, the one /16 for the site is broken up into 2 /17s, so if there is  
a map-request to the other half EID, you won't match the one you have  
in the cache.

What I am saying is that both ETRs will Map-Reply for 2 /17s, one with  
itself as active/none and other one with none/active.

> that one prefix cannot cover

Right, that is what we have documented in -06.

And I understand what you are saying but if you return more than one  
prefix than it justifies the problem Hannu is trying to solve.

Dino