From owner-malloc@catarina.usc.edu Thu Feb 4 01:30:44 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id BAA17463 for ; Thu, 4 Feb 1999 01:30:44 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id WAA12627 for malloc-list; Wed, 3 Feb 1999 22:04:56 -0800 Received: from MAIL2 ([24.232.0.18]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id WAA12616 for ; Wed, 3 Feb 1999 22:04:47 -0800 Received: from juan - 192.168.70.54 by cvtci.com.ar with Microsoft SMTPSVC; Thu, 4 Feb 1999 03:02:26 -0300 Date: Thu, 04 Feb 1999 03:05:59 -0300 From: Baisys Sistemas Subject: Bases de emails y hardware Reply-To: exin@cvtci.com.ar To: malloc@catarina.usc.edu X-Mailer: dbMail v1.3b1 by Mach5 Software. Please report spamming to dbspam@mach5.com. Message-ID: <0c6052602060429MAIL2@cvtci.com.ar> Sender: owner-malloc@catarina.usc.edu Precedence: bulk Atención!!! servicios para PYMEs: Baisys Sistemas ofrece a las pequeñas y medianas empresas una solución integral en materia de equipamiento en cuanto a instalaciones y mantenimiento de equipos, redes, Internet y comunicaciones. Instalación, Configuración y Mantenimiento de Redes · Cableado alimentación 220/110 V c/tierra · Cableado par trenzado (RJ45) o coaxil (RG58) · Canalización con cable-canal y piso-canal · Instalación de cajas y periscopios · Instalación de hubs · Instalación de impresoras y modems de red · Sistemas de alimentación ininterrumpible (UPS) · Instalación de sistemas operativos Windows 98/95/NT o Novell · Configuración de recursos compartidos · Administración y Políticas de seguridad · Sistemas de backup (CD, Tape Backup, Zip, Jaz) Servicio Técnico y Mantenimiento de Equipos Abonos mensuales de mantenimiento que incluyen: · Servicio técnico a domicilio sin cargo ante falla de equipos, caídas de red y otras eventualidades · Configuración de software · Copias de seguridad en CD · Limpieza periódica de equipos, teclados e impresoras Servicios de Internet Asesoramiento en materia de conexión a Internet, correo electrónico, conexiones y configuración de redes para acceso simultáneo desde varios equipos. *********** GRAN OFERTA DE FEBRERO 1999: OFREZCA SUS PRODUCTOS Y SERVICIOS POR EMAIL!!!! CD ROM CON 44.000 EMAILS DE ARGENTINA para publicidad por email $ 300.00.- Mouse Genius............................................. $ 4.30.- Mouse genérico.......................................... $ 2.90.- Parlantes 120 watts..................................... $ 7.85.- Micrófono con pié...................................... $ 2.50.- Disco rígido 5.1 GB UDMA....................... $ 157.00.- Módem 56 KB Po......................................... $ 33.10.- Gabinete mini tower fuente 250 w.............. $ 23.15.- Monitor 17 pulgadas Digital...................... $ 318.00.- Placa de red COMBO genérica.................. $ 12.40.- Grabadora CD Mitsubishi 6 x 2 IDE.......... $ 405.00.- Impresora LEXMARK Chorro de tinta..... $ 136.35.- Scanner FULL PAGE Color........................ $ 66.15.- Por otros artículos, consúltenos!!!! Precios de contado más IVA. Baisys Sistemas. Florida 165 - Piso 14 - Of. 1409 - (1333) Capital Federal. Teléfono : 4345-3801. Lunes a viernes de 10 a 19 hs. E-mail : exin@cvtci.com.ar Web Page : http://members.spree.com/sip.baisys Este mensaje llega a usted desde una lista de distribución. Su incorporación a la misma fue sugerida por alguno de nuestros clientes. Si por cualquier motivo NO DESEA RECIBIR esta lista periódicamente, por favor háganoslo saber enviando un mensaje con la palabre ELIMINAR. From owner-malloc@catarina.usc.edu Thu Feb 4 10:10:29 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id KAA27001 for ; Thu, 4 Feb 1999 10:10:29 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id GAA13838 for malloc-list; Thu, 4 Feb 1999 06:14:12 -0800 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 GAA13834 for ; Thu, 4 Feb 1999 06:14:07 -0800 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA10017 for ; Thu, 4 Feb 1999 06:13:35 -0800 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id JAA10711; Thu, 4 Feb 1999 09:13:31 -0500 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.9.1b+Sun/8.8.8) with SMTP id JAA03825 for ; Thu, 4 Feb 1999 09:13:33 -0500 (EST) Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id JAA18314; Thu, 4 Feb 1999 09:13:32 -0500 Message-Id: <199902041413.JAA18314@bcn.East.Sun.COM> Date: Thu, 4 Feb 1999 09:13:32 -0500 (EST) From: Steve Hanna Reply-To: Steve Hanna Subject: MADCAP revised and submitted to IESG To: malloc@catarina.usc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vAZsLc96gYfjselBuHlSmA== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-malloc@catarina.usc.edu Precedence: bulk In response to comments received during Working Group Last Call, I have revised the MADCAP draft and submitted it to the Internet Drafts editor for distribution. I have also placed a copy on the malloc web page at http://north.east.isi.edu/malloc/draft-ietf-malloc-madcap-04.txt. A list of changes made in this version appears at the end of this email. Since we seem to have reached rough consensus on this document, I have submitted it to the IESG, requesting that it be published as a Proposed Standard. It should be entering IETF Last Call soon. Thanks, Steve Hanna -------------- Removed unused references and references to Internet Drafts. Clarified wording. Changed MAY to SHOULD in parts of sections 2.2.2, 2.2.3, and 2.2.4 that very much resemble the following: If a server can process the request with a shorter lease time or later start time than the client requested, it SHOULD send an ACK message with the lease time or start time that it can offer. Added a brief explanation of why it's not a good idea to adjust for substantial clock skew. Changed to new boilerplate on first page. From owner-malloc@catarina.usc.edu Tue Feb 9 10:30:31 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id KAA19895 for ; Tue, 9 Feb 1999 10:30:31 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id HAA05349 for malloc-list; Tue, 9 Feb 1999 07:00:34 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id HAA05345 for ; Tue, 9 Feb 1999 07:00:29 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA19307; Tue, 9 Feb 1999 09:59:55 -0500 (EST) Message-Id: <199902091459.JAA19307@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-04.txt Date: Tue, 09 Feb 1999 09:59:55 -0500 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 : Multicast Address Dynamic Client Allocation Protocol (MADCAP) Author(s) : B. Patel, M. Shah, S. Hanna Filename : draft-ietf-malloc-madcap-04.txt Pages : 40 Date : 08-Feb-99 This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-madcap-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-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-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: <19990208112125.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-madcap-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-madcap-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990208112125.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Mon Feb 15 22:49:58 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.8.5/8.8.7a) with SMTP id WAA15537 for ; Mon, 15 Feb 1999 22:49:57 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id TAA00895 for malloc-list; Mon, 15 Feb 1999 19:11:04 -0800 Received: from mailnew.fibertel.com.ar ([24.232.0.123]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id TAA00890 for ; Mon, 15 Feb 1999 19:10:54 -0800 Date: 16 Feb 1999 03:07:03 -0000 (added by MTA mailnew.fibertel.com.ar) X-Internal-ID: 36C1984F0001E7F1 Received: from pc-javier (24.232.9.235) by mailnew.fibertel.com.ar (NPlex 2.0.108) for malloc@catarina.usc.edu; 16 Feb 1999 03:07:02 -0000 Message-ID: <36C1984F0001E7F1@mailnew.fibertel.com.ar> (added by mailnew.fibertel.com.ar) From: IIBA To: "malloc@catarina.usc.edu" Subject: Cursos Intensivos de Informática de Sábados y Domingos. Reply-To: iiba@bitsmart.com X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk ATENCION: Cursos Intensivos de Informática de fin de semana. NO DEJE PASAR ESTA OPORTUNIDAD DE CAPACITARSE YA! OBJETO: Los cursos apuntan a resolver la problemática de las personas que no disponen del tiempo necesario para capacitarse durante la semana. Se entregará certificado de realización del curso. Práctica intensiva personalizada sobre computadoras (1 PC por alumno, 100% de práctica). CURSOS DISPONIBLES: Windows 95 (2 días - 16 hs.). Windows 98 - Operación (2 días 16 hs.). Windows 98 - Comunicaciones e Internet (1 día 8 hs.). Internet (1 día 8 hs.). Word 97 - Básico (2 días 16 hs.). Word 97 - Avanzado (1 día 8 hs.). Excel 97 - Básico (2 días 16 hs.). Excel 97 - Avanzado (2 días 16 hs.). AutoCAD 14 - Dibujo en 2 dimensiones (2 días 16 hs.). AutoCAD 14 - Dibujo en 3D y Modelado de Sólidos (2 días 16 hs.). OTROS CURSOS: Access 95 Access 97 Corel Draw 6.0 Corel Draw 8.0 Excel 95 Introducción al PC Office 95 Office 97 PowerPoint 95 PowerPoint 97 Visual Basic 4.0 Windows NT 4 - Workstation Word 95 Descuentos por más de un curso o a grupos de personas (consultar). Puede consultar los contenidos de los cursos, sus duraciones y costos en: http://www.bitsmart.com/iiba o enviarnos un e-mail a: iiba@bitsmart.com FECHAS Y HORARIOS DISPONIBLES (Febrero de 1999): Sábado 20/02 Domingo 21/02 Sábado 27/02 Domingo 28/02 En horarios de 9 a 13 hs. y 15 a 19 hs (consultar por horarios especiales). LUGAR: Los cursos de realizarán en Capital Federal (también se realizan cursos a distancia). RESERVAR VACANTE (Cupos limitados). A los interesados rogamos enviar los datos siguientes y nos pondremos en contacto. NOMBRE Y APELLIDO: EMPRESA y CARGO (Si corresponde): TELEFONO: CURSO(S) DE INTERES: FECHAS DE INTERES: Cordialmente, Depto. de Capacitación Instituto Informático Buenos Aires iiba@bitsmart.com Para mayor información sobre los cursos visite nuestra página en: http://www.bitsmart.com/iiba From owner-malloc@catarina.usc.edu Sun Feb 21 03:23:40 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00824 for ; Sun, 21 Feb 1999 03:23:40 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id XAA22976 for malloc-list; Sat, 20 Feb 1999 23:55:00 -0800 Received: from PROXY (smtp.sion.com [209.14.106.6]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id XAA22968 for ; Sat, 20 Feb 1999 23:54:53 -0800 Received: from gustavo-fiorito - 209.14.107.121 by sion.net with Microsoft SMTPSVC; Sun, 21 Feb 1999 04:53:23 -0300 Date: Sun, 21 Feb 1999 04:49:09 -0300 From: BNT - Empresa de Viajes y Turismo Subject: Pasajes Aereos Reply-To: bnt@overnet.com.ar To: malloc@catarina.usc.edu X-Mailer: dbMail v1.32 by Mach5 Software. Please report spamming to dbspam@mach5.com. Message-ID: <09fa32353071529PROXY@sion.net> Sender: owner-malloc@catarina.usc.edu Precedence: bulk Ante nada le pedimos disculpas por este mail no solicitado, de no querer seguir recibiendo esta informacion, por favor contestar a este mensaje con OUT en el Subject. Precios de Pasajes Aereos convenientes: Santiago de Chile: $ 99.- British Airways $ 130.- Aerolineas Argentinas Montevideo: $ 85.- Aerolineas Argentinas - Pluna - Lapa San Pablo: $ 222.- Canadian Rio de Janeiro: $ 277.- Vasp Miami: $ 549.- Aerolineas Argentinas vuelo diurno, $ 649.- Vuelo Nocturno New York: $ 649.- Aerolineas Argentinas Los Angeles: $ 899.- American Airlines Lima: $ 349.- Aero Peru , Aerolineas Argentinas Madrid: $ 799.- Spain Air Londres: $ 849.- Aerolineas Argentinas / $ 899.- british Airways Paris: $ 849.- Air France Punta del Este: $ 146.- Aerolineas Argentinas / Pluna Consulte por el itinerario que necesite, hoteleria, autmoviles, traslados. Servicio de atencion a empresas. Entrega de documentacion a domicilio. ____________________________________________________________________ Buenos Aires New Travel - Esmeralda 1269 - 1007 - Capital Federal 4315-8148 // 4312-5004 e-mail: bnt@overnet.com.ar ____________________________________________________________________ From owner-malloc@catarina.usc.edu Wed Feb 24 20:17:34 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06743 for ; Wed, 24 Feb 1999 20:17:33 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA07432 for malloc-list; Wed, 24 Feb 1999 16:50:52 -0800 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA07428 for ; Wed, 24 Feb 1999 16:50:47 -0800 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id SAA21385; Wed, 24 Feb 1999 18:38:23 -0800 (PST) (envelope-from dthaler) From: Dave Thaler Message-Id: <199902250238.SAA21385@dthaler.microsoft.com> Subject: AAP spec comments In-Reply-To: <199902041413.JAA18314@bcn.East.Sun.COM> from Steve Hanna at "Feb 4, 99 09:13:32 am" To: mjh@aciri.org Date: Wed, 24 Feb 1999 18:38:19 -0800 (PST) Cc: malloc@catarina.usc.edu X-Mailer: ELM [version 2.4ME+ PL32 (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 Comments on draft-ietf-malloc-masc-01.txt: The -01 version has been on the MALLOC web site for a while now (August '98) but needs to be submitted as an I-D. (BTW, for the rest of the list, the web site has been moved to http://www.aciri.org/malloc/ instead of the north.east.isi.edu site). The current spec does an admirable job of separating itself from the lower level protocol (MADCAP), but unfortunately does not separate itself well from the higher level protocol... it doesn't say "MDHCP" or "MADCAP" anywhere but says "MASC" all over the place. This is probably the biggest problem with the current presentation. It's especially important given that it's sounding likely that people may want to start running MADCAP+AAP soon, but not MASC anytime soon. Several places appear to imply that AAP only handles global addresses, not scoped ones (other places correctly mention scopes). For example, the first paragraph of section 3 appears to say that if no global prefix is known, a server cannot allocate any addresses (even scoped ones). It is also unclear (section 3.2 for instance) whether AAP uses a single address or a scope-relative address. Since I believe AAP is/should be using a scope-relative address (being bounded at the Allocation-Scope for communication about all larger scopes), this may also require some clarifications. If AAP is to be the intra-domain protocol, it needs IANA assignments for port and relative addresses (left as ??? in 3.2). MADCAP's packet formats handle multi-address allocations nicely, while AAP's packet formats are currently limited to single addresses. Similarly, some of the AAP messages assume IPv4 only. -Dave From owner-malloc@catarina.usc.edu Thu Feb 25 17:47:58 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24055 for ; Thu, 25 Feb 1999 17:47:57 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id OAA12349 for malloc-list; Thu, 25 Feb 1999 14:18:58 -0800 Received: from wwwnni.us.newbridge.com (wwwnni.us.newbridge.com [204.177.219.11]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id OAA12345 for ; Thu, 25 Feb 1999 14:18:48 -0800 Received: from herndon-mh1.us.newbridge.com (herndon-gw1 [204.177.219.66]) by wwwnni.us.newbridge.com (8.9.0/8.9.0) with ESMTP id RAA00484 for ; Thu, 25 Feb 1999 17:28:48 -0500 (EST) Received: from kraken.us.newbridge.com by herndon-mh1.us.newbridge.com; Thu, 25 Feb 1999 17:18:14 -0500 Received: from sailfish.nni by kraken.us.newbridge.com (SMI-8.6/SMI-SVR4) id RAA01938; Thu, 25 Feb 1999 17:15:46 -0500 Received: by sailfish.nni (SMI-8.6/SMI-SVR4) id QAA22787; Thu, 25 Feb 1999 16:53:30 -0500 From: adevgan@newbridge.com (Aman Devgan) Message-Id: <199902252153.QAA22787@sailfish.nni> Subject: Multiple sernder scenario To: malloc@catarina.usc.edu Date: Thu, 25 Feb 1999 16:53:30 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] 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 If two MADCAP clients request addresses for the same scope (TTL), does the MADPCAP server lease the same multicast address to them both? So if one of the many senders to a multicast group decides to leave and generates a RELEASE, the MADCAP server should not release this multicast address to be reused. Is this true? The draft-ietf-malloc-madcap-04.txt doesn't say much about how the MADCAP server manages the leases and addresses. Also is there a mechanism (like a dedicated UDP port) by which addresses in use within a scope are advertised to all hosts? Given enough information the receivers can make an informed decision about which multicast group to join. By the way, they will have to lease this group address from the MADCAP server, right? This mechanism could also be used by other senders to this group which can request lease on the address already in use for this scope. Thanks, -- Aman Devgan From owner-malloc@catarina.usc.edu Thu Feb 25 18:58:29 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28163 for ; Thu, 25 Feb 1999 18:58:28 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id PAA12845 for malloc-list; Thu, 25 Feb 1999 15:36:01 -0800 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id PAA12837 for ; Thu, 25 Feb 1999 15:35:52 -0800 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id RAA22563; Thu, 25 Feb 1999 17:23:31 -0800 (PST) (envelope-from dthaler) From: Dave Thaler Message-Id: <199902260123.RAA22563@dthaler.microsoft.com> Subject: Re: Multiple sernder scenario In-Reply-To: <199902252153.QAA22787@sailfish.nni> from Aman Devgan at "Feb 25, 99 04:53:30 pm" To: adevgan@newbridge.com (Aman Devgan) Date: Thu, 25 Feb 1999 17:23:31 -0800 (PST) Cc: malloc@catarina.usc.edu X-Mailer: ELM [version 2.4ME+ PL32 (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 > If two MADCAP clients request addresses for the same scope (TTL), TTL scoping should not be used, only admin scoping. > does the MADPCAP server lease the same multicast address to them both? If the requests are for non-overlapping times, the server is perfectly free to do so. > So if one of the many senders to a multicast group decides to leave and > generates a RELEASE, the MADCAP server should not release this multicast > address to be reused. Is this true? The MADCAP server will not release the address unless the client identifier matches, so if client that allocated the address doesn't give out the client identifier to any other sender, then the server won't release it. Additional access-control can be done if the server supports IPsec, although user-based IPsec is needed before it becomes really useful. > The draft-ietf-malloc-madcap-04.txt > doesn't say much about how the MADCAP server manages the leases > and addresses. From my understanding, that's because it's up to the implementation. > Also is there a mechanism (like a dedicated UDP port) by which addresses > in use within a scope are advertised to all hosts? That's what the SAP protocol is for. Session advertisement is covered by the MMUSIC WG. > Given enough information > the receivers can make an informed decision about which multicast group > to join. By the way, they will have to lease this group address from the > MADCAP server, right? No, only the session creator needs to lease the address. -Dave From owner-malloc@catarina.usc.edu Thu Feb 25 20:55:10 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03249 for ; Thu, 25 Feb 1999 20:55:09 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA13576 for malloc-list; Thu, 25 Feb 1999 17:33:19 -0800 Received: from wwwnni.us.newbridge.com (wwwnni.us.newbridge.com [204.177.219.11]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA13572 for ; Thu, 25 Feb 1999 17:33:12 -0800 Received: from herndon-mh1.us.newbridge.com (herndon-gw1 [204.177.219.66]) by wwwnni.us.newbridge.com (8.9.0/8.9.0) with ESMTP id UAA02609 for ; Thu, 25 Feb 1999 20:43:15 -0500 (EST) Received: from kraken.us.newbridge.com by herndon-mh1.us.newbridge.com; Thu, 25 Feb 1999 20:32:38 -0500 Received: from us.newbridge.com by kraken.us.newbridge.com (SMI-8.6/SMI-SVR4) id UAA03461; Thu, 25 Feb 1999 20:30:13 -0500 Message-Id: <36D5F7D7.C5B5E734@us.newbridge.com> Date: Thu, 25 Feb 1999 20:24:39 -0500 From: Aman Devgan X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: Aman Devgan , malloc@catarina.usc.edu Subject: Re: Multiple sernder scenario References: <199902260123.RAA22563@dthaler.microsoft.com> Content-Type: multipart/mixed; boundary="------------E393A133F3F59949DC6683B5" Sender: owner-malloc@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. --------------E393A133F3F59949DC6683B5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If the session creator decides to leave the group while there are other sources active in this multicast group, does the MADCAP server release the group address? The said active sources would then have to try to set up a new session. -- Aman Dave Thaler wrote: > > If two MADCAP clients request addresses for the same scope (TTL), > > TTL scoping should not be used, only admin scoping. > > > does the MADPCAP server lease the same multicast address to them both? > > If the requests are for non-overlapping times, the server > is perfectly free to do so. > > > So if one of the many senders to a multicast group decides to leave and > > generates a RELEASE, the MADCAP server should not release this multicast > > address to be reused. Is this true? > > The MADCAP server will not release the address unless the client > identifier matches, so if client that allocated the address doesn't > give out the client identifier to any other sender, then the server > won't release it. Additional access-control can be done if the > server supports IPsec, although user-based IPsec is needed before > it becomes really useful. > > > The draft-ietf-malloc-madcap-04.txt > > doesn't say much about how the MADCAP server manages the leases > > and addresses. > > >From my understanding, that's because it's up to the implementation. > > > Also is there a mechanism (like a dedicated UDP port) by which addresses > > in use within a scope are advertised to all hosts? > > That's what the SAP protocol is for. Session advertisement is covered > by the MMUSIC WG. > > > Given enough information > > the receivers can make an informed decision about which multicast group > > to join. By the way, they will have to lease this group address from the > > MADCAP server, right? > > No, only the session creator needs to lease the address. > > -Dave --------------E393A133F3F59949DC6683B5 Content-Type: text/x-vcard; charset=us-ascii; name="adevgan.vcf" Content-Description: Card for Aman Devgan Content-Disposition: attachment; filename="adevgan.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Devgan;Aman tel;fax:(703) 736-5959 tel;work:(703) 736-5853 x-mozilla-html:FALSE url:http://vivid-rnd.us.newbridge.com org:Newbridge Networks;Internetworking Product Development version:2.1 email;internet:adevgan@us.newbridge.com title:Design Engineer adr;quoted-printable:;;593 Herndon Parkway,=0D=0AHerndon, VA 20170;Herndon;Virginia;20170;Fairfax fn:Aman Devgan end:vcard --------------E393A133F3F59949DC6683B5-- From owner-malloc@catarina.usc.edu Thu Feb 25 21:03:58 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03539 for ; Thu, 25 Feb 1999 21:03:57 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA13596 for malloc-list; Thu, 25 Feb 1999 17:37:49 -0800 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA13590 for ; Thu, 25 Feb 1999 17:37:31 -0800 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id TAA22702; Thu, 25 Feb 1999 19:25:07 -0800 (PST) (envelope-from dthaler) From: Dave Thaler Message-Id: <199902260325.TAA22702@dthaler.microsoft.com> Subject: Re: Multiple sernder scenario In-Reply-To: <36D5F7D7.C5B5E734@us.newbridge.com> from Aman Devgan at "Feb 25, 99 08:24:39 pm" To: adevgan@us.newbridge.com (Aman Devgan) Date: Thu, 25 Feb 1999 19:25:07 -0800 (PST) Cc: dthaler@dthaler.microsoft.com, adevgan@newbridge.com, malloc@catarina.usc.edu X-Mailer: ELM [version 2.4ME+ PL32 (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 Aman writes: > If the session creator decides to leave the group while there are other > sources > active in this multicast group, does the MADCAP server release the group > address? The said active sources would then have to try to set up a new > session. No, the address allocation is unrelated to membership. The session creator may never even join or send anything to the group. For example, you might allocate the address from one machine and advertise the session far in advance. When the start time arrives, you might participate in the session on a different machine. -Dave From owner-malloc@catarina.usc.edu Fri Feb 26 11:34:39 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21821 for ; Fri, 26 Feb 1999 11:34:38 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id HAA15754 for malloc-list; Fri, 26 Feb 1999 07:40:18 -0800 Received: from aardvark.aciri.org ([192.150.187.20]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id HAA15750 for ; Fri, 26 Feb 1999 07:40:13 -0800 Received: from aardvark.aciri.org (localhost [127.0.0.1]) by aardvark.aciri.org (8.9.2/8.9.2) with ESMTP id HAA26158 for ; Fri, 26 Feb 1999 07:40:16 -0800 (PST) (envelope-from mjh@aardvark.aciri.org) From: Mark Handley X-Organisation: ACIRI To: malloc@catarina.usc.edu Subject: MALLOC web pages Date: Fri, 26 Feb 1999 07:40:16 -0800 Message-ID: <26156.920043616@aardvark.aciri.org> Sender: owner-malloc@catarina.usc.edu Precedence: bulk As of today, the web server on north.east.isi.edu no longer exists. The MALLOC web pages can now be found at http://www.aciri.org/malloc If you have any links to the old pages, could you please amend them. Cheers, Mark From owner-malloc@catarina.usc.edu Wed Mar 3 21:12:58 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17315 for ; Wed, 3 Mar 1999 21:12:57 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id RAA09951 for malloc-list; Wed, 3 Mar 1999 17:51:52 -0800 Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id RAA09947 for ; Wed, 3 Mar 1999 17:51:49 -0800 Received: (dmm@localhost) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id RAA26085; Wed, 3 Mar 1999 17:51:18 -0800 (PST) Date: Wed, 3 Mar 1999 17:51:18 -0800 (PST) Message-Id: <199903040151.RAA26085@zipper.cisco.com> From: David Meyer To: mboned@network-services.uoregon.edu, malloc@catarina.usc.edu Subject: Use of 226/8 for static allocations Sender: owner-malloc@catarina.usc.edu Precedence: bulk MBONED Working Group David Meyer Internet Draft Cisco Systems Category Experimental draft-ietf-mboned-glop-bits-00.txt March, 1999 Glop Bit Usage 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This describes an experimental policy for use of the class D address space using 226/8 as the experimental subset. This new experimental allocation is in addition to those described on [IANA] (e.g. [RFC2365]). This memo is a product of the MBONE Deployment Working Group (MBONED) in the Operations and Management Area of the Internet Engineering Task Force. Submit comments to or the authors. David Meyer [Page 1] Internet Draft draft-ietf-mboned-glop-bits-00.txt Feburary, 1999 3. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. 4. Problem Statement Multicast address have traditionally been allocated by a dynamic mechanism such as SDR [SAP]. However, many current multicast deployment models are not amenable to dynamic allocation. For example, many content aggregators require group addresses which are fixed on a time scale which is not amenable to allocation by a mechanism such as described in [SAP]. Perhaps more seriously, since there isn't general consensus by providers, content aggregators, or application writers as to the allocation mechanism, the Internet is left with out a coherent multicast address allocation scheme. While the MALLOC working group is looking at a specific strategy [MADCAP, MASC], it is proposed that a different strategy be developed in parallel. 5. Glop Bits For purposes of the experiment described here, the IANA should allocate 226/8. The remaining 24 bits (GLOP bits) will be administered as described here. A multicast address in 226/8 is structured as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 226 |X| GLOP Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The GLOP Bits field is comprised of an assigned prefix and a local use field: David Meyer [Page 2] Internet Draft draft-ietf-mboned-glop-bits-00.txt Feburary, 1999 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 226 |X| Variable Length Prefix + Local Use Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that the maximum length of an assigned prefix is 22. The Local Use field is intended for local administration though an unspecified mechanism (while such a mechanism is outside the scope of this draft, see e.g. [MADCAP]).Finally, the addresses the X bit set to zero are reserved for future use. 6. Allocation The glop bits are intended to be used in an experiment of static allocation to achieve aggregation in a manner similar to the TLA approach described in [RFC2374]. 7. Security Considerations The approach described here may have the effect of reduced exposure to denial of space attacks as it greatly reduces the space that is dynamically assigned. Further, since dynamic assignment does not cross domain boundaries, well known intra-domain security techniques can be applied. 8. IANA Considerations IANA should allocate 226/8 for experimental assignments. This assigment should timeout one year after the assigment is made. The assignment may be renewed at that time. It should be noted that the experiment described here is in the same spirit the experiment described in [RFC1707]. David Meyer [Page 3] Internet Draft draft-ietf-mboned-glop-bits-00.txt Feburary, 1999 9. Acknowledgments This idea originated with Peter Lothberg's idea that we use the same allocation (AS based) as described in RFC 1797 in the class D address space. Randy Bush contributed many insightful comments. 10. References [MADCAP] B. Patel, et. al., "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", draft-ietf-malloc-madcap-04.txt, Feburay, 1999. [MASC] D. Estrin, et. al., "The Multicast Address-Set Claim (MASC) Protocol", draft-ietf-malloc-masc-01.txt, August, 1998. [IANA] www.isi.edu/in-notes/iana/assignments/multicast-addresses [RFC1797] IANA, "Class A Subnet Experiment", RFC 1797, April, 1995. [RFC2365] David Meyer, "Administratively Scoped IP Multicast", July, 1998. [RFC2374] R. Hinden, et. al., "An IPv6 Aggregatable Global Unicast Address Format", July, 1998. [SAP] Handley, Mark, "SAP: Session Announcement Protocol", draft-ietf-mmusic-sap-00.txt, November, 1996. 11. Author's Address David Meyer Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134-1706 United States EMail: dmm@cisco.com David Meyer [Page 4] From owner-malloc@catarina.usc.edu Wed Mar 3 21:36:10 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20786 for ; Wed, 3 Mar 1999 21:36:08 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id SAA10049 for malloc-list; Wed, 3 Mar 1999 18:17:52 -0800 Received: from aardvark.aciri.org ([192.150.187.20]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id SAA10045 for ; Wed, 3 Mar 1999 18:17:48 -0800 Received: from aardvark.aciri.org (localhost [127.0.0.1]) by aardvark.aciri.org (8.9.2/8.9.2) with ESMTP id SAA42590; Wed, 3 Mar 1999 18:17:36 -0800 (PST) (envelope-from mjh@aardvark.aciri.org) From: Mark Handley X-Organisation: ACIRI To: David Meyer cc: mboned@network-services.uoregon.edu, malloc@catarina.usc.edu Subject: Re: Use of 226/8 for static allocations In-reply-to: Your message of "Wed, 03 Mar 1999 17:51:18 PST." <199903040151.RAA26085@zipper.cisco.com> Date: Wed, 03 Mar 1999 18:17:36 -0800 Message-ID: <42588.920513856@aardvark.aciri.org> Sender: owner-malloc@catarina.usc.edu Precedence: bulk > Glop Bit Usage ... > This describes an experimental policy for use of the class D address > space using 226/8 as the experimental subset. This new experimental > allocation is in addition to those described on [IANA] (e.g. > [RFC2365]). ... > IANA should allocate 226/8 for experimental assignments. This > assigment should timeout one year after the assigment is made. The > assignment may be renewed at that time. It should be noted that the > experiment described here is in the same spirit the experiment > described in [RFC1707]. Apart from the facts that static allocation results in poor address space utilization (witness unicast address allocation), there is an issue with address space leakage. It's quite likely that addresses will be statically allocated, and then permanently fall into disuse (get forgotten about, get allocated to companies that disappear, etc). I would say that this proposal is infeasible in the long run unless the static allocations themselves have a lifetime, and time out if they're not renewed. This is about the only way IANA would be able to terminate this experiment after a year if it was considered a failure. Also it's in keeping with transitioning between truely dynamic allocation (MASC-style) and "static" allocation as users require one or the other for whatever reason. Cheers, Mark From owner-malloc@catarina.usc.edu Fri Mar 5 15:13:35 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21627 for ; Fri, 5 Mar 1999 15:13:34 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA17816 for malloc-list; Fri, 5 Mar 1999 11:27:17 -0800 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA17812 for ; Fri, 5 Mar 1999 11:27:10 -0800 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id NAA04933; Fri, 5 Mar 1999 13:14:03 -0800 (PST) (envelope-from dthaler) From: Dave Thaler Message-Id: <199903052114.NAA04933@dthaler.microsoft.com> Subject: MZAP status To: mboned@network-services.uoregon.edu Date: Fri, 5 Mar 1999 13:14:03 -0800 (PST) Cc: malloc@catarina.usc.edu X-Mailer: ELM [version 2.4ME+ PL32 (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 IANA has now assigned a port number for MZAP: 2106 They didn't however read my request for a scope-relative address very well (which I made clear twice) since they assigned us a single global address. I've complained, so we're still waiting for a scope-relative address (which I assume will be "3"). -Dave From owner-malloc@catarina.usc.edu Fri Mar 5 15:38:39 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22092 for ; Fri, 5 Mar 1999 15:38:38 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA17970 for malloc-list; Fri, 5 Mar 1999 12:02:57 -0800 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA17966 for ; Fri, 5 Mar 1999 12:02:44 -0800 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id NAA04993; Fri, 5 Mar 1999 13:49:45 -0800 (PST) (envelope-from dthaler) From: Dave Thaler Message-Id: <199903052149.NAA04993@dthaler.microsoft.com> Subject: MALLOC Agenda Items for Minneapolis To: malloc@catarina.usc.edu Date: Fri, 5 Mar 1999 13:49:45 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL32 (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 Please forward any more requests for agenda items to me, along with a pointer to a draft (put it on a web page if you didn't make the I-D deadline). So far I have received requests for the following agenda items: * Charter update - Thaler/Hanna * MADCAP Changes (short) - Shah/Patel/Hanna draft-ietf-malloc-madcap-04.txt * MALLOC MIB - Thaler draft-ietf-malloc-malloc-mib-00.txt * AAP? - ?? draft-handley-aap-1.ps (available from MALLOC web site) * Use of 226/8 - Meyer draft-ietf-mboned-glop-bits-00.txt (recently posted to MALLOC list) * MADCAP Scope Nesting option - Kermode draft-kermode-madcap-nest-opt-00.txt Reminder: the MALLOC web site is now at http://www.aciri.org/malloc/ See you all in Minneapolis, -Dave From owner-malloc@catarina.usc.edu Fri Mar 5 16:06:23 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22595 for ; Fri, 5 Mar 1999 16:06:20 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA18205 for malloc-list; Fri, 5 Mar 1999 12:35:55 -0800 Received: from dthaler.microsoft.com ([131.107.1.30]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA18198 for ; Fri, 5 Mar 1999 12:35:48 -0800 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id OAA05079; Fri, 5 Mar 1999 14:22:47 -0800 (PST) (envelope-from dthaler) From: Dave Thaler Message-Id: <199903052222.OAA05079@dthaler.microsoft.com> Subject: Re: MZAP status In-Reply-To: <199903052114.NAA04933@dthaler.microsoft.com> from Dave Thaler at "Mar 5, 99 01:14:03 pm" To: dthaler@dthaler.microsoft.com (Dave Thaler) Date: Fri, 5 Mar 1999 14:22:47 -0800 (PST) Cc: mboned@network-services.uoregon.edu, malloc@catarina.usc.edu X-Mailer: ELM [version 2.4ME+ PL32 (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 Okay, just heard back from IANA. MZAP has been assigned the scope-relative address TOP-3 as expected. I'm not aware of any other issues that need to be resolved. Dave M., when can we start a WG last call? -Dave From owner-malloc@catarina.usc.edu Wed Mar 10 09:07:18 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10348 for ; Wed, 10 Mar 1999 09:07:17 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id FAA07577 for malloc-list; Wed, 10 Mar 1999 05:38:43 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id FAA07573 for ; Wed, 10 Mar 1999 05:38:36 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09643; Wed, 10 Mar 1999 08:38:02 -0500 (EST) Message-Id: <199903101338.IAA09643@ietf.org> To: IETF-Announce:; Cc: malloc@catarina.usc.edu From: The IESG SUBJECT: Last Call: Multicast Address Dynamic Client Allocation Protocol (MADCAP) to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 10 Mar 1999 08:38:02 -0500 Sender: owner-malloc@catarina.usc.edu Precedence: bulk The IESG has received a request from the Multicast-Address Allocation Working Group to consider Multicast Address Dynamic Client Allocation Protocol (MADCAP) 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 March 31, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-malloc-madcap-04.txt From owner-malloc@catarina.usc.edu Thu Mar 11 15:41:51 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10461 for ; Thu, 11 Mar 1999 15:41:50 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA13789 for malloc-list; Thu, 11 Mar 1999 11:54:23 -0800 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA13785 for ; Thu, 11 Mar 1999 11:54:19 -0800 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.8.5/8.6.9) with ESMTP id LAA22989 for ; Thu, 11 Mar 1999 11:54:17 -0800 (PST) Message-Id: <199903111954.LAA22989@rumi.usc.edu> To: malloc@catarina.usc.edu Subject: MASC port assigned Date: Thu, 11 Mar 1999 11:54:17 -0800 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk FYI, IANA has assigned the following port to MASC: masc 2587/tcp MASC masc 2587/udp MASC Well, I asked only for a TCP port, so the UDP port is a bonus, just in case any part of malloc needs it :) Pavlin From owner-malloc@catarina.usc.edu Thu Mar 11 15:46:16 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10524 for ; Thu, 11 Mar 1999 15:45:53 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA13798 for malloc-list; Thu, 11 Mar 1999 11:55:28 -0800 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA13794 for ; Thu, 11 Mar 1999 11:55:24 -0800 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.8.5/8.6.9) with ESMTP id LAA23000 for ; Thu, 11 Mar 1999 11:55:19 -0800 (PST) Message-Id: <199903111955.LAA23000@rumi.usc.edu> To: malloc@catarina.usc.edu Subject: Malloc address block Date: Thu, 11 Mar 1999 11:55:18 -0800 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk I just saw that the following block of multicast addresses has been assigned for dynamic allocation: 225.0.0.0-225.255.255.255 MALLOC (temp - renew 12/99) [Handley] Because people will start doing malloc experiments with this block of addresses, I would suggest temporarily dividing the space across different parts of the architecture to avoid any unwanted intereference during debugging stages. For example: 225.0.0.0-225.0.255.255 Single host API experiments (without MADCAP) 225.1.0.0-225.1.255.255 Local experiments with MADCAP (without MASC) 225.2.0.0-225.127.255.255 Reserved 225.128.0.0-225.255.255.255 MASC experiments Suggestions/comments? Pavlin From owner-malloc@catarina.usc.edu Thu Mar 11 16:34:19 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11746 for ; Thu, 11 Mar 1999 16:34:15 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA13992 for malloc-list; Thu, 11 Mar 1999 12:41:16 -0800 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA13988; Thu, 11 Mar 1999 12:41:12 -0800 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.8.5/8.6.9) with ESMTP id MAA23096; Thu, 11 Mar 1999 12:41:06 -0800 (PST) Message-Id: <199903112041.MAA23096@rumi.usc.edu> To: Mark Handley cc: malloc@catarina.usc.edu Subject: Re: Malloc address block In-reply-to: Your message of "Thu, 11 Mar 1999 12:27:39 PST." <66065.921184059@aardvark.aciri.org> Date: Thu, 11 Mar 1999 12:41:06 -0800 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk > >225.0.0.0-225.0.255.255 Single host API experiments (without MADCAP) > >225.1.0.0-225.1.255.255 Local experiments with MADCAP (without MASC) > >225.2.0.0-225.127.255.255 Reserved > >225.128.0.0-225.255.255.255 MASC experiments > > > > I'm not clear we need addresses from the global malloc space for the > single host and local experiments. Shouldn't they come from the > local-scope range instead to ensure that local experiments don't clash > with each other? Yes, you are right. The above dividing will only prevent different pieces of malloc interfering with each other, but the membership is global (i.e. the mcast routing will not be stop at the borders). So: 225.0.0.0-225.127.255.255 Reserved 225.128.0.0-225.255.255.255 MASC experiments Pavlin From owner-malloc@catarina.usc.edu Thu Mar 11 16:58:04 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12285 for ; Thu, 11 Mar 1999 16:58:02 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA13939 for malloc-list; Thu, 11 Mar 1999 12:27:32 -0800 Received: from aardvark.aciri.org ([192.150.187.20]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA13935; Thu, 11 Mar 1999 12:27:25 -0800 Received: from aardvark.aciri.org (localhost [127.0.0.1]) by aardvark.aciri.org (8.9.2/8.9.2) with ESMTP id MAA66067; Thu, 11 Mar 1999 12:27:39 -0800 (PST) (envelope-from mjh@aardvark.aciri.org) From: Mark Handley X-Organisation: ACIRI To: Pavlin Ivanov Radoslavov cc: malloc@catarina.usc.edu Subject: Re: Malloc address block In-reply-to: Your message of "Thu, 11 Mar 1999 11:55:18 PST." <199903111955.LAA23000@rumi.usc.edu> Date: Thu, 11 Mar 1999 12:27:39 -0800 Message-ID: <66065.921184059@aardvark.aciri.org> Sender: owner-malloc@catarina.usc.edu Precedence: bulk >I just saw that the following block of multicast addresses has >been assigned for dynamic allocation: > >225.0.0.0-225.255.255.255 MALLOC (temp - renew 12/99) [Handley] > >Because people will start doing malloc experiments with this block >of addresses, I would suggest temporarily dividing the space across >different parts of the architecture to avoid any unwanted >intereference during debugging stages. For example: > >225.0.0.0-225.0.255.255 Single host API experiments (without MADCAP) >225.1.0.0-225.1.255.255 Local experiments with MADCAP (without MASC) >225.2.0.0-225.127.255.255 Reserved >225.128.0.0-225.255.255.255 MASC experiments > >Suggestions/comments? I'm not clear we need addresses from the global malloc space for the single host and local experiments. Shouldn't they come from the local-scope range instead to ensure that local experiments don't clash with each other? Also it's probably worth reserving 225.0.0.0-225.0.0.255 so that we don't hash into the same Mac address as the link-local groups. Although these groups should behave reasonably, it seems risky to use them at the moment. Cheers, Mark From owner-malloc@catarina.usc.edu Sat Mar 13 15:51:36 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08466 for ; Sat, 13 Mar 1999 15:51:35 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA23622 for malloc-list; Sat, 13 Mar 1999 12:29:40 -0800 Received: from mailnew.fibertel.com.ar ([24.232.0.123]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA23611 for ; Sat, 13 Mar 1999 12:29:27 -0800 X-Internal-ID: 36EA310200003D80 Received: from pc-javier (24.232.9.175) by mailnew.fibertel.com.ar (NPlex 2.0.108) for malloc@catarina.usc.edu; 13 Mar 1999 20:25:38 -0000 Message-ID: <36EA310200003D80@mailnew.fibertel.com.ar> (added by mailnew.fibertel.com.ar) Date: Sat, 13 Mar 1999 17:30:47 -0300 From: IIBA Subject: Cursos Intensivos de Informática de Sábados y Domingos. Reply-To: iiba@bitsmart.com To: malloc@catarina.usc.edu X-Mailer: dbMail v1.3b1 by Mach5 Software. Please report spamming to dbspam@mach5.com. Content-Transfer-Encoding: Quoted-Printable MIME-Version: 1.0 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: Quoted-Printable AT.: malloc@catarina.usc.edu ATENCION: Cursos Intensivos de Inform=E1tica de fin de semana. NO DEJE PASAR ESTA OPORTUNIDAD DE CAPACITARSE YA! OBJETO: Los cursos apuntan a resolver la problem=E1tica de las personas q= ue no disponen del tiempo necesario para capacitarse durante la semana.=20 Se entregar=E1 diploma de realizaci=F3n del curso. Pr=E1ctica intensiva personalizada sobre computadoras (1 PC por alumno, 1= 00% de pr=E1ctica). CURSOS DISPONIBLES: Windows 95 (2 d=EDas - 16 hs.). $ 150,-- Windows 98 - Operaci=F3n (2 d=EDas 16 hs.). $ 150,-- Windows 98 - Comunicaciones e Internet (1 d=EDa 8 hs.). $ 90,-- Internet (1 d=EDa 8 hs.). $ 90,-- Word 97 - B=E1sico (2 d=EDas 16 hs.). $ 150,-- Word 97 - Avanzado (1 d=EDa 8 hs.). $ 90,-- Excel 97 - B=E1sico (2 d=EDas 16 hs.). $ 150,-- Excel 97 - Avanzado (2 d=EDas 16 hs.). $ 150,-- AutoCAD 14 - Dibujo en 2 dimensiones (2 d=EDas 16 hs.). $ 150,-- AutoCAD 14 - Dibujo en 3D y Modelado de S=F3lidos (2 d=EDas 16 hs.). $ 15= 0,-- OTROS CURSOS: Access 95 Access 97 Corel Draw 6.0 Corel Draw 8.0 Excel 95 Introducci=F3n al PC Office 95 Office 97 PowerPoint 95 PowerPoint 97 Visual Basic 4.0 Windows NT 4 - Workstation Word 95 Puede consultar los contenidos de los cursos, sus duraciones y costos enviandonos un e-mail a: iiba@bitsmart.com FECHAS Y HORARIOS DISPONIBLES (Marzo de 1999): S=E1bado 13/03 Domingo 14/03 S=E1bado 20/03 Domingo 21/03 S=E1bado 27/03 Domingo 28/03 En horarios de 9 a 13 hs. y 15 a 19 hs (consultar por horarios especiales). LUGAR: Los cursos de realizar=E1n en Capital Federal (tambi=E9n se realizan curs= os a distancia). RESERVAR VACANTE (Cupos limitados). A los interesados rogamos enviar los datos siguientes y nos pondremos en contacto. NOMBRE Y APELLIDO: EMPRESA y CARGO (Si corresponde): TELEFONO: CURSO(S) DE INTERES: FECHAS DE INTERES: Cordialmente, Depto. de Capacitaci=F3n Instituto Inform=E1tico Buenos Aires iiba@bitsmart.com From owner-malloc@catarina.usc.edu Tue Mar 23 20:17:02 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05093 for ; Tue, 23 Mar 1999 20:17:01 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA24080 for malloc-list; Tue, 23 Mar 1999 16:44:29 -0800 Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA24071 for ; Tue, 23 Mar 1999 16:44:22 -0800 Received: (dmm@localhost) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id QAA06460; Tue, 23 Mar 1999 16:42:48 -0800 (PST) Date: Tue, 23 Mar 1999 16:42:48 -0800 (PST) Message-Id: <199903240042.QAA06460@zipper.cisco.com> From: David Meyer To: internet-drafts@ietf.org cc: malloc@catarina.usc.edu, mboned@network-services.uoregon.edu Subject: please post draft (draft-ietf-malloc-static-allocation-00.txt) Sender: owner-malloc@catarina.usc.edu Precedence: bulk Thanks, Dave MBONED Working Group David Meyer Internet Draft Cisco Systems Peter Lothberg Sprint Category Experimental draft-ietf-malloc-static-allocation-00.txt March, 1999 Static Allocations in 233/8 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This describes an experimental policy for use of the class D address space using 226/8 as the experimental statically assigned subset of the class D address space. This new experimental allocation is in addition to those described on [IANA] (e.g. [RFC2365]). This memo is a product of the Multicast-Address Allocation working group (MALLOC) in the Internat and Transport Areas of the Internet Engineering Task Force. Submit comments to or the authors. David Meyer [Page 1] Internet Draft draft-ietf-malloc-static-allocation-00.txt March, 1999 3. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. 4. Problem Statement Multicast address have traditionally been allocated by a dynamic mechanism such as SDR [SAP]. However, many current multicast deployment models are not amenable to dynamic allocation. For example, many content aggregators require group addresses which are fixed on a time scale which is not amenable to allocation by a mechanism such as described in [SAP]. Perhaps more seriously, since there isn't general consensus by providers, content aggregators, or application writers as to the allocation mechanism, the Internet is left without a coherent multicast address allocation scheme. While the MALLOC working group is looking at a specific strategy [MADCAP, MASC], it is proposed that a different strategy be developed in parallel. 5. Address Space For purposes of the experiment described here, the IANA should allocate 233/8. The remaining 24 bits will be administered in a manner similar to that described in RFC1797: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 233 | 16 bits AS | local bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1. Example Consider, for example, AS 5662. Written in binary, left padded with 0s, we get 0001011000011110 Mapping the high order octet to the second octet of the address, and the low order octect to the the third octet, we get 233.22.30/24. David Meyer [Page 2] Internet Draft draft-ietf-malloc-static-allocation-00.txt March, 1999 6. Allocation As mentioned above, the allocation propsed here follows the RFC1797 (case 1) allocation scheme, modified as follows: the high order octet has the value 233, and the next 16 bits are a previously assigned Autonomous System number (AS), as registered by a network registry and listed in the RWhois database system. This allows a single /24 per AS. As was the case RFC1797, using the AS number in this way allows the experiment to get underway quickly in that it automatically allocates some addresses to each service provider and does not require a registration step. 6.1. Private AS Space Thhe address space mapped to the private AS space (as defined in [RFC1930], is reserved for future allocation. 7. Security Considerations The approach described here may have the effect of reduced exposure to denial of space attacks as it greatly reduces the space that is dynamically assigned. Further, since dynamic assignment does not cross domain boundaries, well known intra-domain security techniques can be applied. 8. IANA Considerations IANA should allocate 233/8 for experimental assignments. This assigment should timeout one year after the assigment is made. The assignment may be renewed at that time. It should be noted that the experiment described here is in the same spirit the experiment described in [RFC1707]. David Meyer [Page 3] Internet Draft draft-ietf-malloc-static-allocation-00.txt March, 1999 9. Acknowledgments This idea originated with Peter Lothberg's idea that we use the same allocation (AS based) as described in RFC 1797 in the class D address space. Randy Bush and Mark Handley contributed many insightful comments. 10. References [MADCAP] B. Patel, et. al., "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", draft-ietf-malloc-madcap-04.txt, Feburay, 1999. [MASC] D. Estrin, et. al., "The Multicast Address-Set Claim (MASC) Protocol", draft-ietf-malloc-masc-01.txt, August, 1998. [IANA] www.isi.edu/in-notes/iana/assignments/multicast-addresses [RFC1797] IANA, "Class A Subnet Experiment", RFC 1797, April, 1995. [RFC1930] J. Hawkinson, et. al., "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC1930, March, 1996. [RFC2365] David Meyer, "Administratively Scoped IP Multicast", July, 1998. [RFC2374] R. Hinden, et. al., "An IPv6 Aggregatable Global Unicast Address Format", July, 1998. [SAP] Handley, Mark, "SAP: Session Announcement Protocol", draft-ietf-mmusic-sap-00.txt, November, 1996. David Meyer [Page 4] Internet Draft draft-ietf-malloc-static-allocation-00.txt March, 1999 11. Author's Address David Meyer Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134-1706 United States EMail: dmm@cisco.com Peter Lothberg Sprint VARESA0104 12502 Sunrise Valley Drive Reston VA, 20196 Email: roll@sprint.net David Meyer [Page 5] From owner-malloc@catarina.usc.edu Mon Mar 29 13:41:41 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21465 for ; Mon, 29 Mar 1999 13:41:40 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA11478 for malloc-list; Mon, 29 Mar 1999 10:09:50 -0800 Received: from network-services.uoregon.edu (network-services.uoregon.edu [128.223.60.21]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA11474 for ; Mon, 29 Mar 1999 10:09:44 -0800 Received: (from shep@localhost) by network-services.uoregon.edu (8.9.1/8.9.1) id KAA14339; Mon, 29 Mar 1999 10:04:01 -0800 (PST) Message-Id: <199903291804.KAA14339@network-services.uoregon.edu> X-Mailer: exmh version 2.0gamma 1/27/96 To: malloc@catarina.usc.edu, mboned@network-services.uoregon.edu Subject: 233/24 Calculator Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Mar 1999 10:04:01 -0800 From: Greg Shepherd Sender: owner-malloc@catarina.usc.edu Precedence: bulk It's not pretty, but it's functional. http://www.ogig.net/glop Greg Shepherd University of Oregon From owner-malloc@catarina.usc.edu Wed Mar 31 16:37:40 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01407 for ; Wed, 31 Mar 1999 16:37:39 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA23245 for malloc-list; Wed, 31 Mar 1999 12:33:49 -0800 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 MAA23241 for ; Wed, 31 Mar 1999 12:33:43 -0800 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA06632 for ; Wed, 31 Mar 1999 12:33:45 -0800 (PST) Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id PAA25130; Wed, 31 Mar 1999 15:33:01 -0500 Received: from bcn.East.Sun.COM (bcn [129.148.75.4]) by suneast.East.Sun.COM (8.9.1b+Sun/8.8.8) with SMTP id PAA01013 for ; Wed, 31 Mar 1999 15:32:57 -0500 (EST) Received: from sun.com by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id PAA18349; Wed, 31 Mar 1999 15:32:54 -0500 Message-ID: <37028679.14EE0AED@sun.com> Date: Wed, 31 Mar 1999 15:32:57 -0500 From: Steve Hanna Organization: Sun Microsystems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: malloc@catarina.usc.edu Subject: draft MALLOC minutes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Here is a draft of the minutes for the MALLOC meeting at IETF 44. Please get comments back to the list by Friday morning, since that's the deadline for submitting minutes to the proceedings. I apologize for taking so long to get these out. The fault is entirely mine. Steve Casner got the minutes to me promptly, but I've been very busy. Thanks, Steve ------------ Minutes of MALLOC Working Group IETF 44 (Minneapolis, MN) Tuesday, March 16, 1999 Minutes reported by S. Casner and S. Hanna. Agenda: Agenda Bashing Thaler MADCAP Update Hanna Scope Nesting Kermode AAP Update Hanna MASC Status Radoslavov Static Allocation Meyer MALLOC MIB Thaler Milestone Update Thaler I. MADCAP Update MADCAP was pretty well settled at last IETF, so it has gone to WG last call in January and IETF last call last week. Soon expected to be published as Proposed Standard. Abstract API update: The draft is unchanged since November, but Ross commits to revising the draft to reflect changes in MADCAP by next month. The revised draft is to go to last call after next IETF. II. MADCAP Scope Nesting Option Problem: TTL scoping doesn't work for large scopes. We go to admin scoping to solve this, but then we need to be able to do nesting of scopes to have the same expanding ring effect that TTLs provided. To do nested scopes, need three protocols: MZAP, this proposal, and SADP. MADCAP lists the scopes enclosing a given point, but doesn't provide nesting info. A pair of scopes A and B may have the relationship AB, or A=B. Listing all the pairwise combinations is too long. The list is sparse because not all scopes will nest, so we could do some sort of list of pairs, a dense matrix, or a sparse matrix (list of lists). To keep things simple, and based on the assumption that the number of scopes is O(10), the proposal is to use a dense binary matrix representation with the diagonal deleted and padded to an even byte boundary per row. The bit string is 1 wherever the scope corresponding to the row element is nested in the scope represented by the column. Consensus was that this should become a working group document headed for Proposed Standard. III. AAP Status AAP is an intradomain address allocation protocol that works via periodic announcements, based on SAP. It is used be MADCAP servers (and others) to communicate within a domain. The original draft was by Mark Handley. Steve Hanna is joining now as a co-author to help move it forward to last call by August. Open issues: - Need IPv6 support (MADCAP has it) - Want to be able to represent allocated addresses as ranges to reduce message size; currently have to list addresses individually, and we expect them to be allocated and used in blocks. - Need signature format; there are some ideas but no strong candidates yet. - Need server mobility, like DHCP failover. MADCAP uses a secret representing allocation ownership to prevent someone else taking action on the allocation. How to communicate these secrets from the server that does the allocation to the backup servers? Use a cryptographic hash of client ID so it can be communicated in the clear. Mark Handley raised the issue that the client identifier may not have cryptographic randomness, so it may be possible to search the client id space to find one that matches the hash. - Use MADCAP message format for AAP? This would allow more shared code. On the other hand, the functions are different, so code savings might not be large. Handley: This might cause confusion. Even though the syntax of the messages would be the same for MADCAP and AAP, the semantics are totally different. Thaler: MADCAP has an extensible options-based format, which is convenient. - Shall we change the name of AAP? The relationship to MADCAP is not obvious, and the server-to-server nature is not obvious. Hanna has not heard a name he likes better yet. Take this to the list for suggestions. Want to resolve in next few weeks. IV. MASC Implementation & Status MASC functions: 1. Associate group ranges with AS's, hierarchically allocated from parents to children. 2. Announce group ranges to MADCAP servers using AAP. To implement a MASC server, MUST implement MASC protocol and part of AAP (the part that handles announcement of addresses). SHOULD also implment MZAP. Overview of the implementation design: three layers - communication upward with parent domain via MASC - my own domain (state mainenance) - communication with child domain via MASC, also AAP to the local domain Working on implementation as a stand-alone server. MASC protocol is done, AAP and MZAP not yet. 30% of 10000 lines is MASC. TODO: MASC QUERY and RESPONSE debug msgs. Why not just use SNMP? It's faster and easier to implement MASC's own messages; could do both. Thaler - More important than faster and easier is that you can get an answer from more remote domains, as mrinfo can do for multicast routers. SNMP is better for looking at nodes in one's own domain. Pavlin says, yes, we do want to have access to other domains, especially for debugging. This access can be turned off when desired. Maybe these messages should be in a separate draft as a feature to use only during debugging stage. Needs to do testing, and implement AAP, MZAP. Stable Storage format MASC will run on BG(M)P routers that in general do not have stable storage. A reboot of one node is not a problem because info can be restored from other nodes so long as you trust your neighbors with your internal state; but if all reboot at once, info is lost. Another solution is to use AAP to store internal state on a MADCAP server that does have a disk. This is more complicated, and can record only part of the information that MASC has (PREFIX_IN_USE and allocated-by-madcap addresses). Handley: This doesn't complicate AAP because it needs this info anyway. Third solution is to run at least one diskful MASC node, maybe in a non-router. But this has a configuration problem: normally MASC peering of the routers is implicit in BG(M)P peering; adding a non-router requires configuration. Can solve this with UDP multicast of MASC OPEN messages from the diskful server; then each MASC router establishes a TCP connecion back to the diskful node. Handley: There is a problem with this because there could be a conflict between what one learns from AAP and from MASC peers. Those need to be consistent. Thinks that MASC should solve this problem, rather than pushing it to AAP. The info is signed from MASC to AAP, and the same info is returned, so it should not get messed up unless one lies to oneself. Not strongly in favor of one solution or other, but we should figure out one way to do it. Having two different implementations may still work, but there is the possibility of confusion about the architecture. Thaler: Issue if aap servers also reboot at same time? May need more discussion on the list. V. Static Allocation in the 226/8 Address Range At MADDOGS meeting in Dallas at end of February, address allocation was discussed among several other topics. Dave has begun to question the assumption that there is not a lot of IPv4 multicast space. When broadcast.com said they needed a lot of addresses, they meant 1000. Yet the space is 256 million. So, there was a proposal from Peter Lothberg to get an experimental allocation of 226/8, using AS number as middle 16 bits and thereby allocating a /24 to each AS. Subsequently, Dave decided the space could be used more efficiently since not al AS's will need the same allocation of space. Lothberg figured this didn't matter because this is a test of the MADCAP and AAP mechanisms, not a real test of allocation. Meyer proposes using a similar philosophy to 225/8, where that is for an experiment with dynamic allocation and 226/8 is an experiment with static allocation. Is there really a near-to-immediate term shortage? Stipulate all the advantages of dynamic assignment; this is not questioned, but it is basicaly optimal packing/aggregation. Handley: Problem of static allocation is fragmentation over time. Suggests using a /8 adjacent to the 232/8 (which was allocated to VMTP and is now used for Express) so that 225/8 can be allowed to grow upward if it is successful, and 239/8 can grow downward if needed. Note this uses all of the mechanism of allocation except MASC (that is, AAP and MADCAP). The proposal is to reserve bit 8 to avoid consuming all of this allocation at once. Let the registries work out allocation of the remaining space; the issues are the same as they have done for unicast addresses. Perhaps because of route scaling problems there won't be a very large number of small groups (use multiple unicasts instead), so maybe we don't need as many addresses as thought. Conclusions: - Want to know if registry is useful as allocation mechanism - Want to enable the entities that need addresses right away - Works with AAP and MADCAP - 226/8 is and experiment along the lines of RFC1797 and RFC2374 - Proposes to ask IANA for allocation - What to do with the document? (Work item of MALLOC or MBONED?) Casner: Need to have a lifetime on those registrations, otherwise it will be too hard to get them back. Handley: Agrees. The allocations should be explicitly timed using the mechanisms of AAP and MADCAP. Thaler: This is important so that we can get all the lower protocols exercised. Munil Shah's implementation of the MADCAP server will require a lifetime to be entered on ranges that are manually configured into the server. Also, on AS numbers versus the registry plan: the motivation for AS idea is no politics. Proposes that the part of space with bit 8 clear should follow Lothberg's original AS plan. This makes it very easy for debugging to see the AS number in the middle. Note that debugging of multicast is hard, so this has some value. Meyer: Yes, this would get it off the ground right away, but provide a backup mechanism through registry to get more if the AS allocation was not sufficient. Handley: The AS mechanism is good because it doesn't start down the slippery slope of manual allocation. Williamson: Why not ask IANA for two /8's? Meyer: No, we don't need that much space. Thaler: Don't want to have to ask IANA for two. We already got 225/8, and we don't want to seem like we don't know what we're doing. Meyer: Doesn't like sharing between AS and registry allocation because of the posibility that AS's may be allocated in the high half. Thaler: Want WG consensus on whether this should be a MALLOC document. Otherwise it might go to mboned, which might seem like competition and conflict between working groups. Meyer: MALLOC is where the allocation experience is. Kermode: Agrees it should be here; needs to be carefully labeled as an experiment. Consensus was that this should become a MALLOC WG doc. Meyer: Will repost with AS idea becoming more a part of it, but with some flexibility. Handley: Experimental status is for protocols; maybe this should be BCP? Several people disagreed. BCP indicates it is a best practice, which this is not. Consensus was for experimental status. VI. MALLOC MIB Report on comments since the January draft. The goal is to be able to configure the multicast address allocation servers, and monitor health and utilization of clients and servers. Two functions: Configuration -- Need to be able to manually configure scopes until routers begin using MZAP: - list of scopes (ranges, lifetimes) - names of scopes Monitoring -- What questions do we want to be able to ask? - how full is a scope - who's using it - who has particular addresses - are requests being met These goals drive the design of the MIB. Open question for the working group is whether there should be one MIB or multiple MIBs: A MAAS server has both MADCAP and AAP interacting with the database; should the MIB deal with configuration functions, MADCAP, and AAP separately? There are some protocol-specific queries one might make, e.g., how many requests of a specific type. Does anyone have opinions on this philosophical question of MIB design? Current design doesn't do protocol specific functions and concentrates on the database and configuration, all one MIB. Review of the MIB design: - A few scalars for configuration - Scope table which tracks address blocks and their states; need to add flags from MZAP messages, and stats on protocol specific messages to know how the MADCAP and AAP protocols are behaving. - Scope name table: scope, language, name Needs change to make "default" boolean be flags to allow expansion for other flags. - Request table: scope, lease id, start/stop times, # addresses, state, who requested. Allows easily answering "who's using up the space?" - Address block table: lease id, first address and number of addresses Allows easily answering "who allocated address x.x.x.x?" Maps back into the request table via lease id. Questions - Are we able to configure everything we need to? Note that implementation specific configuration doesn't belong in MIB. - Are there other diagnostic questions we will want to ask? Kermode: Want to be able to query to find out the scope nesting, i.e., what relationships between scopes. This was noted. Also feels one MIB is right. VII. Charter/Milestones Update We are approaching the end of the existing milestone timeline in April, so we need to update it: Architectural framework update to be moved to Apr 99. The next few milestones are done. Since MIB was later than its original date of Oct 98, its Apr 99 milestone moves to Aug 99. Abstract API changes from Jan to August for going to IESG. ISP's are less sure about top levels of the MALLOC architecture than lower layers, so maybe the architecture doc should talk about top level being experimental. Want architecture doc to go to IESG by August also. AAP also August. Change inter-domain protocol (MASC) to experimental, and take Meyer's proposal to experimental also, in parallel. General agreement with this course of action. MASC MIB: if experimental, may not need to be a WG work item. So, presented list of revised milestones. Several docs to be updated in April. At Oslo, nail down intra- and inter-domain protocols (latter as experimental). August submit all the rest of the documents. Hanna: any of these that are ready sooner will go sooner. No objections, will be sent to ADs.