Subject: [RRG] RRG process clarification

From: Lixia Zhang <[email-masked]>
Date: Fri, 18 Apr 2008 00:07:08 -0700

Folks,

We've been told that the process that we're trying to execute is still  
not clear.  Here's an attempt to clarify things.

Our ultimate goal is to deliver a recommendation for a routing  
architecture.  Please note that our goal is NOT to deliver a wholly  
complete, fleshed out routing subsystem implementation, complete with  
protocols, specs, and running code.  Those are all non-goals. Although  
one can potentially learn a great deal from running implementations,  
they are more useful in improving designs than fundamental  
architecture.  What we should be doing is trying to reach consensus on  
the various pieces of the architecture.

An architecture (a.k.a., a framework) is a set of concepts around how  
a system works.  An architecture divides the system into its various  
subsystems and describes the functions of those subsystems and their  
interactions.  Obviously, one can iterate down, performing  
hierarchical decomposition of the architecture.  If you pursue this  
far enough, then you'll find that you have an implementation, but  
again, that's not our charter.  We need only go so far as to provide a  
working architecture.

The level of detail that we have to deliver is certainly open to  
discussion.  Since we are not expected to deliver the engineering part  
of the solution, it is sufficient for us to provide enough specifics  
so that good, competent engineers can take the architecture and design  
the details of a solution without further guidance.

Initially, we started with putting a number of proposals on the table,  
which helped us better understand the design space. However we have  
noticed that lately the discussions have mostly focused on microscopic  
detail about the various proposals instead of the high level  
architectural issues. This is natural, we have a great deal of  
engineering experience, and we're more easily attracted to how the  
little bits work at the bottom than how things should look from the  
larger perspective.
Unfortunately, our charter is to understand that larger perspective.

There is a very broad solution space at hand, and we need to  
understand the breadth of it.  Yes, we could simply pick one solution  
and go with that, but we would not be performing our due diligence.   
The community has placed in us the responsibility to understand the  
whole of the solution space, partition it, and select the best path  
through it.  Without exploring the solution space at least a bit, we  
won't have done a credible job of thinking about all of the ways that  
we could architect the system.

Further, once we have surveyed the solution space, we need to develop  
rough consensus on the approach through the solution space.  Arguing  
about 'incremental deployment', for example, doesn't help this at  
all.  We need to first come to some agreement on the very highest  
level branches in the decision tree (e.g., do we do map-and-encap or  
translation or ???), and not worry about the detailed leaves.  That is  
up to the IETF to wrestle with.

Getting a consensus on this very highest level branches is a difficult  
task, as it requires a good understanding of multiple important  
factors as well as their interplays, perhaps with the mapping system  
design as a centerpiece. Again, our job is to deliver an architecture,  
thus we must first reach such a consensus.

As we gain consensus on more and more of these high level design  
decisions, we will then be able to put together a sound architecture.  
For people who are experienced engineers, this is somewhat analogous  
to writing a functional specification of a system.  We need not do the  
entire work of detailed design.  Rather, our task is to specify all of  
the vital properties for later refinement.

Regards,
Tony & Lixia

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Peter Sherbin <[email-masked]>
Date: Fri, 18 Apr 2008 05:27:53 -0700 (PDT)

> We need to first come to some agreement on the very highest  
> levetl branches in the decision tree (e.g., do we do map-and-encap or  
> translation or ???),...

This sounds good and in line with the original expectations of RRG. It looks that the initial step is to define drivers or building blocks (the Internet atoms - "iats" - if you will). Next would be to agree on how drivers interact (or how we want them to interact) thus outlining an architecture.

There were several attempts to list drivers and major concepts such as location ID; name ID; what physical item must have a location ID; which items must bear a name ID; location ID space/structure; name ID space/structure; behavior of items with name IDs; role of items with location IDs; a wireline connectivity is a private instance of generally mobile world; etc. Formulating a general principle such as "a sender of the data bears costs of the data delivery to the final destination over the network" would guide the actual participants in all aspects of their Internet activities thus helping with the implementation in a long run.

Thanks,

Peter

--- On Fri, 4/18/08, Lixia Zhang <[email-masked]> wrote:

> From: Lixia Zhang <[email-masked]>
> Subject: [RRG] RRG process clarification
> To: "rrg" <[email-masked]>
> Date: Friday, April 18, 2008, 3:07 AM
> Folks,
> 

      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

---

From: Lars Eggert <[email-masked]>
Date: Fri, 18 Apr 2008 10:24:30 -0700

Hi,

thanks for your note - it does really make things a lot clearer.

On 2008-4-18, at 0:07, ext Lixia Zhang wrote:
> Further, once we have surveyed the solution space, we need to  
> develop rough consensus on the approach through the solution space.   
> Arguing about 'incremental deployment', for example, doesn't help  
> this at all.  We need to first come to some agreement on the very  
> highest level branches in the decision tree (e.g., do we do map-and- 
> encap or translation or ???), and not worry about the detailed  
> leaves.  That is up to the IETF to wrestle with.

I hate to bring up the R-word, but I think before we can get to a  
consensus on architectural or technical directions for a solution, we  
need some consensus on what the requirements are for the architecture.  
What are the goals and non-goals?

All the solution proposals on the table apear to have slightly  
different sets of problems they address, based on what the proponents  
of each consider important. The ongoing discussion intermingles  
arguments about which goals are important to address for a future  
architecture with which technical mechanisms are suitable to address  
them, and that's confusing (well, to me at least.)

Lars

---

From: "Tony Li" <[email-masked]>
Date: Fri, 18 Apr 2008 15:11:40 -0700

Hi Lars,
 
|I hate to bring up the R-word, but I think before we can get to a  
|consensus on architectural or technical directions for a solution, we  
|need some consensus on what the requirements are for the 
|architecture.  
|What are the goals and non-goals?

Please see http://tools.ietf.org/html/draft-irtf-rrg-design-goals-01

Tony

---

From: [email-masked]
Date: Fri, 18 Apr 2008 18:25:55 EDT

Lars,
even the existing routing paradigms should be questioned.
LISP doesn't do anything for Multicast, it doesn't do anything wrt the IPv4  
depletion issue, it produces new update churn as to fight existing update  
churn. 
Or: Wasn't IPv6 the future? Now the new routing architecture is supposed to  
be backward compatible with IPv4 AND !!! IPv6. Hasn't IPv6 got its chance and  
didn't it miss this chance ?
What about the orthogonality between intra- and interdomain routing  
protocols?! Isn't this a pity ?
I mentioned Multicast and LISP above. I should defend LISP. All existing  
multicast models have an enormous flaw: they are not state-less. This can be  
changed and -imo- should be changed.
 
Summary: There could be such a bright future for routing.But not if BGP,  
i.e. the distance vector algorithm, is considered a holy cow.
 
Heiner

In einer eMail vom 18.04.2008 19:29:10 Westeuropäische Normalzeit schreibt  
[email-masked]:

Hi,

Lars

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 18 Apr 2008 15:32:49 -0700

> LISP doesn't do anything for Multicast, it doesn't do anything wrt  
> the IPv4 depletion

I have mentioned before that we are working on LISP-Multicast and  
indicated an Internet-Draft will be available by the end of April. We  
are still sticking to that schedule.

And the main LISP spec describes two approaches that can be taken. The  
yet to be published draft-farinacci-lisp-multicast-00.txt chooses one  
of them and details the design.

> issue, it produces new update churn as to fight existing update churn.
> Or: Wasn't IPv6 the future? Now the new routing architecture is  
> supposed to be backward compatible with IPv4 AND !!! IPv6. Hasn't  
> IPv6 got its chance and didn't it miss this chance ?
> I mentioned Multicast and LISP above. I should defend LISP. All  
> existing multicast models have an enormous flaw: they are not state- 
> less. This can be changed and -imo- should be changed.

Stateless-multicast can only mean that you broadcast traffic  
everywhere.  ;-)

Dino

>
> Summary: There could be such a bright future for routing.But not if  
> BGP, i.e. the distance vector algorithm, is considered a holy cow.
>
> Heiner
>
>
> In einer eMail vom 18.04.2008 19:29:10 Westeuropäische Normalzeit  
> schreibt [email-masked]:
> Hi,
>

---

From: Lars Eggert <[email-masked]>
Date: Fri, 18 Apr 2008 15:59:03 -0700

Hi,

> Please see http://tools.ietf.org/html/draft-irtf-rrg-design-goals-01

I must admit that I don't follow the RRG very closely very often (it  
requires a full-time commitment), but I don't remember the discussion  
around this document resulting in a consensus. But I may be wrong, and  
RGs don't need to operate by consensus. In any event, the document is  
definitely is a good start.

