Re: Last Call: Classical IP and ARP over ATM to Proposed Standard

Masataka Ohta <mohta@necom830.cc.titech.ac.jp> Wed, 27 October 1993 13:08 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04329; 27 Oct 93 9:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04319; 27 Oct 93 9:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09239; 27 Oct 93 9:08 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04283; 27 Oct 93 9:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04147; 27 Oct 93 9:05 EDT
Received: from necom830.cc.titech.ac.jp by CNRI.Reston.VA.US id aa09141; 27 Oct 93 9:05 EDT
Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 27 Oct 93 22:01:06 +0900
X-Orig-Sender: ietf-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Masataka Ohta <mohta@necom830.cc.titech.ac.jp>
Return-Path: <mohta@necom830.cc.titech.ac.jp>
Message-Id: <9310271301.AA04421@necom830.cc.titech.ac.jp>
Subject: Re: Last Call: Classical IP and ARP over ATM to Proposed Standard
To: ietf@CNRI.Reston.VA.US
Date: Wed, 27 Oct 1993 22:01:05 -0000
Cc: tng-wg@jain.ad.jp
X-Mailer: ELM [version 2.3 PL11]

Since the last call to promote "Classical IP and ARP over ATM" to
Proposed Standrad, I investigated:

	draft-ietf-atm-classic-ip-05.txt

and found a serious problem.

That is, though the ID says:

   ATM does not support broadcast addressing, therefore there are no
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   mappings available from IP broadcast addresses to ATM broadcast
   services. Note: this lack of mapping does not restrict members from
   transmitting or receiving IP datagrams specifying any of the four
   standard IP broadcast address forms as described in [8].  Members,
   upon receiving an IP broadcast or IP subnet broadcast for their LIS,
   MUST process the packet as if addressed to that station.

IT DOES. ATM forum has assigned the ATM broadcast address.

As the ID is mostly on how to do ARP with non-broadcast environment, I
think the entire ID does not worth to be Proposed Standard.

							Masataka Ohta

PS

I checked the archive of ATM WG and found that someone said that we
can't wait broadcast issues finalized by ATM forum, which might
have been a valid reason when it was said (93/06).

I also felt that there is strong negative feeling agaist broadcast
storm in the WG. But, the ID gives quite ugly protocol (giving all the
WS SNAP, ATM and IP addresses, let a single server control all of them,
and hand cofigure all WSs to know the location of the central server)
only to solve the ARP/RARP issues. As many protocols such as RIP
and NIS, relies on broadcast now, it is not worthwhile to redesign
them just for "classical IP". Also, as the ID admits a single ARP
server is not robust enough, the ID is useful only for small number
of workstations, where, broadcast storm is, also, not a problem