Border Gateway Multicast Protocol (BGMP): Protocol Specification
RFC 3913

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    bgmp mailing list <bgmp@ietf.org>, 
    bgmp chair <bgmp-chairs@tools.ietf.org>
Subject: Document Action: 'Border Gateway Multicast Protocol 
         (BGMP): Protocol Specification' to Informational RFC 

The IESG has approved the following document:

- 'Border Gateway Multicast Protocol (BGMP): Protocol Specification '
   <draft-ietf-bgmp-spec-07.txt> as an Informational RFC

This document is the product of the Border Gateway Multicast Protocol 
Working Group. 

The IESG contact persons are Alex Zinin and Ross Callon.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bgmp-spec-07.txt

Technical Summary
 
 This document describes BGMP, a protocol for inter-domain multicast
 routing.  BGMP builds shared trees for active multicast groups, and
 optionally allows receiver domains to build source-specific, inter-
 domain, distribution branches where needed.  BGMP natively supports
 "source-specific multicast" (SSM).  To also support "any-source
 multicast" (ASM), BGMP requires that each multicast group be associated
 with a single root (in BGMP it is referred to as the root domain).  It
 requires that different ranges of the multicast address space are
 associated (e.g., with Unicast-Prefix-Based Multicast addressing) with
 different domains.  Each of these domains then becomes the root of the
 shared domain-trees for all groups in its range.  Multicast participants
 will generally receive better multicast service if the session
 initiator's address allocator selects addresses from its own domain's
 part of the space, thereby causing the root domain to be local to at
 least one of the session participants.
 
Working Group Summary
 
 The community didn't have enough motivation to invest enough
 cycles in finishing the work on this protocol or its implementation.
 This document would be an archival snapshot of the work.
 
Protocol Quality
 
 The specification was reviewed for IESG by Alex Zinin.

RFC Editor Note:

In section 10, in the second paragraph under the heading 
"OpenSent state:"

OLD

      If the value of the Autonomous System
      field is the same as the local Autonomous System number

NEW

      If the configured remote Autonomous System value for this peering
      is the same as the local Autonomous System number