I'm wondering if anything more needs to be said with regards to the  
impact that changing the routing architecture has on L4/L7 protocols  
(my personal pet peeve), whether it is desired that existing L3  
protocols be usable as a starting point for implementation and  
deployment, whether improving O&M of the routing subsystem is  
desirable, whether the current weak statement is really what we want  
to require from a routing revamp, etc.?

Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 18 Apr 2008 16:08:20 -0700

On 2008-4-18, at 15:59, ext Lars Eggert wrote:
> whether the current weak statement is really what we want to require  
> from a
                                   ^
                             on security

> routing revamp, etc.?

---

From: "Tony Li" <[email-masked]>
Date: Fri, 18 Apr 2008 16:46:52 -0700

Lars, 

|I must admit that I don't follow the RRG very closely very often (it  
|requires a full-time commitment), but I don't remember the discussion  
|around this document resulting in a consensus. 

There was some discussion, but not a great deal of contention.  The comments
did taper off, and that was taken as a sign of rough consensus by yours
truly.

|But I may be 
|wrong, and  
|RGs don't need to operate by consensus. In any event, the document is  
|definitely is a good start.

We intentionally did not issue it as an RFC so that it could be kept open
for further changes.  Suggestions are still welcome.

Tony

---

From: Robin Whittle <[email-masked]>
Date: Sat, 19 Apr 2008 11:44:20 +1000

I am responding to Lixia's and Tony's message, and to Tony's
discussion with Lars Eggert about how the RRG Design Goals are still
up for discussion and change.

Hi Lixia and Tony,

I support what I think you are suggesting - a systematic approach by
which all major design decisions are evaluated and ideally some
consensus reached.

However, the only way we can reach consensus about each branch in
the tree-like or somewhat criss-crossing network of design paths is
to go to the end of each path, or combination of paths, to find out
how all those particular choices work together.

Bugs Bunny could only acquire the knowledge required to make a fully
informed choice about whether to turn left at Albuquerque by
exploring the road to the right far enough to be sure that it sucked.

I think it is natural and essential that we discuss lots of low
level details, including "incremental deployability", business
models, problematic technicalities etc. to evaluate how particular
combinations of design choices would work together.

> architecture.  Please note that our goal is NOT to deliver a
> wholly complete, fleshed out routing subsystem implementation,
> complete with protocols, specs, and running code.  Those are all
> non-goals. Although one can potentially learn a great deal from
> running implementations, they are more useful in improving designs
> than fundamental architecture.  What we should be doing is trying
> to reach consensus on the various pieces of the architecture.

I think this can only be done after most people have thoroughly
explored their way down the various divergent design paths.

I try to explore all the way down each road until I come to one or
more "showstoppers" things I think cannot be overcome.  Some people
are convinced that some approaches could never work - they see
showstoppers in those approaches without looking at them in much
detail.  Or perhaps they are convinced that other approaches
couldn't work as well as their own preferred approach, and so never
really consider them in detail or critique them on the RRG.

Even if some proposal looks moribund to me, I try to look at it
further and hope to learn something from it.

I have documented my evaluation of the various branches, by way of
"25 questions" and specific critiques.  I think it would be good if
others did the same, particularly for Ivip, for which no detailed
critique or evaluation has yet been done.  Philip Eardley made a
start and hopefully this discussion will continue.  Michael Meisel
prompted me to clearly state a business case for the fast push
mapping system.  It would be great to have continuing discussion and
critique of these technical and business aspects of Ivip.

To properly explore various design options, it isn't enough to say
why approach X would work, or work best - it is necessary to
evaluate all the half-way credible alternatives to X and show either
why they can't work, or why they are clearly inferior to X.

For instance, I think it would be good for the supporters of
LISP-NERD to point out clearly why LISP-ALT, APT, Ivip and TRRP
either can't work, or can't solve the problem as well as NERD.

Likewise, I think LISP-ALT folks should do a detailed exposition on
what is wrong with APT, Ivip and TRRP.  Ignoring these proposals is
not as helpful as stating clearly why they can't be as good as
LISP-ALT.  In doing so, a good debate would ensue and it would be
possible to understand to what extent this view was the result of
differences in understanding the problem, the future environment,
in misunderstanding APT etc.  It may also point up some previously
ignored problems in APT etc.

There's enough documentation of Ivip and of the most challenging
part of it - the fast hybrid push-pull system and its potential
business models - for someone who supports anything other than Ivip
to do a detailed critique.  Hopefully, that will happen soon.

> An architecture (a.k.a., a framework) is a set of concepts around
> how a system works.  An architecture divides the system into its
> various subsystems and describes the functions of those subsystems
> and their interactions.  Obviously, one can iterate down,
> performing hierarchical decomposition of the architecture.  If you
> pursue this far enough, then you'll find that you have an
> implementation, but again, that's not our charter.  We need only
> go so far as to provide a working architecture.

Sure, but the best design has a bunch of elements which work
unusually well together.  Such a good combination can best be found
by playful attempts at various combinations, including of ideas
which at first seem odd or undesirable.

For instance, the outer packet's source address being that of the
sending host.  I think this is very desirable in some ways - and I
only explored as a result of mistakenly thinking this was how LISP
worked.

Only once the design is done can one step back and describe it in
terms of choices between one path and another in a top-down "design
process".  That is not really a design process.  The design is
already done and this is a way of describing it.  A proper decision
process at Albuquerque can't be done when first arriving the fork in
the road.  The proper decision can be described at the fork, but the
decision can only be made after having travelled a long way down at
least one of the two roads.

I can imagine the RRG reaching some kind of consensus on a document
which describes the choices in a correctly ordered set of design
decisions.  But very often, the reason for one top-level choice is
only revealed in the finer points of the design, by all the lower
level aspects it enables.

> discussion.  Since we are not expected to deliver the engineering
> part of the solution, it is sufficient for us to provide enough
> specifics so that good, competent engineers can take the
> architecture and design the details of a solution without further
> guidance.

This sounds good to me.

> Initially, we started with putting a number of proposals on the
> table, which helped us better understand the design space. However
> we have noticed that lately the discussions have mostly focused on
> microscopic detail about the various proposals instead of the high
> level architectural issues. This is natural, we have a great deal
> of engineering experience, and we're more easily attracted to how
> the little bits work at the bottom than how things should look
> from the larger perspective.
>

I think this is how engineers figure out the larger perspective - by
trying a variety of distinct designs, each of which makes good sense
based on whatever assumptions it starts with, and/or according to
different peoples' views of the problem and the environment in which
the solution operates.

When writing something complex, it is not typically possible to
start with anything like a coherent summary of what the final piece
will contain.  I have to dive in, write a bunch of stuff, re-arrange
it to make it better, leave it sit overnight or for months,
rearrange it some more, have some over-arching insight, rearrange it
some more and then finalise it.  Then, a month later, I might be
able to write a concise account of what I arrived at.

> understand the breadth of it.  Yes, we could simply pick one
> solution and go with that, but we would not be performing our due
> diligence.

I think a broad discussion like we are having now is a crucial part
of the due diligence.

I think the RRG could fulfil its charter by evaluating a set of
separate, cohesive, proposals and arriving at a consensus that one
particular proposal was significantly more promising than the rest.
 Then, we could articulate the reasons why we think this is the
case, noting any ways we think that proposal could be improved.
This may involve using parts of other proposals.

Then the recommendation would be for an RRG-specified set of
architectural principles, which work well together for the reasons
the RRG agrees on (rough consensus) and describes in our
recommendation.  We would note that these were best exemplified by
proposal X, adding various reservations and suggestions for
improvements.

I think this recommendation would be at about the level of detail
you are planning for, but it would include more specific mention of
proposal X than I think you currently plan for.  It would recognise
that proposal X was a work in progress, with many things yet to be
decided, so it wouldn't endorse proposal X as such.  Proposal X
could subsequently change in some way the RRG would not have been
happy with.  So the recommendation would be a set of architectural
principles, building blocks, specific goals to be solved in specific
ways, recognition that some things were either non-goals or remain
goals, but have not yet been solved etc.

This way, anyone could start up some proposal Y, based on all the
desirable elements the RRG outlined (most or all of which can be
found in proposal X) but then go on and develop Y as an alternative
to whatever X develops into, while remaining true to the RRG's goals.

> The community has placed in us the responsibility to understand
> the whole of the solution space, partition it, and select the best
> path through it.
>
> Without exploring the solution space at least a bit, we won't have
> done a credible job of thinking about all of the ways that we
> could architect the system.

