The IRTF Routing Research Group is supposed
to produce a set of
recommendations, based on rough consensus, for an architecture (maybe
multiple promising architectures?) by which the Internet's routing
scalability problem can be solved.
The draft of this document
is being edited by Tony Li (RRG co-chair):
The
draft recommendation requests that the RRG have another year to make
our final recommendation. I fully support this.
The draft
recommendation currently includes three taxonomies of approaches,
architectures etc. by which the routing scaling problem might be solved:
3.1 A Mechanism
Taxonomy
3.2 A Functional Taxonomy
3.3 The Herrin Taxonomy
As
of version 01, a note in section 3 indicates that the 3.3
taxonomly is the most important.
My understanding of the list discussions in late February 2009 is
that Tony considers the first two incomplete, and not worthy of being
worked on to make them complete. If so, I think they should be
removed, or at least labeled as being known to be incomplete.
The
"Herrin Taxonomy" is based on Bill Herrin's page
http://bill.herrin.us/network/rrgarchitectures.html
(sixth draft). This avoids the use of the names of actual
proposals - in an attempt to focus on the architectural principles
which are available. Also, terms like "ITR" and "ETR" are
replaced by terms such as "encoder" and "decoder". My
understanding is that Bill's aim was to facilitate discussion, as part
of helping to devise recommendations.
I have a
page
http://www.firstpr.com.au/ip/ivip/rrgarch/
where I attempt to match the divisions in Bill's taxonomies to the
various proposals. I am concentrating on "Strategy A"
(core-edge-separation techniques, including LISP, APT, Ivip and TRRP)
because I think all the other strategies cannot work.
I suggested an improvement to the 3.1
taxonomy:
Tony
responded:
After
several replies to each other, I understand the situation can be
summarized, from the last two messages in this thread:
TL: The taxonomy in 3.1 is inadequate and not particularly helpful and not really
worth further refinement. It's included mostly out of completeness.
RW: I don't see the value in "completeness" if it means including every possible
taxonomy, including those which are inadequate.
I suggest that if you don't want to improve it, that you either clearly state
it is incomplete or remove it.
My first preference is for improving it and my second is for removing it.
Please see
this message:
I
suggested new text so that Ivip's architectural options are covered
properly in the 3.3 "Herrin Taxonomy". I also suggested
completely revised text for the assessment of the "Strategy A"
approaches (core-edge separation techniques). I also suggested a new
version of A3b, which
covers LISP's "stateful" approach to handling PMTUD problems.
(See discussion of this approach:
http://www.ietf.org/mail-archive/web/rrg/current/msg04428.html
2009-01-29).
Tony responded:
in part:
Unfortunately, length and detail do not create clarity. Instead, they
frequently obscure it. The point of having broad, overall descriptions is
to first describe the key aspects of the particular segment of the solution
space. These create abstractions that we can actually discuss and
manipulate in some pragmatic fashion without drowning in implementation
detail.
Yes, once we have made the key architectural decisions at the uppermost
layers of the solution space, then we can and should recurse downwards into
more detail, but until then, the details simply serve as noise in conflict
with any insights and generalizations that we might have.
This
prompted me to write:
to which there have been no replies.
My suggested changes
in message 4535 have not resulted in changes
to the 01 draft. I mentioned this on the list:
pointing to this page.
The
first version of this page was "a". The current version number is
at the top of the page. To see an
older version x, use this directory name with index-x.html added.
Please don't link to these. To refer to older version,
please use the letter and a link to this changelog:
http://www.firstpr.com.au/ip/ivip/RRG-2009/rec/#changelog
.
a 2009-03-01
Mainly concerned my suggested changes to
3.3. Did not adequately cover earlier suggested changes to 3.1.
b 2009-03-02
Added proper discription of suggested
changes to 3.1, and this Changelog.