Comments on the (currently draft) RRG recommendations of March 2009

Robin Whittle  2009-03-02
This 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 page.

Background

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):

2009-02-15 http://tools.ietf.org/html/draft-irtf-rrg-recommendation-00

2009-02-26 http://tools.ietf.org/html/draft-irtf-rrg-recommendation-01  (diff from 00)

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. 



My critiques of version 00 and 01

Taxonomy 3.1

I suggested an improvement to the 3.1 taxonomy:

draft-irtf-rrg-recommendation-00 - Modified-Header Forwarding (MHF) 2008-02-18 
http://www.ietf.org/mail-archive/web/rrg/current/msg04520.html

Tony responded:

http://www.ietf.org/mail-archive/web/rrg/current/msg04529.html  2009-02-23

Thank you very much for your suggestion.  However, section 3.1.3 (and, for
that matter, all of section 3.1) is much more general than section 3.3.1.4.
I believe that those two techniques are covered quite adequately there.
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.
In version 01:

Taxonomy 3.3

Please see this message: 

Ivip map-encap & MHF in draft-irtf-rrg-recommendation-00  2009-02-24
http://www.ietf.org/mail-archive/web/rrg/current/msg04535.html


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:

http://www.ietf.org/mail-archive/web/rrg/current/msg04546.html  2009-02-24

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:

Brevity, abstraction & detail; Consensus on Bill's divisions and Strategy A?  2009-02-25
http://www.ietf.org/mail-archive/web/rrg/current/msg04547.html
 
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:

draft-irtf-rrg-recommendation-01 lacks suggested improvements
http://www.ietf.org/mail-archive/web/rrg/current/msg04559.html 2009-03-01

pointing to this page.



Changelog

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.