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

From: [email-masked]
Date: Wed, 07 Mar 2007 10:50:02 -0500

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-03.txt
	Pages		: 5
	Date		: 2007-3-7
	
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-03.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-03.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-03.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: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 7 Mar 2007 12:26:38 -0500

> A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mboned-ipv4-uni-based-mca
st-03.txt

The I-D states:

   For subnets with a /24 or shorter prefix, the unicast prefix of the
   subnet is appended to the common /8.  Any remaining bits may be
   locally assigned by hosts within the link (e.g., using manual
   configuration).  Individual subnets 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.

But I think this mechanism should work well also for IP subnets with
prefix longer than /24.

If I administer a network consisting of multiple small IP subnets,
created from at least one, or preferably more contiguous Class C address
blocks, I should be able to use this mechanism just fine for multicasts
to all of those small IP subnets.

Perhaps that paragraph could be word-smithed to sound less restrictive.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 7 Mar 2007 12:26:38 -0500

The I-D states:

Bert

---

From: Pekka Savola <[email-masked]>
Date: Thu, 8 Mar 2007 07:48:40 +0200 (EET)

> Perhaps that paragraph could be word-smithed to sound less restrictive.

I'm not opposed to that but doing so will bring up the issue "who, 
more precisely, is the 'owner' of a prefix"?

If a network provider controls (say) a /16 block and gives it out as 
(for example) /26's:

  - if you get a.b.c.0/26 and manage get permission from holders of 
a.b.c.{64,128,192}/26 to use their 'share', is it OK for you to use 
TBD.a.b.c?

  - or, for all prefixes smaller than /24, the 'right' is with the 
party that holds the superblock, and the owner of the superblock can 
assign addresses arbitrarily, e.g. to the party in the previous 
example:
  a) TBD.a.b.c, or
  b) TBD.a.b.200 (or whatever, or nothing at all)

The same issue is already present to some degree.  Currently the 
proposal is written to delegate directly to the subnets, instead of 
the owner of the prefixes (this has tradeoffs both ways).  This is one 
issue that (IMHO) needs serious consideration.

The question is, whether this is a mechanism a network administrator 
can use inside his/her superblock of allocations, or a host or a 
subnet administrator can use inside his/her subnet.  In the previous 
case, if the multicast allocation need on some other subnets would be 
greater than on others, more addresses could be used in a subnet that 
they're actually needed in.  On the other hand, if the focus is on the 
subnets, most subnets will be able to get about one address but not 
more than that.  That may not be sufficient either.

Personally I'd argue that multicast addresses for a prefix 
(superblock) are likely to be more useful than assignment to a subnet 
because in many cases more than one group address is needed and there 
are usually many subnets which don't need any.  The main advantage of 
a subnet-based approach is (AFAICS) if you want to implement some kind 
of zero-conf multicast group address reservation protocol inside the 
subnet.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Thu, 8 Mar 2007 07:48:40 +0200 (EET)

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 8 Mar 2007 10:10:48 -0500

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]] 

>   b) TBD.a.b.200 (or whatever, or nothing at all)

Probably both scenarios could hold, depending on circumstances.
Especially because the traditional ISP/client model is not the only one
to be considered.

In either case, this mechanism would allow provisioning of global scope
multicast addresses with close to no pain at all, to many more networks
than the maximum length prefix /24 limitation now in the text might
imply.

> are usually many subnets which don't need any.

Agree.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 8 Mar 2007 10:10:48 -0500

Agree.

Bert

---

From: John Zwiebel <[email-masked]>
Date: Thu, 8 Mar 2007 10:58:44 -0800

> to all of those small IP subnets.

   don't you mean "from" those subnets?  We're concerned with the  
source sending
   to a group assigned to that subnet.

> Perhaps that paragraph could be word-smithed to sound less  

Could you provide a concrete example?

Let us say that the TBD prefix is 238
I have a /24:  171.69.12.0/24
Therefore the one and only multicast address I can allocate is:
    238.171.69.12

If you had smaller subnets (/26) you are still limited to the same  
address.
and so some entity has to be delegated the responsibility of saying  
exactly
which sources "own" this address.

OTOH, perhaps -any- and -all- sources in that /24 can send whatever  
they want
to that multicast address.  It is just known that this is going to  
happen.

---

From: John Zwiebel <[email-masked]>
Date: Thu, 8 Mar 2007 10:58:44 -0800

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 8 Mar 2007 14:53:59 -0500

> From: John Zwiebel [mailto:[email-masked]]

>    to a group assigned to that subnet.

Yes, sorry, I caught that too late.

> Therefore the one and only multicast address I can allocate is:

Right. And as Pekka said earlier today, if the ISP has a contiguous set
of n Class C blocks from which a large number of small IP subnets are
created, then you would have n globally unique IP multicast addresses
for all of these small IP subnets, which could be assigned to individual
subnets by some means TBD. Or simply used as global scope IP multicast
addresses by all of these small IP subnets.

This is a pretty cool new feature, I believe. Not as cool as IPv6's
version, but much better than we had before.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 8 Mar 2007 14:53:59 -0500

Bert

---

From: Tim Chown <[email-masked]>
Date: Mon, 12 Mar 2007 15:30:07 +0000

> of zero-conf multicast group address reservation protocol inside the 

As someone at a campus site with an old money Class B but no ASN then
this system would be useful.

The draft states that networks with prefixes > /24 must use a different
technique.   That may mean going to their upstream to see if they can
arrange to use an address from the provider who probably does have a
/24 or bigger.   But that's where most people are now going off cap in
hand to their first BGP-using upstream.

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 12 Mar 2007 15:30:07 +0000

-- 
Tim