A WG Review message for this WG already went out a month ago.
What has changed to necessitate another Last Call?
Could the-powers-that-be please make it easier for those who might
care to understand if there is something here that we should know and
possibly comment about?
A simple explanation,
Hi John.
Turns out Jari sent a message with an overview of the changes. But it
only went to the lisp mailing list, to which I'm not subscribed.
See http://www.ietf.org/mail-archive/web/lisp/current/msg03674.html
That is the sort of explanation I was looking for.
But since re-chartering is an I
Hi Thomas,
On Feb 15, 2012, at 4:31 PM, Thomas Narten wrote:
> A WG Review message for this WG already went out a month ago.
>
> What has changed to necessitate another Last Call?
>
> Could the-powers-that-be please make it easier for those who might
> care to understand if there is something h
Thanks, Thomas. In case it's not obvious, Jari's message isn't responsive to
the points I raised in my own message so I'll look forward to discussing those.
--John
On Feb 16, 2012, at 12:10 PM, Thomas Narten wrote:
> Hi John.
>
> Turns out Jari sent a message with an overview of the changes.
If I may separate issues for a moment,
the absence of milestones is because Terry and I have to come up with a
proposal for them which matche sthe revised goals.
If you read the rest of the differences, you will see that the general
question of what LISP is aimed at providing is indeed still t
On 15.02.2012 23:31, Thomas Narten wrote:
A WG Review message for this WG already went out a month ago.
What has changed to necessitate another Last Call?
Could the-powers-that-be please make it easier for those who might
care to understand if there is something here that we should know and
pos
John,
The IESG had no specific objection to these parts, but we made the charter in general
shorter and reformulated some of the results. In particular, the idea was to put much of
the material that you pointed to into the "LISP impacts" document. In general,
the IESG felt that we had to go ba
Jari,
I appreciate that brevity is desirable. I think in this case, the compression
process may have been unintentionally lossy. Let me say what in my view was
lost:
1. In discussions within the LISP WG it's frequently stated that
experimentation will resolve some disputed question. Given this
On 2/20/12 9:06 PM, John Scudder wrote:
> Jari,
>
>
> 2. LISP relies on caching,
LISP-ALT relies on caching.
Eliot
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Damian, others,
On 2/23/12 11:15 AM, Damien Saucez wrote:
> Hello Eliot,
>
> May I ask you why you say that LISP+ALT relies on caching?
>
> LISP+ALT is just a BGP based overlay, where is the caching
> there (is the BGP RIB that you consider as a cache?).
An investigation I ran looked at the possi
Hello Eliot,
May I ask you why you say that LISP+ALT relies on caching?
LISP+ALT is just a BGP based overlay, where is the caching
there (is the BGP RIB that you consider as a cache?).
Cheers,
Damien Saucez
On 23 Feb 2012, at 07:38, Eliot Lear wrote:
>
>
> On 2/20/12 9:06 PM, John Scudder w
Thanks for your feedback, John. Would a modified charter with these changes
work for you:
Jari
Locator/ID Separation Protocol (lisp)
-
Current Status: Active
Last updated: 2012-03-08
Chairs:
Joel Halpern
Terry Manderson
Internet Area Directors
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.
>> 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
Jari,
This is pretty good, thank you. I have one further comment. You guys have
prioritized three of the work items:
"The first three items (architecture, deployment models, impacts) need
to be completed first before other items can be submitted as RFCs."
But it's not clear to me that these (es
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
John,
On 3/13/12 8:23 PM, John Scudder wrote:
> 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 purpos
> From: John Scudder
> 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 cach
Relevant? Yes.
Gating? No.
In fact, I would put it the other way around.
The architecture documentis very useful, almost necessary, for deciding
whether the solution is a good one.
The cache management evaluations are another component of such an
evaluation.
Even understanding the cache manag
> Relevant? Yes.
> Gating? No.
>
> In fact, I would put it the other way around.
> The architecture documentis very useful, almost necessary, for deciding
> whether the solution is a good one.
> The cache management evaluations are another component of such an
> evaluation.
> Even understanding t
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 f
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 l
> Re ETR sync, I think not even that much wiggle room exists.
I beg to differ. What happens if an iBGP mesh is not configured properly? Does
that mean the BGP architecture is broken?
We have said in the past, several times, that if the ETRs are out of sync, then
the ITR that gets a Map-Reply f
One further remark:
On Mar 13, 2012, at 3:04 PM, Joel M. Halpern wrote:
...
> It may take engineering and evaluating some cache management schemes
> before one can decide whether the archtiecture is a good one.
...
Agreed.
Isn't it relevant to the architecture document, that it be possible for
> I don't think the proper analogy
> is a bathroom. Everyone knows you can build bathrooms that work, having
> seen successful examples in the past. You might instead think of a building
> which includes a perpetual motion machine [*] as a key element.
Fair enough, and now I understand where you f
> From: John Scudder
> On Mar 13, 2012, at 3:04 PM, Joel M. Halpern wrote:
>> It may take engineering and evaluating some cache management
>> schemes
> Isn't it relevant to the architecture document, that it be possible
> for a reader to judge whether the architecture is
Barry,
On Mar 14, 2012, at 11:02 AM, Barry Leiba wrote:
Relevant? Yes.
Gating? No.
In fact, I would put it the other way around.
The architecture documentis very useful, almost necessary, for deciding
whether the solution is a good one.
The cache management evaluations are another component of
27 matches
Mail list logo
