Subject: mboned: draft-pashby-ipv6-mc-scoped-addr-01 is now available

From: "Pashby, Ronald W CTR NSWCDD-B35" <[email-masked]>
Date: Mon, 17 Apr 2006 09:40:27 -0500

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.

---

From: John Zwiebel <[email-masked]>
Date: Mon, 17 Apr 2006 14:19:23 -0700

On Apr 17, 2006, at 7:40 AM, Pashby, Ronald W CTR NSWCDD-B35 wrote:

> 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
>
> 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

---

From: Stig Venaas <[email-masked]>
Date: Tue, 18 Apr 2006 09:07:59 +0200

John Zwiebel wrote:
>> Node Identifiers.  This is need to avoid the possibility of flooding a 
>> host that has limited processing resources with multicast
>>
>> 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.
>>
>>

I think keeping group IDs for addresses like the solicited node 
multicast addresses separate is a good thing. The draft is a bit hard to 
parse IMO. Do you want to have one single range for all dynamic group 
IDs for link-local addresses? What if people want to do some link-local 
high bandwidth multicast? Rather than distinguishing between link-local 
and other scopes, isn't it better to have sort of an extended control 
block range that includes stuff like solicited addresses?

I also don't see any clear benefit from distinguishing between group IDs 
for scope <= 8 and > 8.

More comments below.

> 
> 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

Yes, I had trouble reading this.
> 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
> 
> 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
> I don' t understand this.  These are bytes and it isn't clear how this 
> references the 

I don't understand this last sentence. Should it say bytes? I still 
don't see how this results in the range above.

Stig

> FWIW: it isn't clear that you are referencing 2373 WRT multicast address 
> assignments

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/