LSR Working Group U. Chunduri, Ed. Internet-Draft R. Li Intended status: Standards Track Huawei USA Expires: January 17, 2019 K. Smith Vodafone July 16, 2018 Resources for Preferred Path Routes in IGPs draft-cls-ppr-te-attributes-00 Abstract Preferred Path Routing (PPR) is concerned with setting up the route for a given prefix as specified in the path description along with a corresponding data plane/forwarding identifier PPR-ID. This document specifies an extension to PPR, a mechanism to perform resource reservations nodes on Preferred Path Routes (PPR) for IGPs (IS-IS, OSPFv2, OSPFv3). This is done by specifying the resources that need to be reserved along the path using PPR path attributes. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119], RFC8174 [RFC8174] when, and only when they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the 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 https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 17, 2019. Chunduri, et al. Expires January 17, 2019 [Page 1] Internet-Draft Resources for Preferred Path Routes in IGPs July 2018 Copyright Notice Copyright (c) 2018 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 (https://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. PPR Resource Reservation Related Parameters . . . . . . . . . 4 3.1. IS-IS Parameters . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Bandwidth Sub-TLV . . . . . . . . . . . . . . . . . . 4 3.1.2. Burst Size Sub-TLV . . . . . . . . . . . . . . . . . 5 3.1.3. Per-hop Queuing Latency Sub-TLV . . . . . . . . . . . 5 3.1.4. Lifetime Sub-TLV . . . . . . . . . . . . . . . . . . 6 3.1.5. Node Resource Capability Sub-TLV . . . . . . . . . . 7 3.1.6. Node Status TLV . . . . . . . . . . . . . . . . . . . 8 3.1.7. IS-IS TE Metric Extensions . . . . . . . . . . . . . 9 3.1.7.1. Per PPR queuing delay on the node . . . . . . . . 10 3.1.7.2. Unidirectional Utilized PPR Bandwidth . . . . . . 10 3.2. OSPFv2/OSPFv3 Parameters . . . . . . . . . . . . . . . . 11 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6.1. IGP Common Parameters . . . . . . . . . . . . . . . . . . 12 6.2. IS-IS Registries . . . . . . . . . . . . . . . . . . . . 12 6.3. OSPFv2 Registries . . . . . . . . . . . . . . . . . . . . 13 6.4. OSPFv3 Registries . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Chunduri, et al. Expires January 17, 2019 [Page 2] Internet-Draft Resources for Preferred Path Routes in IGPs July 2018 1. Introduction RSVP [RFC2205] allows out of band signaling along a specified path for resource reservations. This is done by sending PATH/RESV message with flow-spec/filter-spec. RSVP-TE [RFC3209], builds on RSVP protocol and defines new objects, modifies existing objects for MPLS LSP establishment with resources (reserved bandwidth). This is less widely deployed perhaps due to soft-state maintenance, scaling and management overhead considerations. [RFC8370] addresses some of the concerns by specifying refresh independence and per-peer flow control which would reduce processing cycles required to maintain LSP state. Segment Routing [I-D.ietf-spring-segment-routing] enables packet steering with a specified path in the packet itself. This is defined for MPLS (with a set of stacked labels) and IPv6 (path described as list of IPv6 addresses in SRHeader) data planes called SR-MPLS and SRv6 respectively. Routing with Preferred Paths with an optimized data plane (regardless of the type of data plane) is described in [I-D.chunduri-lsr-isis-preferred-path-routing].With PPR nodes in IGP compute the nexthops based on the path description for the prefix. This results in multiple benefits, including increased performance, compatibility and reduction of the data plane overhead of both path and services along the path. While these allow packet steering on a specified path (either encoded in the packet itself or through a data plane identifier), they do not have any notion of QoS or resources reserved along the path. This document extends PPR to indicate the resources to be reserved along the preferred path. These resources are required in some deployments [I-D.clt-dmm-tn-aware-mobility], for not only providing committed bandwidth or deterministic latency, but also for assuring overall service level guarantee in the network. This approach does not require per-hop provisioning and also reduces the OPEX by minimizing the number of protocols needed and allows dynamism with FRR capabilities. Unlike RSVP-TE [RFC3209], the approach does not rely on periodic refreshes for state synchronization between neighbors. 1.1. Acronyms MPLS - Multi Protocol Label Switching MTU - Maximum Transferrable Unit PPR - Preferred Path Routing/Route PPR-ID - Preferred Path Route Identifier, a data plane identifier Chunduri, et al. Expires January 17, 2019 [Page 3] Internet-Draft Resources for Preferred Path Routes in IGPs July 2018 SID - Segment Identifier SR-MPLS - Segment Routing with MPLS data plane SRH - Segment Routing Header - IPv6 routing Extension header SRv6 - Segment Routing with Ipv6 data plane with SRH TE - Traffic Engineering 2. Solution Overview Key aspect of the solution concerns with specifying the resources to be reserved along the preferred path [I-D.chunduri-lsr-isis-preferred-path-routing], [I-D.chunduri-lsr-ospf-preferred-path-routing].Reservations are expressed in terms of required resources (bandwidth), traffic characteristics (burst size), and service level parameters (expected maximum latency at each hop) based on the capabilities of each node and link along the path. The second part of the solution is providing mechanism to indicate the status of the reservations requested i.e., if these have been honored by individual node/links in the path. This is done by defining a new TLV/Sub-TLV in respective IGPS. Another aspect is additional node level TLVs and extensions to [RFC7810] and [RFC7471] to provide accounting/usage statistics that have to be maintained at each node per preferred path. All the above is specified for IS-IS/OSPFv2/OSPFv3 protocols. 3. PPR Resource Reservation Related Parameters This section describes the encoding of additional TLVs and Sub-TLVs needed for resource reservations, associated accounting statistics for Preferred Path Routes in IS-IS/OSPFv2/OSPFv3 protocols. 3.1. IS-IS Parameters [I-D.chunduri-lsr-isis-preferred-path-routing] defines few PPR- Attribute Sub-TLVs and this document extends the same for resources to be reserved through various Sub-TLVs. The following additional IS-IS PPR-Attribute Sub-TLVs (Type - IANA TBD) are defined: 3.1.1. Bandwidth Sub-TLV This is the required bandwidth for the PPR at each node/link in the path description. It has minimum (CIR) and maximum bandwidth (PIR). Chunduri, et al. Expires January 17, 2019 [Page 4] Internet-Draft Resources for Preferred Path Routes in IGPs July 2018 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Bandwidth Sub-TLV Format o Type: TBD (IANA) o Length: 10 Octets o Minimum bandwidth: The minimum bandwidth required, or CIR, unit Mbps o Maximum bandwidth: The maximum bandwidth required, or PIR, unit Mbps 3.1.2. Burst Size Sub-TLV This is the required burst for the PPR and is the maximum burst size. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Burst Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Burst Size Sub-TLV Format o Type: TBD (IANA) o Length: 6 Octets o Burst size: The burst size, unit K bytes 3.1.3. Per-hop Queuing Latency Sub-TLV This is the bounded latency for each hop on the PPR. This is not the end to end latency. Chunduri, et al. Expires January 17, 2019 [Page 5] Internet-Draft Resources for Preferred Path Routes in IGPs July 2018 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type | Length | Reserved |T| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Latency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Per-hop Queuing Latency Sub-TLV Format o Type: TBD (IANA) o Length: 6 Octets o Flags: 1 Octet T Bit - Set to 0, if Queuing Latency in milliseconds and Set to 1, If Queuing Latency in microseconds Latency: Expected maximum queuing latency for each hop When an expected hop-by-hop latency is given, the bandwidth expectation (CIR) MUST be present. 3.1.4. Lifetime Sub-TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type | Length | Reserved| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Lifetime Sub-TLV Format o Type: TBD (IANA) o Length: 6 Octets o Flags: 1 Octet o Life Time: Life time of reservations done at each node in Seconds See the usage of this TLV and procedures after Lifetime expiration and related details in Section 4. Chunduri, et al. Expires January 17, 2019 [Page 6] Internet-Draft Resources for Preferred Path Routes in IGPs July 2018 3.1.5. Node Resource Capability Sub-TLV The node Resource Capability Sub-TLV is defined within the body of the IS-IS Router Capability TLV [RFC7981]. This would allow what all TE parameters than can be supported by a node. This sub-TLV lists all supported TE capabilities. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type | Length | RC Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: IS-IS Reservation Capability Sub-TLV Format o Type: TBD (IANA) from IS-IS Router Capability TLV Registry o Length: Total length of the value field in bytes o RC Flags: 2 Octets Reservation Capability Sub-TLV bit-field Format Reservation Capability bit-field Format 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B|S|L|T| Reserved |E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Bit-0: B Bit: If this bit is set, Min/Max bandwidth reservation is supported by the node o Bit-1: S Bit: If this bit is set burst size handling is supported by the node o Bit-2: L Bit: If this bit is set per hop maximum queuing latency is supported by the node o Bit-3: T Bit: If this bit is set an expiration timer for PPR-ID is supported by the node o Bit-15: E Bit: If this bit is set one more 16-bit status bit-field is followed to this bit-field. Chunduri, et al. Expires January 17, 2019 [Page 7] Internet-Draft Resources for Preferred Path Routes in IGPs July 2018 Rest of the bits undefined and transmitted as unset/0. 3.1.6. Node Status TLV A new top level IS-IS TLV is defined to indicate the status of per preferred path TE resource reservation by each node, where it is part of one ore more PPRs. This TLV should be generated by a node which is along the preferred path and which does the reservation of resources as indicated in the above TE parameters. Structure of this TLV: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Sub-TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Node Status TLV Format o Type: TBD (IANA) - From IS-IS top level TLV registry o Length: Total length of the value field in bytes o Sub-TLVs : One or more Sub-TLVs This document defines one of the Sub-TLVs in the above TLV. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type | Length | PPR-ID Type | PPR-ID Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // PPR-ID Value (Size variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |16-bit status bit-field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Reservation Status Sub-TLV Format Chunduri, et al. Expires January 17, 2019 [Page 8] Internet-Draft Resources for Preferred Path Routes in IGPs July 2018 Reservation Status Sub-TLV bit-field Format Reservation Status bit-field Format 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B|S|L|T| Reserved |E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Bit-0: B Bit: If this bit is set, Min/Max bandwidth reservation for the PPR-ID is present o Bit-1: S Bit: If this bit is set burst size handling for the PPR- ID is present o Bit-2: L Bit: If this bit is set per hop maximum queuing latency enforcement is present o Bit-3: T Bit: If this bit is set an expiration timer is present o Bit-15: E Bit: If this bit is set one more 16-bit status bit-field is followed to this bit-field. Rest of the bits undefined and transmitted as unset/0. Once preferred path is received through IGP as defined in [I-D.chunduri-lsr-isis-preferred-path-routing] and with the extensions as specified in this document for resources reservation, a node on the path allocate the resources requested in the hardware. However after resources are allocated in the hardware, status of the same is given to the respective IGP in the control plane, which would enable IGP to indicate the status in the structure described above. If record is missing in the above structure, for that preferred path reservations could have been withdrawn. 3.1.7. IS-IS TE Metric Extensions Once resource reservations are done, usage statistics need to be maintained and further transported to a central entity. Each node on PPR path, the following stat(s) need to be maintained. More parameters TBD. Chunduri, et al. Expires January 17, 2019 [Page 9] Internet-Draft Resources for Preferred Path Routes in IGPs July 2018 3.1.7.1. Per PPR queuing delay on the node This Sub-TLV advertises the average PPR queue delay variation in the node. This is a 24-bit field carries the average PPR queue delay over a configurable interval in microseconds The delay variation advertised. The format of this Sub-TLV is shown in the following diagram: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED | Avg. queue Delay Variation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PPR-ID Type | PPR-ID Len | PPR-ID Value (Size variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: QUEUE Delay Sub-TLV Format o where: Type: TBD IANA - from the node capabilities TLV. Length: Variable RESERVED: This field is reserved for future use. It MUST be set to 0 when sent and MUST be ignored when received. Delay Variation: This 24-bit field carries the average PPR queue delay variation over a configurable interval in microseconds, encoded as an integer value. When set to 0, it has not been measured. When set to the maximum value 16,777,215 (16.777215 sec), then the delay is at least that value and may be larger. 3.1.7.2. Unidirectional Utilized PPR Bandwidth This Sub-TLV advertises the PPR bandwidth utilization per PPR-ID in the node. The bandwidth utilization advertised by this Sub-TLV MUST be the bandwidth from the system originating this Sub-TLV. The format of this Sub-TLV is shown in the following diagram: Chunduri, et al. Expires January 17, 2019 [Page 10] Internet-Draft Resources for Preferred Path Routes in IGPs July 2018 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Utilized Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PPR-ID Type | PPR-ID Len | PPR-ID Value (Size variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: TLV Format where: o Type: IANA (TBD) - from the "Sub-TLVs for TLVs 22, 23, 141, 222, and 223" registry: o Length: Total length of the value field in bytes o Utilized Bandwidth: This field carries the bandwidth utilization per PPR-ID on a link , forwarding adjacency, or bundled link in IEEE floating-point format with units of bytes per second. Considerations for a link or forwarding adjacency or for a bundled link is similar to Section 4.7 of RFC 7810. 3.2. OSPFv2/OSPFv3 Parameters Similar extensions are needed for OSPFv2 and OSPFv3 PPR TLV's PPR attributes except the Type (respective suggested values in Section 6.3 and Section 6.4) and Length fields are 2 octets each. New Sub-TLVs are also needed for Node status similar to Figure 6 and TE parameter extensions similar to Section 3.1.7 for OSPFv2 and OSPFv3 protocols. 4. Elements of Procedure If a PPR has attributes as specified in Section 3 for reserving resources along the path, individual nodes in the path description acts on the path attributes. Section 3 defines few PPR-Attributes for allocating/reserving resources in each node of the PPR path description. Presence of these Sub-TLVs instruct to provision the hardware with appropriate parameters as specified. Traffic accounting should happen concerning to the resource in question, when the actual data traffic hits for the PPR-ID in the forwarding plane. New attribute values can be updated for an existing PPR-ID and when the PPR-ID is withdrawn corresponding resources along the path MUST be removed along with the Status TLV Figure 7 update. Chunduri, et al. Expires January 17, 2019 [Page 11] Internet-Draft Resources for Preferred Path Routes in IGPs July 2018 After the data plane is programmed for a TE, a TE state is created. The TE state life is determined by the "Life Time" in the PPR attribute Sub-TLV. Whenever there is a packet processed by a TE state for the respective PPR-ID, the associated timer for the TE state is reset. If the timer of a TE state is expired, the TE state will be erased and the associated resource can be released and accordingly and Node Status TLV Figure 7 would be updated. In order to keep the TE state active, IGP LSP/LSA refresh has to happen and it should be less than the time of "Life time" attribute (Section 3.1.4). 5. Acknowledgements TBD. 6. IANA Considerations 6.1. IGP Common Parameters This document requests additional IANA registries in an IANA managed registry "Interior Gateway Protocol (IGP) Parameters" for various PPR TLV parameters. The registration procedure is based on the "Expert Review" as defined in [RFC8126]. The suggested registry names are: 6.2. IS-IS Registries This document requests IANA to create a new Sub-TLV registry for IS- IS PPR TLV Section 3 with the following initial entries (suggested values): Sub-TLV # Sub-TLV Name --------- --------------------------------------------------------- 5 Bandwidth (Section 3.1.1) 6 Burst Size (Section 3.1.2) 7 Per-hop Queuing Latency (Section 3.1.3) 8 Lifetime (Section 3.1.4) This document also requests a new Sub-TLV code point from IS-IS Router Capability TLV Registry as defined by [RFC8126] and an IS-IS top level Status TLV code point from IANA IS-IS TLV code- point registry. Chunduri, et al. Expires January 17, 2019 [Page 12] Internet-Draft Resources for Preferred Path Routes in IGPs July 2018 6.3. OSPFv2 Registries This document requests IANA to create a new Sub-TLV registry for OSPFv2 PPR TLV Section 3 with the following initial entries (suggested values): Sub-TLV # Sub-TLV Name --------- --------------------------------------------------------- 4 Bandwidth (Section 3.2) 5 Burst Size (Section 3.2) 6 Per-hop Queuing Latency (Section 3.2) 7 Lifetime (Section 3.2) 6.4. OSPFv3 Registries This document requests IANA to create a new Sub-TLV registry for OSPV3 PPR TLV Section 3 with the following initial entries (suggested values): Sub-TLV # Sub-TLV Name --------- --------------------------------------------------------- 4 Bandwidth (Section 3.2) 5 Burst Size (Section 3.2) 6 Per-hop Queuing Latency (Section 3.2) 7 Lifetime (Section 3.2) 7. Security Considerations Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. Further security analysis for IS-IS protocol is done in [RFC7645] with detailed analysis of various security threats and why [RFC5304] should not be used in the deployments. OSPF security extensions are described in [RFC2328] and [RFC7684] and these apply to the extensions specified in this document. While OSPF is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPF routing domain. In these deployments, stronger authentication mechanisms such as those specified in [RFC7474] SHOULD be used. Chunduri, et al. Expires January 17, 2019 [Page 13] Internet-Draft Resources for Preferred Path Routes in IGPs July 2018 Advertisement of the additional information defined in this document introduces no new security concerns in IS-IS or OSPF protocols. 8. References 8.1. Normative References [I-D.chunduri-lsr-isis-preferred-path-routing] Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", draft-chunduri-lsr-isis-preferred-path-routing-01 (work in progress), July 2018. [I-D.chunduri-lsr-ospf-preferred-path-routing] Chunduri, U., Qu, Y., White, R., Tantsura, J., and L. Contreras, "Preferred Path Routing (PPR) in OSPF", draft- chunduri-lsr-ospf-preferred-path-routing-01 (work in progress), July 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 8.2. Informative References [I-D.clt-dmm-tn-aware-mobility] Chunduri, U., Li, R., Tantsura, J., Contreras, L., and X. Foy, "Transport Network aware Mobility for 5G", draft-clt- dmm-tn-aware-mobility-01 (work in progress), July 2018. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, . [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . Chunduri, et al. Expires January 17, 2019 [Page 14] Internet-Draft Resources for Preferred Path Routes in IGPs July 2018 [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, . [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, . [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, . [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, . [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 7810, DOI 10.17487/RFC7810, May 2016, . [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Chunduri, et al. Expires January 17, 2019 [Page 15] Internet-Draft Resources for Preferred Path Routes in IGPs July 2018 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and T. Saad, "Techniques to Improve the Scalability of RSVP-TE Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, . Authors' Addresses Uma Chunduri (editor) Huawei USA 2330 Central Expressway Santa Clara, CA 95050 USA Email: uma.chunduri@huawei.com Richard Li Huawei USA 2330 Central Expressway Santa Clara, CA 95050 USA Email: renwei.li@huawei.com Kevin Smith Vodafone UK Email: kevin.smith@vodafone.com Chunduri, et al. Expires January 17, 2019 [Page 16]