I think we are exploring the space quite well.  I think it has been
something like this:

  We recognised and agreed on the problems in today's BGP system:
  how it unfairly burdens DFZ router operators with costs incurred
  due to  the existence and activities of edge networks.  From that,
  we recognised that the current BGP system places increasingly
  unacceptable limits on the desires of many end-user networks to
  get address space which is suitable for multihoming, portability
  between ISPs and traffic engineering.

  We explored what could be done to soup up the BGP system to make
  it scale better:

     Conclusion:  Very little - certainly not enough to make more
     than a few tens of percent difference to a problem which is,
     at least in one measurable respect, doubling every 4 years.

        http://bgp.potaroo.net

  Therefore, explore complete replacements for the BGP system:

     Conclusion:  None of these could be introduced, and even if
     one could be, it would be challenging to come up with a
     system which worked markedly better than BGP.

  Therefore, explore overlay architectures which leave the BGP
  system going and take most of the load of end-user network
  address management and forwarding/routing from the BGP system.
  The potentially practical ones - which work for both IPv4 and
  IPv6, which not involve host upgrades or drastic replacements
  of DFZ routers, fall into two classes:

    Tunnelling systems: (map-encap) LISP, APT, Ivip TRRP.

    Address translation:  The only one being seriously discussed and
                          which works with both IPv4 and IPv6 is
                          Six-One Router.

> develop rough consensus on the approach through the solution

I think all this low-level discussion is our best way of surveying
the solution space.

I think there are attempts at high-level theoretical discussions,
such as the recent post by Peter Sherbin, but I can't see how this
helps us arrive at practical proposals which could in fact be
introduced widely without inducements or major upheavals.

> this at all.

Since the RRG Design Goals require a solution to be "incrementally
deployable" I think we need to reach consensus on what this means.

I found I had a much more stringent understanding of this term than
many other people.  I am not trying to change anyone's mind about
what "incrementally deployable" means, but if the consensus is that
it means the less restrictive meaning, then I argue that we would be
better off with a more stringent requirement such as mine.

  http://psg.com/lists/rrg/2008/msg00957.html

The likelihood that a proposal will be widely adopted without
inducements is one of the key requirements of any successful
solution.  I think the less restrictive interpretation of
"incrementally deployable" test would allow quite a few proposals
when only a few, or perhaps none of them, could actually succeed in
the wild and be adopted widely enough without inducements to make a
difference to routing scalability.

> We need to first come to some agreement on the very highest level
> branches in the decision tree (e.g., do we do map-and-encap or
> translation or ???), and not worry about the detailed leaves.
> That is up to the IETF to wrestle with.

I am sure it is for us to wrestle with.  Good designs are cohesive
and have all the bits fitting nicely together.  Ideally, each
element does two or more separate beneficial things and doesn't get
in the way of something important.

If we did a top-down design by committee, without fully exploring
what the result would be like, how its bits would fit together etc.
the result would be the IETF folks (probably us, in fact) throwing
in the towel when they realise the architecture is moribund - that
it looked good from a distance, but doesn't actually allow the
creation of anything like the best working system.

No-one could arrive at the optimal design for any complex system by
making one high level decision after another without first exploring
all (or at least many of) the options which each choice would
support or preclude.

> Getting a consensus on this very highest level branches is a
> difficult task, as it requires a good understanding of multiple
> important factors as well as their interplays, perhaps with the
> mapping system design as a centerpiece. Again, our job is to
> deliver an architecture, thus we must first reach such a
> consensus.

Thus we must continue to explore the particular designs on offer -
with each participant ideally contributing to a robust critique of
the ones they don't support.

Ignoring the other proposals and focussing on one preferred approach
is not good enough, because it is not joining the debate and it is
not allowing for the possibility that maybe the real strengths and
weaknesses of another proposal are different from what they appear
from a distance.

> decisions, we will then be able to put together a sound

I think the process at present is healthy - multiple teams of people
doing their best to design a sound architecture in their own ways.
With more thorough debate, including detailed critiques of all
proposals, some broad consensus will probably emerge on which design
package (or design direction) is best.

This is assuming there is sufficient agreement on the problem and
the current and future environment a solution must operate in -
which may not be the case.

For instance there has already been some difference of opinion on to
what extent mobility or helping to solve the IPv4 address depletion
problem should be goals for an RRG-recommended architecture.

Lars Eggert wrote about this:

> different sets of problems they address, based on what the
> proponents of each consider important. The ongoing discussion
> intermingles arguments about which goals are important to address
> for a future architecture with which technical mechanisms are
> suitable to address them, and that's confusing (well, to me at
> least.)

Some people don't want to overload the RRG process with too many
goals and therefore constraints.

Other folks believe it would be wrong to define and construct a new
architecture which only solved one thing, whilst not considering
other major goals or desirable outcomes - some of which can probably
be achieved by one or more of the current proposals without
significant extra complication, but not by others.

There are fundamental uncertainties and differences of opinion on
numbers of "end-user networks" the new architecture is supposed to
serve in the decades to come.  There is no consensus on the future
numbers of end-user networks and therefore EID prefixes, within two
or three orders of magnitude!

I think there is a wide divergence of opinion on how big these
end-user networks will be and what they will be doing with their
space.  The biggest part of this divergence of opinion is probably
about whether the future definition of an "end-user network" will
include each hand-held device of billions of consumers: mobile
address space tied to their cell-phones and laptops etc.

If we had a reasonably cohesive understanding of goals, future
environment, what "end-user networks" means, how many there will be,
how they will use their space etc. AND once we have more fully
explored the strengths and weaknesses of current design proposals,
then, it would be possible to backtrack and state, with rough consensus:

   "Our first major decision is that the future architecture will be
    based on map-encap."

If we decide this (I think we will), we would also be able have
consensus about why we chose it, such as:

  "Because there are one or more viable design approaches with
   this, and because there are in-principle reasons why all other
   alternatives can't work."

And/or:

  "Because no-one was able to create a potentially practical
   proposal which wasn't map-encap."

> For people who are experienced engineers, this is somewhat
> analogous to writing a functional specification of a system.
> We need not do the entire work of detailed design.  Rather, our
> task is to specify all of the vital properties for later
> refinement.

I think this is fine.  I think we may be able to reach a consensus
on the best architecture by next March.  But only by pursuing
low-level detailed, critiques of the practical aspects of all
current proposals.

Regarding the RRG Design Goals, Tony wrote to Lars:

>> I must admit that I don't follow the RRG very closely very
>> often (it requires a full-time commitment), but I don't
>> remember the discussion around this document resulting in a
>> consensus.
>
> There was some discussion, but not a great deal of contention.
> The comments did taper off, and that was taken as a sign of rough
> consensus by yours truly.

It isn't complete consensus (I am not suggesting it needs to be),
because I wrote a bunch of stuff which suggested improvements to the
Design Goals:

  http://psg.com/lists/rrg/2007/msg00199.html

To this I would add that we need to agree on what "incrementally
deployable" means.  If it is agreed that this is as weak a concept
as some folks indicate in recent discussion, I argue we need to have
a much stronger criteria, involving likely widespread or ubiquitous
adoption without disruption and without significant inducements.

>> But I may be wrong, and RGs don't need to operate by consensus.
>> In any event, the document is definitely is a good start.
>
> We intentionally did not issue it as an RFC so that it could be
> kept open for further changes.  Suggestions are still welcome.

OK - mine are listed above.

  - Robin

---

From: Eliot Lear <[email-masked]>
Date: Sat, 19 Apr 2008 08:51:57 +0200

> definitely is a good start.

And I would argue it's a bad idea to aim for consensus, having attempted 
to do so before.  That's a huge hurdle for getting work done.  The IETF 
has it for standardization.  I don't see the need for research output.

Eliot

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 19 Apr 2008 00:39:49 -0700

On Apr 18, 2008, at 5:27 AM, Peter Sherbin wrote:
> This sounds good and in line with the original expectations of RRG.  
> It looks that the initial step is to define drivers or building  
> blocks (the Internet atoms - "iats" - if you will). Next would be to  
> agree on how drivers interact (or how we want them to interact) thus  
> outlining an architecture.
>
> There were several attempts to list drivers and major concepts such  
> as location ID; name ID; what physical item must have a location ID;  
> which items must bear a name ID; location ID space/structure; name  
> ID space/structure; behavior of items with name IDs; role of items  
> with location IDs; a wireline connectivity is a private instance of  
> generally mobile world; etc.

What I gathered from the above:
- a clearly defined set of terminology is critically important
   (I saw fair number of "ID"s in a pretty short paragraph:-)

- the terminology definition, in turn, critically depend on reaching
   agreement on a set of basic concepts.
   (e.g. is a wireline connectivity a special case of generally mobile  
world)

- what falls into the basic concepts depends on the scope of the design
   (e.g. the overall Internet architecture, vs. the routing architecture
   with a clear understanding of its relations to the other parts)

> Formulating a general principle such as "a sender of the data bears  
> costs of the data delivery to the final destination over the  
> network" would guide the actual participants in all aspects of their  
> Internet activities thus helping with the implementation in a long  
> run.
>
> Thanks,
>
> Peter

I feel less sure about the above principle. Lars brought up the  
requirement question. It seems to me the requirements should guide our  
discussion about the very highest level branch in the decision tree.

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 19 Apr 2008 00:47:21 -0700

