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