The IP over ATM Mailing List Archive by date

[Markus Jork <jork@nestvx.enet.dec.com>]

I agree with Scott and Jim that we can't solve this issue in just a few days
on the mailing list. Hopefully, there will be enough time for a discussion
in Los Angeles. This topic should get a well-known place on the agenda of
some wg, at a time when ipng, rolc and ipatm folks can attend. Or maybe a
separate session just for this. But please: earlier than 9:45pm and more than
15 minutes (that's about the time we had in Dallas).

Anyway, this shouldn't keep us from identifying the issues and starting
to discuss things?


Back to Joel Halpern's concern:

[It's good you bring this up a second time. I almost forgot about your first
 mail because I've been away from my office for a few days.]

> Unfortunately, what it requires instead is a fully configured 
> hierarchy of servers covering the entire ATM fabric.  Given taht in 
> this proposal the servers are NOT running routing, there is 
> complexity required to maintain the heirarchy.  With a heriarchy of 
> routers, the routers maintain the hierarchy themselves.

In this regard, I don't see much of a difference to all existing or
proposed IPv4 mechanisms. Basing the comparison on an ideal
future NHRP-only IPv4 scenario, where all the NHRP servers have to be
co-located with a router: you could do just the same with the ND servers
proposed in Peter's draft. Start an ND server on each router. They will find
each other automagically. I'm not saying this is necessarily a good idea,
because it would increase the load on a single point: the router. In fact,
I think we can even do better:

> In fact, 
> there are even proposals to allow the automatic formation of such a 
> heirarchy.  (No, said proposals are not fully fleshed out.  They need 
> work.  But the nature of routing gives one hope that it can be done.)

Peter's draft contains a rather fleshy proposal for the automatic formation
of the ND server hierarchy (using UNI 4.0 signalling). This includes automatic
load sharing and error recovery.

> In addition, in the absence of a set of routers, there is nothing to 
> serve as the default forwarding path. One of the relevant IPv4  
> observations is also important here. ~You do not want to set up a VC 
> for a DNS query~.  Therefore, there must be a connected heirarchy of 
> routers, so that packets can be default, connectionless, forwarded.

It depends on your applications. My guess is that in most cases, there won't
be a need for such a "connectionless" forwarding path. But it's probably not
worth arguing about that. The point is, I consider it a feature of Peter's
draft that you don't have to put a router inside your ATM network when it's
not necessary. You could even run a large ATM network subdivided into multiple
logical links without the need for routers inbetween. People spend lots of
money for the ATM equipment. Why do you want to force them to fork out even
more for a couple of routers that just route from ATM to ATM?

Just to avoid misunderstandings for people who haven't read the draft so far:
of course there's nothing in there that prevents you from installing routers
inside the ATM network. There's just the option not to do so even for large
ATM networks.

> Given that the routing heirarchy must exist, must be stable, and can 
> handle the query problem, why in heavens name would I want to invent 
> anything else? 

I think I answered part of this question in this mail and the other, more
important part, has already been addressed in the discussion so far (there is
much more to ND than just address resolution).

Markus