Subject: RE: network controls are necessary

From: "Tony Li" <[email-masked]>
Date: Fri, 6 Dec 2002 10:30:15 -0800

|   If I thought having the network make the selections would 
|   require change in 
|   application logic, I would not be suggesting such a solution.
|   I would prefer a solution that is completely invisible to 
|   the application 
|   (such as Tony Li's suggesting that the application is 
|   handed a 32 bit 
|   identifier when it currently expects an IP address).
|   Failing that, I would prefer to minimize the application coupling.
|   Having application level address selection increases the 
|   application impact.

I'd second that.  Even assuming that the host has policy control 
(which I'm not in favor of), the management of locators would belong
in the stack, NOT in the application code.  I would tend to 
extend the API to have a "Hey, this connection isn't working" entry 
so that applications can signal the stack.

Tony

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Sat, 7 Dec 2002 02:25:51 -0500

> From: "Christian Huitema" <[email-masked]>

    > Rant: an old tenet of networking is that a name is not an address and
    > an address is not a route

This simplistic analysis (by Shoch) of the correct set of namespaces for a
network architecture was made obsolete by Saltzer about 20 years ago, and I
strongly suspect that Shoch would be the first to tell you so.

    > I don't see why we would need to invent new names and refer to names as
    > identifiers and addresses as locators.

"Name" properly is a meta-syntactic term for any kind of identifying string,
so in some sense every name in the IP architecture (IEEE addresses, IPvN
addresses, DNS names, etc) are *all* names.

The reason for inventing a new namespace and calling them "identifiers", and
referring to what we used to call "addresses" as "locators" is to make plain
that we have different namespaces to say i) *who* something is, and ii)
*where* it is - and "locators" *only* do the latter. This is unlike IPvN at
the moment, where effectively there is only one kind of name, which does both
- which has been shown to have significant disadvantages.

	Noel

---

From: "Tony Li" <[email-masked]>
Date: Fri, 6 Dec 2002 23:41:05 -0800

|   The reason for inventing a new namespace and calling them 
|   "identifiers", and
|   referring to what we used to call "addresses" as "locators" 
|   is to make plain
|   that we have different namespaces to say i) *who* something 
|   is, and ii)
|   *where* it is - and "locators" *only* do the latter. This 
|   is unlike IPvN at
|   the moment, where effectively there is only one kind of 
|   name, which does both
|   - which has been shown to have significant disadvantages.

BTW, practical experience bears this out.  For hosts with
multiple interfaces, sooner or later, you find that you need
a unique IPv4 address to use regardless of what connectivity
is available.  You end up putting an IP address on a loopback
interface to provide the "identifier".

If you come at it the other way and start with a CLNP host
that has an identifier but no interface addresses, you quickly
find that people ALSO want to be able to reference a system
based on it's particular location.

IPv4 did a fine thing in colocating the identifier and 
locator in 32 bits.  And it made sense when the IMP port
number was part of the address.  But those days are well
past us now, the net is much more richly connected and 
being multihomed no longer means that you had two IMPs.

If we are to move the Internet architecture forward, then we
need to apply what we've learned over the past 30 odd years
and deploy a new routing and addressing architecture that 
fixes the semantic overload that was once a practical necessity
and give ourselves the additional flexibility that results.

Articulating the same position for 10 years now, I remain yours
in routing,
Tony

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Sun, 8 Dec 2002 13:04:54 -0500

> From: "Joel M. Halpern" <[email-masked]>

    > One of the reasons I want to keep hosts out of the routing space is
    > that if we ever do find routing solutions that we want to use for new
    > capabilities (QoS or otherwise) I would not want to have to upgrade the
    > hosts as well as the routers to deliver such capabilities.

On first reading this, I thought you were meaning that you wanted to keep
hosts out of any involvement in path selection altogether (which I think is
unreasonable - re-run statement about each car driver making their own
routing choices :-).

But I gather you instead that you simply mean that you don't want to have to
change the hosts (more than once). This is reasonable, but I would go
slightly further: the current routing architecture (i.e. based on exchange of
routing tables) is so broken there's no point in having hosts involved in
path selection until it has been ditched completely.

    > From: Iljitsch van Beijnum <[email-masked]>  

    > People sitting in a bus can also be excellent drivers, but that doesn't
    > mean they get to second guess the bus driver. .. Getting routers to
    > work together is hard enough, getting hosts which are much more diverse
    > in every way to do the same is next to impossible.
##  > However, that does not mean hosts should be kept stupid: any task a
##  > host can perform autonomously without adverse effects on other systems
##  > should be performed by the host and not by the network infrastructure.

Exactly! I couldn't have said it better myself (and I'll probably be
'borrowing' this phrase in the future! :-).

The only (minor) change I would make would be to say "{may} be performed by
the host and not by the network infrastructure" - we probably want to provide
the 'vanilla' version of the function somewhere in the network, so the host
doesn't *have* to do it unless it wants to.

Alas, the Multi-6 group has to live with the routing as it is, not as it
ought to be, so this entire point, while of great interest, is purely
academic at this stage.

	Noel

---

From: "Tony Li" <[email-masked]>
Date: Sun, 8 Dec 2002 16:20:56 -0800

