idnits 2.17.1 draft-dukes-lisp-colored-engineered-underlays-01.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 (December 18, 2017) is 2319 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 (-06) exists of draft-filsfils-spring-segment-routing-policy-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-lisp-ddt (ref. 'I-D.ietf-lisp-ddt') ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Downref: Normative reference to an Experimental RFC: RFC 8060 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Dukes 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track J. Arango 5 Expires: June 21, 2018 Microsoft 6 December 18, 2017 8 LISP Colored Engineered Underlays 9 draft-dukes-lisp-colored-engineered-underlays-01 11 Abstract 13 This document defines a LISP control plane extension that associates 14 a locator record with a color value that can be used to select an 15 engineered underlay path to the corresponding RLOC. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 21, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 53 3. Color LCAF . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 6.1. Informative References . . . . . . . . . . . . . . . . . 4 58 6.2. Normative References . . . . . . . . . . . . . . . . . . 4 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 61 1. Introduction 63 LISP [RFC6830] provides reachability to overlay addresses called 64 Endpoint Identifiers (EIDs) via one or more underlay addresses called 65 Routing Locators (RLOCs). For each destination RLOC, it may be 66 desirable for the control plane to select one of potentially multiple 67 underlay paths. 69 For traffic traversing an Ingress Transit Router (ITR) to an Egress 70 Transit Router (ETR), the ITR may be able to reach a particular ETR 71 RLOC through multiple underlay paths available via one or more 72 locally connected service providers. Furthermore, the ITR may be 73 able to select which of these paths per provider to use, for example 74 different paths may have unique bandwidth and latency metrics making 75 them more or less suitable for traffic destined to some EIDs. When 76 the ITR requests and obtains an EID mapping, it needs to know how to 77 choose an underlay path for each remote RLOC. If the ETR can provide 78 a hint in terms of an opaque color attribute for each RLOC the EID 79 maps to, then the ITR would be able to select a policy matching that 80 tuple to satisfy the needs of the application or 81 endpoint associated with this particular EID. 83 One expected use of the tuple is to select a Segment 84 Routing policy as defined in 85 [I-D.filsfils-spring-segment-routing-policy]. 87 This draft specifies an LCAF type [RFC8060] that encodes the color 88 for each RLOC in an EID mapping record. The ITR MAY use the color to 89 determine the underlay path to reach the EID via the corresponding 90 RLOC. 92 A locator record now has an RLOC and color, and both fields are part 93 of the comparison to determine if two locator records are the same. 95 The definition of how the color is chosen or configured at the ETR, 96 or how policies are distributed and configured at the ITR is outside 97 the scope of this document. 99 2. Requirements Notation 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 3. Color LCAF 107 When a color is stored in the LISP Mapping Database System for 108 selection of an appropriate policy to reach an EID via a destination 109 RLOC it MAY be encoded in a LISP Canonical Address. 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | AFI = LCAF (16887) | Rsvd1 | Flags | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Type = TBD |C|O| Rsvd2 | Length | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Color ... | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | ... Color | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | AFI | Address | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 CO Flags: The CO Flags are as defined in 124 [I-D.filsfils-spring-segment-routing-policy] and have the 125 following impact on how the subsequent Color is interpreted. 00 is 126 their default value. 128 When 00, the traffic destined to EID is preferably steered onto a 129 valid policy where RLOC is the IPv4/6 destination RLOC 130 address and C is a color value, else it is steered on the shortest 131 path to the RLOC. 133 When 01, the traffic destined to EID is preferably steered onto a 134 valid policy else onto a valid policy (null endpoint, C) 135 else on the shortest path to the RLOC. 137 When 10, the traffic destined to EID is preferably steered onto a 138 valid policy else onto a valid policy (null endpoint, C) 139 else on any valid SR-TE policy else on the IGP 140 path to the RLOC. 142 The null endpoint is 0.0.0.0 for IPv4 and ::0 for IPv6 (all bits 143 set to 0). 145 Color: A 64-bit color value. 147 AFI: The address family of the locator. Valid values are 1 for 148 IPv4 and 2 for IPv6. 150 Address: The address of the locator. 152 The Color Canonical Address Type can be used to encode RLOC 153 addresses. 155 Usage: This encoding can be used in RLOC records in Map-Requests, 156 Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT 157 [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended 158 EIDs are used in Map-Referral messages. 160 4. IANA Considerations 162 An assignment is requested from IANA "LISP LCAF Type" registry for 163 the "Color LCAF", value is TBD. 165 5. Security Considerations 167 The Color LCAF may indirectly indicate association of the type of 168 service offered by some subsets of endpoints to ITRs that was not 169 previously disclosed to the ITR. 171 6. References 173 6.1. Informative References 175 [I-D.filsfils-spring-segment-routing-policy] 176 Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, 177 F., Hegde, S., Lin, S., bogdanov@google.com, b., 178 Horneffer, M., Steinberg, D., Decraene, B., and S. 179 Litkowski, "Segment Routing Policy for Traffic 180 Engineering", draft-filsfils-spring-segment-routing- 181 policy-03 (work in progress), October 2017. 183 6.2. Normative References 185 [I-D.ietf-lisp-ddt] 186 Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 187 Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- 188 ddt-09 (work in progress), January 2017. 190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 191 Requirement Levels", BCP 14, RFC 2119, 192 DOI 10.17487/RFC2119, March 1997, 193 . 195 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 196 Locator/ID Separation Protocol (LISP)", RFC 6830, 197 DOI 10.17487/RFC6830, January 2013, 198 . 200 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 201 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 202 February 2017, . 204 Authors' Addresses 206 Darren Dukes 207 Cisco Systems 208 Canada 210 Email: ddukes@cisco.com 212 Jesus Arango 213 Microsoft 214 USA 216 Email: jearango@microsoft.com