On Apr 18, 2008, at 3:25 PM, [email-masked] wrote:
> the IPv4 depletion issue, it produces new update churn as to fight  
> existing update churn.

in the spirit of discussing architectural issues: wonder if you could  
turn the above specifics into some architectural issues that you feel  
we need to pay attention to?

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 19 Apr 2008 00:55:39 -0700

On Apr 18, 2008, at 3:59 PM, Lars Eggert wrote:
> requires a full-time commitment), but I don't remember the  
> discussion around this document resulting in a consensus. But I may  
> be wrong, and RGs don't need to operate by consensus. In any event,  
> the document is definitely is a good start.
>
> (my personal pet peeve),

personally I agree that's a very important thing to get a clear  
understanding (I have some half-baked ideas here), though I dont see  
it belonging to the requirement doc.

> whether it is desired that existing L3 protocols be usable as a  
> starting point for implementation and deployment, whether improving  
> O&M of the routing subsystem is desirable, whether the current weak  
> statement is really what we want to require from a routing revamp,  
> etc.?

this is a good list. Most (if not all) of them were discussed during  
the IAB Routing and Addressing workshop (take a look of RFC4984 if  
anyone interested)

Lixia

---

From: "Tony Li" <[email-masked]>
Date: Sat, 19 Apr 2008 01:49:48 -0700

Hi Eliot, 

|And I would argue it's a bad idea to aim for consensus, having 
|attempted 
|to do so before.  That's a huge hurdle for getting work done.  
|The IETF 
|has it for standardization.  I don't see the need for research output.

True, for pure research, it's not a requirement.  However, for our output to
have any broader impact, some degree of buy-in is required.  A
recommendation that we hand off that is immediately dismissed is effectively
pointless.

Tony

---

From: xuxiaohu 41208 <[email-masked]>
Date: Sat, 19 Apr 2008 11:19:52 +0200

> - what falls into the basic concepts depends on the scope of the 
> design   (e.g. the overall Internet architecture, vs. the routing 
> architecture   with a clear understanding of its relations to the 
> other parts)

agree, the first thing we need to do is to define the concept clearly before architecture design,and I believe that the scope of design is the first concept to be defined since it will determine what's the best candidate of id and locator.

Best regards,
Xiaohu Xu

---

From: Eliot Lear <[email-masked]>
Date: Sat, 19 Apr 2008 11:51:29 +0200

Tony,
> recommendation that we hand off that is immediately dismissed is effectively

Perhaps I'm looking at this wrong.  Maybe the approach should be both.  
Let's explore these avenues and learn, and THEN make a recommendation.  
The thing I'm most encouraged by in this process are the papers that are 
beginning to show up in the academic community.  Having some concrete 
methods itself provides us with research questions that we are beginning 
to get some answers to.  That's important because data and analysis can 
really help both confirm and disspell some of the cautions and claims 
that have been raised.

Eliot

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sat, 19 Apr 2008 12:26:03 +0200

hi,
 
> little bits work at the bottom than how things should look from the  

after the rrg-design-goals drafting, floor has been left open to the low
level specification and implementation level.

hence, the four steps between goals and low-level specs -- the
principles, the models, the components, and the high-level specs -- have
not been (seriously) addressed so far.

the consequence of skipping these steps are: 

1. low-level specs look already like a set of patches with unpredictable
performance and impact/ consequences (the last mtg discussion was clear
about this). by thinking locally and try acting globally this is the
only result one could reach anyway.

2. there are different low-level specs under discussion while the bottom
line shall be on common components and their interactions (before
reaching the high-level spec stage). 

> Unfortunately, our charter is to understand that larger perspective.

when looking at the rear mirror, one could observe that after brief
consideration on goals and objectives, the low-level development phase
has started without taking into account global architectural
considerations. the design space analysis that has been launched is a
not proof point either since they can not lead to further work on the
model and the components of the common architecture (since the latter
were not specified).

i simply hope that this "process clarification" will lead the group
toward routing system architectural sound work and outcome. 

thanks,
-d.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Lixia Zhang
> Sent: Friday, April 18, 2008 9:07 AM
> To: rrg
> solution  
> develop  
> difficult

---

From: [email-masked]
Date: Sat, 19 Apr 2008 14:02:51 EDT

And the main  LISP spec describes two approaches that can be taken. The  
yet to be  published draft-farinacci-lisp-multicast-00.txt chooses one  
of them  and details the design.
Dino,
this is a misunderstanding. Of course you will and can provide some draft  
which will outline how LISP will cope with the existing multicast models. No  
doubt.
My critic is that the architecture discussion isolates the diverse issues.  
That's why I mentioned Multicast and OSPF.
About 10 years ago I wrote to Scott Bradner "why we have Multicast  addresses 
" that is comparable with "why do train cabins have compartments and  not the 
seating arrangement like in an aircraft". It is obvious for reasons of  
tradition. The first train drew a couple of coaches, and IP adopted MC addresses  
from LAN. His response: your point is well taken.
 
However all the problems are interwoven. There is the IPv4 address  depletion 
which appears to be most urgent. At the same time Multicast is wasting  
address space by more than a billion class D addresses although the same purpose  
could be accomplished (the identification of any multicast instance) by means 
of  a new "Multicast forwarding" protocol type combined with the sender's  
Unicast IPv4 address + port. Such a change would relax the  situation 
substantially at least for some more years.
 
Or, take OSPF. Why will OSPF never finish? Sure there will always be new  
node/link related stuff to be advertised. But can't all of it be completely  
opaque to OSPF?
But first of all OSPF itself is truely not yet completed:  ipfrr  can just be 
the beginning of enhanced intradomain routing. It has one  valuable approach: 
After at least one Dijkstra best next hop is determined, it  uses the idle 
time to improve its routing capability. BGP with/without LISP  wastes the time 
with update churn processing. This is obviously due to the  protocol. Proof: No 
such churn in OSPF.
Also, because OSPF and BGP are such different /orthogonal it isn't possible  
to do more sophisticated routing. OSPF-MT can never be extended to 
interdomain.  There may further interesting objectives like "safest routing". It may be - 
 politically- an even more interesting rerouting topic than the fast speed of 
 ipfrr.
 
There  are many more objectives, e.g. with respect to TE or Network  
Management, which aren't badly served by the current architecture.

Stateless-multicast can only mean that you broadcast  traffic  
everywhere.  ;-)
Oh no. Just because all so far standardized multicast models do need state,  
that does not mean that there were no alternative.
 
Funny enough, you mention broadcast: There are also better methods  than 
flooding for doinge broadcast. But certainly not without knowledge about  the 
network topology.
 
There are well-known disadvantages of BGP. The most important one however  is 
never mentioned: you have no topological view and therefore no view of that  
subnetwork which would use some particular (current) router for transit. How 
can  you do better than TE guess work in such a situation ?
It is wellknown what RPF means. But it does not mean what it says: reverse  
path forwarding means forward to the upstream subtree (which may start out with 
 several links).
 
In summary: Isolated handling of individual problems is not an  architecture
 
Heiner

Dino

---

From: Peter Sherbin <[email-masked]>
Date: Sat, 19 Apr 2008 21:47:51 -0700 (PDT)

Yes the summary is good and thank you for that. Generally the idea is to agree on basic terminology, concepts, and start building from there. Drivers/building blocks seem to be critically important, e.g. the notion of molecules and atoms helped to produce a constructive model of the world. Similarly defining the "Internet atoms" could lead to a robust theory guiding the implementation.

Concerns about continuity, IPv4 transition to IPv6 as important as they are nevertheless they are not a priority to RRG. A smooth transition becomes a logical extension of the "correct" theory about the "natural" architecture of the Internet.

As to the guiding economic principle(s) it is just nice to have. It will become obvious from the "correct" theory anyway and we can drop this subject completely if it helps to speed up the discussion.

Thanks,

Peter

--- On Sat, 4/19/08, Lixia Zhang <[email-masked]> wrote:

> Subject: Re: [RRG] RRG process clarification
> To: [email-masked]
> Cc: "rrg" <[email-masked]>
> Date: Saturday, April 19, 2008, 3:39 AM

---

From: Christian Vogt <[email-masked]>
Date: Sun, 20 Apr 2008 21:43:35 +0300

> As to the guiding economic principle(s) it is just nice to have. It  
> will become obvious from the "correct" theory anyway and we can drop  
> this subject completely if it helps to speed up the discussion.

Peter,

you have a number of important points.  Thanks for sharing them.

Your statement cited above, however, is one that I don't agree
with.  Consideration of economic principles is, IMVHO, important
to arrive at the right theory.  If we omit this, we risk ending
up with the wrong theory which will eventually turn into a
protocol that people are reluctant to deploy -- not for technical
or backwards compatibility reasons, but for economic reasons.

