[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Dave,

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

Thanks for the quick turnaround Robin.

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

That is what the "Record TTL" is for. Look again at the packet format section.

Likewise, in the "Unreachable" message.

Not clear at this point that a Record TTL is needed. It all depends on if the CAR/ITR will cache a negative entry. We'll know more when we get the implementation done and start testing CONS.

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 

Or not in the CONS database at all.

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:

We could do this if the CARs are configured with the same mask- length. But again, we need deployment experience before just adding stuff like this.

   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.


Right, understand your suggestion.

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. 

Noted.

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?

It got that far because there was a more-specific in a CAR that was aggregated and the CDR has the aggregate and matches the request EID against it.

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.

We believe that the Map-Requests will go all the way to an aggregating/replying CAR since we are proposing aggressive aggregation.

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. 

That is right. And the replying CAR will reply with an Unreachable.

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.

The only way to solve this is to hole-punch the aggregate with a more- specific. And we know what that does to the Internet. ;-) So we are not going to do this.

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.

We don't replicate it everywhere. The mappings stay at the level-0 CAR level. And the Requests hunt for the mapping by following an aggregated and reaggregated path in a strict hierarchy.

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:

The functionality of a Requesting-CAR and a Replying-CAR can be separated. And a Replying CAR does not need to peer with ITRs. We present it this way to show you that both are at level-0 of the hierarchy.

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

This is a CAR that sends Requests. We have received comments from others about this and in the next rev we will call them "Requesting CARs" and "Replying CARs" to differentiate the functionality. And, of course, the 2 pieces of functionality can be co-located in the same device.

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.

It doesn't require it. We envision it will be deployed this way. An ITR could go into a PE device at an ISP that is serving multiple customer connections from that device.

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.

And I have mentioned to you that you don't want PI addresses to be routeable and hence "BGP prefixes". So what you propose can work for PA addresses but if you apply them to PI prefixes, then the routing table cannot get smaller.

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?

LISP 1.5 entails having a separate topology. Either tunneled or physical. You can run BGP on it. The namespace advertise in this instance of BGP are EID-prefixes. Think of it as another VRF on the Internet. The LISP probe packets (packets that are encapsulated by an ITR with the inner DA equal to the outer DA) are sent on this topology so the data can be used as a Request for the ETR to return a data-triggered mapping.

Think of a data-triggered mapping an instance of LISP 1.5.

Think of a control-plane mapping an instance of LISP 3. CONS is an example of a LISP 3 variant. So is NERD.

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.

This is old text we forgot to remove. We will fix it. The design passes an originator prefix which is the one the CAR is aggregating. So we don't need to assign a /32 EID to a CAR.

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. 

Just a bug in the spec. Sorry for the confusion.

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. 

Well we had to use the name CONS.  ;-)

Dino


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