2.4.7 MBONE Deployment (mboned)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 03-Feb-00


David Meyer <dmm@cisco.com>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.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



GLOP Addressing in 233/8



Multicast-Scope Zone Announcement Protocol (MZAP)

Current Meeting Report

Draft MBONED WG Minutes

47th IETF

Adelaide, Australia

27 March 2000


1. Updates
2. Overview of SSM Activity - Source Specific Multicast
3. Usage in 232/8
4. Sprint's PIM-SO Deployment Plans
5. MSDP Traceroute
6. Anycast-RP for IPv6
7. Inter-Domain Multicast Forwarding

Scribe: Evi Nemeth (evi@cs.colorado.edu)


- GLOP Addressing (RFC 2770) is done. In addition the IANA has granted another year for 233/8.

- MZAP (RFC 2776) is done.

- Anycast-RP -- draft-ietf-mboned-anycast-rp-05.txt

There are still some questions about this one. In particular, should it be Experimental or Informational. ADs seem to be of the opinion that Experimental is the appropriate category.

Comments on this point:

Steve Casner - Informational is ok, but its really more than that, informational ok for things not specifying protocol, just methods.

Meyer -- BCP inappropriate, too strong.

Randy Bush -- Read the definition of Informational and Experimental, thinks it should be Experimental.

Steve Casner -- If its deployed in lots of places its BCP.

Jeremy Hall -- Was BGP Experimental or BCP.

Jhawk -- BGP3 is experimental. so it should stay Experimental.

Meyer said take it to Experimental to advance it.

2. Overview Of SSM Activity - Source Specific Multicast (SSM)
John Meylor (Cisco)

Gave a quick overview of current multicast and how SSM would relate to it. In particular, how SSM can simplify things if the source is well-known. Shortest path tree can be created right away, doesn't need shared tree and data to renegotiate path. One important point is that the value of SSM is lost if one mixes shared trees and SPT in 232/8. This turned out to be controversial.

3. Usage in 232/8 -- draft-shepherd-ssm232-00.txt
Greg Shepherd (Cisco Systems)

232/8 space set aside for source only trees. SSM doesn't work well if different domains treat 232/8 differently.

Steve Deering -- The original idea was to set aside 232/8 and in this part of the space you have to identify your sources. Do not wire in knowledge about this piece of address space (a la the admin. scoped space).

John Meylor -- Agreed with Steve Deering on the above point. There are knobs to do specific SSM things, but wont hard code anything.

Steve Deering: Wants to preclude hazards and not lock things in for all time. I.e, make it an operational issue, and make the default behavior treat 232/8 this way.

Greg Shepherd -- Some mechanism needs to be implemented, filtering or hard coded.

Meyer - some folks are using 232/8. Content providers wanted more addresses. Among other things, this makes filtering 232/8 a contentious issue for us.

Dave Thaler -- "Minority Opinion" or application viewpoint. Point: In order to use SSM in 232/8 with filtering, both hosts and routers have to be upgraded, different lans will take different paths from current IGMP2 to IGMP3. Main point: There are financial disincentives to filtering (*,g) in 232/8. So don't filter till most hosts and routers are using IGMP3.

John Meylor -- What is the incentive to move from traditional to 232/8. Its not enough for iana to say don't do it. Filtering in the application layer goes away if they upgrade. But, address collisions can occur.

Suggested middle ground - what about new range or part of 232 that is not filtered.

Jeremy Hall -- Content providers have taken 232 space when they shouldn't and so if it wont work so what.

John Meylor -- There are only a few and they know the implications and its ok. do we see a value of precluding shared trees in an address range. If so we have to filter.

Randy Bush -- What went wrong, why is there this conflict. We need to find a way to transition content into that space (232).

Steve Casner - What are the guarantees that need to be given for 232/8 to be useful?

John Meylor -- Large PIM domains that source content into, content provider cant guarantee what receiver gets, so cant do service level agreements with their customers.

Colin Perkins - They pay per byte, so thats an incentive to upgrade.

John Meylor - Is not suggesting that we limit source specific joins to the 232 space, suggesting that in 232 thats the only way to get data. If you know the source, should be able to join it in any address range.

4. Sprint's PIM-SO Deployment Plans -- draft-bhattach-diot-PIMSO-00.txt
Gene Bowen (Sprint Labs)

SSM seems to fit what most content providers want, can do it with hacks to PIM sparse mode. The draft is available for anyone who wants to contribute, not in IETF process now. Discussion centered around Sprint's deployment plans. It was proposed that the Sprint specific deployment sections be removed and the document made it to a framework document for SSM. Current documents relevant to SSM:


5. MSDP Traceroute to MSDP Working Group, out of time

6. Anycast-RP for IPv6
Brian Haberman (Nortel)

Described extensions to MSDP and Anycast RP for IPv6.
Draft forthcoming.

7. Inter-Domain Multicast Forwarding -- draft-jibiki-iwata-mboned-idmf-00.txt
Atsushi Iwata

Proposed extension to MSDP forwarding. Time ran short and discussion was pushed to the MSDP WG.


None received.