One example where, I believe, consideration of economics is due
is the question of who should select the ingress link of an edge
network (a related thread on this list).  Letting the sender of a
packet select the remote ingress link (by letting it select the
destination transit address) would certainly be an approach that
is technically viable, but it would be opposite to the economic
view that the receiver, who pays for its ingress link, should be
able to control which one is used.

- Christian

---

From: [email-masked]
Date: Sun, 20 Apr 2008 17:33:30 EDT

In einer eMail vom 20.04.2008 20:45:24 Westeuropäische Normalzeit schreibt  
[email-masked]:

-  Christian

Wrt this example: at first, a routing technology should be provided, that  
gives you all the options - of course, in a scalable way.
 
For comparison, consider an intradomain-OSPF network topology, and  hereby 
some (destination) node with several links to several  neighboring nodes. It can 
be assumed that at some point in time the rtgwg  might provide good solutions 
to do IP forwarding in compliance with preferencing  any particular ingress 
link at the destination node. Good solutions means,  this preferenced choice 
shall be well balanced wrt to the total traffic to that  destination node.
 
However, with the current inter-domain protocols  you can forget the  
pursuing of such goals.
 
Heiner

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 21 Apr 2008 13:08:15 -0700 (PDT)

> Consideration of economic principles is, IMVHO, important
> to arrive at the right theory. 

Christian, yes economics are important and, IMO, the basic directional guidelines to the implementers should come from the designers. E.g. economic questions persistently surface on various IETF lists (see the latest p2p workshop announcement) while officially IETF does not comment on such. RRG seem to have more leniency here but firstly RRG may want to have a consensus on whether economics become a part of the discussion. On my side I would be glad to discuss on and/or off list, whichever helps.

Thanks, Peter.

--- On Sun, 4/20/08, Christian Vogt <[email-masked]> wrote:

> From: Christian Vogt <[email-masked]>
> Cc: "Lixia Zhang" <[email-masked]>, "Routing Research Group Mailing List" <[email-masked]>
> Date: Sunday, April 20, 2008, 2:43 PM

---

From: "Tony Li" <[email-masked]>
Date: Mon, 21 Apr 2008 13:27:42 -0700

|> Consideration of economic principles is, IMVHO, important
|> to arrive at the right theory. 
|
|Christian, yes economics are important and, IMO, the basic 
|directional guidelines to the implementers should come from 
|the designers. E.g. economic questions persistently surface on 
|various IETF lists (see the latest p2p workshop announcement) 
|while officially IETF does not comment on such. RRG seem to 
|have more leniency here but firstly RRG may want to have a 
|consensus on whether economics become a part of the 
|discussion. On my side I would be glad to discuss on and/or 
|off list, whichever helps.

Discussion of economics are certainly relevant and welcome.  From a
pragmatic point of view, it's helpful to understand the implications of what
we're doing.  However, IMVHO, perfect economic parity is a non-goal.  For
one thing, it may not be achievable.  For another, it may pervert the
technical solution into a non-workable result.  We've seen entire countries
collapse as a result of that effect, so let's not repeat it here.  Finally,
what is economically perfect today is unlikely to retain its economic
balance in the long term.  Change that happens and disturbs the economics
should not cause the architecture to become unworkable.

Again, we should focus on our primary requirements.

Regards,
Tony

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 21 Apr 2008 17:52:02 -0700 (PDT)

> Again, we should focus on our primary requirements.

Fully agree. IMHO, economics is just an application of E=mc^2 to a society, i.e. any economic system that does not comply would eventually collapse. With regard to the Internet the "correct" theory hopefully will capture relevant vectors of energy thus guiding the implementers on many fronts including economics.

Thanks, Peter

--- On Mon, 4/21/08, Tony Li <[email-masked]> wrote:

> From: Tony Li <[email-masked]>
> Subject: RE: [RRG] RRG process clarification
> To: [email-masked], "'Christian Vogt'" <[email-masked]>
> Cc: "'Lixia Zhang'" <[email-masked]>, "'Routing Research Group Mailing List'" <[email-masked]>
> Date: Monday, April 21, 2008, 4:27 PM

---

From: Christian Vogt <[email-masked]>
Date: Tue, 22 Apr 2008 16:40:46 +0300

> Wrt this example: at first, a routing technology should be provided,  
> that gives you all the options - of course, in a scalable way.

Heiner,

"Code is law", says Lawrence Lessig, and I think he has a point.
We have to consider, up front, what the code (or the protocol,
in our case) should allow and what it should forbid.

- Christian

---

From: [email-masked]
Date: Tue, 22 Apr 2008 14:09:45 EDT

Heiner,

-  Christian

Aha,  another law for the RRG :-). But let me backup a little  bit:
I do not know any particular reason why - intradomain-like - entering a  
particular egress node via some preferenced ingress link should be a useful  
objective. I only wanted to point out that a knowledge about the topology  would 
enable more sophisticated algorithms/mechanisms/protocols.
 
Wrt multihoming and interdomain routing let's see what people think is a)  
desirable, b) feasible.
 
Heiner

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 25 Apr 2008 11:57:02 +0200

Hi,

After a careful reading of the following RRG charter, I come to a basic
conclusion that RRG aims to work not only on "R(outing)", but also on
"A(ddressing)".However, there is also a statement in the charter as "
Although Internet routing is a broad and active research area, a focused
effort at this time is necessary to assure rapid progress towards reaching
the goal." Now I'm wondering what the focused effort means? Just Routing? If
not, should the RRG be renamed as RARG or reclarify its charter so as to
make no confuse for those people who believe in that the RRG is only working
on "R"? ;-)

Best wishes,
Xiaohu XU

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The Routing Research Group (RRG) is chartered to explore routing and
addressing problems that are important to the development of the Internet
but are not yet mature enough for engineering work within the IETF. As the
Internet continues to evolve, the challenges in providing a scalable and
robust global routing system will also change over time. At the moment, the
Internet routing and addressing architecture is facing challenges in
scalability, mobility, multi-homing, and inter-domain traffic engineering.
Thus the RRG proposes to focus its effort on designing an alternate
architecture to meet these challenges. Although Internet routing is a broad
and active research area, a focused effort at this time is necessary to
assure rapid progress towards reaching the goal.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Tony Li
> 发送时间: 2008年4月19日 0:12
> 收件人: 'Lars Eggert'; 'ext Lixia Zhang'
> 抄送: 'rrg'
> 主题: RE: [RRG] RRG process clarification
> 
> 
> Hi Lars,
>

---

From: "Tony Li" <[email-masked]>
Date: Fri, 25 Apr 2008 09:14:14 -0700

Hi Xu, 

|After a careful reading of the following RRG charter, I come to a basic
|conclusion that RRG aims to work not only on "R(outing)", but also on
|"A(ddressing)".However, there is also a statement in the charter as "
|Although Internet routing is a broad and active research area, 
|a focused
|effort at this time is necessary to assure rapid progress 
|towards reaching
|the goal." Now I'm wondering what the focused effort means? 

In general, it means that we're trying to work on the scalability problem
and not trolling the broader possible problem set of all possible routing
research.

|Just Routing? If
|not, should the RRG be renamed as RARG or reclarify its 
|charter so as to
|make no confuse for those people who believe in that the RRG 
|is only working
|on "R"? ;-)

We did actually discuss this for exactly the reasons that you cite.
However, we felt that the advantages were outweighed by the confusion that
it would create as part of renaming.

Tony

---

From: Lixia Zhang <[email-masked]>
Date: Fri, 2 May 2008 08:52:06 -0700

>
> Folks,
>
> We've been told that the process that we're trying to execute is  
> still not clear.  Here's an attempt to clarify things.
>
> complete, fleshed out routing subsystem implementation, complete  
> with protocols, specs, and running code.  Those are all non-goals.  
> Although one can potentially learn a great deal from running  
> implementations, they are more useful in improving designs than  
> fundamental architecture.  What we should be doing is trying to  
> reach consensus on the various pieces of the architecture.
> ......
> diligence.  The community has placed in us the responsibility to  
> understand the whole of the solution space, partition it, and select  
> the best path through it.  Without exploring the solution space at  
> least a bit, we won't have done a credible job of thinking about all  
> of the ways that we could architect the system.
>
> mapping system design as a centerpiece. Again, our job is to deliver  
> an architecture, thus we must first reach such a consensus.
> ......

Folks,

it's been exactly 2 weeks since the above msg was posted. There was an  
initial exchange of msgs on this thread, mainly expressing agreement  
with the proposed direction together with clarifications on several  
specific issues.  However that exchange stopped shortly after, as  
opposed to continue on to articulate and propose what should be our  
decision on that very highest level branches in the decision tree. In  
fact the list has been uncharacteristically quiet this week:)

