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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ RAM mailing list RAM at iab.org https://www1.ietf.org/mailman/listinfo/ram