2.5.8 Protocol Independent Multicast (pim)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-30

Tom Pusateri <pusateri@juniper.net>
Liming Wei <lwei@redback.com>
Routing Area Director(s):
Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>
Routing Area Advisor:
Alex Zinin <zinin@psg.com>
Mailing Lists:
General Discussion: pim@ietf.org
To Subscribe: http://www1.ietf.org/mailman/listinfo/pim/
Archive: http://www1.ietf.org/mail-archive/working-groups/pim/current/maillist.html
Description of Working Group:
The Protocol Independent Multicast (PIM) Working Group is chartered to standardize and promote the Protocol Independent Multicast Version 2 (PIMv2), Sparse Mode and Dense Mode, as a scalable, efficient and robust multicast routing protocol, capable of supporting thousands of groups, different types of multicast applications, and all major underlying layer-2 subnetwork technologies. The working group will decide if there is a need for any follow on work or version 3 of the protocol.

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.

Goals and Milestones:
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.
  • - draft-ietf-pim-bidir-05.txt
  • - draft-ietf-pim-sm-v2-new-08.txt
  • No Request For Comments

    Current Meeting Report

                             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: 
    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 
    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 
    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
    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 
    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 
    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 
    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. 


    IP Multicast with PIM-SM over a MPLS TE Core