Re: [RAM] Question about lisp-cons aggregation

> draft-meyer-lisp-cons doesn't seem to have made it through
> the system yet, but I have some points.

Right, we posted it yesterday.

> I'm probably being stupid, but it seems that you don't
> actually define what you mean by an aggregate, or describe
> the algorithm for forming an aggregate. Now that may be well
> known within routing protocols, but I think you need to
> either explain it in this draft or give a precise reference.

An aggregate in the CONS context is simple an EID-prefix. So for  
example, a CAR will have a much of mappings that can fit into a power- 
of-2 less-specific prefix. That is the prefix the CAR advertises to  
the level-1 CDR as an "aggregate".

> Specifically, in section 4 just after Fig. 2 you say
>
>> The CARs aggregate these EID-prefixes,
>
> and I think that needs an algorithmic description.

Okay, we will try to improve the text.

> In 5.3.1 you say
>
>>    If the CAR finds a match, it next checks to see if the EID- 
>> prefix is
>>    the last prefix in an aggregate or is the only EID-prefix in an
>>    aggregate.
>
> I think you need to define what "the last prefix in an aggregate"
> means; otherwise this description is also not algorithmic.

Okay.

> I also don't understand how this process (removing an EID-prefix)
> fails to create black holes.

Because all more-specifics for an CAR advertised aggregate falls into  
it. So if there are no more-specifics, the aggregate doesn't need to  
be advertised so the Map-Request that would have been forwarded along  
this path would cause the CDR to send an Unreachable message to the  
Reqeusting-CAR.

> Incidentally, I noticed two cases of IPv4ism in section 5.1:
> a reference to /32 (instead of "/32 or /128") and a default prefix
> of 0.0.0.0/0 (instead of "0.0.0.0/0 or 0::/0").

We will fix.

> Overall I like this approach more than NERD. Although it requires
> more innovation, it seems to match the problem and minimize  
> dependencies.

Thanks for your input.

Dino

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