draft-ietf-pim-mtid-04.txt   draft-ietf-pim-mtid-05.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: September 29, 2010 Cisco Systems, Inc. Expires: March 22, 2011 Cisco Systems, Inc.
March 29, 2010 September 22, 2010
PIM Multi-Topology ID (MT-ID) Join-Attribute PIM Multi-Topology ID (MT-ID) Join-Attribute
draft-ietf-pim-mtid-04.txt draft-ietf-pim-mtid-05.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 September 29, 2010. This Internet-Draft will expire on March 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 3, line 31 skipping to change at page 3, line 31
Assuming that two source trees, (S1, G1) and (S1, G2), are used for Assuming that two source trees, (S1, G1) and (S1, G2), are used for
the stream. By using MT capable unicast routing protocols and the stream. By using MT capable unicast routing protocols and
procedures described in this document, it is possible to construct procedures described in this document, it is possible to construct
two source trees for (S1, G1) and (S1, G2) in such a way that they do two source trees for (S1, G1) and (S1, G2) in such a way that they do
not share any transit network segment. As a result, a single network not share any transit network segment. As a result, a single network
failure will not cause any loss to the stream. failure will not cause any loss to the stream.
This draft introduces a new type of PIM Join Attribute used to encode This draft introduces a new type of PIM Join Attribute used to encode
the identity of the topology PIM uses for RPF. It is based on the identity of the topology PIM uses for RPF. It is based on
[RFC5384], and specifies additional procedures and rules to process [RFC5384], and specifies additional procedures and rules to process
the attribute and resolve conflict. the attribute and resolve conflict. The draft does not introduce any
change to the RPF check procedure used to verify the incoming
interface when a packet is forwarded.
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. In the rest of the
document, PIM RPF topology may be simply referred to as "topology" document, PIM RPF topology may be simply referred to as "topology"
when there is no ambiguity. when there is no ambiguity.
skipping to change at page 4, line 35 skipping to change at page 4, line 35
- this value is not required to be the same as the MT-ID used by - this value is not required to be the same as the MT-ID used by
the unicast routing protocols that contribute routes to the the unicast routing protocols that contribute routes to the
topology. In practice, when only one unicast routing protocol topology. In practice, when only one unicast routing protocol
(such as OSPF or IS-IS) is used, PIM MT-ID is recommended to be (such as OSPF or IS-IS) is used, PIM MT-ID is recommended to be
assigned using the same value as the IGP topology identifier. assigned using the same value as the IGP topology identifier.
This is for the purpose of reducing management overhead and 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 domain for the same topology. For actual deployment, one should
have a means to detect inconsistency of the 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 draft applies to PIM
skipping to change at page 6, line 26 skipping to change at page 6, line 26
- 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.
4.2.3. Validating PIM MT-ID Join Attribute 4.2.3. Validating PIM MT-ID Join Attribute
An encoded PIM MT-ID join attribute is valid if all of the following An upstream router must be known to support this draft in order for a
conditions are satisfied, downstream router to include the PIM MT-ID attribute in its Join
packets. But an upstream router doesn't need to know if a downstream
router supports this draft or not when deciding whether to accept the
attribute. Hence, if the Join packet sender doesn't include "PIM Join
Attribute" or "PIM MT-ID" options in its Hello packets, the PIM MT-ID
attribute in the Join may still be considered valid. This is also in
accordance with the "Robustness Principle" outlined in [RFC761].
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. accepted for this particular source. Processing of the rest of
the Join message continues.
- the length field must be 2 and the value must not be 0.
If an encoded PIM MT-ID join attribute is deemed invalid, it is - the length field must be 2. If the length field is not 2, the
silently ignored. The packet is processed as if the attribute were rest of the Join message, including the current (S,G) or (*,G)
not present. entry, MUST be ignored. The group, source and the RP in the Join
message that have already been processed SHOULD still be
considered valid.
It is important to note that, if the sender is not a PIM neighbor - the value MUST not be 0. If it is 0, the PIM MT-ID attribute is
that has included "PIM Join Attribute" or "PIM MT-ID" option in its ignored. Processing of the rest of the Join message, including
Hello packets, the encoding may still be considered valid by an the current (S,G) or (*,G) entry, continues as if the particular
implementation. PIM MT-ID attribute weren't present in the packet.
4.2.4. Conflict Resolution 4.2.4. Conflict Resolution
It is important to note that the definition of "PIM MT-ID conflict" The definition of "PIM MT-ID conflict" varies depending on whether it
varies depending on whether it is on an upstream or a downstream is on an upstream or a downstream router.
router.
On an upstream router, a conflict occurs when the router doesn't have On an upstream router, a conflict occurs when the router doesn't have
local topology selection policy and it has received different PIM local topology selection policy and it has received different PIM
MT-ID from Join packets sent by its downstream routers or Assert MT-ID from Join packets sent by its downstream routers or Assert
packets from another forwarding router on the LAN. In another word, packets from another forwarding router on the LAN. In another word,
if an upstream router has a local configuration that specifies a if an upstream router has a local configuration that specifies a
different topology than that from an incoming Join/Assert packet, different topology than that from an incoming Join/Assert packet,
including the case PIM MT-ID is not encoded in the incoming packet, including the case PIM MT-ID is not encoded in the incoming packet,
it does not apply the conflict resolution procedures. it does not apply the conflict resolution procedures.
skipping to change at page 11, line 7 skipping to change at page 11, line 7
[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 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", RFC 4601, August 2006. Specification (Revised)", RFC 4601, August 2006.
[RFC5384] A. Boers, I. Wijnands, E. Rosen, "The Protocol Independent [RFC5384] A. Boers, I. Wijnands, E. Rosen, "The Protocol Independent
Multicast (PIM) Join Attribute Format", RFC 5384, November 2008 Multicast (PIM) Join Attribute Format", RFC 5384, November 2008
11. Informative References 11. Informative References
[RFC761] ISI, "Transmission Control Protocol", RFC 761, January 1980.
[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.
 End of changes. 12 change blocks. 
21 lines changed or deleted 36 lines changed or added

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