summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7896.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7896.txt')
-rw-r--r--doc/rfc/rfc7896.txt283
1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc7896.txt b/doc/rfc/rfc7896.txt
new file mode 100644
index 0000000..1b4d53a
--- /dev/null
+++ b/doc/rfc/rfc7896.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. Dhody
+Request for Comments: 7896 Huawei Technologies
+Updates: 5440 June 2016
+Category: Standards Track
+ISSN: 2070-1721
+
+
+ Update to the Include Route Object (IRO) Specification
+ in the Path Computation Element Communication Protocol (PCEP)
+
+Abstract
+
+ The Path Computation Element Communication Protocol (PCEP) enables
+ communications between a Path Computation Client (PCC) and a PCE, or
+ between two PCEs. RFC 5440 defines the Include Route Object (IRO) to
+ specify network elements to be traversed in the computed path. The
+ specification does not specify if the IRO contains an ordered or
+ unordered list of subobjects. During recent discussions, it was
+ determined that there was a need to define a standard representation
+ to ensure interoperability. It was also noted that there is a
+ benefit in the handling of an attribute of the IRO's subobject, the L
+ bit.
+
+ This document updates RFC 5440 regarding the IRO specification.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ 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/rfc7896.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dhody Standards Track [Page 1]
+
+RFC 7896 IRO Specification Update June 2016
+
+
+Copyright Notice
+
+ Copyright (c) 2016 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Update in the IRO Specification . . . . . . . . . . . . . . . 3
+ 2.1. Update to RFC 5440 . . . . . . . . . . . . . . . . . . . 3
+ 3. Operational Considerations . . . . . . . . . . . . . . . . . 4
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
+ 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 5.1. Normative References . . . . . . . . . . . . . . . . . . 4
+ 5.2. Informative References . . . . . . . . . . . . . . . . . 5
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
+
+
+
+
+
+
+
+
+
+
+
+
+Dhody Standards Track [Page 2]
+
+RFC 7896 IRO Specification Update June 2016
+
+
+1. Introduction
+
+ The Path Computation Element Communication Protocol (PCEP) enables
+ communications between a Path Computation Client (PCC) and a PCE, or
+ between two PCEs. [RFC5440] defines the Include Route Object (IRO)
+ to specify network elements to be traversed in the computed path.
+ The specification does not specify if the IRO is an ordered or
+ unordered list of subobjects. In addition, it defines the L bit as
+ having no meaning within an IRO.
+
+ [RFC5441] describes the use of an IRO to indicate the sequence of
+ domains to be traversed during inter-domain path computation.
+
+ During recent discussions, it was determined that there was a need to
+ define a standard representation to ensure interoperability.
+
+ This document updates the IRO specifications in Section 7.12 of
+ [RFC5440].
+
+2. Update in the IRO Specification
+
+ Section 7.12 of [RFC5440] describes the IRO as an optional object
+ used to specify a set of network elements to be traversed in the
+ computed path. It states that the L bit in the subobject has no
+ meaning within an IRO. It does not mention if the IRO contains an
+ ordered or unordered list of subobjects.
+
+2.1. Update to RFC 5440
+
+ The IRO specification is updated to remove the last line in the
+ Section 7.12 of [RFC5440], which states:
+
+ "The L bit of such sub-object has no meaning within an IRO."
+
+ Further, Section 7.12 of [RFC5440] is updated to add the following
+ two statements at the end of the first paragraph.
+
+ - The content of an IRO is an ordered list of subobjects
+ representing a series of abstract nodes (refer to Section 4.3.2 of
+ [RFC3209]).
+
+ - The L bit of an IRO subobject is set based on the loose or strict
+ hop property of the subobject; it is set if the subobject
+ represents a loose hop. If the bit is not set, the subobject
+ represents a strict hop. The interpretation of the L bit is as
+ per Section 4.3.3.1 of [RFC3209].
+
+
+
+
+
+Dhody Standards Track [Page 3]
+
+RFC 7896 IRO Specification Update June 2016
+
+
+3. Operational Considerations
+
+ Because of the lack of clarity in [RFC5440], it is possible to
+ encounter implementations that always interpret the IRO subobjects as
+ loose. When these implementations interwork with an implementation
+ conforming to this document, the following impact might be seen:
+
+ o If a non-conforming (to this document) PCC sends an IRO to a
+ conforming (to this document) PCE, then the PCE may unexpectedly
+ fail to find a path (since the PCC may think of the IRO subobjects
+ as loose hops, but the PCE interprets them as strict hops).
+
+ o If a conforming PCC sends an IRO containing strict hops to a non-
+ conforming PCE, then the PCE may erroneously return a path that
+ does not comply with the requested strict hops (since the PCE
+ interprets them all as loose hops). The PCC may check the
+ returned path and find the issue, or it may end up using an
+ incorrect path.
+
+4. Security Considerations
+
+ This update in the IRO specification does not introduce any new
+ security considerations, apart from those mentioned in [RFC5440].
+ Clarification in the supported IRO ordering or Loose hop bit handling
+ will not have any negative security impact.
+
+ It is worth noting that PCEP operates over TCP. An analysis of the
+ security issues for routing protocols that use TCP (including PCEP)
+ is provided in [RFC6952].
+
+5. References
+
+5.1. Normative References
+
+ [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+ and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+ Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
+ <http://www.rfc-editor.org/info/rfc3209>.
+
+ [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
+ Element (PCE) Communication Protocol (PCEP)", RFC 5440,
+ DOI 10.17487/RFC5440, March 2009,
+ <http://www.rfc-editor.org/info/rfc5440>.
+
+
+
+
+
+
+
+
+Dhody Standards Track [Page 4]
+
+RFC 7896 IRO Specification Update June 2016
+
+
+5.2. Informative References
+
+ [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
+ "A Backward-Recursive PCE-Based Computation (BRPC)
+ Procedure to Compute Shortest Constrained Inter-Domain
+ Traffic Engineering Label Switched Paths", RFC 5441,
+ DOI 10.17487/RFC5441, April 2009,
+ <http://www.rfc-editor.org/info/rfc5441>.
+
+ [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
+ BGP, LDP, PCEP, and MSDP Issues According to the Keying
+ and Authentication for Routing Protocols (KARP) Design
+ Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
+ <http://www.rfc-editor.org/info/rfc6952>.
+
+Acknowledgments
+
+ A special thanks to the PCE chairs for guidance regarding this work.
+
+ Thanks to Francesco Fondelli for his suggestions in clarifying the
+ L bit usage.
+
+ Thanks to Adrian Farrel for his review and comments.
+
+ Thanks to Jonathan Hardwick for shepherding the document and
+ providing text in Section 3.
+
+ Thanks to Deborah Brungard for her comments and being the responsible
+ AD.
+
+ Thanks to Peter Yee for the Gen-ART review.
+
+ Thanks to Alvaro Retana for comments during the IESG review.
+
+Author's Address
+
+ Dhruv Dhody
+ Huawei Technologies
+ Divyashree Techno Park, Whitefield
+ Bangalore, Karnataka 560066
+ India
+
+ Email: dhruv.ietf@gmail.com
+
+
+
+
+
+
+
+
+Dhody Standards Track [Page 5]
+