FYI, discussion taking place in mboned. ------- Forwarded Message
From: John Zwiebel <[EMAIL PROTECTED]> To: "Pashby, Ronald W CTR NSWCDD-B35" <[EMAIL PROTECTED]> Cc: John Zwiebel <[EMAIL PROTECTED]>, <mboned@lists.uoregon.edu> Date: Mon, 17 Apr 2006 14:19:23 -0700 Subject: Re: mboned: draft-pashby-ipv6-mc-scoped-addr-01 is now available On Apr 17, 2006, at 7:40 AM, Pashby, Ronald W CTR NSWCDD-B35 wrote: > This draft was presented at the mboned wg in Dallas. It is available > at > http://www.ietf.org/internet-drafts/draft-pashby-ipv6-mc-scoped-addr-01.txt > It discusses changing the range for Dynamically Assigned Multicast > Identifiers so that they don't overlap with the Solicited > > Node Identifiers. This is need to avoid the possibility of > flooding a host that has limited processing resources with multicast > > traffic that it has not requested. > > There were no objections to this in the wg, but there was little > time to discuss it. Please comment on it so we can determine how to > proceed. > > 2cents: it took me a (long) while to figure out that you were proposing a change to the multicast group-id allocation so that there wouldn't be an L2 addressing overlap. There is information included in the draft that isn't directly relevant and caused me to doubt that I understood what you were proposing. (ie, the probability tables didn't help) The idea that you want to separate out the solicited node group-ids at L2 from the other dynamically assigned group-ids should have been enough. Abstract: should be "multicast group id" [2373] Para 1: should be 'multicast group id' Are 'multicast ids' the same thing as "multicast group ids"? In para 3 these two statements need a reference to explain how these are allocated. (ie, where are these methods defined?) I don't see what these methods have to do with your proposal Hosts may also join a multicast group based on an MD5 hash of its hostname. There is a method for creating dynamic multicast groups, which defines that, the multicast group id to be generated by a 32 bit random number and then setting the highest bit. Why is this the easiest? Why select this range? Why not start the reserved group at D? The options in 4.3.2.1 (site-local, organization-local) don't seem to be broadly used. "The easiest way is to reduce the range from 0x80000000 - 0xFFFFFFFF to the range of 0x80000000 - 0xBFFFFFFF. " I don' t understand this. These are bytes and it isn't clear how this references the random number referred to earlier since there's no reference and it seems orthogonal to what you are proposing. (ie why mention it?) The probability tables also confuse the issue. "This is accomplished by setting the highest 2 bits of the 32 bit random number to 0b10." Para 4.0: explain that this is a proposal for changing the 3307 definitions. ie, repeat again. para 4.1, why change it from the heading used in 3307? Keep the headings consistent. or provide a reason for changing the name. "Permanent IPv6 Multicast Addresses" para 5.1: shouldn't this be LNCB? Add the definitions of the LCNB ranges as defined above. FWIW: it isn't clear that you are referencing 2373 WRT multicast address assignments where only the last 32-bits are the group-ID _______________________________________________________________ user interface: http://darkwing.uoregon.edu/~llynch/mboned.html web archive: http://darkwing.uoregon.edu/~llynch/mboned/ ------- End of Forwarded Message -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
