2.5.1 Border Gateway Multicast Protocol (bgmp)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Oct-99


Bill Fenner <fenner@research.att.com>
Brad Cain <bcain@nortelnetworks.com>
Jeremy Hall <jhall@uu.net>

Routing Area Director(s):

David Oran <oran@cisco.com>
Rob Coltun <rcoltun@siara.com>

Routing Area Advisor:

Rob Coltun <rcoltun@siara.com>

Mailing Lists:

General Discussion:bgmp@catarina.usc.edu
To Subscribe: majordomo@catarina.usc.edu
In Body: subscribe bgmp
Archive: ftp://catarina.usc.edu/pub/bgmp/mail-archive/

Description of Working Group:

As IP multicast is being more widely deployed and used, the existing multicast routing algorithms have demonstrated several limitations which make them unsuitable for deployment globally or among multiple provider domains. Protocols like DVMRP and PIM Dense Mode that rely on broadcasting and pruning leave state in parts of the network that are not on the multicast delivery tree. Protocols like CBT and PIM Sparse Mode use a centralized resource to learn of multicast sources. Service providers are reluctant to maintain state for multicast groups that have no receivers in their domain or use a centralized resource in another domain that they cannot control.

BGMP is a scalable multicast routing protocol which addresses these problems. Like CBT and PIM Sparse Mode, BGMP chooses a global root for a delivery tree. However, the root is a domain, not a single router, so if there is any path available to the domain connectivity can be maintained. BGMP builds a bidirectional, shared tree of domains. Similarly to the unicast EGP/IGP split, BGMP is used as the inter-domain or external protocol, while domains can run any multicast IGP internally (such as CBT or PIM Sparse Mode), and can build source-specific shortest-path distribution branches to supplant the shared tree where needed.

The BGMP working group is chartered to complete the protocol specification and follow it through the Internet standards track. It will also help to design a transition mechanism from MSDP (the Multicast Source Distribution Protocol, an interim interdomain solution that is unlikely to scale for the long term) to Internet-wide BGMP.

Goals and Milestones:

Nov 99


Develop security portion of spec

Nov 99


Evaluate forwarding rules and transient behavior under a wide range of topologies under simulation

Nov 99


Evaluate interoperability with multicast IGPs in more detail and identify any relevant optimizations and/or implementation issues.

Nov 99


Resolve multi-access LAN forwarding mechanisms

Nov 99


Consider monitoring and measurement (e.g. multicast traceroute) and evaluate support for existing and/or new monitoring and measurement tools and protocols.

Mar 00


Produce initial version of MIB

Mar 00


Produce revised protocol specification based upon simulations and evaluations

Mar 00


Design a transition architecture from PIM-SM/MSDP to BGMP

Jul 00


Guide the development of a reference implementation

Jul 00


Oversee interoperability experiments

Jul 00


Submit final version of protocol specification Internet Draft

Nov 00


Finalize MIB

Nov 00


Produce applicability document

No Current Internet-Drafts
No Request For Comments

Current Meeting Report

BGMP met once at the DC IETF. These minutes were prepared by Bill Fenner.

Dave Thaler spoke first, about debugging and monitoring of BGMP. First, a BGMP MIB is needed. Second, tools to debug the multicast RIB (S-routes and G-routes) are needed; a BGP4+ MIB with a PathAttr table per SAFI was suggested. On multicast traceroute: multicast traceroute already has rules for handling shared-tree protocols, so the only problem arises when crossing the inside of a domain may be problematic. This is handled by having the BGMP router encapsulate the trace across the domain to the upstream BGMP router when the MIGP could be problematic.

Modifying "mrinfo" to include BGMP peering information was suggested, but it was agreed that "mrinfo" should be replaced by SNMP and so should not be updated with new functionality.

Dave's proposals on monitoring action items:

Brad Cain talked about incremental deployment of BGMP and transition from PIM-SM+MSDP. BGMP sources can easily be injected into MSDP; the question is how to use a PIM-SM+MSDP domain as transit for BGMP. Such a domain is effectively multiple source-based-tree domains; one option is to use domain-wide reports to make membership known to the borders (DWR's would only be required at the RP's).

Isidor Kouvelas talked about a problem with source-specific branches in BGMP; generally, the problem arises when a failure occurs on a sender-only branch after a source-specific tree has been set up. The BGMP authors are considering solutions to the problem.


None received.