I am not following your conclusion, or how you got there from Noel's note.
The separation of identity and location should mean, for example, that
multi-homed sites can be properly aggregated in teh core routing table.
So the separation is distinctly applicable to multi-homed sites and
their inter-domain aggregation.
One related side effect is that the mapping system can take
responsibility for providing traffic engineering information for such
sites, so that we do not have to use dis-aggregation for multi-homed
edge sites' traffic engineering.
FIB aggregation is a local trick. It does nothing to help routing
advertisements. Also, while I will not sneeze at a 30% benefit (more
runway is very useful), that clearly is not an architectural answer to
the problems.
While there have been some inter-domain variations on
virtual-aggregation suggested, the primary applicability of tat
technique is intra-domain. While it has the potential (if we can deal
with configuration complexity and issues such as loose source policy
application) to provide a significantly larger than 30% win, it is still
largely a short term technique designed to help us keep functionaing
while we get to an architecture that works better.
Yours,
Joel M. Halpern
Flinck, Hannu (NSN - FI/Espoo) wrote:
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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
