PIM Meeting IETF 66 3:10 PM July 12th 2006 Chair(s): Tom Pusateri Mike McBride Routing Area Advisor: Bill Fenner pim draft status/rechartering/milestones 10 min Tom/Mike draft-atwood-pim-sm-linklocal-01 10 min Bill Atwood Salekul Islam draft-savola-pim-lasthop-threats-01 10 min Pekka Savola draft-hoerdt-pim-group-unreachable-00 10 min Stig Venaas pim-bsr-mib 10 min Bharat Joshi ----- Agenda Bashing. Tom : We have 3 documents in the RFC editor queue that are coming out soon, in the publication requested state. Existing work is the BSR MIB. We have decided to adopt that. There is the RPF vector and the PIM attribute draft. Mike : Those both need to be updated before they time out. Tom : There are 3 new drafts that need to be considered today. Mike : A few comments about the PIM Charter - there is a portion that is where were are at now - to decide whether there is a need for a version 3. Tom and I are of the opinion that there is still work to do. [apparent consent] So, we need to re-charter. One thing is here on the screen [to address PIM enhancements for multipoint label switched solutions]. Bill Atwood : This is about how we secure PIM messages. PIM draft says use AH with manual keying and anti-replay. But IPsec says that you can't have anti-replay with multicast. IPsec with 4301 no longer supports per-interface. Who is talking to whom ? If I am a router, the messages go to ALL_PIM_ROUTES, so it looks like a ASM group, but it is really a collection of SSM groups. We have two choices : Declare that when these communications are done by IPsec they are done by SSM, or The AH Spec says that anti-replay SHOULD not be done with multicast AH. That could be changed. Dino : Calling it ASM or SSM adds no value. This is link layer, and it's not an SSM group or an ASM group, it's done at a lower level. Bill : That was part of our thinking when we picked IPsec. Bill : We are prepared to work on this if the working group is in favor - I will produce a draft 02. Toerless : You are saying that you have a separate sequence number space for each neighbor but one key for all of them. Bill : You are going to manually set up the keying. Dino : You will probably not want to configure it per peer. Toerless : Can you compare this with GDOI [?] ? Bill : My reading of GDOI is that there is a lot of weight there that you don't need. Toerless : How is this any different from any other protocol that uses link local multicast ? Bill : I don't know. Tom : My thoughts are that MSEC is more about securing data. I think that this squarely fits within our realm. Toerless : Is there any reason why this should be tied to PIM ? Tom : Most likely not. Toerless : Then don't make it specific to PIM. Pekka : From that perspective it might make sense to get it reviewed from Msec. Bill : OSPF just did this with OSPF v.3 They have done some of this work and we may be able to leverage that work. This work might already be done. Toerless : Maybe they only did it for OSPF. Bill Fenner : Each of these protocols has different interactions. You might leverage bits of the protocol that you need but it wouldn't be universal. Toerless : I would prefer one solution for any protocol that uses link layer multicast. Dino : I think that the only way to solve this is with an encapsulation layer. Then it's one solution it's implemented once and every protocol can use it. Rather than saying, everybody can use AH, you should actually implement it so that everybody can use it. That should be your compelling point [laughter]. Pekka : Last Hop threats to PIM. This was put on hold waiting for the PIM spec. I noticed that there was not an analysis on last hop threats on the LAN : Nodes might send unauthorized (unicast) register messages They might become unauthorized PIM Neighbors Routers may accept PIM messages from outside. Non-routers might become the PIM DR. The threats may be DOS too. Mitigation methods are PIM "passive mode", ignoring PIM traffic on a link, using IPsec, and IP filtering of PIM messages. With multiple PIM routers on a link, you will have to use IPsec between them. Now the question is what we have to do about it now that we are rechartering. In many deployments, IPsec is not that much used. Options are an informational RFP, part of a new PIM-SM spec, or let it remain dormant. Tom : If we ever rev the spec again, this could be included. Pekka : It's not sure that this should be added to the draft if it is ever revved. ----- Simple Join Failure Notification : Stig Venaas Stig : The authors could not be here so I am presenting for them. If you do not receive multicast it is hard to identify why you do not receive data. The idea of this draft is to send a message downstream if a join fails. If a join fails, the router sends an ICMP message downstream to the complete OIF, and it flooded down the tree. A typical problem is that a router tried to get multicast and it failed, so that you would have information on what happened. If this is propagated all the way to the end host, it could be used by the user for debugging. The draft talks about how you might have one message with several errors. Messages should be rate limited. Dino : One thing is that joins might be sent and never received. Stephen Casner : You said that the routers should log this ? Stig : The last hop router could log them. Toerless : There are some fundamental problems. You are multicasting the error but there is no indication as to when the error is repaired. Also, this is very much tied to the PIM state machinery. This needs to be a PIM extension. Stig : This was intended to be for PIM, but ICMP was used to that they would go down to every Toerless : What does this give you that you would not get from multicasting syslog messages. Stig : But it doesn't work interdomain. Toerless : What does it help to have it multicasted to a million people ? Stig : The network operator could decide whether to propagate this or not. Toerless : In the early PIM discussions we asked whether or not we should have PIM Dave : Are these sent as Link-Local ? Stig : It should be link-local. Tom : Before this if people did a join and then did get it then they I don't see a problem that this solve that Mtrace doesn't solve. Stig : I would be very happy if Mtrace was implemented everywhere. Tom : Creating a new protocol doesn't get it implemented any earlier. Tom Narten : I think that having ICMP based notification makes sense, for the last hope. Pekka : I think that the last hop could be dealt with. Would a join ACK solve this problem ? Stig : It's not communicated going back. Bill Atwood : If I am a bad good actor and join groups that don't exist, do we want this ? Dino : Most people turn off ICMP unreachable. Why not just send heartbeats from the source ? Stig : You don't know where it's broken. Dino : Users don't do that sort of debugging. Tom Narten : The type of errors should be limited to non-transient errors. Stig : It would be useful you had join attributes to do this. ----- Bharat Joshi PIM BSR MIB : PIM BSR MIB was taken out from PIM MIB - we wanted to put this on the fast track - I made a few changes - I wanted to add scopes and zones to the tables - I want feedback on how exactly these tables could be made so that we could add them. Stig : The main issue is, could a single router belong to several zones for the same scope ? Bill Fenner : You might have the same group range for 2 different zones on the same router. I think that the RFC 4001 zones are not quite a match for this, but I think I need to think about this more. Toerless : I thought that we didn't want to have different zones on the same scopes., Dave McWalter : In the Multicast MIB, single zone scopes is how we did it for PIM - given a scope, you should get an unique zone for the scope. I think that a 32 bit zone ID is all right. I think you are right that we could put a 32 bit identifier. Bill Fenner : I am still having a little trouble thinking about this. In IPv6 scope boundaries are inside router - the architectures are different for v4 and v6. Bharat : I think we need to take it to the list. ------ Tom : Potential work is these 3 drafts, maybe hard state to stop periodic joins, multicast over point to multipoint LSPs. Pekka : The most important thing we should be doing with PIM is to improve its management ability. Dino : I had a draft called PIM population count which propagated population information. Greg : The last hop is not going to care about the work presented here. Pekka : I thought that population count was more of an accounting feature. I would like to see the reliability of PIM improved. Gaurab : There are a couple of drafts on multicast over point to multipoint LSPs - now it's more mature. We understand the applications rather well, and we have deployment experience. It's not clear that the MP2MP-LSP draft needs to be resurrected. The PIM remote neighbors draft might have applicability. PIM Snooping, we need to decide whether it needs to be done here or in L2VPN. Toerless : When we did IGMP snooping it could only be informational - has the IETF changed ? Gaurab : You bring up a good point. Toerless : If you bring up a standard that has normative [?]. Gaurab : PIM snooping is not spelled out. Bill Fenner : IGMP snooping was about the behavior of devices that weren't IETF layer devices. Dino : But the IETF has broken that rule many times. Bill Fenner : I think it would be a hard sell. Dino : If PIM snooping required changes to PIM does that need to be done here ? Toerless : We did RGMP as informational because it wasn't clear if there was interest. Gaurab : IGMP snooping is widely deployed. Tom Narten : We have to keep in mind that snooping is a tradeoff and it would be better to have clear protocol for communication between layer 3 and layer 2 devices. Toerless : The layer 2 stuff is driven by making the Unicast simpler. Tom : Now we have more foreknowledge. Pekka : You mentioned that RGMP wasn't successful - that may or may not be related to the fact that CISCO claimed IPR on it.