Subject: [RRG] December meeting: call for contributions

From: Tony Li <[email-masked]>
Date: Wed, 5 Sep 2007 13:24:28 -0700

Hi all,

It looks like our anticipated meeting on Dec. 7th is running into  
some logistical issues, so instead, we've asked for 2 2.5 hour  
meetings interleaved within IETF that same week.  As usual, those  
sessions are very much subject to change, so we'll keep you informed  
as the Secretariat updates us.

At this point, we'd like to open the agenda for contributions.  As  
always, new proposals are very much welcome.  Contributions must have  
links to documents that participants may review prior to the  
meeting.  Internet drafts are welcome, but not required.  The cutoff  
dates for Internet drafts are: Nov. 12 for new drafts, and Nov. 19  
for revised drafts.  Publish early and often.  ;-)

Please send your requests for time on the agenda to both Lixia and  
myself.

Thanks,
Lixia & Tony

--
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: David Kessens <[email-masked]>
Date: Wed, 5 Sep 2007 21:24:35 -0700

Tony, Lixia,

> for revised drafts.  Publish early and often.  ;-)

I was wondering whether there are plans to actually make a selection
out of the different proposals, or see if a design team can be formed
that will investigate a way forward that is based on several of the
proposals. 

Quite honestly, I am a bit concerned that continuing work in parallel
on all the different proposals might easily create a situation where
it becomes very difficult to decide on a single solution as people
have invested already quite a bit of their time and energy on a
particular track.

David Kessens
---

---

From: Eliot Lear <[email-masked]>
Date: Thu, 06 Sep 2007 10:01:01 +0200

Hi David,
> have invested already quite a bit of their time and energy on a

My concern tends to run the other way.  I think a design team would be 
premature.  As one author, I'm not wedded to my design or to LISP, for 
that matter.  I do think several key things are needed before we get 
into design committees:

    * A clear understanding of which problems each solution solves
    * Some experimentation to see how each solution behaves
    * Some analysis that looks at stress points with each mechanism
    * and a summary of all of this that compares approaches.  Robin
      Whittle made an attempt at such a thing, but it would be better
      when we have all had a bit more hands on.

Now don't get me wrong - I understand that things can work in the small 
and not in the large.  I think that's why the scaling analysis is 
crucial.  It needs to take into account motivations and behaviors, which 
are always tricky at best.  For instance, what if one of these 
approaches actually encourages disaggregation into the existing BGP 
core?  Could that happen?

For my part, I've set out to do a bit of the stress point analysis in 
the next rev of the NERD draft, but it is woefully incomplete.  Also, my 
goal for that draft is for it to be published as an EXPERIMENTAL RFC.  
At such time as we actually want to standardize, then I think a design 
team would be appropriate.  I'm just not there yet.

Regards,

Eliot

---

From: Tony Li <[email-masked]>
Date: Thu, 6 Sep 2007 01:24:03 -0700

Hi David,

Speaking for myself...

> that will investigate a way forward that is based on several of the

The goal is to make a recommendation as to how we should proceed.

Frankly, that recommendation isn't possible until there is at least one
proposal that has stabilized and we're not in a rush to make a  
recommendation
on something that is still being thought through.

I would hope that design teams, collaborations, mergers, etc. will  
continue
to happen until we reach the point where we do have a recommendation.

> have invested already quite a bit of their time and energy on a

My experience says that people become emotionally invested in their
proposals even before they submit the first Internet draft.  ;-)   
While I
grant you that deciding early can reduce this effect, I'll point out  
that
making a poor recommendation quickly is not a net improvement.

My (personal) $.02,
Tony

---

From: Jari Arkko <[email-masked]>
Date: Thu, 06 Sep 2007 11:45:59 +0300

I do see David's point. However, as Elliot pointed out...

> I do think several key things are needed before we get into design
> committees:

I would agree with this. At this point, I still see significant question
marks
in the different approaches, and the priority should be in getting the
fundamental issues solved than debating about whose proposal to take
or what merger to perform.

In other words, I think we are still exploration phase. Getting the various
folks on the same page would be good, but I would suggest starting
with something else, like getting a common understanding of what
the remaining issues are.

Jari

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 6 Sep 2007 10:14:05 -0400 (EDT)

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

    > The goal is to make a recommendation as to how we should proceed.

I'm not sure that's such a good approach. Every time the I* has tried this,
first it gets really political, and then it often doesn't have the desired
outcome. I think the I* can best serve in the following ways:

