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

BGMP is a proposed new IETF working group.
Mailing list: [email protected]
To subscribe: [email protected]
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.