idnits 2.17.1 draft-kowal-lisp-policy-distribution-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (15 September 2021) is 953 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-07 Summary: 2 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 M. Kowal 3 Internet-Draft M. Portoles 4 Intended status: Experimental Cisco Systems 5 Expires: 19 March 2022 A. Jain 6 Juniper Networks 7 D. Farinacci 8 lispers.net 9 15 September 2021 11 LISP Transport for Policy Distribution 12 draft-kowal-lisp-policy-distribution-01 14 Abstract 16 This document describes the use of the Locator/ID Separation Protocol 17 (LISP) to encode and transport data models for the configuration of 18 LISP ITRs. 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 19 March 2022. 43 Copyright Notice 45 Copyright (c) 2021 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 (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 2 61 3. Policy Distribution Use Cases . . . . . . . . . . . . . . . . 3 62 4. Policy Distribution: Packet Flow Description . . . . . . . . 3 63 4.1. Policy Distribution . . . . . . . . . . . . . . . . . . . 4 64 4.2. Policy Updates . . . . . . . . . . . . . . . . . . . . . 5 65 5. Mapping System Operations . . . . . . . . . . . . . . . . . . 6 66 6. Policy Distribution Process . . . . . . . . . . . . . . . . . 6 67 7. Policy Distribution Encoding . . . . . . . . . . . . . . . . 6 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 10.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 When LISP ITRs are deployed with enough configuration to build a LISP 78 overlay, they may require additional configurations such as security, 79 QoS, and/or traffic forwarding policies. As networks continue to 80 grow, it can be challenging to ensure these configurations are 81 distributed to many ITRs and kept in sync. LISP network operators 82 may wish to re-use their existing LISP architecture to distribute 83 these configurations as opposed to configuring them by hand, using a 84 script, or investing in a configuration management system. The 85 configurations can be distributed via a mapping system that the 86 network operator manages or is managed by a third-party as part of a 87 managed service offering. 89 2. Definition of Terms 91 LISP related terms are defined as part of the LISP specification 92 [RFC6830], notably EID, RLOC, Map-Request, Map- Reply, Map-Notify, 93 Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map- Server 94 (MS) and Map-Resolver (MR). 96 3. Policy Distribution Use Cases 98 The ITR could use the mapping system to receive configuration 99 policies for use cases such as: 101 * The RLOC interfaces of an ITR may be connected to WAN links that 102 are policed at sub-line rate by its upstream provider. Using the 103 mapping system, the ITR could receive and apply the QoS policies 104 that would shape traffic to the correct rate on each ITR RLOC 105 interface. 107 * ITRs use the mapping system to receive access-list (ACL) 108 configuration(s) that would allow them to restrict traffic from 109 authorized sources to authorized services. 111 * ITRs receive configurations that determine local forwarding 112 policies, such as specifying ITR RLOCs to be used for egress 113 forwarding on a per-application basis or RLOCs on different ITRs 114 within the same LISP site to maintain application symmetry. 116 * Baseline configurations for common services (e.g., DNS, SSH, 117 Syslog) can be maintained in a mapping system and distributed 118 across multiple ITRs. 120 Policy distribution is not meant to provide zero-touch provisioning 121 for ITRs within a LISP network. At a minimum, the ITR must have a 122 map resolver defined, IP connectivity to the map resolver, and one or 123 more distinguished names defined for receiving specific policies from 124 the mapping system. 126 4. Policy Distribution: Packet Flow Description 128 The following figure illustrates a reference system used to support 129 packet flow descriptions in this section. 131 +----------+ +-+---+ 132 |controller|---------|MS/MR| 133 +----------+ +-----+ 134 | 135 _..-._.--._...._.,.-|_.,--._.-_._.-.._ 136 .-.' '.-. 137 ( RLOC SPACE ) 138 ( ) 139 '..'.-._.'--'._.'.-._.'.-._.'.-._.'.-._.'.--.' 140 / \ 141 (ifaceA) (ifaceB) 142 +-+--+--+ +-+--+--+ 143 .| xTR A |.-. .| xTR B |.-. 144 ( +-+--+--+ ) ( +-+--+--+ ) 145 .' Site A ) .' Site B ) 146 ( . ( . 147 '--'._.'. ) '--'._.'. ) 148 '--' '--' 150 Figure 1: Reference system for policy distribution 152 The reference system contains two sites, site A and site B, with 153 corresponding xTR-A and xTR-B providing encapsulation and 154 decapsulation services for the overlay traffic. xTR-A uses 155 interface-A to forward and receive encapsulated traffic through the 156 RLOC space; and xTR-B uses interface-B for it. 158 For packet flow purposes the reference system assumes that a network 159 controller provides the policies to a map-server. 161 When an ITR comes up, it requests it's designated policies with it's 162 map-server. The MS may have this policy configured by the 163 administrator via a network controller. 165 4.1. Policy Distribution 167 The following is an illustration of the sequence to distribute a 168 policy registered by the controller with the mapping system, down to 169 an ITR that requests its designated policies. In the example 170 represents the hostname of the ITR that learns a policy using this 171 mechanism. 173 * The Mapping-System is either configured by an operator or learns a 174 mapping sent by a controller though a Map-Register. The Mapping 175 System learns the mapping: EID="policy-" --> RLOC= "{ 176 "shape":{ "interface":"ifaceA", "direction":"outbound", 177 "value":100Mbps }}". The EID is encoded as a Distinguished Name 178 and the RLOC as a JSON string. 180 * ITR-A is configured to dynamically learn policies from the Mapping 181 System with the name "policy-ITR-A" (policy followed by its 182 hostname). 184 * ITR-A sends a Map-Request to the Mapping System with EID="policy- 185 " encoded as a Distinguished Name. The Map-Request is sent 186 with the N-bit set. 188 * The Mapping System forwards the request to the appropriate Map- 189 Server. The Map-Server adds ITR-A to the subscription list of 190 EID="policy-" and sends back a Map-Notify with the mapping 191 that the controller has registered. 193 * When ITR-A receives the Map-Notify installs the received policy 194 locally, to shape traffic sent over the RLOC facing interface. 196 * Note that when the map-server has multiple policies associated 197 with this ITR, it can send each one of the policies as an 198 additional locator record (following the same JSON format) in the 199 mapping. The locator count in the Map-Notify reflects the number 200 of policies distributed with the mapping. 202 4.2. Policy Updates 204 Policy distribution takes advantage of the LISP pubsub model to 205 ensure that router updates are properly distributed when policies 206 change. In such a case, and using the same reference sytem as above, 207 the information exchange is as follows: 209 * The controller sends a Map-Register to the Mapping System, 210 updating the policy mapping with: EID="policy-" --> RLOC= 211 "{ "shape":{ "interface":"ifaceA", "direction":"outbound", 212 "value":200Mbps }}". 214 * When the corresponding Map-Server receives this update it checks 215 the list of ITRs subscribed for updates of EID="policy-" 216 and finds out that ITR-A is subscribed. 218 * The Map-Server sends a Map-Notify to ITR-A with the updated 219 mapping information that has been registered. 221 * When ITR-A receives and validates the Map-Notify, it updates the 222 local policy, changing the shaping rate as specified in the new 223 JSON description. Note that if the JSON specifies the same policy 224 that is currently applied the notification is ignored. 226 5. Mapping System Operations 228 The mapping system that is used for distributing policy 229 configurations can be managed by either the administrator who owns 230 and operates their own LISP sites or a third-party administrator who 231 offers LISP mapping system functionality as a managed service. A 232 controller or orchestrator could be used to update and optimize 233 policies within the mapping system based on network or ITR telemetry. 235 Within the mapping system, the administrator must define a 236 distinguished name that is specific to an ITR. The distinguished 237 name is associated with the specific policy configurations that the 238 ITR is to receive. Each ITR is configured with the minimal 239 requirements to perform a mapping request procedure as well as a 240 distinguished name that can be matched upon in the mapping system. 242 Map-Servers should be able to receive policy registrations through 243 the Map-Registration process. The Map-Registration must encode the 244 policy following the specification in the policy distribution 245 encoding section. 247 6. Policy Distribution Process 249 The ITR subscribes to its policy via the Map-Request procedure 250 defined in section 5 of [I-D.ietf-lisp-pubsub]. The PubSub procedure 251 is used to ensure that policies can be updated or audited after an 252 ITR has received them. Policies are published to the ITR from the 253 mapping system using the mapping notification procedure defined in 254 section 6 of [I-D.ietf-lisp-pubsub]. 256 EID-to-RLOC mappings used for policy distribution are of the type EID 257 to RLOC . The EID is 258 a distinguished name uniquely identifying a router in the system, 259 while each RLOC record uses JSON encoding to specify the particular 260 policy (or policies) that this router needs to implement. 262 7. Policy Distribution Encoding 264 When the ITR is configured to receive a policy using a distinguished 265 name, the ITR sends a subscription for the EID record encoded as this 266 Distinguished Name. When a policy has been registered with the 267 Mapping System for this Distinguished Name, the ITR receives a 268 publication with a list of policies as RLOC records and encoded as 269 JSON strings (as defined in section 5.4 of [RFC8060]. 271 Example encoding for QoS policy that shapes traffic to 50 percent of 272 the line-rate: EID-Record encoded as distinguished name "policy-ce- 273 router1" RLOC-Record record encoded as JSON string "{ "shape":{ 274 "interface":"ethernet1", "direction":"outbound", "unit":"percent", 275 "value":50 }}" 277 Example encoding for setting the ITR's NTP server to 1.1.1.1: EID- 278 Record encoded as distinguished name "policy-ce-router" RLOC-Record 279 record encoded as JSON string "{ "NTP-address" : "1.1.1.1" }" 281 Multiple ITRs can be configured to use multiple distinguished names 282 for receiving multiple sets policies. This allows for an ITR to 283 receive specific policies and many ITRs to receive policies that can 284 be broadly applied. Referring to the two examples above, an ITR can 285 be configured to use a distinguished name of "policy-ce-router1" to 286 receive a QoS configuration that is specific to that node while also 287 using a distinguished name of "policy-ce-router" to receive 288 configurations that are common to each ITR in the LISP network (e.g., 289 NTP configuration). The use of multiple distinguished names per ITR 290 reduces the amount of configuration within the mapping system. 292 8. IANA Considerations 294 This memo includes no request to IANA. 296 9. Acknowledgements 298 Thanks to James Stankiewicz for his thorough comments and 299 suggestions. 301 10. References 303 10.1. Normative References 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, 307 DOI 10.17487/RFC2119, March 1997, 308 . 310 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 311 Locator/ID Separation Protocol (LISP)", RFC 6830, 312 DOI 10.17487/RFC6830, January 2013, 313 . 315 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 316 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 317 February 2017, . 319 10.2. Informative References 321 [I-D.ietf-lisp-pubsub] 322 Rodriguez-Natal, A., Ermagan, V., Cabellos-Aparicio, A., 323 Barkai, S., and M. Boucadair, "Publish/Subscribe 324 Functionality for LISP", Work in Progress, Internet-Draft, 325 draft-ietf-lisp-pubsub-07, 8 January 2021, 326 . 329 Authors' Addresses 331 Michael Kowal 332 Cisco Systems 333 111 Wood Ave. South 334 Iselin, NJ 08830 335 United States of America 337 Email: mikowal@cisco.com 339 Marc Portoles Comeras 340 Cisco Systems 341 170 Tasman Drive 342 San Jose, CA 95134 343 United States of America 345 Email: mportole@cisco.com 347 Amit Jain 348 Juniper Networks 349 1133 Innovation Way 350 Sunnyvale, CA 94089 351 United States of America 353 Email: atjain@juniper.net 355 Dino Farinacci 356 lispers.net 357 San Jose, CA 358 United States of America 360 Email: farinacci@gmail.com