Following on from Tony's message in "Re: [rrg] Ivip map-encap & MHF
in draft-irtf-rrg-recommendation-00":
http://www.ietf.org/mail-archive/web/rrg/current/msg04546.html

Short version:     What is meant by "abstract"?

                   Concern about deciding too hastily between
                   what is relevant in an architectural discussion
                   and what is implicitly irrelevant "implementation
                   detail".

                   Likewise, concern about over-emphasising the value
                   of brevity.

                   Can the RRG form rough consensus that Bill's
                   top level taxonomic divisions are adequate?

                   What about consensus that the best solution will
                   be found within the core-edge separation division
                   - Strategy A?


Hi Tony,

Regarding the scope of the taxonomies and the level of detail in the
divisions of the taxonomies you wrote:


> |The descriptions of these approaches in 3.3.1.x are exceedingly
> |minimal.  I don't know why everything has to be so terse.  Internet
> |drafts are printed on 100% recycled electrons, and I think it is
> |important to help people - including those outside the RRG - identify
> |and understand the various possible architectures as clearly as
> |possible.
> 
> Unfortunately, length and detail do not create clarity.  

Yes, but clarity can only be achieved with sufficient length and
detail.  This is assuming clarity means more than simplicity and lack
of ambiguity - that a clear description of the architecture or class
of possible architectures is sufficient to clearly distinguish it
from all other divisions of the solution space.

A clear description of a division in the architectural taxonomy will
not be excessively brief and will most likely be written by someone
who fully understands at least one architecture which fits within
that division.


> Instead, they frequently obscure it.  

OK - but do you think any of the text I suggested obscures clarity?

If so, please propose simpler versions.

With one exception (my attempt to improve A4d, which covers LISP and
maybe to some extent APT) all the changes I made concern the
architectural principles used in the Ivip proposal.

Since I chose and/or devised these architectural principles for my
proposal, and since I assert that the previous text (or lack of text)
is inadequate for properly describing these architectural principles,
I think my suggested text should be the starting point for
discussions about how to properly describe these divisions of the
taxonomy.

The I-D, RFC, recommendation or whatever it will be:

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

will be an important reference for everyone who is involved in the
future architecture of the Net.  It results from a dozen or so
face-to-face meetings and 6,272 mailing list messages (RAM and RRG,
38Mb including headers).

A central feature of the recommendation will be the one or more
taxonomies.  I think it is essential that the taxonomic divisions and
sub-divisions be described clearly - in terms we in the RRG
understand and in terms which other people will understand.

I think it is rather tortuous using "encoder" and "decoder" when
"ITR" and "ETR" are more communicative and accurate, but I understand
you are trying to keep the discussion as general as possible.


> 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.

While I am all for brainstorming, I am not convinced that much good
will come from abstract manipulations of very high level constructs
which distinguish the highest level divisions in the solution space,
such as the difference between core-edge separation, core-edge
elimination and one or more clean-slate approaches which do not
involve cores or edges at all.

I don't want to get in the way of such discussions, but I think most
people in this field went through this stuff two years ago.

We are not trying to design an idealised network.  We are very
tightly constrained by the need for the scalable routing solution to
be voluntarily adopted by the great majority of end-user networks
which want multihoming, TE and portability -  none of whom can be
assumed to have any direct concern with the costs born by ISPs due to
routing scaling problems.

So the solution has to have clear, immediate, benefits for the great
majority of such end-user networks, as well as being attractive to
most ISPs and to whatever new and existing entities will be involved
in running various aspects of the solution.

This rules out significant changes to host protocols, operating
systems or applications.

It rules out having to renumber the network when choosing a new ISP.

IMHO it rules out expecting people to abandon IPv4 and adopt IPv6.

It rules out changes to the interdomain routing system which would
disrupt the BGP DFZ.

I think the RRG could probably reach rough consensus now that this
rules out all approaches other than core-edge separation schemes -
"Strategy A".

I am only really interested in the different architectural approaches
to core-edge separation.


You and Ran Atkinson seem to be wary of drowning in "implementation
detail", "engineering detail" etc.

But how do you decide what is "implementation detail" and so,
presumably unworthy of consideration in an "architectural" discussion.

"Pragmatic" surely means discussing things in a way which considers
all the potential barriers to success - which involves a great deal
of detail about challenges and potential solutions.  This goes right
down to bits, bytes, milliwatts, nanoseconds and exact methods of
achieving some pretty tricky things: AKA "implementation details".

