draft-ietf-pim-group-rp-mapping-06.txt   draft-ietf-pim-group-rp-mapping-07.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: June 9, 2011 D. McWalter Expires: June 12, 2011 D. McWalter
December 6, 2010 December 9, 2010
PIM Group-to-RP Mapping PIM Group-to-RP Mapping
draft-ietf-pim-group-rp-mapping-06.txt draft-ietf-pim-group-rp-mapping-07.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.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 June 9, 2011. This Internet-Draft will expire on June 12, 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 2, line 23 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
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. Deprecation 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
skipping to change at page 3, line 24 skipping to change at page 3, line 24
physical router but it is one logical RP address and must be physical router but it is one logical RP address and must be
consistent across the PIM domain. This is usually achieved by using consistent across the PIM domain. This is usually achieved by using
the same algorithm to select the RP in all the PIM routers in a the same algorithm to select the RP in all the PIM routers in a
domain. 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] has defined an algorithm that allows PIM-STD-MIB [RFC5060] includes a number of objects to allow an
administrators to override Group-to-RP mappings with static administrator to set the precedence for Group-to-RP mappings which
configuration. But this algorithm is not completely deterministic, are learned statically or dynamically and stored in the
because it includes an implementation-specific 'precedence' value. 'pimGroupMappingTable'. The MIB module also defines an algorithm
that can be applied to the data contained in the
'pimGroupMappingTable' to determine Group-to-RP mappings. However,
this algorithm is not completely deterministic, because it 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",
skipping to change at page 10, line 5 skipping to change at page 10, line 5
* 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. This will serve as a final
tiebreaker. tiebreaker.
7. Deprecation of MIB Objects 7. Interpretation of MIB Objects
Group-to-RP mapping algorithm defined in PIM-STD-MIB [RFC5060] does The algorithm defined in this document does not use the concept of
not specify the usage of 'pimGroupMappingPrecedence' and precedence and therefore the values configured in the
'pimStaticRPPrecedence' objects in 'pimGroupMappingTable' table 'pimGroupMappingPrecedence' and 'pimStaticRPPrecedence' objects of
clearly. With the newly proposed algorithm in this document, these the 'pimGroupMappingTable' table in the PIM-STD-MIB module [RFC5060]
MIB objects would not be required. So we propose to deprecate these are not applicable to the new algorithm. The objects still retain
MIB objects from PIM-STD-MIB. Also the algorithm defined in this their meaning for 'legacy' implementations, but since the algorithm
document MUST be preferred over Group-to-RP mapping algorithm defined defined in this document is to be used in preference to that found in
in either PIM-SM[RFC4601] or in PIM-STD-MIB[RFC5060]. PIM-SM [RFC4601] and PIM-STD-MIB [RFC5060], the usage of these fields
will decline as implementations are upgraded to support the new
algorithm.
8. Clarification for MIB Objects 8. Clarification for MIB Objects
When a Group-to-RP mapping entry is created in the When a Group-to-RP mapping entry is created in the
pimGroupMappingTable in the PIM-STD MIB[RFC5060], it would be pimGroupMappingTable in the PIM-STD MIB[RFC5060], it would be
acceptable to have an entry with an RP with address type 'unknown' acceptable to have an entry with an RP with address type 'unknown'
and a PimMode of Dense Mode or SSM. These entries would represent and a PimMode of Dense Mode or SSM. These entries would represent
group ranges for Dense mode or SSM. group ranges for Dense mode or SSM.
Also all the entries which are already included in the SSM Range Also all the entries which are already included in the SSM Range
 End of changes. 7 change blocks. 
18 lines changed or deleted 24 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/