Last Modified: 2003-10-30
This working group will act as a consultant to any PIM-over-Foo proposals, including but not limited to PIM-over-ATM, using PIM for multiprotocol label switching, and PIM-over-UDLR links.
1) PIM-SM v2 specification (standards track)
This document is a specification for Sparse Mode Protocol Independent Multicast.
2) PIM-DM v2 speficication (standards track)
This document is a specification for Dense Mode Protocol Independent Multicast.
3) PIM MIB (standards track)
This document contains the MIB definitions for PIMv2.
|Aug 98||Hold the first Working Group meeting and discuss the charter and the state of progress on the chartered items.|
|Aug 98||Update the PIM-DM version 2 Internet-draft. Go to WG last call. Submision to IESG for considerations as proposed standard.|
|Aug 98||Resubmit the latest PIM-SM version 2 specification to IESG for consideration as a proposed standard RFC|
|Dec 98||Submit Internet-Draft describing use of IP security with PIM.|
|Dec 98||Submit updated PIM-SM and PIM-DM internet-drafts, clarifying any inconsistencies or ambiguities in the previous drafts.|
|Apr 99||Submit PIM-SM version 2 and PIM-DM version 2 specifications to IESG for consideration as Draft Standards.|
|Apr 99||Submit PIM-SM and PIM-DM Applicability Statements|
|Apr 99||Submit PIMv2 MIB to IESG for consideration as proposed standard.|
|Nov 99||Submit PIMv2 MIB to IESG for consideration as draft standard.|
PIM Working Group Meeting Minneapolis, MN November 2003 Reported by: Isidor Kouvelas - - SM spec review status Version released recently which is pretty close if not last. Sent to reviewers. Team at Motorola is reviewing. More people needed to go over last version. Reviewers should be looking for errors. No major changes to the spec. Waiting for reviewer comments to release one final version. Spec has already received significant amount of review. - - Bi-Dir status Waiting on Sparse Mode spec. Load spliting will go in separate spec once we get a good solution. - - Dense-Mode spec Members of the working group no longer have interest in this document. Therefore, we will pursue moving it to experimental as is until such a time when this changes. - - BSR Mark doesn't think the BSR spec is in fabulous shape. Volunteers needed to carry it on. - - PIM MIB update There are 3 volunteers to work on the spec. Effort coordinated through CVS. Mailing list: http://www.mountain2sea.com/mailman/listinfo/pim-mib If you have input please send email to regular PIM list. Suggestions for major changes welcome. MIB should not hold back SM spec. Bill says the MIB spec has to at least be in progress. - - Anycast RP redundancy update - Dino Anycast-PIM not to be confused with anycast RP or MSDP o Anycast PIM is a way to do anycast RP without MSDP. o Has all the benefits of MSDP with less protocols Current draft includes comments on previous version and has been renamed to ht tp://ietf.org/internet-drafts/draft-iet f-pim-anycast-rp-00.txt. Authors want the document to become a standards track document. Changes to the draft include peering with MSDP domains. Mark: Did we actually decide to accept this as a WG item? Dino: There were no objections. Hugh: Since there has been confusion about whether this has been a working group document we should give people time to review. Mark: People have to read the draft before knowing if they want it to be a WG document. Tom: We dont have to move forward with this draft. We are just saying that we want to work on this issue. AD: Document has to be taken to the list and then the decision has to be made whether we want it to be a WG doc. - - Multicast over P2MP LSPs - Rahul draft-raggarwa-pim-sm-mpls-te-00.txt Need of a way to do multicast through an MPLS only core that does not have routes that can be used for source RPF. Provider isn't interested in carrying BGP routes in the code which makes multicast RPF impossible. Provider may want to keep multicast routing state out of the core. Added benefit of MPLS in core is traffic engineering for multicast traffic. Point-to-multipoint LSPs used to deliver traffic from source PE to multiple receiving PEs. There were many slides with figures and examples. Please refer to presentation slides for explanation of protocol operation. Isidor: It is very hard to aggregate different (S,G) entries on P2MP LSPs. When (S,G) olist changes you are either forced to flood additional traffic to some of the PEs or create a new LSP. You either flood or get a state explosion. Dino: Similar scalability concern as above. Rahul: It all depends on the sophistication of the LSP management mechanism in PIM. ?1: Timing issues in LSP establishment and increased join latency. Dino: There will be increased join latency because of all the chit-chat. Yiqun: BGP free code and information used for multicast RPF are two different things. BGP free code means that you do not have the unicast BGP routing information in the core. Whether you carry the MBGP table in the core is a separate issue. Robert: You can have an IP multicast VPN backbone as an alternative to MPLS to establish the point 2 multipoint tunnels. Rahul: Solution applies to providers who run RSVP edge-to-edge. There are many providers that do this. (doubts from audience). Hugh: Problem could be split into two drafts. One that discusses the PIM control mechanisms and is independent of the tunneling mechanism and one that discusses the specific solution based on an MPLS backbone. Dino: Can you compare this draft to the one from NTT. Rahul: NTT specs address P2MP setup and not how multicast uses the tunnels. Rahul: MPLS WG to work on the P2MP LSP setup. PIM-SM WG to do the PIM-SM extensions. WG taking on this work? ADs would like the working group to finish its current milestones before taking on new work. The decision to look at this within the working group will be postponed until we can get some other work items completed.