2.4.8 MBONE Deployment (mboned)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 11-Oct-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

MBONED, dec 14, 00,

David Meyer chair, dmm@cisco.com
Evi Nemeth scribe (evi@caida.org)

Mnycast draft - hung on msdp draft, an rfc cant reference a draft.

Multicast apps draft - new draft didn't make the deadline, will be out just after this meeting, added ssm stuff to original that went to iesg and was returned as not useful. Got lots of folks to say it was useful.

Multicast debugging - trying to figure out how to produce something that makes sense and is useful. Come up with a format for common problems that come up and how to fix them. Tools in there are somewhat old, broken links, etc. It changed ownership to kevin. Are there suggestions on what should be in here.

Provide a template to add to it. etc.

Dmm: Good idea but outside our charter.
Thaler: Thats one of the problems we ran into, need to document things that are time invariant, rather than things that are bugs this week and may be fixed next week.
Jon Crowcroft: Experience shows things have changed, used to be able to trace problems, there is enough native mcast now so that its opaque. We don't have documents on unicast routing, maybe we don't need one on mcast routing. Disagrees, needs to point to tools and where to get them.
Jhawk: Real difference seems to be the red tape involved in keeping it in the working group and making an rfc vs. just a web page.
Kevin: If its done as an rfc then it would need to be updated yearly.
Dmm: Just heard 2 opposing views, keep it as a working group document, or not. vote -- keep it.

Mrm draft -- Jim Martin is doing an implementation for nortel, that will include changes and it will be re-submitted here as a draft. should we just do it with snmp. Cisco went off and did an implementation and that drove the draft, then Kevin's students did a host implementation, now Nortel, trying to merge all 3 experiences.

Bill Fenner: Doing mrm with snmp, include bill's slides mrm is a framework of what can be done, some parts of it can be done using snmp. the rtp mib was recently published as an rfc.

**Bill mapped the MRM things that could be done with the mib or extensions to the mib.

Thaler: Don't need extensions, use raw objects. some extensions are router specific.

**Bill asked for opinions on whether MRM is better than just using snmp.

thaler: likes mib, has extra capabilities, avoids the problem of security in MRM.
kevin: MRM uses ipsec.
bill: ipsec not widely deployed.
kevin: snmpv3 isn't either.
bill: ipsec involves kernel changes, snmpv3 doesn't. wider potential deployment of snmpv3 than ipsec in the short term.
beau williamson: agrees.
thaler: the difference between ipsec and snmp security, granularity is different, ipsec can identify the box, snmp can give read/write security on individual functions.
kevin: one thing we can do today is use MRM, with snmpv3 we are still waiting for vendors. how fast can bill write the mib and get it out there. is there an MRM manager? yes, command line.

kevin would like to make sure that a tool like this is available to the community soon. for bill the non starter is ipsec.

thaler: from the manager side its much easier to do snmp manager (eg. with scotty scripting language), real question is how soon vendors will do the agent side. bill will do the mib and a simple manager before the next ietf.
dmm vote: how many want to end of life MRM and go with bill's proposal. mostly yes. MRM has expired, authors might choose not to resubmit it.

mcast-connect draft - brad: got lots of good comments, including them and resubmitting it.
kevin: are you going to talk about ssm, it shouldn't be too hard to add ssm. need to include ssm even though it only has to forward joins to go inter-domain. brad will include some stuff about ssm before resubmitting.

232bcp draft - greg shepard (shep@cisco.com), has slides, include them. want to document operational practices to see how to get ssm into pim.
Hal Sandick: there is some overlap with the ssm section of the pim spec.
dmm: the point is this doc is a bcp dealing with whats out there today.
thaler: everything in it is pim sparse mode and msdp related, if this is a bcp for the general case, don't you need statements about pim dense mode, igp things, etc.
dmm: doesn't want creeping featurism, want to provide operational guidance to folks wanting to deploy ssm and use msdp. targeted to isp providers.
thaler: need rules for igmp.
hal: there are some things that are in conflict with the pim spec, inconsistencies in advertising rp's to the 233/8 range but then send register stops and drop traffic.
dmm: need to add recommendations for igmp.

ssm deployment update, greg: has slides, include them.
has msdp filter list.
greg: wants other folks to contribute them too.

dmm: wants to publish the filter list, there is a set of groups that you don't want to send SAs for power outages on a campus flood the net with discovery packets that need to be filtered. put the filter list in the bcp document. there are bsd and linux igmpv3 stacks/apps including vic/vat diffs and binaries. is the infrastructure robust enough to forward joins?
greg: experience on abilene says yes its ok, but only 4 hops. also ripe meeting test showed it ok, linx demo too.
dmm: sense is that trouble with robust mcast was not with forwarding, but with source discovery.

