The IP Over NBMA (ION) Archive

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Bert;

> > But, you complaining in IETF mailing list that IETF is concentrating
> > on IP-based solutions is no good.
> 
> No, I don't buy this position, Masataka. Grenville himself said, in one 
> of his MARS drafts, that if the underlying medium had an inherent 
> multicast capability, then the IP multicast over such a medium would be 
> a trivial problem. (I hope I paraphrased accurately; apologies if I 
> didn't.) Although I would agree that within a LIS the solution might be 
> trivial, a global solution (IP over global ATM cut-through multicast) is 
> probably far from trivial, but I digress.

As I was afraid from the beginning, ATMosphere of VENUS is thick
and obscure.

Instead of you complaining "trivial for small scale", it's a lot
clear to say "not scalable".

Even if you can insist a very complex protocol trivial, the protocol
can't make fundamentally unscalable things scale.

> As you might know, I think that the IP multicast solution is somewhat 
> lacking (specifically, because it depends on mucho excess bandwidth in 
> the WAN to achieve QoS).

You think ATM multicast solution is somewhat lacking, specifically
because it depends on mucho excess bandwidth in the WAN to achieve
QoS.

That's fine.

Or, do you want to say IETF needs QoS routing, on which we are
already working?

> My comment was merely to point out that VENUS's conclusions are not 
> surprising. In particular, a problem which was tough yesterday to solve 
> with UNI 3.1 is not going to become easy today, with UNI 3.1, unless we 
> really believe that dullards were working the problem before. We should 
> not take UNI 3.1/PNNI 1.0 as the definitive, do-all and end-all ATM 
> design, is my point.

Which part of VENUS ID, do you think, is UNI 3.1 specific?

Making a complex ATM protocol more complex won't solve the
fundamental scalability problem in the IP part.

						Masataka Ohta