draft-ietf-pim-mtid-07.txt   draft-ietf-pim-mtid-08.txt 
PIM WG Yiqun Cai PIM WG Yiqun Cai
Internet Draft Heidi Ou Internet Draft Heidi Ou
Intended Status: Proposed Standard Intended Status: Proposed Standard
Expires: July 31, 2011 Cisco Systems, Inc. Expires: December 10, 2011 Cisco Systems, Inc.
January 31, 2011 June 10, 2011
PIM Multi-Topology ID (MT-ID) Join-Attribute PIM Multi-Topology ID (MT-ID) Join Attribute
draft-ietf-pim-mtid-07.txt draft-ietf-pim-mtid-08.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 31, 2011. This Internet-Draft will expire on December 10, 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 17 skipping to change at page 2, line 17
Abstract Abstract
This document introduces a new type of PIM Join Attribute that This document introduces a new type of PIM Join Attribute that
extends PIM signaling to identify a topology that should be used when extends PIM signaling to identify a topology that should be used when
constructing a particular multicast distribution tree. constructing a particular multicast distribution tree.
Table of Contents Table of Contents
1 Specification of Requirements ...................... 3 1 Specification of Requirements ...................... 3
2 Introduction ....................................... 3 2 Introduction ....................................... 3
3 Functional Overview ................................ 3 3 Functional Overview ................................ 4
3.1 PIM RPF Topology ................................... 3 3.1 PIM RPF Topology ................................... 4
3.2 PIM MT-ID .......................................... 4 3.2 PIM MT-ID .......................................... 5
3.3 Applicability ...................................... 5 3.3 Applicability ...................................... 6
4 Protocol Specification of PIM MT-ID ................ 5 4 Protocol Specification of PIM MT-ID ................ 6
4.1 PIM MT-ID Hello Option ............................. 5 4.1 PIM MT-ID Hello Option ............................. 6
4.2 PIM MT-ID Join Attribute ........................... 5 4.2 PIM MT-ID Join Attribute ........................... 7
4.2.1 Sending PIM MT-ID Join Attribute ................... 5 4.2.1 Sending PIM MT-ID Join Attribute ................... 7
4.2.2 Receiving PIM MT-ID Join Attribute ................. 6 4.2.2 Receiving PIM MT-ID Join Attribute ................. 7
4.2.3 Validating PIM MT-ID Join Attribute ................ 6 4.2.3 Validating PIM MT-ID Join Attribute ................ 8
4.2.4 Conflict Resolution ................................ 7 4.2.4 Conflict Resolution ................................ 9
4.2.4.1 Conflict Resolution Rules For Upstream Routers ..... 7 4.2.4.1 Conflict Resolution Rules For Upstream Routers ..... 9
4.2.4.2 Conflict Resolution Rules For Downstream Routers ... 8 4.2.4.2 Conflict Resolution Rules For Downstream Routers ... 10
5 Packet Format ...................................... 8 5 Packet Format ...................................... 10
5.1 PIM MT-ID Hello Option ............................. 8 5.1 PIM MT-ID Hello Option ............................. 10
5.2 PIM MT-ID Join Attribute TLV Format ................ 9 5.2 PIM MT-ID Join Attribute TLV Format ................ 10
6 IANA Considerations ................................ 9 6 IANA Considerations ................................ 11
7 Security Considerations ............................ 9 6.1 PIM ................................................ 11
8 Acknowledgments .................................... 10 6.2 PIM ................................................ 11
9 Authors' Addresses ................................. 10 7 Security Considerations ............................ 12
10 Normative References ............................... 10 8 Acknowledgments .................................... 12
11 Informative References ............................. 11 9 Authors' Addresses ................................. 12
10 Normative References ............................... 13
11 Informative References ............................. 13
1. Specification of Requirements 1. Specification of Requirements
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
Some unicast protocols, such as OSPF and IS-IS, allow a single Some unicast protocols, such as OSPF and IS-IS, allow a single
network to be viewed as multiple topologies [RFC4915, RFC5120]. This network to be viewed as multiple topologies [RFC4915], [RFC5120].
enables PIM to construct multicast distribution trees using separate Deploying multi-topology (MT) routing allows different paths through
network paths even when the roots of the trees are the same. the network to be selected to support different traffic, or to offer
protection paths in the event of failures.
This capability can be used to improve the resilience of multicast PIM [RFC4601] employs a technique known as Reverse Path Forwarding
applications. For instance, a multicast stream can be duplicated and (RPF) to construct forwarding trees between multicast sources and
transported using different network layer addresses simultaneously. receivers. The procedure of RPF uses topology information provided
Assuming that two source trees, (S1, G1) and (S1, G2), are used for by routing protocols, such as OSPF and IS-IS. If PIM was able to
the stream. By using MT capable unicast routing protocols and access the multiple topologies created by the routing protocols, it
procedures described in this document, it is possible to construct would be possible to construct multicast forwarding trees using
two source trees for (S1, G1) and (S1, G2) in such a way that they do separate network paths even when the roots of the trees are the same.
not share any transit network segment. As a result, a single network
failure will not cause any loss to the stream.
This draft introduces a new type of PIM Join Attribute used to encode This capability would facilitate an improvement to the resilience of
the identity of the topology PIM uses for RPF. It is based on multicast applications. For instance, a multicast stream can be
[RFC5384], and specifies additional procedures and rules to process duplicated and transported using two source trees, (S1, G1) and (S1,
the attribute and resolve conflict. The draft does not introduce any G2), simultaneously. By using MT capable unicast routing protocols
change to the RPF check procedure used to verify the incoming and procedures described in this document, it is possible to
interface when a packet is forwarded. As an example to use the construct two source trees for (S1, G1) and (S1, G2) in such a way
capability described by this draft, an application can choose to use that they do not share any transit network segment. As a result, a
group addresses, and/or source addresses, to identify a unique single network failure will not cause any loss to the stream.
This document introduces a new type of PIM Join Attribute [RFC5384],
named MT-ID Join Attribute. It is used to encode the numerical
identity of the topology PIM uses when performing RPF for the
forwarding tree that is being joined. This document also specifies
procedures and rules to process the attribute and resolve conflicts
arising from mismatches in capabilities to support the attribute or
the value of the attribute.
This document does not introduce any change to the RPF check
procedure used to verify the incoming interface when a packet is
forwarded as defined in [RFC4601]. For example, to use the
capability described by this document, an application can choose to
use group addresses, and/or source addresses, to identify a unique
multicast stream. It might further need to perform the functions of multicast stream. It might further need to perform the functions of
splitting and merging. But the detailed processing is beyond the splitting and merging. But the detailed processing is beyond the
scope of the document. scope of the document.
In the rest of the document, the MT-ID Join Attribute may be simply
referred to as "MT-ID".
3. Functional Overview 3. Functional Overview
3.1. PIM RPF Topology 3.1. PIM RPF Topology
PIM RPF topology is a collection of routes used by PIM to perform RPF PIM RPF topology is a collection of routes used by PIM to perform RPF
operation when building shared or source trees. In the rest of the operation when building shared or source trees. The routes in the
document, PIM RPF topology may be simply referred to as "topology" topology may be contributed by different protocols. In the rest of
when there is no ambiguity. the document, PIM RPF topology may be simply referred to as
"topology" when there is no ambiguity.
In a multi-topology environment, multiple RPF topologies can be In a multi-topology environment, multiple RPF topologies can be
created in the same network. A particular source may be reachable in created in the same network. A particular source may be reachable in
only one of the topologies, or in several of them via different only one of the topologies, or in several of them via different
paths. paths.
To select the RPF topology for a particular multicast distribution To help explain the relationship between MT capable unicast routing
tree, one or more of the following can be done. protocol and MT capable RPF topologies, please consider the following
example.
1. configure a policy that maps a group range to a topology. When +++ A +++ B +++
RPF information needs to be resolved for the RP or the sources + +
for a group within the range, the RPF lookup takes place in the S -- R1 R2 -- receivers
specified topology. This can be used for PIM-SM/SSM/Bidir. * *
*** C *** D ***
2. configure a policy that maps a source prefix range to a - The traffic source is S. S is announced by R1 using MBGP to
topology. This can be used for PIM-SM and PIM-SSM. every router. This route is installed in every topology.
3. use the topology identified by the Join Attribute encoding in - Two topologies are created in the unicast IGP, let us call them
the received PIM packets. OSPF 1000 and OSPF 2000. OSPF 1000 includes A, B and interfaces
in R1 and R2 that are configured to be part of OSPF 1000. OSPF
2000 includes C, D and interfaces on R1 and R2 that are
configured to be part of OSPF 2000.
The details of the first two methods are implementation specific and - Two PIM RPF topologies are created, let us call them PIM 500 and
are not discussed in this document. The specification to support the PIM 600.
third method is included in this document.
PIM 500 comprises the following routes: S announced by MBGP and
those learned via OSPF 1000.
PIM 600 comprises the following routes: S announced by MBGP and
those learned via OSPF 2000
The above example shows that the naming spaces of MT-ID are not
required to be the same between PIM and IGPs. Furthermore, a unicast
IGP topology and the PIM RPF topology to which the IGP topology
contributes routes are not required to have the same set of routes.
In the above example, the prefix covering S does not exist in either
OSPF 1000 or OSPF 2000. But since it exists in PIM 500 and PIM 600,
R2 is able to join to it via either path.
There are two methods to select the RPF topology for a particular
multicast distribution tree, via configuration or via PIM.
When it is done via configuration, a network administrator configures
a policy that maps a group range to a topology, and/or maps a source
prefix range to a topology. Using the same example, the policy can
say that to build a forwarding tree for G1 only routes in PIM 500 are
to be used, and to build a forward tree for G2 only routes in PIM 600
are used. The result is that packets for (S, G1) will follow the
path of S-R1-A-B-R2 and packets for (S, G2) will follow the path of
S-R1-C-D-R2.
An alternative to static configuration is to include the RPF topology
information as a new PIM Join Attribute in the PIM Join packets sent
by downstream routers.
Both methods can be used at the same time. The details of the first
method are implementation specific and are not discussed in this
document. The specification to support the second method is included
in this document.
3.2. PIM MT-ID 3.2. PIM MT-ID
For each PIM RPF topology created, a unique numerical ID is assigned For each PIM RPF topology created, a unique numerical ID is assigned
per PIM domain. This ID is called PIM MT-ID. PIM MT-ID has the per PIM domain. This ID is called the PIM MT-ID. The PIM MT-ID has
following property, the following properties,
- it is the path identifier that is used by PIM control plane, but - It is the path identifier that is used by PIM control plane, but
does not function in the forwarding state for a specific does not function in the forwarding state for a specific
topology. The differentiation for topologies on forwarding plane topology. The differentiation for topologies on forwarding plane
is made by different group addresses, and/or source addresses is made by different group addresses, and/or source addresses
instead. instead.
- this value is not required to be the same as the MT-ID used by - As shown earlier, this value is not required to be the same as
the unicast routing protocols that contribute routes to the the MT-ID used by the unicast routing protocols that contribute
topology. In practice, when only one unicast routing protocol routes to the topology. In practice, when only one unicast
(such as OSPF or IS-IS) is used, PIM MT-ID is recommended to be routing protocol (such as OSPF or IS-IS) is used, the PIM MT-ID
assigned using the same value as the IGP topology identifier. is RECOMMENDED to be assigned using the same value as the IGP
This is for the purpose of reducing management overhead and topology identifier. Using the same example presented earlier, if
every route in PIM 500 is contributed by OSPF 1000, it is
RECOMMENDED to name this RPF topology as PIM 1000 instead of PIM
500. This is for the purpose of reducing management overhead and
simplifying troubleshooting. simplifying troubleshooting.
- this value must be unique and consistent within the network - This value must be unique and consistent within the network
domain for the same topology. For actual deployment, one should domain for the same topology. For example, PIM 500 MUST refer to
have a means to detect inconsistency of the MT-ID configuration, the same topology on routers R1, C, D and R2. For actual
but the detail of such mechanism is beyond the scope of this deployment, one should have a means to detect inconsistency of
document. the PIM MT-ID configuration, but the detail of such mechanism is
beyond the scope of this document.
- 0 is reserved as the default, and MUST NOT be included in the - 0 is reserved as the default, and MUST NOT be included in the
join attribute encoding. Join Attribute encoding.
- how to assign a PIM MT-ID to a topology is decided by the network - How to assign a PIM MT-ID to a topology is decided by the network
administrator and is outside the scope of this document administrator and is outside the scope of this document
3.3. Applicability 3.3. Applicability
The PIM MT-ID join attribute described in this draft applies to PIM The PIM MT-ID Join Attribute described in this document applies to
Join/Assert packets used by PIM SM/SSM/Bidir. It is not used in any PIM Join/Assert packets used by PIM SM/SSM/Bidir. It is not used in
other PIM packets, such as Prune, Register, Register-Stop, Graft, any other PIM packets. As such, it can only be used to build shared
Graft-ack, DF Election, Candidate-RP, and Bootstrap. As such, it can or source trees for PIM SM/SSM and PIM-bidir downstream.
only be used to build shared or source trees for PIM SM/SSM and PIM-
bidir downstream.
When this attribute is used in combination with RPF vectors defined When this attribute is used in combination with RPF vectors defined
in [RFC5496] [ID.ietf-l3vpn-2547bis-mcast], they are processed in [RFC5496] and [ID.ietf-l3vpn-2547bis-mcast], the vectors are
against the topology identified by the PIM MT-ID attribute. processed against the topology identified by the PIM MT-ID attribute.
4. Protocol Specification of PIM MT-ID 4. Protocol Specification of PIM MT-ID
The change to the PIM protocol includes two pieces, PIM MT-ID Hello The change to the PIM protocol includes two pieces, PIM MT-ID Hello
Option and PIM MT-ID Join Attribute. Option and PIM MT-ID Join Attribute.
4.1. PIM MT-ID Hello Option 4.1. PIM MT-ID Hello Option
A router MUST include both PIM MT-ID and PIM Join Attribute Hello PIM MT-ID Hello Option is used by a router to indicate if it supports
Option in its PIM Hello packets if it supports functionality the functionality described by this document. If it does, it MUST
described by this document. include the PIM Hello Option in its PIM Hello packets and MUST
include both the Join Attribute Option [RFC5384] and the new PIM MT-
ID Option (see Section 5.1 of this document for packet format).
4.2. PIM MT-ID Join Attribute 4.2. PIM MT-ID Join Attribute
4.2.1. Sending PIM MT-ID Join Attribute 4.2.1. Sending PIM MT-ID Join Attribute
When a PIM router originates a PIM Join/Assert packet, it may choose When a PIM router originates a PIM Join/Assert packet, it may choose
to encode PIM MT-ID of the topology in which RPF lookup takes place to encode PIM MT-ID of the topology in which RPF lookup is to take
for the corresponding (*,G) or (S,G) entry. The chosen PIM MT-ID MUST place for the corresponding (*,G) or (S,G) entry. The PIM MT-ID
be the one decided by local topology selection configuration if it identifies the topology chosen by local policy/configuration or is
exists, or the one received from downstream routers after conflict the value received from downstream routers after MT-ID conflict
resolution procedures are applied. resolution procedures have been applied (See Section 4.2.4 for
further detail).
The following are the exceptions, The following are the exceptions,
- a router MUST NOT attach the attribute if PIM MT-ID is 0. The
- A router MUST NOT include the attribute if PIM MT-ID is 0. The
value of 0 is ignored on reception. value of 0 is ignored on reception.
- a router SHOULD NOT do so if the upstream router, or any of the - A router SHOULD NOT include PIM MT-ID in its Join/Assert packets
routers on the LAN does not include "PIM Join Attribute" or "PIM if the upstream router, or any of the routers on the LAN does not
MT-ID" option in its Hello packets. include "PIM Join Attribute" or "PIM MT-ID" Option in its Hello
packets.
- a router SHOULD NOT encode PIM MT-ID for pruned sources. If - A router SHOULD NOT attach PIM MT-ID for pruned sources. PIM
encoded, the value is ignored. MT-ID MUST be ignored for a pruned source by a router processing
the Prune message.
4.2.2. Receiving PIM MT-ID Join Attribute 4.2.2. Receiving PIM MT-ID Join Attribute
When a PIM router receives a PIM MT-ID join attribute in a When a PIM router receives a PIM MT-ID Join Attribute in a
Join/Assert packet, it MUST perform the following, Join/Assert packet, it MUST perform the following,
- validate the attribute encoding. The detail is described in the - Validate the attribute encoding. The detail is described in the
next section. next section.
- if the join attribute is valid, use the rules described in the - If the Join Attribute is valid, use the rules described in the
section "Conflict Resolution" to determine a PIM MT-ID to use. section "Conflict Resolution" to determine a PIM MT-ID to use.
- use the topology identified by the selected PIM MT-ID to perform - Use the topology identified by the selected PIM MT-ID to perform
RPF lookup for the (*,G)/(S,G) entry unless a different topology RPF lookup for the (*,G)/(S,G) entry unless a different topology
is specified by a local configuration. The local configuration is specified by a local configuration. The local configuration
always takes precedence. always takes precedence.
While it is an exception case, it is worthwhile to describe what will
happen if a router receives PIM MT-ID Join Attribute but doesn't
support functionality described in [RFC5384] or this document.
If the router supports [RFC5384] but not this document, it is able to
skip PIM MT-ID Join Attribute and move on to the next Join Attribute
if one is present. The RPF decision will not be altered because the
router doesn't understand the meaning of PIM MT-ID Join Attribute.
The router will use the procedures described by [RFC5384] to perform
conflict resolution.
If a router doesn't support [RFC5384], it will ignore the Join/Assert
message because it is not able to parse the encoded sources.
If a router does support both [RFC5384] and this document, but choose
not to send either PIM MT-ID or PIM Join Attribute Option in its
Hello packets (likely due to administrative reason), when it receives
a PIM Join/Assert packets with PIM MT-ID Join Attribute, it SHOULD
ignore the Join/Assert message.
4.2.3. Validating PIM MT-ID Join Attribute 4.2.3. Validating PIM MT-ID Join Attribute
An upstream router must be known to support this draft in order for a An upstream router MUST be known to support this document in order
downstream router to include the PIM MT-ID attribute in its Join for a downstream router to include the PIM MT-ID attribute in its
packets. But an upstream router doesn't need to know if a downstream Join packets. But an upstream router doesn't need to know if a
router supports this draft or not when deciding whether to accept the downstream router supports this document or not when deciding whether
attribute. Hence, if the Join packet sender doesn't include "PIM Join to accept the attribute. Hence, if the Join packet sender doesn't
Attribute" or "PIM MT-ID" options in its Hello packets, the PIM MT-ID include "PIM Join Attribute" or "PIM MT-ID" options in its Hello
attribute in the Join may still be considered valid. This is also in packets, the PIM MT-ID attribute in the Join may still be considered
accordance with the "Robustness Principle" outlined in [RFC761]. valid. This is also in accordance with the "Robustness Principle"
outlined in [RFC761].
The following text specifies the detail of the validity check. The following text specifies the detail of the validity check.
- there is at most 1 PIM MT-ID attribute encoded. If there are - There is at most 1 PIM MT-ID attribute encoded. If there are
multiple PIM MT-ID Join Attributes included, only the last one is multiple PIM MT-ID Join Attributes included, only the last one is
accepted for this particular source. Processing of the rest of accepted for this particular source. Processing of the rest of
the Join message continues. the Join message continues.
- the length field must be 2. If the length field is not 2, the - The length field must be 2. If the length field is not 2, the
rest of the Join message, including the current (S,G) or (*,G) rest of the Join message, including the current (S,G) or (*,G)
entry, MUST be ignored. The group, source and the RP in the Join entry, MUST be ignored. The group, source and the RP in the Join
message that have already been processed SHOULD still be message that have already been processed SHOULD still be
considered valid. considered valid.
- the value MUST not be 0. If it is 0, the PIM MT-ID attribute is - The value MUST NOT be 0. If it is 0, the PIM MT-ID attribute is
ignored. Processing of the rest of the Join message, including ignored. Processing of the rest of the Join message, including
the current (S,G) or (*,G) entry, continues as if the particular the current (S,G) or (*,G) entry, continues as if the particular
PIM MT-ID attribute weren't present in the packet. PIM MT-ID attribute weren't present in the packet.
4.2.4. Conflict Resolution 4.2.4. Conflict Resolution
The definition of "PIM MT-ID conflict" varies depending on whether it The definition of "PIM MT-ID conflict" varies depending on whether it
is on an upstream or a downstream router. is on an upstream or a downstream router.
On an upstream router, a conflict occurs when the router doesn't have PIM MT-ID conflicts arises on an upstream router when the router
local topology selection policy and it has received different PIM doesn't have a local topology selection policy and receives Join
MT-ID from Join packets sent by its downstream routers or Assert packets from downstream routers and/or Assert packets from other
packets from another forwarding router on the LAN. In another word, forwarding routers on the LAN and those packets contain different PIM
if an upstream router has a local configuration that specifies a MT-IDs.
different topology than that from an incoming Join/Assert packet,
including the case PIM MT-ID is not encoded in the incoming packet,
it does not apply the conflict resolution procedures.
On the other hand,when a downstream router sees a different PIM MT-ID However, if an upstream router has a local configuration that
attribute from other routers on the LAN it applies rules to resolve specifies PIM MT-IDs to identify RPF topologies, and those MT-IDs do
the conflicts regardless of whether the router has local topology not match the MT-ID on a received Join or Assert packet, this is not
selection policy or not. considered to be a conflict and the resolution procedures are not
applied. This includes the case where there are local PIM MT-IDs,
but there is no PIM MT-ID encoded in the incoming packet.
It MUST be noted that the MT-ID value being considered for comparison On the other hand, when a downstream router sees a different PIM MT-
does not include the four reserved bits. That is, only the lower ID attribute from other routers on the LAN it applies rules to
order 12 bits are used in resolving conflicting attributes. resolve the conflicts regardless of whether the router has local
topology selection policy or not.
When two PIM MT-IDs are compared, only the 12-bit Value field (see
Section 5.2) is compared. Other fields of the PIM MT-ID Join
Attribute TLV Format (including the four reserved bits) MUST NOT be
used in the comparison.
4.2.4.1. Conflict Resolution Rules For Upstream Routers 4.2.4.1. Conflict Resolution Rules For Upstream Routers
- if an upstream router receives different PIM MT-ID attributes - If an upstream router receives different PIM MT-ID attributes
from PIM Join packets, it MUST follow the rules specified in from PIM Join packets, it MUST follow the rules specified in
[RFC5384] to select one. The PIM MT-ID chosen will be the one [RFC5384] to select one. The PIM MT-ID chosen will be the one
encoded for its upstream neighbor. encoded for its upstream neighbor.
In order to minimize the chances of potential transient In order to minimize the chances of potential transient
forwarding loops, an upstream router MAY choose to ignore the forwarding loops, an upstream router MAY choose to ignore the
incoming PIM Join/Prune packets all together if it sees a incoming PIM Join packets all together if it sees a conflict in
conflict in PIM MT-ID attributes. This action may also be taken PIM MT-ID attributes. This action may also be taken by an
by an upstream router which has locally configured topology upstream router which has locally configured topology selection
selection policy, as an exception to the rules described above. policy, as an exception to the rules described above.
- if an upstream router receives a different PIM MT-ID attribute in - If an upstream router receives a different PIM MT-ID attribute in
an ASSERT packet, it MUST use the tie-breaker rules as specified an ASSERT packet, it MUST use the tie-breaker rules as specified
in [RFC4601] to determine an ASSERT winner. PIM MT-ID is not in [RFC4601] to determine an ASSERT winner. PIM MT-ID is not
considered in deciding a winner from Assert process. considered in deciding a winner from Assert process.
4.2.4.2. Conflict Resolution Rules For Downstream Routers 4.2.4.2. Conflict Resolution Rules For Downstream Routers
- if a downstream router sees different PIM MT-ID attributes from - If a downstream router sees different PIM MT-ID attributes from
PIM Join packets, it MUST follow the specification of [RFC4601] PIM Join packets, it MUST follow the specification of [RFC4601]
as if the attribute did not exist. For example, the router as if the attribute did not exist. For example, the router
suppresses its own Join packet if a Join for the same (S,G) is suppresses its own Join packet if a Join for the same (S,G) is
seen. seen.
The router MUST NOT use the rules specified in [RFC5384] to The router MUST NOT use the rules specified in [RFC5384] to
select a PIM MT-ID from Join packets sent by other downstream select a PIM MT-ID from Join packets sent by other downstream
routers. routers.
- if a downstream router sees its preferred upstream router loses - If a downstream router sees its preferred upstream router loses
in the ASSERT process, and the ASSERT winner uses a different PIM in the ASSERT process, and the ASSERT winner uses a different PIM
MT-ID, the downstream router SHOULD still choose the ASSERT MT-ID, the downstream router SHOULD still choose the ASSERT
winner as the RPF neighbour but it MUST NOT encode PIM MT-ID when winner as the RPF neighbour but it MUST NOT encode PIM MT-ID when
sending Join packets to it. sending Join packets to it.
5. Packet Format 5. Packet Format
5.1. PIM MT-ID Hello Option 5.1. PIM MT-ID Hello Option
0 1 2 3 0 1 2 3
skipping to change at page 9, line 17 skipping to change at page 11, line 9
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr Type | Length |R R R R| Value | |F|E| Attr Type | Length |R R R R| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- F bit: 0 Non-transitive Attribute. - F bit: 0 Non-transitive Attribute.
- E bit: As specified by [RFC5384]. - E bit: As specified by [RFC5384].
- Attr Type: 3. - Attr Type: To be assigned by IANA.
- Length: 2. - Length: 2.
- R: Reserved bits, 4 in total. - R: Reserved bits, 4 in total.
- Value: PIM MT-ID, 1 to 4095. Range 2048 to 4095 are for - Value: PIM MT-ID, 1 to 4095.
experimental and proprietary use.
6. IANA Considerations 6. IANA Considerations
A new PIM Hello Option type, 30, has been assigned for PIM MT-ID 6.1. PIM
Hello Option. The detail is in [HELLO].
A new PIM Join Attribute type needs to be assigned. 3 is proposed for The IANA maintains a registry of "Protocol Independent Multicast
now. (PIM) Parameters" with a sub-registry called "PIM-Hello Options"
The IANA assigned the PIM Hello Option type value 30 for the PIM MT-
ID Hello Option according to the First Come First Served allocation
policy.
The IANA is requested to make that allocation permanent with
reference to this document.
Note that the option defined in Section 5.1 of this document has
length 0. The IANA is requested to update the length value recorded
in the registry.
6.2. PIM
The IANA maintains a registry of "Protocol Independent Multicast
(PIM) Parameters" with a sub-registry called "PIM Join Attribute
Types".
The IANA is requested to assign the next available value for the PIM
MT-ID Join Attribute defined in Section 5.2 of this document.
7. Security Considerations 7. Security Considerations
As described in [RFC5384], the security of the Join Attribute is only
guaranteed by the security of the PIM packet that carries it.
Similarly, the security of the Hello Options is only guaranteed by
securing the whole Hello Packet.
In view of the fact that malicious alteration of the PIM MT-ID Hello
Option or the PIM MT-ID carried in a packet might cause the PIM
resiliency goals to be violated, the security considerations of
[RFC4601] apply to the extensions described in this document.
As a type of PIM Join Attribute, the security considerations As a type of PIM Join Attribute, the security considerations
described in [RFC5384] apply here. Specifically, malicious alteration described in [RFC5384] apply here. Specifically, malicious alteration
of PIM MT-ID may cause the resiliency goals to be violated. of PIM MT-ID may cause the resiliency goals to be violated.
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Eric Rosen, Ice Wijnands, Dino The authors would like to thank Eric Rosen, Ice Wijnands, Dino
Farinacci, Colby Barth, Les Ginsberg, Dimitri Papadimitriou, Thomas Farinacci, Colby Barth, Les Ginsberg, Dimitri Papadimitriou, Thomas
Morin and Hui Liu for their input. Morin and Hui Liu for their input.
And the authors would also like to thank Adrian Farrel for his
detailed and constructive comments during the AD review.
9. Authors' Addresses 9. Authors' Addresses
Yiqun Cai Yiqun Cai
Cisco Systems, Inc Cisco Systems, Inc
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
E-mail: ycai@cisco.com E-mail: ycai@cisco.com
Heidi Ou Heidi Ou
skipping to change at page 11, line 19 skipping to change at page 13, line 31
[RFC4915] P. Psenak, S. Mirtorabi, A. Roy, L. Nguyen, P. Pillay- [RFC4915] P. Psenak, S. Mirtorabi, A. Roy, L. Nguyen, P. Pillay-
Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007. Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007.
[RFC5120] T. Przygienda, N. Shen, N. Sheth, "M-ISIS: Multi Topology [RFC5120] T. Przygienda, N. Shen, N. Sheth, "M-ISIS: Multi Topology
(MT) Routing in Intermediate System to Intermediate Systems (IS- (MT) Routing in Intermediate System to Intermediate Systems (IS-
ISs)", RFC 5120, February 2008. ISs)", RFC 5120, February 2008.
[RFC5496] I. Wijnands, A. Boers, E. Rosen, "The Reverse Path [RFC5496] I. Wijnands, A. Boers, E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496, March 2009. Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
[HELLO] IANA, "PIM-Hello Options",
http://www.iana.org/assignments/pim-parameters/pim-
parameters.xhtml#pim-parameters-1
[ID.ietf-l3vpn-2547bis-mcast] E. Rosen,R Aggarwal, "Multicast in [ID.ietf-l3vpn-2547bis-mcast] E. Rosen,R Aggarwal, "Multicast in
MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10, January 2010 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10, January 2010
 End of changes. 55 change blocks. 
152 lines changed or deleted 271 lines changed or added

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