Re: [RAM] Question about lisp-cons aggregation

[David Meyer <[e-mail]>]

On Wed, Jul 04, 2007 at 09:26:53PM -0700, Dino Farinacci wrote:
> >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.

	Yes. We've had quite a few comments on that text, so we
	need to tighten that up.

> >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.

	Yes, and good point Brian.

> >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.

	Yep, another good catch Brian.


> >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.

	Yes, thanks Brian.

	Dave

_______________________________________________
RAM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram