pim Tuesday, 15 November 2011 Notes by : Marshall Eubanks Agenda bashing NOTE WELL Status A good year for RFCs New work items Some drafts to discuss Stig : ietf-pim-port is done Mike : Pop count has gone through WGLC without much response 3 support the draft Lenny opposed : saying PIM shouldn't carry topology info Greg S : I think he misunderstood the intention behind pop-count Mike : I hesitate to carry on with such weak response Stig : Check the room Mike : OK : If PIM pop count should proceed (as experimental) raise of hands : 7 in favor 0 opposed Mike : We'll take it to the list I think there is consensus here Vero Zheng : 4601 revision advance PIM from PS to DS implementation and deployment report requested by IESG Stig : I don't think it should be that hard to reach internet standard the big concern is with down refs Vero : This work is supporting work 4601bis - draft adopted by WG in October addressed errata, optional features, and revved to 01 version we are preparing a survey with questions about operational experience less than 10 questions - very straightforward have you deployed which version interop issues do you deploy SM and DM and route between them ? also SSM BSR etc then there are questions for implementers (*,*,RP) implemented ? simple and straightforward questions Li (Cisco) : 4601 vs 2362 - this is not a yes or no question also Marshall suggested that the PIM survey ask about IPV6 vs v4 experience Thomas : You should make sure it is confidential ? Jeffery : to recap : Specific feature sets for operators, which are you using v4 vs v6 survey should be confidential and sent to a 3rd party Marshall Eubanks volunteered to be the neutral party Toerless : This should be in two steps - what is deployed should be public, the operators should be more private and confidential Marshall : Ask about Bidir ? [not in this draft] I will look at what is in the draft and comment to the list. PIM ECMP first presented at ietf 80 accepted after ietf 81 changed name to ECMP redirect that's the changes Let's go through the feature quickly current PIM ECMP RPE selection is downstream and uses address caching and cannot consider load and cannot handle sticky PPF decisions no mechanism to "assert" between different paths we designed ECMP redirect message to allow upstream routers to recommend a different path. also, allows downstream routers to consider bandwidth key features this is triggered by PIM joins sent in a different subnet use "non-routing" metrics IANA NUMBERS have been requested not granted yet of course Only HELLO messages can be easily assigned other messages require an RFC authors want WGLC Stig : We only have 5 types, so we need to be a bit careful I would be less concerned for join attributes Dino : My suggestion would be to add an extension type Stig : We may need to think about extending the types We haven't gotten any change requests for 8 months or so for PS Results of hand raise : 4 in favor of WGLC no opposed Dino : Any implementations One Hitoshi IGMP explicit membership tracking function 4 objectives per host accounting reducing number of query messages Shortening leave latencies Toerless : You are not supposed to be changing IGMP behavior when for the test messages ? quite recently, or strung out ? Toerless : It is important to send conventional messages for those that don't support this the one thing that isn't mentioned is snooping ? How do I know if devices are snooping Toerless : No one has shown proof that reducing messages is a requirement Hitoshi : on wireless networks this is important Toerless : then we need to look at what are the goals we are trying to achieve Toerless : if this is important, we should look at in depth and find a solution that would work for everyone Toerless : There is text in the document, but I don't think it's the right text Toerless : We would not need this optimization for the primary use case Stig : This document is informational so as long as it is informational, it is ok to discuss different tradeoffs, etc. Hitoshi : Next steps ? This is informational I would prefer BCP We need some use cases PIM DR Load balancing Sri from Cisco new draft today, DR election is given by DR priority or IP address failover can take a long time as state is rebuilt plus, one router does all the work proposal : use hash function to determine which R becomes the GDR only applicable for the last hop router Limiting it to SM/SSM/DM only new capability : router announces hash masks how do we create the forwarding state? a candidate runs the hash algorithm to determine if it is the new GDR a GDR becoming a non-GDR MAY chose not remove the state, leading to an assert discussion at the mike [including me] - if a router goes up or down, only flows going through that router should have to change question of intended status : experimental or PS ? Mike McBride : Who would support ? 12 pro none opposed Thomas : The draft is suggesting at GDR is used as a tie breaker I suggest that the answer to the 3rd question should be yes Jeffrey Unnecessary upstream traffic scenario # 1 - no receivers dropped at RP should be dropped earlier scenario # 2 this is hard to describe in words but I think it is basically RP on a stick fix for scenario 1 RP HAS (*,G-PREFIX) notification route scenario 2 : RP sens periodic neighbor-specific this propagates until it gets to a router with more than 2 down streams Dino : Is there additional receiver state ? Marshall Does the RP keep state a timer to stop things if the downstream stops refreshing the state Toerless : This can probably all be made to work.. It makes a previously simple protocol, BiDir PIM. and really complexities it. is there a use case ? We don't want to have data triggered events in BiDir PIM So, I have a motivational issue When you have the use case, why not use PIM SM with SPT threshold infinity PIM has been stable for 10 years I need a lot more motivation Jeffery : So far,BiDir pim has only been used in scenarios with receivers everywhere Ice : BiDir only tends to be used with lots of senders, so this won't get used. It seems like we are adding PIM DM into BiDir Greg Shepherd : How would this enable more utilization for BDP? Why would operators care ? BiDir PIM has a specific niche Dino : This is a state bandwidth tradeoff and I think these guys are saying, don't do it. this does feel like dense mode. Greg S : If you can better describe the use case it would help me. # [02:54:24] No. Dino : You are telling him,, don't use BiDir PIM, but he may feel that there is a need for BiDir PIm and thus this as an optimization No one supported taking on the draft. Ice PIM source discovery problem highly redundant mcast network with no single point of failure supporting source discovery this sounds like PIM SSM but source discovery remains an issue if sources are known, SSM mapping is used this focus on a specific situation there is no RP FHR detects a new active source S,G mapping is send using RPF flooding BSR and Auto-RP do this now BSR seems like a logical choice Each FHR connected to a source becomes a BSR router the first packet is NOT delivered SDR depends on it MANY applications do not depend on first packet applications that are could use PIM BiDir Want feedback Thomas : The problem statement is good the tradeoff of not delivering first packet is reasonable BUT, you are triggering control plane events based on data plane events ICE : But the new packets already create new states Thomas : agreed - but you have to damp the behavior also, I don't think that BSR is the solution Toerless : I am motived to see a solution - something like situation awareness in the military, where you don't want RPs BSR is a RPF flooding mechanism Ice : I don't think that we should overload the IGP mechanism Toerless : this is not a multicast specific problem this is somewhat backwards facing Dino : I think it is good to do this at a network layer. I have a database - the LISP database, which need not be data event driven you could inject (S,G) joins and we could make it scale quite well also, you may want to reach AMT receivers not on the multicast network Thomas : Source discovery is done in MSDP and L3VPNs, where it is done with BGP Dino : This would inject data driven events into BGP, and that cannot be good We need to get away from data driven events Stig : Msnip Thomas : BGP would give you congestion control and authentication Siri : WOuldn't this make BSR very chatty in the network ? Dino : If it is trigger based it will be chatty and if it isn't there will be join latency problems Mike : Who wants to take this draft, which uses BSR Dino : Do intermediate routers have to store state ? Ice : no Greg Shepherd : Knowing the scars from certain choices, I am concerned about moving this forward without clear instructions on how it is to be used Thomas : The problem statement looks decent we could separate the problem statement and the solution no consensus was called this will be taken to the list Dino : Multicast only fast reroute idea is to switch tree branches is < 50 msec solution is to use preinstalled branches - no changes to PIM only changes required at the edge