Re: [RAM] Just posted: draft-meyer-lisp-cons-00.txt

Hi Dave,

I read your I-D and have some questions, observations, suggestions etc.

In the Map Reply message, I think there needs to be some information
on how long to cache the results for.

Likewise, in the "Unreachable" message.

I understand the "Unreachable" message means that the EID in the request
 is not within any prefix which any CAR known to the system is currently
authoritative for.  Ideally, the requester would be told to cache this
result for some period of time.  Also, ideally, the system would be
smart enough to know what the nearest addresses above and below this
were for which there was a CAR with authoritative mapping information.
There is no mechanism for this in your proposal, as far as I can see,
but I think the "Unreachable" message should contain something like:

   The system has no CARs which have mapping information for
   this address, or for addresses below it to XXX inclusive, or
   for addresses above it to YYY inclusive.

That will save the ITRs and caching CARs from bugging any CDRs in the
near future with mapping requests for nearby addresses.

Perhaps this "Unreachable" reply could be renamed, because it does not
imply anything about reachability of any host which might be using a
mapped address - just that while an ITR enquired about this address
because it assumed it might be part of the LISP system, that as far as
the system knows at present, the address is not mapped by the LISP system.

I am not sure at what point such a reply would be generated.  I
understand it should be generated when a CDR gets a request and then
decides it couldn't pass it on to another CDR. (Sect 5.2 para 5.).  But
how did the request get that far, unless this is the very first CDR?

I understand a CAR sending the request on to the one or more CDRs it
connects to.  Maybe that first CDR (or multiple such CARs) would find it
had no entry in its EID-prefix database, so it has no parent or sibling
CDR to send the request on to - so the first CDR would always be the one
which generates this "Unreachable" reply.

What if a CAR is authoritative for mapping the EID range:

     11.0.0.0
  to 11.0.255.255

but there is a whole range:

     11.0.27.3
  to 11.0.27.127

which currently does not map to any RLOC.  There would probably be many
such ranges with no current mapping.

Let's say this CAR gets a request for the mapping of an EID 11.0.27.16.
 Not only should it reply that there is no mapping, with a cache time,
but I think it should also include in the reply something to the effect:

   "The requested EID is part of a range 11.0.27.3 to 11.0.27.127 for
    which there is no mapping at present."

Then the requesting ITR and its CAR(s) can cache this and stop bugging
the system with further requests when it gets a packet addressed to
other addresses in this range, for as long as the cache time says so.

I think I broadly understand why you have this distributed network of
CDRs as a kind of routing system to forward requests towards an
authoritative CAR.

I don't understand how you make each CAR's data become replicated
somewhere else, so the system still works when the CAR is down.  I was
looking in your I-D to see how you implemented something like what is
done with nameservers, with one being the master and others slaves, but
all being authoritative to answer queries.

I don't understand why you have the reply traverse all the CDRs.  Why
doesn't the authoritative CAR just send a response directly to the CDR
and/or ITR which make the request?

I don't understand why the devices which are authoritative for mapping
information for a particular prefix of EID space also have to be the
first point of call for requests from ITRs, other perhaps than your plan
of making something like a three layer model for the whole system:

  Core of the orange = CDRs with various linkages and redundancies.
                       CDRs don't cache.  Their only function is to
                       connect CARs to CARs in the shortest path
                       manner, or with a longer path for redundancy
                       if one or more CDRs on the shortest path
                       fails.

  Skin of the orange = CARs which both hold the authoritative mapping
                       and which act as interface points for ITRs.
                       CARs cache the results of queries they pass
                       on to an ITR, so if another ITR makes the same
                       request, there is no need to send another
                       request and response through the core.

  Outside the skin   = ITRs, with links to one or more CARs.

Would it be possible instead to have two types of devices in the "skin"?:

1 - Caching devices which one or more ITRs talk to, and which interface
    to the CDR core by one or more links to CDRs.

2 - Authoritative mapping devices which actually respond to the mapping
    requests by reference to their own database, for the addresses
    for which they are authoritative.

These seem to be two totally unrelated functions which you have combined
in the CAR.  The CAR can also respond to mapping queries directly
received from ITRs, but only if by chance the request concerns the small
subset of the mapped address space for which this CAR is authoritative.

