Unicast-Prefix-Based IPv4 Multicast Addresses
draft-ietf-mboned-ipv4-uni-based-mcast-06

[Ballot comment]
The draft seems to imply that an organization must choose between these allocation methods. 
I don’t see why that is the case.  Is there any reason that an AS can’t take advantage of both
GLOP and the mechanism specified in this I-D?  The idea that these mechanisms are
complementary is no where to be found.

[Ballot discuss]
This is a revised discuss.

It feels a bit odd to be evaluating a standards track competitor to a current BCP (RFC 3180).
This document does not update or obsolete 3180, but contains rather strong arguments for
the superiority of this mechanism.  RFC 3306 (which is PS) and the ipv6 analog for this
specification, has been cited as the rationale for staying at PS.

However, there would a significant disconnect between the text of ipv4-uni-based-mcast
and the publication tracks for the three documents.  The text of the I-D strongly discourages
use of 3180 beginning with the first sentence:

    “RFC 3180 defined an experimental allocation mechanisms (called “GLOP”) ...”

(I can find no evidence that 3180 was approved as experimental, and the I-D on which it
was based seems to have been targeting BCP from the –00 draft.)  The document also
includes compelling rationale for why this mechanism is superior to GLOP in sections 1 and 3.

The reader of this document would surely believe be surprised to learn that 3180 is the
BCP, and readers of 3180 have no way to learn that there is another specification they should
be reviewing.

[Ballot comment]
The draft seems to imply that an organization must choose between these allocation methods.  I don’t see why that is the case.  Is there any reason that an AS can’t take advantage of both GLOP and the mechanism specified in this I-D?  The idea that these mechanisms are complementary is no where to be found.

[Ballot discuss]
This is a revised discuss.

It feels a bit odd to be evaluating a standards track competitor to a current BCP (RFC 3180).
This document does not update or obsolete 3180, but contains rather strong arguments for
the superiority of this mechanism.  RFC 3306 (which is PS) and the ipv6 analog for this specification, has been cited as the rationale for staying at PS.

However, there would a significant disconnect between the text of ipv4-uni-based-mcast and the publication tracks for the three documents.  The text of the I-D strongly discourages use of 3180 beginning with the first sentence:

    “RFC 3180 defined an experimental allocation mechanisms (called “GLOP”) ...”

(I can find no evidence that 3180 was approved as experimental, and the I-D on which it was based seems to have been targeting BCP from the –00 draft.)  The document also includes compelling rationale for why this mechanism is superior to GLOP in sections 1 and 3.

The reader of this document would surely believe be surprised to learn that 3180 is the BCP, and readers of 3180 have no way to learn that there is another specification they should be reviewing.

[Ballot comment]
Please consider the Gen-ART Review by Francis Dupont on 2010-05-12:

  - 1 page 3: assignment ... need -> assignments?
    (please reread the statement and improve it)

[Ballot comment]
I share Tim's concern that we need to explore the extent of IETF consensus on this proposal.

In particular there are not many m/c /8 left so we need to make sure the allocation is well used.

One limitation of the proposed method is that a small organization has an extremely limited number of m/c addresses that that can create by this mechanism. Did the WG consider, for example, the creation of a registry of organizations that wanted m/c addresses but which did not have a 16bit AS number, since this would have allowed greater flexibility in the number of m/c addresses an organization could own?


Also I had to stare at this figure

  Bits:  |  8  | Unicast Prefix Length | 24 - Unicast Prefix Length |
          +-----+-----------------------+----------------------------+
  Value: | TBD | Unicast Prefix        | Group ID                  |
          +-----+-----------------------+----------------------------+

for a while before I understood it and wonder if there is a better way to show this.

[Ballot comment]
I share Tim's concern that we need to explore the extent of IETF consensus on this proposal.

In particular there are not many m/c /8 left so we need to make sure the allocation is well used.

One limitation of the proposed method is that a small organization has an extremely limited number of m/c addresses that that can create by this mechanism. Did the WG consider, for example, the creation of a registry of organizations that wanted m/c addresses but which did not have a 16bit AS number, since this would have allowed greater flexibility in the number of m/c addresses an organization could own?

[Ballot discuss]
This is a discuss-discuss.

It feels a bit odd to be evaluating a standards track competitor to a current BCP (RFC 3180).
This document does not update or obsolete 3180, but contains rather strong arguments for
the superiority of this mechanism.

I would like to explore the level of IETF consensus for this specification, and the implications
(if any) for RFC 3180.

IANA comments:

This document updates RFC 5771, as it sets an algorithm for the
assignment of this particular /8. We'd like to add some language to the
IANA Considerations section along these lines:

"Because addresses in this block are algorithmically pre-assigned, no
other IANA assignment policy is required."

Technical Summary

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

This draft specifies a mechanism similar to RFC3306, whereby a
range of global IPv4 multicast address space is provided to each
organization that has unicast address space. A resulting advantage
over GLOP is that the mechanisms in IPv4 and IPv6 become more
similar.

Working Group Summary

This draft has received strong support within the working group and
no major controversies were noted.

Document Quality

There were several comments made during working group last call.
The author has addressed and/or incorporated all questions and
concerns in the document. This document has also been thoroughly
discussed and reviewed for several years on the mailing list and
during the working group meetings.

Personnel

Lenny Giuliano is the Document Shepherd. Ron Bonica is the
Responsible Area Director.

RFC Editor Note

Please replace TBD in sections 3 and 4 with IANA-assigned value,
and delete this note.


IANA Note

IANA should assign a /8 in the global IPv4 multicast address space
for this purpose.