From owner-malloc@catarina.usc.edu Wed Sep 2 17:53:02 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id RAA09847 for ; Wed, 2 Sep 1998 17:53:01 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA07833; Wed, 2 Sep 1998 14:53:02 -0700 Date: Wed, 2 Sep 1998 14:53:02 -0700 Message-Id: <199809022153.OAA07833@catarina.usc.edu> To: malloc-archive@ietf.org From: majordomo@catarina.usc.edu Subject: Welcome to malloc Reply-To: majordomo@catarina.usc.edu -- Welcome to the malloc mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe malloc or from another account, besides malloc-archive@lists.ietf.org: unsubscribe malloc malloc-archive@lists.ietf.org If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. [Last updated on: Wed Nov 5 11:13:30 1997] This is an automatic reply confirming your subscription request to the malloc@catarina.usc.edu list. Welcome to the malloc (or Multicast address ALLOCation working group) list. You can find archives of this list as well as other goodies at: 1. Mail archive: ftp://catarina.usc.edu/pub/multicast/malloc/mail-archive/ http://netweb.usc.edu/multicast/malloc/mail-archive/ 2. Home page(s): http://north.east.isi.edu/malloc/ (the official one of the WG) http://netweb.usc.edu/multicast/malloc/ 3. Ftp site: ftp://catarina.usc.edu/pub/multicast/malloc/ -- majordomo@catarina.usc.edu (Version 1.94) From owner-malloc@catarina.usc.edu Wed Sep 9 16:01:11 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id QAA11356 for ; Wed, 9 Sep 1998 16:01:10 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA28170 for malloc-list; Wed, 9 Sep 1998 12:24:59 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA28166 for ; Wed, 9 Sep 1998 12:24:54 -0700 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA20627 for ; Wed, 9 Sep 1998 12:24:22 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id PAA13809; Wed, 9 Sep 1998 15:24:18 -0400 Received: from bcn.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id PAA05503; Wed, 9 Sep 1998 15:24:19 -0400 Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id PAA12680; Wed, 9 Sep 1998 15:24:16 -0400 Message-Id: <199809091924.PAA12680@bcn.East.Sun.COM> Date: Wed, 9 Sep 1998 15:24:18 -0400 (EDT) From: Steve Hanna Reply-To: Steve Hanna Subject: Draft malloc minutes from IETF 42 To: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2eFmLcsT6QhGN8OCMjhm1Q== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk Here is a draft set of minutes for the malloc session at IETF 42. Please send comments to me or to the list by Friday, August 11, 1998 noon EDT. The final version of the minutes are due at the secretariat by Friday 5:00 PM EDT. Thanks, Steve Hanna ------------- Minutes of MALLOC Working Group IETF 42 (Chicago, IL) Tuesday, August 25, 1998 Minutes reported by M. Smirnov and S. Hanna. Agenda: Agenda Bashing Hanna Introduction Hanna MASC Radoslavov AAP Handley MDHCP Hanna MZAP Thaler Advance Allocation Thaler This is the first meeting of MALLOC as an IETF working group. I. Agenda and Introduction Steve Hanna presented the agenda and started with the introduction, which covered an overview of the MALLOC architecture with 3 levels and subsequent protocols: MASC for interdomain, AAP for intradomain and MDHCP for host-client interactions for multicast address allocation. The introduction was concluded with the overview of the status of MALLOC documents: architecture needs minor revisions (see later in minutes); MASC, AAP, MDHCP and MALLOC API have been recently updated, however some open issues do exist. II. MASC Pavlin Radoslavov gave a detailed overview of MASC according to draft-ietf-malloc-masc-01.txt. Pavlin presented the goals, claim-collide mechanism, MASC topology with possibly multiple relations (parent:child, sibling:sibling, internal:peer) in it. He underlined that there is no requirement for a strict hierarchy, the MASC topology is following unicast topology. A sample topology was introduced. MASC update messages were presented with their formats and processing rules. The following issues were also addressed: claims comparison function, expanding/renewing the prefix (via reclaim in advance), releasing (via timestamp mechanism). Clash example based on the previously introduced example of MASC topology was presented, as well as issues of dealing with zones and changing the network provider. It was noted that MASC storage must keep only local domain allocations. In the following discussion it was proposed to start with a smaller range of addresses managed by MASC while asking IANA to keep the rest of the whole range being unassigned. There was a consensus that address ranges should not be mentioned in the document while the TCP port number should be retained. It was also suggested and generally accepted to move to a 32 bit MASC domain ID. III. AAP Mark Handley presented the new release of AAP: explanation was improved, terminology (MASC router, MAAService, AAP node) was added; however there is no IPv6 yet in the draft. The architecture permits every node to be a server, all AAP messages are multicast. Six AAP messages are ASA, SSIG, ACLM, AITU, AU, ASRP. There is no explicit Address Deletion message now while it is believed that timing mechanisms will do the job. Mark has noted a number of open issues and possibilities for improvements: server signature (SSIG) could be designed better, it is not clear whether address prefixes (in ASA - Address set Announce) should be prefixes, masks or ranges, AAP tunnelling (with a proxy MAAS in a previous domain). The AAP discussion addressed the following questions. How many address sets would usually be included in an ASA (Address Set Announce) message? This depends on the behavior of the MASC server sending the message. Currently, we expect that such servers would manage their addresses in such a way that the number of address sets in an ASA message would be one or two. Two new messages - Address Claim (ACLM) and Address Intent To Use (AITU) - are serving in principle the same purpose. Which one should be used would be based on a server load (busy server or quiet server). The document assumes that the decision on whether a server is a busy or a quiet one is a local decision and should be kept for implementation. Dave Thaler suggested that AITU is better anyway. The requirement in the current draft for AAP servers to have stable storage should be understood in such a way that if, e.g. a router has a stable storage then this router could serve as a MAAS. A question on ASRP (Address Space Report): How does a MASC router know when it's time to decrease the allocation of addresses in a domain? By the absence of reports. The opinion was expressed that the absense of explicit deletion in AAP is questionable. While it could be considered an application side issue (which also could be linked with the pre-allocation), the abstract API document has ADEL spec in it. IV. MDHCP Steve Hanna presented MDHCP update. It is based on DHCP design principles but is not dependent on it. A server discovery is based on multicast, which should cause no problem. Changes in the current draft are made in such a way that now it is completely separate from the DHCP protocol, has a separate port number. However, sharing of an options number space with DHCP might be dangerous, therefore the DHCP WG approval is needed to avoid collisions between the two. One of the open issues is which scope(s) to use for server discovery. There was a discussion also on a motivation for support of MDHCP servers that provide services for scopes they're not in, on language issues which are still to be addressed, on a desire to remove unused fields from the MDHCP header, on a transition plan from a current practice to a MALLOC architecture, and on the necessity to support whatever policies might be introduced in the area. Steve Hanna stated that the next steps are to resolve open issues and to go for the last call for the MDHCP. The timeframe for this was stated as "a few months". V. MZAP Dave Thaler described how MZAP (Multicast-scope Zone Announcement Protocol) fits into the malloc architecture, especially in distributing scope zone information. It was noted that possible confusions with textual names should be resolved by boundary routers. The multicast scope is considered to be small or big. For small scopes, MASC is not used and AAP uses scope-relative addresses for communication. For large scopes, MASC is used and AAP uses a single multicast address for communication. Recommended is well-known allocation domain scope. With regard to this, the MALLOC architecture document needs to be updated. Marc Handley pointed out that it is not clear what to do with this, i.e. how to use big and small scopes: contributions are welcome. VI. Advance Allocation Dave Thaler presented then the issue of advance allocation as a summary of mailing list discussion: motivation for pre-allocation and steps in pre-allocation. The steps are: pre-allocation with return of (granted | trying | denied); advertisement with, say, 0.0.0.0 in place of requested address; allocation (in case of "trying"); possibly (another) usage until the start time. The maximum usage time of the addresses is an administrative decision. Effects on other documents are as follows: abstract API and MDHCP need to include "trying" result and way to fetch address later; AAP and MASC need no changes. Michael Smirnov pointed that shortly before the 42nd IETF a new draft (draft-phillips-malloc-util-00.txt) has been submitted with motivation for proactive pre-allocation. It was decided to resubmit this draft for a discussion on the mailing list. From owner-malloc@catarina.usc.edu Fri Sep 11 17:21:13 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id RAA28860 for ; Fri, 11 Sep 1998 17:21:12 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA07309 for malloc-list; Fri, 11 Sep 1998 13:45:37 -0700 Received: from mercury.Sun.COM ([192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA07305 for ; Fri, 11 Sep 1998 13:45:28 -0700 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA02962 for ; Fri, 11 Sep 1998 13:44:53 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id QAA06586; Fri, 11 Sep 1998 16:44:49 -0400 Received: from bcn.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id QAA21401; Fri, 11 Sep 1998 16:44:49 -0400 Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id QAA20691; Fri, 11 Sep 1998 16:44:47 -0400 Message-Id: <199809112044.QAA20691@bcn.East.Sun.COM> Date: Fri, 11 Sep 1998 16:44:49 -0400 (EDT) From: Steve Hanna Reply-To: Steve Hanna Subject: malloc minutes submitted To: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8iW6HXJVxJR6wH8JHQgEcw== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk No changes have been requested, so I have submitted to the Secretariat the IETF 42 malloc minutes previously posted to this list. -Steve Hanna From owner-malloc@catarina.usc.edu Tue Sep 29 10:32:41 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id KAA11126 for ; Tue, 29 Sep 1998 10:32:41 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id GAA03148 for malloc-list; Tue, 29 Sep 1998 06:53:22 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id GAA03144 for ; Tue, 29 Sep 1998 06:53:17 -0700 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA05086 for ; Tue, 29 Sep 1998 06:52:46 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id JAA17651; Tue, 29 Sep 1998 09:52:42 -0400 Received: from bcn.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id JAA09959; Tue, 29 Sep 1998 09:52:44 -0400 Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id JAA13450; Tue, 29 Sep 1998 09:52:42 -0400 Message-Id: <199809291352.JAA13450@bcn.East.Sun.COM> Date: Tue, 29 Sep 1998 09:52:42 -0400 (EDT) From: Steve Hanna Reply-To: Steve Hanna Subject: MDHCP changes To: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: OL26OCm0dIJqIevqcshZzA== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk At IETF 42, several concerns were raised regarding MDHCP. First, it was stated that sharing DHCP's option number space is a bad idea. Their option space is already overcrowded. Second, there were objections to the large number of bytes in each MDHCP packet devoted to reserved fields purely to allow code to be shared with DHCP servers and clients. I have spoken to the other authors of the MDHCP draft and we have agreed to split the MDHCP option space off from the DHCP option space, making it completely separate. We have also agreed to remove the chaddr, sname, and file fields from the packet format. This will remove 208 of the 228 bytes currently devoted to reserved fields within the MDHCP packet format. Removing more fields would make it difficult to share any code between MDHCP and DHCP implementations. We have also agreed to solutions for almost all the open issues listed in the current MDHCP draft. I don't believe that any of these were controversial, so I will not describe them here. Before proceeding to write up a new MDHCP draft including these changes, I would like to check the current consensus of the malloc working group. The question is this: With the changes described above, are there objections to moving MDHCP forward? Thanks, Steve Hanna From owner-malloc@catarina.usc.edu Tue Sep 29 15:51:01 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id PAA19536 for ; Tue, 29 Sep 1998 15:51:00 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA04480 for malloc-list; Tue, 29 Sep 1998 12:10:09 -0700 Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA04476 for ; Tue, 29 Sep 1998 12:10:03 -0700 Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.1/8.9.1) id MAA08740; Tue, 29 Sep 1998 12:09:58 -0700 (PDT) Message-Id: <199809291909.MAA08740@daffy.ee.lbl.gov> To: Steve Hanna Cc: malloc@catarina.usc.edu Subject: Re: MDHCP changes In-reply-to: Your message of Tue, 29 Sep 1998 09:52:42 PDT. Date: Tue, 29 Sep 1998 12:09:58 PDT From: Vern Paxson Sender: owner-malloc@catarina.usc.edu Precedence: bulk > Removing more fields would make it > difficult to share any code between MDHCP and DHCP implementations. So how much opportunity for common code is left? Is it enough to merit any semblence of compatibility? Vern From owner-malloc@catarina.usc.edu Tue Sep 29 19:19:40 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id TAA22393 for ; Tue, 29 Sep 1998 19:19:39 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA04812 for malloc-list; Tue, 29 Sep 1998 13:27:42 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA04808 for ; Tue, 29 Sep 1998 13:27:33 -0700 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA10711; Tue, 29 Sep 1998 13:27:01 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id QAA17885; Tue, 29 Sep 1998 16:26:59 -0400 Received: from bcn.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id QAA21882; Tue, 29 Sep 1998 16:26:59 -0400 Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id QAA15381; Tue, 29 Sep 1998 16:26:58 -0400 Message-Id: <199809292026.QAA15381@bcn.East.Sun.COM> Date: Tue, 29 Sep 1998 16:26:58 -0400 (EDT) From: Steve Hanna Reply-To: Steve Hanna Subject: Re: MDHCP changes To: vern@ee.lbl.gov Cc: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hVQBclRDKZd7JlQrLDljdA== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk I'm not a DHCP implementer (at least not any more), so I can't speak to this from personal experience. Microsoft seems to think that the remaining compatibility is useful. But this may be due to the fact that they have already implemented an earlier version of MDHCP. It would be interesting to hear from other DHCP implementers. -Steve > To: Steve Hanna > Cc: malloc@catarina.usc.edu > Subject: Re: MDHCP changes > Date: Tue, 29 Sep 1998 12:09:58 PDT > From: Vern Paxson > > > Removing more fields would make it > > difficult to share any code between MDHCP and DHCP implementations. > > So how much opportunity for common code is left? Is it enough to > merit any semblence of compatibility? > > Vern From owner-malloc@catarina.usc.edu Tue Sep 29 21:10:45 1998 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id VAA23674 for ; Tue, 29 Sep 1998 21:10:44 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA06034 for malloc-list; Tue, 29 Sep 1998 17:40:55 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA06030 for ; Tue, 29 Sep 1998 17:40:49 -0700 Received: by mail3.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Tue, 29 Sep 1998 17:40:18 -0700 Message-ID: From: Munil Shah To: "'Vern Paxson'" , "'Steve Hanna'" Cc: "'malloc@catarina.usc.edu'" Subject: RE: MDHCP changes Date: Tue, 29 Sep 1998 17:40:18 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-malloc@catarina.usc.edu Precedence: bulk There is still a plenty of opportunity for common code. The administration, ipaddress management are two big things. -Munil -----Original Message----- From: Vern Paxson [mailto:vern@ee.lbl.gov] Sent: Tuesday, September 29, 1998 12:10 PM To: Steve Hanna Cc: malloc@catarina.usc.edu Subject: Re: MDHCP changes > Removing more fields would make it > difficult to share any code between MDHCP and DHCP implementations. So how much opportunity for common code is left? Is it enough to merit any semblence of compatibility? Vern