- Bring people together to discuss the technical issues
- Educate the larger community on what the technical issues are
- Allow people who are working on designs to do so in an open manner:
-- Make the specifications freely available to all
-- Specifically, receive feedback on their designs
-- Next, when it comes to doing final specifications, providing a forum
	to do so in an open way (as opposed to the small design team which
	is critical at the early stages of a design)

When it has tried to do just these things, it has succeeded very well. When
it tries to make a pick, it often falls on its face.

	Noel

---

From: Tony Li <[email-masked]>
Date: Thu, 6 Sep 2007 09:57:21 -0700

> it tries to make a pick, it often falls on its face.

Noel,

I hear ya.  However, the group is explicitly chartered by the IRTF to  
make
a recommendation.

Tony

---

From: David Kessens <[email-masked]>
Date: Thu, 6 Sep 2007 10:23:46 -0700

Tony,

> to happen until we reach the point where we do have a recommendation.

I understand this and I have no problem with that. What I was looking
for is a bit more of a timeline until which time we keep looking at
different proposals. Basically, deadlines work real well to get people
motivated to send in their proposals and to get them more refined to
the point where they are stable enough for a serious analysis.

To say it in a different way: what is the plan to get from here to the
recommendation ?

David Kessens
---

---

From: [email-masked]
Date: Thu, 6 Sep 2007 14:06:52 EDT

AFAIK 151 research projects in the category "the network of the  future"  
have qualified for being funded by the EU. So I am curious about  the many 
contributions to be presented to the RRG soon. Unfortunately our  research project 
was rated to be POOR and was therefore rejected. The poor  objectives were:
- developing a hierarchical routing protocol which fits for the combined  
intra- and interdomain network such that it will scale (1-2 K instead of  
200-300K FIB entries) for good and that UPDATE-churn is avoided (the more  distant 
the lesser the churn)
- providing multipath forwarding along shortest paths, along detouring  but  
loop-free paths, along loop-endangered paths but providing support to  ensure 
loop-less forwarding.
- real-time traffic balancing based on a p2mp/mp2p message  ping-pong between 
an (overloaded) transit node and precisely all nodes  of its specific 
"ingress sector" wrt to traffic towards a given destination  node
- shared network maintenance by a set of arbitrarily spread "controler  
nodes" based on the fact that if each network node knows the entire topology as  
well as these controler nodes, any node may determine for every node and every  
link by which controler node it is to be controled.
- Multihoming in the light of the developed extremely scalable hierarchical  
routing protocol (see above).
 
This hierarchical routing protocol wouldn't be prefix-centric any more.  
Hence IPv6 (remember: factor 4 to make the current situation worse)  wouldn't be a 
problem, nor a longer life of  IPv4 as even single IP addresses rather /8 
blocks might be  taken from the IANA-reserve pool.  
 
I also referred to the so-called Rhekter's law and added that the right  
choice should be made and that the terrible mistake as to make the wrong choice  a 
second time should be avoided. I am afraid that CONS (etc.)  is about to  
make this terrible mistake. It is a huge machinery for distributing/retrieving  
routing relevant information which we could get for free - not in the same way, 
 but in a much better i.e.  scalable way, which is not   afraid of mobile 
applications. 
IMHO: Yakov's remark was not upgraded to a law, but downgraded to a bon  mot. 
In some way, it was never taken  seriously - unfortunately. 
 
Heiner

In einer eMail vom 06.09.2007 16:16:04 Westeuropäische Normalzeit schreibt  
[email-masked]:

Noel

In einer eMail vom 05.09.2007 22:26:50 Westeuropäische Normalzeit schreibt  
[email-masked]:

Hi  all,

At this point, we'd like to open the agenda for  contributions.  As  
always, new proposals are very much  welcome.  

Thanks,
Lixia &  Tony

---

From: "William Herrin" <[email-masked]>
Date: Thu, 6 Sep 2007 14:31:15 -0400

On 9/6/07, [email-masked] <[email-masked]> wrote:
> Unfortunately our research
> project was rated to be POOR and was therefore rejected. The poor objectives
> were:  [...]

Heiner,

There's a developed extremely scalable hierarchical routing protocol?
Really? What is it?

Regards,
Bill Herrin

-- 
William D. Herrin                  [email-masked]  [email-masked]
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: [email-masked]
Date: Thu, 6 Sep 2007 16:18:26 EDT

