NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 27-May-99
Chair(s):
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:
Done |
|
Submit Internet-Draft on inter-provider coordination of the deployment of pruning mrouteds. |
Done |
|
Establish initial charter, goals, and long-term group agenda. |
Done |
|
Submit Internet-Draft outlining requirements for the existing MBONE infrastructure. |
Done |
|
Submit Internet-Draft specifying the use of administratively scoped multicast addresses. |
Done |
|
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 |
Internet-Drafts:
· Multicast Debugging Handbook
· Multicast-Scope Zone Announcement Protocol (MZAP)
· Scoped Address Discovery Protocol (SADP)
· Multicast-Friendly Internet Exchange (MIX)
· IP Multicast Applications: Challenges and Solutions
· Justification for and use of the Multicast Routing Monitor (MRM) Protocol
Request For Comments:
RFC |
Status |
Title |
RFC2365 |
Administratively Scoped IP Multicast | |
RFC2588 |
IP Multicast and Firewalls | |
Administrivia
Scribe: Evi Nemeth (evi@cs.colorado.edu)
Agenda
- Logical RP Draft Status -- Meyer
- Static Allocation Draft Status -- Meyer
- Allocation of Multicast Addresses in IPv6 -- Haberman
- Should MSDP not Advertise Some Groups -- Meyer
- MAESTRO BOF Summary -- Oran
- Inter-Domain Multicast Routing Issues -- Estrin
- Multicast Session Control Center -- Fasano
- Mzap Status -- Thaler
- Experiences with MSDP and MRM -- Hall
- Status of Internet Multicast -- Meyer/Fenenr
Detailed Minutes
Logical RP Draft Status (Meyer)
Randy Bush: Concerns about how to debug problems.
Tom Pusatari: Hard to debug in PIM v2, since BSR knows but nobody else knows. We need to know which box advertised an SA to you.
Bill Fenner: Was the discussion about how to do the inter-domain version included as well as the intra-domain version. Need explicit discussion about inter- and intra-. feels there is an interaction.
Dorian Kim: The inter-domain stuff was put in draft 0 because it might be a neat thing. having tried it, now know you don't want to do this.
Dave Thaler: If we are going for bcp leaving it out is fine, but if we are going for informational, we need text that says why you should not do it. need the warning there.
Randy Bush: Why invent new terms re. anycast.
Meyer: were using the term Anycast, but Deering and others objected to its use.
Bill Fenner: RFC 1546 seems to define anycasting in the way we are using it.
A "hum vote": 2/3 for "anycast rp", 1/3 "logical rp". Carried. The name will be changed back to Anycast RP.
Static Allocation Draft Status (Meyer)
Few comments made. Should go to WG last call (experimental) soon.
Meyer: Learned after the meeting that the IANA has allocated 233/8 for this use.
Fenner: Add section to the document on transition and on getting the addresses back.
Handley: If we use BGMP, these addresses are not aggregatable so how do they work in a GRIB in BGMP.
Thaler: Doesn't think its a major problem
Meyer: wants to update doc and get it going because lots of people are using static addresses and we need a doc to support them.
Allocation of Multicast Addresses in IPv6 (Haberman)
Use the ipv6 network prefix for a domain in multicast address
Thaler: likes it for interface to routing, AS number not included in bgmp so its nice and simple.
Fenner: one of the reasons to limit to lower 32 bits is to not collide with the ethernet link level address in the lower half. haberman's proposal has 48 bits available and wants to use them. but that messes things up. bill says you have already 64 bits of uniqueness. someone elsewhere (ipv6 wg's) made a decision that conflicts in the ethernet address were bad.
Should MSDP not Advertise Some Groups (Meyer)
SA caches get full of junk, maybe need to have BCP to describe filters you need to put on MSDP. RP's announcing SA's for internal sources. Hardware whose dhcp litters the SA caches,
Thaler: what do you break if you filter, e.g., don't filter mtrace.mcast.net. You would have to look at each one. SLPv1 is the bad guy for SVRLOC. may want to coordinate with SLP working group before recommending filtering.
Fenner: for the service discovery items, what TTL are these sent with. Folks assume TTL scoping. Might want something like "don't forward an sa unless you have gotten a packet with ttl > 16".
Kim: Should write a doc that says dont forward this type of thing.
Thaler: What is the relationship between these entries and those where only 1 packet was received. might fix it in MSDP to eliminate the 1 only packets.
Fenner: Meyer's data shows that msdp infrastructure is not passing everything everywhere. His data shows 5k sa's and here are 6k bogus ones. Meyer: For example, a campus power outage adds thousands of these.
Pusatari: Tell IANA not to allocate these, hunt down these people and tell them not to do it, people reuse addresses for different purpose because they are so hard to get.