I think this low valuation of "engineering detail" is not shared by
many people who have something important to contribute to a scalable
routing solution.  This results in curious outcomes such as Dino
occasionally writing to the list, as if his tail was between his
legs, discussing something he considers important in an apologetic
manner, because it seems to be an "implementation detail".  More
often, I suspect, people don't write at all.


Please consider the new text I proposed in my message:

  http://www.ietf.org/mail-archive/web/rrg/current/msg04535.html

For instance A4h, which is intended to create a proper place in the
taxonomy for the architectural elements which I chose for Ivip's
encapsulation approach.

A successful encapsulation architecture must involve a secure,
scalable approach to handling PMTUD problems.  So I think the two
things need to be described together.  I assert that this A4h text,
or something like it, is needed to properly describe the division
within the A4 space which encompasses the encapsulation and PMTUD
architecture I chose for Ivip.  A4h is exclusive thing to Ivip -
anyone can use it.

I also assert that A4h is different enough from A4d (an attempt to
describe a division in the architectural taxonomy which encompasses
LISP's "statefull" approach) to warrant a separate place in the
taxonomy.  For instance, for almost all traffic packets, A4h avoids
the use of UDP or any other headers apart from IP-in-IP.  A4h also
maintains for all packets the use of the outer source address being
that of the originating host - which makes it very easy to extend
border filtering on source address to decapsulated packets, as
explained in my proposed replacement text for Bill's short sentence
on "Border filtering".


I think I understand your desire for abstract thinking in order to
find new ideas, new combinations of existing ideas etc. - and to
avoid being bogged down in existing combinations and ways of thinking.

However, since I think you don't contribute much "abstract"
discussion to the list, but frequently urge me and others to write
and think with greater abstraction or at a more "architectural"
level, I am unsure what it is you want.  Perhaps you could give some
examples - concrete enough so I can understand them!


> 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.

I don't understand this at all.

Bill's taxonomy casts a pretty wide net.

It is clear that a number of teams and individuals looked at the
whole scene two or so years ago and concluded that the only way
forward was a core-edge separation scheme.  I think this is the
correct decision.  Initially, that meant Map-Encap.  Now it also
includes Map-Translate (Six/One Router) and Map-Forward using
modified IP headers.

This resulted in a handful of architectures with some things in
common and many significant differences.

Only by discovering differences between actual architectures that
someone is proposing (or perhaps has just dreamed up but does not
seriously propose) can we determine the need of divisions in the
taxonomy.  This gives rise to the need for suitably detailed
descriptions of those divisions.

These details are vital and in no way resemble "noise".


You may choose to apply a "higher" (more "abstract", less "detailed")
distinction between what constitutes a good description of a
significant division between sub-spaces of the total design space
than someone else does.

However, if a designer or a proponent of a particular architecture
asserts that their architecture needs its own division in the
taxonomy, and/or if they assert that they need a different, perhaps
more detailed, description than you consider adequate, then I suggest
that the designer's suggested text be sympathetically considered for
inclusion in the draft report in full.


> |The taxonomy should clearly cover every seriously proposed
> |architecture - and should probably not cover anything else without
> |noting that such an architecture may be possible, but has not yet
> |been proposed.
> 
> I strongly disagree.  The point of the taxonomy is to cover as much of the
> solution space as we can possibly see.  Specific proposals are only points
> in this space and our top-down decision making should have us first try for
> consensus at the broadest possible levels of abstraction.

OK - I agree.

I agree with the overall divisions in Bill's taxonomy.

Does anyone disagree with these divisions?  Should some be removed,
added or described in different ways?

My guess is that there would be good consensus in the RRG that the
overall divisions in Bill's taxonomy are adequate.  Then the question
becomes how to sub-divide each of those divisions.

However, if we also have consensus that the best practical solution
will certainly be a core-edge separation scheme, then we should be
concentrating our attention on Strategy A.

It doesn't really matter if we haven't delineated every architectural
option in some other Strategy N - as long as we have established that
any architecture meeting the criteria of Strategy N is a non-starter,
for instance due to it being impossible to introduce voluntarily, for
instance due to its need for new stacks, APIs and/or applications.


In that process of discussing subdivisions within the taxonomy, I
suggest caution in imposing restrictions regarding brevity or degree
of abstraction.

If someone who has devised or chosen an architecture, or some
architectural principle, asserts that the taxonomy needs to be
changed in order to clearly accommodate that architecture, then I
think there would need to be some pretty careful discussion and broad
support from the RRG before it was decided that their proposed text
was too long, too detailed or unnecessary.


  Regards

     - Robin