Subject: [lisp] Questions on Map-Resolver operation

From: Ravi Bhagavatula <[email-masked]>
Date: Thu, 19 May 2011 08:27:04 -0700

Hi,

I am going thru operation of a Map-Server/Map-Resolver WITHOUT the ALT
(MS/MR services hosted on a single node). Referring to Section 4.4 (of
LISP-MS), I am not quite sure I understand the following:
- 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, and hence the iTR
to always receive a non-authoritative Map-Reply if the MS/MR
combination has a mapping for the request EID?
- Section 4.4, 1st paragraph indicates that 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).
- Continuing on this topic, it would be useful to indicate in the
first 2 paragraphs of this section that the (non-authoritative or
negative) Map-Reply messages are sent back to the iTR ONLY if the MR
has all the information it needs for calling the shots against the
requested eid-rloc mapping.
- Is it expected for the Encapsulated Map Request (that the MR
receives) to have a RecordCount > 1? Considering the fact that the
MR/MS forward/re-encapsulate a sub-set of these map-requests to the
eTR, a RecordCount > 1 would introduce some complexity on the MS/MR
nodes (mostly centered around re-building the pay-load map-request,
the inner IP header, the inner UDP header). 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?

Thanks,
--
Ravi Bhagavatula
San Jose, CA

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 19 May 2011 21:30:57 -0400 (EDT)

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

    > the MR knows about mapping either from its local store ... or from the
    > ALT.

Ah, I don't know whether this is just imprecise wording on your part, or
something more significant, but the ALT does not contain _mappings_, it merely
contains information about which ETRs, via their MSs, are _authoritative
sources_ for mappings, for given portions of the EID namespace. To get the
_actual mapping_, one still has to communicate with an ETR.

    > there is always a possibility of the fact that the MR's view of the
    > mapping could be "lagging behind" the ALT, and hence the
    > "non-authoritative" Map-Reply.

It's certainly possible that something (either an ITR, or an MR) could hold an
outdated mapping (i.e. one which has not had its TTL expire, but has been
superseded - e.g. because an ETR mentioned in it has gone down because of
hardware failure).

The case you mention (in which an MS/ETR is no longer _authoritative_ for a
chunk of the EID namespace, but that information has not fully propogated
throughout the ALT) can certainly happen, but is I believe much less likely
than the case in which the _contents_ of a mapping are outdated (as
above). That case (of the mapping data being outdated) is what the 'mapping
versioning' mechanism is inteded to discover.

	Noel