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
- Re: complex extensions attacking IETF protocols Masataka Ohta
- Re: complex extensions attacking IETF protocols Bob Stewart
- Re: complex extensions attacking IETF protocols Karl Denninger
- Re: ISMS working group and charter problems Keith McCloghrie
- Re: ISMS working group and charter problems Dave Crocker
- Re: ISMS working group and charter problems Tom Petch
- Re: ISMS working group and charter problems Sam Hartman
- Re: ISMS working group and charter problems Juergen Schoenwaelder
- Re: ISMS working group and charter problems Sam Hartman
- Re: ISMS working group and charter problems Juergen Schoenwaelder
- Re: ISMS working group and charter problems Keith McCloghrie
- Re: ISMS working group and charter problems Jeffrey Hutzelman
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Juergen Schoenwaelder
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Juergen Schoenwaelder
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group Keith McCloghrie
- Re: [Isms] ISMS charter broken- onus should be on… Keith McCloghrie
- Re: Gen-ART review of draft-ietf-imss-fc-fcs-mib-… Keith McCloghrie
- Re: Gen-ART review of draft-ietf-imss-fc-fcs-mib-… Suresh Krishnan
- Re: IETF MAILING: REGISTERED ATTENDEES: December … Masataka Ohta
- Re: IETF MAILING: REGISTERED ATTENDEES: December … Theodore Y. Ts'o
- Re: Last Call: Classical IP and ARP over ATM to P… Brian Carpenter CERN-CN
- Re: IAB/IETF standardization process Masataka Ohta
- Last Call: Classical IP and ARP over ATM to Propo… IESG Secretary
- Re: IETF MAILING: REGISTERED ATTENDEES: December … Masataka Ohta
- Copyright Confusion (was Re: IAB/IETF standardiza… Donald E. Eastlake 3rd (Beast)
- Re: Last Call: Classical IP and ARP over ATM to P… Masataka Ohta
- Re: Copyright Confusion (was Re: IAB/IETF standar… Masataka Ohta
- Re: Copyright Confusion (was Re: IAB/IETF standar… carl
- Re: Last Call: Classical IP and ARP over ATM to P… vincent birritteri ee stnt
- Re: IAB/IETF standardization process Simon E Spero
- Re: IETF MAILING: REGISTERED ATTENDEES: December … Masataka Ohta
- Re: IAB/IETF standardization process Masataka Ohta
- Re: IETF MAILING: REGISTERED ATTENDEES: December … Masataka Ohta
- Re: Last Call: Classical IP and ARP over ATM to P… Masataka Ohta
- Re: Last Call: Classical IP and ARP over ATM to P… Mark Laubach
- Re: Last Call: Classical IP and ARP over ATM to P… Masataka Ohta
- Re: IAB/IETF standardization process Mark Crispin
- Re: IAB/IETF standardization process Theodore Ts'o
- Re: Last Call: Classical IP and ARP over ATM to P… Masataka Ohta
- Last Call: Classical IP and ARP over ATM to Propo… The IESG