Noel Thank you for the answer. So I conclude that that
- for ISP internal and inter-domain scalability concerns we have the evolutionary path of aggregating RIB/FIBs - for stub networks we have identity/location separation or elimination The two cases have different target scenarios, beneficiaries and incentives for deployment. Does it make sense to have one recommendation as we are essentially dealing the problem of scalability in two different contexts. - Hannu >-----Original Message----- >From: Noel Chiappa [mailto:[email protected]] >Sent: Wednesday, November 25, 2009 21:09 >To: [email protected] >Cc: [email protected] >Subject: Re: [rrg] moving towards recommendation: the current plan > > > > From: "Flinck, Hannu (NSN - FI/Espoo)" <[email protected]> > > > I am left wondering how does the locator and identifier >separation > > fit into the story line. > > ... > > They separation seems to be orthogonal to the aggregation based > > solutions. > >No, because a lot of the routing-table entries which are >appearing now are 'de-aggregates' caused by a number of things >which separation of location and identity will give us >additional tools to provide _without_ having to depend on the >routing. (Remember Wheeler's/Lampson's famous aphorisms about >problems in computer science being solved by another layer of >indirection, i.e. binding - separation of location and >identity gives us just such a layer of binding.) > >(BTW, "locator and identifier" is not really optimal >terminology, because those refer to specific kinds of names, >and it's better to refer to the generic concepts, i.e. >'identity' and 'location'.) > > >Here are some examples of things which are causing extra >routing table entries to appear, which can be done without >those extra entries if there is a identity/location binding layer: > >- Injecting more-specifics into the external scope to cause >inbound traffic to take the optimal entry point: this can be >down with I/L separation by binding the addresses of different >parts of the internal scope to different entry routers (with >others listed as lower-priority, in case the prime router fails). > >- Multi-homing, which causes what are effectively PI addresses >(even if allocated from one provider's block) to be advertized >from routers connected to other providers: again, with I/L >separation, the different entry routers can be listed in that >block's binding, and only the location of the entry routers >(which can/should be given addresses from the block of the >provider to which they are attached) need be advertized - >aggregated, of course, into that provider's advertisement. > >- Provider-independent addresses, which are inherently unaggregatable: >with I/L separation, the PI addresses need not be advertized >in the modified part of the network, only the location of the >entry routers. > >There are more, such as punch-outs (an organization changes >providers, and takes their address block with them), etc. > > >Do note that the exact details, and the benefits, will vary >from case to case, depending on the particulars; in some cases >(e.g. the PI one), only parts of the network which are running >the location/identity separation will benefit from reduced >routing tables. > >Which is, of course, not a bug, but a feature - it's an >incentive to those parts of the network to convert... :-) > > Noel > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
