Noel -
Any routing-scalability-related issues with BGP are not due to BGP
being
push-based; they are due to frequent updates ... [this] issue[]
would go
away in an address indirection architecture
Not necessarily. It all depends on what functionality you're trying to
get out of that layer of binding, i.e. how often the average binding
changes. E.g. if you try and do some mobility through that binding
layer
(I'm not saying we should, just as an illustration) that will
radically
increase the rate/amount of updates.
Sure. If we were to integrate extra functionality into the mapping
system, then this would necessarily limit the solution space for the
mapping system. In the specific case where this extra functionality is
mobility support, the solution space would become limited to pull-based
mapping systems, and we would have to accept the disadvantages of
push-based mapping systems that I described in my previous email.
FWIW, this solution space limitation is one of the reasons why I think
we should not collapse mobility support into the mapping system.
On a more general note, I actually did some 'back of the envelope'
calculations a year or two ago, trying to decide whether to use push
or
pull, and my recollection is that the update rate numbers (i.e. the
control traffic at each and every ITR) for push got fairly significant
(in terms of the number of updates per second) even with only moderate
numbers of mapping entries, and a fairly low assumed per-entry update
rate (e.g. for provider changes only).
This kind of calculations would be very useful. Do you still have that
envelope...? ;-)
[...] the points you raise are certainly valid, but there are good
points on both sides, and I don't think the answer is clear-cut - if
it
were, we probably wouldn't still be discussing it.
Yep. This was exactly my point towards Dino.
Also, I'm not sure that for those working on LISP, ALT is the
'preferred' long-range answer to the question of 'what does the
mapping
subsystem look like'. I think the focus is on ALT at the moment in
large
part because it's fairly easy to deploy, because it re-uses existing
code. (Dino et al, please correct me to the degree I am confused
here.)
It is easy to deploy in a testbed, I agree. I remain skeptical about
real-world deployability, though. Don't see a good reason why providers
would set up and maintain ALT routers. Certainly not for the benefit of
the Internet. Perhaps if you add a model to charge the LISP sites for
the ALT service; but that in turn would make the deployment of LISP
harder...
- Christian
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
