draft-ietf-pim-explicit-rpf-vector-06.txt   draft-ietf-pim-explicit-rpf-vector-07.txt 
Network Working Group J. Asghar Network Working Group J. Asghar
Internet-Draft IJ. Wijnands, Ed. Internet-Draft IJ. Wijnands, Ed.
Intended status: Standards Track S. Krishnaswamy Intended status: Standards Track S. Krishnaswamy
Expires: November 8, 2015 A. Karan Expires: May 20, 2016 A. Karan
Cisco Systems Cisco Systems
V. Arya V. Arya
DIRECTV Inc. DIRECTV Inc.
May 7, 2015 November 17, 2015
Explicit RPF Vector Explicit RPF Vector
draft-ietf-pim-explicit-rpf-vector-06.txt draft-ietf-pim-explicit-rpf-vector-07.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 RP associated with the multicast tree. of the Source or RP 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,
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 November 8, 2015. This Internet-Draft will expire on May 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . 4 5. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . 4
6. Mixed Vector Processing . . . . . . . . . . . . . . . . . . . 4 6. Mixed Vector Processing . . . . . . . . . . . . . . . . . . . 5
7. Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . . 5 7. Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . . 5
8. PIM Asserts . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. PIM Asserts . . . . . . . . . . . . . . . . . . . . . . . . . 5
9. Join Suppression . . . . . . . . . . . . . . . . . . . . . . 5 9. Join Suppression . . . . . . . . . . . . . . . . . . . . . . 6
10. Unsupported Explicit Vector Handling . . . . . . . . . . . . 6 10. Unsupported Explicit Vector Handling . . . . . . . . . . . . 6
11. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . 6 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 12. Security Considerations . . . . . . . . . . . . . . . . . . . 6
13. Security Considerations . . . . . . . . . . . . . . . . . . . 7 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 14.1. Normative References . . . . . . . . . . . . . . . . . . 7
15.1. Normative References . . . . . . . . . . . . . . . . . . 7 14.2. Informative References . . . . . . . . . . . . . . . . . 7
15.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The procedures in [RFC5496] define how a RPF vector can be used to The procedures in [RFC5496] define how a 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
skipping to change at page 3, line 30 skipping to change at page 3, line 29
"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 SSM or PIM ASM.
Live-Live implies using 2 active spatially diverse multicast trees to Live-Live implies using 2 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 2 copies from the PIM multicast core and
will replicate 1 copy towards the receivers [I-D.ietf-rtgwg-mofrr]. will replicate 1 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 2 active PIM trees in the core such that
they do not intersect to avoid a single point of failure. IGP routed they do not intersect to avoid a single point of failure. IGP routed
RPF paths of 2 PIM trees could be routed over the same transit router RPF paths of 2 PIM trees could be routed over the same transit router
and create a single point of failure. It is useful to have a way to and create a single point of failure. It is useful to have a way to
specify the explicit path along which the PIM join is propagated. 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
skipping to change at page 4, line 4 skipping to change at page 3, line 50
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, but it does not introduce any new mechanism in PIM to in PIM. It is up to the mechanism(s) that produce the Explicit RPF
validate the correctness of the RPF vectors. It is up to the Vectors to ensure they are correct. Existing mechanisms like
mechanism(s) that produce the Explicit RPF Vectors to ensure they are [I-D.ietf-mboned-mtrace-v2] may be used to verify how the PIM tree
correct. Existing mechanisms like [I-D.ietf-mboned-mtrace-v2] may be was build.
used to verify how the PIM tree 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. 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 [RFC5496] procedures are used, if R5-R6 link
fails then the join may be re-routed using R6-R8-R7 path to reach R5. fails then the join may be re-routed using R6-R8-R7 path to reach R5.
5. Explicit RPF Vector Attribute 5. Explicit RPF Vector Attribute TLV Format
This draft uses PIM join attribute type TBD1 by IANA for specifying 0 1 2 3
an Explicit RPF Vector. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
Figure 2
F 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
TLV specified in the list.
Type: The Vector Attribute type is TBD1.
Length: Length depending on the Address Family (IPv4 or IPv6) of the
Encoded-Unicast address.
Value: Encoded-Unicast address. This SHOULD be a valid IPv4 or IPv6
address of an upstream router.
6. Mixed Vector Processing 6. Mixed Vector Processing
Explicit RPF Vector attribute does not impact or restrict 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 tree is explicit and other parts are loosely routed. RPF vectors the tree is explicit and other parts are loosely routed. RPF vectors
are processed in the order in which they are specified. are processed in the order in which they are specified.
7. Conflicting RPF Vectors 7. Conflicting RPF Vectors
skipping to change at page 5, line 34 skipping to change at page 5, line 45
A router processing 'Explicit' or 'Loose' RPF Vectors MUST verify A router processing 'Explicit' or 'Loose' RPF Vectors MUST verify
that the order in which RPF Vectors types appear in the PIM Join that the order in which RPF Vectors types appear in the PIM Join
Attribute list received from its downstream PIM neighbors are equal. Attribute list received from its downstream PIM neighbors are equal.
Once it is determined the RPF Vector types are on the stack are Once it is determined the RPF Vector types are on the stack are
equal, the content of the RPF Vectors MUST be compared ([RFC5384]). equal, the content of the RPF Vectors MUST be compared ([RFC5384]).
If it is determined that there is either a conflict with RPF Vector If it is determined that there is either a conflict with RPF Vector
types or the RPF Vector content, we use the RPF Vector stack from the types or the RPF Vector content, we use the RPF Vector stack from the
PIM adjacency with the numerically smallest IP address. In the case PIM adjacency with the numerically smallest IP address. In the case
of IPv6, the link local address will be used. When two neighbors of IPv6, the link local address will be used. When two neighbors
have the same IP address, either for IPv4 or IPv6, the interface have the same IP address, either for IPv4 or IPv6, the interface
index MUST be used as a tie breaker. index MUST be used as a tie breaker. It's RECOMMENDED that the
router doing the conflict 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 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
skipping to change at page 6, line 28 skipping to change at page 6, line 40
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 explcit vector and check
that the state is created correctly on each router along the path. that the state is created correctly on each router along the path.
Tools like mtrace can be used for debugging and to ensure that the Tools like mtrace can be used for debugging and to ensure that the
join state is setup correctly. join state is setup correctly.
11. Explicit RPF Vector Attribute TLV Format 11. IANA Considerations
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
Figure 2
F 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
TLV specified in the list.
Type: The Vector Attribute type is TBD1.
Length: Length depending on the Address Family of the Encoded-
Unicast address.
Value: Encoded-Unicast address. This could be a valid primary or
secondary address.
12. IANA Considerations
A new attribute (TBD1) type from the "PIM Join Attribute Types" A new attribute (TBD1) type from the "PIM Join Attribute Types"
registry needs to be assigned by IANA for the Explicit RPF Vector registry needs to be assigned by IANA for the Explicit RPF Vector
attribute. The proposed value 4. attribute. The proposed value 4.
13. 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 [RFC4601] apply here. PIM Join packets as described in PIM-SM [I-D.ietf-pim-rfc4601bis]
Additionally, the Explicit RPF Vector list should be subject to a apply here. Inorder to minimize the risk of a malicious node
policy to validate the list consists of a valid path before its used injecting an incorrect Explicit RPF vector stack, it should be used
by a receiver to build a multicast tree. within a single management 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.
14. Acknowledgments 13. Acknowledgments
The authors would like to thank Vatsa Kumar, Nagendra Kumar and The authors would like to thank Vatsa Kumar, Nagendra Kumar and
Bharat Joshi for the comments on the document. Bharat Joshi for the comments on the document.
15. References 14. References
15.1. Normative References 14.1. Normative References
[I-D.ietf-rtgwg-mofrr] [I-D.ietf-pim-rfc4601bis]
Karan, A., Filsfils, C., Wijnands, I., and B. Decraene, Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
"Multicast only Fast Re-Route", draft-ietf-rtgwg-mofrr-06 Parekh, R., Zhang, J., and L. Zheng, "Protocol Independent
(work in progress), February 2015. 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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, <http://www.rfc-editor.org/info/rfc2119>.
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[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", RFC Independent Multicast (PIM) Join Attribute Format",
5384, November 2008. RFC 5384, DOI 10.17487/RFC5384, November 2008,
<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, March 2009. Forwarding (RPF) Vector TLV", RFC 5496,
DOI 10.17487/RFC5496, March 2009,
<http://www.rfc-editor.org/info/rfc5496>.
15.2. Informative References 14.2. Informative References
[I-D.ietf-mboned-mtrace-v2] [I-D.ietf-mboned-mtrace-v2]
Asaeda, H., "Mtrace Version 2: Traceroute Facility for IP Asaeda, H., Meyer, K., and W. Lee, "Mtrace Version 2:
Multicast", draft-ietf-mboned-mtrace-v2-11 (work in Traceroute Facility for IP Multicast", draft-ietf-mboned-
progress), October 2014. mtrace-v2-12 (work in progress), October 2015.
[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B.
Decraene, "Multicast-Only Fast Reroute", RFC 7431,
DOI 10.17487/RFC7431, August 2015,
<http://www.rfc-editor.org/info/rfc7431>.
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 USA
Email: jasghar@cisco.com Email: jasghar@cisco.com
 End of changes. 26 change blocks. 
81 lines changed or deleted 87 lines changed or added

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