From owner-malloc@catarina.usc.edu Mon Apr 17 21:06:56 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12361 for ; Mon, 17 Apr 2000 21:06:55 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id RAA35425 for malloc-list; Mon, 17 Apr 2000 17:56:46 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id RAA35420 for ; Mon, 17 Apr 2000 17:56:45 -0700 (PDT) Received: from dthaler.microsoft.com ([131.107.152.20]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id RAA00599 for ; Mon, 17 Apr 2000 17:56:45 -0700 (PDT) Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id TAA13979; Mon, 17 Apr 2000 19:27:18 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <200004180227.TAA13979@dthaler.microsoft.com> Subject: MALLOC minutes To: minutes@ietf.org, malloc@catarina.usc.edu Date: Mon, 17 Apr 2000 19:27:18 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Multicast Address Allocation WG (malloc) Thursday, March 30 at 0900-1130 =============================== CHAIRS: Dave Thaler Steve Hanna AGENDA: Agenda Bashing Introduction and Document Status Dave Thaler (5 minutes) AAP Updates: Mark Handley (30 minutes) draft-ietf-malloc-aap-03.txt MALLOC MIB Update: Dave Thaler (10 minutes) draft-ietf-malloc-mib IPv6 Multicast Address Allocation: Brian Haberman (5 minutes) draft-haberman-malloc-ipv6-prefix-00.txt draft-haberman-ipngwg-mcast-arch-00.txt ---------------------------------------------------------------------- Document Status ---------------- Two RFCs were published since the last meeting: MADCAP is now RFC 2730 (Proposed Standard) Abstract API is now RFC 2771 (Informational) Three documents were sent to IESG since last meeting: Architecure Document (submitted for Informational) MADCAP Scope Nesting Option (submitted for Proposed Standard) MASC (submitted for Experimental) Other WG Documents remaining: AAP MIB (blocked on AAP) AAP Updates: Mark Handley draft-ietf-malloc-aap-03.txt ---------------------------- lots of changes in 02 only explanation changes in 03 changes from 02 - 03 - Scaling Analysis (section 6) added: some errors, needs to be revised again - Reccomendation that hosts use MADCAP instead of AAP if a MADCAP server is available - Added discussion of allocation conflicts Beau Williamson asked: include text on how apps should deal with shifting addresses within a session? E.g. when we have an allocation conflict Dave Thaler responded: Not in AAP, this is part of session advertisements, this is something that is explained in the architecture document. - Added examples (Appendix A) - Noted reserved port number: 2878 - Removed Appendix D (Unresolved Issues) recap from 01 - 02 1) - Originally AAP assumed that could be large numbers of AAP speakers in a domain. e.g. sdr might speak AAP - this no longer the intent - can now use simpler algorithm for defending addresses * use unform random backoff, not exponential random backoff - aim is for approx 2-10 AAP speakers in a domain, with 1000 being the upper bound 2) Security mechanim - Use IPSec AH instead of custom authentication - Currently only use manual keying with a group-shared key - SMuG is working on group-keying mechanisms for later on What's next 3/00 Currently in WG last Call 4/00 Send to IESG, IETF Last Call 5/000? IESG approves as Proposed Standard other docs will be discussed in zeroconf or mboned as approriate MALLOC MIB Update: Dave Thaler draft-ietf-malloc-mib-02.txt ---------------------------- RFC2465 - defines IPv6Address type - IPv6-specific MIBs can use this draft-ops-endpoint-mib-07.txt - defines protocol-independent InetAddress type - should be RFC soon - protocol-independent MIBs should use this Changes to the MALLOC MIB - IPv6 support now uses standard InetAddress types - Updated MIB Boilerplate text - Language names now use Language Tag type defined in Multicast MIB - Added Guid type to identify leases - Reading key now MUST return empty string (was MAY) (Thanks to Lars Viklund for reviewing this MIB) ToDo - Prefix coordinator config * Has interval but not ranges to advertise - Security * currently has old "public key" objects IPv6 Multicast Address Allocation: Brian Haberman draft-haberman-ipngwg-mcast-arch-00.txt --------------------------------------- presented in IPNG WG Objectives - - Simplify IPv6 multicast address allocation - - Aid in debugging IPv6 multicast networks - - Single-source IPv6 multicast Architecture change proposal - - borrow the idea from GLOP, but include the network prefix of the allocation domain in the mcast address - - can do this as only the bottom 32 bits actually get used +---------+-----+----------------+----------+ | prefix | len | unicast prefix | group id | +---------+-----+----------------+----------+ prefix is the multicast prefix to be reserved for this purpose len is length of unicast prefix Multicast Debugging - - Who owns the multicast address - - Who allocated the multicast address Single-Source Multicast - - set "unicast prefix" to 0/0 This doc will been adopted as a WG document by the IPNG WG IPv6 Multicast Allocation Guidelines: Brian Haberman draft-haberman-malloc-ipv6-prefix-00.txt ---------------------------------------- - - short document that describes guidelines for MAAS's for generating the low 32-bits of multicast addresses so as to avoid layer-2 clashes. - - use pseudo-random address, avoiding group IDs reserved by IANA for the All-hosts, All-routers, etc groups. - - should this be a malloc WG doc? Thaler: must make explicit assumption that allocation of unicast implies allocation of multicast prefix as well. There are content provides who would like to use scope to construct borders around countries etc. Is there enough richness there to allow these things? Thaler: out of scope this WG is about allocation Haberman: new IAB doc on scoped address architecture Thaler: current IPv6 draft says that scopes must nest, can't define "arbitrary" ones unless they nest. Handley: arbitrary scopes are hard to do beacuse they must be convex...you will create black holes Handley: yes, this should be a malloc WG doc, it should probably be "proposed" 239 vs 232 Discussion ---------------------- Q: What addresses should be used for IPv4 source-specific, scoped groups? A 1) is to take one piece of the 232 range and divide it up for scoping things. Arg is don't do this as it makes advertising and filtering more difficult. 2) is to take a piece of each 239 subrange and make it source-specific. Arg is 239 is set aside as being scopable but not as source-specific. This can expand downwards into 238, though. 3) take 238 and carve it up just like 239, and distribution is the same. So MZAP announcement for (say) 239.192/16 implies that 238.192/16 is a source-specific range with the same distribution scope. This is much closer to the IPv6 proposal discussed earlier, where a single bit in the address can identify (independent of scope) whether the address is source-specific or not. Casner: just let certain scopes in 239 be used as SSM Holbrook: if we make the 232 range dynamic, then routers do become the MZAP servers? Handley/Casner: we need to keep 232 clean. If we put structure in then we will run into allocaiton conflicts at scope boundaries. Handley: we could use MZAP to indicate SS range within 239, this would require that ALL routers that could have local hosts listen to MZAP in this range. Thaler: If you're running IGMP then you could have local hosts. The argument for 238 is that routers can filter on all of 238. Casner: my main concern with 238 is fragmentation email list: ssm@external.cisco.com Actions: 1) Roger Kermode to resubmit MADCAP Nesting State Option Draft to IESG after incorporating comments from ADs 2) Mark Handley to fix scaling analysis in AAP draft and resubmit for WG last call 3) Brian Haberman to generate new document for immediate WG last call 4) Dave Thaler to generate new MIB and resubmit for WG last call Thanks to Roger Kermode for taking minutes. From owner-malloc@catarina.usc.edu Tue Apr 25 14:54:45 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22391 for ; Tue, 25 Apr 2000 14:54:43 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA76765 for malloc-list; Tue, 25 Apr 2000 11:30:33 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA76760 for ; Tue, 25 Apr 2000 11:30:33 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id LAA23043 for malloc@catarina.usc.edu; Tue, 25 Apr 2000 11:31:03 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id DAA74972 for ; Tue, 25 Apr 2000 03:47:25 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id DAA14596 for ; Tue, 25 Apr 2000 03:47:24 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08126; Tue, 25 Apr 2000 06:44:06 -0400 (EDT) Message-Id: <200004251044.GAA08126@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: malloc@catarina.usc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-malloc-madcap-nest-opt-04.txt Date: Tue, 25 Apr 2000 06:44:06 -0400 Sender: owner-malloc@catarina.usc.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast-Address Allocation Working Group of the IETF. Title : MADCAP Multicast Scope Nesting State Option Author(s) : R. Kermode Filename : draft-ietf-malloc-madcap-nest-opt-04.txt Pages : 13 Date : 24-Apr-00 This document defines a new option to the Multicast Address Dynamic Client Allocation Protocol (MADCAP) to support nested scoping. The new option's purpose is to allow clients to learn which scopes nest inside each other, and hence may be used for expanding scope searches or hierarchical multicast transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-madcap-nest-opt-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-malloc-madcap-nest-opt-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-malloc-madcap-nest-opt-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000424142229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-madcap-nest-opt-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-madcap-nest-opt-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000424142229.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Fri Apr 28 18:05:32 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12942 for ; Fri, 28 Apr 2000 18:05:31 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA13256 for malloc-list; Fri, 28 Apr 2000 14:52:13 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA13251 for ; Fri, 28 Apr 2000 14:52:12 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id OAA01237 for malloc@catarina.usc.edu; Fri, 28 Apr 2000 14:52:12 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA12617 for ; Fri, 28 Apr 2000 11:55:18 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA21656 for ; Fri, 28 Apr 2000 11:55:17 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08818; Fri, 28 Apr 2000 14:51:11 -0400 (EDT) Message-Id: <200004281851.OAA08818@ietf.org> To: IETF-Announce: ; Cc: malloc@catarina.usc.edu From: The IESG SUBJECT: Last Call: MADCAP Multicast Scope Nesting State Option to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 28 Apr 2000 14:51:11 -0400 Sender: owner-malloc@catarina.usc.edu Precedence: bulk The IESG has received a request from the Multicast-Address Allocation Working Group to consider MADCAP Multicast Scope Nesting State Option as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 12, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-malloc-madcap-nest-opt-04.txt