Subject: Re: [Int-area] [rrg] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP

From: [email-masked] (Noel Chiappa)
Date: Sat, 31 Jan 2009 15:23:27 -0500 (EST)

> From: Christian Vogt <[email-masked]>

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

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

Certainly, a full-push system is going to be distributing lots of mappings to
boxes that never use them - my guess was something in the 99% region, if not
much higher. (Long digression on the optimal mapping distribution system
omitted - 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.)

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 might well make sense to transition to something else in the long run -
but then of course one has the transition issue to deal with, and from what
thinking I have put into that particular problem, it's more problematic that
some of the other long-term transition issues (e.g. to a different inter-xTR
packet format, etc). So that would argue to make replacement of that
subsystem priority number one...

	Noel
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Christian Vogt <[email-masked]>
Date: Sat, 31 Jan 2009 22:31:17 -0800

Noel -

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

> 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