2.4.9 MBONE Deployment (mboned)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://antc.uoregon.edu/MBONED/ -- Additional MBONED Page
NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-14

David Meyer <dmm@sprint.net>
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:
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
  • - draft-ietf-mboned-ssm232-04.txt
  • - draft-ietf-mboned-auto-multicast-01.txt
  • - draft-ietf-mboned-rfc3171-update-00.txt
  • - draft-ietf-mboned-ipv4-uni-based-mcast-00.txt
  • - draft-ietf-mboned-iesg-gap-analysis-00.txt
  • Request For Comments:
    RFC2365BCPAdministratively 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
    RFC3171BCPIANA Guidelines for IPv4 Multicast Address Assignments
    RFC3170 I IP Multicast Applications: Challenges and Solutions
    RFC3180BCPGLOP 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

    IETF 56 MBONED WG Minutes
    Embedded IPv6 RP draft (Pekka Savola)
    	- The idea is that it will make interdomain IPv6 multicast work changes the 
    model slightly sources send to one RP and join to one RP.
    	- Format builds on RFC3306, and removes remnants of the "SPT join to the RP 
    only model" 
    	- Questions: Is there any need to change the core routers ?
    	  What happens when local config (or BSR) says one RP but the group name 
    implies another? 
    	- Do you need the RP address field at all (RP ad) ?  Is simpler, but 
    would loose flexibility Could always use different unicast prefixes if you 
    want to use different RP's
    	- Do you need to support plen > 64 ?
    	  (This would overlap with the 32 bit group ID.)
    	- Can this be published before the PIMv2 specs are ?
    	- Toerless : Can we assign different meanings to different RP 
    addresses ? for different modes of operation for PIM, you would have a 
    different RP address 0 is the default another could be for bi-dir PIM 
    	- There are enough unicast addresses that there is no reason to have to 
    conserve them ! 
    	- Pekka: The problem is that this might clash with current unicast IP 
    address allocations. 
    	- Thaler:  It depends a lot on whether you are going to do the same stuff in 
    	- Lenny Guiliani:  Toerless is arguing that the RPad should be changed to be 
    a context field 
    	- Lenny Guiliani:  As I see it, it makes no sense to have a solution for 
    interdomain and a different solution for intradomain multicast. If we 
    continue to do this we will replicate MSDP for IPv6. This idea of 
    building in all this crap into the network just to make SDR work is not 
    wise. I think that we should just say that SSM is the service model for 
    IPv6 multicast. (Scattered applause.)
    	- Dave Meyer; This is a deployment working group. It is not the place to 
    solve the multicast architecture problems. The IESG will have to charter 
    	- Dave Thayer: This is still useful for the intradomain case.
    	- Greg Shepard: I do not see the need for the intradomain case as you can 
    just do it (static application).
    	- Dave: The argument has been made that this is simpler than any of the 
    existing methods 
    	- Greg Shepherd: Including static allocation ?
    	- Dave Thaler: Including static.
    	- Randy Bush: I have said this before; either someone should sell porn 
    over multicast to make it pay, or you should all find something 
    worthwhile to do with your time. (Scattered applause.) 
    	- Dave Meyer: What I propose is to take this to the list.
    Multicast DoS (Tom Pusateri)
    	Multicast is sensitive to state explosion. If you want to scale, you have to 
    limit (S,G) state to only on the tree. With real multicast traffic, you run 
    out of bandwidth way before you run out of state. Not so with attacks.
    	What makes state "leak" ?
    	PIM shared trees
    	MSDP - 330,000 cache entries from the Sapphire worm
    	filters and rate limits will reduce the problem at the expense of 
    dropping real data. 
    	- Toerless: If you limit your customers, then at least the core will not 
    	- Dave Meyer:  Filters and limits will put scale limits on multicast 
    which will be trouble in the future. 
    	How to reduce state
    	- Use SSM
    	- PIM bi-dir can also reduce state as you can use (*,G) state in the 
    forwarding cache 
    	Conclusion - Should not be using the network for source discovery, 
    therefore - make a plan to turn off MSDP
    	- Dave Meyer: So do we think we need a work item to design a 
    deployment plan to turn off MSDP?
    	- Dino: if we cannot limit MSDP, we can make it look like MBGP policy 
    	- Bill Nickless: I believe that going from ASM to SSM is difficult 
    enough that it will require a transition period.
    	- John Meylor: There is a requirement for ASM
    	- John Meylor (after tme talk) 99.99% of all multicast 
    applications today use ASM, and they work.  So be careful before you tar ASM 
    with a broad brush. 
    	- Dave Meyer:  Should there be a BCP to stop encapsulation of 
    multicast data in MSDP packets ? --  ratholed.
    MCOP (Rami Lehtonen)
    	Deal with threats - to control which networks / hosts can or cannot send 
    traffic to/from a multicast group.
    	which networks can / cannot receive a given group, maximum number of 
    groups that an individual host can send data to. 
    	Multicast control is based on filtering IGMP / MLD packets and 
    multicast packets.
    	Control information is  used between MCOP router and Multicast control 
    	- Mark Handley:  when the host leaves the group is the state 
    maintained ?
    	- Rami:  If the group is inactive, it will time out
    	- Mark Handley: For fast joins for layered congestion control, we would 
    prefer that when a host leaves the group that the information is cached for a 
    few minutes.
    	- Dave Thayer: If space is not an issue, there is no reason to remove 
    filters at all until some new filter needs the space.  
    	- Haixiang He: Given the cheapness of memory, why would the filters ever be 
    too large ? 
    	- Rami: The problems in Atlanta were more about the dynamical nature of the 
    control tables, not their size. 
    	- Haixiang He:  what do you authenticate _on_ - if I have two hosts on a 
    network, how do I let one get the multicast and the other not ?  
    	- Rami: The authentication and filtering is always based on a network, not 
    an individual host. 
    	- Haixiang He: Is this for one domain ?
    	- Answer: This is intradomain only, yes.
    	- Dave Thayer: Each router is going to be controled by one 
    organization, so each router has a specific MCOP server that it talks to. 
    	- Dave Meyer: So what do you want us to do ? We don't generally work on 
    protocols in MBONED. 
    	- Rami: Maybe it could be shared with Magma.
    	- Dave Thayer:  Which working groups owns COPS ? They should  get this 
    	- Dave Meyer: I think I would agree with this. One part of this could be 
    here, but the protocol is way beyond either this group or MAGMA. 
    draft-venaas-mboned-v4v6mcastgw-00.txt (Stig Venaas)
    	IPv4 to IPv6 multicast gateways
    	Basic idea is to use PIM-SM
    	Idea IPv6 group maps to IPv4 group : a.b.c <--> PREFIX::a.b.c
    	Gateway strips off or adds the PREFIX
    	Gateway assumes that there always are multicast listeners.
    	Issues :
    	- NAT issues
    	- When resending, all packets get only one IPv6 unicast address
    	Question - should be WG take this over ?
    	- Brian Haberman: It should be MTP rather than NetTP.  My complete 
    comment was that it is something MBONED should look at if v6ops thinks it 
    needs to be done for operational transition.  
    	- Dave Thayer: Going SSM from v4 to v6 seems doable, but there may not be 
    enough v4 addresses to map a v6 SSM source into v4. Also, I think that this 
    is the only current working group that could do this. The question is, 
    should it ? 
    	- Dave Meyer: I think that this needs more research before we take it on; 
    Further, we can  v6ops decide if this is required. 
    EGLOP (Dave Meyer)
    GLOP is sparse, and a /8 is a lot of address space.
    1930 AS space - extended GLOP
    The IRR's already do allocation, so why re-invent the wheel ?
    Dave Thaler has a scheme to assign 225/8
    He went through this and urged that it go to last call.
    Dave Meyer noted the complexity of trying to get multicast address space, 
    and wondered if it was appropriate to set up another.


    None received.