draft-ietf-pim-explicit-rpf-vector-05.txt   draft-ietf-pim-explicit-rpf-vector-06.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: August 9, 2015 A. Karan Expires: November 8, 2015 A. Karan
Cisco Systems Cisco Systems
V. Arya V. Arya
DIRECTV Inc. DIRECTV Inc.
February 5, 2015 May 7, 2015
Explicit RPF Vector Explicit RPF Vector
draft-ietf-pim-explicit-rpf-vector-05.txt draft-ietf-pim-explicit-rpf-vector-06.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 August 9, 2015. This Internet-Draft will expire on November 8, 2015.
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 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . . . . 4
6. Mixed Vector Processing . . . . . . . . . . . . . . . . . . . 4 6. Mixed Vector Processing . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . 5
10. Unsupported Explicit Vector Handling . . . . . . . . . . . . 5 10. Unsupported Explicit Vector Handling . . . . . . . . . . . . 6
11. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . 5 11. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . 6
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
13. Security Considerations . . . . . . . . . . . . . . . . . . . 6 13. Security Considerations . . . . . . . . . . . . . . . . . . . 7
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
15.1. Normative References . . . . . . . . . . . . . . . . . . 6 15.1. Normative References . . . . . . . . . . . . . . . . . . 7
15.2. Informative References . . . . . . . . . . . . . . . . . 7 15.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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
router owning the address of the RPF vector is reached, following the router owning the address of the RPF vector is reached, following the
skipping to change at page 5, line 12 skipping to change at page 5, line 12
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
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 [RFC5384] apply.
The conflict resolution procedures in section 3.3.3 [RFC5384] only
apply to attributes of the same Join Attribute type. Join Attributes
that have a different type can't be compared because the content of
the Join Attribute may have a totally different meaning and/or
encoding. This may cause a problem if a mix of Explicit RPF Vectors
(this document) and 'loose' RPF vectors [RFC5496] is received from
two or more downstream routers. The order in which the 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
not resolve the conflict. The following procedures MUST be applied
to deal with this scenario.
A router processing 'Explicit' or 'Loose' RPF Vectors MUST verify
that the order in which RPF Vectors types appear in the PIM Join
Attribute list received from its downstream PIM neighbors are equal.
Once it is determined the RPF Vector types are on the stack are
equal, the content of the RPF Vectors MUST be compared ([RFC5384]).
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
PIM adjacency with the numerically smallest IP address. In the case
of IPv6, the link local 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 breaker.
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
will therefore not be a tie breaker in the PIM Assert selection will therefore not be a tie breaker in the PIM Assert selection
skipping to change at page 5, line 46 skipping to change at page 6, line 21
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
need to be sent on, it is recommended that the administrator computes
the path to include routers that support explcit vector and check
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
join state is setup correctly.
11. Explicit RPF Vector Attribute TLV Format 11. 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: The F bit MUST be set to 0. Otherwise there could be loops.
skipping to change at page 7, line 7 skipping to change at page 7, line 31
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 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-rtgwg-mofrr] [I-D.ietf-rtgwg-mofrr]
Karan, A., Filsfils, C., Wijnands, I., and B. Decraene, Karan, A., Filsfils, C., Wijnands, I., and B. Decraene,
"Multicast only Fast Re-Route", draft-ietf-rtgwg-mofrr-05 "Multicast only Fast Re-Route", draft-ietf-rtgwg-mofrr-06
(work in progress), February 2015. (work in progress), February 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, March 1997.
[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 Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. 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", RFC
5384, November 2008. 5384, November 2008.
[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, March 2009.
15.2. Informative References 15.2. Informative References
[I-D.ietf-mboned-mtrace-v2] [I-D.ietf-mboned-mtrace-v2]
Asaeda, H. and W. Lee, "Mtrace Version 2: Traceroute Asaeda, H., "Mtrace Version 2: Traceroute Facility for IP
Facility for IP Multicast", draft-ietf-mboned-mtrace-v2-11 Multicast", draft-ietf-mboned-mtrace-v2-11 (work in
(work in progress), October 2014. progress), October 2014.
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. 11 change blocks. 
16 lines changed or deleted 48 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/