BGMP met in one session at the Oslo IETF: Tuesday 5:00-6:00.

BGMP is a proposed new IETF working group.
Mailing list: bgmp@catarina.usc.edu
To subscribe: bgmp-request@catarina.usc.edu
Archive: ftp://catarina.usc.edu/pub/bgmp/mail-archive/

The meeting started with a summary of BGMP.  BGMP is an inter-domain multicast tree building protocol.  It builds bidirectional trees of domains, with a root domain per group determined by a table (likely to be a RIB propogated by MBGP, but that's a detail to be worked out).  Bidirectional trees reduce the dependence on the root for data distribution, and trees of domains reduce the dependence on any one node in a domain, allowing more flexibility in handling failures.  BGMP supports bidirectional or unidirectional shared trees as well as source-specific trees.

Dave Thaler gave a status update.  He covered two main items; the use of BGP path attributes and a brief implementation status.  As discussed in IDMR in Minneapolis, using BGP Path Attributes to perform designated forwarder election can eliminate a race condition that arises between the time a BGP route is learned and the BGMP designated forwarder election exchange occurs.  However, there was a strong feeling from the BGP community that it's not appropriate to have BGP perform per-link actions, particularly for a specific tree construction protocol.  Dave said that Rusty Eddy had some comments on handling the race condition which should get added to the spec.

The other proposed BGP path attribute, the directional annotation, seems more feasible, since it's more end-to-end and is likely to be usable for other tree construction protocols (e.g. bidirectional PIM).  Tree directionality needs to get added to the spec.

Bill Fenner gave an overview of BGMP and the attributes that make it appropriate for an inter-domain routing protocol; that presentation is available in the proceedings.

A discussion then followed.  The highlights of the discussion follow.

It was suggested that the transition architecture be a join work item for MSDP, BGMP and MBONED.  MSDP and BGMP should be involved because they are the protocols being transitioned from and to, respectively, and MBONED because transition is an operational issue so the operational multicast WG needs to be involved.  The MBONED mailing list will be used for this transition discussion.

An additional work item was suggested: constructing the rules for BGMP to interoperate in a shared forwarding cache on a single router using the architecture described in draft-thaler-interop.  This should probably be a seperate informational document. 

Rusty Eddy at ISI has a BGMP implementation and might be able to help with interoperability and protocol testing.

Two service providers raised issues:
Interoperability and coexistence with MSDP, since we know that MSDP will remain deployed for some time.
Since MSDP is our "now" solution, we don't want the BGMP "future" solution to interfere with resources (e.g. developer time) that should be committed to MSDP.

Deborah on "simulation" item on charter - "test" is a better word which could include simulation if appropriate.  ns has bidirectional tree stuff but it doesn't simulate any particular routing protocol.

Don't implement without a story on debugging (at least mtrace, i.e. at least as much as we have now).
"network management implications" in spec?
story on debugging infrastructure before real deployment

Action Items:
Could other tree construction protocols use designated forwarder elections from MBGP?
Rusty Eddy's comments on how to handle the forwarder election race condition should get added to the spec.
Tree directionality needs to get added to the spec.
Spec security section needs to get updated; many can be the same the BGP4 spec.