To (re)start that very much needed discussion, I thought a useful  
starting point is to first reach a shared understanding of exactly how  
many branches we face at that highest level branching point.  Below is  
a strawman list (extracted from the taxonomy draft Scott Brim and I  
put out in late March).  this by no means any position, but sole for  
the purpose to get a discussion started.

- the shared goal of all the proposals so far: making the routing  
system scalable by routing on topologically (read: ISP) aggregatable  
prefixes only.

- alternative ways to get there (branches)
#1 Using only aggregatable addresses throughout in the Internet
The essence of this approach is that a multihomed site will have  
multiple address prefixes.
Example approaches under this category:
- SHIM6, with a shim layer between IP and transport to hide the multiple
   IP addresses from transport
- A proposal by Mark Handley, which pushes all multiple IP addresses
   all the way up to transport layer to handle
(NOTE: I mention these examples for the sake of illustrating what this  
branch means; by no means we should get into specific proposal debate  
here)

#2 Routing on aggregatable addresses only inside the global transit  
core (the place that faces scalability challenges today), but do not  
push these provider-based addresses into user sites.
The essence of this approach is that a mapping layer must exist at the  
interface between user sites and the transit core.
(the word "layer" is meant an insulation boundary between parts of the  
net; please do not confuse it with "protocol layer". I simply could  
not find another word at the moment)
Example approaches under this category:
- map-n-encap, which uses IP-in-IP tunneling at the boundary
- GSE, which uses IP address rewrite at the boundary

Some people prefer to separate out IP-address-rewrite to a 3rd  
category, and I would be happy to go that way as well.

Does the above miss any other branches at the top level design tree?

Lixia
PS: I do owe Robin a reply with regard to what are the steps towards  
the decision (i.e. whether RRG needs a depth-first search to reach a  
decision), but I want to make clear that the above question is  
orthogonal to that debate.

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 02 May 2008 18:26:06 +0200

> system scalable by routing on topologically (read: ISP) aggregatable

Hi Lixia,

Should the geographically aggregatable address be out of the consideration?
For example, the site networks will use geographically aggregatable
addresses which are independent of the ISPs. However, these addresses can be
aggregated in the ISP network even though the transit networks within some
region are required to be connected directly or indirectly.

Best wishes,
Xiaohu XU

---

From: "Tony Li" <[email-masked]>
Date: Fri, 2 May 2008 09:43:20 -0700

Hi Xiaohu,

|Should the geographically aggregatable address be out of the 
|consideration?
|For example, the site networks will use geographically aggregatable
|addresses which are independent of the ISPs. However, these 
|addresses can be
|aggregated in the ISP network even though the transit networks 
|within some
|region are required to be connected directly or indirectly.

No, geographically aggregatable addresses are not out of consideration.
However, to seriously propose them, one should also include solutions to the
well known issues with geographic aggregation.  At the very least, these
include the resulting common interconnect within the geographic area and the
effective mandate of the topology.  

Regards,
Tony

---

From: "Tony Li" <[email-masked]>
Date: Fri, 2 May 2008 09:47:57 -0700

|Does the above miss any other branches at the top level design tree?

It should be noted that some folks come at things with an alternate
branching structure:

	- Map-n-encap
	- Translation
	- Transport

Which branching structure to use is also open for discussion.

Regards,
Tony

---

From: Randall Atkinson <[email-masked]>
Date: Fri, 2 May 2008 10:31:43 -0700

% Does the above miss any other branches at the top level design tree?

Fixing naming.

An "8+8" architecture does not necessarily require any address
rewriting.  So one can have architectures that fix the naming issues
without being in a grouping called "address rewriting".

Folks on this list might want to read IEN-1 to see how long ago
some folks understood these are naming issues at their heart.
(IEN-1 is online in PDF these days.)

Cheers,

Ran

---

From: Lixia Zhang <[email-masked]>
Date: Fri, 2 May 2008 10:57:48 -0700

> It should be noted that some folks come at things with an alternate

Where would you put SHIM6 in the above?
(I wasn't clear whether it belongs to transport, as the shim layer is  
between IP and transport; while the proposal from Mark lies entirely  
on transport)

Lixia

---

From: "Tony Li" <[email-masked]>
Date: Fri, 2 May 2008 11:01:31 -0700

Ran,

|% Does the above miss any other branches at the top level design tree?
|
|Fixing naming.
|
|An "8+8" architecture does not necessarily require any address
|rewriting.  So one can have architectures that fix the naming issues
|without being in a grouping called "address rewriting".

Is this really a different branch?  Don't all solutions "fix" naming for
varying values of "fix"?

Tony

---

From: "Tony Li" <[email-masked]>
Date: Fri, 2 May 2008 11:03:32 -0700

|> It should be noted that some folks come at things with an alternate
|> branching structure:
|>
|> 	- Map-n-encap
|> 	- Translation
|> 	- Transport
|
|Where would you put SHIM6 in the above?
|(I wasn't clear whether it belongs to transport, as the shim layer is  
|between IP and transport; while the proposal from Mark lies entirely  
|on transport)

IMHO, SHIM6 lives directly in the translation camp.  It is very much NAT in
the host.

Tony

---

From: David R Oran <[email-masked]>
Date: Fri, 2 May 2008 15:17:26 -0400

On May 2, 2008, at 1:57 PM, Lixia Zhang wrote:

> (I wasn't clear whether it belongs to transport, as the shim layer  
> is between IP and transport; while the proposal from Mark lies  
> entirely on transport)
>
The network/transport boundary is inside hosts and is emphemeral. The  
salient questions, at least to me, are:

a) which bits on the wire are interpreted/set by hosts only versus   
which bits on the wire are interpreted/set/modified by routers only,  
versus which are interpreted/set/modified by both
b) whether only the router hardware/software needs to modified, only  
the host hardware/software below the application interfaces needs to  
be modified, or if both need to modified
c) if the scheme is undetectable by application code, detectable but  
not in any useful/harmful way by applicaiton code, or if application  
code is affected.

DaveO.

---

From: Randall Atkinson <[email-masked]>
Date: Fri, 2 May 2008 14:57:43 -0700

% Is this really a different branch?

Using Lixia's taxonomy, the answer is clearly Yes.
It fits in none of the categories that Lixia defined.

% Don't all solutions "fix" naming for varying values of "fix"?

That is not at all clear to me.  We have various ways of dealing
with the site multi-homing issue, but not all of the ways that
have been discussed here to address that involve changes
to the naming architecture.

If you prefer a different term, please suggest one.

(The category missing is not map-and-encapsulate,
nor is it address rewriting, nor ...)

Cheers,

Ran

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 2 May 2008 18:36:47 -0400 (EDT)

> From: "Tony Li" <[email-masked]>

    > It should be noted that some folks come at things with an alternate

I dunno if it's worth noting that that analysis tree is as much (if not more)
engineering, as opposed to architectural.

	Noel

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 03 May 2008 13:37:32 +1200

> IMHO, SHIM6 lives directly in the translation camp.  It is very much NAT in

No, it's fundamentally different in that the packet delivered to the upper
layer at the far end is identical to the packet sent by the upper layer.
It's vital to distinuguish reversible mutation of the packet from irreversible
mutation. So I would put shim6 and map-and-encap together; they are
isomorphic viewed from the upper layer.

    Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 02 May 2008 22:33:49 -0400

Actually, the way I look at it, both encaps and rewrite (map-and-encaps 
and translation) have the property that the information of interest to 
the upper layers is carried and preserved.  The biggest difference I see 
(and I tend to think it is architectural, although there are those who 
see it differently) is that by having the upper layers ignore part of 
the packet, we can use that part for the mapping result, avoiding the 
need for encapsulation.

Yours,
Joel

---

From: "Tony Li" <[email-masked]>
Date: Sat, 3 May 2008 01:47:51 -0700

Ran,

|% Don't all solutions "fix" naming for varying values of "fix"?
|
|That is not at all clear to me.  We have various ways of dealing
|with the site multi-homing issue, but not all of the ways that
|have been discussed here to address that involve changes
|to the naming architecture.
|
|If you prefer a different term, please suggest one.
|
|(The category missing is not map-and-encapsulate,
|nor is it address rewriting, nor ...)

Well, there's a set of the solutions that simply propagate the hosts ability
to work with the current semantics of an address and provide another layer
of address for routing to work with.

Then there's the set of solutions that actually provide a different
identifier for transport to work with and require transport changes.  This
would include all of the GSE-like proposals and Handley's suggestion.  This
would span some of the 'translation' solutions as well as all of the
transport level solutions.

Tony

---

From: "Tony Li" <[email-masked]>
Date: Sat, 3 May 2008 01:56:59 -0700

Hi Brian,

|> IMHO, SHIM6 lives directly in the translation camp.  It is 
|very much NAT in
|> the host.
|
|No, it's fundamentally different in that the packet delivered 
|to the upper
|layer at the far end is identical to the packet sent by the 
|upper layer.
|It's vital to distinuguish reversible mutation of the packet 
|from irreversible
|mutation. So I would put shim6 and map-and-encap together; they are
|isomorphic viewed from the upper layer.