|   What I was referring to was an AFI for the identifier, not for the
|   locator. So I don't care about whether the packets end up 
|   being IPv6,
|   IPv4 or CLNP, but I do care that "www.yahoo.com" is a FQDN 
|   and not an
|   IPv4 address, an IPv6 address, a CLNP NET, or a phone 
|   number. I want to
|   know it's a v4 or v6 address so I can build TCP packets that are
|   compatible with today's IPv4 or IPv6 TCP packets, even if I 
|   then choose
|   to transmit them over CLNP. I want to know if it's a phone 
|   number so I
|   can apply the processing best used for phone numbers rather 
|   than feed it
|   to the DNS and get nothing back.

That shouldn't be necessary.  Syntactically, they are all sufficiently
different that the lower layers should be able to figure this out
without difficulty.

|   > Nothing is perfect until you have removed all that can be removed.
|   
|   On the other hand, something that can't be expanded later 
|   to accommodate
|   new needs isn't very perfect either.

Hence the need for loose coupling.

Tony

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 09 Dec 2002 11:03:52 -0500

> 1) The address pair does not work because there really is no connectivity 
> over that path.  In that case, presumably routing will catch up pretty 
> quickly.  

I'm curious about something like that can be made to happen..

That seems to require either that alternate paths with alternate
locators have to silently cover for each other..  (which appears to
have the layer-9 probloems of geographic addressing), or that
information about failure of (for instance) an individual link to a
site will "pretty quickly" propagate all the way across the network,
which seems hard to scale up..

Maybe we have different ideas about what "pretty quickly" means.

Maybe a site could withdraw the identifier->locator mapping when a
link is known to have lost connectivity, but that clearly limits
what can be done to cache identifier-locator mappings..

					- Bill

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 9 Dec 2002 08:36:03 -0800

> I have nothing to gain by having control in the SBR.  I no longer work
> at Cisco, so I have no interest in placing more responsibility and
> complexity into the CPE gear.  I'm just trying to design a clean
> architecture
> that scales.  That's what we should all be striving for.

I have heard many assertions that this or that solution does not scale.
Since we are engineers, I would very much like that references to
scaling be backed up by a complexity analysis. Lacking that, we are
dealing with beliefs and esthetics.

For example, we can say that, with CIDR, the size of the routing tables
in the DFZ routers should scale as something between O(P), which is the
number of DFZ providers, which itself is expected to scale with the
number of sites as something like either O(log S) or O(sqrt S),
depending which opinion you believe. On the other hand, without CIDR,
the routing tables would scale as O(S). That makes the comparison quite
clear.

-- Christian Huitema

---

From: "Tony Li" <[email-masked]>
Date: Mon, 9 Dec 2002 11:15:50 -0800

|   For example, we can say that, with CIDR, the size of the 
|   routing tables
|   in the DFZ routers should scale as something between O(P), 
|   which is the
|   number of DFZ providers, which itself is expected to scale with the
|   number of sites as something like either O(log S) or O(sqrt S),
|   depending which opinion you believe. On the other hand, 
|   without CIDR,
|   the routing tables would scale as O(S). That makes the 
|   comparison quite
|   clear.

Christian,

For M multihomed sites, CIDR will give us growth of O(P + M), where
M is likely to come to dominate (and overwhelm).  We need an
architecture where we have some confidence that in the long term, the
M factor is either removed from the equation or controlled.  Certainly
something like O(P + log M) might be reasonable, but I see no way of
doing that other than something like the geographic approach and the
issues there are considerable.

I can see a way to get to O(P), but we're a long way from consensus
on that.

In any case, the real scalability requirement is that

	d(DFZ)
	------  <<  Moore's law
	  dt

O(P+M) does not meet this requirement, IMHO.

Tony

---

From: "Michel Py" <[email-masked]>
Date: Tue, 10 Dec 2002 21:08:37 -0800

> Craig A. Huegen wrote:
> As long as you are considering how to take a network of
> 100,000 hosts in a distribution of 65% OS-A, 25% OS-B,
> 5% OS-C, and 5% OS-Other (comprised of about 35 different
> other OS's),
> (PS - No, those aren't real numbers of operating system
> distribution at any particular entity that still exists.

Not that far off.

S-A = win2k
OS-B = nt4

Out of the 36 different OS for OS-C and Other-OS, I can enumerate:
Windows 95
Windows 98
Windows 98se
Windows Me
Windows XP
MacOs pre OS8.6
MacOs pre-OS X
MacOs X
Linux
FreeBSD
Solaris 7
Solaris 8
UnixWare
HP/UX
different flavors of OS/400 w/TCP/IP
..
..

Not to mention that on lots of networks I had to work on, 6 to 7
protocols on the wire are common, given the basic 5 found all the time:
IP
IPX
AT Ph II
Decnet
SNA

Although I agree that we do need more host people involved, the fact of
the matter is that the network administrator is the one that sees the
big picture, given the fact that the AS/400 guys don't talk to the
Macintosh guys that don't talk to the Windows guys. TE is not only about
IP. Stuff like DLSW+ and proprietary video protocols come to mind.

Michel.