Draft MBONED WG Minutes 47th IETF Adelaide, Australia 27 March 2000 AGENDA ------ http://www.maoz.com/~dmm/IETF/47/MBONED/agenda http://www.maoz.com/~dmm/IETF/47/MBONED/mboned.mgp 1. Updates 2. Overview of SSM Activity - Source Specific Multicast 3. Usage in 232/8 4. Sprint's PIM-SO Deployment Plans 5. MSDP Traceroute 6. Anycast-RP for IPv6 7. Inter-Domain Multicast Forwarding Scribe: Evi Nemeth (evi@cs.colorado.edu) 1. UPDATES ---------- Meyer o GLOP Addressing (RFC 2770) is done. In addition the IANA has granted another year for 233/8. o MZAP (RFC 2776) is done. o Anycast-RP -- draft-ietf-mboned-anycast-rp-05.txt There are still some questions about this one. In particular, should it be Experimental or Informational. ADs seem to be of the opinion that Experimental is the appropriate category. Comments on this point: Steve Casner - Informational is ok, but its really more than that, informational ok for things not specifying protocol, just methods. Meyer -- BCP inappropriate, too strong. Randy Bush -- Read the definition of Informational and Experimental, thinks it should be Experimental. Steve Casner -- If its deployed in lots of places its BCP. Jeremy Hall -- Was BGP Experimental or BCP. Jhawk -- BGP3 is experimental. so it should stay Experimental. Meyer said take it to Experimental to advance it. 2. Overview Of SSM Activity - Source Specific Multicast (SSM) ------------------------------------------------------------- John Meylor (Cisco) Gave a quick overview of current multicast and how SSM would relate to it. In particular, how SSM can simplify things if the source is well-known. Shortest path tree can be created right away, doesn't need shared tree and data to renegotiate path. One important point is that the value of SSM is lost if one mixes shared trees and SPT in 232/8. This turned out to be controversial. 3. Usage in 232/8 -- draft-shepherd-ssm232-00.txt ------------------------------------------------- Greg Shepherd (Cisco Systems) 232/8 space set aside for source only trees. SSM doesn't work well if different domains treat 232/8 differently. Steve Deering -- The original idea was to set aside 232/8 and in this part of the space you have to identify your sources. Do not wire in knowledge about this piece of address space (a la the admin. scoped space). John Meylor -- Agreed with Steve Deering on the above point. There are knobs to do specific SSM things, but wont hard code anything. Steve Deering: Wants to preclude hazards and not lock things in for all time. I.e, make it an operational issue, and make the default behavior treat 232/8 this way. Greg Shepherd -- Some mechanism needs to be implemented, filtering or hard coded. Meyer - some folks are using 232/8. Content providers wanted more addresses. Among other things, this makes filtering 232/8 a contentious issue for us. Dave Thaler -- "Minority Opinion" or application viewpoint. Point: In order to use SSM in 232/8 with filtering, both hosts and routers have to be upgraded, different lans will take different paths from current IGMP2 to IGMP3. Main point: There are financial disincentives to filtering (*,g) in 232/8. So don't filter till most hosts and routers are using IGMP3. John Meylor -- What is the incentive to move from traditional to 232/8. Its not enough for iana to say don't do it. Filtering in the application layer goes away if they upgrade. But, address collisions can occur. Suggested middle ground - what about new range or part of 232 that is not filtered. Jeremy Hall -- Content providers have taken 232 space when they shouldn't and so if it wont work so what. John Meylor -- There are only a few and they know the implications and its ok. do we see a value of precluding shared trees in an address range. If so we have to filter. Randy Bush -- What went wrong, why is there this conflict. We need to find a way to transition content into that space (232). Steve Casner - What are the guarantees that need to be given for 232/8 to be useful? John Meylor -- Large PIM domains that source content into, content provider cant guarantee what receiver gets, so cant do service level agreements with their customers. Colin Perkins - They pay per byte, so thats an incentive to upgrade. John Meylor - Is not suggesting that we limit source specific joins to the 232 space, suggesting that in 232 thats the only way to get data. If you know the source, should be able to join it in any address range. 4. Sprint's PIM-SO Deployment Plans -- draft-bhattach-diot-PIMSO-00.txt ------------------------------------------------------------------------ Gene Bowen (Sprint Labs) SSM seems to fit what most content providers want, can do it with hacks to PIM sparse mode. The draft is available for anyone who wants to contribute, not in IETF process now. Discussion centered around Sprint's deployment plans. It was proposed that the Sprint specific deployment sections be removed and the document made it to a framework document for SSM. Current documents relevant to SSM: draft-holbrook-ssm-00.txt draft-bhattach-diot-PIMSO-00.txt draft-bhaskar-pim-ss-00.txt draft-sandick-pimsm-ssmrules-00.txt draft-shepherd-ssm232-00.txt draft-ietf-idmr-igmp-v3-03.txt draft-ietf-idmr-msf-api-00.txt 5. MSDP Traceroute to MSDP Working Group, out of time ----------------------------------------------------- 6. Anycast-RP for IPv6 ---------------------- Brian Haberman (Nortel) http://www.maoz.com/~dmm/IETF/47/MSDP/IPv6/msdp_and_ipv6.ppt http://www.maoz.com/~dmm/IETF/47/MSDP/IPv6/pim_for_ipv6_and_anycast_rp.ppt Described extensions to MSDP and Anycast RP for IPv6. Draft forthcoming. 7. Inter-Domain Multicast Forwarding -- draft-jibiki-iwata-mboned-idmf-00.txt ----------------------------------------------------------------------------- Atsushi Iwata Proposed extension to MSDP forwarding. Time ran short and discussion was pushed to the MSDP WG.