Subject: [RAM] Re: [arch-d] mailing lists and follow-ons to the IAB Routing & Addressing workshop

From: [email-masked] (Noel Chiappa)
Date: Thu, 7 Dec 2006 15:09:41 -0500 (EST)

> From: David Meyer <[email-masked]>

    > discussion of what the follow-on's to the workshop might be on various
    > lists. What I'm hoping we can do is consolidate that discussion on
    > [email-masked].

I would take a slightly different view, and think there is (non-overlapping)
role for both (and I hope the various I* bodies won't take offense at me for
differing a bit with this plan; I really do have everyone's best interests at
heart here.)

First, this is a big problem, and there are a number of different technical
areas; with a single forum, it might get kind of Babel-like. Second, and more
important I think, I find that in any wide-ranging discussion like this, the
routing stuff (which is usually the hardest problem) gets the short end of
the stick. (I have my opinions on why that happens, but I'll leave them be
for now.) And, I hope I don't need to point out, it was coming problems with
the routing which have led to this.

IMNSHO, it's really unacceptable to work on this problem and not give a key
role to consideration of how the routing is going to work. And to make sure
the routing is going to work, we have to dive into the muck and tackle the
routing technical issues in some detail, to make sure it all really works. So
we have to drive pretty quickly to considering the technical details of how
the routing is going to work, I think. And that's something the people who
seem to have energy available to discuss things have been fairly loathe to do,
despite some not-so-subtle prods from me.

So I think keeping the RAM list focused on just the routing stuff is really
pretty critical; it's clear that that's a really substantial discussion.
Discussion of other related topics there (e.g. separation of location and
identity) would just distract from that, and that's where A-D list would be
useful.

I feel that discussion of such issues as end-end naming, whether we have to
use the "jack-up" model (in which end-hosts remain totally unmodified), etc,
etc, really ought to be kept on A-D, to keep RAM clear for these routing
issues.

To keep this from getting too long, I'll send out a separate message in a
couple of hours (just on RAM) giving a little more detail on the points I
think RAM needs to work on, and how I think it can best make progress on them.

	Noel

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: David Meyer <[email-masked]>
Date: Thu, 7 Dec 2006 13:13:06 -0800

> think RAM needs to work on, and how I think it can best make progress on them.

	Thanks Noel.  No disagreement on my part.

	--dmm

---

From: John Leslie <[email-masked]>
Date: Thu, 7 Dec 2006 18:39:02 -0500

>> lists. What I'm hoping we can do is consolidate that discussion on

   It _will prove difficult to keep general architecture separate from
routing table growth. I agree with David that keeping a complete (enough)
record of the discussion on the RAM list is a reasonable request.

   This will probably  result in a fair amount of cross-posting. :^(

> I would take a slightly different view, and think there is
> (non-overlapping) role for both (and I hope the various I* bodies won't
> take offense at me for differing a bit with this plan; I really do have
> everyone's best interests at heart here.)

   It's important to consider the stated purpose of the RAM list:
] 
] This list serves as a technical discussion forum for all members of the
] IETF community that are interested in continued discussion of the
] analysis of and potential solutions to the continued growth in the size
] and dynamics of the Internet's default free zone routing table.

   We need, IMHO, to respect that.

> First, this is a big problem, and there are a number of different
> technical areas; with a single forum, it might get kind of Babel-like.

   A very definite risk!

