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@iab.org
https://www1.ietf.org/mailman/listinfo/ram