The IP Over NBMA (ION) Archive

Cell Relay Retreat>ION Archive>month:1996-Jul> msg00103



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

VENUS

  • From: Albert Manfredi <manfredi@engr05.comsys.rockwell.com>
  • Date: Thu, 25 Jul 1996 11:44:35 -0700
  • CC: ion@nexen.com
  • Organization: Rockwell Defense Electronics - Collins

mohta@necom830.hpcl.titech.ac.jp wrote:

[ ... ]

> > Not a job for the IETF? True. It's a job for the ATMF,
> 
> That's also fine.
> 
> BUT,
> 
> > and hopefully the
> > IETF would make use of those solutions.
> 
> the IETF uses IP.
> 
> If you can't accept IP-based solutions, that's fine.
> 
> 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 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). Since IP is aiming at becoming the general 
purpose solution, I believe that the shortcomings will sooner or later 
have to be addressed. At this point, I don't think they are even being 
acknowledged and I don't believe that referencing future ATM developments 
as a possible way out is being acknowledged or even mentioned.

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.

Bert
manfredi@engr05.comsys.rockwell.com


  • Follow-Ups:
    • VENUS
      • From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
    • VENUS
      • From: Daniel Zappala <daniel@isi.edu>