Meeting of the PIM Working Group at IETF-65 in Dallas, Texas, Tuesday, March 21, 2006 Chair(s): Tom Pusateri Mike McBride Marshall Eubanks [Scribe] Agenda : Agenda Bashing and General Status Discussion Mike draft-ietf-pim-sm-v2-new-11 Bill draft-ietf-pim-proposed-req-02 Mike draft-ietf-pim-join-attributes-01 Arjen draft-ietf-pim-rpf-vector-01 Ice draft-ietf-pim-mib-v2-05 David draft-ietf-pim-sm-bsr-07 Stig Mike McBride : Anycast RP has passed through the IESG, but it may take a few months to get an RFC number. Regarding the BiDir draft, I don't know if there is anything that the WG has to provide. Bill : BiDir was really waiting on the Sparse Mode draft to be done. Now that the Sparse Pim Spec Status : The new draft was submitted yesterday, and it was approved by the IESG today. Bill : As you know, this was a multi-year effort. I dumped the data from the drafts. Most of the work was in the first 3 months, and the rest was in the next five years. It took a looooong time to do the last little bit. This is just a general IETF lesson. This is how things tend to work in the IETF. Beau Williamson : We approach the state of being done asymptotically. Bill : We still have a file with 80 issues in the spec. It could always be better. Dino : You had 100+ pages in 6 years. In anycast, we had 9 pages and it took 3 years. Pekka : The ID tracker for BiDir says that it is waiting for an implementation report. Mike : I believe that that was done. Bill : I will look for it. Arjen Boers draft-pim-attributes Arjen : This has already gone for last call. It started out as one draft - based on comments, it was separated into 2 drafts. draft-ietf-pim-join-attributes-01 Went through last call and received some more comments. In Vancouver, Tom Pusateri said that he had a counter-proposal, but he hasn't sent one yet. Mike : I synced up with Tom and we were in agreement that this draft should proceed to WGLC. His draft is based on not using PIM in the core. The idea is that if you don't have BGP in the core, why would you want PIM, it should all be done in MPLS. Stig had some issues raised after the last call, but I think that these can be resolved without going through LC. Stig : That sounds good to me. Mike : It sounds like your draft needs one more revision, and then we can proceed to the IESG. Pekka : At what point do we need to start the implementation report ? Mike : I don't know. That's a good question. You can't start too early. Bill : The only thing that you have to watch out for is if the spec changes after you do the implementation report. Dave McWalter : We have just been through a WG LC on the PIM-MIB draft. We have updated the traps, we have added some dense mode objects, but the last call passed pretty much without any comments, so I think that the WG is about done with this. Mike : Of course DM is experimental, so we don't know how the IESG will react to that. Dave : The WG resolution in Paris was that we could include DM if it wasn't a hassle and it was simple, so if it isn't, we can re-evaluate it. ------ Stig : The BSR Spec. The ID has been updated to 07 a few weeks ago. I think that I have resolved all issues. We also did changes to reflect the input from the previous meeting. It was suggested to have a default priority for BSR, and that it be fairly low, so that it wouldn't cause problems. The one we picked was 64. There was discussion at the previous meeting about hold times. You should be able to use very short hold times. Now it says that the holdtime MUST be > the Bootstrap period, and should be > 2.5 times the hold times. Another thing pointed out was that if you adjust the priority of the BS, then it's important that these BSR are forwarded. There are also some corner cases where it's useful to have a pending BSR. This is useful if there is some packet loss Dino Faranacci : I'm worried that if you send the unfavored ones then the BSR is going to go crazy. I also did some changes for unicast BSMs. We changed the checks. For IPv6 this forces the use of link-local addresses. We also specified the use of ttl 1, but then we thought that maybe we should use TTL of 255, so that you could tell if you were getting stuff from multiple hops away. Pekka : Is this going to work with old implementations ? Stig : Currently the TTL is unspecified. Dino : We have been prototyping this and there have been some rare conditions, where data packets are lost because of the interaction of ARP and BSR. You might also want to specify, is it the DR that sends the message ? Stig : In the previous revision, we added some stuff about triggered candidate ZRP advertisements. It's very important for a newly elected BSR to have some idea of the candidates. Then we did some router alert changes. For IPv6, you have values saying what type of router alert. So, for IPv6 we would have to get some values from IANA Router alerts were not done in the previous draft. For multicast messages, there is no need for it. With router alerts, you could also filter these on your boundaries Pekka : From a protocol design standpoint I would love to see router alert go away. Dino : I second the motion. Nidi Baskar : The original spec didn't have router alerts, so there is no interoperability considerations. Stig : We also tried to clarify the language and fix typos and minor things. Last, I want to talk about Fast BSR re-election, which was brought up at the last meeting. You can easily do a 3 second re-election using short told times. It's not that unlikely, if some RPs go away, that some BSRs go away as well. We haven't tried to add this to the spec, and it could be done in another spec. However, if there are other changes to the BSR spec that could make this easier, maybe it should be considered. Dino : Don't you think that the elected BSR, once it hits 255 [cross-talk] Nidi : That makes a bunch of assumptions, that you start at 64. Stig :: We are fixing this. I agree, it's unlikely that we reach 255. Nidi : Even if we figure out ways for candidate BSRs to override it, we still haven't figured out how they can determine when the elected BSRs have gone away Stig : Except for this, we have solved all of the issues that we are aware of. Can we go for a last call ? Mike : Are we in agreement to not include the BSR fast election. Pekka : Are we targeting PS ? Stig : I think so. Mike : I think so. Pekka : Then, we need to figure out when to stop. Nidi : We are starting to work on the protocol and we are implementing it. So, I say, let's move forward. Stig :: My opinion is another draft fixing the issue with the hold time of zero, and then go to last time. Mike : I think it would be worth going to last call at that point. Pekka : I just realized that the charter for the WG is rather old. It doesn't have anything that we are actually working on. Have there been any discussions about this. Mike : At this point all of the drafts are near completion. The only thing that would open things was if we decided to go to fast refresh or open up PIMv3. Stig : There should also probably be a BSR MIB draft. Pekka : The MIB document needs to exist before BSR can go to PS.