[12:12:45] psavola joins the room [12:20:15] psavola leaves the room [12:49:38] jsimbol joins the room [12:50:04] astaikos joins the room [13:10:08] marshall joins the room [13:10:20] Starting the PIM meeting [13:10:27] jwatwood joins the room [13:10:43] Stig : Status - Link Local draft is with the IESG [13:10:54] hopefully there wil be a new version in a few weeks [13:11:02] other 4 adopted drafts [13:11:10] all with short presentations [13:11:16] About link local [13:11:29] AD comments received [13:12:14] We have 3 documents where the author's couldn't make it [13:12:31] Link Local is just about ready for a new draft [13:12:41] they are trying to make it work in practice [13:12:49] with XORP and CISCO [13:13:02] two more orless independnet implementations [13:13:13] all the magic is in IPSEC no changes to PIM ] [13:14:01] Question from Adrian about standards track versus experimental [13:14:14] Stig : That was the idea about [13:14:22] 2 implementations [13:14:30] Any comments ? [13:14:32] No [13:14:35] [No] [13:14:52] Stig : Next is group to RP mapping [13:15:03] David McWalter : [13:15:24] PIM has a number of ways to give a router with an RP [13:15:44] if more than one is running, they all need to give the routers the same RP [13:15:51] there was no protocol to do that [13:15:59] this is a bit of an edge case [13:16:04] or corner case [13:16:25] We are proposing a MUST run algorithm to clear up corner cases [13:16:44] we are not mandating which mechanism operators use [13:17:07] this is just for the cases of multiple overlapping [13:17:13] protocols being used [13:17:42] A recent decision on BSR hashing. We proposed to remove thjs [13:18:04] but it turns out some people have implemented it and do like it, so this will be changed [13:18:08] any comments ? [13:18:39] Wolfgan Beck (remote) joins the room [13:18:41] Without any comments this should go to WGLC [13:18:47] Wolfgan Beck (remote) leaves the room [13:19:02] Stig : How many people feel that this is ready for WGLC ? [13:19:10] [No one raised their hands] [13:19:31] [but no one has problems] [13:19:41] Come to the microphone!!! [13:19:42] Stig : We will check on the list [13:19:49] who ? [13:19:54] any speaker. [13:19:59] I can't hear them [13:20:49] OK, I asked for that [13:20:59] POP COUNT draft (presented by Stig) [13:21:01] 2 changes [13:21:12] - use new PIM join attribute format [13:21:24] - minor change to flags [13:21:58] Join attribute mechanism is a new way of encoding data in the join mechanism [13:22:33] please have a look at this [13:23:03] The IANA considerations have changed as there is a HELO option [13:23:40] Dimitri : Can we make sure this attribute is not triggering any other join messages [13:23:52] Stig : That should be clarified [13:24:44] Dino : The only issue is, what's the processing time. We don't know yet. With implementations we will get experience [13:25:00] Dimitri : There might be refresh or retrigger issues [13:25:21] Dino : I hope it is clear that this should not affect how to trigger. [13:25:40] With PIM over TCP with incrmenental updates, what do you do ? [13:25:54] Two separate designs are going on at the same time. [13:26:11] Stig : There could be issues with messages getting too large. [13:26:50] Stig : I will present the last update to reliable PIM [13:27:08] Use TCP or STCP for join messages [13:27:19] so don't need retransmissions [13:28:15] The main change is that you don't just switch between datagram and PORT Join / Prunes, but stick to one configuration [13:29:03] the old way, you start with dtagram, move to tcp, and maybe go back to datagram [13:30:02] Now, add HELO option to signal PORT versus datagram options. MUST use PORT if enabled. [13:30:50] If you are losing packets, both PORT amd TCP are not likely to work [13:31:19] Another change : Only one join prune message per PRT JP header [13:32:52] Dimitri : Is this going to be used for MTIIU ? [13:33:11] Stig : It is interesting to see if this should be in spec [13:33:36] Stig : Another change is to genid [13:33:55] used to say, every GEN ID change meant a new TCP session [13:34:18] Now, if GenID changes for ALL neighbors, reset [13:35:08] there are cases iin PIM where you have to ignore a message [13:35:29] for example, if 2 routers do no agree on the RP [13:35:49] So, what to do ? Still an open question ? [13:36:21] Now, draft just suggests ignore and cache it [13:37:49] Jakov Richter : I think that there are things here that are outside of scope - everything that is L3VPN related and take it L3VPN working group [13:38:19] Dino : I fully agree [13:38:28] Yakov : Good [13:39:03] Yakov : Now, I find explicit tracking to be confusing. [13:39:25] Is OIF equal to neighbor or not ? [13:39:46] Dino : We don't want to support PORT over multi-access networks [13:39:59] Yakov : What about MBNA ? [13:40:24] Dino : There is a discussion of a collection of point to point links [13:40:38] Yakov : Then you should spell that out [13:40:45] Dino : It says that [13:41:16] Yakov : No, it says per interface. Just spell it out, [13:41:51] If you have PORT and you don't want to track per neighbor you have specify it [13:42:00] the MDT case ? [13:42:10] Dino : the MDT case ? [13:42:25] Yakov : That has to be spelled out explicitly [13:42:47] Dino : Yakov, can you help us form the text ? [13:42:53] Yakov : Yes [13:43:03] Stig : Next is Dimitri [13:43:12] PIM MTID [13:44:08] Dimitri : Want to see if there is WG interest in documenting ths [13:44:17] Point of concern is transient loops [13:44:50] two MDTs can co-exist at the same time [13:45:15] transient loop conditions [13:45:48] traffic diversity cannot be enforced by MTID [13:46:15] topological diversity cannot be enforced by MTID [13:46:38] The MTID CAN enforce known MTD topology [13:47:11] i.e., the static case [13:47:20] the loops are always transient [13:47:44] So, questions [13:47:53] Can we document loop conditions [13:48:04] and specify mitigation means [13:48:42] this would not require a change to PIM- MTID [13:49:07] the second question is, should we have a new I-D to specify mitigation means for this [13:49:17] Any questions [13:49:40] Thomas Morin : Is what you have explained specific to PIM MTID [13:49:56] Dimitri : Of course, the problem is generic [13:51:14] Thomas : If we have loop conditions we have the sam issues [13:51:38] same issues without PIM MTID [13:51:42] Dimitri : Yes [13:51:52] It is improtant to document this [13:52:18] Stig : It would be great to get some text fromt he authors on this [13:52:27] and it may be worth a separate document [13:53:08] Dimitri : My opinion [13:53:36] is that the document is focused on passing information between two neighbors [13:53:46] Stig : It's worth documenting it somewhere [13:54:12] Stig : Next and last is MLDP [13:54:37] I am just a presenter [13:54:58] want to transport global multicast traffic over a MPLS core [13:55:15] no need for L3VPN proceedures [13:55:56] solution : multicast tree information like (S,G) is encoded in the opaque field of the mLDP [13:56:48] mutlcast routers as if it were a pim join [13:57:12] Stig : just as a point, this draft is not intended for PIM [13:57:16] Marshall : Which one ? [13:57:22] Stig : MPLS [13:57:50] Presenter : Each IP multicast flow creates an unique ? in the core [13:58:09] To do this requires 4 new opaque encodings [13:58:26] ipv4, ipv6 and bidir ipv4 and v6 [13:58:39] scalibility is important [13:58:53] each IP multicast flow maps to a LSP [13:59:21] marshall leaves the room [14:00:52] jwatwood leaves the room [14:01:05] astaikos leaves the room [14:01:56] jsimbol leaves the room