Subject: Re: [lisp] Questions on Map-Resolver operation

From: [email-masked] (Noel Chiappa)
Date: Thu, 19 May 2011 12:28:14 -0400 (EDT)

> From: Ravi Bhagavatula <[email-masked]>

    > Consider the case of an MR which receives an Encapsulated Map Request
    > from an iTR. In the particular case of MS/MR services hosted on a single
    > node, it would know right away (authoritatively) if it has a mapping
    > between the requested EID and a corresponding set of RLOCs.  Does this
    > mean that the presence of a combined MS/MR node will result in the
    > Map-Request never to be forwarded to the eTR

I am not absolutely positive about some aspects of the answer here (e.g. how
and when MRs do caching of mappings), so I hope someone else can chime in.

The fact that the MS is on the same node as the MR is, I am pretty sure, not
important to this question. Don't forget that what an MS is told by ETR(s) is
that the ETR _has_ a mapping (i.e. what prefixes the ETR is responsible for),
not _what the mapping is_.

So if the MR/MS wants to acquire the mapping, it has to do at least one
Map-Request/Map-Reply cycle with the ETR (and then we get into the caching
issues - and I'm also hazy on when a Map-Reply is sent to the MR, versus when
it is send directly back to the originating ITR.)

    > the MR sends a non-authoritative Map-Reply back to the iTR if it finds a
    > map-record for the requested EID. If it doesn't, it is expected to send
    > a Negative Map-Reply for this request. This is contrast to the 3rd
    > paragraph in the same section which says "If the Map-Resolver does not
    > have sufficient information to know whether the EID exists, it needs to
    > forward the Map-Request to another device which has more information
    > about the EID being requested". Can some please provide some details on
    > this "sufficient information"? From the looks of it, this information
    > seems to be some state associated with the mapping-database (say, ALT).

I think that's correct.

With ALT as a mapping system, if there is no aggregation, every node in the
entire ALT will have to have a complete routing table, with an entry for every
mapping. So perforce there will have to be aggregation - and aggregation
almost certainly means that one will be 'papering over' holes in the
namespace. So the only way for a leaf on the far side of the ALT network to
find out that there is a hole in an advertisement it is seeing is to go check.

    > Is it expected for the Encapsulated Map Request (that the MR receives)
    > to have a RecordCount > 1? ... Since the Map-Requests are sourced by an
    > iTR for a missing eid-to-rloc mapping, wouldn't it reasonable to expect
    > the iTR to generate a separate Map-Request for every such missing
    > eid-to-rloc mapping?

Again, I would like for someone else to confirm this, but IIRC there are
circumstances in which a single mapping request can return multiple mappings,
which is in the case where there are nested mappings. (E.g. 10/8 to one
RLOC, and 10.1/16 to another. I think we decided to allow that, right?)

A request for 10.2.x.y has to return both mappings, because if it only returns
the 10/8 one, a later packet to 10.1.a.b will go to the wrong ETR.

     Noel

---

From: Ravi Bhagavatula <[email-masked]>
Date: Thu, 19 May 2011 11:06:28 -0700

Hi,

Thanks Noel for the explanation. Re-reading the spec (and using the
below points to provide a new perspective on things), I see that:
- An MR which receives an Encapsulated Map Request (EMR) will send a
non-authoritative Map-Reply to the iTR ONLY if (a) it has up-to-date
info w.r.t to the mapping database, (b) it is operating in a caching
mode, and (c) it has the requested eid-to-rloc mapping
- Ditto for a Negative Map-Reply when it doesn't have the eid-to-rloc mapping.
- In all other cases, the MR would forward the request to the MS. This
request would be sent over the ALT if it exists. Else, the MR would
need to be told how to get to the MS, and the request is forwarded
accordingly
- The MS would re-encapsulate the request onto the appropriate eTRs.

AFAIK, the only situation wherein we would have multiple RLOCs
associated with a given EID is when these RLOCs have different
priorities/weights associated with them. Why would 10.2.x.y/32 in your
example below return 10.0.0.0/8 and 10.1.0.0/16 (since 10.2.x.y/32 is
not a part of the 10.1.0.0/16 net)?

To rephrase my original question, is there any merit in allowing only
1 Record in an EMR for a given requested EID (as the MS would only
need to replicate the entire message, not a part of the message) when
it sends it out to the eTR.

Thanks,
Ravi Bhagavatula
San Jose, CA

On Thu, May 19, 2011 at 9:28 AM, Noel Chiappa <[email-masked]> wrote:
>    > From: Ravi Bhagavatula <[email-masked]>
>
>    > Consider the case of an MR which receives an Encapsulated Map Request
>    > from an iTR. In the particular case of MS/MR services hosted on a single
>    > node, it would know right away (authoritatively) if it has a mapping
>    > between the requested EID and a corresponding set of RLOCs.  Does this
>    > mean that the presence of a combined MS/MR node will result in the
>    > Map-Request never to be forwarded to the eTR
>
>    > the MR sends a non-authoritative Map-Reply back to the iTR if it finds a
>    > map-record for the requested EID. If it doesn't, it is expected to send
>    > a Negative Map-Reply for this request. This is contrast to the 3rd
>    > paragraph in the same section which says "If the Map-Resolver does not
>    > have sufficient information to know whether the EID exists, it needs to
>    > forward the Map-Request to another device which has more information
>    > about the EID being requested". Can some please provide some details on
>    > this "sufficient information"? From the looks of it, this information
>    > seems to be some state associated with the mapping-database (say, ALT).
>
> I think that's correct.
>
>    > Is it expected for the Encapsulated Map Request (that the MR receives)
>    > to have a RecordCount > 1? ... Since the Map-Requests are sourced by an
>    > iTR for a missing eid-to-rloc mapping, wouldn't it reasonable to expect
>    > the iTR to generate a separate Map-Request for every such missing
>    > eid-to-rloc mapping?
>