Minutes pim wg IETF 79 Mike McBride - for whom is this their first IETF ? Agenda Bashing Stig Venaas : First draft is the PIM registry which is now a PIM document this just explains to IANA that we need a registry There is a question as to whether or not we need an experimental type we are going to do another Working Group Last Call on this please speak up. Stig : Next is PIM-PORT This is about PIM Port - PIM over TCP Drops periodic messages and only send new messages when something changes There were lots of wording changes to clear things up There is more text on join suppression, prune override and explicit tracking. SCTP is now preferred over TCP if both are configured. TCP keepalive is in there. Marshall: Does SCTP have a built in keep-alive. ? I think it does, but if it doesn't you need to add that Stig : Correct Mike : How many people feel that this is ready for WGLC? 5 hands yes 0 hands no Stig : Updating rfc 4601 PIM Sparse mode lots of errata - 100 many are really minor the group in Maastrich decided to send this to Draft Standard So, are there multiple implementations? We have someone to take this job So, we want to have a draft by the next IETF Mike : If anyone is interested in working on this please let me know Please look at the errata Stig : RFCs on the standards track start as Proposed Standard and then can advance to Draft Standard and that is what we propose. Mike McBride : The rp-mapping draft is under IESG review Mike McBride : Re Chartering MBONE has traditionally handled multicast protocol work no one wants But, that is OPS SO, we have talked to our AD and the MBONED AD and we want to recharter to take this work. This would mostly be IGMP Behcet : The IGMP tracking draft came originally to MultiMob I think it belongs with us Mike McBride - Is multimob the place to address this? Behcet - yes. for Mobile networks Hitoshi : I am the author of the explicit tracking draft this is not only for mobility at all I prefer to make the discussion in a more general working group Magma would be the best place PIM doesn't include this MultiMob has no charter for extension of IGMP/MLD extension I prefer to do this here Toerless : If something like AMT happened again - it was only in MBONED because we couldn't put in a protocol WG I think that it would be best if MBONED did the requirements draft and then it moved here. Stig : The current proposal is to only do IGMP/MLD here but if there are other proposals for other work let us know Mike McBride : How many people feel that this should be done here ? 13 hands yes 0 no Hui Deng : Unnecessary Multicast flooding We have a camera sourcing multicast 2 switches and a FHR /PIM Router on the edge even if there are no requests behind the FHR multicast still floods to the FHR FHR in PIM SM/DM needs to receive all multicast streams switch running IGMP snooping needs to flood multicast The link bandwidth between the First Hop Switch (FHS) and the FHR can be consumed. If most multicast sources are not requested most of the time this is not acceptable. Problem 2 - outgress cache of switches will be wasted if multicast streams have bursts. Design Goals Switch shall not forward unrequired streams persistently Streams should be terminated at the right switch. Solution profile FHR sends PIM prune messages towards switches If switch finds upstream is not its pim neighbor, it creates a (S,G) with a pruned port. Stig : Prune message is unicast so one message is sent to source and switches snoop it ? Hui - Yes Pruned port's lifetime is 1/3 of the S,G entry lifetime Toerless - this is a revival of MSNIP Stig : Msnip works at the source [Marshall - discussion about "pruned port" which does NOT refer to port multiplexing] Toerless : IGMP switches always flood right now Dino : This would override the flooding Toerless - this only works for SSM Dino : you can bring L3 all the way to the source Hui Deng - we got comments Why not let FHR send IGMP join / leave messages - switch will not forward How about static configuration ? - not flexible How about sending unicast IGMP join / leaves ? Why not let first-hop switch stimulate the IGMP querier? - If two or more switches do this,. problem would still exist PIM Switch entry has to be in the hash version of the switch Toerless : We have two questions - whether or not the router does this with PIM or IGMP (as with MSNIP). Second is how to stop flooding inside the network I would prefer this to be 2 drafts Hui Deng: - Without a refresh mechanism there is a problem FHR can send PIM message but there needs to be a join / prune message Toerless - this is interesting in IGMP proxy routing this also floods So this is another argument to do this in IGMP rather than PIM Stig : How many think we should work on this? 7 yes 0 no Mike McBride : We need to talk about this more Marshall: This has to NOT break things if every switch does not support it Hui Liu : SMFRR Fast Re Route problem : Multicast FRR is to speed up the switch over several proposals, each with advantages and disadvantages Multicast FRR does not rely on Unicast It uses PIM primary join and secondary join to set up primary and backup paths Introduces a new attribute 2 options Option 1 - disable root node only Option 2 - disable both paths By precise control it is possible to apply [protection to complex multicast topoloy Faults can be detected by a number of options option 1 - only root needs to be notified option 2 - each backup node needs to be notified Fault notification tree needs to be pre-estalblished MFRR attribute described Should this be adopted by the WG ? Marshall : In option 2, how do you know what the backup nodes are? Is that configured or what? Jeff Tantsura : What is the problem you are trying to solve ? Mike McBride: There are a couple of proposals to solve this multiple steams sent through the network Jeff : I think that this is pretty broken Q? This is like constrained base routing, When things break this could set up loops and the like. Dmitri : A suggestion - what happens if a branching node fails ? I don't think this is discussed What happens with node failure versus linkl failure ? Dimitri : This could be even more complex in the context of node failures Liu - there is an option for multitree protection Dimitri: do you mandate that the two trees are entirely disjoint ? Mike McBride : Who feels that this should be taken on here ? 5 for 10 against Marshall : Should there be a requirements draft ? Dmmitri : It might be useful to have a presentation of the RTG-WG framework on this Mike McBride : ietf-pim-mtid was updates we will be issuing a WG last call when this is updated.