Last Modified: 2005-06-02
| Done | Hold the first Working Group meeting and discuss the charter and the state of progress on the chartered items. | |
| Done | Update the PIM-DM version 2 Internet-draft. Go to WG last call. Submision to IESG for considerations as proposed standard. | |
| Done | Resubmit the latest PIM-SM version 2 specification to IESG for consideration as a proposed standard RFC | |
| Done | Submit PIM-SM Applicability Statements | |
| Aug 04 | Submit PIMv2 MIB to IESG for consideration as proposed standard. | |
| Done | Submit updated PIM-SM and PIM-DM internet-drafts, clarifying any inconsistencies or ambiguities in the previous drafts. | |
| Done | Submit PIM-SM version 2 and PIM-DM version 2 specifications to IESG for consideration as Draft Standards. | |
| Mar 05 | Submit PIMv2 MIB to IESG for consideration as draft standard. |
| RFC | Status | Title |
|---|---|---|
| RFC3973 | E | Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) |
|
NOTES for PIM WG at IETF 63
PIM WG IETF 63, Paris, August 2 2005 Tom Pusateri, Mike McBride, presiding. Mike : There doesn't seem to be anything controversial today. On the sparse mode draft the AD'S are continuing to review it. Bill Fenner : I am recused from being an AD as I am an author. I think it's great. Pekka : It has been in this state for 5 months now. Mike : It's long. Bill : I am sending a message to Alex. Mike : BiDir draft. There is a new requirement that we fill out several questions. We'll answer those questions and help the draft along. Anycast RP. There have been comments and we're awaiting a new draft. Dino : The author is unaware of that. Tom : I thought that there was an open issue with register stop caching. It either had to be mandatory or more fully specified. Dino : I did not know that the ball was in my court. Bill : I think that this is a communal ball dropping. Dino : Send me comments ASAP. Bill : After our phone call I was OK with it. Tom : I think these were brought up by Amit Shukla Dino : Could somebody send comments to the list. Bill : Let's do it on the list. Dino : I posted the last draft on the list and nobody had comments. Is it going to go through the IESG again ? Bill : No. Once the working group is OK with it it will go through to IETF last call. Tom : It shouldn't be hard to fix. Dino : If I can get the comment this week I will submit before the end of the IETF. [Audience member] : I made comments on the list, which were very small. Mike : The other drafts we have we'll get an update of. Stig ? Bill : Alex just said on jabber that his ETA for PIM-SM is two weeks after this meeting. Stig : BSR Spec. The current draft will expire in August. We have gone through the open issues. One issue is explicit or implicit withdrawal. Suggesting that the elected RP always sends all of the RP mappings. When an RP Mapping is removed, it is included in the next BSM with a hold time of zero. We think this should interoperate well. Next is BSR re-election. How do you do transition. The newly elected BSR hasn't received any announcements. We are proposing that the new BSR sends out an empty BSM. There might be implementations today that just remove all mappings if they get an empty BSM. But, this would be much faster than the 60 seconds it would now take a new BSR to find all mappings. We think that E-BSR's should trigger BSMs when the RP-Set changes. For BSR election, one major change is, instead of waiting 130 seconds, set startup delay in P-BSR state to BS_rand_Override. One question is, is there really a good reason to have such a long delay ? We want to say that we originate and forward ASMs to all interfaces with neighbors. Another question is why the zone Border router bit is set ? Can anyone remember ? Dave Thaler : I was involved in those discussions and don't remember why. It might have been that people were worried about interoperability between PIM and something else in the background. Still another question is do we need to forward unicast BSM's. We are not sure if it is worth it. Remaining issues are fairly simple. There are various semantic issues about BSM semantic fragmentations. One thing some of us have been wondering is how useful it is. There is no reason to fragment one group range. If there isn't any problems, we are just going to write a new draft for the next IETF. Beau Williams : Have you considered getting everything down to the one or two second time range with this mechanism. Stig : We think that the formulae could. But we haven't run any simulations. We need to. Beau : What we could approach reasonably would be useful. Dino : I don't think you want to take this extension to Candidate RP's as well. James : Are we trying to create something that is compatible with existing implementations. This is difficult as we don't know what all of them have been doing. I think that if it is important to come up with an efficient mechanism we might want to create a new spec. James Lingard : PIM MIB. History : The PIM MIB is defined in RFC2934 of October 2000. This 1 Does not reflect the new PIM draft 2 Has No support for IPV6 3 Has No support for Bidir PIM at all. The new MIB effort started in 2002 and then stalled until 2005. Tom set up a new mailing list. At IETF 62 Toerless presented some work he had been doing. This has been turned into -02, where we - added IPV6 AND BiDIR Support. - removed PIM-DM and PIM-SM v1. - Removed all links to IPv4 multicast MB - Added a lot of extra objects - Added a neighbor secondary address table In v3, - completely removed pimIpMRoute and next hop tables. - Added tables for SXSM and static RP - substantial reworking of the BSR tables New structure : Can support IPv4 and v6 independently. Tables for multicast tree state. These tables look like the specification. Remaining work : A few objects to be added or removed and plenty of editorial issues. The draft is in a stage where it could be usefully reviewed by the working group. Open Questions : Should BSR tables be moved in a separate MIB. This would remove a dependency of BSR, which is not really a core element. Would there be problems with making this a WG draft ? Tom : No. Any objections ? [none] James : We now have a PIM SSM range table, which is not really a PIM issue. Maybe this should be moved to a separate MIB. I would like to move this. Dino : Why not the IP multicast routing table MIB ? Dave Thaler : There are end hosts that create MIB's. I guess I am volunteering to help with that. Fenner : If you have an IP Multicast MIB on hosts, is there anything else you would put in the host MIB ? Dave Thaler : Yes. John : Another question is around Dense Mode. Should we create separate MIB for PIM-DM ? Bill : If we explain in the document why there is a normative reference to an experimental documents it's OK. John : We need ann extra enumeration value and some other changes. Bill : OK. It's a tossup. Tom : If it's something we can easily to, great, let's do it. John: There is nothing in the base state that supports NBMA directly. Should there be support for explicit tracking of next-hop neighbors in tree state tables. Thaler : I think that there are reasons to do that. John : It is not always clear that all of the fields make sense if you have explicit tracking. Bill : It seems really clear that if we can implement explicit tracking we should do it. John : Do we need support for single zone scope support ? John : Dino's anycast RP ? Is that going to proposed standard ? Bill : Proposed standard is the track it is on. John : The changes would be very small. What about ANYCAST RP using PIM ? John : You may have noticed that emails I have sent to operational types asking about message statistics. Dino : What I have found is that message statistics are moderately valuable. John : It is have been suggested that we leave this as an Internet draft, or should we just try and get this to an RFC ? Is there any way we can encourage more people to give feedback ? Dave Thaler : It should be the MBoned working group, not PIM. If there is anyone else interested in co-authoring this, please let me know. Toerless : Given some of the mistakes made in the past, I am sure there are places it could be improved. Lorenzo : Anything can be improved, especially MIB's. ------- Arjen : Just an update on the RPF Vector Proxy draft. We have to resubmit it with a new name. A big discussion point were the 5 bits from the reserve field. Well, we don't need them any more. Mike : The L3 VPN requested of the PIM WG ways to cut the amount of message traffic. We asked the L3 VPN to provide more direction on scalability. They have come up with a requirements draft and a operator survey. Dino : I would suggest doing this in PIM v3. Tom : Are you saying that changes are too extensive ? Dino : The changes are too extensive. |