[MBONED] Fwd: [ppml] Policy Proposal: eGLOP multicast address assignments

[Marshall Eubanks <[e-mail]>]

For the list's attention.

This has also been submitted to RIPE, but with no response as yet.

People who are interested can join the PPML list :

http://lists.arin.net/mailman/listinfo/ppml

and participate in the discussion.

Regards
Marshall

Begin forwarded message:

> From: Member Services <[e-mail]>
> Date: February 16, 2007 5:21:32 PM EST
> To: [e-mail]
> Subject: [ppml] Policy Proposal: eGLOP multicast address assignments
>
> ARIN received the following policy proposal. In accordance with the  
> ARIN
> Internet Resource Policy Evaluation Process, the proposal is being
> posted to the ARIN Public Policy Mailing List (PPML) and being  
> placed on
> ARIN's website.
>
> The AC will review this proposal and may decide to:
>
> 1. Accept the proposal as a formal policy proposal as it is presented;
>
> 2. Work with the author to:
>       a) clarify the language or intent of the proposal;
>       b) divide the proposal into two (2) or more proposals; or
>       c) combine the proposal with other proposals; or,
>
> 3. Not accept the proposal as a formal policy proposal.
>
> The AC will review this proposal at their next meeting. If the AC
> accepts the proposal, then it will be posted as a formal policy  
> proposal
> to PPML and it will be presented at a Public Policy Meeting. If the AC
> does not accept the proposal, then the AC will explain that decision;
> and at that time the author may elect to use the petition process to
> advance their proposal. If the author elects not to petition or the
> petition fails, then the proposal will be closed.
>
> The ARIN Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/irpep.html
>
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/index.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Policy Proposal Name: eGLOP multicast address assignments
>
> Author:
> Marshall Eubanks
> David Meyer
>
> Proposal Version: 1
>
> Submission Date: 15 February 2007
>
> Proposal type: new
>
> Policy term: permanent
>
> Policy statement:
>
> RFC 2770 [now replaced by RFC 3180 / BCP 53] set up an automatic  
> "GLOP"
> multicast address assignment in 233/8 based on Autonomous System  
> Numbers
> (ASNs). The mechanism that was set up in RFC 3180 for extending GLOP
> assignments, known as eGLOP, envisioned the assignment of multicast
> addresses by RIRs from the portion of the 233/8 space corresponding to
> the RFC 1930 private address space. This mechanism has never been  
> used,
> but its use has now imperative due to both an increased interest in
> multicast address assignments to support IPTV and the adopted  
> proposals
> to assign 4-octet ASNs, which do not have GLOP assignments. This
> proposal is for the assignment of Multicast addresses by the ARIN RIR
> using the criteria set up in RFC 3180; equivalent proposals are being
> sent to the other RIRs for their consideration.
>
> Rationale:
>
> RFC 2770 [now replaced by RFC 3180 / BCP 53] set up an automatic  
> "GLOP"
> multicast address assignment in 233/8 based on Autonomous System  
> Numbers
> (ASNs). The mechanism that was set up in RFC 3180 for extending GLOP
> assignments, known as eGLOP, envisioned the assignment of multicast
> addresses by RIRs from the portion of the 233/8 space corresponding to
> the RFC 1930 private address space. This mechanism has never been  
> used,
> but its use has now imperative due to both an increased interest in
> multicast address assignments to support IPTV and the adopted  
> proposals
> to assign 4-octet ASNs, which do not have GLOP assignments. This
> proposal is for the assignment of Multicast addresses by the APNIC  
> RIR;
> equivalent proposals will be sent to the other RIRs for  
> consideration in
> due course.
>
>
> RFC 2770 and RFC 3180 describe an experimental policy for use of the
> class D address space by mapping 16 bits of Autonomous System number
> (AS) into the middle two octets of 233/8 to yield a /24, which is
> automatically assigned to that ASN.  While this technique has been
> successful, the assignments are inefficient in those cases in which a
> /24 is too small or the user doesn't have its own AS, and it does not
> work for 4-octet AS number extension scheme.
>
> RFC 3138 expanded on RFC 2770 to allow routing registries to assign
> multicast addresses from the GLOP space corresponding to the RFC 1930
> private AS space; referred to as the EGLOP (Extended GLOP) address  
> space.
>
> The failure to instantiate RFC 3138 assignments had lead to a  
> situation
> where some multicast users feel like they cannot obtain addresses,  
> while
> others apply directly to IANA, with there being at least 24 approved
> applications in 2006. The current situations in inequitable and
> inefficient and there is no reason not to apply the mechanism set  
> up in
> RFC 3138.
>
> RFC 3138 allocated 233.252/14 to eGLOP. The RFC further says that:
>
>
>      Globally scoped IPv4 multicast addresses in the EGLOP space are
>      assigned by a Regional Registry (RIR).  An applicant MUST, as
>      per [IANA], show that the request cannot be satisfied using
>      Administratively Scoped addressing [RFC2365], GLOP addressing
>      [RFC2770], or SSM.  The fine-grained assignment policy is left
>      to the assigning RIR.
>
>
> We propose that each RIR be allocated an initial /20 from this address
> range, and allocate by default /28's to proposers (16 addresses as
> Multicast address are not subject to CIDR default restrictions),  
> subject
> to the above criteria, and that the RIR assign more addresses based on
> demonstrated need. (Note that Multicast addresses are not subject to
> classless aggregation and address blocks as small as a /32 can be  
> usefully
> assigned.)
>
> The proposed policy should facilitate multicast deployment. The  
> current
> mechanism for non-GLOP multicast deployment involves requesting an
> assignment from IANA, which has no ability to evaluate these requests
> and relies on the IANA Multicast Expert appointed by the IESG  
> (currently
> David Meyer). This process is inefficient, inequitable (as this policy
> route is not widely known), encourages the use of "rogue" self-
> assignments, and discourages application developers and service
> providers from developing and deploying multicast.
>
> The only disadvantage that we can see from the proposed policy is that
> the RIR's will have to set up and execute mechanisms to implement it.
>
> Effect on APNIC: We feel that adoption of this proposal will help to
> make multicast deployment more widespread, and should be of benefit to
> APNIC members adopting Multicast for video distribution on the  
> Internet.
>
> References
> ----------
>
> [IANA]        http://www.iana.org/assignments/multicast-addresses
>
>
> [RFC1930]     Hawkinson, J., and T. Bates, "Guidelines for creation,
>                 selection, and registration of an Autonomous System
>                 (AS)", RFC 1930, March 1996.
>
> [RFC2365]     Meyer, D., "Administratively Scoped IP Multicast",
>                 RFC 2365, July 1998.
>
> [RFC2770]     Meyer, D. and P. Lothberg, "GLOP Addressing in
>                 233/8", RFC 2770, February 2000.
>
>
> [RFC3138]     Meyer, D., "Extended Assignments in 233/8", RFC 3138,
>                 June 2001.
>
> [RFC3180]     Meyer, D., "GLOP Addressing in 233/8",  BCP 53, RFC
>                 3180, September 2001.
>
>
> Timetable for implementation: Immediately
>
>
>
> _______________________________________________
> PPML mailing list
> [e-mail]
> http://lists.arin.net/mailman/listinfo/ppml


_______________________________________________
MBONED mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mboned