PIM WG IETF90 Toronto: July 22nd: 1640-1840 WG Status: Stig Alia: Need shepherd for 4601bis draft-zhou-pim-vrrp: Mike (not on agenda, impromptu slides ;) Leny : Don¡¯t use VRRP. Use unicast routing protocols to solve the problem. Herman: Customers have seen this issue. Some solution needed. Stig: Solution in the document has been implemented and shipping. Mike: WG adoption poll (again!) on mailing list. Stig: Individual submission - question to Alia on thoughts. Alia: Can go as independent submission, if it doesn¡¯t hurt anything architecturally. Will not be an AD sponsored work. If it¡¯s a real problem, why not solve in WG. Discuss on list (maybe there is a better solution). Leny: It is a real problem, since things break. Rather than run PIM, run unicast routing protocol. Unicast protocol should be much simpler to run than a multicast protocol. Stig: Customer are using static routing protocol. Hence the need. draft-ietf-pim-source-discovery-bsr-01: Stig Leny: Dense mode solves all the requirements. Stig: DM has issues. Leny: Fix DM issues. DM is simple. Why reinvent PIM DM and call something else. Ice: no periodic pruning. No the same thing as DM. DM will not be simple if you really want to make it work. Toerless: Processing and punting per service. Someone who doesn¡¯t want service, shouldn¡¯t have to punt traffic. Punting rules needs to be strong. Bad examples with things like router alert in the past. Eric: Will it work over VPNs? Flooding mechanism for application level data might have scaling issues. Replication and flooding through provider network issues. Ice: targeted solution for some application. Not a general purpose solution. Do it in customer site, and for VPNs use BGP. Leny: Source going away, is it a timeout or explicit withdrawal? Stig: There is a hold time. Leny: Intra domain multicast routing which doesn¡¯t scale. Should we also include inter-domain problem statement, or just focus on intra-domain? Stig: might work ok with limited inter-domain case. Toerless: Should be ok with enterprise inter-domain cases if the volume of traffic is low. Jeffery: Auto-rp uses generic (dense) forwarding, why not use it? Stig: this simplifies routing and avoids DM Toerless: reduces state refresh (single message contains multiple). Eric: Still have ASM multicast without doing SM. That is a good thing. Stig: Group ranges can choose to operate in this new mode. Toerless: should have default limits. simple configuration model. maybe ask MBONED. Toerless: doesn¡¯t need to solve inter-domain at the beginning. Can just start with intra-domain. draft-ietf-pim-igmp-mld-wireless-mobile-00: Mike Leny: IGMP more robust for? Mobile networks? general applicability? Mike: Mobile is the requirement. Battery saving. Wi-fi / cellular applications. Moving between fixed <-> wireless. Toerless: Mobile radio has large number of receivers and churning fast. Data which shows how current performance is like, and now it improves with this draft. Mike: Beef up draft with use cases. Toerless: Yes, use cases will be helpful (here or MBONED). Andrew: Some optimizations will do more harm than good. Actual numbers will be useful. Mobile signaling can get impacted by aggressively multicast delivery Leny: Talk about different use case tuning. IGMP defaults defined a long time ago. Stig: IGMP tuning was in MULTIMOB, but this draft is changing protocol for mobile environment Leny: Deployment scenario¡¯s could belong to MBONED. Secure IGMP: Will draft-atwood-pim-sigmp-01 draft-atwood-pim-gsam-00 Toerless: Most networks you have a L2 IGMP snooping switch. Snooping decides whether to forward to the port. Will: Good to know. Doesn¡¯t break the model. Toerless: Attack vector? Why secure the queries? Use case details? Will: Perhaps not needed. Brian: Someone may send out a query to just figure out what everyone else is listening to? Privacy thing? Toerless: Switch could filter. Do we need crypto protection? Andrew: This has a cost. Not clear what is the need. There is enough protection (policy etc) to ensure multicast goes to right places. Is this theoretical or real deployment issue? Stig: Purpose is to receive multicast traffic. Don¡¯t need to have query secured. Will: Right to send a report needs protection. Query perhaps doesn¡¯t need protection. Andrew: IPSec decap is expensive. Toerless: Host level IPSec encap is a hard sell. Andrew: Putting IPSec is great for all vendors. But the real question is, what is the use case? Toerless: Use case needed. What does this really solve? Brian: IGAP was a proposal 10 yrs ago. Looked at that? Will: IGAP was v2 only. It modified IGMP packet structure. Toerless: The problem with IGAP was that it has cleartext password? Brian: On a Multi-Access network if you deploy this, I can just get content if someone else is getting it already. Will: not trying to protect content. Trying to protect ¡®who¡¯ can pull content. Brian: Will be good to clarify this requirement in the draft. Toerless: Multicast filtering is in use by service providers to allow right traffic to the right (paying) subscriber. Will: Taking to next level where individual subscriber can be identified and possibly filter (e.g. father pays for content but both father/kid can watch content. with this approach, I can block it for the kid). Experimental code points: Will draft-atwood-pim-reserve-exp-00 Stig: This was presented in last IETF. How much control we need to keep in WG? Toerless: Attribute code points need enough experimental because IETF process is dragging along too long? This will need code change again when real values get allocated. Brian: Experimental code point may be needed for early code (say Alpha code for testing). Early allocation possible for accepted WG items. Toerless: Switching from experimental to WG allocation painful. Andrew: You can play with experimental code point range. When it comes to WG, you move to WG allocation from normal range. Toerless: Can you stay with experimental values and ship code? Andrew: Just push for pre-allocation as early as possible. Stig: Continue on the mailing list. Rechartering discussion: Chairs Stig: Routing area changes being discussed. Functional basis working group. Andrew: Will be nice to have one multicast group. Good idea. Gives participants better / complete view. Toerless: PIM could be the multicast group. Name could remain PIM. (many) - maybe rebranding will help. Toerless: MANET multicast - where does it go? Many people want to work on that. Alia: What we are thinking are opposite to examples being cited ;) But that¡¯s fine. We want to hear all opinions. Some WG are huge, we are thinking of trimming. Some are too small, which might be able to combine with others. Gets more participation from people. PIM folks help with MLDP. Toerless: We wanted MLDP in PIM, but for some reason (logistics? politics? ;) it went to MPLS. Alia: Multicast over foo type things, we need to get right cross WG reviews. Adopting a draft with cross WG concern, discuss on both working groups (multicast and foo). In general keep multicast over foo in foo wg, but ensure multicast wg review. Question is, what else fits in multicast group? Toerless: Use cases have multicast in them.. spread the word in other WGs to include multicast WG in consultation to make that more successful. Alia: In RTGAREA open meeting we will share some thoughts on how to organize the RTG and make new charters be effective for Honolulu. Make change fast. Leny: PIM WG is already headed in that direction. Including of IGMP/MLD already taking us in that direction. BGP MVPN for e.g. should stay in L2VPN since it¡¯s more BGP than Multicast.