2.5.10 Protocol Independent Multicast (pim)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-07

Tom Pusateri <pusateri@juniper.net>
Mike McBride <mcbride@cisco.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://www.ietf.org/mail-archive/web/pim/index.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:
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.
Apr 04  Resubmit the latest PIM-SM version 2 specification to IESG for consideration as a proposed standard RFC
Aug 04  Submit PIM-SM Applicability Statements
Aug 04  Submit PIMv2 MIB to IESG for consideration as proposed standard.
Sep 04  Submit updated PIM-SM and PIM-DM internet-drafts, clarifying any inconsistencies or ambiguities in the previous drafts.
Nov 04  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.
  • - draft-ietf-pim-bidir-07.txt
  • - draft-ietf-pim-sm-v2-new-10.txt
  • - draft-ietf-pim-sm-bsr-04.txt
  • - draft-ietf-pim-dm-new-v2-05.txt
  • - draft-ietf-pim-anycast-rp-02.txt
  • No Request For Comments

    Current Meeting Report

    PIM WG minutes for IETF 60

    [Thanks to Toerless Eckert for taking the notes]

    Isidor Kouvelas
    - PIM-SM Update:
    Many editorial comments, few state machinery comments, all covered in newest version of spec. Summary had recently been sent by Bill Fenner to wg mailing list. Spec considered to be done. Diminishing return. Ask chairs to move spec to IESG.

    Tom Pusateri: Move on, go to IESG, no more comments!

    - Bidir-PIM: minor fixes only, no real protocol changes. One protocol issue open: applying BSR to Bidir-PIM: Wanted not to use BSR Hashing. Because this would forego load-splitting, solution is now to recommend longer hash-mask length by default.

    Toerless: The longer the hash mask, the more HW table entries are required. Up to implementors/customers to figure out how much it is worth it.

    Alex Gall
    - Present BSR update (-04), with Nidhi and Stig.
    - Counted about 60 comments from mailing list.
    - Minor issues, need to revisit spec.
    - Scoping was not well understood. Leave unchanged right now and try to better understand.
    - Need to take out PIM-SM specifics out of draft now it's separate spec and supposed to apply to Bidir-PIM and PIM-SM.
    - Bidir flag should also be interpreted by implementations who do not support Bidir appropriately.
    - Remove hash function from BSR spec

    Mark Handley: It is ONLY in BSR spec ?
    Mike: Conclusion is that hash function is actually in PIM-SM

    Discussion (Bill, Lorenzo, Mark, Toerless, Hugh, Stig, Tom): where is the best place of the hash function ?
    - It is already in PIM-SM.
    - Wanted to have hash function in PIM-SM to have load balancing without necessarily using BSR (but also with static RP, etc..., ppp...)
    - Bill Fenner: ask Cisco whether we implement section 4.7 (hashing across different RP information: autoRP/BSR/static)

    - Tom Pusateri: Thinks no implementation is doing this today, but just apply hash function to BSR.

    - Bill: Let's figure out what to fix: spec or implementation

    - Lorenzo: proposed workaround how to get implementation/spec into sync ...what...

    - Dino: Usage comment into spec: Should only run one RP discovery mechanism within an AS ?

    - Bill mentioned that not applying hash to non-BSR sources may be considered to be compliant by mean of calling it the allowed local policy also referred to by the spec.

    - Compare section 4.7 against implementation and take it to the list.

    - Update on changes in handling of holdtime in BSR (slide 4 - 6).

    - Q Mark Handley: to slide 6: Does not allow for the BSR to immediately remove C-RP from RPset. A: Should work by setting holdtime to 0.
    Mark: May cause compatibility issue with routers using different versions of the spec during holdtime.

    - Mike: Take to list, 20 min left for 5 drafts.

    - Scoping (page 7...13)

    - Dense-mode spec is approved for experimental by IESG, need to get RFC.

    - MIB work: Biggest piece left to do is v6 compatibility piece. Couldn't find person who knows PIM and PIM and MIBs.

    - Anycast-PIM, version -02 update
    See preso from San Francisco IETF.
    11/2003, draf-ietf-pim-anycast-rp-00.txt
    MSDP interworking info added
    11/2003, draf-ietf-pim-anycast-rp-01.txt
    Post last call:
    11/2003, draf-ietf-pim-anycast-rp-02.txt
    -in RFC editors queue

    - Some slides about interworking issues. Describe interworking with external MSDP peerings.

    - present personal draft:

    - Lorenzo: sounds a bit like GRA in RMT, but hopefully more constrained, so may actually go anywhere

    - Toerless: Validate/explain how this work in the presence of IGMP snooping.

    - (??): Maybe out of scope of PIM WG or routing area, more like measurement in-band with routing protocol.

    Toerless: disagreed.

    - Tom: if implemented separately over UDP outside of UDP nobody coupld complain.

    - Mark: PIM tree topology information is very much related to PIM itself - but timezones for example might be a bit outside of the scope.

    - Pekka: ICMP ping ? would that allow similar results ?
    yes, possible out of band but does not scale.

    - presenting pim-proxy draft.

    - Discussion: should default-route on core router be considered to override RPF-proxy.

    - WG chairs to work with ADs on updating PIM WG charter to potentially include these new drafts.


    IETF-60 PIM-SM Update
    IETF PIM MIB Draft
    PIM Pop Count