NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
David Meyer <email@example.com>
Operations and Management Area Director(s):
John Curran <firstname.lastname@example.org>
Michael O''Dell <email@example.com>
Operations and Management Area Advisor:
John Curran <firstname.lastname@example.org>
Scott Bradner <email@example.com>
General Discussion: firstname.lastname@example.org
To Subscribe: email@example.com
Description of Working Group:
The MBONE Deployment Working Group will be 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:
· Deployment of multicast routing in the global Internet.
· Receive regular reports on the current state of the deployment of mbone technology. Create "practice and experience" documents that capture the experience of those who have deployed and are deploying various MBONE technologies (e.g. PIM, DVMRP, CBT).
· Based on reports and other information, provide feedback to IDMR.
· 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 global MBONE.
· Development of guidelines to improve the use of administratively scoped multicast addresses.
· Develop mechanisms and procedures for creating and maintaining a MBONE topology database.
This working group will initially interact closely with IDMR. It is believed that, once hierarchical multicast routing systems are specified and deployed, the working groups will diverge somewhat. Finally, note that in the below 'Goals & Milestones', the type of RFC will be subject to discussions within the 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.
Submit Internet-Draft specifying the use of aggregation for DVMRP (and, in general where applicable). In addition, address the use of DVMRP default.
Submit Internet-Draft specifying the use of native multicast where appropriate (e.g. exchange points).
Begin work on document of co-existence strategies for IPv4 multicast and IPv6 multicast.
Begin work on a document describing the deployment of inter-provider hierarchical multicast routing coordination (or, when available).
· Multicast pruning a necessity
· Administratively Scoped IP Multicast
· Introduction to IP Multicast Routing
· Some Issues for an Inter-domain Multicast Routing Protocol
· Guidelines for Rate Limits on the MBONE
· PIM Multicast Border Router (PMBR) specification for connecting PIM-SM domains to a DVMRP Backbone
· Multicast Debugging Handbook
No Request For Comments
Minutes of the MBONE Deployment (MBONED) Working Group
[Note - One still unresolved issue from Munich surrounds the assignment (or non-assignment) of addresses from the IPv4 Local Admin Scope. This issue was raised by the people from SRCLOC WG, and has yet to be resolved. -- DM]
MBONED Working Group, Wed 1:00-3:15
Chaired by David Meyer
Reported by Dino Farinacci
I. Active Drafts - Dave Meyer
There are 7 active drafts:
· Rate-liming guide
· Draft-gentile-multicast-deployment-00.txt needs an owner
· RPSL support for tunnels is done
II. Pruning Draft Status - John Hawkinson
· Some editorial changes and resubmitted to meet IESG requirements
· Send out for last call
· Done in 15 seconds
III. Draft Updates - Dave Meyer
- IESG is chewing on it (Informational RFC)
- Also at the IESG (BCP draft)
- There was a request to allocate a portion of the administratively scoped address range
- Service Location people requested a 1024-sized block of group addresses. Steve Casner indicated two ways to solve this problem:
- Use a single address that bootstraps other addresses
- Use a single address and have SAP allocate the other addresses
- Functional allocations should be allocated by IANA. The working group may allocate a range to IANA
- Consensus, is to modify the draft to allow IANA to assign address in a subrange.
IV. PIM-SM Interop Testing - Dave Thaler - (for Rusty Eddy)
· Gated and Cisco's running in the lab
- tested C-RP and C-BSR scenarios
- Hellos and DR election
- C-RP hash function
- BSR election and RP-st distribution
- IGMP reports and leaves
- simple join/prune
- register encap/decap in both direction (Cisco ,-> gated)
- register-top from Cisco to gated
- SPT join from Cisco to gated
· To be tested
- Assert mechanism
- more extensive join/prune
- SPT from gated to Cisco
- Interop with pimd (run over the same unix kernel)
- stress testing
- http://catarina.usc.edu/pim (implementation section)
V. Some DVMRP Route Observations - Dave Thaler
· Days in June/July monitored DVMRP routing table
- periodic updates/min 21.07/30.77/41.50 95/96/97 report packets
- triggered updates 8.09/9.73/68.30 95/96/97
- metric changes 37.994/93.84/342.36 95/96/97
· 95 - 2500 routes, 96 - 4000 routes, 97- 5000 routes
· Top 100 unstable routes
- 82 are /24s from one provider
VI. A New Multicast Debugging Tool (mtool) - Jeff Smith
· NTT developing a monitoring tool for corporate multicast networks.
Sue Hares - Multicast Additions for RPSL
· Generate Multicast Configurations requires Interface Policy
· No interface policy in current RPSL and multicast requires interface policy
Martin Tatham - ftp://ftp.labs.bt.com/pub/idmr/bt_idmr_reg.tar.gz
Shared Trees - Distinct policy on "Cores"
John Meylor - IPMI Update
· IPMI is building a "Multicast Channel" to provide content to expedite multicast deployment
MBONED Working Group, Wed 7:30-10:00
Chaired by David Meyer
Minutes recorded by Dino Farinacci
Liming Wei - MRSM
- Use to detect faults in multicast routing
- Isolate location of fault
- Security concerns
- Want to have good coverage of faults
- Good Extensibility
- Low overhead
· What is a fault?
- Topological disconnectivity
- Blackholes in forwarding path
- Excessive/persistent packet losses
- Excessive duplicates
· Now use
- mtrace, rsh, traceroute, a combination of
· Protocol Components
- MRSM monitor, Test Sender (TS), Test Receiver (TR)
· Protocol Messages
- Beacon, Monitor Requests, Statistics Reports
VII. DVMRP Route (In)Stability in the MBONE (preliminary results) - Van Jacobson
· During average hour, 5500 routes, 66% were stable.
· But ~3000 routes were changing.
· Instability caused by a protocol implementation.
· http://ganef.cs.ucla.edu/~masseyd/Route for further information on route stability.
VIII. Admin Scope Zone Discovery - Mark Handley
· Larger scope zones can be flooded through local scope zones using an address from the local scoped zone.
· Flooded with reverse path checks.
· Requirement is to not originate an advertisement in x time after receiving one.
· Use ID to suppress loops between local scoped zones.
IX. Assignment of Admin. Scoped Addresses - David Meyer
· How to do assignment?
· What is an "appropriate" assignment/allocation?
· Who is the allocation "authority"
· Additional document required?
· Appropriate scopes? Multiple scopes?
· Put TBDs in document
· Add reference to document describing assignment guidelines
· SvrLoc needs 1024 assignments and can't really work with only 1 well-known addresses
· Single globally assigned group to bootstrap and get more addresses (scoped using the globally assigned group).
go to list