2.4.7 MBONE Deployment (mboned)

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


David Meyer <dmm@cisco.com>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <wijnen@vnet.ibm.com>

Operations and Management Area Advisor:

Randy Bush <randy@psg.com>

Technical Advisor(s):

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:mboned@ns.uoregon.edu
To Subscribe: majordomo@ns.uoregon.edu
Archive: ftp://ftp.uoregon.edu/mailing-lists/mboned*

Description of Working Group:

The MBONE Deployment Working Group is a forum for coordinating the deployment, engineering, and operation of multicast routing protocols and procedures in the global Internet. This activity will include, but not be limited to:

- Documenting deployment of multicast routing in the global Internet.

- Receive regular reports on the current state of the deployment of multicast technology. Create "practice and experience" documents that capture the experience of those who have deployed and are deploying various multicast technologies.

- Based on reports and other information, provide feedback to other relevant working groups.

- Develop mechanisms and procedures to aid in the transition to native multicast, where appropriate.

- Develop mechanisms and procedures for sharing operational information to aid in operation of the multicast backbones and interconnects.

This is not meant to be a protocol development Working Group.

Goals and Milestones:



Submit Internet-Draft on inter-provider coordination of the deployment of pruning mrouteds.



Establish initial charter, goals, and long-term group agenda.



Submit Internet-Draft outlining requirements for the existing MBONE infrastructure.



Submit Internet-Draft specifying the use of administratively scoped multicast addresses.



Begin work, with RPS WG, on extensions to RPSL to describe multicast routing policy.

Dec 99


Submit Internet-Draft specifying the use of native multicast where appropriate (e.g. exchange points).

Dec 99


Begin work on document of co-existence strategies for IPv4 multicast and IPv6 multicast.

Dec 99


Submit final version of RP document

Dec 99


Submit Internet-Draft specifying static allocations in 233/8

Mar 00


Submit Internet-Draft on debugging multicast problems.

Mar 00


Submit final version of scope zone announcement protocol (MZAP)

Mar 00


Submit final version of scoped address discovery protocol (SADP)

Mar 00


Submit I-D describing ISP multicast deployment practices


Request For Comments:







Administratively Scoped IP Multicast



IP Multicast and Firewalls

Current Meeting Report

Agenda Bashing

MadDogs Update

Deferred by Meyer

GLOP Draft Status

transition from GLOP
GLOP addressing in 233/8
WG last call

Thaler: Why look at this for 232/8 - Is 64 bit addressing an issue?

Meyer - possible that there may be single source models that don't use extended addresses. (not ESL model)

Meyer - We should *not* move GLOP to BCP for now.

Ron Roberts - can we determine which addresses are generating high bandwidth?

Meyer - not addressed yet - submit a draft.

Randy - conflict between last call and the experimental nature of address space

Meyer - leave it experimental.

Anycast RP draft status (DMM slides)

sources known RP-RP via MSDP (convergence slide)
Lots of deployment (i.e. Sprint)
PIM-SM slide (Sprint)

generic anycast approuch (level3 DNS servers)

(unknown) ? about MSDP events of last week

DMM - SA storms caused by SA looping - caused by ability to set defaults routes - instance of mis-configuration causing storm ... (blah)

need tools (peer-RPF for upwards trace)


Pusatari - Terminolgy a problem


Section 6.2 interactions

single-homed MSDP speaker always accept ...seems like a bad thing

doesn't say which address to use - some practices active but not documented

6.2.4 default peers - what are default peers? seems like a bad idea

6.2.4 - bad because it shuts off split horizon

Dino - can't do default route since you might not be directly connected to MSDP peer -

Pusatari: could tunnel

resolution - take to MSDP working group will import MSDP desicions back into this group

MRM status: (Kevin Almeroth)



key is holdtome



intra-domain management tool (NOC)

inter-domain in the style of sdr-monitor



Open Issues:



RTP MIB has support for TR could evolve to supporting all MRM requirements (TS etc.)

Fenner: Not sure what linkages - but will be backwards compatable

Almeroth: DT what piece of draft do you want moved to an archetecture?


Fenner: Agree with Thaler

Connecting Multicast Domains (Brad Cain):



providers PIM-SM/MSDP?MBGP

describes options

cache architecture
protocols submit (s,g) forwarding entries to shared table
several ways to bring transit sources into stub domains

MSDP on boarder

Flood-and Prune protocols

Stub transit examples (see slides)


enterprises use as intra-domain routing protocol
connection options are


Thaler: Unfortunately, admin scoped domain not allowed in PIM2.
Cain: Filter RP data sets at the border
Thaler: Need a draft in PIM WG - I'll help.

MPSPF in stub

easy to connect because
- group LSAs provide global group membership info - >>



need comments on draft

section on BiDir tress

publish as informational doc

SDP and Multicat scoping (Colin Perkins)


SDP containd a mc address


How to choose the scope identifier

MZAP has a scope name would require

MZAP zone ID


Le MUR - Multicast relays in firewalls
(Carsten Bormann)


Unicast considerations

Running firewall:

Packet filters

Proxy firewalls

Multicast relays

Unicast relay


None received.