draft-ietf-pim-explicit-rpf-vector-09.txt   rfc7891.txt 
Network Working Group J. Asghar Internet Engineering Task Force (IETF) J. Asghar
Internet-Draft IJ. Wijnands, Ed. Request for Comments: 7891 IJ. Wijnands, Ed.
Intended status: Standards Track S. Krishnaswamy Category: Standards Track S. Krishnaswamy
Expires: October 28, 2016 A. Karan ISSN: 2070-1721 A. Karan
Cisco Systems Cisco Systems
V. Arya V. Arya
DIRECTV Inc. DIRECTV Inc.
April 26, 2016 June 2016
Explicit RPF Vector Explicit Reverse Path Forwarding (RPF) Vector
draft-ietf-pim-explicit-rpf-vector-09.txt
Abstract Abstract
The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496 The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496
can be included in a PIM Join Attribute such that the RPF neighbor is can be included in a PIM Join Attribute such that the RPF neighbor is
selected based on the unicast reachability of the RPF Vector instead selected based on the unicast reachability of the RPF Vector instead
of the Source or Randezvous Point associated with the multicast tree. of the source or Rendezvous Point associated with the multicast tree.
This document defines a new RPF Vector Attribute type such that an This document defines a new RPF Vector Attribute type such that an
explicit RPF neighbor list can be encoded in the PIM Join Attribute, explicit RPF neighbor list can be encoded in the PIM Join Attribute,
bypassing the unicast route lookup. thus bypassing the unicast route lookup.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on October 28, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7891.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 3 2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Use of the PIM Explicit RPF Vector . . . . . . . . . . . . . 4 4. Use of the PIM Explicit RPF Vector . . . . . . . . . . . . . 4
5. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . 4 5. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . 5
6. Mixed Vector Processing . . . . . . . . . . . . . . . . . . . 5 6. Mixed Vector Processing . . . . . . . . . . . . . . . . . . . 5
7. Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . . 5 7. Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . . 5
8. PIM Asserts . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. PIM Asserts . . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Join Suppression . . . . . . . . . . . . . . . . . . . . . . 6 9. Join Suppression . . . . . . . . . . . . . . . . . . . . . . 6
10. Unsupported Explicit Vector Handling . . . . . . . . . . . . 6 10. Unsupported Explicit Vector Handling . . . . . . . . . . . . 7
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
12. Security Considerations . . . . . . . . . . . . . . . . . . . 7 12. Security Considerations . . . . . . . . . . . . . . . . . . . 7
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 13.1. Normative References . . . . . . . . . . . . . . . . . . 8
14.1. Normative References . . . . . . . . . . . . . . . . . . 7 13.2. Informative References . . . . . . . . . . . . . . . . . 8
14.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The procedures in [RFC5496] define how a RPF vector can be used to The procedures in [RFC5496] define how an RPF Vector can be used to
influence the path selection in the absence of a route to the source. influence the path selection in the absence of a route to the source.
The same procedures can be used to override a route to the source The same procedures can be used to override a route to the source
when it exists. It is possible to include multiple RPF vectors in when it exists. It is possible to include multiple RPF Vectors in
the list where each router along the path will perform a unicast the list where each router along the path will perform a unicast
route lookup on the first vector in the attribute list. Once the route lookup on the first Vector in the attribute list. Once the
router owning the address of the RPF vector is reached, following the router owning the address of the RPF Vector is reached, following the
procedures in [RFC5496], the RPF vector will be removed from the procedures in [RFC5496], the RPF Vector will be removed from the
attribute list. This will result in a 'loosely' routed path that attribute list. This will result in a 'loosely' routed path that
still depends on unicast reachability to the RPF vector(s). still depends on unicast reachability to the RPF Vector(s).
In some scenarios the network adminstrators don't want to rely on the In some scenarios, the network administrators don't want to rely on
unicast reachability to the RPF vector address and want to build a the unicast reachability to the RPF Vector address and want to build
path strictly based on the RPF vectors. In that case the RPF vectors a path strictly based on the RPF Vectors. In that case, the RPF
represent a list of directly connected PIM neighbors along the path. Vectors represent a list of directly connected PIM neighbors along
For these vectors the router would not do a route lookup in the the path. For these Vectors, the router would not do a route lookup
unicast routing table. These vectors are referred to as 'Explicit' in the unicast routing table. These Vectors are referred to as
RPF Vector addresses. If a router receiving an Explicit RPF Vector 'Explicit' RPF Vector addresses. If a router receiving an Explicit
does not have a PIM neighbor matching the Explicit RPF Vector RPF Vector does not have a PIM neighbor matching the Explicit RPF
address, it does not fall back to loosely routing the join. Instead, Vector address, it does not fall back to loosely routing the Join.
it could process the packet and store the RPF Vector list so that the Instead, it could process the packet and store the RPF Vector list so
PIM join can be sent out as soon as the neighbor comes up. Since the that the PIM Join can be sent out as soon as the neighbor comes up.
behavior of the Explicit RPF Vector differs from the loose RPF vector Since the behavior of the Explicit RPF Vector differs from the
as defined [RFC5496], a new attribute called the Explicit RPF Vector 'loose' RPF Vector as defined in [RFC5496], a new attribute called
is defined. the Explicit RPF Vector is defined.
This document defines a new TLV in the PIM Join Attribute message This document defines a new TLV in the PIM Join Attribute message
[RFC5384] for specifying the explicit path. [RFC5384] for specifying the explicit path.
2. Specification of Requirements 2. 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].
3. Motivation 3. Motivation
Some broadcast video transport networks use a multicast PIM Live-Live Some broadcast video transport networks use a multicast PIM Live-Live
resiliency model for video delivery based on PIM SSM or PIM ASM. resiliency model for video delivery based on PIM Source-Specific
Live-Live implies using 2 active spatially diverse multicast trees to Multicast (PIM-SSM) or PIM Any-Source Multicast (PIM-ASM). Live-Live
implies using two active, spatially diverse multicast trees to
transport video flows from root to leaf multicast routers. The leaf transport video flows from root to leaf multicast routers. The leaf
multicast router receives 2 copies from the PIM multicast core and multicast router receives two copies from the PIM multicast core and
will replicate 1 copy towards the receivers [RFC7431]. will replicate one copy towards the receivers [RFC7431].
One of the requirements of the PIM Live-Live resiliency model is to One of the requirements of the PIM Live-Live resiliency model is to
ensure path-diversity of the 2 active PIM trees in the core such that ensure path diversity of the two active PIM trees in the core such
they do not intersect to avoid a single point of failure. IGP routed that they do not intersect to avoid a single point of failure. IGP-
RPF paths of 2 PIM trees could be routed over the same transit router routed RPF paths of two PIM trees could be routed over the same
and create a single point of failure. It is useful to have a way to transit router and create a single point of failure. It is useful to
specify the explicit path along which the PIM join is propagated. have a way to specify the explicit path along which the PIM Join is
propagated.
How the Explicit RPF Vector list is determined is outside the scope How the Explicit RPF Vector list is determined is outside the scope
of this document. For example, it may either be manually configured of this document. For example, it may either be manually configured
by the network operator or procedures may be implemented on the by the network operator or procedures may be implemented on the
egress router to dynamically calculate the vector list based on a egress router to dynamically calculate the Vector list based on a
link state database protocol, like OSPF or IS-IS. link-state database protocol, like OSPF or IS-IS.
Due to the fact that the leaf router receives two copies of the Due to the fact that the leaf router receives two copies of the
multicast stream via two diverse paths, there is no need for PIM to multicast stream via two diverse paths, there is no need for PIM to
repair the broken path immediately. It is up to the egress router to repair the broken path immediately. It is up to the egress router to
either wait for the broken path to be repaired or build a new either wait for the broken path to be repaired or build a new
explicit path using a new RPF vector list. Which method is applied explicit path using a new RPF Vector list. Which method is applied
depends very much on how the vector list was determined initially. depends very much on how the Vector list was determined initially.
Double failures are not considered and are outside the scope of this Double failures are not considered and are outside the scope of this
document. document.
This document describes the procedures to carry Explicit RPF vectors This document describes the procedures to carry Explicit RPF Vectors
in PIM. It is up to the mechanism(s) that produce the Explicit RPF in PIM. It is up to the mechanism(s) that produce the Explicit RPF
Vectors to ensure they are correct. Existing mechanisms like Vectors to ensure they are correct. Existing mechanisms like
[I-D.ietf-mboned-mtrace-v2] may be used to verify how the PIM tree [MTRACE-V2] may be used to verify how the PIM tree was built.
was build.
4. Use of the PIM Explicit RPF Vector 4. Use of the PIM Explicit RPF Vector
Figure 1 provides an example multicast join path Figure 1 provides an example multicast join path
R4->R3->R6->R5->R2->R1, where the multicast join is explicitly routed R4->R3->R6->R5->R2->R1, where the multicast join is explicitly routed
to the source hop-by-hop using the Explicit RPF Vector list. When to the source hop by hop using the Explicit RPF Vector list. When
R5-R6 link fails the join will NOT take an alternate path. the R5-R6 link fails, the Join will NOT take an alternate path.
[S]---(R1)--(R2)---(R3)--(R4)---[R] [S]---(R1)--(R2)---(R3)--(R4)---[R]
<--- | | --- <--- | | ---
| | | | | | | |
| (R5)---(R6) | | (R5)---(R6) |
- (S,G) Join - - (S,G) Join -
| | | |
| | | |
(R7)---(R8) (R7)---(R8)
Figure 1 Figure 1
In comparison, when [RFC5496] procedures are used, if R5-R6 link In comparison, when the procedures specified in [RFC5496] are used,
fails then the join may be re-routed using R6-R8-R7 path to reach R5. if the R5-R6 link fails, then the Join may be rerouted using the
R6-R8-R7 path to reach R5.
5. Explicit RPF Vector Attribute TLV Format 5. Explicit RPF Vector Attribute TLV Format
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| Type | Length | Value |F|E| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
Figure 2 Figure 2
F bit: The F bit MUST be set to 0. Otherwise there could be loops. F bit: 'Transitive Attribute' bit. The F bit MUST be set to 0.
Otherwise, there could be loops.
E bit: End of Attributes. If this bit is set then this is the last E bit: 'End of Attributes' bit. If the E bit is set, then this is
TLV specified in the list. the last TLV specified in the list.
Type: The Vector Attribute type is TBD1. Type: 4 (Explicit RPF Vector)
Length: Length depending on the Address Family (IPv4 or IPv6) of the Length: The length depending on the Address Family (IPv4 or IPv6) of
Encoded-Unicast address. the Encoded-Unicast address.
Value: Encoded-Unicast address. This SHOULD be a valid IPv4 or IPv6 Value: Encoded-Unicast address. This SHOULD be a valid IPv4 or IPv6
address of an upstream router. address of an upstream router.
6. Mixed Vector Processing 6. Mixed Vector Processing
Explicit RPF Vector attribute does not impact or restrict the The Explicit RPF Vector Attribute does not impact or restrict the
functionality of other RPF vector attributes in a PIM join. It is functionality of other RPF Vector Attributes in a PIM Join. It is
possible to mix vectors of different types, such that some part of possible to mix Vectors of different types such that some part of the
the tree is explicit and other parts are loosely routed. RPF vectors tree is explicit and other parts are loosely routed. RPF Vectors are
are processed in the order in which they are specified. processed in the order in which they are specified.
7. Conflicting RPF Vectors 7. Conflicting RPF Vectors
It is possible that a PIM router has multiple downstream neighbors. It is possible that a PIM router has multiple downstream neighbors.
If for the same multicast route there is an inconsistency between the If for the same multicast route there is an inconsistency between the
Explicit RPF Vector lists provided by the downstream PIM neighbor, Explicit RPF Vector lists provided by the downstream PIM neighbor,
the procedures as documented in section 3.3.3 [RFC5384] apply. the procedures as documented in Section 3.3.3 of [RFC5384] apply.
The conflict resolution procedures in section 3.3.3 [RFC5384] only The conflict resolution procedures in Section 3.3.3 of [RFC5384] only
apply to attributes of the same Join Attribute type. Join Attributes apply to attributes of the same Join Attribute type. Join Attributes
that have a different type can't be compared because the content of that have a different type can't be compared because the content of
the Join Attribute may have a totally different meaning and/or the Join Attribute may have a totally different meaning and/or
encoding. This may cause a problem if a mix of Explicit RPF Vectors encoding. This may cause a problem if a mix of Explicit RPF Vectors
(this document) and 'loose' RPF vectors [RFC5496] is received from (this document) and 'loose' RPF Vectors [RFC5496] is received from
two or more downstream routers. The order in which the RPF vectors two or more downstream routers. The order in which the RPF Vectors
are encoded may be different and/or the combination of RPF vectors are encoded may be different, and/or the combination of RPF Vectors
may be inconsistent. The procedures in section 3.3.3 [RFC5384] would may be inconsistent. The procedures in Section 3.3.3 of [RFC5384]
not resolve the conflict. The following procedures MUST be applied would not resolve the conflict. The following procedures MUST be
to deal with this scenario. applied to deal with this scenario.
When a PIM Join with Join Attribute list is received from a When a PIM Join with a Join Attribute list is received from a
downstream neighbor, the router MUST verify that the order in which downstream neighbor, the router MUST verify that the order in which
the RPF Vector types appear in the PIM Join Attribute list matches the RPF Vector types appear in the PIM Join Attribute list matches
what is stored as the Join Attribute list for reaching the Source or what is stored as the Join Attribute list for reaching the source or
Randezvous point listed in the PIM Join. Once it is determined that Rendezvous Point listed in the PIM Join. Once it is determined that
the RPF Vector types on the stack are equal, the content of the RPF the RPF Vector types on the stack are equal, the content of the RPF
Vectors MUST be compared ([RFC5384]). If it is determined that there Vectors MUST be compared ([RFC5384]). If it is determined that there
is either a conflict with RPF Vector types or the RPF Vector content, is either a conflict with RPF Vector types or the RPF Vector content,
the router uses the RPF Vector stack from the PIM adjacency with the router uses the RPF Vector stack from the PIM adjacency with the
numerically smallest IP address. In the case of IPv6, the link local numerically smallest IP address. In the case of IPv6, the link-local
address will be used. When two neighbors have the same IP address, address will be used. When two neighbors have the same IP address,
either for IPv4 or IPv6, the interface index MUST be used as a tie either for IPv4 or IPv6, the interface index MUST be used as a tie
breaker. It's RECOMMENDED that the router doing the conflict breaker. It's RECOMMENDED that the router doing the conflict
resolution log a message. resolution log a message.
8. PIM Asserts 8. PIM Asserts
Section 3.3.3 of [RFC5496] specifies the procedures for how to deal Section 3.3.3 of [RFC5496] specifies the procedures for how to deal
with PIM asserts when RPF vectors are used. The same procedures with PIM Asserts when RPF Vectors are used. The same procedures
apply to the Explicit RPF Vector. There is minor behavioral apply to the Explicit RPF Vector. There is a minor behavioral
difference, the route metric that is included in the PIM Assert difference: the route 'metric' that is included in the PIM Assert
should be the route metric of the first Explicit RPF vector address should be the route metric of the first Explicit RPF Vector address
in the list. However, the first Explicit vector should always be in the list. However, the first Explicit Vector should always be
directly connected, so the Metric may likely be zero. The Metric directly connected, so the metric may likely be zero. The metric
will therefore not be a tie breaker in the PIM Assert selection will therefore not be a tie breaker in the PIM Assert selection
procedure. procedure.
9. Join Suppression 9. Join Suppression
Section 3.3.4 of [RFC5496] specifies the procedures how to apply join Section 3.3.4 of [RFC5496] specifies the procedures for how to apply
suppression when an RPF Vector attribute is included in the PIM join. Join Suppression when an RPF Vector Attribute is included in the PIM
The same procedure applies to the Explicit RPF Vector attribute. The Join. The same procedure applies to the Explicit RPF Vector
procedure MUST match against all the Explicit RPF Vectors in the PIM Attribute. The procedure MUST match against all the Explicit RPF
join before a PIM join can be suppressed. Vectors in the PIM Join before a PIM Join can be suppressed.
10. Unsupported Explicit Vector Handling 10. Unsupported Explicit Vector Handling
The F bit MUST be set to 0 in all Explicit RPF vectors in case the The F bit MUST be set to 0 in all Explicit RPF Vectors in case the
upstream router receiving the join does not support the TLV. As upstream router receiving the Join does not support the TLV. As
described in section 3.3.2 of [RFC5384], routers that do not described in Section 3.3.2 of [RFC5384], routers that do not
understand the type of a particular attribute that has the F bit understand the type of a particular attribute that has the F bit
clear will discard it and continue to process the join. clear will discard it and continue to process the Join.
This processing is particularly important when the routers that do This processing is particularly important when the routers that do
not support the Explicit RPF TLV are identified as hops in the not support the Explicit RPF TLV are identified as hops in the
explicit RPF list, because failing to remove the RPF vectors could Explicit RPF list because failing to remove the RPF Vectors could
cause upstream routers to send the join back toward these routers cause upstream routers to send the Join back toward these routers
causing loops. causing loops.
As the administrator is manually specifying the path that the joins As the administrator is manually specifying the path that the Joins
need to be sent on, it is recommended that the administrator computes need to be sent on, it is recommended that the administrator computes
the path to include routers that support explcit vector and check the path to include routers that support the Explicit Vector and
that the state is created correctly on each router along the path. check that the state is created correctly on each router along the
Tools like mtrace can be used for debugging and to ensure that the path. Tools like mtrace can be used for debugging and to ensure that
join state is setup correctly. the Join state is setup correctly.
11. IANA Considerations 11. IANA Considerations
A new attribute (TBD1) type from the "PIM Join Attribute Types" In the "PIM Join Attribute Types" registry, IANA has assigned the
registry needs to be assigned by IANA for the Explicit RPF Vector value 4 to the Explicit RPF Vector Attribute.
attribute. The proposed value 4.
12. Security Considerations 12. Security Considerations
Security of the Explicit RPF Vector Attribute is only guaranteed by Security of the Explicit RPF Vector Attribute is only guaranteed by
the security of the PIM packet, so the security considerations for the security of the PIM packet, so the security considerations for
PIM Join packets as described in PIM-SM [I-D.ietf-pim-rfc4601bis] PIM Join packets as described in PIM-SM [RFC7761] apply here. A
apply here. A malicious downstream node can attempt a denial of malicious downstream node can attempt a denial-of-service attack by
service attack by sending PIM Join packets with invalid addresses sending PIM Join packets with invalid addresses listed in the RPF
listed in the RPF vector stack with an intent to stop the propogation Vector stack with an intent to stop the propagation of the Joins to
of the joins to the correct upstream node. Another denial of service the correct upstream node. Another denial-of-service attack would be
attack would be a malicious downstream node targeting all joins to a a malicious downstream node targeting all Joins to a specific node
specific node with an intent to overload the bandwidth on that node with an intent to overload the bandwidth on that node by making it
by making it responsible for forwarding multicast traffic for more responsible for forwarding multicast traffic for more streams that it
streams that it can handle. Inorder to minimize the risk of a denial can handle. In order to minimize the risk of a denial-of-service
of service attacks from forged PIM join packets with explicit RPF attack from forged PIM Join packets with Explicit RPF Vector stack,
vector stack, it should be used within a single trusted management it should be used within a single trusted management domain.
domain.
If a router finds that it cannot use the vector list due to the next
hop router not being a PIM neighbor, it may log an error. Also if a
router is receiving two conflicting vectors it may log an error. It
is upto the mechanisms that produced the Explicit RPF vector to
ensure that the the PIM tree is built correctly and to monitor any
error logs.
13. Acknowledgments
The authors would like to thank Vatsa Kumar, Nagendra Kumar and
Bharat Joshi for the comments on the document.
14. References If a router finds that it cannot use the Vector list due to the next
hop router not being a PIM neighbor, it may log an error. Also, if a
router is receiving two conflicting Vectors, it may log an error. It
is up to the mechanisms that produced the Explicit RPF Vector to
ensure that the PIM tree is built correctly and to monitor any error
logs.
14.1. Normative References 13. References
[I-D.ietf-pim-rfc4601bis] 13.1. Normative References
Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, J., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", draft-ietf-pim-rfc4601bis-06 (work in
progress), August 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute Format", Independent Multicast (PIM) Join Attribute Format",
RFC 5384, DOI 10.17487/RFC5384, November 2008, RFC 5384, DOI 10.17487/RFC5384, November 2008,
<http://www.rfc-editor.org/info/rfc5384>. <http://www.rfc-editor.org/info/rfc5384>.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496, Forwarding (RPF) Vector TLV", RFC 5496,
DOI 10.17487/RFC5496, March 2009, DOI 10.17487/RFC5496, March 2009,
<http://www.rfc-editor.org/info/rfc5496>. <http://www.rfc-editor.org/info/rfc5496>.
14.2. Informative References [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <http://www.rfc-editor.org/info/rfc7761>.
[I-D.ietf-mboned-mtrace-v2] 13.2. Informative References
[MTRACE-V2]
Asaeda, H., Meyer, K., and W. Lee, "Mtrace Version 2: Asaeda, H., Meyer, K., and W. Lee, "Mtrace Version 2:
Traceroute Facility for IP Multicast", draft-ietf-mboned- Traceroute Facility for IP Multicast", Work in Progress,
mtrace-v2-12 (work in progress), October 2015. draft-ietf-mboned-mtrace-v2-13, June 2016.
[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. [RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B.
Decraene, "Multicast-Only Fast Reroute", RFC 7431, Decraene, "Multicast-Only Fast Reroute", RFC 7431,
DOI 10.17487/RFC7431, August 2015, DOI 10.17487/RFC7431, August 2015,
<http://www.rfc-editor.org/info/rfc7431>. <http://www.rfc-editor.org/info/rfc7431>.
Acknowledgements
The authors would like to thank Vatsa Kumar, Nagendra Kumar, and
Bharat Joshi for their comments on the document.
Authors' Addresses Authors' Addresses
Javed Asghar Javed Asghar
Cisco Systems Cisco Systems
725, Alder Drive 725, Alder Drive
Milpitas CA 95035 Milpitas, CA 95035
USA United States
Email: jasghar@cisco.com Email: jasghar@cisco.com
IJsbrand Wijnands (editor) IJsbrand Wijnands (editor)
Cisco Systems Cisco Systems
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Email: ice@cisco.com Email: ice@cisco.com
skipping to change at page 9, line 4 skipping to change at page 9, line 22
Email: jasghar@cisco.com Email: jasghar@cisco.com
IJsbrand Wijnands (editor) IJsbrand Wijnands (editor)
Cisco Systems Cisco Systems
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Email: ice@cisco.com Email: ice@cisco.com
Sowmya Krishnaswamy Sowmya Krishnaswamy
Cisco Systems Cisco Systems
3750 Cisco Way 3750 Cisco Way
San Jose CA 95134 San Jose, CA 95134
USA United States
Email: sowkrish@cisco.com Email: sowkrish@cisco.com
Apoorva Karan Apoorva Karan
Cisco Systems Cisco Systems
3750 Cisco Way 3750 Cisco Way
San Jose CA 95134 San Jose, CA 95134
USA United States
Email: apoorva@cisco.com Email: apoorva@cisco.com
Vishal Arya Vishal Arya
DIRECTV Inc. DIRECTV Inc.
2230 E Imperial Hwy 2230 E Imperial Hwy
El Segundo CA 90245 El Segundo, CA 90245
USA United States
Email: varya@directv.com Email: varya@directv.com
 End of changes. 58 change blocks. 
163 lines changed or deleted 160 lines changed or added

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