[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01                                                         
Network Working Group                                       Mike McBride
Internet Draft                                             Cisco Systems
Intended Status: Informational
Expires:  May 2008






                                                            November 2007


                 PIM Refresh Reduction Problem Statement


             draft-mmcbride-pim-refresh-problem-statement-01

Status of this Memo

    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

Copyright Notice

    Copyright (C) The IETF Trust (2007).







McBride                                                         [Page 1]


Internet Draft       PIM Refresh Problem Statement         November 2007


Abstract

    The PIM Working Group has a PIM refresh reduction charter goal. The
    solution to this goal will help reduce the periodic join/prune
    processing in PIM. The L3VPN Working Group identified this periodic
    messaging of PIM as a potential scaling problem for PIM based MVPNs.
    This document identifies the issues we are trying to solve with PIM
    refresh reduction.



Table of Contents

     1          Introduction  .......................................   2
     2          History  ............................................   3
     3          Problem  ............................................   3
     4          Solutions  ..........................................   4
     5          Security Considerations  ............................   4
     6          Iana Considerations  ................................   5
     7          Acknowledgments  ....................................   5
     8          Normative References  ...............................   5
     9          Informative References  .............................   5
    10          Authors' Addresses  .................................   5
    11          Full Copyright Statement  ...........................   6
    12          Intellectual Property  ..............................   6




1. Introduction

    PIM Joins are refreshed every 60 seconds by a downstream router to
    keep multicast state alive at the upstream router. With an increase
    in state there is an increase in control traffic required for
    refresh.

    The PIM Working Group has a PIM refresh reduction charter goal. The
    solution to this goal will help reduce the periodic join/prune
    processing in PIM. The L3VPN Working Group identified this periodic
    messaging of PIM as a potential scaling problem for PIM based MVPNs.
    This document identifies the issues we are trying to solve with PIM
    refresh reduction.









McBride                                                         [Page 2]


Internet Draft       PIM Refresh Problem Statement         November 2007


2. History

    At the November 2004 IETF, the L3VPN WG identified the effects of
    periodic Join/Prune processing in PIM as a potential scalability
    problem for PIM based MVPNs and asked that the PIM WG provide a
    solution. The PIM WG subsequently created a pim refresh design team
    to understand the problem area and provide a solution in needed.

    Although there were disagreements on certain details, the design team
    had rough agreement on a Join/Prune acknowledgement solution.  But,
    before recommending any solution, the PIM WG decided to ask the L3VPN
    WG for a requirements (or similar) document to help determine if this
    is really an area for which a solution is needed.

    The PIM WG continued to discuss the future efforts we wanted to make
    to PIM. The primary focus, of the working group, at the time was in
    completing the PIMv2 [Fenner] draft. There are many enhancements we
    could make to PIM. Do we refrain from future PIM enhancements and
    close the working group? Or should we start going down the path of a
    major PIMv3 revision?

    The L3VPN did produce an MVPN requirements document [Morin] which did
    help to better understand the future scalability requirements of
    MVPN. But that requirements document didn't help in understanding at
    what point PIM messaging could cause a scalability problem for PIM
    based MVPNs.

    In 2007, with the PIMv2 draft complete and the PIM WG tasked with a
    new Charter, it was decided it would be of benefit for the WG to
    provide enhancements to PIM. The WG has determined there is
    additional work to be accomplished and is now chartered to
    standardize extensions to RFC 4601 - Protocol Independent Multicast
    Version 2 - Sparse Mode. These PIM extensions will include PIM
    refresh reduction.



3. Problem

    The PIM WG has decided to provide a solution(s) to reduce the effects
    of the periodic Join/Prune processing in PIM. This solution could
    help in the future scalability of PIM based MVPN as well as other PIM
    deployments.

    PIM Joins are refreshed every 60 seconds by a downstream router to
    keep multicast state alive at the upstream router. With an increase
    in multicast state there is an increase in PIM control traffic
    required for refresh. Scaling could become an issue with MVPNs where,



McBride                                                         [Page 3]


Internet Draft       PIM Refresh Problem Statement         November 2007


    for instance, there could be 1000 MVPNs having 100 mroute entries
    each along with 10 RPF neighbors. One million entries would then be
    sent out on the MDT.

    Additionally, route changes cause Joins to be sent to the new RPF
    neighbor. If the Join is lost, there will be disruption of traffic.
    There is no reliability in the Join/Prune exchange between downstream
    and upstream routers. Larger values of holdtime in the Join/Prune PDU
    would reduce the frequency of refreshes, but could also cause larger
    convergence delays.



4. Solutions

    This is not a solutions draft. Subsequent to this draft, there will
    be drafts which outline solutions to this problem. The following
    ideas have been discussed as possible solutions to be further
    specified:

      + Join/Prune Ack extension to PIM.

      + Hard state (TCP) solution.

      + PIMv3 (strong RPF, explicit tracking, hard state, etc)

      + Include checksums in Hello messages rather than sending periodic
        JPs.

      + Use long holdtimes.




5. Security Considerations

    This document is a problem statement, which describes the reduction
    of PIM messaging, and does not introduce security considerations by
    itself.  Any potential solution must protect against exploiting PIM
    as specified in RFC 4601.











McBride                                                         [Page 4]


Internet Draft       PIM Refresh Problem Statement         November 2007


6. Iana Considerations

    This document does not require any action on the part of IANA.



7. Acknowledgments

    We'd like to thank Dino Farinacci, Suresh Boddapati, Tom Pusateri,
    Marshall Eubanks, Robert Kebler, Venu Hemige, Yiqun Cai, Yakov
    Rekhter, Yetik Serbest, Albert Tian, for their work on the pim
    refresh design team and helping the PIM WG to define a few possible
    solutions.



8. Normative References

    [Fenner] B. Fenner, "Protocol Independent Multicast - Sparse Mode
    (PIM-SM)". RFC 4601

    [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, July 2007,
    draft-ietf-l3vpn-2547bis-mcast-05.txt


9. Informative References

    [MORIN] T. Morin, "Requirements for Multicast in L3 Provider-
    Provisioned VPNs", RFC 4834



10. Authors' Addresses

    Mike McBride
    mmcbride@cisco.com















McBride                                                         [Page 5]


Internet Draft       PIM Refresh Problem Statement         November 2007


11. Full Copyright Statement

    Copyright (C) The IETF Trust (2007).

    This document is subject to the rights, licenses and restrictions
    contained in BCP 78, and except as set forth therein, the authors
    retain all their rights.

    This document and the information contained herein are provided on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.




12. Intellectual Property

    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.  Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository at
    http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at ietf-
    ipr@ietf.org.




McBride                                                         [Page 6]

Internet Draft       PIM Refresh Problem Statement         November 2007