From owner-malloc@catarina.usc.edu Mon Sep 17 05:06:01 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06701 for ; Mon, 17 Sep 2001 05:06:00 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id BAA04342 for malloc-list; Mon, 17 Sep 2001 01:44:05 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id BAA04337 for ; Mon, 17 Sep 2001 01:44:00 -0700 (PDT) Received: from bebop.France.Sun.COM ([129.157.208.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23788 for ; Mon, 17 Sep 2001 02:43:51 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8H8hsr28534; Mon, 17 Sep 2001 10:43:55 +0200 (MET DST) Date: Mon, 17 Sep 2001 10:39:45 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: uni-based-mcast and malloc-ipv6-guide To: ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk I have some comments and questions on the related drafts. > draft-ietf-ipngwg-uni-based-mcast-02.txt It would be quite useful to outline a bit more of the problem that needs solving in the introduction. It would also be useful to have a comparision with IPv4 (either in the introduction or later in the document). Questions I'd like to see answered is whether there are approaches and protocols used for IPv4 multicast address allocation that is effectively replaced by the techniques in the draft i.e. whether the WGs believe that some mechanisms and protocols that do not need to be carried forward to IPv6. The first part of section 3 should presumably refer to and use the picture from draft-ietf-ipnwg-addr-arch-v3 instead of RFC 2373. The description of the fields in section 3 should at a minimum describe the group ID field by having a reference to draft-ietf-malloc-ipv6-guide-03.txt I wonder if it also makes sense to carry some information from that document into this one; e.g. the fact that the high-order bit of the group ID must be zero for these types of addresses. Will the unicast prefix based addresses ever need to use the link-local prefix? If not it might make sense to explicitly ban that where it talks about scope in section 3. The last paragraph in section 3 is about lifetimes. I don't understand what the intended effect is of the statement since I don't know what the lifetime is of a multicast address. Is the intent that e.g. if the prefixes are advertised with a 1 day valid lifetime, that an implementation MUST NOT use multicast addresses derived from those prefixes in SDP advertisements that end beyond 1 day ahead? If the intent is to really be that strict the document definitely needs to be a lot more specific on this point. But I don't see a need to be that strict - all these multicast addresses are temporary - is there any real danger is for some applications "temporary" spans unicast prefix renumbering events? > draft-ietf-malloc-ipv6-guide-03.txt The name of the reference [NEW ARCH] confused me - I was sure it was addr-arch-v3. How about "UNICAST PREFIX" or [3] instead? Section 3 - bullet on SSM. This says that there is a 96 bit multicast prefix but the other drafts says it must be zero. Why not explicitly say zero here as well? Otherwise folks can be lead to believe they can create non-zero middle bits for SSM addresses. (If this change is done the second bullet would need to be rewritten since it refers to SSM.) Section 5 on randomness says: The group ID portion of the address is set using either a pseudo- random 32-bit number or a 32-bit number created using the guidelines in [RFC 1750]. Possible approaches to creating a pseudo-random number include using an MD5 message-digest [RFC 1321] or portions of an NTP [RFC 1305] timestamp. I think the second sentence should be dropped since it could easily be read as taking the MD5 digest of a constrant string, or the current year+month (high-order bits of timestamp), are good enough as random numbers. Thus the paragraph on high-order but set to '1' imply that the high-order bit should always be the same as the T flag in the address? If so it would make sense to explicitly state that. If not I'd like to understand the relationship between the two better. IANA considerations section seem to be incorrect on the last range. The intent as I understand it is not allow private use but that the range is reserved for use that conforms to this specification (i.e. random group IDs). Also, the IANA considerations seem to be missing the request that IANA establish a new registry for permanent group IDs (range 0x40000000-0x7fffffff) which is different than the existing registry for IPv6 multicast addresses. Erik From owner-malloc@catarina.usc.edu Mon Sep 17 13:06:56 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16368 for ; Mon, 17 Sep 2001 13:06:54 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA05940 for malloc-list; Mon, 17 Sep 2001 09:41:21 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA05935 for ; Mon, 17 Sep 2001 09:41:20 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8HGfKT10103 for malloc@catarina.usc.edu; Mon, 17 Sep 2001 09:41:20 -0700 (PDT) (envelope-from pavlin) Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id JAA05830 for ; Mon, 17 Sep 2001 09:19:21 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 09:18:44 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 09:18:44 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 09:18:40 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 09:17:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Mon, 17 Sep 2001 09:17:10 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102DB7D61@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcE/Vj6AdMGnYsMHTPuci1roawbvtwAPIQpQ From: "Dave Thaler" To: "Erik Nordmark" , , X-OriginalArrivalTime: 17 Sep 2001 16:17:54.0579 (UTC) FILETIME=[4E613E30:01C13F94] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id JAA05834 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Erik, I'll let Brian respond to the editorial comments, but to quickly answer a few of your questions: > Will the unicast prefix based addresses ever need to use the link-local > prefix? Need? No, since it could only ever be used for link-local multicast groups, and for that scope they don't buy you anything. > If not it might make sense to explicitly ban that where it talks about > scope > in section 3. Doesn't matter to me. Technically it doesn't hurt anything to allow them. Whether it would be operationally clearer to allow or disallow them, I don't know. > The last paragraph in section 3 is about lifetimes. > I don't understand what the intended effect is of the statement > since I don't know what the lifetime is of a multicast address. See RFC 2908. > Is the intent that e.g. if the prefixes are advertised with a 1 day valid > lifetime, that an implementation MUST NOT use multicast addresses derived > from those prefixes in SDP advertisements that end beyond 1 day ahead? Yes. > If the intent is to really be that strict the document definitely needs > to be a lot more specific on this point. But I don't see a need to be > that strict - all these multicast addresses are temporary - is there > any real danger is for some applications "temporary" spans unicast > prefix renumbering events? Yes. The operational danger is confusion and failure to diagnose problems in a timely fashion. (Same as would happen today in IPv4 if people started using others' AS numbers in their multicast groups.) The performance danger is possible collisions (specifically when the group ID is IANA assigned or algorithmically generated) between the old prefix owner and the new prefix owner. -Dave From owner-malloc@catarina.usc.edu Mon Sep 17 14:47:47 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18132 for ; Mon, 17 Sep 2001 14:47:44 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA00424 for malloc-list; Mon, 17 Sep 2001 11:21:26 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from extmail01m.raleigh.ibm.com (extmail01.raleigh.ibm.com [204.146.167.242]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA00419 for ; Mon, 17 Sep 2001 11:21:24 -0700 (PDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [192.168.1.108]) by extmail01m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id OAA30238; Mon, 17 Sep 2001 14:20:50 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id OAA30750; Mon, 17 Sep 2001 14:20:49 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id OAA03736; Mon, 17 Sep 2001 14:17:21 -0400 Message-Id: <200109171817.OAA03736@rotala.raleigh.ibm.com> To: "Dave Thaler" cc: "Erik Nordmark" , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide In-Reply-To: Message of "Mon, 17 Sep 2001 09:17:10 PDT." <2E33960095B58E40A4D3345AB9F65EC102DB7D61@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Date: Mon, 17 Sep 2001 14:17:21 -0400 From: Thomas Narten Sender: owner-malloc@catarina.usc.edu Precedence: bulk > > The last paragraph in section 3 is about lifetimes. > > I don't understand what the intended effect is of the statement > > since I don't know what the lifetime is of a multicast address. > See RFC 2908. 2908 seems to say mcast addresses have a start and end lifetime. That makes sense. What I think is potentially significantly different with the approach described in *this* document is that the lifetimes are much shorter. I.e., it is conceivable that unicast addresses will be advertised with prefixes of several days or a week in common cases. That doesn't mean the addresses will expire then, just that short unicast lifetimes are being advertised, just in case, it becomes necessary to deprecate the address relatively quickly. However, if multicast addresses derive their lifetimes from the same lifetime, there may be a mismatch in expectations. Seems to me that it might very well cause problems for multicast applications that request an address with a start and end time that don't match the advertised lifetimes of unicast addresses. I wonder if this point should to be discussed in the document explicitely. I.e., seems like this is a potential difference between IPv4 multicast and IPv6 multicast. We should be making such differences very clear to minimize confusion, if nothing else. Will the tying of mcast adddresses to unicast lifetimes put additional pressure on using longer unicast lifetimes? Is this a good thing? What are typical start and end times that folks use in IPv4 today? Do they match expectations for unicast lifetimes in IPv6? Thomas From owner-malloc@catarina.usc.edu Mon Sep 17 14:48:35 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18154 for ; Mon, 17 Sep 2001 14:48:33 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA00452 for malloc-list; Mon, 17 Sep 2001 11:27:29 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA00447 for ; Mon, 17 Sep 2001 11:27:28 -0700 (PDT) Received: from bebop.France.Sun.COM ([129.157.208.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA00751; Mon, 17 Sep 2001 11:27:25 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8HIRIr28590; Mon, 17 Sep 2001 20:27:18 +0200 (MET DST) Date: Mon, 17 Sep 2001 20:23:07 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: uni-based-mcast and malloc-ipv6-guide To: Dave Thaler Cc: Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" <2E33960095B58E40A4D3345AB9F65EC102DB7D61@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk > See RFC 2908. At least that reference is missing from the document. But I see a mismatch between the draft and RFC 2908 since the latter seems to say that an application can request multicast addresses with a particular lifetime. With the uni-based addresses there can be no way for the application to request a lifetime. How can this be resolved? > > Is the intent that e.g. if the prefixes are advertised with a 1 day > valid > > lifetime, that an implementation MUST NOT use multicast addresses > derived > > from those prefixes in SDP advertisements that end beyond 1 day ahead? > > Yes. If that is indeed the WG consensus then this should be made very clear in the draft. Erik From owner-malloc@catarina.usc.edu Mon Sep 17 15:46:33 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20083 for ; Mon, 17 Sep 2001 15:46:31 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA00944 for malloc-list; Mon, 17 Sep 2001 12:27:54 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA00939 for ; Mon, 17 Sep 2001 12:27:53 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8HJRrf19299 for malloc@catarina.usc.edu; Mon, 17 Sep 2001 12:27:53 -0700 (PDT) (envelope-from pavlin) Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id MAA00918 for ; Mon, 17 Sep 2001 12:27:00 -0700 (PDT) Received: from 157.54.9.104 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 12:26:28 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 12:26:28 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 12:26:25 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 12:25:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Mon, 17 Sep 2001 12:25:13 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E73A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcE/plb2CbptxLTwSW22z9tK1HZw1wAB8OBA From: "Dave Thaler" To: "Erik Nordmark" Cc: , X-OriginalArrivalTime: 17 Sep 2001 19:25:43.0701 (UTC) FILETIME=[8B4CCC50:01C13FAE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id MAA00919 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Monday, September 17, 2001 11:23 AM > > > See RFC 2908. > > At least that reference is missing from the document. > But I see a mismatch between the draft and RFC 2908 since the latter > seems to say that an application can request multicast addresses with > a particular lifetime. With the uni-based addresses there can be no > way for the application to request a lifetime. > How can this be resolved? What makes you think there isn't a way for the app to request a lifetime? RFC 2771 applies to all dynamic multicast addresses. -Dave From owner-malloc@catarina.usc.edu Mon Sep 17 16:00:17 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20470 for ; Mon, 17 Sep 2001 16:00:15 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA00980 for malloc-list; Mon, 17 Sep 2001 12:38:19 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA00975 for ; Mon, 17 Sep 2001 12:38:18 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8HJcH122966 for malloc@catarina.usc.edu; Mon, 17 Sep 2001 12:38:17 -0700 (PDT) (envelope-from pavlin) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id MAA00966 for ; Mon, 17 Sep 2001 12:37:52 -0700 (PDT) Received: from 157.54.9.100 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 12:35:44 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 12:35:44 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 12:35:44 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 12:34:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Mon, 17 Sep 2001 12:34:06 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E73B@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcE/pWy6KN2XSVbBTj+hQ+meoKxiQAACSh0Q From: "Dave Thaler" To: "Thomas Narten" , "Erik Nordmark" Cc: , X-OriginalArrivalTime: 17 Sep 2001 19:34:59.0166 (UTC) FILETIME=[D66207E0:01C13FAF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id MAA00967 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Thomas Narten [mailto:narten@raleigh.ibm.com] > Sent: Monday, September 17, 2001 11:17 AM > > > > The last paragraph in section 3 is about lifetimes. > > > I don't understand what the intended effect is of the statement > > > since I don't know what the lifetime is of a multicast address. > > > See RFC 2908. > > 2908 seems to say mcast addresses have a start and end lifetime. That > makes sense. What I think is potentially significantly different with > the approach described in *this* document is that the lifetimes are > much shorter. I.e., it is conceivable that unicast addresses will be > advertised with prefixes of several days or a week in common > cases. That doesn't mean the addresses will expire then, just that > short unicast lifetimes are being advertised, just in case, it becomes > necessary to deprecate the address relatively quickly. However, if > multicast addresses derive their lifetimes from the same lifetime, > there may be a mismatch in expectations. How so? One can renew multicast addresses. (Conceivably an implementation could support the ability to automatically renew multicast addresses as long as the unicast address stays valid.) If the multicast address is being advertised with say SAP, each SAP advertisements can contain the extended lifetime, just like RAs do for unicast prefixes. > Seems to me that it might very well cause problems for multicast > applications that request an address with a start and end time that > don't match the advertised lifetimes of unicast addresses. If so, the same problems exist with any SSM channel that an app uses. > I wonder if this point should to be discussed in the document > explicitely. I.e., seems like this is a potential difference between > IPv4 multicast and IPv6 multicast. We should be making such > differences very clear to minimize confusion, if nothing else. I don't think there's any difference between IPv4 and IPv6 multicast, can you elaborate? (By the way, you should see a uni-based-mcast draft for IPv4 sometime before next IETF.) > Will the tying of mcast adddresses to unicast lifetimes put additional > pressure on using longer unicast lifetimes? Is this a good thing? I don't know. > What are typical start and end times that folks use in IPv4 today? Anywhere from 1-hour duration, to maybe 6 months or so. > Do they match expectations for unicast lifetimes in IPv6? One option might be to make it a SHOULD NOT (for advertised multicast lifetime to exceed known unicast lifetime) with the note that after the unicast lifetime, there is no guarantee that packets will reach their destination. -Dave From owner-malloc@catarina.usc.edu Mon Sep 17 16:47:14 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21478 for ; Mon, 17 Sep 2001 16:47:11 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA01111 for malloc-list; Mon, 17 Sep 2001 13:15:54 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA01106 for ; Mon, 17 Sep 2001 13:15:53 -0700 (PDT) Received: from bebop.France.Sun.COM ([129.157.208.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA25163; Mon, 17 Sep 2001 13:15:51 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8HKFbr03608; Mon, 17 Sep 2001 22:15:41 +0200 (MET DST) Date: Mon, 17 Sep 2001 22:11:25 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: uni-based-mcast and malloc-ipv6-guide To: Dave Thaler Cc: Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" <2E33960095B58E40A4D3345AB9F65EC10290E73A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk > > -----Original Message----- > > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > > Sent: Monday, September 17, 2001 11:23 AM > > > > > See RFC 2908. > > > > At least that reference is missing from the document. > > But I see a mismatch between the draft and RFC 2908 since the latter > > seems to say that an application can request multicast addresses with > > a particular lifetime. With the uni-based addresses there can be no > > way for the application to request a lifetime. > > How can this be resolved? > > What makes you think there isn't a way for the app to request a > lifetime? > RFC 2771 applies to all dynamic multicast addresses. Huh? How does the application requesting a particular lifetime effect the lifetime that the routers use when advertising the unicast prefix? Are you envisioning some new protocol to inform the routers (and the system admin, ISP, RIR) that allocated the unicast prefix that it needs to stay around for long enough to satisfy the applications request? :-) So while there might be an abstract API that allows the application to ask, the scheme in uni-based-mcast doesn't seem to have the pieces so that the system can honor such a request; at least not with a strict interpretation of the relationship between the RFC 2462 notion of lifetime of the unicast prefix, and the presumed lifetime of the derived multicast' address. Hence my question whether the intent is to have such a strict relationship or not. Erik From owner-malloc@catarina.usc.edu Mon Sep 17 17:05:50 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21832 for ; Mon, 17 Sep 2001 17:05:49 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA01157 for malloc-list; Mon, 17 Sep 2001 13:34:20 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA01152 for ; Mon, 17 Sep 2001 13:34:19 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8HKYJN23191 for malloc@catarina.usc.edu; Mon, 17 Sep 2001 13:34:19 -0700 (PDT) (envelope-from pavlin) Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id NAA01133 for ; Mon, 17 Sep 2001 13:28:19 -0700 (PDT) Received: from 157.54.1.52 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 13:27:48 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 13:27:48 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 13:27:48 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 13:27:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Mon, 17 Sep 2001 13:26:26 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E73C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcE/tYLxrZH0ZEwFREK1ekPev20lOwAACppw From: "Dave Thaler" To: "Erik Nordmark" Cc: , X-OriginalArrivalTime: 17 Sep 2001 20:27:02.0677 (UTC) FILETIME=[1C23FC50:01C13FB7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id NAA01134 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Monday, September 17, 2001 1:11 PM > To: Dave Thaler > Cc: Erik Nordmark; ipng@sunroof.eng.sun.com; malloc@catarina.usc.edu > Subject: RE: uni-based-mcast and malloc-ipv6-guide > > > > -----Original Message----- > > > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > > > Sent: Monday, September 17, 2001 11:23 AM > > > > > > > See RFC 2908. > > > > > > At least that reference is missing from the document. > > > But I see a mismatch between the draft and RFC 2908 since the latter > > > seems to say that an application can request multicast addresses with > > > a particular lifetime. With the uni-based addresses there can be no > > > way for the application to request a lifetime. > > > How can this be resolved? > > > > What makes you think there isn't a way for the app to request a > > lifetime? > > RFC 2771 applies to all dynamic multicast addresses. > > Huh? > > How does the application requesting a particular lifetime effect the > lifetime that the routers use when advertising the unicast prefix? It doesn't. In the abstract API, the application supplies a minimum and desired lifetime. If the app says [0, 6 months] and the host knows that the unicast prefix is valid for 1 week, it can tell the app it has it for one week (and the app can renew it at any time). > Are you envisioning some new protocol to inform the routers (and the > system > admin, ISP, RIR) that allocated the unicast prefix that it needs to > stay around for long enough to satisfy the applications request? :-) Gosh I hope not :) > So while there might be an abstract API that allows the application > to ask, the scheme in uni-based-mcast doesn't seem to have the pieces > so that the system can honor such a request; at least not with a strict > interpretation of the relationship between the RFC 2462 notion of lifetime > of the unicast prefix, and the presumed lifetime of the derived multicast' > address. If the app says [6 months, 6 months] then personally I would expect the host to fail the request if it only has a unicast prefix lifetime of 1 week. I think your question is really: should we allow such a host to grant a request for 6 months if it only has a unicast prefix lifetime of 1 week? In my previous email, if there is a need to allow this (and I'm not saying there is), then we'd have to just say it SHOULD NOT, and say that after the unicast lifetime, the multicast packets are not guaranteed to be routed. > Hence my question whether the intent is to have such a strict relationship > or not. I'd like to hear others opinions, but I think that is the authors' intent. -Dave From owner-malloc@catarina.usc.edu Mon Sep 17 17:27:35 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22070 for ; Mon, 17 Sep 2001 17:27:32 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA01237 for malloc-list; Mon, 17 Sep 2001 13:55:51 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from extmail01m.raleigh.ibm.com (extmail01.raleigh.ibm.com [204.146.167.242]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA01232 for ; Mon, 17 Sep 2001 13:55:48 -0700 (PDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [192.168.1.109]) by extmail01m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id QAB30536; Mon, 17 Sep 2001 16:55:15 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id QAA29218; Mon, 17 Sep 2001 16:55:14 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA04604; Mon, 17 Sep 2001 16:51:44 -0400 Message-Id: <200109172051.QAA04604@rotala.raleigh.ibm.com> To: "Dave Thaler" cc: "Erik Nordmark" , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide In-Reply-To: Message of "Mon, 17 Sep 2001 12:34:06 PDT." <2E33960095B58E40A4D3345AB9F65EC10290E73B@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Date: Mon, 17 Sep 2001 16:51:44 -0400 From: Thomas Narten Sender: owner-malloc@catarina.usc.edu Precedence: bulk > How so? One can renew multicast addresses. (Conceivably an > implementation could support the ability to automatically renew > multicast addresses as long as the unicast address stays valid.) Suppose I want to get a multicast address so I can advertise a session (e.g., on a web page). I do this two weeks in advance of the event. I want the address to last one day only. The key point is that I will want to use the address staring two weeks from now. However, because unicast lifetimes are only a week, that's too far into the future to actually get the address (yet), so the address can't be obtained yet. This would seem like it might be a problem. Is it? (I don't know how this scenario fits with the way multicast is actually used in IPv4, so this really is a question.) Thomas From owner-malloc@catarina.usc.edu Mon Sep 17 18:27:35 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23038 for ; Mon, 17 Sep 2001 18:27:34 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA01469 for malloc-list; Mon, 17 Sep 2001 15:08:42 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA01464 for ; Mon, 17 Sep 2001 15:08:40 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8HM8eL23717 for malloc@catarina.usc.edu; Mon, 17 Sep 2001 15:08:40 -0700 (PDT) (envelope-from pavlin) Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id OAA01390 for ; Mon, 17 Sep 2001 14:41:11 -0700 (PDT) Received: from 157.54.1.52 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 14:39:00 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 14:39:00 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 14:39:00 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 14:38:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Mon, 17 Sep 2001 14:38:15 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E73D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcE/uvvke8mpwGIFSsCzYpJ7oEVqjAABI6cA From: "Dave Thaler" To: "Thomas Narten" Cc: "Erik Nordmark" , , X-OriginalArrivalTime: 17 Sep 2001 21:38:15.0915 (UTC) FILETIME=[0F305BB0:01C13FC1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id OAA01392 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Thomas Narten [mailto:narten@raleigh.ibm.com] > Sent: Monday, September 17, 2001 1:52 PM > > > How so? One can renew multicast addresses. (Conceivably an > > implementation could support the ability to automatically renew > > multicast addresses as long as the unicast address stays valid.) > > Suppose I want to get a multicast address so I can advertise a session > (e.g., on a web page). I do this two weeks in advance of the event. I > want the address to last one day only. The key point is that I will > want to use the address staring two weeks from now. > > However, because unicast lifetimes are only a week, that's too far > into the future to actually get the address (yet), so the address > can't be obtained yet. This would seem like it might be a problem. Is > it? (I don't know how this scenario fits with the way multicast is > actually used in IPv4, so this really is a question.) This is a good question, and in fact it's not multicast specific. Here's the unicast equivalent: You're advertising a unicast streaming session on a web page that will start in two weeks (and last one day). You use a URL with a literal unicast address in it. However, you don't know from your RA that your address will definitely be the same by then. Again, this would seem like it might be a problem. I think the same dangers and possible solutions exist for both unicast and multicast. Some solutions, with varying degrees of "goodness", might include: 1) Change the web page if the address changes, and hope people don't use an out-of-date web page. 2) Don't use address literals in the URL, and hope that people don't resolve the name to an address until close to the session starts. 3) Make the admin have knowledge somehow that the address will indeed be valid throughout the life of the session advertised. The point is that pretty much any solution you use for unicast can be used for multicast as well. -Dave From owner-malloc@catarina.usc.edu Mon Sep 17 18:41:53 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23260 for ; Mon, 17 Sep 2001 18:41:51 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA01518 for malloc-list; Mon, 17 Sep 2001 15:21:20 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA01513 for ; Mon, 17 Sep 2001 15:21:15 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8HMLFm23813 for malloc@catarina.usc.edu; Mon, 17 Sep 2001 15:21:15 -0700 (PDT) (envelope-from pavlin) Received: from southstation.m5p.com (dsl-209-162-215-52.easystreet.com [209.162.215.52]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA01504 for ; Mon, 17 Sep 2001 15:20:49 -0700 (PDT) Received: (from george@localhost) by southstation.m5p.com (8.11.4/8.11.4) id f8HMKgX47450; Mon, 17 Sep 2001 15:20:42 -0700 (PDT) Date: Mon, 17 Sep 2001 15:20:42 -0700 (PDT) From: George Mitchell Message-Id: <200109172220.f8HMKgX47450@southstation.m5p.com> To: dthaler@windows.microsoft.com, narten@raleigh.ibm.com Subject: RE: uni-based-mcast and malloc-ipv6-guide Cc: Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC10290E73D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Sender: owner-malloc@catarina.usc.edu Precedence: bulk > > Suppose I want to get a multicast address so I can advertise a session > > (e.g., on a web page). I do this two weeks in advance of the event. I > > want the address to last one day only. The key point is that I will > > want to use the address staring two weeks from now. > > > > However, because unicast lifetimes are only a week, that's too far > > into the future to actually get the address (yet), so the address > > can't be obtained yet. This would seem like it might be a problem. Is > > it? (I don't know how this scenario fits with the way multicast is > > actually used in IPv4, so this really is a question.) > > This is a good question, and in fact it's not multicast specific. > Here's the unicast equivalent: Unless I'm missing something really obvious, shouldn't you both simply be advertising a domain name? Put the address into DNS when the time comes and everybody will be happy. -- George Mitchell From owner-malloc@catarina.usc.edu Mon Sep 17 19:07:25 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23608 for ; Mon, 17 Sep 2001 19:07:24 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA01575 for malloc-list; Mon, 17 Sep 2001 15:39:39 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA01570 for ; Mon, 17 Sep 2001 15:39:38 -0700 (PDT) Received: from [63.105.122.193] (account marshall_eubanks HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1081665; Mon, 17 Sep 2001 18:32:34 -0400 Message-ID: <3BA67BAD.8EC01AC8@21rst-century.com> Date: Mon, 17 Sep 2001 18:39:41 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Thomas Narten CC: Dave Thaler , Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: <200109172051.QAA04604@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thomas Narten wrote: > > How so? One can renew multicast addresses. (Conceivably an > > implementation could support the ability to automatically renew > > multicast addresses as long as the unicast address stays valid.) > > Suppose I want to get a multicast address so I can advertise a session > (e.g., on a web page). I do this two weeks in advance of the event. I > want the address to last one day only. The key point is that I will > want to use the address staring two weeks from now. > > However, because unicast lifetimes are only a week, that's too far > into the future to actually get the address (yet), so the address > can't be obtained yet. This would seem like it might be a problem. Is > it? (I don't know how this scenario fits with the way multicast is > actually used in IPv4, so this really is a question.) > > Thomas In IPv4 I would say, use a GLOP address for this. (We'll rent you one if you don't have any.) Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ Check the status of multicast in real time : http://www.multicasttech.com/status/index.html From owner-malloc@catarina.usc.edu Mon Sep 17 19:24:26 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24820 for ; Mon, 17 Sep 2001 19:24:26 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA01647 for malloc-list; Mon, 17 Sep 2001 15:58:20 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA01642 for ; Mon, 17 Sep 2001 15:58:20 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8HMwJf24095 for malloc@catarina.usc.edu; Mon, 17 Sep 2001 15:58:19 -0700 (PDT) (envelope-from pavlin) Received: from inet-imc-01.redmond.corp.microsoft.com (mail1.microsoft.com [131.107.3.125]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA01633 for ; Mon, 17 Sep 2001 15:57:42 -0700 (PDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 15:57:20 -0700 Received: from 157.54.1.52 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 15:57:20 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 15:57:20 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 15:57:17 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 15:56:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Mon, 17 Sep 2001 15:56:27 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E740@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcE/yZFX9xY/cakGScKkaHQIalQyPQAAcyOQ From: "Dave Thaler" To: , "Thomas Narten" Cc: "Erik Nordmark" , , X-OriginalArrivalTime: 17 Sep 2001 22:56:32.0586 (UTC) FILETIME=[FE9F7AA0:01C13FCB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id PAA01634 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Marshall Eubanks [mailto:tme@21rst-century.com] > Sent: Monday, September 17, 2001 3:40 PM > To: Thomas Narten > Cc: Dave Thaler; Erik Nordmark; ipng@sunroof.eng.sun.com; > malloc@catarina.usc.edu > Subject: Re: uni-based-mcast and malloc-ipv6-guide > > Thomas Narten wrote: > > > > How so? One can renew multicast addresses. (Conceivably an > > > implementation could support the ability to automatically renew > > > multicast addresses as long as the unicast address stays valid.) > > > > Suppose I want to get a multicast address so I can advertise a session > > (e.g., on a web page). I do this two weeks in advance of the event. I > > want the address to last one day only. The key point is that I will > > want to use the address staring two weeks from now. > > > > However, because unicast lifetimes are only a week, that's too far > > into the future to actually get the address (yet), so the address > > can't be obtained yet. This would seem like it might be a problem. Is > > it? (I don't know how this scenario fits with the way multicast is > > actually used in IPv4, so this really is a question.) > > > > Thomas > > In IPv4 I would say, use a GLOP address for this. (We'll rent you one if > you don't have any.) GLOP has exactly the same issue for end sites that don't own their own AS #. When you renumber, chances are it's because you changed your provider, in which case you can no longer use your old provider's GLOP space. Uni-based mcast addresses don't require end sites to have their own AS # (or any other non-aggregatable number). -Dave From owner-malloc@catarina.usc.edu Mon Sep 17 19:31:41 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25061 for ; Mon, 17 Sep 2001 19:31:40 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA01715 for malloc-list; Mon, 17 Sep 2001 16:11:07 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA01710 for ; Mon, 17 Sep 2001 16:11:06 -0700 (PDT) Received: from [63.105.122.193] (account marshall_eubanks HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1081685; Mon, 17 Sep 2001 19:04:02 -0400 Message-ID: <3BA6830F.CDB5CABE@21rst-century.com> Date: Mon, 17 Sep 2001 19:11:11 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Dave Thaler CC: Thomas Narten , Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: <2E33960095B58E40A4D3345AB9F65EC10290E740@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dave Thaler wrote: > > -----Original Message----- > > From: Marshall Eubanks [mailto:tme@21rst-century.com] > > Sent: Monday, September 17, 2001 3:40 PM > > To: Thomas Narten > > Cc: Dave Thaler; Erik Nordmark; ipng@sunroof.eng.sun.com; > > malloc@catarina.usc.edu > > Subject: Re: uni-based-mcast and malloc-ipv6-guide > > > > Thomas Narten wrote: > > > > > > How so? One can renew multicast addresses. (Conceivably an > > > > implementation could support the ability to automatically renew > > > > multicast addresses as long as the unicast address stays valid.) > > > > > > Suppose I want to get a multicast address so I can advertise a > session > > > (e.g., on a web page). I do this two weeks in advance of the event. > I > > > want the address to last one day only. The key point is that I will > > > want to use the address staring two weeks from now. > > > > > > However, because unicast lifetimes are only a week, that's too far > > > into the future to actually get the address (yet), so the address > > > can't be obtained yet. This would seem like it might be a problem. > Is > > > it? (I don't know how this scenario fits with the way multicast is > > > actually used in IPv4, so this really is a question.) > > > > > > Thomas > > > > In IPv4 I would say, use a GLOP address for this. (We'll rent you one > if > > you don't have any.) > > GLOP has exactly the same issue for end sites that don't own > their own AS #. > > When you renumber, chances are it's because you changed your provider, > in which case you can no longer use your old provider's GLOP space. > > Uni-based mcast addresses don't require end sites to have their > own AS # (or any other non-aggregatable number). > > -Dave > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Hi Dave; Yes, but he asked "the way multicast is actually used in IPv4". That's the answer to the question he asked, maybe not to others he should have asked. -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ Check the status of multicast in real time : http://www.multicasttech.com/status/index.html From owner-malloc@catarina.usc.edu Tue Sep 18 03:59:58 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16259 for ; Tue, 18 Sep 2001 03:59:57 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id AAA02782 for malloc-list; Tue, 18 Sep 2001 00:33:44 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id AAA02777 for ; Tue, 18 Sep 2001 00:33:43 -0700 (PDT) Received: from bebop.France.Sun.COM ([129.157.208.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27470; Tue, 18 Sep 2001 01:33:34 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8I7Xdr03156; Tue, 18 Sep 2001 09:33:39 +0200 (MET DST) Date: Tue, 18 Sep 2001 09:29:29 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: uni-based-mcast and malloc-ipv6-guide To: Dave Thaler Cc: Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" <2E33960095B58E40A4D3345AB9F65EC10290E73C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk > If the app says [6 months, 6 months] then personally I would expect the > host to fail the request if it only has a unicast prefix lifetime of 1 > week. > I think your question is really: should we allow such a host to grant > a request for 6 months if it only has a unicast prefix lifetime of 1 > week? Bingo! The related question is: are there applications which would fail to function today if you applied the constraints imposed by this today i.e. the fact that no multicast addresses could be allocated by the API with an end time more than a week into the future? (For this excercise it would make sense to consider the IPv4 multicast applications as well as the IPv6 multicast applications that exist just to try to understand the scope of the applications dependency on multicast address lifetimes.) > In my previous email, if there is a need to allow this (and I'm not > saying > there is), then we'd have to just say it SHOULD NOT, and say that after > the unicast lifetime, the multicast packets are not guaranteed to be > routed. I fail to understand why routing might fail. Could you explain? I do understand that there is a different probability of allocating duplicate uni-based mcast addresses should the unicast prefix be assigned to another entity, but this doesn't lead to routing failing unless you are assuming that routing will do something it doesn't currently do. Erik From owner-malloc@catarina.usc.edu Tue Sep 18 04:10:02 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16371 for ; Tue, 18 Sep 2001 04:10:00 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id AAA02825 for malloc-list; Tue, 18 Sep 2001 00:45:13 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id AAA02820 for ; Tue, 18 Sep 2001 00:45:12 -0700 (PDT) Received: from bebop.France.Sun.COM ([129.157.208.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA17318; Tue, 18 Sep 2001 00:45:08 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8I7iZr04011; Tue, 18 Sep 2001 09:44:35 +0200 (MET DST) Date: Tue, 18 Sep 2001 09:40:25 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: uni-based-mcast and malloc-ipv6-guide To: Dave Thaler Cc: Thomas Narten , Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" <2E33960095B58E40A4D3345AB9F65EC10290E73D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk > This is a good question, and in fact it's not multicast specific. > Here's the unicast equivalent: > > You're advertising a unicast streaming session on a web page that > will start in two weeks (and last one day). You use a URL with > a literal unicast address in it. However, you don't know from > your RA that your address will definitely be the same by then. > Again, this would seem like it might be a problem. Yes, but for unicast there is a clear possibility of using a hostname instead of a literal IP address in such a case. In fact I suspect most unicast usage of this nature uses a hostname. Is such a mechanism possible to use for multicast? (i.e. advertise a FQDN on web pages, in SDP, etc and have the hosts do a DNS lookup to join the session?) Does the malloc architecture take into account using the DNS in such a way? Erik > I think the same dangers and possible solutions exist for both > unicast and multicast. Some solutions, with varying degrees of > "goodness", might include: > 1) Change the web page if the address changes, and hope people > don't use an out-of-date web page. > 2) Don't use address literals in the URL, and hope that people > don't resolve the name to an address until close to the > session starts. > 3) Make the admin have knowledge somehow that the address > will indeed be valid throughout the life of the session > advertised. > > The point is that pretty much any solution you use > for unicast can be used for multicast as well. > > -Dave From owner-malloc@catarina.usc.edu Tue Sep 18 12:36:46 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25081 for ; Tue, 18 Sep 2001 12:36:45 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id IAA04151 for malloc-list; Tue, 18 Sep 2001 08:18:58 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id IAA04146 for ; Tue, 18 Sep 2001 08:18:55 -0700 (PDT) Received: from bebop.France.Sun.COM ([129.157.208.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00874; Tue, 18 Sep 2001 09:18:44 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8IFInr21084; Tue, 18 Sep 2001 17:18:49 +0200 (MET DST) Date: Tue, 18 Sep 2001 17:14:38 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: uni-based-mcast and malloc-ipv6-guide To: Brian Haberman Cc: Erik Nordmark , Dave Thaler , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" <3BA757E4.F845D000@americasm06.nt.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk > > I fail to understand why routing might fail. Could you explain? > > I do understand that there is a different probability of allocating duplicate > > uni-based mcast addresses should the unicast prefix be assigned to another > > entity, but this doesn't lead to routing failing unless you are assuming > > that routing will do something it doesn't currently do. > > I think one possible example is with SSM. The first hop router > may receive an IGMPv3 join with an old prefix that has been > renumbered. It then tries to send the SPT Join to the wrong > network. That network doesn't exist and so the Join fails and > the multicast traffic never flows. Brian, I thought uni-based mcast addresses for SSM has an all zero prefix component. (That's what the uni-based draft says.) Are you referring to such a prefix or the IP source address? Clearly SSM, which explicitly identifies a group by the pair , is likely to barf when the IP source address is no longer valid for the sender. Depending on whether the document is correct or not about having a zero prefix in the SSM multicast destination, this may or may not be an issue for the actual multicast address. Erik From owner-malloc@catarina.usc.edu Tue Sep 18 13:02:48 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25993 for ; Tue, 18 Sep 2001 13:02:45 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA04339 for malloc-list; Tue, 18 Sep 2001 09:17:25 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA04334 for ; Tue, 18 Sep 2001 09:17:24 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8IGHOx16993 for malloc@catarina.usc.edu; Tue, 18 Sep 2001 09:17:24 -0700 (PDT) (envelope-from pavlin) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id HAA03943 for ; Tue, 18 Sep 2001 07:05:39 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8IE4ep28871 for ; Tue, 18 Sep 2001 10:04:40 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Tue, 18 Sep 2001 10:04:46 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SXTX1C0P; Tue, 18 Sep 2001 10:04:41 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87SB2C; Tue, 18 Sep 2001 10:04:42 -0400 Message-ID: <3BA7547C.892C094D@americasm06.nt.com> Date: Tue, 18 Sep 2001 10:04:44 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Dave Thaler , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Erik, Erik Nordmark wrote: > > > See RFC 2908. > > At least that reference is missing from the document. > But I see a mismatch between the draft and RFC 2908 since the latter > seems to say that an application can request multicast addresses with > a particular lifetime. With the uni-based addresses there can be no > way for the application to request a lifetime. > How can this be resolved? Well, the first thing is to actually reference 2908 in the doc. :) I will make sure that 2908 is part of a section describing the changes between v4 and v6 mcast allocation. Brian From owner-malloc@catarina.usc.edu Tue Sep 18 13:03:18 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26019 for ; Tue, 18 Sep 2001 13:03:17 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA04332 for malloc-list; Tue, 18 Sep 2001 09:17:15 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA04327 for ; Tue, 18 Sep 2001 09:17:13 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8IGHBT16989 for malloc@catarina.usc.edu; Tue, 18 Sep 2001 09:17:11 -0700 (PDT) (envelope-from pavlin) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id HAA03920 for ; Tue, 18 Sep 2001 07:02:01 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8IE12p28221 for ; Tue, 18 Sep 2001 10:01:02 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 18 Sep 2001 10:01:17 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TBXMB9KF; Tue, 18 Sep 2001 10:01:16 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87SB2A; Tue, 18 Sep 2001 10:01:15 -0400 Message-ID: <3BA753AD.70F2E912@americasm06.nt.com> Date: Tue, 18 Sep 2001 10:01:17 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Erik, Apologies for the delay in responding. It took me a little while to get back to the States from Stockholm. Responses are in-line... Erik Nordmark wrote: > > I have some comments and questions on the related drafts. > > > draft-ietf-ipngwg-uni-based-mcast-02.txt > > It would be quite useful to outline a bit more of > the problem that needs solving in the introduction. > It would also be useful to have a comparision with IPv4 > (either in the introduction or later in the document). > Questions I'd like to see answered is whether there are > approaches and protocols used for IPv4 multicast address allocation that is > effectively replaced by the techniques in the draft i.e. whether the > WGs believe that some mechanisms and protocols that do not need to > be carried forward to IPv6. Not a problem. There was a fair amount of discussion that never made it into the document wrt what protocols were not being pulled forward from v4. The overall goal is to avoid the need for any inter-domain allocation protocol. Our approach basically will only need, at most, MADCAP servers. > > The first part of section 3 should presumably refer to and use the picture > from draft-ietf-ipnwg-addr-arch-v3 instead of RFC 2373. OK. > > The description of the fields in section 3 should at a minimum describe > the group ID field by having a reference to draft-ietf-malloc-ipv6-guide-03.txt > I wonder if it also makes sense to carry some information from that document > into this one; e.g. the fact that the high-order bit of the group ID must be > zero for these types of addresses. Some of the information in draft-ietf-malloc-ipv6-guide-03.txt was pulled from this doc and moved. I was trying to separate the protocol aspects from the operational aspects. However, the bit-setting may be better off in this document. Any other text you think might belong in other locations/documents? > > Will the unicast prefix based addresses ever need to use the link-local prefix? > If not it might make sense to explicitly ban that where it talks about scope > in section 3. Dave answered this already, but let me add something. The following text is in section 3: The scope of the unicast-prefix based multicast address MUST NOT exceed the scope of the unicast prefix embedded in the multicast address. This text was actually put in specifically to address the use of the link-local prefix. As Dave said, using it doesn't buy you anything, but allowing it makes the work of allocation servers easier since they don't have to prohibit particular scopes on the prefixes. In addition, I could envision the use of this on large switched LANs with a MADCAP server. > > The last paragraph in section 3 is about lifetimes. > I don't understand what the intended effect is of the statement > since I don't know what the lifetime is of a multicast address. > Is the intent that e.g. if the prefixes are advertised with a 1 day valid > lifetime, that an implementation MUST NOT use multicast addresses derived > from those prefixes in SDP advertisements that end beyond 1 day ahead? > If the intent is to really be that strict the document definitely needs > to be a lot more specific on this point. But I don't see a need to be > that strict - all these multicast addresses are temporary - is there > any real danger is for some applications "temporary" spans unicast > prefix renumbering events? I will defer comment for another response since it seems that there has been alot of discussion on this point while I was gone. > > > draft-ietf-malloc-ipv6-guide-03.txt > > The name of the reference [NEW ARCH] confused me - I was sure it > was addr-arch-v3. How about "UNICAST PREFIX" or [3] instead? Ah, a legacy reference. I can change this without any problems. It was a carryover from the original -00 document where Dave and I had proposed breaking the multicast address architecture out of RFC 2373. > > Section 3 - bullet on SSM. This says that there is a 96 bit multicast > prefix but the other drafts says it must be zero. Why not explicitly say zero > here as well? Otherwise folks can be lead to believe they can create non-zero > middle bits for SSM addresses. > (If this change is done the second bullet would need to be rewritten since > it refers to SSM.) I was referring to the fact that the first 96 bits of the address are generated using the specifications in the other draft. The 32-bit group ID is then generated using the techniques in this draft. Given the restrictions in RFC 2373 and its follow-up, all multicast addresses are composed of a 96-bit prefix and a 32-bit group-ID. > > Section 5 on randomness says: > The group ID portion of the address is set using either a pseudo- > random 32-bit number or a 32-bit number created using the guidelines > in [RFC 1750]. Possible approaches to creating a pseudo-random > number include using an MD5 message-digest [RFC 1321] or portions of > an NTP [RFC 1305] timestamp. > I think the second sentence should be dropped since it could easily be > read as taking the MD5 digest of a constrant string, or > the current year+month (high-order bits of timestamp), are good enough as > random numbers. I can drop that sentence. It was added because I had several comments asking for suggestions on creating these random numbers. But, the reference to RFC 1750 should be enough. > > Thus the paragraph on high-order but set to '1' imply that the > high-order bit should always be the same as the T flag in the address? > If so it would make sense to explicitly state that. > If not I'd like to understand the relationship between the two better. Ah, good point. The high-order bit does reflect the setting of the T bit. I can add text to elaborate on that. > > IANA considerations section seem to be incorrect on the last range. > The intent as I understand it is not allow private use but that > the range is reserved for use that conforms to this specification (i.e. > random group IDs). Good catch. The last range is for dynamic allocation use. > > Also, the IANA considerations seem to be missing the request that IANA > establish a new registry for permanent group IDs (range 0x40000000-0x7fffffff) > which is different than the existing registry for IPv6 multicast addresses. I will try and bolster that section a little to spell it out in more concrete terms. Thanks, Brian From owner-malloc@catarina.usc.edu Tue Sep 18 13:03:36 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26030 for ; Tue, 18 Sep 2001 13:03:32 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA04368 for malloc-list; Tue, 18 Sep 2001 09:18:54 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA04363 for ; Tue, 18 Sep 2001 09:18:50 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8IGIk917013 for malloc@catarina.usc.edu; Tue, 18 Sep 2001 09:18:46 -0700 (PDT) (envelope-from pavlin) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id IAA04192 for ; Tue, 18 Sep 2001 08:29:36 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8IFSZp12505 for ; Tue, 18 Sep 2001 11:28:35 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 18 Sep 2001 11:28:30 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TBXMCKXR; Tue, 18 Sep 2001 11:28:30 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87SBL2; Tue, 18 Sep 2001 11:28:28 -0400 Message-ID: <3BA7681E.8F41CFEA@americasm06.nt.com> Date: Tue, 18 Sep 2001 11:28:30 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Dave Thaler , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Erik, Erik Nordmark wrote: > > > > I fail to understand why routing might fail. Could you explain? > > > I do understand that there is a different probability of allocating duplicate > > > uni-based mcast addresses should the unicast prefix be assigned to another > > > entity, but this doesn't lead to routing failing unless you are assuming > > > that routing will do something it doesn't currently do. > > > > I think one possible example is with SSM. The first hop router > > may receive an IGMPv3 join with an old prefix that has been > > renumbered. It then tries to send the SPT Join to the wrong > > network. That network doesn't exist and so the Join fails and > > the multicast traffic never flows. > > Brian, > > I thought uni-based mcast addresses for SSM has an all zero prefix component. > (That's what the uni-based draft says.) > Are you referring to such a prefix or the IP source address? Argh. I was trying to use a simple example, which doesn't make the point. You are correct about the zero prefix. > > Clearly SSM, which explicitly identifies a group by the pair address, Multicast destination>, is likely to barf when the IP source address > is no longer valid for the sender. > Depending on whether the document is correct or not about having a zero > prefix in the SSM multicast destination, this may or may not be > an issue for the actual multicast address. OK, I have had a little time to think about some of these comments. The lifetime of the mcast address allocation may still have an affect on the routing. Since mcast forwarding is based on an state, due to RPF checks, as long as G is not changed by the application sending the data, forwarding should work. Except for the fact that if G changes due to a prefix lifetime expiration, S may/will change as well. This holds true for SSM or ASM. If S is not the one who requested G from the MADCAP server, then it will be arbitrary as to whether or not S will change when G changes due to a lifetime expiration. Brian From owner-malloc@catarina.usc.edu Tue Sep 18 13:12:50 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26344 for ; Tue, 18 Sep 2001 13:12:43 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA04346 for malloc-list; Tue, 18 Sep 2001 09:17:48 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA04341 for ; Tue, 18 Sep 2001 09:17:47 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8IGHlE16997 for malloc@catarina.usc.edu; Tue, 18 Sep 2001 09:17:47 -0700 (PDT) (envelope-from pavlin) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id HAA03974 for ; Tue, 18 Sep 2001 07:11:52 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8IEAqp00078 for ; Tue, 18 Sep 2001 10:10:52 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Tue, 18 Sep 2001 10:11:07 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SXTX1C08; Tue, 18 Sep 2001 10:11:05 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87SB2H; Tue, 18 Sep 2001 10:11:06 -0400 Message-ID: <3BA755FC.EFA35E33@americasm06.nt.com> Date: Tue, 18 Sep 2001 10:11:09 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: <2E33960095B58E40A4D3345AB9F65EC10290E73C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dave, Dave Thaler wrote: > > How does the application requesting a particular lifetime effect the > > lifetime that the routers use when advertising the unicast prefix? > > It doesn't. > In the abstract API, the application supplies a minimum and desired > lifetime. If the app says [0, 6 months] and the host knows that > the unicast prefix is valid for 1 week, it can tell the app it has > it for one week (and the app can renew it at any time). That was my intent. It fits the existing v4 mcast allocation architecture. A host may request an address for ANY particular lifetime, but there are no guarantees that the requested lifetime can be honored. > > > Are you envisioning some new protocol to inform the routers (and the > > system > > admin, ISP, RIR) that allocated the unicast prefix that it needs to > > stay around for long enough to satisfy the applications request? :-) > > Gosh I hope not :) Agreed! I am trying to reduce the number of protocols. > > > So while there might be an abstract API that allows the application > > to ask, the scheme in uni-based-mcast doesn't seem to have the pieces > > so that the system can honor such a request; at least not with a > strict > > interpretation of the relationship between the RFC 2462 notion of > lifetime > > of the unicast prefix, and the presumed lifetime of the derived > multicast' > > address. > > If the app says [6 months, 6 months] then personally I would expect the > host to fail the request if it only has a unicast prefix lifetime of 1 > week. > I think your question is really: should we allow such a host to grant > a request for 6 months if it only has a unicast prefix lifetime of 1 > week? > > In my previous email, if there is a need to allow this (and I'm not > saying > there is), then we'd have to just say it SHOULD NOT, and say that after > the unicast lifetime, the multicast packets are not guaranteed to be > routed. I have no problems changin the text to SHOULD NOT. > > > Hence my question whether the intent is to have such a strict > relationship > > or not. > > I'd like to hear others opinions, but I think that is the authors' > intent. It was my intent. IF we are going to try and eliminate the multi- layered allocation architecture, there needs to be some controlling mechanism and the only one I could find was the unicast prefix in the RAs. Brian From owner-malloc@catarina.usc.edu Tue Sep 18 13:13:28 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26377 for ; Tue, 18 Sep 2001 13:13:24 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA04353 for malloc-list; Tue, 18 Sep 2001 09:18:07 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA04348 for ; Tue, 18 Sep 2001 09:18:04 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8IGI2V17005 for malloc@catarina.usc.edu; Tue, 18 Sep 2001 09:18:02 -0700 (PDT) (envelope-from pavlin) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id HAA04003 for ; Tue, 18 Sep 2001 07:19:53 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8IEIrp01310 for ; Tue, 18 Sep 2001 10:18:53 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Tue, 18 Sep 2001 10:19:14 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SXTX1DAL; Tue, 18 Sep 2001 10:19:13 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87SB2P; Tue, 18 Sep 2001 10:19:13 -0400 Message-ID: <3BA757E4.F845D000@americasm06.nt.com> Date: Tue, 18 Sep 2001 10:19:16 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Dave Thaler , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Erik, Erik Nordmark wrote: > > > If the app says [6 months, 6 months] then personally I would expect the > > host to fail the request if it only has a unicast prefix lifetime of 1 > > week. > > I think your question is really: should we allow such a host to grant > > a request for 6 months if it only has a unicast prefix lifetime of 1 > > week? > > Bingo! > > The related question is: are there applications which would fail to function > today if you applied the constraints imposed by this today i.e. the > fact that no multicast addresses could be allocated by the API > with an end time more than a week into the future? > (For this excercise it would make sense to consider the IPv4 multicast > applications as well as the IPv6 multicast applications that exist just > to try to understand the scope of the applications dependency on multicast > address lifetimes.) As I said in an earlier response, this is not a v6 specific issue. Applications/stacks/nodes/etc. using MAPCAP in v4 will have to deal with the aspect of mcast address leases not filling their initial lifetime requests. Maybe someone with more operational experience than me with MAPCAP allocated addresses will describe how they deal with lease renewal and advertisement issues. I don't see usage of dynamically allocated addresses being requested weeks in advance for one day use. I could be wrong, but I haven't seen any behave in that manner. > > > In my previous email, if there is a need to allow this (and I'm not > > saying > > there is), then we'd have to just say it SHOULD NOT, and say that after > > the unicast lifetime, the multicast packets are not guaranteed to be > > routed. > > I fail to understand why routing might fail. Could you explain? > I do understand that there is a different probability of allocating duplicate > uni-based mcast addresses should the unicast prefix be assigned to another > entity, but this doesn't lead to routing failing unless you are assuming > that routing will do something it doesn't currently do. I think one possible example is with SSM. The first hop router may receive an IGMPv3 join with an old prefix that has been renumbered. It then tries to send the SPT Join to the wrong network. That network doesn't exist and so the Join fails and the multicast traffic never flows. Brian From owner-malloc@catarina.usc.edu Tue Sep 18 13:18:27 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26615 for ; Tue, 18 Sep 2001 13:18:25 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA04471 for malloc-list; Tue, 18 Sep 2001 09:38:54 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA04466 for ; Tue, 18 Sep 2001 09:38:50 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8IGckv03021; Tue, 18 Sep 2001 09:38:46 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f8IGckZ14015; Tue, 18 Sep 2001 09:38:46 -0700 Message-Id: <200109181638.f8IGckZ14015@zed.isi.edu> Subject: Re: uni-based-mcast and malloc-ipv6-guide To: haberman@nortelnetworks.com Date: Tue, 18 Sep 2001 09:38:46 -0700 (PDT) Cc: Erik.Nordmark@eng.sun.com (Erik Nordmark), dthaler@windows.microsoft.com (Dave Thaler), narten@raleigh.ibm.com (Thomas Narten), ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: <3BA758F0.94940360@americasm06.nt.com> from "Brian Haberman" at Sep 18, 2001 10:23:44 AM X-Mailer: ELM [version 2.5 PL3] 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 once they are documented in RFC's they can be added. --bill (zone admin for mcast.net) % % Erik, % I would love to see more usage of DNS for multicast. There % are examples today of mcast addresses being registered in DNS. % Go to your favorite resolver and see what address you get back % when you query all-routers.mcast.net. % % I would have to go and check, but I don't recall discussion % of the use of DNS within the MALLOC Architecture. However, it % would seem rather easy to use DDNS to add MAPCAP allocated addresses % to the DNS. % % Brian % % Erik Nordmark wrote: % > % > > This is a good question, and in fact it's not multicast specific. % > > Here's the unicast equivalent: % > > % > > You're advertising a unicast streaming session on a web page that % > > will start in two weeks (and last one day). You use a URL with % > > a literal unicast address in it. However, you don't know from % > > your RA that your address will definitely be the same by then. % > > Again, this would seem like it might be a problem. % > % > Yes, but for unicast there is a clear possibility of using a hostname instead % > of a literal IP address in such a case. In fact I suspect most unicast % > usage of this nature uses a hostname. % > % > Is such a mechanism possible to use for multicast? (i.e. advertise a FQDN on % > web pages, in SDP, etc and have the hosts do a DNS lookup to join the % > session?) % > Does the malloc architecture take into account using the DNS in % > such a way? % > % > Erik % > % > > I think the same dangers and possible solutions exist for both % > > unicast and multicast. Some solutions, with varying degrees of % > > "goodness", might include: % > > 1) Change the web page if the address changes, and hope people % > > don't use an out-of-date web page. % > > 2) Don't use address literals in the URL, and hope that people % > > don't resolve the name to an address until close to the % > > session starts. % > > 3) Make the admin have knowledge somehow that the address % > > will indeed be valid throughout the life of the session % > > advertised. % > > % > > The point is that pretty much any solution you use % > > for unicast can be used for multicast as well. % > > % > > -Dave % > % > -------------------------------------------------------------------- % > IETF IPng Working Group Mailing List % > IPng Home Page: http://playground.sun.com/ipng % > FTP archive: ftp://playground.sun.com/pub/ipng % > Direct all administrative requests to majordomo@sunroof.eng.sun.com % > -------------------------------------------------------------------- % -- --bill From owner-malloc@catarina.usc.edu Tue Sep 18 14:00:29 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27931 for ; Tue, 18 Sep 2001 14:00:24 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA04360 for malloc-list; Tue, 18 Sep 2001 09:18:24 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA04355 for ; Tue, 18 Sep 2001 09:18:16 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8IGIEd17009 for malloc@catarina.usc.edu; Tue, 18 Sep 2001 09:18:14 -0700 (PDT) (envelope-from pavlin) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id HAA04015 for ; Tue, 18 Sep 2001 07:24:34 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8IENZp01979 for ; Tue, 18 Sep 2001 10:23:35 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Tue, 18 Sep 2001 10:23:45 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TBXMCBPK; Tue, 18 Sep 2001 10:23:44 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87SB2T; Tue, 18 Sep 2001 10:23:42 -0400 Message-ID: <3BA758F0.94940360@americasm06.nt.com> Date: Tue, 18 Sep 2001 10:23:44 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Dave Thaler , Thomas Narten , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Erik, I would love to see more usage of DNS for multicast. There are examples today of mcast addresses being registered in DNS. Go to your favorite resolver and see what address you get back when you query all-routers.mcast.net. I would have to go and check, but I don't recall discussion of the use of DNS within the MALLOC Architecture. However, it would seem rather easy to use DDNS to add MAPCAP allocated addresses to the DNS. Brian Erik Nordmark wrote: > > > This is a good question, and in fact it's not multicast specific. > > Here's the unicast equivalent: > > > > You're advertising a unicast streaming session on a web page that > > will start in two weeks (and last one day). You use a URL with > > a literal unicast address in it. However, you don't know from > > your RA that your address will definitely be the same by then. > > Again, this would seem like it might be a problem. > > Yes, but for unicast there is a clear possibility of using a hostname instead > of a literal IP address in such a case. In fact I suspect most unicast > usage of this nature uses a hostname. > > Is such a mechanism possible to use for multicast? (i.e. advertise a FQDN on > web pages, in SDP, etc and have the hosts do a DNS lookup to join the > session?) > Does the malloc architecture take into account using the DNS in > such a way? > > Erik > > > I think the same dangers and possible solutions exist for both > > unicast and multicast. Some solutions, with varying degrees of > > "goodness", might include: > > 1) Change the web page if the address changes, and hope people > > don't use an out-of-date web page. > > 2) Don't use address literals in the URL, and hope that people > > don't resolve the name to an address until close to the > > session starts. > > 3) Make the admin have knowledge somehow that the address > > will indeed be valid throughout the life of the session > > advertised. > > > > The point is that pretty much any solution you use > > for unicast can be used for multicast as well. > > > > -Dave > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- From owner-malloc@catarina.usc.edu Tue Sep 18 14:09:49 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28116 for ; Tue, 18 Sep 2001 14:09:47 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA04642 for malloc-list; Tue, 18 Sep 2001 10:24:44 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA04637 for ; Tue, 18 Sep 2001 10:24:41 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8IHOcd19537 for malloc@catarina.usc.edu; Tue, 18 Sep 2001 10:24:38 -0700 (PDT) (envelope-from pavlin) Received: from inet-imc-01.redmond.corp.microsoft.com (mail1.microsoft.com [131.107.3.125]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA04628 for ; Tue, 18 Sep 2001 10:23:55 -0700 (PDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Sep 2001 10:23:25 -0700 Received: from 157.54.1.52 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Sep 2001 10:23:24 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Sep 2001 10:23:24 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Sep 2001 10:23:24 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Sep 2001 10:22:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Tue, 18 Sep 2001 10:22:23 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E751@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcFAFCr2cmAezWLMQX+ZH/mxZOcmtAAUjeJA From: "Dave Thaler" To: "Erik Nordmark" Cc: , X-OriginalArrivalTime: 18 Sep 2001 17:22:38.0584 (UTC) FILETIME=[83D71F80:01C14066] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id KAA04629 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Erik Nordmark asks: > I fail to understand why routing might fail. Could you explain? > I do understand that there is a different probability of allocating > duplicate > uni-based mcast addresses should the unicast prefix be assigned to another > entity, but this doesn't lead to routing failing unless you are assuming > that routing will do something it doesn't currently do. Just like providers do source ingress filtering, there might be something similar that providers would do here. (Maybe, maybe not.) -Dave From owner-malloc@catarina.usc.edu Tue Sep 18 14:25:47 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28452 for ; Tue, 18 Sep 2001 14:25:41 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA04712 for malloc-list; Tue, 18 Sep 2001 10:42:11 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA04707 for ; Tue, 18 Sep 2001 10:42:05 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8IHg1k19863 for malloc@catarina.usc.edu; Tue, 18 Sep 2001 10:42:01 -0700 (PDT) (envelope-from pavlin) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id KAA04694 for ; Tue, 18 Sep 2001 10:41:07 -0700 (PDT) Received: from 157.54.9.108 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Sep 2001 10:38:44 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Sep 2001 10:38:43 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Sep 2001 10:38:43 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Sep 2001 10:37:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Tue, 18 Sep 2001 10:36:29 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E753@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcFAX5Rkx4Mz1e80QWqZI4dzOT/o+wAB/+1g From: "Dave Thaler" To: "Brian Haberman" , "Erik Nordmark" Cc: , X-OriginalArrivalTime: 18 Sep 2001 17:37:56.0671 (UTC) FILETIME=[A71014F0:01C14068] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id KAA04695 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Brian Haberman wrote: > > It would be quite useful to outline a bit more of > > the problem that needs solving in the introduction. > > It would also be useful to have a comparision with IPv4 > > (either in the introduction or later in the document). > > Questions I'd like to see answered is whether there are > > approaches and protocols used for IPv4 multicast address allocation that > is > > effectively replaced by the techniques in the draft i.e. whether the > > WGs believe that some mechanisms and protocols that do not need to > > be carried forward to IPv6. > > Not a problem. There was a fair amount of discussion that never > made it into the document wrt what protocols were not being pulled > forward from v4. The overall goal is to avoid the need for any > inter-domain allocation protocol. Our approach basically will only > need, at most, MADCAP servers. Actually, for allocating uni-based mcast addresses, ZMAAP would be more appropriate than MADCAP, since one only has to coordinate within a subnet. (In fact, this was one of the motivations behind doing ZMAAP, since it doesn't require a server.) However, it does not obsolete MADCAP, which would still be used by the sort of people who like using DHCP for unicast address allocation, as well as in the scenario Brian mentions later in the email: > In addition, I could envision the use of this on large > switched LANs with a MADCAP server. -Dave From owner-malloc@catarina.usc.edu Tue Sep 18 14:43:18 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28914 for ; Tue, 18 Sep 2001 14:43:15 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA04800 for malloc-list; Tue, 18 Sep 2001 11:08:07 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA04795 for ; Tue, 18 Sep 2001 11:08:03 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8II7xh20280 for malloc@catarina.usc.edu; Tue, 18 Sep 2001 11:07:59 -0700 (PDT) (envelope-from pavlin) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id LAA04786 for ; Tue, 18 Sep 2001 11:07:33 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Sep 2001 11:06:49 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Sep 2001 11:06:46 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Sep 2001 11:06:40 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Sep 2001 11:05:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Tue, 18 Sep 2001 11:05:32 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E759@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcFAFCr2cmAezWLMQX+ZH/mxZOcmtAAUjeJAAAF0mvA= From: "Dave Thaler" To: "Dave Thaler" , "Erik Nordmark" Cc: , X-OriginalArrivalTime: 18 Sep 2001 18:05:53.0379 (UTC) FILETIME=[8E756B30:01C1406C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id LAA04787 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Dave Thaler > Sent: Tuesday, September 18, 2001 10:22 AM > To: Erik Nordmark > Cc: ipng@sunroof.eng.sun.com; malloc@catarina.usc.edu > Subject: RE: uni-based-mcast and malloc-ipv6-guide > > Erik Nordmark asks: > > I fail to understand why routing might fail. Could you explain? > > I do understand that there is a different probability of allocating > > duplicate > > uni-based mcast addresses should the unicast prefix be assigned to > another > > entity, but this doesn't lead to routing failing unless you are > assuming > > that routing will do something it doesn't currently do. > > Just like providers do source ingress filtering, there might be > something similar that providers would do here. (Maybe, maybe not.) Another example would be if uni-based mcast prefixes are used with BGMP, or any other scheme, to locate the root (domain) of the multicast tree without doing anything different in BGP. If the domain loses its old unicast prefix, after which it's advertised by no one, then the derived multicast addresses would similarly be (intentionally) unusable inter-domain. -Dave From owner-malloc@catarina.usc.edu Wed Sep 19 06:10:42 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28237 for ; Wed, 19 Sep 2001 06:10:40 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id CAA06811 for malloc-list; Wed, 19 Sep 2001 02:30:08 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id CAA06806 for ; Wed, 19 Sep 2001 02:30:07 -0700 (PDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16177; Wed, 19 Sep 2001 03:29:56 -0600 (MDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8J9Tvr18191; Wed, 19 Sep 2001 11:29:57 +0200 (MET DST) Date: Wed, 19 Sep 2001 11:25:30 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: uni-based-mcast and malloc-ipv6-guide To: Dave Thaler Cc: Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" <2E33960095B58E40A4D3345AB9F65EC10290E751@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk > Erik Nordmark asks: > > I fail to understand why routing might fail. Could you explain? > > I do understand that there is a different probability of allocating > > duplicate > > uni-based mcast addresses should the unicast prefix be assigned to > another > > entity, but this doesn't lead to routing failing unless you are > assuming > > that routing will do something it doesn't currently do. > > Just like providers do source ingress filtering, there might be > something similar that providers would do here. (Maybe, maybe not.) Dave, I'm trying to understand exactly what operational practises that you are suggesting and how they would effect the multicast "service". For SSM it is clear that providers might do filtering. But since uni-based mcast doesn't contain a prefix for SSM addresses the nature of filtering will be no different than with IPv4 SSM i.e. verify that the source address is in some access list for using the SSM address or something of that nature. Point is that uni-based-multicast doesn't change anything in this space. For non-SSM (I assume this is what Brian called "ASM") one could envision having checks that somehow compare the unicast prefix in the multicast address with the IP source address. But assuming that ASM really should provide a service where anybody can send, such checks seem quite determintal to the service. Thus if there ever will be reasons for providers or other entities to perform filtering on ASM packets it seems like they need the ability to have access lists with arbitrary IP source addresses associated with the group. Hence the unicast prefix in the group doesn't make filtering any simpler. So I don't understand what operational practise you are hinting at. What am I missing? Erik From owner-malloc@catarina.usc.edu Wed Sep 19 06:19:55 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28344 for ; Wed, 19 Sep 2001 06:19:54 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id CAA06852 for malloc-list; Wed, 19 Sep 2001 02:48:33 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id CAA06847 for ; Wed, 19 Sep 2001 02:48:32 -0700 (PDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA12220; Wed, 19 Sep 2001 02:48:30 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8J9mNr19098; Wed, 19 Sep 2001 11:48:23 +0200 (MET DST) Date: Wed, 19 Sep 2001 11:44:08 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: uni-based-mcast and malloc-ipv6-guide To: Dave Thaler Cc: Dave Thaler , Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" <2E33960095B58E40A4D3345AB9F65EC10290E759@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by catarina.usc.edu id CAA06848 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit > Another example would be if uni-based mcast prefixes are used > with BGMP, or any other scheme, to locate the root (domain) of the > multicast tree without doing anything different in BGP. If the > domain loses its old unicast prefix, after which it's advertised > by no one, then the derived multicast addresses would similarly > be (intentionally) unusable inter-domain. Dave, If so it would be a fine thing to explicitly document this in the draft as a potential issue. One of my comments/questions in the first mail (which you passed to Brian as an editorial one) was the issue of what aspects of the IPv4 stuff we need and need not carry forward to IPv6. Clearly(?) the documents remove the need for MASC for IPv6. Is that all? Will uni-based have any effect on MBGP and BGMP? (I can't find an BGMP draft to even have a peek.) These questions might seem naïve to you, but I suspect there are implementors and operators that might have the same questions. Erik From owner-malloc@catarina.usc.edu Wed Sep 19 14:30:59 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07908 for ; Wed, 19 Sep 2001 14:30:57 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA07957 for malloc-list; Wed, 19 Sep 2001 10:46:13 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA07952 for ; Wed, 19 Sep 2001 10:46:12 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8JHkCX32179 for malloc@catarina.usc.edu; Wed, 19 Sep 2001 10:46:12 -0700 (PDT) (envelope-from pavlin) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id KAA07940 for ; Wed, 19 Sep 2001 10:45:46 -0700 (PDT) Received: from 157.54.8.23 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Sep 2001 10:43:23 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Sep 2001 10:43:12 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Sep 2001 10:43:12 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Sep 2001 10:43:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Wed, 19 Sep 2001 10:43:09 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E77B@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcFA8ERRDh5Xb9OIRp2cfmMHB26/WwAQOWOw From: "Dave Thaler" To: "Erik Nordmark" Cc: , X-OriginalArrivalTime: 19 Sep 2001 17:43:10.0148 (UTC) FILETIME=[8C52A040:01C14132] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id KAA07941 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Wednesday, September 19, 2001 2:44 AM > To: Dave Thaler > Cc: Dave Thaler; Erik Nordmark; ipng@sunroof.eng.sun.com; > malloc@catarina.usc.edu > Subject: RE: uni-based-mcast and malloc-ipv6-guide > > > > Another example would be if uni-based mcast prefixes are used > > with BGMP, or any other scheme, to locate the root (domain) of the > > multicast tree without doing anything different in BGP. If the > > domain loses its old unicast prefix, after which it's advertised > > by no one, then the derived multicast addresses would similarly > > be (intentionally) unusable inter-domain. > > Dave, > > If so it would be a fine thing to explicitly document this in the draft > as a potential issue. I don't think this document should mention BGMP or any other specific protocol. I think it's fine to state the issue generically (i.e. not guaranteed to be routed by all protocols). > One of my comments/questions in the first mail (which you passed to Brian > as an editorial one) was the issue of what aspects of the IPv4 stuff we > need and need not carry forward to IPv6. > > Clearly(?) the documents remove the need for MASC for IPv6. Is that all? > Will uni-based have any effect on MBGP and BGMP? > (I can't find an BGMP draft to even have a peek.) For this type of address, AAP is not really needed either. There is no effect on MBGP. The effect on BGMP is just that it makes it deployable without MASC or doing anything different with MBGP, and hence provides a much cleaner solution than MSDP does for IPv4. I agree that it would be helpful to add a paragraph discussing this in the draft. -Dave From owner-malloc@catarina.usc.edu Wed Sep 19 15:16:46 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09136 for ; Wed, 19 Sep 2001 15:16:41 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA08324 for malloc-list; Wed, 19 Sep 2001 11:49:17 -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]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA08319 for ; Wed, 19 Sep 2001 11:49:16 -0700 (PDT) Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id JAA16629 for ; Wed, 19 Sep 2001 09:32:49 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8JGU5B31628 for malloc@catarina.usc.edu; Wed, 19 Sep 2001 09:30:05 -0700 (PDT) (envelope-from pavlin) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id FAA07121 for ; Wed, 19 Sep 2001 05:05:30 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8JC4Rp17574 for ; Wed, 19 Sep 2001 08:04:30 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Wed, 19 Sep 2001 08:04:33 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SXTX1118; Wed, 19 Sep 2001 08:04:33 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87SBWZ; Wed, 19 Sep 2001 08:04:33 -0400 Message-ID: <3BA889D3.34849A17@americasm06.nt.com> Date: Wed, 19 Sep 2001 08:04:35 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Dave Thaler , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Orig: Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Erik, Erik Nordmark wrote: > One of my comments/questions in the first mail (which you passed to Brian > as an editorial one) was the issue of what aspects of the IPv4 stuff we > need and need not carry forward to IPv6. > > Clearly(?) the documents remove the need for MASC for IPv6. Is that all? > Will uni-based have any effect on MBGP and BGMP? > (I can't find an BGMP draft to even have a peek.) The text in the draft will be changed to point out how uni-based mcast removes the need for inter-domain mcast allocation protocols. From my point of view, I don't see them really affecting MBGP or BGMP. From some discussions I have had with Dave, uni-based mcast MAY help make BGMP simpler... > > These questions might seem naïve to you, but I suspect there are implementors > and operators that might have the same questions. No argument there. I am trying to find some time this week to make some updates to these docs so that we can keep them moving. Brian From owner-malloc@catarina.usc.edu Thu Sep 20 04:25:57 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03734 for ; Thu, 20 Sep 2001 04:25:56 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id BAA02477 for malloc-list; Thu, 20 Sep 2001 01:11:38 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id BAA02472 for ; Thu, 20 Sep 2001 01:11:36 -0700 (PDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29897; Thu, 20 Sep 2001 02:11:24 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8K8BXg12513; Thu, 20 Sep 2001 10:11:33 +0200 (MET DST) Date: Thu, 20 Sep 2001 10:07:18 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: uni-based-mcast and malloc-ipv6-guide To: Dave Thaler Cc: Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" <2E33960095B58E40A4D3345AB9F65EC10290E77B@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk > I don't think this document should mention BGMP or any other specific > protocol. I think it's fine to state the issue generically (i.e. not > guaranteed to be routed by all protocols). OK. But given that I didn't understand the one sentence statement it seems like this explanation needs to be at least a paragraph if not longer. > For this type of address, AAP is not really needed either. > There is no effect on MBGP. > The effect on BGMP is just that it makes it deployable without MASC or > doing anything different with MBGP, and hence provides a much cleaner > solution than MSDP does for IPv4. > > I agree that it would be helpful to add a paragraph discussing this in > the draft. Great. Erik From owner-malloc@catarina.usc.edu Thu Sep 27 11:12:18 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03373 for ; Thu, 27 Sep 2001 11:12:17 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id HAA29985 for malloc-list; Thu, 27 Sep 2001 07:46:21 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id HAA29980 for ; Thu, 27 Sep 2001 07:46:15 -0700 (PDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id f8REhjF01599; Thu, 27 Sep 2001 10:43:45 -0400 Message-Id: <200109271443.f8REhjF01599@hygro.adsl.duke.edu> To: ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: draft-ietf-ipngwg-uni-based-mcast-03.txt Date: Thu, 27 Sep 2001 10:43:45 -0400 From: Thomas Narten Sender: owner-malloc@catarina.usc.edu Precedence: bulk I have question about the references to SSM. In particular, the document says: > The unicast prefix-based IPv6 multicast address format supports > Source-specific multicast addresses, as defined by [SSM ARCH]. To > accomplish is, a node MUST: > > o Set P = 1. > o Set plen = 0. > o Set network prefix = 0. > > These settings indicate that the multicast address is being used in > source-specific multicast transmission. The source address field in > the IPv6 header identifies the owner of the multicast address. Is it required (or desirable) for the network prefix to be set to 0 as stated above? I.e., the test for the address being SSM would be something like: - SSM - All IPv6 SSM multicast addresses will have the format FF3x::/96. In a previous discussion, I believe someone asserted that even for SSM addresses, having the identity of the sender embedded within the address could be useful. I.e, putting in the link value rather than zero could help debugging. What are the pros and cons of doing this? I worry that this document seems to be putting constraints on the format of SSM addresses, when in fact the SSM document to which it refers does not seem to be finished yet (e.g., it does not seem to be in sync with the documents being discussed here). > [SSM ARCH] H. Holbrook and B. Cain, "Source-Specific Multicast > for IP", Work In Progress, March 2001. (which I assume is draft-holbrook-ssm-arch-02.txt) Indeed, shouldn't this reference be considered normative? What is the current status of the ssm-arch document? Thomas From owner-malloc@catarina.usc.edu Thu Sep 27 13:20:49 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07627 for ; Thu, 27 Sep 2001 13:20:47 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA30535 for malloc-list; Thu, 27 Sep 2001 09:58:10 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA30530 for ; Thu, 27 Sep 2001 09:58:08 -0700 (PDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id f8RGtYj02937; Thu, 27 Sep 2001 12:55:35 -0400 Message-Id: <200109271655.f8RGtYj02937@hygro.adsl.duke.edu> To: "Dave Thaler" cc: ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: draft-ietf-ipngwg-uni-based-mcast-03.txt In-Reply-To: Message from "Thu, 27 Sep 2001 09:34:35 PDT." <2E33960095B58E40A4D3345AB9F65EC10290E846@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 27 Sep 2001 12:55:34 -0400 From: Thomas Narten Sender: owner-malloc@catarina.usc.edu Precedence: bulk > If plen = 0, then isn't the "network prefix" portion 0 bits long? That would be one interpretation. Another possibly would be that the network prefix should have special meaning, other than looking at the first plen bits. I guess I'm asking if it would make sense to do so, for (say) debugging purposes. > The SSM range should be FF3x::/12 (and this is mentioned in the SSM > overview doc today). draft-holbrook-ssm-arch-02.txt talks about reserving ff3x and ff2x for SSM. draft-ietf-ssm-overview-01.txt says: > Source-Specific Multicast (SSM) : This is the multicast service model > defined in [SSM-ARCH]. An IP datagram is transmitted by a source S to > an SSM destination address G, and receivers can receive this datagram > by subscribing to channel (S,G). SSM is derived from EXPRESS [EXPRESS] > and supports one-to-many multicast.The address range 232/8 has been > assigned by IANA [IANA-ALLOC] for SSM service in IPv4. For IPv6, the > range FF3x::/12 is defined for SSM services [SSM-IPV6]. But that range also covers the address that are defined in this document, including non-SSM addresses! (And it doesn't cover the plen field that defines whether the address is SSM or not!!) So things do not seem to be in sync. Thomas From owner-malloc@catarina.usc.edu Thu Sep 27 13:25:35 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07901 for ; Thu, 27 Sep 2001 13:25:32 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA30562 for malloc-list; Thu, 27 Sep 2001 10:04:10 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA30557 for ; Thu, 27 Sep 2001 10:04:09 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8RH49T95449 for malloc@catarina.usc.edu; Thu, 27 Sep 2001 10:04:09 -0700 (PDT) (envelope-from pavlin) Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id JAA30468 for ; Thu, 27 Sep 2001 09:38:34 -0700 (PDT) Received: from 157.54.9.108 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 27 Sep 2001 09:35:51 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 27 Sep 2001 09:35:49 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 27 Sep 2001 09:35:51 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 27 Sep 2001 09:35:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: draft-ietf-ipngwg-uni-based-mcast-03.txt Date: Thu, 27 Sep 2001 09:34:35 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E846@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: draft-ietf-ipngwg-uni-based-mcast-03.txt thread-index: AcFHY6sDXkAADOvYRLCF43yhqD+EzwADmebw From: "Dave Thaler" To: "Thomas Narten" , , X-OriginalArrivalTime: 27 Sep 2001 16:35:13.0022 (UTC) FILETIME=[617891E0:01C14772] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id JAA30469 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Thomas Narten [mailto:narten@raleigh.ibm.com] > Sent: Thursday, September 27, 2001 7:44 AM > To: ipng@sunroof.eng.sun.com; malloc@catarina.usc.edu > Subject: draft-ietf-ipngwg-uni-based-mcast-03.txt > > I have question about the references to SSM. In particular, the > document says: > > > The unicast prefix-based IPv6 multicast address format supports > > Source-specific multicast addresses, as defined by [SSM ARCH]. To > > accomplish is, a node MUST: > > > > o Set P = 1. > > o Set plen = 0. > > o Set network prefix = 0. > > > > These settings indicate that the multicast address is being used in > > source-specific multicast transmission. The source address field in > > the IPv6 header identifies the owner of the multicast address. > > Is it required (or desirable) for the network prefix to be set to 0 as > stated above? I.e., the test for the address being SSM would be > something like: > > - SSM - All IPv6 SSM multicast addresses will have the > format FF3x::/96. If plen = 0, then isn't the "network prefix" portion 0 bits long? The SSM range should be FF3x::/12 (and this is mentioned in the SSM overview doc today). -Dave From owner-malloc@catarina.usc.edu Thu Sep 27 13:33:56 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08216 for ; Thu, 27 Sep 2001 13:33:54 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA30607 for malloc-list; Thu, 27 Sep 2001 10:10:55 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA30602 for ; Thu, 27 Sep 2001 10:10:54 -0700 (PDT) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id f8RHArL95553 for malloc@catarina.usc.edu; Thu, 27 Sep 2001 10:10:53 -0700 (PDT) (envelope-from pavlin) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA30581 for ; Thu, 27 Sep 2001 10:08:56 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8RH7qp26473 for ; Thu, 27 Sep 2001 13:07:52 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Thu, 27 Sep 2001 13:08:07 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TTSTRS68; Thu, 27 Sep 2001 13:08:01 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87S1WG; Thu, 27 Sep 2001 13:08:01 -0400 Message-ID: <3BB35CFA.DB63556@americasm06.nt.com> Date: Thu, 27 Sep 2001 13:08:10 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: Dave Thaler , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: draft-ietf-ipngwg-uni-based-mcast-03.txt References: <200109271655.f8RGtYj02937@hygro.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thomas Narten wrote: > > > If plen = 0, then isn't the "network prefix" portion 0 bits long? > > That would be one interpretation. Another possibly would be that the > network prefix should have special meaning, other than looking at the > first plen bits. I guess I'm asking if it would make sense to do so, > for (say) debugging purposes. The problem is that SSM requires all 128-bits to represent the source. So, it seems simpler to indicate in some manner that the destination multicast address is SSM and refer to the source address to determine the "owner". > > > The SSM range should be FF3x::/12 (and this is mentioned in the SSM > > overview doc today). > > draft-holbrook-ssm-arch-02.txt talks about reserving ff3x and ff2x for > SSM. I believe that this draft is in the process of being revised prior to a last call. > > draft-ietf-ssm-overview-01.txt says: > > > Source-Specific Multicast (SSM) : This is the multicast service model > > defined in [SSM-ARCH]. An IP datagram is transmitted by a source S to > > an SSM destination address G, and receivers can receive this datagram > > by subscribing to channel (S,G). SSM is derived from EXPRESS [EXPRESS] > > and supports one-to-many multicast.The address range 232/8 has been > > assigned by IANA [IANA-ALLOC] for SSM service in IPv4. For IPv6, the > > range FF3x::/12 is defined for SSM services [SSM-IPV6]. > > But that range also covers the address that are defined in this > document, including non-SSM addresses! (And it doesn't cover the plen > field that defines whether the address is SSM or not!!) So things do > not seem to be in sync. So, since I am the common denominator between the two drafts, I must claim responsibility. The SSM overview draft should state that FF3x::/32 is the SSM range for IPv6. Brian From owner-malloc@catarina.usc.edu Thu Sep 27 13:45:34 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08983 for ; Thu, 27 Sep 2001 13:45:30 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA30701 for malloc-list; Thu, 27 Sep 2001 10:23:49 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA30696 for ; Thu, 27 Sep 2001 10:23:48 -0700 (PDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id f8RHJwW01344; Thu, 27 Sep 2001 13:19:59 -0400 Message-Id: <200109271719.f8RHJwW01344@hygro.adsl.duke.edu> To: "Brian Haberman" cc: Dave Thaler , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: draft-ietf-ipngwg-uni-based-mcast-03.txt In-Reply-To: Message from "Thu, 27 Sep 2001 13:08:10 EDT." <3BB35CFA.DB63556@americasm06.nt.com> Date: Thu, 27 Sep 2001 13:19:58 -0400 From: Thomas Narten Sender: owner-malloc@catarina.usc.edu Precedence: bulk "Brian Haberman" writes: > Thomas Narten wrote: > > > > > If plen = 0, then isn't the "network prefix" portion 0 bits long? > > > > That would be one interpretation. Another possibly would be that the > > network prefix should have special meaning, other than looking at the > > first plen bits. I guess I'm asking if it would make sense to do so, > > for (say) debugging purposes. > The problem is that SSM requires all 128-bits to represent the source. To be clear, you mean all 128 bits of the source address in the IP header. I'm not questioning that or suggesting otherwise. > So, it seems simpler to indicate in some manner that the destination > multicast address is SSM and refer to the source address to determine > the "owner". Agree with this also. But, does that mean it's best to require that the 64plus middle bits of the SSM address be all zeros? Seems like it would be useful to allow (or even suggest in the SHOULD sense) that the middle bits identify the link. That way if you look at the multicast address (independant of the source IP address) you can still glean some useful information out of it. Note: I'm asking this as a question. If other folks have opinions, I'd like to hear them. > > > > > The SSM range should be FF3x::/12 (and this is mentioned in the SSM > > > overview doc today). > > > > draft-holbrook-ssm-arch-02.txt talks about reserving ff3x and ff2x for > > SSM. > I believe that this draft is in the process of being revised prior to > a last call. > > > > draft-ietf-ssm-overview-01.txt says: > > > > > Source-Specific Multicast (SSM) : This is the multicast service model > > > defined in [SSM-ARCH]. An IP datagram is transmitted by a source S to > > > an SSM destination address G, and receivers can receive this datagram > > > by subscribing to channel (S,G). SSM is derived from EXPRESS [EXPRESS] > > > and supports one-to-many multicast.The address range 232/8 has been > > > assigned by IANA [IANA-ALLOC] for SSM service in IPv4. For IPv6, the > > > range FF3x::/12 is defined for SSM services [SSM-IPV6]. > > > > But that range also covers the address that are defined in this > > document, including non-SSM addresses! (And it doesn't cover the plen > > field that defines whether the address is SSM or not!!) So things do > > not seem to be in sync. > So, since I am the common denominator between the two drafts, I must > claim responsibility. The SSM overview draft should state that > FF3x::/32 is the SSM range for IPv6. Either I still don't get it, or this isn't true either. Only if plen == 0 is the address an SSM one. So you can't say that ff3x::/32 is the SSM range, because the plen field is in the last octet of that range. Thomas From owner-malloc@catarina.usc.edu Thu Sep 27 14:49:36 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10733 for ; Thu, 27 Sep 2001 14:49:35 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA30920 for malloc-list; Thu, 27 Sep 2001 11:15:39 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA30915 for ; Thu, 27 Sep 2001 11:15:38 -0700 (PDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id f8RI6Gs01803; Thu, 27 Sep 2001 14:06:20 -0400 Message-Id: <200109271806.f8RI6Gs01803@hygro.adsl.duke.edu> To: "Brian Haberman" , Dave Thaler , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: draft-ietf-ipngwg-uni-based-mcast-03.txt In-Reply-To: Message from "Thu, 27 Sep 2001 13:19:58 EDT." <200109271719.f8RHJwW01344@hygro.adsl.duke.edu> Date: Thu, 27 Sep 2001 14:06:15 -0400 From: Thomas Narten Sender: owner-malloc@catarina.usc.edu Precedence: bulk Thomas Narten writes: > > So, since I am the common denominator between the two drafts, I must > > claim responsibility. The SSM overview draft should state that > > FF3x::/32 is the SSM range for IPv6. > Either I still don't get it, or this isn't true either. Only if plen > == 0 is the address an SSM one. So you can't say that ff3x::/32 is the > SSM range, because the plen field is in the last octet of that range. I clearly didn't get it above; I agree that FF3x::/32 would be the SSM range. Thomas