Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Joel,

Re cache management schemes, I think that depends on whether you mean "system level behavior" of a small-scale system, or one operating at large scale or under some kind of stress. The earlier discussion notwithstanding, for practical purposes caching is central to LISP; as such, it's a little weird to say it's architecturally unimportant.

Re ETR sync, I think not even that much wiggle room exists.

--John

On Mar 13, 2012, at 3:04 PM, Joel M. Halpern wrote:

Actually John, I would have to disagree with your assertion about what
it takes to describe the archtiecture.
It may take engineering and evaluating some cache management schemes
before one can decide whether the archtiecture is a good one.  But that
is very different from being able to describe the archteicture so that
one can understand the system level behavior.

Yours,
Joel

On 3/13/2012 2:37 PM, John Scudder wrote:
Barry and all,

On Mar 8, 2012, at 4:34 PM, Barry Leiba wrote:
...
But it's not clear to me that these (especially architecture and impacts) can
be said to have been properly analyzed until some of the lower-priority items
(I'm thinking of threats, cache, ETR sync) have been fleshed out.

I hear what you are saying. But I think the opinion in the IESG at least
was, however, that those three really are high priority, and that other
documents before them are not so useful before they are completed. I guess
it is a different perspective, whether you do things top-down or bottom-up.
I do agree with both points of view, actually.

The dependencies (threats, cache, ETR sync, and whatever else) can
certainly be discussed to the extent needed to lay out the
architecture and other priority documents, with notes taken and saved
for when other documents need to be produced.  That still says that
the working group needs to focus on discussion that leads to the
completion of the three priority documents first, before tackling the
others.  Everyone understands that these priority items can't be
developed in a vacuum; we just don't want things to wander off into
lower-level details such as protocol elements and text that can wait
for the next phase.

You don't want to boil the ocean; that's fine. My point is that without covering (at least) cache management and ETR synchronization, the architecture will not be done. Think about the old joke about the mathematical proof that includes "... then a miracle occurs" as one of its steps (http://star.psy.ohio-state.edu/coglab/Miracle.html). Similarly, threats and the impacts document.

One way to handle this (other than what I've already suggested) might be to explicitly note that the respective documents should cover these topics. For example (edits set off by [[ ]]):

- Architecture description: This document will describe the
  architecture of the entire LISP system, making it easier to read the
  rest of the LISP specifications and providing a basis for discussion
  about the details of the LISP protocols. [[The document will
  cover relevant issues including though not limited to cache
  management and ETR synchronization.]]

and

- A description of the impacts of LISP: This document will describe
  the problems that LISP is intended to address and the impacts that
  employing LISP has. While the work on LISP was initiated by Internet
  routing scaling concerns, there has also been an interest on
  improved solutions to a number of different problems, such as
  traffic engineering. This document should describe problem areas
  (such as scaling or traffic engineer) where LISP is expected to have
  a positive effect, as well as any tradeoffs that are caused by
  LISP's design. [[The document will discuss potential security-
  related impacts, whether positive or negative.]]

Regards,

--John
_______________________________________________
lisp mailing list
lisp@xxxxxxxx<mailto:lisp@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/lisp





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]