2.4.9 MBONE Deployment (mboned)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional MBONED Page

Last Modified: 2004-09-07


David Meyer <dmm@1-4-5.net>

Operations and Management Area Director(s):

Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>

Operations and Management Area Advisor:

David Kessens <david.kessens@nokia.com>

Technical Advisor(s):

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion: mboned@lists.uoregon.edu
To Subscribe: majordomo@lists.uoregon.edu
Archive: http://www.uoregon.edu/~llynch/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 for sharing operational
  information to aid in operation of the multicast backbones and

- Update RFC 3171/BCP 51 based on experience.

- Develop a roadmap informational RFC that describes the current
  IPv4 and IPv6 IETF multicast architectures, including
  references to the relevant IETF documents and guidance for
  implementers and network operators.

- Complete the MSDP MIB

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

Goals and Milestones:

Done  Submit I-D on inter-provider coordination of the deployment of pruning mrouteds.
Done  Establish initial charter, goals, and long-term group agenda.
Done  Submit I-D outlining requirements for the existing MBONE infrastructure.
Done  Submit I-D specifying the use of administratively scoped multicast addresses (RFC 2365)
Done  Submit I-D specifying the use of native multicast where appropriate (e.g. exchange points).
Done  Submit I-D on IP Multicast and Firewalls (RFC 2588)
Done  Submit I-D specifying static allocations in 233/87 (RFC 3180)
Done  Submit I-D on debugging multicast problems.
Done  Submit final version of scope zone announcement protocol (MZAP RFC 2776)
Done  Submit final version of scoped address discovery protocol (SADP)
Done  Submit I-D describing ISP multicast deployment practices
Done  Submit I-D, with RPS WG, on extensions to RPSL to describe multicast routing policy
Done  Submit I-D describing extended allocations in 233/8 (RFC 3138)
Done  Submit I-D describing IANA Guidelines for IPv4 Multicast Address Assignments (RFC 3171)
Done  Submit I-D describing IP Multicast Applications issues (RFC 3170)
Done  Submit I-D describing Anycast (RP) mechanism (RFC 3446)
Done  Submit I-D describing Source-Specific Protocol Independent Multicast in 232/8
Done  Submit I-D describing MSDP Deployment Scenarios
Done  Submit I-D describing IPv4 Multicast Unusable Group And Source Addresses
Done  Submit I-D describing Embedded RP for IPv6 Multicast Address
Apr 04  Submit I-D on PIM-SM Multicast Routing Security Issues
May 04  Submit I-D on IPv4/IPv6 multicast co-existence issues and strategies for IPv4 multicast and IPv6 multicast
Jun 04  Update IANA Guidelines for IPv4 Multicast Address Assignments (RFC 3171/BCP 51)
Jun 04  Submit PIM-SM Multicast Routing Security Issues to IESG for Informational
Jun 04  Submit MSDP MIB to IESG for Experimental
Aug 04  Submit IPv4 multicast address allocation procedures IESG for BCP
Aug 04  Submit IPv4/v6 co-existence strategies to IESG for Informational
Aug 04  Submit multicast roadmap/reference architecture document to IESG for Informational


  • draft-ietf-mboned-ssm232-08.txt
  • draft-ietf-mboned-auto-multicast-03.txt
  • draft-ietf-mboned-msdp-deploy-06.txt
  • draft-ietf-mboned-ipv4-uni-based-mcast-02.txt
  • draft-ietf-mboned-embeddedrp-07.txt
  • draft-ietf-mboned-mroutesec-04.txt
  • draft-ietf-mboned-msdp-mib-00.txt
  • draft-ietf-mboned-ipv6-multicast-issues-01.txt

    Request For Comments:

    RFC2365 BCP Administratively Scoped IP Multicast
    RFC2588 I IP Multicast and Firewalls
    RFC2770 E GLOP Addressing in 233/8
    RFC2776 PS Multicast-Scope Zone Announcement Protocol (MZAP)
    RFC3138 I Extended Allocations in 233/8
    RFC3170 I IP Multicast Applications: Challenges and Solutions
    RFC3171 BCP IANA Guidelines for IPv4 Multicast Address Assignments
    RFC3180 BCP GLOP Addressing in 233/8
    RFC3446 I Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)

    Current Meeting Report

    MboneD IETF 61 8 November 2004

    Chair: David Meyer

    David Meyer - time is tight, so let's move fast
    A new topic is Multi Point LSP's - MPLS Multicast

    Brief discussion on drafts in progress :


    Ideas for keeping SSM and ASM traffic separate on real networks. Waiting on normative reference for the PIM spec

    Embedded RP has gone through the IESG and is on track at the editor queue

    Mroutesec - Also in the editor queue


    This needed a waiver for MSDP (an experimental spec is not generally allowed as a reference in a standards track document ) and is waiting on the PIM spec.

    IPv6 multicast issue draft - waiting on the AE to approve for the IESG or bounce.
    It is now out of the WG.

    Note that several specs are now being held up by references to the still unfinished PIM spec.

    Tom Pusateri - the PIM spec is waiting on a few details and needs some volunteers to finish

    Bill Fenner - this is making as much progress as usual (i.e., none).
    Some changes were promised but now I have forgotten what they were.
    Action Item - remember what is needed and ask the group to approve them.

    Tom Pusateri - AMT draft

    AMT is a way to have an AMT gateway discover a path from a non-multicast site to a native multicast domain

    3 way membership handshake has been added, plus a 32 bit nonce based on discussions in Seoul.

    Why do this ?
    Content providers should drive this
    - first at server farms
    - also providers who have multicast enabled upstream provider

    3 way handshake
    AMT Request with a gateway NONCE (GNONCE) from the gateway
    Relay creates a RNONCE from the hash of a secret with the gateway nonce and the group address. It sends the GNONCE and the RNONCE to the gateway
    the gateway sends back the GNONCE and the RNONCE and the ????

    Need - a /16 prefix to deploy and try to do public relay for BGP and anycast

    Pusateri has FreeBSD gateway / relay code ready for testing.

    He wants providers who can provide test relays

    Toerless Eckert :
    Why do we need yet another tunnel mechanism ? Why not IPSec ?
    Or another existing tunnel protocol ?

    Pusateri - this is based on the IPv6 6to4

    This uses the existing tunnel mechanism of 6to4

    Dave Thaler - this has been asked in the past. The difference is primarily at the server end. The primary benefit is on the server side

    Toerless - I would not worry about the scalability Hopefully this will lead to adoption, so it is not clear why scalability is an issue, and deployment will be self limited.

    I do not think that the difference from this and existing tunnels is that essential.

    Pekka Savola - it is

    Toerless - if you cannot provide at least 200 to 300 kbps per tunnel, what is the point.

    Pekka Savola - for DSL aggregation, there can be a lot of L2TP

    Isadore -- This does require state per client per stream. This cannot be escaped

    Dave Thaler - but there is not state for idle clients

    David Meyer - If you want to see other encapsulations (i.e., existing tunnel mechanisms) used for this purpose, you need to make an objection and write a draft.
    Dave Thaler
    Unicast prefix based multicast addresses.

    People ask - "Is there interest in this ?", so I sent out a message to group. No responses as yet.

    This is not intended to replace the IPv4 GLOP space system, but to extend it.

    Is there interest - so I asked the group, is there still interest. There is very little work to do.

    Toerless - We should use SSM for interdomain multicast. This draft leads in the wrong way. This also needs a lot of address space - a complete /8

    Pekka Savola - It is important to note that you get one address per/24, which is not a lot.

    David Meyer - Let's take this to the list.

    Pekka Savola. I notice that there is not yet a current and up to date documentation for multicast addressing. There are some confusing or even wrong earlier documents.

    IANA also needs something to point to when people request multicast address from then.

    I have separated assignment from allocation

    Multicast address discovery is an open question but in practice is not being done.

    Open Issues
    Is making RFC2908 historic appropriate.

    My question to you is - would this be a useful document ?

    Toerless - this would be a nice BCP

    It may be that "architecture" should be removed from the document.

    Pekka Savola. I think that your interpretation of "architecture" is a little more formal than mine.

    Toerless - It is

    Mark Handley - As an author, I think the RFC2908 should be replaced. The word architecture should be kept in the title so that people looking for the old one will find this one.

    Rami Lehtonen
    Multicast source discovery for SSM
    For the one to many model, sources can be discovered out of band

    For many-to many or many to one, need source discovery

    Why in the host ?

    This can be deployed rapidly and co-exists with existing SD protocols

    No RP's are needed, and there is no traffic

    New source sends MSDP to a group controller.

    This can be implemented in the network or in the edge hosts

    Toerless - do all of the channels have to use the same G ? You should not
    try to restrict all of the channels to use the same G.

    Colin Perkins - what problems does this solve ? If I am using ASM for service discovery, then

    Colin - I cannot see any applications that can use this.

    Steve ? - The idea here is that you can announce the (S.G) for SSM. Is there a standardized way to do this ?

    Colin : SIP

    Toerless : It would be useful if Colin could give a presentation to describe how do this. Or write a draft.

    Colin : There are 3000 pages of RFC that describe this

    Toerless : That's too many pages for this purpose. Write us a draft.

    Steve - I have applications that I know how to do this with ASM. I would like an easy way on how to do this for SSM.

    Colin - Go and talk the SIPPING working group. That is what they do.

    H. Ohta

    "Well managed IP multicasting"

    Network operators want to
    - build efficient networks
    - create value added services
    - build manageable networks

    IGMP / MLD does not provide accounting

    Network cannot identify or authenticate or authorize users or keep track of usage

    This is not sufficient for carrier class services (high quality premium or fee based).

    Content providers also want this

    Dave Thaler : Are the existing mechanisms sufficient ?

    Pekka Savola : I think that existing ISPs can do all of this using existing mechanisms

    Haixiang He : Layer 2 authentication is not good enough as the link account provider and the content provider may not be the same party.

    Dave Thaler : Layer 3 solutions involving only
    IGMP and MLD are not at the right layer. For the last hop L2 mechanisms are a much better fit. If you are talking about end to end then I can agree that this is necessary. You might want to remove the IGMP and MLD from this discussion.

    Ohta :
    We need to make it possible for network operators and content providers cooperate and both make money. They need to share revenue, and this means that they need to measure usage. Content providers are not good for networks and network providers are not good for network, They both need to cooperate.

    I want to find out if the MBONED network



    Dan Alveraz: MBONED needs to support different business models for multicast. I want the MBONED group to be a repository for all multicast work. I want to evolve this into a framework and requirements document.

    Pekka Savola : I think that in general this work is useful, and that the current approach is not really useful. We need to take this one level to a frameworks and requirements draft.

    Dan of Cisco - That is what this draft is trying to do.

    David Meyer - How many in the WG think that we should take this on ? (Show of hands - a majority yes, but definitely some no.)

    David Meyer - Let's shift gears to P2MP

    This is in cooperation with the L3VPN group.

    Generic issue - how do we set up multipoint forwarding paths.
    This is just getting attention in the MPLS world.

    Issues include

    - forwarding state vs tree construction cost

    - efficiency of forwarding path

    The last IETF there was the YCAI presentation for L4VPNs and MP-LSP's

    Claim : This is still a multipoint tree building problem, and previous work should be leveraged. Same issues, some different

    Several good attempts to describe a framework, but they also include a solution, which muddies the waters.

    Can the group come up with a framework via IMDOC ?
    I propose that we produce a framework draft and requirements draft and cleanly separate those two.

    IMDOC and MBONED are focused on functional proposals into a logical architecture

    Yakov Richter - You mentioned a need to work on a requirements document.
    There is ongoing work in L3VPN for multicast requirements.
    There is also a L2VPN requirements document in existence. What will this third requirements document service. Requirements document makes sense in the

    John Meylor - One thing that would be useful is some requirements between them. I think that the best thing for MBONED is to extract the common points out of this.

    Nudula - I think that the applications group should have a requirements document. If they feel a need for multicast help, they can come to the appropriate multicast working group.

    Ne Ching from Cisco - The multicast requirements document should include MORE than just the particular and specific requirements for each particular area (such as L3VPN

    Toerless - what we have is a service model. RFC2547 and other architechtures are coming up that have no common frameworks

    Yakov. Talking about a service model in the abstract is pointless unless you talk about the particular service.

    David Meyer - Last one

    George Swallow - swallow@cisco.com

    The setting

    Within MPLS, some people are interested in point to multipoint distribution of large (video) flows with QOS and high availability

    The MPLS mentions multicast but "I am not sure that that sentence is parsable."
    Dino F started this work, but it has gone fallow and needs to be restarted.

    MPLS is NOT chartered to redefine or replace IP multicast

    P2MP TE - exists below the IP layer

    How the set of destination s is determined is outside of the scope

    Iit may be useful to extend PIM and or MBGP to handle P2MP TWE tunnels.

    This is not the job of the MPLS WG

    We are chartered to think about requirements but not to resolve them.

    Eric - I think that your charter is defective

    Swallow - When the charter was broader, we got a lot of bozons involved who wanted to re-define everything

    Mike McBride - The PIM charter says that PIMWG will act as consultants for proposals for "PIM over foo". The area directors did not want us to expand our Charter until we finished our basic documents, which we have nearly done and now the area directors are willing to allow us to expand our charter.

    Tom Pusateri - We are not _looking_ for new work in the PIM WG, but we will consider new requirements if they are brought to us.

    Mike McBride - We are open to this, but we need some guidance from MBONED as to what we should do.

    Seisho Yasukawa - P2MP TE

    TE is used to provide QOS "guarantees"

    MPLS is a suitable solution for this.

    What is P2MP TE ?

    A TE tunnel with one source and multiple destinations
    This should be application agnostic.

    P2MP TE tunnels should have unique P2MP ID's

    Need mechanisms for tunnel establishment, teardown, failure reporting, call admission control, QOS, etc.

    GMPLS should be applicable

    Some issues

    LSP (Label Switched Path) variation on different LSP branches ?
    Can short term data duplication be tolerated when there is tree modification ?
    What are the limits and design targets?
    Dimitri Papadimitrou

    P2MP solutions and properties based on RSVP

    Features include ;

    explicit source routing

    tree is expected to show homogeneous QOS parameters

    need means to delete parts of the tree without affecting other parts of the tree

    Specific issues are still under discussion and we invite advice from the multicast community.

    John Meylor - we need a complete survey of the different multipoint solutions that are available.

    Yakov - That is an excellent suggestion, for the L2VPN or L3VPN working groups.

    David Meyer - We wanted to have MPLS in this group as the multicast people were not providing input into those working groups.

    Adrian Farrel - Detecting P2MP Data Plane Failures.

    There is a need to create analogues of the traditional internet tools such as ping and trace for P2MP solutions.

    For PING, the ping hits all of the egresses, and if it them all, it can flood the ingress.
    Two solutions - rate limiting, or specifying a specific receiver.

    Traceroute has a similar problem.

    Dave Thaler - For multicast, the mtrace goes from the receiver to sender

    Haixiang He - using mtrace the response is unicast

    Bill Fenner - the group is specified in the request. It can be either unicast or multicast.
    Pekka Savola

    Documentation on multicast threats has been lacking. We just finished one document, but we need another for first hop multicast threats.

    This falls between PIM and MAGMA working groups.

    Dave Thaler - I think that this should be done in MAGMA and PIM as appropriate. These threats are not really protocol independent

    David Meyer - We are talking about threat analysis, not the solution

    Tom Pusateri - As we advance the PIM spec, we could and should include this in the PIM WG


    Overview of the Internet Multicast Addressing Architecture
    Issues in Well Managed IP Multicasting Services
    On-link IGMP/MLD/PIM threats and problems