draft-ietf-pim-group-rp-mapping-04.txt   draft-ietf-pim-group-rp-mapping-05.txt 
PIM Working Group B. Joshi PIM Working Group B. Joshi
Internet-Draft Infosys Technologies Ltd. Internet-Draft Infosys Technologies Ltd.
Expires: October 28, 2010 A. Kessler Intended status: Standards Track A. Kessler
Cisco Systems, Inc. Expires: January 22, 2011 Cisco Systems, Inc.
D. McWalter D. McWalter
Metaswitch Networks July 21, 2010
April 26, 2010
PIM Group-to-RP Mapping PIM Group-to-RP Mapping
draft-ietf-pim-group-rp-mapping-04.txt draft-ietf-pim-group-rp-mapping-05.txt
Abstract Abstract
Each PIM-SM router in a PIM Domain which supports ASM maintains Each PIM-SM router in a PIM Domain which supports ASM maintains
Group-to-RP mappings which are used to identify a RP for a specific Group-to-RP mappings which are used to identify a RP for a specific
multicast group. PIM-SM has defined an algorithm to choose a RP from multicast group. PIM-SM has defined an algorithm to choose a RP from
the Group-to-RP mappings learned using various mechanisms. This the Group-to-RP mappings learned using various mechanisms. This
algorithm does not consider the PIM mode and the mechanism through algorithm does not consider the PIM mode and the mechanism through
which a Group-to-RP mapping was learned. which a Group-to-RP mapping was learned.
skipping to change at page 1, line 43 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 28, 2010. This Internet-Draft will expire on January 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 9 skipping to change at page 4, line 9
Embedded-RP as defined in section-7.1 of Embedded-RP address in IPv6 Embedded-RP as defined in section-7.1 of Embedded-RP address in IPv6
Multicast address [RFC3956], mentions that to avoid loops and Multicast address [RFC3956], mentions that to avoid loops and
inconsistencies, for addresses in the range FF70::/12, the inconsistencies, for addresses in the range FF70::/12, the
Embedded-RP mapping must be considered the longest possible match and Embedded-RP mapping must be considered the longest possible match and
higher priority than any other mechanism. higher priority than any other mechanism.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119. This and "OPTIONAL" are to be interpreted as described in RFC 2119
document also uses following terms: [RFC2119]. This document also uses following terms:
o PIM Mode o PIM Mode
PIM Mode is the mode of operation a particular multicast group is PIM Mode is the mode of operation a particular multicast group is
used for. Wherever this term in used in this document, it refers to used for. Wherever this term in used in this document, it refers to
either Sparse Mode or BIDIR Mode. either Sparse Mode or BIDIR Mode.
o Dynamic group-to-RP mapping mechanisms o Dynamic group-to-RP mapping mechanisms
The term Dynamic group-to-RP mapping mechanisms in this document The term Dynamic group-to-RP mapping mechanisms in this document
skipping to change at page 7, line 18 skipping to change at page 7, line 18
entries entries
Many network operators will have a dedicated infrastructure for the Many network operators will have a dedicated infrastructure for the
standard multicast group range (224/4) and so might be using standard multicast group range (224/4) and so might be using
statically configured Group-to-RP mappings for this range. In this statically configured Group-to-RP mappings for this range. In this
case, to support some specific applications, they might like to learn case, to support some specific applications, they might like to learn
Group-to-RP mappings dynamically using either BSR or Auto-RP Group-to-RP mappings dynamically using either BSR or Auto-RP
mechanism. In this case to select Group-to-RP mappings for these mechanism. In this case to select Group-to-RP mappings for these
specific applications, a longer prefix match should be given specific applications, a longer prefix match should be given
preference over statically configured Group-to-RP mappings. For preference over statically configured Group-to-RP mappings. For
example 239.100.0.0/16 could be learned for a corporate example 239.100.0.0/16, an administratively scoped multicast address
communications application. Network operators may change the Group- range, could be learned for a corporate communications application.
to-RP mappings for these applications more often and would need to be Network operators may change the Group-to-RP mappings for these
learned dynamically. applications more often and would need to be learned dynamically.
o Migration situations o Migration situations
Network operators occasionally go through a migration due to an Network operators occasionally go through a migration due to an
acquisition or a change in their network design. In order to acquisition or a change in their network design. In order to
facilitate this migration there is a need to have a deterministic facilitate this migration there is a need to have a deterministic
behaviour of Group-to-RP mapping selection for entries learned using behaviour of Group-to-RP mapping selection for entries learned using
BSR and Auto-RP mechanism. This will help in avoiding any unforeseen BSR and Auto-RP mechanism. This will help in avoiding any unforeseen
interoperability issues between different vendor's network elements. interoperability issues between different vendor's network elements.
skipping to change at page 14, line 9 skipping to change at page 14, line 9
Therefore the hash in BSR is ignored for PIM-Bidir RP mappings based Therefore the hash in BSR is ignored for PIM-Bidir RP mappings based
on the algorithm defined in this document. It is RECOMMENDED that on the algorithm defined in this document. It is RECOMMENDED that
network operators configure only one PIM-Bidir RP for each RP network operators configure only one PIM-Bidir RP for each RP
Priority. Priority.
11. Filtering Group-to-RP mappings at domain boundaries 11. Filtering Group-to-RP mappings at domain boundaries
An implementation of PIM SHOULD support configuration to block An implementation of PIM SHOULD support configuration to block
specific dynamic mechanism for a valid group prefix range. For specific dynamic mechanism for a valid group prefix range. For
example, it should be possible to allow 239/8 range for Auto-RP example, it should be possible to allow an administratively scoped
protocol but block the BSR advertisement for the same range. address range, such as 239/8 range, for Auto-RP protocol but block
Similarly it should be possible to filter out all Group-to-RP the BSR advertisement for the same range. Similarly it should be
mappings learned from BSR or Auto-RP protocol. possible to filter out all Group-to-RP mappings learned from BSR or
Auto-RP protocol.
12. Security Consideration 12. Security Consideration
This document does not suggest any protocol specific functionality so This document does not suggest any protocol specific functionality so
there is no security related consideration. there is no security related consideration.
13. IANA Consideration 13. IANA Consideration
This draft does not create any namespace for IANA to manage. This draft does not create any namespace for IANA to manage.
14. Acknowledgements 14. Acknowledgements
This draft is created based on the discussion occurred during the This draft is created based on the discussion occurred during the
PIM-STD-MIB [RFC5060] work. Many thanks to Stig Vennas, Yiqun Cai PIM-STD-MIB [RFC5060] work. Many thanks to Stig Vennas, Yiqun Cai
and Toerless Eckert for providing useful comments. and Toerless Eckert for providing useful comments.
15. Normative References 15. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. [RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A.
Kessler, "Protocol Independent Multicast MIB", RFC 5060, Kessler, "Protocol Independent Multicast MIB", RFC 5060,
January 2008. January 2008.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", Point (RP) Address in an IPv6 Multicast Address",
skipping to change at page 19, line 26 skipping to change at page 19, line 26
Andy Kessler Andy Kessler
Cisco Systems, Inc. Cisco Systems, Inc.
425 E. Tasman Drive 425 E. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: kessler@cisco.com Email: kessler@cisco.com
URI: http://www.cisco.com/ URI: http://www.cisco.com/
David McWalter David McWalter
Metaswitch Networks
100 Church Street
Enfield EN2 6BQ
UK
Email: dmcw@metaswitch.com Email: david@mcwalter.eu
 End of changes. 10 change blocks. 
20 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/