Well, we should agree to disagree.  I don't see it as at all vital to care
about reversible mutations.  We do packet remarking (i.e., DiffServ) and
it's never seemed like a significant issue.

While I grant you that they would seem to be almost isomorphic from the
upper layer, modulo corner cases, I can't help but want to view
architectures from more than immediately above them.  That view would seem
to be like judging bridge architectures by only looking at the surface of
the road deck.  One has to look at the underpinnings as well.

Tony

---

From: [email-masked]
Date: Sat, 3 May 2008 09:29:39 EDT

In einer eMail vom 02.05.2008 17:55:18 Westeuropäische Normalzeit schreibt  
[email-masked]:

Folks,

On this thread I suggested to relax the IPv4 depletion issue by  replacing 
the Multicast addresses with a new "Multicast" Protocol Type combined  with the 
sender's Unicast address. Indeed, the reaction was absolute silence. I  
expected at least opposition by referring to backward compatability (what is  taken, 
is taken) and that it may need some flag day, announced well in  advance. 
IMO, who can check for class D, may as well check for a new protocol  type. But 
the reaction was a storm of unsent messages.
 
I also meant it architecturally: I think the type of operation (or should I  
say TOS ?) is worth to be indicated in the header. It could be p2p-Unicast as  
well as p2p-Anycast, p2mp-Multicast, p2mp-Broadcast, mp2mp-Multicast,  
mp2mp-Broadcast, and (who knows ) mp2p. Indicating the type of operation by  means 
of different address ranges is a bad design.
Imagine, at some point in time in the future, there were some desire for  
multiple address families.
Should then each AFI be combined with a respectively special address  range 
as to indicate the type of processing? It would even be worse  -architecturally.
 
Heiner

---

From: "Tony Li" <[email-masked]>
Date: Sat, 3 May 2008 23:02:00 -0700

Hi Brian,

|I realised that this apparent disagreement is because we've
|been implictly assuming that the only valid taxonomy for solutions
|is a hierarchy. If you root your hierarchy in the upper layer
|viewpoint, you get a different tree than if you root it in
|the routing viewpoint.
|
|What we actually need is a facet-based taxonomy. That is what
|someone (Melinda Shore, to be precise) pointed out to Scott Brim
|and me when we were developing RFC 3234. If we describe things
|that way, I suspect we won't disagree at all.
|
|[Google will find lots of stuff about facet-based taxonomies,
|and their inventor S.R. Ranganathan, e.g.
|http://www.miskatonic.org/library/facet-web-howto.html ]

Thank you very much.  I think that's very intriguing.  I encourage other
folks to check it out.

Tony

---

From: [email-masked]
Date: Sun, 4 May 2008 03:43:17 EDT

Faceting classification 
(_http://www.miskatonic.org/library/facet-web-howto.html_ (http://www.miskatonic.org/library/facet-web-howto.html)  ,  very 
interesting ) :
 
In my last email, see also below, replace the term  "architecturally" with 
"from the point of view of faceting classfication" !  The Type of 
Operation/Service/Process is a perfect fit for Faceting  Classification.
 
Heiner

In einer eMail vom 03.05.2008 15:31:56 Westeuropäische Normalzeit schreibt  
[email-masked]:

 
Heiner

---

From: Ricardo Oliveira <[email-masked]>
Date: Mon, 5 May 2008 00:49:39 -0700

Xiaohu and all,

Routing purely by geographical location is not viable since routing  
is done per policy and traffic exchange agreements between ISPs and  
not by location.
Said that, and as mentioned in this list before, GIRO is a solution  
that takes advantage of geographical info in the address, while  
keeping policy routing between ISPs. The closest solution to GIRO  
pointed bellow is GSE, with the difference that in GIRO the local  
address is not rewritten at border routers, but rather appended to  
the prefix advertised in BGP.

--Ricardo

---

From: Ricardo Oliveira <[email-masked]>
Date: Mon, 5 May 2008 01:15:36 -0700

Just to clarify: in GIRO there's no map'nencap or header manipulation 
(GSE), and therefore GIRO is different from the proposals bellow.  
GIRO addresses are structured in two parts, internal and external.  
The external part is the one announced in BGP, whereas the internal  
part is used for routing inside the destination net;  but all pkts  
carry always the same address. More details at http://www.cs.ucla.edu/ 
~rveloso/papers/giro.pdf

Thanks,

--Ricardo

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 5 May 2008 08:29:20 -0700

> effective mandate of the topology.

well said.
Xiaohu, please let us know if there is a plan to submit such a proposal.

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 5 May 2008 08:38:48 -0700

On May 2, 2008, at 12:17 PM, David R Oran wrote:

> The network/transport boundary is inside hosts and is emphemeral.  
> The salient questions, at least to me, are:
>

an excellent set of questions.
it seems that the 3 branches above can be expressed by the answers to  
the above questions.

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 5 May 2008 08:51:33 -0700

> It fits in none of the categories that Lixia defined.

Just to clarify: do you mean that "fix naming" is not in any of the  
branches mentioned in my msg?
(the text below suggests the answer is yes)

> nor is it address rewriting, nor ...)

Here is my personal view:
- naming on Internet is a very important issue.
- it is also very broad, concerning multiple layers of the protocol  
stack.
- there are inter-dependencies between naming at diff layers.
- In solving the routing scalability problem,
   we need a clear understanding of, as far as naming is concerned,
   (a) what we depend on the lower layers
   (b) what we may affect on the higher layers
- It is beyond our charter to offer a solution for the
   naming problem across all the layers of the protocol stack.
- IP/routing layer solution should focus on our own problem at hand,
   once we make the design decision here, we'd be in much better
   position to handle upper layer naming issues.

Lixia

---

From: Randall Atkinson <[email-masked]>
Date: Mon, 5 May 2008 11:04:32 -0700

% Just to clarify: do you mean that "fix naming" is not in any
% of the branches mentioned in my msg?

Yes.

% Here is my personal view:
% - naming on Internet is a very important issue.

Agree.

% - it is also very broad, concerning multiple layers of the
%   protocol stack.

That claim is not necessarily true.

% - there are inter-dependencies between naming at diff layers.

At present, this is often the case, but is not always the case.
It is not necessarily true going forwards.

% - In solving the routing scalability problem,
%   we need a clear understanding of, as far as naming is concerned,
%   (a) what we depend on the lower layers
%    (b) what we may affect on the higher layers

I can't follow the above.

% - It is beyond our charter to offer a solution for the
%    naming problem across all the layers of the protocol stack.

That is not obvious from a plain reading of the current charter.

In any event, there are architectural concepts that might be applied
that would not require ALL layers of naming to change.

% - IP/routing layer solution should focus on our own problem at hand,
%   once we make the design decision here, we'd be in much better
%   position to handle upper layer naming issues.

The defined problemS in the charter, all of which are in scope,
go beyond site multi-homing to explicitly include other things
(e.g. mobility).

ALL of the problems in the RG charter need to be addressed,
not just the site multi-homing issue.

As an example, reading IEN-1 might suggest that modifying the sundry
transport-protocols to not include location information in the pseudo-header
is  one possible solution approach.  (It might or might not be the
*preferred* approach, but that is a separate question.)  That approach
is neither translation, nor map-and-encap, nor ....

Yours,

Ran
[email-masked]

---

From: xuxiaohu 41208 <[email-masked]>
Date: Tue, 06 May 2008 16:55:12 +0200

> > well known issues with geographic aggregation.  At the very 
> least,  
> > these
> > include the resulting common interconnect within the geographic 
> area  
> > and the

Hi Lixia,

yes, I plan to submit a upgraded version of the HRA proposal soon. In this version, I hope to embed some geographical information into the locator domain ID and simultaneously define the hierarchical host identifier with embeded organization affiliation by borrowing some idea from CGA.

Best wishes,
Xiaohu Xu

---

From: Scott Brim <[email-masked]>
Date: Tue, 6 May 2008 15:52:52 -0400

> It should be noted that some folks come at things with an alternate

I would go with this conceptual framework, but not call it "transport",
since that can be confusing.  The point is that the solution is in the
endpoints (i.e. transport layer) not in the network.  Perhaps just say
"endpoint-based".

On 5/2/08 9:37 PM, Brian E Carpenter allegedly wrote:
> mutation. 

Agreed.  That's why translation is different from encapsulation.
However ...

> So I would put shim6 and map-and-encap together; they are

They deliver the same result from the point of view of the application,
but do so with very different requirements and placement of functions
and complexity.  I'm still in favor of "map/encap", "translation", and
"endpoint-based".

On 5/2/08 10:33 PM, Joel M. Halpern allegedly wrote:
> the upper layers is carried and preserved.  