> Second, and more important I think, I find that in any wide-ranging
> discussion like this, the routing stuff (which is usually the hardest
> problem) gets the short end of the stick. (I have my opinions on why
> that happens, but I'll leave them be for now.) And, I hope I don't
> need to point out, it was coming problems with the routing which have
> led to this.

   I don't mind stating my opinion why: too few folks understand routing,
while too many insist on talking about it.

> IMNSHO, it's really unacceptable to work on this problem and not give
> a key role to consideration of how the routing is going to work.

   Agreed.

> And to make sure the routing is going to work, we have to dive into
> the muck and tackle the routing technical issues in some detail,
> to make sure it all really works.

   Agreed. This is perhaps _too_ hard on a fully open list...

> So we have to drive pretty quickly to considering the technical details
> of how the routing is going to work, I think. And that's something the
> people who seem to have energy available to discuss things have been
> fairly loathe to do, despite some not-so-subtle prods from me.

   As any rational expert should be, IMHO, until s/he is assured of
protection from "feature creep".

> So I think keeping the RAM list focused on just the routing stuff is
> really pretty critical; it's clear that that's a really substantial
> discussion.

   I agree that discussing routing details is currently more appropriate
for RAM than [arch-d]. I am even willing to (try to) help Noel discuss
it there. But I don't think it a good idea to try to limit that list
to routing discussion.

> Discussion of other related topics there (e.g. separation of location
> and identity) would just distract from that, and that's where A-D list
> would be useful.

   IMHO, _some_ separation of location from identity will be necessary
in order to make routing scale acceptably. It seems unwise to call such
discussion out-of-scope.

> I feel that discussion of such issues as end-end naming, whether we
> have to use the "jack-up" model (in which end-hosts remain totally
> unmodified), etc, etc, really ought to be kept on A-D, to keep RAM
> clear for these routing issues.

   End-to-end naming probably belongs on [arch-d].

   "Jack-up" is likely necessary for short-term fixes. It too should be
in-scope for discussion on RAM.

> To keep this from getting too long, I'll send out a separate message
> in a couple of hours (just on RAM) giving a little more detail on the
> points I think RAM needs to work on, and how I think it can best make
> progress on them.

   Sounds like a good idea to start discussion!

--
John Leslie <[email-masked]>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 7 Dec 2006 23:02:12 -0500

I think Noel makes good sense here but suggest one caveat.

When and if identifiers and naming appears as imperative to any
architecture we have to take time to delve into them not just put them
on hold and that will take us away from just routing a bit but only for
routing not transport and I fear if we don't do that we may not see bug
in the routing architecture of future analysis and development in RAM.

/jim 

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]] 
> Sent: Thursday, December 07, 2006 3:10 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [RAM] Re: [arch-d] mailing lists and follow-ons to 
> the IAB Routing &Addressing workshop
> 
> (non-overlapping) role for both (and I hope the various I* 
> bodies won't take offense at me for differing a bit with this 
> plan; I really do have everyone's best interests at heart here.)
> 
> 
> First, this is a big problem, and there are a number of 
> different technical areas; with a single forum, it might get 
> kind of Babel-like. Second, and more important I think, I 
> find that in any wide-ranging discussion like this, the 
> routing stuff (which is usually the hardest problem) gets the 
> short end of the stick. (I have my opinions on why that 
> happens, but I'll leave them be for now.) And, I hope I don't 
> need to point out, it was coming problems with the routing 
> which have led to this.
> 
> IMNSHO, it's really unacceptable to work on this problem and 
> not give a key role to consideration of how the routing is 
> going to work. And to make sure the routing is going to work, 
> we have to dive into the muck and tackle the routing 
> technical issues in some detail, to make sure it all really 
> works. So we have to drive pretty quickly to considering the 
> technical details of how the routing is going to work, I 
> think. And that's something the people who seem to have 
> energy available to discuss things have been fairly loathe to 
> do, despite some not-so-subtle prods from me.
> 
> 
> So I think keeping the RAM list focused on just the routing 
> stuff is really pretty critical; it's clear that that's a 
> really substantial discussion.
> identity) would just distract from that, and that's where A-D 
> list would be useful.
> 
> I feel that discussion of such issues as end-end naming, 
> whether we have to use the "jack-up" model (in which 
> end-hosts remain totally unmodified), etc, etc, really ought 
> to be kept on A-D, to keep RAM clear for these routing issues.
> 
> To keep this from getting too long, I'll send out a separate 
> message in a couple of hours (just on RAM) giving a little 
> more detail on the points I think RAM needs to work on, and 
> how I think it can best make progress on them.
> 
> 	Noel
>