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

Mark Laubach <laubach@matmos.hpl.hp.com> Thu, 28 October 1993 07:26 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00759; 28 Oct 93 3:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00752; 28 Oct 93 3:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01960; 28 Oct 93 3:26 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00742; 28 Oct 93 3:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00706; 28 Oct 93 3:20 EDT
Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa01866; 28 Oct 93 3:20 EDT
Received: from localhost by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA12226; Thu, 28 Oct 93 00:20:12 -0700
Message-Id: <9310280720.AA12226@matmos.hpl.hp.com>
To: Masataka Ohta <mohta@necom830.cc.titech.ac.jp>
Cc: Joel Halpern <jmh@anubis.network.com>, ietf@CNRI.Reston.VA.US
Subject: Re: Last Call: Classical IP and ARP over ATM to Proposed Standard
In-Reply-To: Your message of Thu, 28 Oct 93 11:51:54 +0200
Date: Thu, 28 Oct 1993 00:20:12 -0700
X-Orig-Sender: ietf-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mark Laubach <laubach@matmos.hpl.hp.com>

    From:  Masataka Ohta <mohta@necom830.cc.titech.ac.jp>
    Subject:  Re: Last Call: Classical IP and ARP over ATM to Proposed Standard

    > Mr. Masataka Ohra:
    > 
    > I believe that you have misread the ATM Forum documents.  They do NOT
    > "assign the ATM broadcast address".  While they talk about multicast,
    > the current ATM Forum documents do not define mutlicast addressing.
    
    I said nothing about multicast, because it will not be fully operational
    until IPng.
    
    > And "broadcast" is even more vaguely covered.
    
    I think the address, VP=2, VC=14 is specifically assigned for broadcast,
    isn't it?
    
I don't have the specification near me as I am making this reply.  There
may be some VC's reserved for broadcast use, but I believe there is no 
underlying support for the broadcast of AAL5 PDUs.

    > In addition, broadcast/multicast is not a mandatory feature of all
    > ATM networks.  As such, we can not count on it for even local operation
    > of ATM.
    
    We can't expect the broadcast for ATM WAN, of course.
    
    But several existing TCP/IP protocols relies on broadcast over LAN.
    
    So, why can't we count on broadcast for local operation?
    
As Joel has pointed out, it is not mandatory in ATM networks.

    > I will assume that the extremely harsh tone of your note, denigrating
    > a lot of hard, valuable work by a lot of people, was due to linguistic
    > difficulties rather than other causes.
    
    I merely evaluated the ID by its content, not by the number of related
    people nor the amount of consumed effort.

Thank you for your comments.  There are nearly 1000 people on the ATM
working group distribution list and we've had consistently around 100
or so attending the WG at each of the last three IETF meetings.  The
composition of the group is varied and consists of members heavily
involved in the IETF community and members heavily involved in the ATM
Forum community and in the development of the UNI 3.0 specification.
The consensus of the working group members is reflected in the
classical document.
    
    It is my impression that people in ATM WG are, quite optimisticly, trying
    to solve the global routing issues as the extension of ARP, which makes
    their proposal quite strange.

The scope of the classical document restricts ATMARP to the boundaries
of a classical Logical IP Subnet (LIS); i.e. it is not a global
mechanism.  The client interface to the ATMARP service has been 
designed to migrate without change to a multicast environment when
multicast services addresses and the requisite support are commonly
available in local ATM networks.

Minutes from the last ATM WG in Amsterdam are available on line
via ftp anonymous:
  
    matmos.hpl.hp.com:~ftp/pub/ip-atm/minutes.amsterdam

They detail the decision/consensus items from the last WG session.

Regards,
Mark