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

From: [email-masked] (Noel Chiappa)
Date: Thu, 22 Jan 2009 23:34:25 -0500 (EST)

> ... claiming that LISP is an appropriate solution to the problems
    > discussed at the IAB's October 2006 Routing and Addressing Workshop

Yakov, perhaps I'm confused, but I don't hear anyone claiming that LISP
should be 'anointed' as _the_ solution. In fact, it's explicitly being put
forward as an Experimental protocol.

What other path forward would you suggest for that work? Should LISP work not
be done in the IETF at all, but rather as a closed, private, outside effort?

        Noel
_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: [email-masked] (Noel Chiappa)
Date: Mon, 26 Jan 2009 13:35:19 -0500 (EST)

> From: David Conrad <[email-masked]>

    >> The question to ask is whether LISP is an appropriate solution to
    >> the problems discussed at the IAB's October, 2006 Routing and
    >> Addressing Workshop.
    >> ...
    >> Yet the LISP proponents still did not adequately address these concerns.

    > Perhaps the reasons LISP proponents haven't adequately addressed those
    > concerns is because they are not addressable with the underlying LISP
    > assumptions?

When thinking about the routing, it's also important to remember that LISP,
in the sense of 'a map-encaps scheme plus a mapping subsystem plus ancillary
glue' is likely (almost certainly?) just a component, almost more of a piece
of necessary substrate (to give us a way out of the current paint corner),
than a full-blown new routing approach. (I've referred before to how LISP
reminded me of simply the deployment plan for a new routing architecture I
worked on.)

Yes, LISP may do some routing-like things (e.g. support multi-homing, and
provide a certain amount of provider independence), but there's a limit to
what you can do with simply separating location and identity. At the end of
the day, we're still working with BGP, and if you want to do more with
_routing_ than BGP allows (e.g. control the paths for traffic aggregates),
then you need something _else_ new.

And deploying that new thing would almost certainly start with.... deploying
something that looks a lot like LISP. Add that to the fact that LISP gives
you a decent bang/buck _in and of itself_ (multi-homing, etc), and you soon
decide to focus on getting LISP done (right, with hooks for the future), and
worry about the rest later...

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 28 Jan 2009 23:06:01 -0500 (EST)

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

    > Portability of EID prefixes requires that the ALT topology follows
    > EID-addressing. This leads to potentially longer-than-optimal paths
    > along the ALT topology. Vice versa, if path stretch is to be limited,
    > then portability of EID prefixes must be restricted.

Yes, but this is only for the first packet(s), until the mapping gets back to
the ITR. Do you really think a few extra hops there are going to be a
problem? (Especially given that due to EGP/IGP information flow barriers,
paths probably aren't completely optimal anyway....)

Also, what percentage of DNS resolutions take more than one round-trip
(because of the use of multi-level DNS names)? Surely that's an even worse
delay (several round-trips, as opposed to simply a few extra hops), but I
don't think I've heard complaints about that?

        Noel

---

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

> 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