Subject: mboned: I-D ACTION:draft-ietf-mboned-ipv4-uni-based-mcast-02.txt

From: [email-masked]
Date: Thu, 28 Oct 2004 15:55:27 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the MBONE Deployment Working Group of the IETF.

	Title		: Unicast-Prefix-based IPv4 Multicast Addresses
	Author(s)	: D. Thaler
	Filename	: draft-ietf-mboned-ipv4-uni-based-mcast-02.txt
	Pages		: 5
	Date		: 2004-10-28
	
This specification defines an extension to the multicast
addressing architecture of the IP Version 4 protocol.  The
extension presented in this document allows for unicast-prefix-
based allocation of multicast addresses.  By delegating multicast
addresses at the same time as unicast prefixes, network operators
will be able to identify their multicast addresses without needing
to run an inter-domain allocation protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mboned-ipv4-uni-based-mcast-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mboned-ipv4-uni-based-mcast-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mboned-ipv4-uni-based-mcast-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 30 Oct 2004 18:06:10 +0300 (EEST)

> 	Filename	: draft-ietf-mboned-ipv4-uni-based-mcast-02.txt

I've re-read the spec, and have a concern.

GLOP allocates multicast addresses to the operator of the AS, to be 
delegated as appropriate.  This mechanism allocates multicast 
addresses to each subnet.

Now, if we assume that a rather typical subnet size is /24 (often it's 
less, giving no addresses directly to the subnet), this gives one 
address per subnet.  Only rather rarely you see subnets larger than a 
/24.

This draft seems to be written in the sense that e.g., a site with a 
/16 would not get 256 multicast addresses (similar to GLOP), but that 
each subnet within the site would get 1 (or so) address. (And that 
those subnets that don't need an address couldn't/shouldn't be re-used 
for other purposes, because the mapping would be incorrect then)

But multicast usage seems to be more concentrated than that.  Those 
who use multicast often need more than just one address.  And those 
who don't use multicast don't need anything at all.

Hence, trying to allocate directly to the subnets seems to lose the 
significant administrative flexibility for the site handing out 
addresses: GLOP's 256 per site is likely enough due to aggregation 
reasons, but 1 per subnet is insufficient.

Now, if the assignment scheme was defined such that each allocation 
would be done to the site holding the address space (like GLOP is 
done), and the bits inside that would be assigned as appropriate 
(typically manually, but MADCAP would be a possibility as well), I 
think this would be OK.

In other words, due to the amount of bits in v4 multicast address, 
direct mapping (in either direction) between a subnet and multicast 
address might not be sufficient; IPv6 is different here.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/