pim WG minutes Anaheim Tue Mar 23 1300-1500 Chairs: Stig and Mike Meeting opened at 1307 (because we had some sound problems) draft-ietf-pim-group-rp-mapping-03 Andy Kessler ================================== Andy described the history of the PIM group mapping issue, going back to the discovery of the issue in PIM-MIB. Andy described use cases motivating a standard algorithm. Andy went through changes in the -03 draft. In particular, filtering at the network edge is now viewed as the way to enforce policy. The proposed algorithm is designed to be consistent with most PIM implementations our there today. Andy described the matching algorithm. Andy points out that much of the algorithm is assembled from existing RFCs. PIM-SM, BSR, and so on. Someone asked about the hash function. Andy answered that this is the existing hash function defined in RFC 4601. Toerless asked how this lines up with the MIBs. Andy said there's text in this draft that deprecates the preferences from the MIB. Wison(?) Li asked about overlapping group ranges for auto-rp, is there a hash function for auto-rp? Yiqun answered that if multiple RPs are defined for the same group range, only one is selected, so no clash is possible. Andy described how the algorithm works for auto-rp. Thomas Morin asked why the hash function is not used for bidir. Andy answered that mapping would need to be done on the fly as data packets arrived. Stig said the hash function isn't used for bidir, and hashing isn't mentioned by the bidir spec. Isidore confirmed that hashing is not done for bidir because of inefficiency in forwarding, perhaps there is some text on this in the bidir spec. Andy agreed - "this is what I was trying to say". Thomas thinks this should be documented somewhere. Andy agreed we could add text to clarify that, but we'll check if it's specified anywhere first. Bill Fenner says the BSR RFC talks about transporting the hash around and doesn't say what to do with it. The implication is that if you're doing SM you can use it. Yiqun says if we do add that text (his phone sang "I'm a little teapot short and stout" at this point) Yiqun said that (*,G) hashing is possible, and he knows implementations that have done hashing in this case. Whatever text we come up with must ensure that routers select the same RP. Yiqun suggested we would not be able to come up with a method that was 100% back-compatible, so perhaps we should look at work-arounds for this. Andy will think about this and put something on the list. Mike asked if this draft was ready for WGLC (Mike's count - 11 hands) Mike asked if anyone thinks it is not ready (Mike's count - no hands) Mike said we'll take this to the list and perhaps do last call in a week or two. draft-ietf-pim-mtid-03 Yiqun Cai ====================== Yiqun presented updates made since the -03 draft. One major changes included when conflict resolution rules are applied. Another was in response to a comment from Thomas, to allow an upstream router to altogether ignore the incoming Join if MT-ID doesn't match. Yiqun thinks the draft is ready for WGLC, and asked for comments. Thomas talked about the new text to avoid loops, he had one nit - if a router has local configuration that is different, then it perhaps should be considered a conflict. Yiqun said that local configuration should override the join because if routers are upgraded to support MT-ID from the outside in, then routers can still build the trees. Otherwise incremental deployment will not be possible. Yiqun agreed that it could be an option to treat this case as a conflict. Toerless drew an analogy, Yiqun agreed with it. Mike asked about resolution of Dimitri's comments from last time. Yiqun described conversations he has had with Toerless and Dimitri. The resolution is that if a router doesn't like a join attribute, it can ignore the join altogether, rather than just ignoring the attribute. Yiqun believes that Dimitri's comments have been addressed. (Dimitri is not present in the room.) Mike asked if this draft is ready for WGLC. (Mike's count - 10 hands) Mike asked if anyone thinks it is not ready (Mike's count - no hands) Mike said we'd take this to the list. draft-ietf-pim-pop-count-02 Yiqun Cai =========================== Yiqun has just updated this draft to make sure it is not expired. But Yiqun plans to change the packet format to make it more extensible, and to make it compatible with pim-port. Yiqun said he hopes to have a revision in good time for the next IETF, to give folks a chance to review it. draft-ietf-pim-port-02 Stig Venaas ====================== Stig described changes in the -02 version. Stig said there has been a question from Thomas Morin about the tracking support flag (disable join suppression). Stig described how messages are not broadcast (they're over TCP) so there will never be prune override or join suppression. So there is no action required here. Thomas agreed that the document now looks reasonable. Stig said that another of Thomas's comments requires some explanation - he's add a sentence to describe what will happen when a pair of neighbors both support TCP and SCTP. Stig plans to submit and ID in a few days adding text on this second point. Stig then thinks it is ready for WGLC. He'll leave this to Mike though. Mike asked whether there is anything that needs to be added to the draft. Stig confirmed that he'll just add a sentence saying that SCTP is preferred to TCP. He is happy to do this as part of WGLC updates, or generate a revision before. Mike asked if this draft is ready for WGLC. (Mike's count - 5 hands) Mike asked if anyone thinks it is not ready (Mike's count - 1 hand) Mike said we'd take this to the list. It's not unanimous, it's probably rough, but we'll take it to the list. Mike encouraged Lenny (the one vote against) to take any comments he had to the list. draft-xu-pim-drpriority-auto-adjustment Xu Xiaohu ======================================= Xiaohu described the problem of a failure of an interface at the DR, which is not handled by the PIM spec. Xiaohu described possible solutions and their disadvantages. Xiaohu described the proposed solutions of varying the PIM DR priority when connectivity is lost, perhaps by coupling it with VRRP. Yiqun is not sure that this is the right thing to do in practice. You only need the DR change if you don't want the downstream LAN (that the DR is still connected to) to be transit. Yiqun suggests that to enforce this restriction, then the router should run IGMP proxy rather than PIM. Toerless said that IGMP proxy is not defined in a redundant setting, so it wouldn't make things simpler. Yiqun said that we're not running RPF in this case, if we were then the failed router would just re-route (across the listeners' LAN). If we're not routing then we don't need to run PIM. Yiqun would rather see this discussed in a different context, rather than as a modification to PIM. Lenny asked whether this could be done by the implementation, why does it need to be specified? Toerless asked whether VRRP was standardized for this... Lenny said the VRRP spec doesn't include a description of how to use it for tracking (the only instance of the word "Track" is "Standards Track".) Toerless asked if there is any description of tracking in the IETF, seeing as we couldn't find something? Mike is sure that this would be defined somewhere, and thinks Xiaohu needs to find out. Mike personally likes this solution in PIM, but it could be done in a particular implementation. Thomas said it's very useful to document things, even if they are just for particular implementations. Toerless asked if Informational would be acceptable, Thomas had no strong opinion. Mike asked if this draft should be adopted, is this something we should address? (Mike's count - 2 hands) Mike asked who thinks this should not be addressed here (Mike's count - 8 hands) That's not a good sign, says Mike. Stig said that even though the room is negative, this should be explored on the list, where there might be other opinions. draft-venaas-pim-registry-00 Stig Venaas ============================ Stig noticed a couple of months ago that there is no registry for PIM messages. For historical reaons there are some PIM messages in the IGMP registry. Stig put up the current PIM messages, and the RFCs that assigned their message types. Stig also suggested we should restore a reserved message type. Stig suggested that the mechanism for assigning message types in this registry should be "IETF review". There is only space for 4 more messages, so we need to be very strict about adding new message types. 11 of 16 types have been used. If we reserve type 15, then it provides options to add new message types. This is not in the draft yet. Stig thinks it is clear that a registry is needed, but asks whether "IETF review" is too liberal or too strict a rule. (Adrian indicated from the floor that it is not the strictest rule). Stig asks for WG adoption, perhaps it is ready for last call already. Adrian asked for thoughts about experimental message types. Stig replied that the space is very small, but it might be useful. Is one single message type enough? Stig is reluctant to assign one. Adrian clarified that if two vendors have separate experiments, and then they get run in the same place, then it goes pop. That is the idea, in order to discourage people from deploying experiments. Stig asked if this draft should be adopted. (Stig's count - 17 hands) Stig asked who was against. (Stig's count - 0 hands) Stig said we'll confirm this on the list. Stig then asked if this draft should be last called immedaitely after adoption. (Stig's count - 16 hands) Stig asked who is against. (Stig's count - 1 hand) pim errata Stig Venaas ========== Stig said that there are 110 errata on the PIM spec, which is pretty scarey. 17 have been rejected, 91 are "held for document update". Stig split these out. 53 are editorial (more or less). There are 6 about brackets for ordering of operations. There are 6 on security, which are interesting, link- local security is already being worked on. Stig suggested that documents could be created to discuss aspects of PIM security. Bill Atwood mentioned that is going to happen in KARP. Stig looked at some clarifications, which might be worth doing if people didn't get it. Stig talked about a more serious comments on figure 5, in the (S,G,rpt)-state machine. Actions on (S,G) joins should override, much like (S,G,rpt) joins are documented to do. Stig suggests there might be issues if you don't. Stig then put up a dense slide on section 4.5.4, which he doesn't quite understand himself. It might lead to two PIM neighbors periodically joining with (S,G,rpt) state pruned, and then the other overriding. Stig said that it looks pretty bad just looking at the numbers, so people are persuading him to do something. Perhaps we should do a new version of RFC 4601. Stig encouraged people to take a look at the errata, and see if they need something doing about them. Toerless pointed out that there don't seem to be any SSM errors, and anyone wanting to do just SSM has to dig through the whole document. This would be a good enough reason for Toerless to crate a new document, to split the SSM stuff clearly out from SM. Stig's personal opinion is that the Errata are not as scary as they seem from the numbers. Yiqun thinks we should document the implementation experience with RFC 4601 before we think about doing an update to it. Stig asked Adrian (AD) whether people sometimes do an update just for minor and editorial issues. Adrian said "yes". Adrian said that the IETF chair (who is his boss) periodically goes through the lists, and chases to get errata rejected, verified, or "held". He then sees "held" as an intent to update the document. If they were "verified", then he would be off our back. As does another AD. Do we actually need to do anything? No. But consider you were coming new to PIM, and you wanted to implement, and you didn't know which of these you had to pay attention to. Is this consistent with us facilitating interoperable implementations? Mike asked if a document describing what the errata are would be a good thing. Bill Fenner thinks this would be way worse, that's not any better than "read RFC 4601 and the RFC editor page together." If we're going to publish anything we should just update RFC 4601. Bill said that going through this review process is very painful, and people will want to make other changes while it is being updated, and that will be another 3 year process. Back to big long lists of "holding for document update". Most of them are tiny things that hardly matter. They largely don't block creating interoperable implementations. I felt like rejecting some of them, but I felt sorry for people who had read the whole document. Bill said that he'd be willing to do the typing work of making updates, but he is scared to death of review and feedback and getting it through the IESG another time. Adrian said we could work on the IESG, saying the WG is only prepared to do this if the IESG promise only to object to the changes, not to the unchanged parts of the RFC. Adrian asked if there is energy just to fix the typos. If there is no energy, draw a line and move on. Stig thinks if we can keep it minimal, we should have enough energy. Toerless doesn't see the value in that, what precedents are there for just updating documents to fix errata. Bill Fenner said that this is a fairly new process, so there aren't really precedents. Eric muttered into Adrian's ear that charter might be a way to handle this - if the charter says the group is just handling the update and not any other changes, then the group is scoped and nothing else can be done. Eric agreed, nothing is going to fail to interoperate just because you've failed to fix one of these errata. Stig asked if we should do a minor update just to address the errata. (Stig's count - no-one) Stig asked if it would be a bad idea to just leave it and not do any updates (?) (Stig's count - 2 hands) Mike has heard that if the PIM WG isn't prepared to address errata, then it shouldn't take on new work. Mike and Adrian agreed that they should talk. KARP and pim Bill Atwood ============ Bill Atwood introduced KARP, which had its first meeting this morning. Bill explained the history of the work and the background to the formation of KARP. Bill said that a major theme is the roadmap for going from the current state of unauthenticated communication, or one-off manual keying of each router, to a state where everything is automated and state-of-the-art. We can't go from here to there overnight. Bill described the two main options, firstly change everything to run inside IPSec. Secondly change slowly, accept what is there and strengthen it and design mechanisms to make it easier to manage. Bill mentioned that these slides reflect his opinion last night, but that as a result of KARP discussions he would have to change them slightly. Bill said that KARP will gradually work its way through the routing protocols as we find people who are interested. Teams will be formed including people with security expertise and people with expertise in the routing protocols. Bill said that in the past routing WGs have avoided working on security because it wouldn't be good enough for the security people. The security ADs have now agreed to accept less-than-perfect solutions, at least initially. Things should get better as the KARP project creates models that can be re-used. Toerless said that PIM isn't routing, it is a tree-building protocol. Routing has a problem in that the same routing might be needed to make the keying work. So please make sure that key distribution only depends on unicast. Toerless said that PIM was later than the IGPs and was forced to adopt IPSec and replay protection, the 4601 that we have says how to use IPSec for IP security. Bill said these statements are very weak Toerless said sure, but these are far better than in unicast routing. Bill was not sure he understood Toerless' question. He doesn't see this as requiring a new approach to PIM. KARP is committed to accepting what is already there. Stig mentioned that PIM relies on unicast, so it can't be more secure than unicast in most ways. PIM should be about as secure as unicast. Bill said OSPF does a lot of multicasting to neighbors, and PIM does everything that way. So anything that is done for OSPF should be useful for PIM. Mike thanked Bill for "watching our back in KARP". Mike will talk to Adrian about common work with other working groups. Meeting closed 14:50.