But to get to that level, where they are the same, you have to get above
transport, and up there every proposal so far is essentially the same.
The information of interest to the upper layers is carried and
preserved.  So that doesn't distinguish things.

> The biggest difference I see

Having lower layers ignore parts of the existing header just changes
the boundaries of what is semantically meaningful to them.  So far the
functions, and relationships between functions, have not changed, so I
would say that's not a significant architectural change.  However,
the fact that you add the new function is significant.  However
(again), That function can be added independent of whether it uses a
piece of an existing header or not.

Whether extra addressing information is placed in extra encapsulating
headers or is added to existing headers doesn't feel like a huge
difference either, since in either case the e2e information is still
preserved and can be extracted.  But if the e2e information can NOT be
extracted -- if I am an endpoint and I see someone changing all my
headers between me and my friend -- that feels like a significant
architectural change.

Scott

---

From: Scott Brim <[email-masked]>
Date: Tue, 6 May 2008 16:00:57 -0400

> Thank you very much.  I think that's very intriguing.  I encourage other

Melinda is the one with the degree in Information Science, and yes she
did mention faceted classification to us.  The idea is that within a
particular attribute you might have a hierarchical taxonomy, but an
object can have multiple independent attributes, and they can be
ordered in priority arbitrarily.  

However, we don't *want* to be able to order attributes arbitrarily
:-).  We can certainly use a faceted classification system to describe
everything, and to index everything, but I will be surprised if we can
use it to pick a solution.

Then again I've finally come to believe that the functions are more
important than what we feed to them.  Instead of discussing naming of
nouns such as "address", let's first talk about interactions between
verbs such as "encapsulate".  Once we have that written down I hope
the attributes of what is fed to the "verbs" will be less important.
I'll try to write more about this soon.

Scott

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 06 May 2008 16:16:01 -0400

Focusing on one comment:

Scott Brim wrote:
...
>> Actually, the way I look at it, both encaps and rewrite 
>> (map-and-encaps and translation) have the property that the 
>> information of interest to the upper layers is carried and preserved.  
> 

Well, at the very least it distinguishes the proposals from NAT.  And 
while we all agree that classic NAT as it is practiced is a bad idea, it 
is important to remember what properties we care about.  Particularly 
when we are considering translation solutions.

Joel

---

From: Robert Bonomi <[email-masked]>
Date: Tue, 6 May 2008 17:59:16 -0500 (CDT)

> From: Scott Brim <[email-masked]>
> Date: Tue, 6 May 2008 15:52:52 -0400

Looking strictly at methodologies for change, the available options are:

   1) 'Replacement.'  Tear out the old-style infrastructure and replace it 
      "in toto".  This requires the origin point to do things the 'new way',
      the destination point to do things the 'new way', and requires` all 
      intermediate points to do things the 'new way', as well.

      NOTE:  It may be possible for old-style and new-style protocols to 
      co-exist on the wire, but there is -no- inter-operation between the 
      new-style and old-style nodes.

      Anything/everything 'new style' operates exclusively in the new-style
      domain.  Everything old-style operates exclusively in the old-style
      domain.  If an end-point wishes to be present in both domains, that
      _end-point_ must implement both protocols itself.

      Advantages: option for 'clean slate' design; no 'historical baggage'
      to deal with; single, uniform methodology end-to-end; any device and/or
      application works 'anywhere'.

      Disadvantages:  either/or solution; requires a 'flag day' cut-over;
      chicken and egg acceptance problem; reaching critical mass; possible 
      balkanization, etc.  

   2) 'Translation.'  Allows old-style end-points to communicate with new-
      style end-points *IF* a suitable 'gateway' is interposed "somewhere.
      "Network" elements can be either old-style or new-style depending on 
      which side of the translation gateway they are on.  In fact they _must_ 
      be either old-style or new-style on the appropriate sides of the gateway.
      multiple translations can occur on a path.  "old->new-old" is lossless,
      "new->old->new" _can_ result in partial loss of functionality.

      Functional requirements:
	 (1) Anything attempting to communicate with an 'old-style' system 
	     must not rely on any 'features' of the new-style protocol that 
	     cannot be 'back-mapped' into the old-style communication.
         (2) An "old->new->old" double-translation must be lossless. i.e.,
	     as if there had been no translation at all.

      Advantages:   "mixed-mode" operation possible. "anything can talk to
      anything", as long as there is _a_ path with required translation 
      capabilities between the two end-points.  Network infrastructure
      can move  more-and-more to 'new style' (from center outwards), by 
      simply moving the translation points closer to the end-users.

      Disadvantages: "Translation" devices require a fairly intimate knowledge
      of both new-style and old-style protocols, and there are far too many
      opportunities for Murphy to stick his oar in when _exact_ equivalence 
      between old- and new-style functionality doesn't exist.

   3) 'Encapsulation.'  Implement an arbitrary new-style layer 'underneath'
      what the end-users see.  This preserves/presents the 'appearance' of
      the old-style protocol to the outside world, _while_ being free to
      do  "whatever seems appropriate" in the infrastructure, *without* any
      visible impact (except possibly indirectly, in a performance change)
      to external users.
      
      Functional requirement:
	 (1) a method of determining which new-style device at the far edge
	     of the new-style network should recieve packs for old-style
	     address '0xDEADBEEF'. This requires an information flow _from_
	     the old-style domain _into_ the new-style one.  Since the
	     infrastructyre layer is normally 'utterly invisible' to the
	     end-user layer, this requires the addition of specialty devices
	     that have conscious visibility at both layers.

      Advantages: complete decoupling of end-user requirements from the infra-
      structure.  ANY/ALL future infrastructure changes are essentially 
      invisible to the end user.  "Virtual" clean-slate to design on, any/all
      'historical baggage' is simply data to the new-style infrastructure.
      _CAN_ be rolled out incrementally although the main benefits occur only
      when (at least near-) "universal" adoption has occured.  "Encapsulation"
      is easy to do.

      Disadvantages:  must now maintain tables of 'mapping' information not
      formerly needed.  Possible additional latency on connection initiation
      depending on how this 'mapping' information is (a) organized, and 
      (b) disseminated.  Additional hardware required to perform the 
      encapsulation and mapping. "Mapping" is is a -hard- issu issue.

---

From: "Tony Li" <[email-masked]>
Date: Wed, 7 May 2008 11:47:49 -0700

Hi Scott,

|> 	- Map-n-encap
|> 	- Translation
|> 	- Transport
|
|I would go with this conceptual framework, but not call it "transport",
|since that can be confusing.  The point is that the solution is in the
|endpoints (i.e. transport layer) not in the network.  Perhaps just say
|"endpoint-based".

Well, that's one perspective.  My issue with that is that there are
solutions (e.g., SHIM6) that are endpoint-based but not in the transport.
My perspective is that where a function is located physically is less
signficant architecturally than where it fits in amongst the various
subsystems.  So, for example, I consider SHIM6 to be a translation technique
in the network layer and the fact that it happens in the end-host is an
engineering nuance.  In your division it would seem to be ambiguously split
because it is both a translation technique and endpoint-based.

Put another way, I think that this results in basis vectors that aren't
orthogonal.

Tony

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 7 May 2008 17:00:45 -0400

On  6 May 2008, at 18:59, Robert Bonomi wrote:
>      "in toto".

4) Make changes that are incrementally deployable -- and do so
    in a backwards compatible way.  Hypothetical Example: define
    a new option or flag that indicates the TCP checksum does not
    include location information for that session.  If the option
    is not present, fall back to the old way of doing things to
    maintain interoperability.  Permits gradual transition to a
    new naming architecture that decouples transport-layer state
    from the location or point of network attachment or interface
    being used at a particular instant in time.

Cheers,

Ran

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 May 2008 07:56:17 +0200

Lixia, Dave,

> it seems that the 3 branches above can be expressed by the answers to

Yes. A possibly important subcase of c is what kind of addresses are
exposed to applications. Some of the proposals on the table expose
non-routable identifiers, some don't. This affects how referrals work,
whether applications need to use ice-like mechanisms when talking to
each other, etc.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 May 2008 08:07:34 +0200

Robert,

>       visible impact (except possibly indirectly, in a performance change)
I think there is something missing here. For instance, as you know we
have encapsulation based mechanisms, but we're finding out that even
with those, we have to figure out how the "old" and the "new" world
should talk to each other. So if 3) really means an overlay, you need to
know how to exit from and return to the overlay in order to talk to
hosts in the existing Internet.

This leads me to conclude that the real options on the table will in any
case include some form of translation. I do not mean translation in the
NAT sense here, by the way. What I mean is that A (site) thinks he is
talking the new protocol, B (site) thinks he is talking the old
protocol, and somewhere in between there a C that converts between the
two. For instance, a LISP PTR or Six/One Router 1-1 NAT.

Jari