Subject: [RADIR] Re: Routing & Addresssing problem statement

From: Thomas Narten <[email-masked]>
Date: Fri, 01 Jun 2007 11:29:14 -0400

Hi Ross.

Thanks for the comments!

> I understand that section 6 has not been written out in detail,
> and is likely to be updated / changed in the process of fully
> fleshing it out. However, I do have some general concerns
> about what is currently there, or perhaps more with what is
> not there yet (ie, perhaps what is there is not complete).

> Three issues with point 1:

> One is that if we limit the size of the DFZ routing load by
> exploding the size of a different routing table (perhaps by
> putting very large tables on the edge), then this does not
> necessarily help.

I agree with this point, but I'd argue this is sliding towards
solution requirements (hmm, there is a difference between the problem
statement and solution requirements). I.e., pushing the pain elsewhere
from the DFZ may solve the DFZ problem, but cause another equally bad
one. That said, I'm not at all sure the concern you mention needs to
be called out explicitely.  I think it kind of goes without saying
that a solution better not cause a problem somewhere else that is just
as bad as the original problem...

> Another issue with point 1 is that I don't see us have having,
> or even discussing, any method that actually puts a limit on
> the overall routing table size, or that prevents an ISP from
> advertising a very large number of prefixes. I suppose that if
> this got too egregious, then perhaps other core ISPs would
> get together and agree to dump the excessive routes (which
> would mostly likely cause lots of excitement). This of course
> relates to the point that Tony made:

So, is the lack of a firm/absolute upper bound really part of the
problem definition? (e.g., can't the same thing happen within an AS
using OSPF?) What we really want is some level of assurance that there
are practical limits on the overall table size and that they match
what then-current hardware can reasonable handle. But couldn't that
could be based on social or other factors as well?

We'd really be raising the bar if we said the problem included
"preventing DOS attacks".

> >This probably also should somehow capture that the growth rate is
> >unconstrained, either architecturally or through regulatory dictum.
> >Thus, the challenge is not only to cope with current growth rates,
> >but to also cope with whatever arbitrary growth rate is presented in
> >the future...

> Even if we have a way to map all addresses to fully topological
> addresses at the edge, we don't currently have any way to enforce
> the implication that only topologically assigned and aggregatable
> **and aggregated** addresses are actually advertised.

Hmm. Is this yet another part of the problem statement, or is this
heading into the more general "all the things we'd like to see better
in a new architecture"? I worry about drifting into the latter,
because we'll end up with an intractable problem.  I'd probably be OK
with this as a desireable property, as opposed to a requirement.

> Also, I am not sure whether we want to "reduce the growth rate of
> the DFZ routing load", or if we want to "ensure that the growth rate
> of <some routing load, including DFZ> stays within technically and
> economically manageable bounds".

DFZ is where the main pain is, from what I'm hearing...

> Finally, I don't think that we are currently certain that it is
> *possible* to do all that is in section 6, without causing other
> unfortunate problems. I suppose that the "without causing other
> unfortunate problems" and "only do it if it is actually possible"
> might be implicit, but I am wondering if we want to at least say
> something about this.

I was assuming this is implicit... Do others have thoughts on this?

Thomas

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

---

From: Ross Callon <[email-masked]>
Date: Fri, 01 Jun 2007 14:30:09 -0400

At 11:29 AM 6/1/2007 -0400, Thomas Narten wrote:
>...

I am not so concerned about the lack of a firm upper bound. I am
concerned that there isn't any group (including us) that has any
way to push back on, or limit, the table growth. We can (assuming
that we can work out details) design an approach that facilitates
operation of the Internet with a smaller table, but we don't have any
way to push back when people do things that cause table growth.

There is a question regarding whether the IETF should be the ones
who design a method of pushing back. However, there is an equally
large question regarding whether any other group is the right one
either.

>"preventing DOS attacks".

I didn't mean to bring in any thought of more "traditional" DoS
attacks.

>with this as a desireable property, as opposed to a requirement.

Desirable property or general goal seems reasonable to me.

>DFZ is where the main pain is, from what I'm hearing...

I was intending that the phrase "limit growth rate" might be
better stated as "ensure that the growth rate stays within
technically and economically manageable grounds".

>I was assuming this is implicit... Do others have thoughts on this?

Thanks, Ross

---

From: Thomas Narten <[email-masked]>
Date: Fri, 01 Jun 2007 15:16:33 -0400

> way to push back when people do things that cause table growth.

Here is what I put into the document based on Tony's comments:

   Finally, the scalability challenge is aggravated by the lack of any
   limiting architectural upper-bound on the growth rate and a weakening
   of traditional social constraints on the growth rate that have helped
   restrain growth so far.  Going forward, there is considerable
   uncertainty whether future growth rates will continue to be
   sufficiently constrained so that the routing load can be handled by
   routers available at that time.

So I think we are in agreement and share the same  concern.

> large question regarding whether any other group is the right one

Well, right now it is the RIRs (via policies like PI) and what
operators actually do. So yes, there are risks/uncertainty. 

It's unclear what the IETF can do, though we may have more options if
we make an architectural change like ID/LOC splitting.

> technically and economically manageable grounds".

I like this phrasing.  I will see about using it in the document.

Thomas