Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces

From: [email-masked] (Noel Chiappa)
Date: Fri, 20 Mar 2009 13:20:53 -0400 (EDT)

> From: Sam Hartman <[email-masked]

    > I think the fact that LISP maps networks rather than end systems

'initially maps' or 'currently maps' is I think more accurate. There's
nothing in either the Request-Reply or encapsulation protocols, _as currently
designed_, which limits either one to only networks.

    > The other thing I'd like the charter to do is to say how much future
    > possible extensions to LISP are in scope. My belief is that the current
    > charter limits the scope of the LISP we're designing to cases where
    > most routers do not change, and where most hosts and routers are
    > unaware of LISP. While we might choose to make LISP work when deployed
    > very close to the edge, say first hop router, that is not a use case
    > we're focusing on, and we're certainly not designing in features for
    > that deployment.

I don't have any problem whatsoever with having the charter limit the output
of the WG, as initially chartered (because revising charters down the line,
as targets are reached, is certainly done), to documents intended to support
the case you describe ("most routers do not change, and where most hosts and
routers are unaware of LISP").

However, I'd like to understand exactly what you mean when you say we will
"certainly not design[] in features for [other uses]". Taken at its face
meaning, that could prevent adding anything intended to give the LISP system
a capability to evolve and change down the road.

Is that really your intent?

	Noel

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Mar 2009 19:06:50 -0400

>>>>> "Noel" == Noel Chiappa <[email-masked]> writes:

    Noel> However, I'd like to understand exactly what you mean when
    Noel> you say we will "certainly not design[] in features for
    Noel> [other uses]". Taken at its face meaning, that could prevent
    Noel> adding anything intended to give the LISP system a
    Noel> capability to evolve and change down the road.

    Noel> Is that really your intent?

So, what it definitely does not mean is sound protocol design:
designing for extensibility, adding extension mechanisms, adding ways
of doing phased upgrades.

If you were to propose an extension designed to make LISP work better
when an EID was mapped to a specific stack ID I'd say that was
currently out of scope.

If you argued that we should choose between two proposals on the table
because one would make a future of LISP where most hosts did know
about LISP easier, I'd initially sit back and watch the WG
discussions.  If people came to consensus about which proposal to use
quickly, that would be fine.  If the discussion seemed stuck, but a
consensus would be clear if arguments hinging on evolution of LISP
beyond the current charter were discarded, then I would make a
consensus call discarding those arguments.

--Sam