draft-ietf-pim-group-rp-mapping-08.txt   draft-ietf-pim-group-rp-mapping-09.txt 
PIM Working Group B. Joshi PIM Working Group B. Joshi
Internet-Draft Infosys Technologies Ltd. Internet-Draft Infosys Technologies Ltd.
Updates: 4601 (if approved) A. Kessler Updates: 4601 (if approved) A. Kessler
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: July 1, 2011 D. McWalter Expires: July 16, 2011 D. McWalter
December 28, 2010 January 12, 2011
PIM Group-to-RP Mapping PIM Group-to-RP Mapping
draft-ietf-pim-group-rp-mapping-08.txt draft-ietf-pim-group-rp-mapping-09.txt
Abstract Abstract
Each PIM-SM router in a Protocol Independent Multicast (PIM) Domain Each PIM-SM router in a Protocol Independent Multicast (PIM) Domain
which supports Any Source Multicast (ASM) maintains Group-to-RP which supports Any Source Multicast (ASM) maintains Group-to-RP
mappings which are used to identify a Rendezvous Point(RP) for a mappings which are used to identify a Rendezvous Point(RP) for a
specific multicast group. PIM-SM has defined an algorithm to choose specific multicast group. PIM-SM has defined an algorithm to choose
a RP from the Group-to-RP mappings learned using various mechanisms. a RP from the Group-to-RP mappings learned using various mechanisms.
This algorithm does not consider the PIM mode and the mechanism This algorithm does not consider the PIM mode and the mechanism
through which a Group-to-RP mapping was learned. through which a Group-to-RP mapping was learned.
This document defines a standard algorithm to deterministically This document defines a standard algorithm to deterministically
choose between several group-to-rp mappings for a specific group. choose between several Group-to-RP mappings for a specific group.
This document first explains the requirements to extend the This document first explains the requirements to extend the
Group-to-RP mapping algorithm and then proposes the new algorithm. Group-to-RP mapping algorithm and then proposes the new algorithm.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 1, 2011. This Internet-Draft will expire on July 16, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Existing algorithm . . . . . . . . . . . . . . . . . . . . . . 5 3. Existing algorithm . . . . . . . . . . . . . . . . . . . . . . 5
4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Common use cases . . . . . . . . . . . . . . . . . . . . . . . 7 5. Common use cases . . . . . . . . . . . . . . . . . . . . . . . 7
6. Proposed algorithm . . . . . . . . . . . . . . . . . . . . . . 8 6. Proposed algorithm . . . . . . . . . . . . . . . . . . . . . . 8
7. Interpretation of MIB Objects . . . . . . . . . . . . . . . . 10 7. Interpretation of MIB Objects . . . . . . . . . . . . . . . . 10
8. Clarification for MIB Objects . . . . . . . . . . . . . . . . 11 8. Clarification for MIB Objects . . . . . . . . . . . . . . . . 11
9. Use of dynamic group-to-rp mapping protocols . . . . . . . . . 12 9. Use of dynamic Group-to-RP mapping protocols . . . . . . . . . 12
10. Consideration for Bidirectional-PIM and BSR hash . . . . . . . 13 10. Consideration for Bidirectional-PIM and BSR hash . . . . . . . 13
11. Filtering Group-to-RP mappings at domain boundaries . . . . . 14 11. Filtering Group-to-RP mappings at domain boundaries . . . . . 14
12. Security Consideration . . . . . . . . . . . . . . . . . . . . 15 12. Security Consideration . . . . . . . . . . . . . . . . . . . . 15
13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16 13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
15. Normative References . . . . . . . . . . . . . . . . . . . . . 18 15. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Multiple mechanisms exist today to create and distribute Group-to-RP Multiple mechanisms exist today to create and distribute Group-to-RP
mappings. Each PIM-SM router may learn Group-to-RP mappings through mappings. Each PIM-SM router may learn Group-to-RP mappings through
various mechanisms. various mechanisms as described in section 4.
It is critical that each router select the same 'RP' for a specific It is critical that each router select the same 'RP' for a specific
multicast group address. This is even true in the case of Anycast RP multicast group address otherwise full multicast connectivity will
for redundancy. This RP address may correspond to a different not be established. This is even true in the case of Anycast RP for
physical router but it is one logical RP address and must be redundancy. This RP address may correspond to a different physical
consistent across the PIM domain. This is usually achieved by using router but it is one logical RP address and must be consistent across
the same algorithm to select the RP in all the PIM routers in a the PIM domain. This is usually achieved by using the same algorithm
domain. to select the RP in all the PIM routers in a domain.
PIM-SM [RFC4601] has defined an algorithm to select a 'RP' for a PIM-SM [RFC4601] has defined an algorithm to select a 'RP' for a
given multicast group address but it is not flexible enough for an given multicast group address but it is not flexible enough for an
administrator to apply various policies. Please refer to section 3 administrator to apply various policies. Please refer to section 3
for more details. for more details.
PIM-STD-MIB [RFC5060] includes a number of objects to allow an PIM-STD-MIB [RFC5060] includes a number of objects to allow an
administrator to set the precedence for Group-to-RP mappings which administrator to set the precedence for Group-to-RP mappings which
are learned statically or dynamically and stored in the are learned statically or dynamically and stored in the
'pimGroupMappingTable'. The MIB module also defines an algorithm 'pimGroupMappingTable'. The Management Information Base (MIB) module
that can be applied to the data contained in the also defines an algorithm that can be applied to the data contained
'pimGroupMappingTable' to determine Group-to-RP mappings. However, in the 'pimGroupMappingTable' to determine Group-to-RP mappings.
this algorithm is not completely deterministic, because it includes However, this algorithm is not completely deterministic, because it
an implementation-specific 'precedence' value. includes an implementation-specific 'precedence' value.
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document also uses following terms: 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 is used in this document, it refers to
either Sparse Mode or Bidirectional (BIDIR) Mode. either Sparse Mode or Bidirectional (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
refers to Bootstrap Router (BSR) and Auto-RP. refers to Bootstrap Router (BSR) [RFC5059] and Auto-RP.
o Dynamic mappings or Dynamically learned mappings o Dynamic mappings or Dynamically learned mappings
The terms Dynamic mappings or Dynamically learned mappings refer to The terms Dynamic mappings or Dynamically learned mappings refer to
group-to-RP mappings that have been learned by BSR or Auto-RP. group-to-RP mappings that have been learned by BSR or Auto-RP.
Group-to-RP mappings that have been learned by embedded RP are Group-to-RP mappings that have been learned by embedded RP are
referred to as Embedded Group-to-RP mappings. referred to as Embedded Group-to-RP mappings.
o Filtering o Filtering
skipping to change at page 6, line 32 skipping to change at page 6, line 32
highest priority. They cannot be overridden either by static highest priority. They cannot be overridden either by static
configuration or by dynamic Group-to-RP mappings. configuration or by dynamic Group-to-RP mappings.
o Dynamic mappings will override a static RP config if they have o Dynamic mappings will override a static RP config if they have
overlapping ranges. However, it is possible to override dynamic overlapping ranges. However, it is possible to override dynamic
Group-to-RP mappings with static configurations, either by Group-to-RP mappings with static configurations, either by
filtering, or by configuring longer static group addresses that filtering, or by configuring longer static group addresses that
override dynamic mappings when longest prefix matching is applied. override dynamic mappings when longest prefix matching is applied.
o A Group-to-RP mapping learned for PIM-BIDIR mode is preferred to o A Group-to-RP mapping learned for PIM-BIDIR mode is preferred to
an entry learned for PIM-SM mode. an entry learned for PIM-SM mode as stipulated by section 3.3 of
[RFC5059].
o Dynamic group-to-RP mapping mechanisms are filtered at domain o Dynamic group-to-RP mapping mechanisms are filtered at domain
boundaries or for policy enforcement inside a domain. boundaries or for policy enforcement inside a domain.
5. Common use cases 5. Common use cases
o Default static Group-to-RP mappings with dynamically learned o Default static Group-to-RP mappings with dynamically learned
entries entries
Many network operators will have a dedicated infrastructure for the Many network operators will have a dedicated infrastructure for the
skipping to change at page 7, line 37 skipping to change at page 7, line 37
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.
o Use by management systems o Use by management systems
A network management station can determine the RP for a specific A network management station can determine the RP for a specific
group in a specific router by running this algorithm on the group in a specific router by running this algorithm on the
Group-to-RP mapping table fetched using SNMP MIB objects. Group-to-RP mapping table fetched using MIB objects.
6. Proposed algorithm 6. Proposed algorithm
The following algorithm addresses the above mentioned shortcomings in The following algorithm deterministically chooses between several
the existing mechanism: Group-to-RP mappings for a specific group. It also addresses the
above mentioned shortcomings in the existing mechanism.
1. If the Multicast Group Address being looked up contains an 1. If the Multicast Group Address being looked up contains an
embedded RP, RP address extracted from the Group address is embedded RP, the RP address extracted from the Group address is
selected as Group-to-RP mapping. selected as the Group-to-RP mapping.
2. If the Multicast Group Address being looked up is in the Source 2. If the Multicast Group Address being looked up is in the Source
Specific Multicast (SSM) range or is configured for Dense mode, Specific Multicast (SSM) range or is configured for Dense mode,
no Group-to-RP mapping is selected, and this algorithm no Group-to-RP mapping is selected, and this algorithm
terminates. The fact that no Group-to-RP mapping has been terminates. The fact that no Group-to-RP mapping has been
selected can be represented in the PIM-STD-MIB module by setting selected can be represented in the PIM-STD-MIB module by setting
the address type of the RP to 'unknown' as described in Section the address type of the RP to 'unknown' as described in Section
8. 8.
3. From the set of all Group-to-RP mapping entries, the subset 3. From the set of all Group-to-RP mapping entries, the subset
whose group prefix contains the multicast group that is being whose group prefix contains the multicast group that is being
looked up, is selected. looked up, is selected.
4. If there are no entries available, then the Group-to-RP mapping 4. If there are no entries available, then the Group-to-RP mapping
is undefined and this algorithm terminates. is undefined and this algorithm terminates.
5. A longest prefix match is performed on the subset of Group-to-RP 5. A longest prefix match is performed on the subset of Group-to-RP
Mappings. Mappings.
* If there is only one entry available then that is selected as * If there is only one entry available then that entry is
Group-to-RP mapping. selected as the Group-to-RP mapping.
* If there are multiple entries available, we continue with the * If there are multiple entries available, we continue with the
algorithm with this smaller set of Group-to-RP Mappings. algorithm with this smaller set of Group-to-RP Mappings.
6. From the remaining set of Group-to-RP Mappings we select the 6. From the remaining set of Group-to-RP Mappings we select the
subset of entries based on the preference for the PIM modes subset of entries based on the preference for the PIM modes
which they are assigned. A Group-to-RP mapping entry with PIM which they are assigned. A Group-to-RP mapping entry with PIM
Mode 'BIDIR' will be preferred to an entry with PIM Mode Mode 'BIDIR' will be preferred to an entry with PIM Mode
'PIM-SM' 'PIM-SM'
* If there is only one entry available then that is selected as * If there is only one entry available then that entry is
Group-to-RP mapping. selected as the Group-to-RP mapping.
* If there are multiple entries available, we continue with the * If there are multiple entries available, we continue with the
algorithm with this smaller set of Group-to-RP Mappings algorithm with this smaller set of Group-to-RP Mappings
7. From the remaining set of Group-to-RP Mappings we select the 7. From the remaining set of Group-to-RP Mappings we select the
subset of the entries based on the origin. Group-to-RP mappings subset of the entries based on the origin. Group-to-RP mappings
learned dynamically are preferred over static mappings. If the learned dynamically are preferred over static mappings. If the
remaining dynamic Group-to-RP mappings are from BSR and Auto-RP remaining dynamic Group-to-RP mappings are from BSR and Auto-RP
then the mappings from BSR is preferred. then the mappings from BSR is preferred.
* If there is only one entry available then that is selected as * If there is only one entry available then that entry is
Group-to-RP mapping. selected as the Group-to-RP mapping.
* If there are multiple entries available, we continue with the * If there are multiple entries available, we continue with the
algorithm with this smaller set of Group-to-RP Mappings. algorithm with this smaller set of Group-to-RP Mappings.
8. If the remaining Group-to-RP mappings were learned through BSR 8. If the remaining Group-to-RP mappings were learned through BSR
then the RP will be selected by comparing the RP Priority in the then the RP will be selected by comparing the RP Priority in the
Candidate-RP-Advertisement messages. The RP mapping with the Candidate-RP-Advertisement messages. The RP mapping with the
lowest value indicates the highest priority [RFC5059]. lowest value indicates the highest priority [RFC5059].
* If more than one RP has the same highest priority value we * If more than one RP has the same highest priority value we
continue with the algorithm with those Group-to-RP mappings. continue with the algorithm with those Group-to-RP mappings.
* If the remaining Group-to-RP mappings were NOT learned from * If the remaining Group-to-RP mappings were NOT learned from
BSR we continue the algorithm with the next step. BSR we continue the algorithm with the next step.
9. If the remaining Group-to-RP mappings were learned through BSR 9. If the remaining Group-to-RP mappings were learned through BSR
and the PIM Mode of the Group is 'PIM-SM' then the hash function and the PIM Mode of the Group is 'PIM-SM' then the hash function
will be used to choose the RP. The RP with the highest as defined in section 4.7.2 of [RFC4601] will be used to choose
resulting hash value will be selected. Please look at section the RP. The RP with the highest resulting hash value will be
10 for consideration of hash for BIDIR-PIM and BSR. selected. Please look at section 10 for consideration of hash
for BIDIR-PIM and BSR.
* If more than one RP has the same highest hash value we * If more than one RP has the same highest hash value we
continue with the algorithm with those Group-to-RP mappings. continue with the algorithm with those Group-to-RP mappings.
* If the remaining Group-to-RP mappings were NOT learned from * If the remaining Group-to-RP mappings were NOT learned from
BSR we continue the algorithm with the next step. BSR we continue the algorithm with the next step.
10. From the remaining set of Group-to-RP Mappings we will select 10. From the remaining set of Group-to-RP Mappings we will select
the RP with the highest IP address. This will serve as a final the RP with the highest IP address (numerically greater). This
tiebreaker. will serve as a final tiebreaker.
7. Interpretation of MIB Objects 7. Interpretation of MIB Objects
The algorithm defined in this document does not use the concept of The algorithm defined in this document does not use the concept of
precedence and therefore the values configured in the precedence and therefore the values configured in the
'pimGroupMappingPrecedence' and 'pimStaticRPPrecedence' objects of 'pimGroupMappingPrecedence' and 'pimStaticRPPrecedence' objects of
the 'pimGroupMappingTable' table in the PIM-STD-MIB module [RFC5060] the 'pimGroupMappingTable' table in the PIM-STD-MIB module [RFC5060]
are not applicable to the new algorithm. The objects still retain are not applicable to the new algorithm. The objects still retain
their meaning for 'legacy' implementations, but since the algorithm their meaning for 'legacy' implementations, but since the algorithm
defined in this document is to be used in preference to that found in defined in this document is to be used in preference to that found in
skipping to change at page 12, line 5 skipping to change at page 12, line 5
Mode in the pimGroupMappingPimMode object is set to either ssm(2) or Mode in the pimGroupMappingPimMode object is set to either ssm(2) or
dm(5) to represent group ranges for SSM or Dense mode. dm(5) to represent group ranges for SSM or Dense mode.
Also, all the entries which are already included in the SSM Range Also, all the entries which are already included in the SSM Range
table in the IP Mcast MIB [RFC5132] are copied to the table in the IP Mcast MIB [RFC5132] are copied to the
pimGroupMappingTable. Such entries have their type in the pimGroupMappingTable. Such entries have their type in the
pimGroupMappingOrigin object set to configSsm(3), and the RP address pimGroupMappingOrigin object set to configSsm(3), and the RP address
type in the pimGroupMappingRPAddressType object set to unknown(0) as type in the pimGroupMappingRPAddressType object set to unknown(0) as
described above. described above.
9. Use of dynamic group-to-rp mapping protocols 9. Use of dynamic Group-to-RP mapping protocols
It is not usually necessary to run several dynamic Group-to-RP It is not usually necessary to run several dynamic Group-to-RP
mapping mechanisms in one administrative domain. Specifically, mapping mechanisms in one administrative domain. Specifically,
interoperation of BSR and Auto-RP is OPTIONAL. interoperation of BSR and Auto-RP is OPTIONAL.
However, if a router does receive two overlapping sets of Group-to-RP However, if a router does receive two overlapping sets of Group-to-RP
mappings, for example from Auto-RP and BSR, then some algorithm is mappings, for example from Auto-RP and BSR, then some algorithm is
needed to deterministically resolve the situation. The algorithm in needed to deterministically resolve the situation. The algorithm in
this document MUST be used. This can be important at domain border this document MUST be used on all routers in the domain. This can be
routers, and is likely to improve stability under misconfiguration important at domain border routers, and is likely to avoid conflicts
and when configuration is changing. under misconfiguration (when routers receive overlapping sets of
Group-to-RP mappings) and when configuration is changing.
An implementation of PIM that supports only one mechanism for An implementation of PIM that supports only one mechanism for
learning Group-to-RP mappings MUST also use this algorithm. The learning Group-to-RP mappings MUST also use this algorithm. The
algorithm has been chosen so that existing standard implementations algorithm has been chosen so that existing standard implementations
are already compliant. are already compliant.
10. Consideration for Bidirectional-PIM and BSR hash 10. Consideration for Bidirectional-PIM and BSR hash
BIDIR-PIM [RFC5015] is designed to avoid any data driven events. BIDIR-PIM [RFC5015] is designed to avoid any data driven events.
This is especially true in the case of a source only branch. The RP This is especially true in the case of a source only branch. The RP
mapping is determined based on a group mask when the mapping is mapping is determined based on a group mask when the mapping is
received through a dynamic mapping protocol or statically configured. received through a dynamic mapping protocol or statically configured.
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 filter
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 an administratively scoped example, it should be possible to allow an administratively scoped
address range, such as 239/8 range, for Auto-RP protocol but block address range, such as 239/8 range, for Auto-RP protocol but filter
the BSR advertisement for the same range. Similarly it should be out the BSR advertisement for the same range. Similarly it should be
possible to filter out all Group-to-RP mappings learned from BSR or possible to filter out all Group-to-RP mappings learned from BSR or
Auto-RP protocol. Auto-RP protocol.
12. Security Consideration 12. Security Consideration
This document enhances an existing algorithm to deterministically This document enhances an existing algorithm to deterministically
choose between several group-to-rp mappings for a specific group. choose between several Group-to-RP Mappings for a specific group.
The updated algorithm will not completely prevent the possibility of Different routers may select a different Group-to-RP Mapping for the
different routers selecting different group-to-rp mappings for the same group if the Group-to-RP Mappings learned in these routers are
same group. Such situations can be avoided if various mechanisms not consistent. For example: let us assume that BSR is not enabled
used to learn group-to-rp mappings are secure and consistent across in one of the routers and so it does not learn any Group-to-RP
the network. Mappings from BSR. Now the Group-to-RP Mappings learned in this
router may not be consistent with other routers in the network, it
may select a different RP or may not select any RP for a given group.
Such situations can be avoided if the mechanisms used to learn Group-
to-RP Mappings are secure and consistent across the network. Secure
transport of the mapping protocols can be accomplished by using
authentication with IPsec as described in section 6.3 of [RFC4601].
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.
 End of changes. 25 change blocks. 
51 lines changed or deleted 61 lines changed or added

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