Hi Lixia and Tony,
I don't have a clear idea of what documents the RRG will be producing
or how these will be debated, drafted and finalised.
Here's my current understanding and some questions.
I saw 14 proposals. However, one is for archival purposes only:
Enhanced Efficiency of Mapping Distribution Protocols in
Map-and-Encap Schemes
http://www.ietf.org/mail-archive/web/rrg/current/msg05540.html
K. Sriram, Young-Tak Kim, and Doug Montgomery
and three, in my estimation, are only for mapping systems:
2-phased mapping for Internet core/edge split schemes
http://www.ietf.org/mail-archive/web/rrg/current/msg05536.html
Wei Zhang
Layered Mapping System
http://www.ietf.org/mail-archive/web/rrg/current/msg05534.html
http://www.ietf.org/mail-archive/web/rrg/current/msg05554.html
Sun Letong, YinXia, Wang ZhiLiang, Wu Jianping
Mapping system based on compact routing
http://www.ietf.org/mail-archive/web/rrg/current/msg05519.html
http://www.ietf.org/mail-archive/web/rrg/current/msg05531.html
Hannu Flinck
Tony wrote:
http://www.ietf.org/mail-archive/web/rrg/current/msg05496.html
Mapping systems are obviously a component of a solution but are
not by themselves a solution. To be considered seriously, they
should be used in conjunction with some network layer solution.
Are the four proposals above going to be part of the final phase?
The archival one is not really meant to be a solution. The other
three could only be part of a solution, and I think they can't be
evaluated alongside the other 10 proposals because they do not
contain a proposal for a complete solution. The first one is meant
to apply to various core-edge separation schemes. The last two seem
to be attempts to improve on ALT, for the purposes of providing a
mapping system for LISP. However, without the proponents of those
core-edge separation schemes adopting these mapping systems, there's
no way of evaluating how well the combination would work.
I understand from:
http://www.ietf.org/mail-archive/web/rrg/current/msg05544.html
that you are compiling the summaries into an Internet Draft and that
in that ID each summary will be followed by a 500 word "analysis".
I understand the proponents are to find and choose one or more people
(ideally several: "collaboration of a number of people" to write the
"analysis" - but that the proponents can't write or contribute to
that analysis themselves. So these analyses will presumably be
reasonably positive - or as positive as the proponents can persuade
anyone to write!
Then there will be a 500 word "rebuttal" of the proposal. This will
be solicited by Lixia and yourself. Is this to be written by one
person or more? Will you ask particular people to write this - or
will you accept contributions from anyone? How would you choose the
people or between contributed rebuttals? Is anyone to contribute a
rebuttal to the RRG list, or should we do it in private to the co-chairs?
Is "rebuttal" too strong a term to use? I guess a critique could
either be in terms that the proposal cannot possibly work - which is
a rebuttal - or that it could work, but not as well as some other
proposal. That could be tricky to do respectfully (with sufficient
details, arguments and qualifications) in 500 words, since it also
involves evaluating at least one other proposal which would be argued
to work better.
Then you will solicit "another counterpoint". "Solicit" indicates to
me that you won't simply ask the proponents for a "counterpoint" but
that you will ask someone to write something - or accept potentially
multiple counterpoints and either choose one, or encourage the
authors to work together to produce a single one.
Will people contribute counterpoints freely on the list, or directly
to you? I guess the counterpoint is to the "rebuttal" - so it can
only be written after the rebuttals are finalised.
Are the proponents allowed to write a counterpoint? What if the
proponents of the proposal don't like your choices about the
counterpoint?
While it looks tricky, I can see some value in this set of pieces of
writing.
But the resulting document doesn't seem to resemble a
"recommendation" to the IETF.
I guess there will be a lot of debate on the list about the merits of
the various proposals. However, the remaining 10 proposals are not
all directly comparable. I think they fit into three groups:
A - 3 core-edge separation proposals which would work for both IPv4
and IPv6 and not require any host changes:
Ivip
http://www.ietf.org/mail-archive/web/rrg/current/msg05533.html
Robin Whittle
LISP
http://www.ietf.org/mail-archive/web/rrg/current/msg05503.html
Vince Fuller, Dino Farrinacci, David Meyer and Darrel Lewis.
Tunneled Inter-domain Routing (TIDR)
http://www.ietf.org/mail-archive/web/rrg/current/msg05538.html
Juan Jose Adan
These three seem to be in direct competition in that it would
only make sense to adopt one, and because they seem to be based
on broadly the same set of assumptions. I think each could
potentially be adopted widely, on a voluntary basis, in a
not-too-distant time-frame (3 to 10 years), due to there being no
need for host changes and no assumptions about widespread
migration to IPv6 as providing relief from the IPv4 scaling
problem.
B - 6 proposals which I think are all core-edge elimination schemes
which I think are not suitable for widespread voluntary adoption
in the near-term, due to the need for host-changes. Some are
IPv6-only. One is IPv4-only - while I recall the RRG consensus
is to definitely solve the IPv6 problem, and ideally the IPv4
problem too.
These seem to me to have different goals, different time-frames
and very different ideas about adoption than the Group A
proposals:
Global Locator, Local Locator, and Identifier Split (GLI-Split)
http://www.ietf.org/mail-archive/web/rrg/current/msg05537.html
Michael Menth, Matthias Hartmann and Dominik Klein
hIPv4
http://www.ietf.org/mail-archive/web/rrg/current/msg05529.html
Patrick Frejborg
Identifier-Locator Network Protocol (ILNP)
http://www.ietf.org/mail-archive/web/rrg/current/msg05539.html
Ran Atkinson
Name-Based Sockets
http://www.ietf.org/mail-archive/web/rrg/current/msg05543.html
Christian Vogt
Name overlay (NOL) service for scalable Internet routing
http://www.ietf.org/mail-archive/web/rrg/current/msg05532.html
Yangyang Wang
RANGI
http://www.ietf.org/mail-archive/web/rrg/current/msg05505.html
Xiaohu Xu
C - One proposal which could be adopted without any further IETF
protocol development and would probably not preclude any other
proposal. At the same time, I think few people would see it as a
full solution to the routing scaling problem - which is what the
Group A and B proposals are attempting to be.
Aggregation with Increasing Scopes: An Evolutionary Path Towards
Global Routing Scalability
http://www.ietf.org/mail-archive/web/rrg/current/msg05542.html
Dan Jen, Dan Massey, Robert Raszuk, Lan Wang, Xiaohu Xu,
Beichuan Zhang and Lixia Zhang.
This proposal suggests it is near-term preliminary to a
longer-term host-based solution - implicitly a core-edge
elimination scheme. Some of the proponents previously worked
on a core-edge separation scheme (APT) but decided that this -
and presumably other such schemes - are too difficult to
introduce.
Is the RRG's final recommendation going to be in a separate ID from
the one with the summaries, analyses, rebuttals and counterpoints?
If so, what is the schedule for discussing and writing it?
Could the recommendation be split into sections according to
time-frame and/or for IPv4 and IPv6?
There are divergent viewpoints about how important it is to solve the
IPv4 scaling problem and how urgently we need to work on the IPv6
scaling problem. Maybe the RRG will reach consensus on this and so
be able to recommend a single approach.
If there is no broad consensus or this on anything else, will the
final recommendation try to summarise the two or more major groups of
viewpoints?
Discussion of proposals has been banned or discouraged until now.
Only a subset of the proposals which were discussed on the RRG or the
RAM list are still alive. Now there are a bunch of new ones - or at
least unfamiliar ones, since TIDR predates this incarnation of the
RRG and has barely been mentioned on the mailing list.
I hope you will be able to help me and others understand the form of
the final recommendation.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