In two places your I-D states:

  This case could arise when source-site is LISP-enabled (i.e.,
  there is an ITR deployed), . . .

This confirms my original understanding that all LISP variants require
an ITR in the edge network of any host which will successfully send a
packet to a host with EID address.

When I wrote of Ivip (originally ViP) on 15 June, the key difference
from LISP is that the mapped addresses (EIDs in LISP terminology) are
part of advertised BGP prefixes, and so packets with destination
addresses matching these prefixes will be forwarded out of edge networks
which lack ITRs, ultimately to be encapsulated by one of the many Ivip
ITRs in the core of the Net.  This makes Ivip much more easy to
incrementally deploy, since all senders will have their packets sent,
whereas with LISP, only those senders in edge networks with ITRs will
have their packets sent.

I have asked for clarification of what LISP 1.5 involves, since Dino
stated that what I was proposing was in fact LISP 1.5.  So far I have
had no clarification or examples.  Can you give any explanation of what
LISP 1.5 entails, regarding the location of ITRs inside or outside edge
networks, and whether prefixes for which the system does EID-to-RLOC
mapping are routed by the current BGP system?

I found the following sections of your I-D confusing:

Page 10:

   Each CAR will also have a /32 EID assigned to it from each of its
   configured blocks.  This /32 EID is used in a Map-Request message so
   a replier can get the Map-Reply back to this requesting CAR in the
   event that no CAR has been configured with the the requested EID
   block.  This case could arise when source-site is LISP-enabled (i.e.,
   there is an ITR deployed), but the destination-site has not deployed
   LISP yet so there is no ETR.

I don't understand any of this stuff about using a single IP address
which is mapped by the LISP system as what is later described as the
"Originating address".  Forgetting about the last sentence, I don't
understand why any special mechanism is required to get a message to a
CAR.  It has an IP address which is reachable via ordinary BGP routing,
so why not send any message directly there?

I don't understand why any special message technique is required if no
CAR is authoritative for the EID in the request.  The last sentence
refers to "this", giving a possible cause for "this".  I think the
"this" is the "the event that no CAR has been configured with the the
requested EID block." so I don't think the final sentence is trying to
explain the reason for the use of a single IP address within the mapped
block for sending a message to the CAR which initiated the request.

Each CAR is on some fixed, or at least stable, IP address which is
reachable by the ordinary BGP routing system.  The block of mapped
address space it is authoritative for could be split into many prefixes,
including (I think) individual IP addresses, each with a different
EID->RLOC mapping.  Yet I thought that generally the idea with LISP was
not to map individual IP addresses, but prefixes.  (On the other hand,
on page 3, you write that the database could hold mapping for 10 billion
IP addresses - yet there are only about 3.7 billion public unicast IPv4
addresses.)

If, for instance, it was desired to have a /20 block in the LISP system
and the "owner" of that block (eg. the ISP or AS end-user to whom the
prefix was assigned by an RIR) wanted to map this entire prefix to one
ETR or another, it seems the quoted paragraph prevents this, because one
address must be mapped to the authoritative CAR's IP address.

   Push-Add messages contain an EID-prefix, and Originator Address, a
   64-bit sequence number, and a PV that records the path the message
   took in the CDR level (Section 6.3).  Note that the Originator
   Address is an EID used to route a Reply back to the requesting ITR

           (Missing full-stop.)

Pages 11 and 12

   The Originator address allows a replying CDR to
   forward a Unreachable message (Section 6.5) back to the requesting
   CAR.  This case arises when source-site is LISP-enabled (i.e., there
   is an ITR deployed), but the destination-site has not deployed LISP
   yet so there is no ETR.

This text just seems to confirm my understanding of this IP address, but
doesn't help me understand why such a mechanism is needed or desired.

I skipped from 5.3 and started reading again at 6.4.

Finally, when I read the title of the I-D "... Content Distribution
Overlay ..." I thought this would be for a fancy use of the LISP network
to efficiently transport video, sound etc. multicast or on-demand media
files, which are widely referred to as "content" by those who own the
pipes and packaging systems.

  - Robin                   http://www.firstpr.com.au/ip/ivip/

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram