2.6.11 Protocol Independent Multicast (pim)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-09-27


Tom Pusateri <pusateri@bangj.com>
Mike McBride <mmcbride@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
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
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.
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 2004  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 2005  Submit PIMv2 MIB to IESG for consideration as draft standard.


  • draft-ietf-pim-bidir-08.txt
  • draft-ietf-pim-sm-v2-new-11.txt
  • draft-ietf-pim-sm-bsr-06.txt
  • draft-ietf-pim-mib-v2-04.txt
  • draft-ietf-pim-anycast-rp-04.txt
  • draft-ietf-pim-proposed-req-01.txt
  • draft-ietf-pim-rpf-vector-01.txt
  • draft-ietf-pim-join-attributes-00.txt

    Request For Comments:

    RFC3973 E Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)

    Current Meeting Report

    Protocol Independent Multicast (pim)
    Tom Pusateri 
    Mike McBride 
    Mailing Lists:
    General Discussion: pim@ietf.org
    IETF 64 : Meeting November 10, 20056
    Agenda :
    Status of the PIM Draft
    draft-ietf-pim-join-attributes-00    Arjen Boers    5min
    draft-ietf-pim-rpf-vector-01         Ice Wijnands   5min
    draft-ietf-pim-mib-v2-04             David McWalter 10min
    draft-ietf-pim-sm-bsr-06             Nidhi Bhaskar  10min
    draft-hemige-pim-improved-assert-00  Venu Hemige    10min
    L3VPN Issues                         Mike McBride
    Scribe : Marshall Eubanks 
    Status of the PIM Draft
    PIM-SM has passed the IESG Last Call, with a few remaining issues. The Chairs 
    urged those participating to send in their corrections. The BiDir draft needs 
    an implementation report. 
    draft-ietf-pim-join-attributes-00    Arjen Boers    5min
    The Chairs plan to do a WGLC for this draft after this meeting.
    draft-ietf-pim-rpf-vector-01         Ice Wijnands   5min
    There is another, expired draft, to solve the same problem. Tom Pusateri 
    suggested resurrecting the earlier draft and comparing the two solutions. 
    draft-hemige-pim-improved-assert-00  Venu Hemige    10min
    The working group raised various issues with this draft. The Chairs suggested 
    these be addressed before it is adopted by the Working Group.
    draft-ietf-pim-mib-v2-04             David McWalter 10min
    The changes in the recent draft update were described. The separate PIM-MIB and 
    PIM-State mailing lists will be shut down and traffic should be directed to the 
    main PIM list. 
    draft-ietf-pim-sm-bsr-06             Nidhi Bhaskar  10min
    The author asked for a WGLC on this document before IETF-65.
    L3VPN Issues                         Mike McBride
    Mike McBride described the results of Thomas Morin's survey about multicast 
    requirements. The L3VPN WG is thinking of dropping PIM entirely for BGP based 
    Multicast routing on Multicast VPN's. An extensive discussion of this and PIM 
    state refresh reduction followed. 
    Narrative Minutes 
    Mike McBride : A brief update on existing drafts. The tools page is a great 
    resource for all of our drafts. You can check what the changes are, etc. 
    The PIM anycast draft is progressing. Nothing more for us to do at this point.
    PIM-SM has passed the IESG Last Call. There are a few remaining issues.
    I wore this shift [a colorful tie-die] specifically for Bill Fenner, to 
    encourage him to finish. 
    Bill : We had a burst of energy and had two more final PIM spec meetings, and I 
    expect it to take one or two more. We're trying to resist more tweaks, but some 
    of the issues are real, for example IPsec has changes since we last addressed 
    the IPsec issues. 
    Tom : Can you give us an estimate ?
    Bill Fenner : What year is this ? [laughter]
    Tom : The longer it stays like this, the more there is to update.
    Bill : We'll try and find time in November for this.
    Tom : Isidor [Kouvelas]  wanted everyone to know that his list is done.
    Tom : There are changes that are needed to the proposed requirements document, 
    but they all seemed like less than nits to me. 
    Bill : I actually agree with that. I can bump Alex about this again. I actually 
    don't think that it is useful to publish documents like this as RFC's. 
    Tom : What is the status of BiDir ? Is it just waiting on PIM ?
    Bill : That's a question that I have asked myself.
    Tom : Isidor put a new version out 10/25.
    Mike : I think it should be publication requested.
    Bill : We need an implementation report specifically for BiDir.
    Tom : I will get together with Isidor to work on the implementation report.
    Arjen Boers : draft-ietf-pim-join-attributes-00
    Draft was submitted in June 2004. The original PIM proxy draft was split into 2 
    parts, for join attributes and the RPF vector. 
    Why do we need this ? For certain situations, we need an additional 
    information. For example, edge routers include additional information in PIM 
    We use the attribute to do the RPF check.
    This is new encoding from before, and doesn't use the reserved bits, and uses 
    an end of stack bit. 
    It allows numbers of attributes - with this encoding, we allow for 64 types of 
    We incorporated a number of comments from James Lingard.
    Mike McBride : I know that there is another, expired, draft with another 
    proposal for this solution. 
    Tom : This is just attributes for joins. We will do a WGLC for this right after 
    this meeting. 
    The other part is PIM RPF Vector
    The problem statement is the same as before.
    The edge router will encode the BGP next hop as an attribute 
    The target router will remove the attribute.
    Simple -- just encode with the IP address.
    Tom : In the middle of 2004, another proposal solved the same problem in a 
    different way. 
    As a WG we may want to look at both proposals. Because it expired, I will try 
    and revive it. 
    Bill : Is the proposal to publish them both as experimental ?
    Tom : Do you want to do it as experimental ?
    Arjen : I would like to go for draft standard.
    Bill : We try to resist doing two ways to do the same thing, both on the 
    standards track. 
    Arjen : Maybe for the next IETF we can see what the differences are.
    Tom : We may have to meet in a room and discuss this.
    Arjen : We'll take some beer with us. [laughter]
    Vennu Hemige : Is there a reason why it is not using the encoded source address 
    What if it is a IPv6 address ?
    Arjen : You can use encoded source if you want, but it's larger.
    Tom : In the first draft, I think that there is stuff left over which makes it 
    quite independent enough. I'll send what I noticed to the list.
    Bill : I think we should think about using the encoded source address. If we 
    have something new to RFP to, we would have to create a new address family. I 
    can't say I have any idea how often 
    Dino Farinacci : In the spirit of consistency, it would be nice to be like the 
    other encoded addresses. 
    Vennu Hemige : Improved Assert in PIM-SM
    The motivation is to decouple the control plane dependancy on the data plane to 
    detect duplicate traffic. 
    The idea is to elect an assert winner before duplicate traffic is seen. For 
    applications like IPTV duplicate traffic can be as bad as dropped traffic. 
    When a downstream router sends a join, the other routers on a LAN see the joins 
    but don't react if they know they wouldn't win an assert. 
    In the proposal, joins are sent to all routers, routers see Joins on 
    If a join is seen, and you could win,  then trigger an asset.
    Then assert election happens right away.
    This is a simple extension of PIM-SM.
    Nidhi - This is an interesting application.
    Assert processing in PIM can come from other mechanisms, say because you lost 
    your join. 
    You can't really get rid of your  need to assert.
    Vennu : The draft addresses a lot of the assert scenarios.
    PIM-SM is a soft state protocol. If you lose the first join, the issues are the 
    Bill : You're going from a data plane detection which would work in seconds to 
    something that would take 60 seconds. In the lost join case, I don't think that 
    this is better. 
    Vennu : In PIm-SSM Asserts are about the only reason to tightly couple the data 
    and control plane. 
    If joins are lost, there are issues anyway.
    Bill : PIM behaves poorly if messages are lost.
    What I actually wanted to ask. When you are switching from a (*,G) tree to a 
    (S,G) tree, normally, you wait until traffic is flowing. If you pre-assert in 
    this way, that advantage goes away. If for some reason, the (S,G) doesn't work, 
    the switchover doesn't happen until the SPT bit is set. This is a tricky corner 
    Vennu : I would like to understand this scenario better
    Suresh : The idea that you can detect duplicate traffic before it happens. In 
    most cases, it just works. 
    Dave Thaler : If you do have duplicates in multicast, it can be much worse than 
    in unicast. It may be difficult, but it's worth it. 
    I think that it is important to detect stuff in data - that's an important 
    Vennu : In MPLS, there is a solution that says that it's OK to have duplicate 
    traffic - it's OK for the duration of the stream. 
    Dino : They are wrong.
    Toerless : There was a person saying use this as an optimization and keep the 
    data trigger as a fall back. I wanted to do this. 
    I think that there is a more fundamental problem, which is that the assert by 
    itself sucks. If we can move onto something that would avoid asserts 
    Nidhi : I think that this is a nice optimization for the cases where it work. 
    But you can't say that you don't have to do data detection. 
    If there is an RPF change, for example. They can show up in surprising cases.
    Bill : It is a corner case. PIM has about 150 million corner cases.
    Vennu : There is benefit in doing this.
    Bill : It's a nice optimization when it works. If the only times it doesn't 
    work is when it creates work in the data plane, that's closed. 
    Beau : If you can't exhaustively prove that your optimization won't black hole 
    traffic you shouldn't do it. 
    Dave Thaler : Do you do the join first or the assert first ?
    Dino : When a join comes up, there can be lots of (S,G) in there, which could 
    cause N Asserts to come out. I don't want one packet to cause an explosion of 
    Tom : Come up with another version of your draft which addresses these comments 
    and we will [adopt it on in the WG]. 
    draft-ietf-pim-mib-v2-04  - David McWalter
    4 major changes in PIM MIB
    Added anycast RP
    Added 4 traps, two for error cases, 2 are administrative
    SSM Range configuration
    BSR configuration has been taken out and will be a personal submission
    Tom : I want to close down the PIM-MIB and the PIM-State lists. Any traffic can 
    go to the main PIM list. 
    draft-ietf-pim-sm-bsr-06  - Nidhi Bhaskar
    BSR Spec : The ID has been refreshed.
    Updated to reflect input - the specification is pretty stable.
    Triggered RP-Set changes, we recommend a backoff, and at least 10 seconds.
    Can we do a last call before the next meeting ?
    John Zweibel : the BSR hold time isn't proportional ?
    Nidhi : No it isn't. There is a fixed interval.
    John : So you can't change it ?
    Nidhi : Unless you configure it on all of the routers.
    John : Second, the priority should be non-zero.
    And the candidate RP hold time. How is that calculated ?
    Nidhi : The value for the hold time is derived from the hold time
    The BSR MIB has been removed from the PIM MIB. Should it be added back ?
    Tom : I would say not, as it's a dependency we don't need.
    Dino : Did you make packet format changes ?
    Nidhi : No
    Dave Thaler : What's the expected time frames of submitting these ?
    Bill : Anycast RP is in IESG last call.
    It's not that big a deal to have two different MIB documents.
    Mike McBride 
    For those of you who attended the L3VPN WG, Thomas Morin showed results of a 
    very interesting survey about multicast requirements. 
    There doesn't seem to be an urgent need to solve PIM refresh immediately. There 
    has been a variety of proposals to handle Multicast in BGP. 
    Tom : It would be good to get a summary of the Join Prune ACK stuff that went 
    on and why it stopped. 
    Mike : Refresh reduction came to a halt because we were waiting on the L3VPN to 
    give us requirements. 
    Nidhi : Was there ever a clear communication of requirements ? I think it would 
    be useful to get that input. 
    Tom : Maybe we should ask them for this.
    Dino : The basic idea is we introduce a new very lightweight JP-ack mechanism, 
    which works well on point to point links and on multi-access LANs. 
    If  we wanted to limit it to P2P links it could be ready very quickly.
    Nidhi : The alternative to JP reduction is to put Multicast routing in BGP.
    The changes that L3VPN will bring to PIM  are more than just refresh reduction.
    Mike McBride : Is this something that L3VPN needs to work on ?
    Greg Shepherd : This is the PIM WG. Anything that affects PIM should be 
    addressed here. 
    Dino Farinacci : For the JP ACK version I think that this should be not be PIM 
    Version 3. 
    This could open it up for all sorts of  revisions.


    None received.