Last Modified: 2003-01-14
- 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.
|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|
|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|
|RFC3171||BCP||IANA Guidelines for IPv4 Multicast Address Assignments|
|RFC3170||I||IP Multicast Applications: Challenges and Solutions|
|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)|
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 IPv4. - 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 that. - 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 die - 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 server - 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 too. - 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.