[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] EXPLISP BOF at the Dublin IETF
Hi Jari,
I support the LISP-ALT team having their own discussion list
concentrating on their experimental work, since that does not seem
to fit well with the RRG at present. Maybe an experimental IETF WG
would be a good way to do it.
I entirely agree with this:
> The technology just is not ready, not this particular proposal nor
> the other ones. We might be heading into the right direction with
> map-n-encap/translate, but before standards can be created we need
> to have a solid understanding of what the mapping system should be
> like, how the old and new Internet can talk to each other, and
> what the effects to the rest of the Internet will be.
I fully support writing code, running prototypes etc. I wish I had
more time to work on Ivip, with more IDs, writing code etc.
I think the LISP-ALT team could contribute to the solution of the
routing scaling problem better if they also:
1 - Write (to the RRG list - or some other related list which
does not yet exist) detailed critiques of other proposals
which differ from LISP, but aim to achieve the same or
similar goals. APT and Ivip are well enough documented to
form the basis of detailed, constructive, critiques - such
as:
a - Any fundamental, technical or business-case problems in
Ivip's fast-push mapping distribution system.
b - Fundamental problems in how both APT and Ivip push the
full mapping data to ITRs and Query Servers at some
chosen point in the network and use fast, reliable,
pull (and perhaps "notify" local push) to all local
ITRs.
c - Implementation details of the above, which differ
entirely between APT and Ivip.
d - Ivip's business case for OITRDs and how it contrasts
with the lack of business case, so far, for LISP PTRs.
e - APT's assumption of the creation of separate APT
islands, when it should be possible to avoid this,
and so remove some problems which the islands create.
2 - Better explain how LISP-ALT system works, by way of
practical examples, presentation material with graphics
etc. I am not the only one who finds it hard to understand
the LISP IDs clearly, and frequently finds that when a
question about LISP is answered on the list, that the
explanation involves things which seem to contradict what
we thought we learnt from the LISP IDs.
3 - Create a LISP home page so people can find an authoritative
list of latest IDs, latest explanations, latest news etc.
You wrote:
> Frankly, I think the RRG is doing exactly the right thing by
> focusing on concepts and not protocols, but the other side is
> perhaps too neglected; some discussion of experimentation and
> bottom-up design would also be helpful. Like keeping the coders
> awake...
I proposed an RRG-Sandbox list to be run alongside the RRG list, to
discuss such things while leaving the RRG discussion focused as
Lixia and Tony desire.
http://psg.com/lists/rrg/2008/msg01540.html
http://psg.com/lists/rrg/2008/msg01595.html
> Of course, the other extreme would also be bad, if we ignored
> conceptual problems as long as we can test something. The right
> approach would be somewhere in the middle. And routing scalability
> is a hard problem that needs face to face time, possibly lots of
> it. Can we provide more time?
This is the biggest IT question of the early 21st century. I doubt
the RRG is going to devise the solution, in complete architectural
detail in 2008-03 sufficient to convince the IETF to embark on a
single path of developing standards track RFCs.
Time will march on - as it is wont to do - until someone devises and
implements a solution, and until a sufficiently large majority of
end-users willingly adopt it.
> On the other hand, why do we need yet another group to look at
> this?
I think we need at least one more group to discuss the routing
scalability problem, because the RRG focus involves rejecting
discussion of actual proposals and of "details" which many of us
regard as crucial.
> We certainly don't want to send a signal that the RRG can be
> closed, the work has moved to IETF.
Indeed.
> We don't want to send a signal that the protocol selection is
> done, and the answer is Lisp. That would premature.
Absolutely.
> And we do not want to have a group that merely ships RFCs, without
> trying to advance our knowledge of the issues relating to the
> solutions.
I don't want to frustrate the efforts of the LISP-ALT people to
advance their work however they wish. However I think that it would
be better to have a single list, not just one focussed on one aspect
of LISP, where all people interested in this field discussed all the
relevant proposals, and where the designers of each proposal took
greater efforts than I think the LISP-ALT folks have so far to
understand and critique proposals other than their own.
> With all the above in mind, I have approved a limited scope BOF for
> Dublin. This BOF/WG focuses on LISP and ALT, documents the open issues
> in these designs, suggests ways to conduct tests to resolve those
> issues, and acts as a forum to provide information about results of
> those experiments. My hope is that some of this information can also be
> fed back to the RRG, and helps the overall design decisions. All design
> discussion should continue on the RRG list as-is.
OK - but what about detailed discussion of other proposals?
LISP-NERD, APT, Ivip, TRRP, Six/One Router or any newer nascent
proposals, such as converting IPv6 to GSE addressing:
http://lists.arin.net/pipermail/arin-ppml/2008-June/010988.html
http://psg.com/lists/rrg/2008/msg01534.html
I am opposed to the creation of separate forums for each of these,
apart from each group having their own private mailing list, of course.
We really need creative design ideas, constructive criticism of all
the proposals etc. - ideally on one list. Since the RRG can't
accommodate this, I favour the creation of a second list. On such a
list, if there was too much arcane stuff about LISP-ALT or any other
proposal for that new list to handle well, then that would be a time
to bud off a more specialised list.
- Robin
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg