Comments on the (currently draft) RRG recommendations of
March 2009 Robin Whittle 2009-03-02
is version b
of this page, updated to refer to version 01 of the draft.
../ To my page
on the RRG in 2009. ../../ To the main Ivip
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):
draft recommendation requests that the RRG have another year to make
our final recommendation. I fully support this.
recommendation currently includes three taxonomies of approaches,
architectures etc. by which the routing scaling problem might be solved:
3.1 A Mechanism
3.2 A Functional Taxonomy
3.3 The Herrin Taxonomy
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.
"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
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.
critiques of version 00 and 01
I suggested an improvement to the 3.1
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.
In version 01:
- A note is added
to 3.: "Of these, we've found that Section 3.3 is the most useful
so far and is where we will continue to focus our efforts."
is improved with changes and extensions.
- My suggested
improvements are not included.
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
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
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.
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.
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
Mainly concerned my suggested changes to
3.3. Did not adequately cover earlier suggested changes to 3.1.b
Added proper discription of suggested
changes to 3.1, and this Changelog.