pimwg meeting minutes

Prague, Czech Republic

Tuesday, March 20th, 2007

Created the summarized notes from the audio archives which can be listened to in their entirety at: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf68/ietf68-ch6-tue-pm.mp3

Mike: Welcome, agenda bashing

Bill: AD for few more hours. Both bidir and pim mib approved by iesg in last few weeks. Getting stuff off books that have been languishing. BSR is almost complete as well.

Mike: Thanks to Bill for all his hard work as AD

BSR Draft:

Alex: Received few comments from last rev of bsr draft from Eric Gray and Sandy Murphy. Will talk to Sandy this week, few issues she came up with, will take to list. Lars Eggert: are you allowed to say document updates 2362? It has been obsoleted by new pimsm spec which doesn't contain the bsr. Alex thinks its correct that we say we obsolete 2362.

Bill: Those relationships don't have the meanings we'd like them to. Since its obsolete it may be that it just doesn't matter, you should take out obsolete comments, just pretend this is new.

Alex: Eric Gray had valid issues with bsr state machine and I will update draft to clarify things a bit. Describe the no info state better.

Alex: Eric has issue that scopes could expire before bootstrap timer expires unless timers were constrained in certain way. Have a constraint that its not allowed to happen. State machine is correct. Scopes on timer always has to be higher than bootstrap timer. Scopes will expire a little bit later than if implemented then with default timers specified in current spec.

Alex: There is a timer assoc with group to rp mapping and when that timer expires that mapping is deleted. its not explicitely mentioned anywhere. It could be added to a section that describes how the rp set is received and used by a router.

Alex: Would like to published one more revision then get draft approved.

RPF vector and join attribute drafts:

Arjen: join attributes passed last call, one last Stig comment about adding IANA registry then off to iesg. rpf vector has a few more improvements and corrections then we'll go to last call.

last hop threats draft:

Pekka:recap in hopes to generate feedback. It identifies last hop vulnerabilities and attacks that can be done with vulnerabilities. Last hop between router and host is the concern. Could send unauthorized register message to RPs that may contain spoofed messages and create nasty state. Host may also become unauthorized neighbor. Routers may accept unauthorized messages from neighbors. Unauthorized node could be elected as DR. Mitigation methods: pim passive mode (able to receive and send multicast but router doesn't send hellos on that interface or process pim messages). Possible when you have a single router on a link. Also could use IPsec on a link. If just one router also possible to filter out all pim messages. When multiple valid pim routers on a link, you'll have to use IPsec.

Not much changed since last rev except minor editorial updates. pim spec has been published so this can now proceed. pim passive has been implemented in Junos. Should we go for wglc or have people review doc.

Derek: could you also have pim filter which filters on sources.

Pekka: yes, but you could also spoof the source. The host could send source messages with router. So that might not be good enough.

Derek: we have the capability to filter on source but should also combine that with lockdown of addresses.

Dino: How about having a switch between host and routers. If a switch is connected to a particular host port don't accept pim messages on that port, so router never sees the pim message.

Pekka: yes, that could also be mentioned in the doc.

Pekka: How to procede with the doc?

Mike: revise the doc based upon these comments then we'll issue wglc.

Mike: authors for linklocal draft not able to attend but they are activity working on it and have been seeking and receiving advice from msec.

Mike: rechartering/milestones discussion. sent a proposed new charter, all comments have been incorporated in text of new charter and milestones. Will email ADS and secretariat in a week if I don't hear anything.

Mike: One milestone worth discussion is reducing the messaging of pim. We did have a design team to look into ways to reduce pim messaging. at that time it appeared that a j/p ack proposal was most agreed upon but since then the urgency of it has dissipated and it was thought that it was a bit too complex. There have been other thoughts on how to handle this. We have had plenty of requests to come up with some sort of solution from operators and l3vpn.

Maria: Nothing has been completed on this in pimwg?

Mike: correct

Maria: Something has to be done in this area, particularly in context of 2547 multicast. refresh reduction is critical for scalability purposes. Dont see the problem yet for scalability of mvpns but it may show up and need some sort of solution. Receiver explicit tracking needs to be a part of the solution for aggregation purposes of trees in the core. It has to scale.

Mike: how does wg want to proceed to solve this?

Dino: Do people think this is important for non mvpn environments

Maria: yes. definitely need in core for vpn context, but also needed towards the CE. native ip multicast needs it. biggest impact is in the core.

Dino: let me restate: do you think solution is necessary for a non pe box.

Greg: Marias explanation is still mvpn context. PE to CE is still mvpn environment. The solution would have to be on both ends of the PE.

Dino: If there is too much traffic on the PE-CE link, there is probably too much state on one hop downstream as well. Do your customers have a concern?

Maria: not yey. They do have the choice of bidir to reduce state.

Maria: Only PE, which has many interfaces, is of most importance.

Mike: We have a milestone to get something submitted by end of year. If that doesn't happen, we'll probably need to create a design team.

Mike: drafts have been submitted (not in time to discuss for ietf) to offer other enhancements to pim which fit into our new charter.

Pekka: One clarification needed in the charter which says provide a "more reliable" solution. Propose to whom and by whom.

Mike: I'll change "propose" to "submit".