idnits 2.17.1 draft-jearango-lisp-stateful-pull-model-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 3, 2017) is 2611 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC6830' is defined on line 250, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) 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 J. Arango 3 Internet-Draft J. Leong 4 Intended status: Experimental Cisco Systems 5 Expires: September 4, 2017 March 3, 2017 7 LISP Stateful Pull Model 8 draft-jearango-lisp-stateful-pull-model-00.txt 10 Abstract 12 This document specifies a stateful pull model for LISP where ITRs can 13 subscribe with the mapping system to be notified whenever a 14 particular EID mapping changes. The model uses a publish/subscribe 15 mechanism that supports overlapping EID registrations without having 16 to notify the ITR about every single prefix covered by a particular 17 subscription. The pull model is stateful in the sense that it 18 requires that the mapping system maintain subscription state. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 4, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 56 3. Subscription Establishement . . . . . . . . . . . . . . . . . 2 57 4. Publication of Overlapping Prefixes . . . . . . . . . . . . . 3 58 5. Mobility and Barrier Prefixes . . . . . . . . . . . . . . . . 4 59 6. Negative Subscriptions . . . . . . . . . . . . . . . . . . . 4 60 7. ITR Eviction of Subscription and Map-cache State . . . . . . 5 61 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 2. Requirements Notation 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [RFC2119]. 72 3. Subscription Establishement 74 When operating in a stateful pull model, a lookup miss in the data 75 plane's forwarding table results in the transmission of a 76 subscription message to the mapping system. The subscription message 77 contains a query prefix field that is set to the destination host's 78 address. As in the stateless pull model, the ITR creates an 79 incomplete map-cache entry to inhibit further signaling from the data 80 plane until the corresponding mapping information is received from 81 the mapping system. 83 When processing a subscription message, the mapping system performs a 84 longest-prefix match in the mapping database for the query prefix 85 included in the subscription message. The resulting mapping is sent 86 to the ITR in a publication message. The query prefix is also 87 included as an explicit indication that the publication message is to 88 be used by the ITR to create subscription state. 90 The ITR creates an entry in a subscription table when it receives a 91 publication message that includes a query prefix. The subscription 92 entry contains the longest-matching EID prefix returned by the 93 mapping system in the publication message. The query prefix is used 94 by the ITR to perform an exact match lookup for an incomplete map- 95 cache entry. The map-cache entry is then linked as one of the 96 sources (producers) of the subscription state. The host address of 97 the map-cache entry is ovweritten with the EID prefix of the 98 subscription entry. The locators of the subscription entry are 99 copied to the map-cache entry. The map-cache entry is transitioned 100 to complete state and reprogramed in the data plane. 102 4. Publication of Overlapping Prefixes 104 The mapping system must publish all mappings that are more specific 105 than the subscription state, unless a mechanism is conceived to more 106 efficiently support overlapping prefixes. Publication of more 107 specific mappings is necessary to ensure that the correct locators 108 are used in the following two situations: 110 a. An ITR can quite possibly have a subscription entry that covers 111 multiple destination hosts to which it is sending traffic. The 112 mapping system could later receive a registration that is more 113 specific than the current subscription state and at the same time 114 happens to be the longest matching prefix for one or multiple 115 destination hosts currently being covered by the subscription. 117 b. An ITR starts forwarding traffic to a new destination host that 118 is covered by an existing subscription entry, but for which the 119 mapping system has a mapping that is even more specific. 121 To efficiently support overlapping prefixes, the mapping system only 122 publishes registered mappings that are one level below the 123 subscription prefix. To be formally precise, the mapping system only 124 publishes registered mappings that are direct hirarchical children of 125 the subscription prefix. A more specific registered mapping is a 126 hirarchichal child of a subscription prefix if there DOES NOT exist 127 another registered mapping that is also more specific than the 128 susbcription prefix and at the same time less specific than the 129 prefix under consideration. 131 The publication messages for child prefixes have a flag set 132 indicating that a corresponding map-cache entry should be created 133 with a "signal-and-forward" action in the data plane. These Map- 134 cache entries are also marked or linked as additional sources 135 (producers) of the corresponding subscription. When a longest 136 matching forwarding lookup hits one of these map-cache entries, the 137 packet will be encapulated using one of the locators in the entry and 138 the control plane will be signaled to trigger a subscription for the 139 destination host, as described in section Section 3. The ITR is now 140 subscribed to what used to be a child prefix. The "signal-and- 141 forward" map-cache entry is deleted. The incomplete map-cache entry 142 created during the data-plane signaling event inherits the EID prefix 143 and the locators from the new susbcription state. Any registered 144 mappings that happen to be hirarchical children of the new 145 susbcription will be published by the mapping system. 147 5. Mobility and Barrier Prefixes 149 Dynamic EID prefixes are mobility prefixes configured at the ETRs to 150 enable detection and registration of individual hosts covered by the 151 prefix, as opposed to just registering the entire block as a single 152 prefix. Depending on the prefix length, dynamic EID prefixes can 153 result in a very large fan-out of individual host mappings that are 154 hirarchical children of a less specific mapping. 156 An ITR that sends a subscription where the query prefix is a mobile 157 host that is not yet registered in the mapping system can potentially 158 end up being subscribed to a less specific prefix with a huge fan-out 159 of mobile host mappings. These mobile host mappings are hirarchical 160 children of the less specific mapping and will therefore be published 161 to the ITR. 163 To avoid publishing all the mobile hosts to the ITR, the dynamic EID 164 prefix is configured in the mapping system as a barrier prefix. A 165 barrier prefix has the following properties: 167 a. If the barrier prefix is the longest matching prefix for a 168 subscription request, the ITR gets subscribed to the query 169 prefix, not the barrier prefix. If the mobile node corresponding 170 do the query prefix is not yet registered, the publication 171 message can have an empty locator set. 173 b. A barrier prefix that is a hierarchical child of a less specific 174 subscription gets published to the ITR with an explicit 175 indication that it MUST be programed in the data plane with a 176 "signal" action. This ensures that future traffic covered by the 177 dynamic EID prefix triggers a subscription, even if the ITR has a 178 map-cache entry that is less specific than the dynamic EID 179 prefix. 181 6. Negative Subscriptions 183 In the LISP stateless pull model, a Map-Request whose longest 184 matching lookup in the mapping system results in a lookup miss will 185 trigger a negative Map-Reply. The prefix included in the reply is 186 the least specific gap or hole in the mapping system that also covers 187 the prefix in the Map-Request. This minimizes the amount of map- 188 cache entries necessary to forward traffic not covered by mapping 189 database. 191 In the stateful pull model, a subscription message could similarly 192 result in a lookup miss in the mapping system. The least specific 193 gap or hole in the mapping database that covers the subscription 194 request gets self-registered by the mapping system as a negative 195 mapping. A negative mapping can contain an empty locator set. 196 Alternatively, if one or more PETRs are registering the 0/0 prefix, 197 the locator set of a negative mappings could inherit the merged set 198 of locators from the 0/0 mapping. The publication message sent to 199 the ITR in response to the subscription contains the negative 200 mapping. According to the subscription procedure described in 201 section Section 3, the ITR creates a subscription entry and a map- 202 cache entry for the negative mapping. 204 If and when a prefix gets registered that is more specific than a 205 negative mapping, said prefix will effectively be a hierarchical 206 child of the negative mapping and will therefore be published to any 207 ITR currently subscribed to the negative prefix. 209 Negative mappings get evicted from the mapping system when the set of 210 ITRs subscribed to the negative mapping becomes empty. Subscriptions 211 to prefixes that are more specific than the negative mapping do not 212 prevent the eviction of the negative mapping. What is important is 213 that there are no subscriptions on the negative mapping itself. 215 7. ITR Eviction of Subscription and Map-cache State 217 An ITR subscription entry may be sourced by one map-cache entry whose 218 prefix is equal to that of the subscription entry, and multiple map- 219 cache entries whose prefixes are more specific than that of the 220 subscription entry. Any of these map-cache entries may be evicted 221 when an unpublish message is received from the mapping system. An 222 unpublish message is an indication that the corresponding mapping is 223 no longer registered in the mapping system. 225 A subscription entry can be evicted from the ITR when the set of map- 226 cache entries sourcing the subscription becomes empty. The ITR sends 227 an unsubscribe message when a suscription entry is evicted. 229 The ITR can collectively evict a subscription entry and all 230 associated map-cache entries in a single atomic operation if none of 231 the map-cache entries have been hit by forwarding traffic after an 232 unspecified amount of time. Note that while evicting a single map- 233 cache entry for lack of use is possible, it will not prevent the 234 mapping system for publishing it again if there is a change in the 235 corresponding mapping. 237 Note that the mapping system MUST keep track of a subscription even 238 if there are no registered mappings that are covered by the 239 subscription. The Mapping system can only evict a subscription entry 240 if it receives an unsubscribe message from the ITR or if it looses 241 communication with the ITR 243 8. Normative References 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, 247 DOI 10.17487/RFC2119, March 1997, 248 . 250 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 251 Locator/ID Separation Protocol (LISP)", RFC 6830, 252 DOI 10.17487/RFC6830, January 2013, 253 . 255 Authors' Addresses 257 Jesus Arango 258 Cisco Systems 259 170 Tasman Drive 260 San Jose, CA 95134 261 USA 263 Email: jearango@cisco.com 265 Johnson Leong 266 Cisco Systems 267 170 Tasman Drive 268 San Jose, CA 95134 269 USA 271 Email: joleong@cisco.com