Subject: Re: [arch-d] It's the routing, people!

From: [email-masked] (Noel Chiappa)
Date: Sat, 11 Nov 2006 13:15:49 -0500 (EST)

> From: Geoff Huston <[email-masked]>

    > I don't see routing melting today.

I'm only here because other people seem to think it's coming, and want to get
moving on a solution. If there is no problem, then this whole discussion is
moot, no?

    > I don't necessarily accept that FIB meltdown is only prevented by
    > changing the routing paradigm, as I still don't accept that FIB = RIB.
    > I see that if per packet performance is critical, and that appears to
    > be the case, then the lookup performed per packet should be fast. But I
    > don't accept that this necessarily implies that you have to perform
    > this lookup over the equivalent of the RIB stuffed into a fast lookup
    > data structure to derive an answer that is of the same order as the
    > number of physical egress choices on the box.

I'm not the person to be discussing that point with. You need to talk to the
people who made the case at the IAB workshop. Apparently they convinced the
people at the workshop, but maybe you see something they don't. I read
through the slides from the workshop, and the conclusions seemed reasonable,
but again, perhaps you see something that changes things.

Do you have some approach in mind that works differently? If so, could you
at least sketch it out for us briefly - a full-blown writeup isn't necessary.

    > I suspect that a better understanding of the semantics of addresses,
    > and the distinction .. about what are the characteristics of the
    > packet's source and destination tag, and the relationship of these two
    > tags to the forwarding path across the network are useful in
    > understanding the relationship to the problem being presented here and
    > the degrees of freedom in the symbol space that we can manipulate to
    > provide mitigation

I'm not sure I fully see what you are getting at here, but this kind of
discussion, about not just the semantics of addresses, but about how those
semantics relate to the computation of paths across the connectivity graph,
would be OK, but I didn't hear that happening.

Again, something with a bit more information as to some new scheme which you
might have in mind would make it possible to examine these issues you raise
above, because at this level of abstraction it's hard to draw any definite
conclusions.

	Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: "Schliesser, Benson" <[email-masked]>
Date: Sat, 11 Nov 2006 19:17:51 -0600

Except, with IPv4 each AS could easily be allocated multiple (non-contiguous, non-aggregateable) prefixes, for instance as they grow over time. With v6 it wouldn't necessarily have to be that way.

Cheers,
-Benson

-----Original Message-----
From: Iljitsch van Beijnum
To: Schliesser, Benson
CC: [email-masked]
Sent: Sat Nov 11 16:37:07 2006
Subject: Re: [arch-d] It's the routing, people!

On 11-nov-2006, at 21:19, Schliesser, Benson wrote:

> Of the approx 23k ASs in the global routing system, only 3k are  
> transit ASs. The other 20k systems are basically end networks that  
> multihome.

[...]

> If we can come up with a good solution to multihoming that removes  
> the need for these end networks to participate in global routing  
> etc, and change policy so that it reflects this in turn, it seems  
> to me that we can materially reduce table size and rate of growth.

How can that be true? There are some 200k prefixes in the global  
table. If there are indeed 20k multihomers, that means only 10% of  
the global routing table can be attributed to multihoming, as  
multihoming functionality only requires a single prefix per  
multihomed AS. (Please note that my statement doesn't preclude people  
from announcing more prefixes for other reasons once they're  
multihomed.)

So _today_ the majority of the routing table size/growth is not the  
result of multihoming. However, this doesn't mean that it couldn't be  
in the future, as other factors that contribute to large routing  
tables will become less important over time and/or in IPv6.
_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: [email-masked] (Noel Chiappa)
Date: Mon, 13 Nov 2006 20:55:15 -0500 (EST)

> From: "Fleischman, Eric" <[email-masked]>

    >> From: Tony Li [mailto:[email-masked]]=20

    >> In my mind, that's one of the primary benefits of any loc/id split.
    >> Multiple locators per-site, with locator replacement at the border.

    > Good answer, Tony!!

Well, I think we basically agree, but let me comment on one point you raise,
perhaps not so much for your benefit (as you probably already understand the
point I'm going to make), as for that of others:

    > Many Internet architects are apparently keen to burden us end users
    > with multiple addresses. To the extent that Multi6 and Shim6 do this,
    > to that extent they will be resisted for deployment
    > ...
    > There are administrative, management, and security implications of
    > multiple addresses that make them impractical
    > ...
    > Shifting the burden from ISPs to the end user is just not going to cut
    > it. Why does anybody imagine that end users will willingly bear
    > significant operational expenses

As I pointed out a while back:

  Multihoming is something that is done to provide *benefits*. Those are not
  *free*. There is a *cost* for them, and a multihoming design has to think
  about *where* and how much those costs are.

  "TANSTAAFL: There Ain't No Such Thing As A Free Lunch"

	http://ana-3.lcs.mit.edu/~jnc/tech/nsrg/multihoming_points.txt

So when you speak of "the burden", I hear "the cost of providing to someone
something extra they want, e.g. extra reliability". And then I seem to hear
you say that you think the rest of the network should bear that cost, and not
"shift" it "to the end user" - i.e. the party who's getting the benefit.
Doesn't sound like fair economics to me.

Having said that, I understand your point that assigning multiple configured
identity/location fields per host is unbearably painful in a large
organization.

At the same time, I hope (in fact, I expect I can assume) that you can see
that from the point of view of the routing, if an organization is multi-homed
to widely disparate places in the network's connectivity topology, assigning
multiple "routing-names" (to avoid the mental baggage of the term
"addresses") is really the only way to economically provide that party that
benefit.

Which leads us to:

    > Rather, a clean solution that is equally good for everybody has to be
    > found, which is why I personally have supported the loc/id split
    > approach for many years now.

and I have long agreed with that, as my note went on to point out:

  My contention, however, is that the "optimal" solution .. to the large
  space of multihoming "problems" involves extra capabilities in two
  different areas:

    - identity/location separation

which is really the only way to reconcile that particular pairing of
irresistable force (routing overhead) and the immovable rock (configuration
difficulties).

    > Alternatively, we can NAT.

Hmmm. Yes... There is always NAT. I gather than one of the things that
drove NAT deployment (in addition to address space shortages) was the
fact that it made switching ISP's a lot simpler...

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 14 Nov 2006 14:17:01 -0500 (EST)

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

    > I think it's a bit over the top to say that it "doesn't work". You
    > still have reachability and failover.

Well, I did say "this doesn't work (in the sense of 'provide the best paths',
although the traffic will still get there)".

    >> we have such poor tools to manage what I call "abstraction action
    >> boundaries" .. In fact, do we have any at all? (My apologies for my
    >> ignorance about this, but I'm not very up on the latest BGP stuff,
    >> since I've concluded that Destination-Vector designs are inherenly
    >> inferior, and therefore uninteresting.)

    > Thank you for the insult.

I'm sad you feel that way, because none was intended. It's simply a statement
of practicality; I have many major interests in life other than networking,
and I therefore don't have the time to follow fine operation detail of things
which strike me as not the best way to go. I cheerfully accept that the world
will keep going in that direction, I just don't have time to pay detailed
attention to it.

	Noel