Transcript PowerPoint Presentation - Group-to

Group-to-RP Mapping
IETF Draft:
draft-ietf-pim-group-rp-mapping-00
Authors:
Andy Kessler, Cisco Systems
Bharat Joshi, Infosys Technologies Ltd.
David McWalter, Data Connection Ltd
Session_ID
Presentation_ID
© 2008 Cisco Systems, Inc. All rights reserved.
Cisco Public
1
Need for Standard Algorithm
Need for standard deterministic algorithm
 No existing RFC/Draft defines a complete
algorithm
 A standard algorithm is required for interop
Resolves cases in which there are several group
mappings for a single group from different
sources
 A standard algorithm could be used to
determine the selected RP by an independent
network management system
Session_ID
Presentation_ID
© 2008 Cisco Systems, Inc. All rights reserved.
Cisco Public
2
What is new in this Rev ?
 Hash function is removed from Algorithm
RFC 4601 and RFC 5059 suggested use of hash function is
removed – discussed on PIM list and was agreed
 New Section – Clarification of MIB Objects
Clarifies support for SSM and DM in group mapping table
 New Use Case – Network Mgmt Systems
 Algorithm explicitly deals with SSM and DM Group
types
 Draft now states that new algorithm deprecates grouprp-mapping algorithm in RFC 4601 and RFC 5060
Session_ID
Presentation_ID
© 2008 Cisco Systems, Inc. All rights reserved.
Cisco Public
3
Clarification of MIB Objects
Support for all multicast group ranges
It is acceptable to represent SSM and DM groups in
the pimGroupMappingTable in the PIM-STD MIB
SSM and DM entries would have an RP with an
address type of ‘unknown’ and a PIM mode of
Dense Mode or SSM
Creates one stop shopping for all multicast group
mappings
- Useful for NMS apps
Session_ID
Presentation_ID
© 2008 Cisco Systems, Inc. All rights reserved.
Cisco Public
4
Use Cases
 Default static Group-to-RP mappings with
dynamically learned entries
Default infrastructure for general purpose apps and
specific mappings for special apps that change more often
 Static Group-to-RP mappings with overridedynamic flag
Network Operators need to ability to nail down the RP
mappings statically and ignore all dynamic messages
 Migration situations
After acquisitions or mergers companies will need
deterministic method to move from one RP mapping
method to another (e.g. AutoRP to BSR)
 Use by Management Systems
Ability for NMS to determine Group-RP-Mappings used by a
router
Session_ID
Presentation_ID
© 2008 Cisco Systems, Inc. All rights reserved.
Cisco Public
5
Proposed Algorithm
The RP would be selected with this preference:
1. Embedded RP
2. Static with 'override-dynamic' flag
3. Longest match
4. PIM-Bidir over PIM-SM
5. Origin preference - bsr, auto-rp, static and
other
6. Highest IP address
Session_ID
Presentation_ID
© 2008 Cisco Systems, Inc. All rights reserved.
Cisco Public
6
Current Issues with Draft
 Minor Typos
?
Session_ID
Presentation_ID
© 2008 Cisco Systems, Inc. All rights reserved.
Cisco Public
7
References
 Section 1.1 of RFC 5059 - BSR Mechanism for PIM
... the router chooses only one of the RPs by applying a
deterministic algorithm so that all routers in the domain
make the same choice. It is important to note that this
algorithm is part of the specification of the individual
routing protocols (and may differ among them), not of the
BSR specification.
 Section 3.3 of RFC 5059 - BSR Mechanism for PIM
If the BSR learns of both BIDIR and PIM-SM Candidate-RPs
for the same group range, the BSR MUST only include RPs
for one of the protocols in the BSMs. The default behavior
SHOULD be to prefer BIDIR.
Session_ID
Presentation_ID
© 2008 Cisco Systems, Inc. All rights reserved.
Cisco Public
8
References
 Section 4.7.1 of RFC 4601 - PIM-SM Protocol Spec
Describes the existing algorithm for choosing a group from
multiple Group-to-RP Mapping. It does not address these
issues
– Does not consider the origin of a group-to-rp mapping
(e.g. bsr, autorp, static, etc)
– Allow for static override
– Doesn't allow for higher priority of PIM-Bidir over PIM-SM
 Section 4.7.2 of RFC 4601 - PIM-SM Protocol Spec
Describes the Hash function and talks about the highest IP
address but only after the hash function.
Session_ID
Presentation_ID
© 2008 Cisco Systems, Inc. All rights reserved.
Cisco Public
9
References
 Section 7.1 of RFC 3956 - Embedded RP for IPv6
To avoid loops and inconsistencies, for addresses in the
range FF70::/12, the Embedded-RP mapping MUST be
considered the longest possible match and higher priority
than any other mechanism.
Session_ID
Presentation_ID
© 2008 Cisco Systems, Inc. All rights reserved.
Cisco Public
10