experiences with ssm, hans kuhn, uoregon, has slides, include them. haven't gotten to measurement and debugging tools yet. os support for freebsd, linux, windows whistler.
dmm: are these complete igmpv3 implementations.
greg: freebsd yes, not sure about others.
thaler: windows is complete.
joel: linux is not backwards compatible. whistler is in beta. vic/vat port done. all tools pointed to from videolab.uoregon.edu. several applications in the works. rumors from cisco that ip/tv will support it.
dmm: asked if from hans perspective he thinks ssm is a win? or can you tell yet?
hans: when ssm images are available on routers it will be a big win.
dmm: here's the real question, first we did sdr and anybody could do an advertisement,
hans: there was no hierarchy, now there is and its on the web so you can search it with google.
joel: one of the real wins for content providers is that ssm may be more popular with backbone providers, because they (content providers) don't have to do anything. joining is a web action, not multicast.
peter lothberg: we can do classic mcast and it kind of works, we can do ssm and it kind of works but we need to get to users, need a standard demark, user is behind last mile stuff, dsl investment is worthless if multicast goes over it. can we give a useful error report to see if multicast works. can the user somehow test if mcast works for him and notify his provider with a sensible error report.
joel: have something that gives you a web page if your join doesn't work, uses a particular port. uses urd. ??? version jamcast had a really neat web page, had a tiny windows program that had a hard coded join that said you are multicast enabled or you aren't.
dmm: requires a mcast heartbeat. ??? - nlanr beacon program does what we want, need to get it into the ssm world.
greg: this moves us to the mboned participant from peter's end user focus.
peter: if no customers demand multicast providers wont do it. content providers are going to push their content out there, we don't want that unicast.
thaler: agrees with peter and rob's comments. want the answer to "do you have mcast" always to be yes. want to give the user a test. microsoft doing a tool. we should focus on that.
dmm: thats what isp's don't like about mcast, its a bandwidth eater as well as saver.
dmm: there was an old proposal for a mcast heartbeat that was shotdown.
thaler: it was shot down because you could do it anyway.
dmm: question: should we resurrect the beacon idea and make a way for users to determine if they have multicast.
kevin: access to mcast can mean many different things.
joel: now you choose from 1 of 3 media clients, those client vendors have a vested interest in keeping their products separate (they like that the user doesn't have multicast, their client negotiates it).
dmm: our purpose is that user could provide data back to their content provider or isp.

msdp monitoring - mark barrett, has slides, include them. fenner: it looks great, you've gotten around to doing all the things i haven't. heartily approves.
greg: agrees, your tool meets all of my wish list.
dmm: does "fair and reasonable" license mean free to the community.
mark: will try to work on it.
fenner: comparing local view with global view might help with knowing what you should have and where to look for problems.
fenner: injecting sa's is scary.
mark: thats why its password protected, might only want it for your local network. can filter at your router to send sa's to a monitor but not accept any.
dmm: injecting sa's is like injecting bogus route into bgp and see where it goes. when you debug these things, you end up with a set of possible problems and you then have to check out each. have you ever thought about reasoning over the set of things (AI style) to see how to track down the offender from the set of possibilities.
fenner: we will have to use the tool for a while to see what to do next. one way to represent data might be the way the sdr-monitor does with red/green boxes.

enhancing deployment with auto tunnels, tony ballardie, ballardie@dial.pipex.com, has slides, include them. idea is host should be able to get multicast enabled without talking to your isp or anyone.
brad cain : one issue is that until there is ip in ip encapsulation in hardware, all the tunnels go with the slow path.
tony: alternative is to get no multicast.
brad: yes but isp doesn't want all that traffic thru the slow path overloading the router.
thaler: this is like the stuff discussed in ngtrans for ip6. use tunnel brokers, go to a web page and ask for a tunnel. not necessarily efficient. real question is to decide how to find a tunnel endpoint near you. ngtrans is leaning to using an anycast address. don't need any sdp stuff because the address is well known, then you don't need to deal with rp's. you are probably going to deal with either your isp's tunnel endpoint or the sources isp because they have customer relationship to you but routers in the middle don't.
beau: question about mechanism, points out that it will break prune override mechanism.
dino: do deploy this quickly don't make any of the changes in slide 3, use igmp proxy, igmp might be in dslam, multicast it on the last hop only. assume that you have an igmp proxy on the first hop or last hop router. arguing about getting sysadmins to do it. hard to get routers to cooperate. if you require host changes it will take another 12-18 months.
zaid: need to think about the fact that some isps that support multicast want to make money on it. isps may not like this.
peter: we are trying to make the multicast native and reliable. this is taking us backwards.
tony: but its been 7-8 years and it doesn't work. reality is that its desirable, but not working. rat hole.
dino: we took 5 years to get ospf deployed, its being deployed at a rate that is ok relative to the complexity.

roger kermode - scope address discovery draft is being resurrected. run sessions with multiple scopes. problem in announcing addresses of smaller scopes. protocol allows you to discover small scope addresses. ipv6 is doing it easier, want to do it that way.

dmm: what do we want to do about heartbeat? take it to the list.


None received.