Subject: [MBONED] I-D ACTION:draft-ietf-mboned-ipv4-uni-based-mcast-04.txt

From: [email-masked]
Date: Mon, 30 Jul 2007 13:15:02 -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-04.txt
	Pages		: 6
	Date		: 2007-7-30
	
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-04.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-04.txt".

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
MBONED mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mboned

---

From: Tim Chown <[email-masked]>
Date: Tue, 31 Jul 2007 15:43:25 +0100

> http://www.ietf.org/internet-drafts/draft-ietf-mboned-ipv4-uni-based-mcast-04.txt

Hi,

I have reread Dave's draft (thanks for reposting) and have a few very
minor comments.  These could all be ignored ;)

Abstract:
"without needing to run an inter-domain allocation protocol."

- many today probably use GLOP, which isn't a protocol as such.  As I
mentioned in Chicago in my academic world many universities don't run
BGP (single fat upstream link) so they need to chase an ASN upstream,
which isn't ideal.
 
Section 1:

- this draft doesn't actually really fix the 4 listed disadvantages,
in that you (as a /16) are limited to 256 addresses, and if you have
smaller than a /16 disadvatanges 2 and 3 may still apply, but it
provides a really useful multicast address allocation scheme for the
many Olde Class B sites out there :)

- how would we declare success or failure after 1 year?

Section 2:

I think this paragraph could be broken up and tweaked for clarity:

"For organizations with a /24 or shorter prefix, the unicast prefix of
   the organization is appended to the common /8.  Any remaining bits
   may be assigned by any mechanism the organization wishes.  For
   example, an organization that has a subnet with a /24 or shorter
   prefix assigned to a link may wish to embed the entire subnet prefix
   within the multicast address, with the remaining bits assigned by
   hosts within the link (e.g., using manual configuration).
   Organizations with a prefix length longer than 24 do not receive any
   multicast address space from this mechanism; in such cases, another
   mechanism must be used."

- My interpretation is that if a site has a /20, it could either assign
16 multicast addresses from the 4 bits it has available, or it could
have one multicast address available on each of its internal /24's (if
that is how the internals happened to be).   Personally, we'd probably
use the 'assign manually within the /16 site' method.  One *might* read
the draft as the latter method being suggested.

So maybe say something like:

"For organizations with a /24 or shorter prefix, the unicast prefix of
   the organization is appended to the common /8.  Any remaining bits
   may be assigned by any mechanism the organization wishes.

 For example, the an organisation that has a /16 prefix assigned may
   choose to assign multicast addresses manually from the /24 sized
   multicast prefix derived from the above method.   Alternatively, an
   organisation may choose to delegate use of multicast addresses to
   individual subnets that are /24 size or shorter.
 
 Organizations with a prefix length longer than 24 do not receive any
   multicast address space from this mechanism; in such cases, another
   mechanism must be used."

"Compared to GLOP, an AS will receive more address space via this
   mechanism if it has more than a /16 for unicast space.  An AS will
   receive less address space than it does from GLOP if it has less than
   a /16."

- in my personal case, we get GLOP from ja.net, so the benefit for the
upstream provider with the ASN is that they could still use GLOP, and
not have downstream sites with /16's but no ASN leeching their GLOP 
space.   This may be worth mentioning as an advantage, especially if 
the provider doesn't have a /16 for internal use themselves (which may 
happen?).

Section 3:

"The same well known intra-domain security techniques can be applied
   as with GLOP. "

- maybe add a sentence to be explicit?

I'm not sure how much dynamic allocation is used today :)

Anyway, just maybe nitpicking a bit, would just like to see this method
happen soon!    I wonder how long IANA will take to pick a /8...

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 31 Jul 2007 15:43:25 +0100

Hi,

Abstract:

Section 1:

Section 2:

 

Section 3:

-- 
Tim