Subject: [RAM] Question about lisp-cons aggregation

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Jul 2007 11:56:07 +0200

Hi,

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

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.

Specifically, in section 4 just after Fig. 2 you say

> The CARs aggregate these EID-prefixes,

and I think that needs an algorithmic description.

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.

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

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

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

     Brian

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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Jul 2007 21:26:53 -0700

> the system yet, but I have some points.

Right, we posted it yesterday.

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

> and I think that needs an algorithmic description.

Okay, we will try to improve the text.

> means; otherwise this description is also not algorithmic.

Okay.

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

> of 0.0.0.0/0 (instead of "0.0.0.0/0 or 0::/0").

We will fix.

> more innovation, it seems to match the problem and minimize  

Thanks for your input.

Dino

---

From: David Meyer <[email-masked]>
Date: Thu, 5 Jul 2007 08:00:35 -0700

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

> >means; otherwise this description is also not algorithmic.

	Yes, and good point Brian.

> >of 0.0.0.0/0 (instead of "0.0.0.0/0 or 0::/0").

	Yep, another good catch Brian.

> >more innovation, it seems to match the problem and minimize  

	Yes, thanks Brian.

	Dave