All of the mentioned objectives are based on (or are to extend) an  algorithm 
which is shown by a network graphic on my _www.hummel-research.de_ 
(http://www.hummel-research.de/) . At first I  can convert all network links to arrows 
(arcs) which all are directed towards  a given (red) node. Based  on this I 
could even create a new geometry  (not Euclid, where two points are 
interconnected by a straight line (no matter  whether this line crosses any swampy land :-))
 
Heiner

In einer eMail vom 06.09.2007 20:32:16  Westeuropäische Normalzeit schreibt 
[email-masked]:

Heiner,

Regards,
Bill Herrin

---

From: Tony Li <[email-masked]>
Date: Thu, 6 Sep 2007 14:07:36 -0700

> To say it in a different way: what is the plan to get from here to the

David,

Unfortunately, research seldom works to schedule, and establishing a
timeline now would probably result in us converging on a half-baked
solution.  I don't think we do anyone a favor if we make a flawed
rush to judgement.

That said, yes, I would like to see us move more rapidly.  If you have
suggestions on how we could otherwise accelerate the process, I'd
love to hear about it.

My guess is that we could motivate more researchers if we could actually
provide funding, but I'm not quite ready to start holding bake  
sales.  ;-)

Tony

---

From: David Kessens <[email-masked]>
Date: Thu, 6 Sep 2007 17:17:57 -0700

Tony,

> solution.  I don't think we do anyone a favor if we make a flawed

But not having a schedule whatsoever is not likely to get us anywhere
within finite time either.

> suggestions on how we could otherwise accelerate the process, I'd

For example, set a review date by which we are going to do a
preliminary review that will throw out at least some of the proposals
so that we don't have to spend time on every meeting on every proposal
even if we already know that it is not going to be the solution.

David Kessens
---

---

From: Tony Li <[email-masked]>
Date: Thu, 6 Sep 2007 18:14:52 -0700

> within finite time either.

Nor will having a schedule.

> even if we already know that it is not going to be the solution.

Not necessary.  So far, proposals seem to be pretty much self-selecting.

Tony

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 6 Sep 2007 21:42:20 -0400 (EDT)

> From: "William Herrin" <[email-masked]>

    > There's a developed extremely scalable hierarchical routing protocol?

http://ana-3.lcs.mit.edu/~jnc/nimrod/docs.html

	Noel

---

From: David Kessens <[email-masked]>
Date: Fri, 7 Sep 2007 09:02:42 -0700

Tony,

> Nor will having a schedule.

Some planning and scheduling does help to get any project to complete.
Whether it is a research project or any other project.

> Not necessary.  So far, proposals seem to be pretty much self-selecting.

What do you mean by this ? How is "self-selecting" supposed to work if
any proposal gets meeting time at the cost of spending less time on
the more promising proposals ?

David Kessens
---

---

From: Tony Li <[email-masked]>
Date: Fri, 7 Sep 2007 10:43:16 -0700

David,

> Whether it is a research project or any other project.

We should then agree to disagree.  We are in a position where we have
volunteer contributors.  Those who are working on their existing  
proposals
are executing well, but those who are working on upcoming
new proposals are simply unknown to us.  We can schedule them until the
cows come home, but that will not cause them to deliver.

> the more promising proposals ?

There are numerous proposals that have been presented that have
effectively thrown themselves out by ceasing to progress.  I invite you
to visit our wiki page (http://www3.tools.ietf.org/group/irtf/trac/ 
wiki/RoutingResearchGroup) for
a more complete list.  Also you might want to review the agendas of the
last two meetings, also on our wiki page, to see exactly the breadth
of what we've covered.  Suffice it to say that after all of these  
proposal
have been reviewed, we appear to only have a few remaining evolving
proposals.

As to meeting time, what we've tried to do is to slant the agenda
heavily in favor of new proposals as we're still in the exploratory
phase, trying to understand the solution space.  Existing proposals
that wish to give us updates are certainly accommodated.  I invite you
to look at the net amount of time that LISP got at the last meeting.

As with the IETF, the RRG meetings are not the sole venue for making
progress on a proposal.  Any proposal is more than welcome to work
offline, form their own mailing lists and interact privately.  The RRG
mailing list and our wiki page are also available for those who prefer
to have broader involvement.  For proposals that feel that this is still
not enough time, they are welcome to follow the initiative that the
LISP team has done and ask for their own independent meeting
time.

Tony

---

From: Scott Brim <[email-masked]>
Date: Fri, 07 Sep 2007 19:02:47 -0400

> the remaining issues are.

Lixia and I still plan to get a "taxonomy" draft together for this
meeting.  You saw some of it in the slides at the Chicago meeting.  The
goal is to distinguish the critical dimensions and to compare/contrast
the different approaches along those dimensions, as an aid to
understanding them.