idnits 2.17.1 draft-kompella-spring-dhcp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2019) is 1754 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-mpls-rmr-11 == Outdated reference: A later version (-02) exists of draft-kompella-spring-rmr-00 == Outdated reference: A later version (-06) exists of draft-bonica-spring-srv6-plus-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella 3 Internet-Draft R. Bonica 4 Intended status: Standards Track Juniper Networks 5 Expires: January 8, 2020 July 7, 2019 7 Using DHCP to Manage Node and Ring SID Assignment 8 draft-kompella-spring-dhcp-00 10 Abstract 12 Node and ring segment identifiers (SIDs) assignements in a particular 13 domain (such as an IGP area) must follow certain rules: they must be 14 allocated from a configured set of SID blocks; they must be unique; 15 and the values should be sticky, i.e., the same value(s) should be 16 assigned to a node should its assignment expire (as might happen if 17 the node resets). This memo suggests the use of the Dynamic Host 18 Configuration Protocol to handle such assignments. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 8, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Operational Requirements . . . . . . . . . . . . . . . . . . 2 62 3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 67 6.2. Informative References . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 Fundamental to SPRING forwarding is the notion of Segment Identifiers 73 (SIDs) [RFC8402]. At a high level, there are two types of SIDs: 74 those that are locally assigned by the advertising node, such as 75 adjacency and binding SIDs; and those that are globally unique within 76 a given SPRING domain, such as node and ring SIDs. Node SIDs are 77 often manually configured on routers today; this is not only tedious, 78 but error-prone as well; the addition of ring SIDs which must be 79 managed per ring makes manual assignment even more fraught 80 ([I-D.kompella-spring-rmr]). 82 This document describes the use of the Dynamic Host Configuration 83 Protocol (DHCP [RFC2132]) for managing global SID allocation. The 84 description is limited to the use of node and ring SIDs for MPLS 85 ([I-D.ietf-spring-segment-routing-mpls]); other types of SID 86 allocation, such as for SRv6+ ([I-D.bonica-spring-srv6-plus]) will be 87 described in a future version. 89 2. Operational Requirements 91 Node SID assignments must satisfy the following properties: 93 A SID allocation is an index within a block. This block is 94 defined by a base value (SRGB) and a range; the SID value MUST 95 fall within the range. 97 SID assignments MUST be unique. Duplicate assignments can have 98 serious forwarding consequences, such as loops and packet 99 misdelivery. 101 and should have the following properties: 103 Assignments SHOULD have a long lease time. 105 Assignments SHOULD be "sticky", i.e., a node re-requesting a 106 global SID of the same type that it had previously requested 107 SHOULD be assigned the same SID (if possible). 109 An expired SID SHOULD NOT be re-assigned to another node until 110 sufficient time has passed. This time SHOULD be configurable on 111 the DHCP server. 113 3. Theory of Operation 115 A DHCP server to be used for global SID assignment SHOULD be told the 116 following: 118 The type of SID (node, anycast, ring, ...) 120 The block or set of blocks for each type: SRGB and range. 122 The default lease time and hold time (before re-assigning a SID to 123 a different node). 125 The DHCP server need know nothing about SID semantics; the only thing 126 it needs to know is that ring SIDs are allocated in pairs, and all 127 other SIDs are allocated singly. 129 A node taking part in a SPRING network MAY be configured to use DHCP 130 to get node SIDs. This configuration should say whether to use DHCP 131 for its loopback address, for anycast SIDs and/or for ring SIDs. 133 A node configured to use DHCP to obtain a SID for its loopback and/or 134 any other prefix sends a request to the DHCP server including the 135 following information: 137 the type of SID 139 the prefix 141 A node that participates in an RMR ring and is configured to use DHCP 142 to obtain a pair of ring SIDs sends, once ring identification is 143 complete ([I-D.ietf-mpls-rmr]), a DHCP request including: 145 the type of SID (ring SID) 147 the ring ID 149 The DHCP server replies to such requests by: 151 1. looking up the type of SID request; 153 2. checking if it has previously allocated a SID for this node and 154 prefix (or pair of SIDs for this node and ring ID); 156 3. if so, checking if the same SID (or pair of SIDs) is available; 157 if so, allocating that SID (or pair of SIDs) and returning. 159 4. Otherwise, allocating a new SID/pair of SIDs, noting this in its 160 database, and returning. 162 4. Security Considerations 164 DHCP is a very widely used protocol, and thus ensuring its continuing 165 secure and robust operation is vital. When the requirements of DHCP 166 in this context are better understood, this section will be filled 167 out. 169 5. IANA Considerations 171 Should this document be deemed useful, relevant IANA code points 172 would be requested. 174 6. References 176 6.1. Normative References 178 [I-D.ietf-mpls-rmr] 179 Kompella, K. and L. Contreras, "Resilient MPLS Rings", 180 draft-ietf-mpls-rmr-11 (work in progress), June 2019. 182 [I-D.ietf-spring-segment-routing-mpls] 183 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 184 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 185 data plane", draft-ietf-spring-segment-routing-mpls-22 186 (work in progress), May 2019. 188 [I-D.kompella-spring-rmr] 189 Kompella, K., Deshmukh, A., and R. Torvi, "Resilient MPLS 190 Rings", draft-kompella-spring-rmr-00 (work in progress), 191 October 2018. 193 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 194 Requirement Levels", BCP 14, RFC 2119, 195 DOI 10.17487/RFC2119, March 1997, 196 . 198 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 199 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 200 . 202 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 203 Decraene, B., Litkowski, S., and R. Shakir, "Segment 204 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 205 July 2018, . 207 6.2. Informative References 209 [I-D.bonica-spring-srv6-plus] 210 Bonica, R., Hegde, S., Kamite, Y., Alston, A., Henriques, 211 D., Halpern, J., and J. Linkova, "IPv6 Support for Segment 212 Routing: SRv6+", draft-bonica-spring-srv6-plus-03 (work in 213 progress), July 2019. 215 Authors' Addresses 217 Kireeti Kompella 218 Juniper Networks 219 1194 N. Mathilda Ave. 220 Sunnyvale, CA 94089 221 US 223 Email: kireeti.kompella@gmail.com 225 Ron Bonica 226 Juniper Networks 227 1194 N. Mathilda Ave. 228 Sunnyvale, CA 94089 229 US 231 Email: rbonica@juniper.net