[lisp] LISP Versioning vs. Solicit-Map-Request

[Robin Whittle <[e-mail]>]

Short version:     The proposed (not at all official) mapping
                   Versioning approach to LISP should work in
                   all circumstances on a direct ETR to ITR basis.

                   However, its equivalent in the current LISP
                   drafts - Solicit-Map-Request - I think will
                   only work when the sending host is on an EID
                   address, which will frequently not be the case.

I think one of the advantages of the Versioning approach:

  http://tools.ietf.org/html/draft-iannone-lisp-mapping-versioning-00

is that the ETR sends a packet directly to the remote ITR which is
sending it encapsulated traffic packets, prompting the ITR to request
new mapping if its cached mapping version is less than the version
number in the message.  This should work in all circumstances where
the ITR's Map-Request goes to the ETR, including with the use of
non-caching Map-Resolvers.

  http://tools.ietf.org/html/draft-fuller-lisp-ms-00

or with a caching Map-Resolver when the ITR's Map-Request has the A
(Authoritative) bit set, causing the caching Map-Resolver not to
answer from its cache, but to send the Map-Request to the ALT
network, verbatim, with the ITR's address rather than its own.  The
ETR sends the Map-Reply straight back to the ITR.

The Versioning system should also work to some extent when the ITR
requests mapping with the A (Authoritative) flag set to zero, via a
caching Map-Resolver.  In this case, the Map-Resolver requests the
mapping (if it doesn't already have it) and the ETR replies to the
Map-Resolver.  The ETR then could cache the address of the
Map-Resolver and send it a Map-Update-Notification Message.

The first potential problem here is how the ETR could figure out the
Map-Resolver to send the Map-Update-Notification Message to.  This is
not a problem if the ETR decides to send it to all recent requesters.
  But if, for some reason (I don't know how) the ETR decided that a
particular ITR's behaviour was indicative of it needing to get new
mapping, it could be difficult or impossible for the ETR to figure
out which caching Map-Requester the errant ITR got its mapping from.

The second potential problem is how a Map-Resolver, which has just
obtained updated mapping and recognises it differs from the mapping
it recently had and recently sent in a Map-Reply to an ITR, could
prompt the ITR to get fresh mapping.  I guess the Map-Resolver could
send the ITR a Map-Update-Notification Message and rely on the ITR
requesting the mapping again, ideally with the A bit zeroed, to save
the burden on the ALT network and ETR of sending the request all the
way to the ETR, rather than the Map-Resolver generating the Map-Reply
from its fresh cache.


The ETR could always send a Map-Update-Notification Message direct to
the ITR.  I guess the ITR should then respond by making a Map-Request
with the A flag set, so as to ignore any (perhaps or presumably
stale) cached mapping in its local caching Map-Resolver.

There is no explicit way in the current LISP protocols for the ITR to
request the caching Map-Resolver refresh its mapping cache before
sending a reply, other than perhaps sending the Map-Resolver a
Map-Update-Notification Message, waiting a few seconds and then
requesting the mapping again, with A set to zero.

However Dino wrote of an implicit technique:

  http://www.ietf.org/mail-archive/web/rrg/current/msg04575.html

    ITR sends A=1 Map-Requests with an SMR-bit set.  That can tell
    the Map-Resolver to ask for the Map-Reply back to update it
    cache.  I know there are security issues with this but it's one
    way of doing it.


At least this Versioning system should work in all circumstances on a
direct ETR to ITR basis.


The existing LISP system of Solicit-Map-Request (SMR):

  http://tools.ietf.org/html/draft-farinacci-lisp-12#section-6.5.2

won't work when the remote sending host is on an RLOC address, as
will be the hosts of ISPs, of end-users who retain BGP-mapped PI
addresses and of the many end-users, such as DSL customers at home,
who will continue to use PA address space provided by their ISP.

SMR would work when the remote sending host is on an EID address, so
packets going to it are encapsulated in a local ITR, with the LISP
header with its SMR bit set, to be decapsulated by the remote ETR
where the SMR bit will be recognised.  Then, the remote ETR signals
the ITR at that end-user network to request new mapping.

As far as I know, there is no provision for an ETR sending a
Solicit-Map-Request to a caching Map-Resolver.  Maybe it can, but
neither "SMR" nor "Solicit" appear in:

  http://tools.ietf.org/html/draft-fuller-lisp-ms-00


  - Robin