idnits 2.17.1 draft-jaufeerally-nexthop-path-info-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 (December 10, 2018) is 1963 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: '64496' is mentioned on line 209, but not defined == Missing Reference: '64497' is mentioned on line 199, but not defined == Missing Reference: '64498' is mentioned on line 209, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-intarea-provisioning-domains-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Path Aware Networking Research Group R. Jaufeerally 3 Internet-Draft AS210036 4 Intended status: Experimental December 10, 2018 5 Expires: June 13, 2019 7 Providing Next External Hop Path Information to End Hosts 8 draft-jaufeerally-nexthop-path-info-00 10 Abstract 12 The aim of this document is to define an interface through which an 13 Autonomous System (AS) can disseminate information about forwarding 14 of packets to the next hop outside the AS, to devices within its 15 network. This information can be used to make path aware routing 16 decisions, either by being aware of the default route packets will 17 take when traversing the AS, or by using other mechanisms to control 18 the path packets which is out of the scope of this document. 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 RFC 2119 [1]. 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 June 13, 2019. 43 Copyright Notice 45 Copyright (c) 2018 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. Detection of Path Aware Functionality . . . . . . . . . . . . 3 62 3. The Path Service . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 7.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 The current state of the internet is such that routing decisions are 74 made by the network operator, and the end user has no a priori 75 information about network paths. It is possible to manually find 76 information about paths a posteriori using tools such as traceroute. 78 There exists unstandardized out of band mechanisms such as looking 79 glasses [3] and specialized tools like NLNOG RING [4] that allow for 80 customizable introspection of the network control and data plane. 81 These tools provide valuable information to network engineers, and 82 enthusiastic end users to ascertain information about forwarding 83 routes which packets are nominally following. 85 This document defines a standardized interface to provide network 86 path information to end hosts, routers, and other devices within a 87 network. This path awareness can be used to optimize use of network 88 resources by the end host, for example allowing programmatic 89 decisions on which links to use for a given packet. 91 The implementation strategy we define is a mechanism to bootstrap 92 devices within an AS with the information required to obtain path 93 awareness from the network control plane. In addition, we define a 94 standard format for the interchange of path information in this 95 context. 97 2. Detection of Path Aware Functionality 99 In order for an end host to make use of the path aware functionality 100 in a network, the host needs to detect that the network supports such 101 features. To make hosts aware of these features we use an extension 102 to the provisioning domain [2] architecture to advertise a service 103 which can provide network path information. 105 We define a new PvD key, "x-52759-pan" which contains information 106 about the path aware network services. Specifically, in this draft 107 we use this vehicle to distribute the service endpoint address for 108 the path resolution service. The PvD contents of this attribute are 109 defined as follows: 111 +---------+--------+------------------------------------------------+ 112 | Key | Value | Meaning | 113 | | type | | 114 +---------+--------+------------------------------------------------+ 115 | version | string | Which version of the path aware services is | 116 | | | supported. When implementing this draft the | 117 | | | string MUST be "draft-irtf-panrg-nexthop-path- | 118 | | | info-00" | 119 | url | string | The HTTPS endpoint address of the path service | 120 +---------+--------+------------------------------------------------+ 122 Table 1: PvD keys 124 { 125 "version": "draft-irtf-panrg-nexthop-path-info-00", 126 "url": "https://path-server.pan.rayhaan.net/" 127 } 129 Example contents of the "x-52759-pan" attribute in the PvD JSON 130 document. 132 Figure 1 134 The url parameter MUST be resolvable by the client using the default 135 name resolution services available in the network, and SHOULD also be 136 resolvable globally to facilitate usage by hosts using alternative 137 name resolution services. 139 3. The Path Service 141 The Path Service provides a uniform API through which path 142 information can be obtained. We define in this section the 143 functionality which this service must provide, and how it will be 144 accessed by clients. 146 +----------------------+--------------------------------------------+ 147 | URL Endpoint | Purpose | 148 +----------------------+--------------------------------------------+ 149 | /route// | To get the routes available to the | 150 | | destination address prefix (), | 151 | | whose type is the provided address family | 152 | | (). | 153 | /route/all | To get all routes reachable in the | 154 | | network. | 155 +----------------------+--------------------------------------------+ 157 Table 2: API URL Endpoints 159 Implementations of this draft MUST support IPv6 as AF parameter, and 160 MAY also support IPv4. 162 The data type for returned data in this service is determined by the 163 HTTP "accept" header which is provided by the client. 164 Implementations of this draft MUST support the "application/json" 165 content type and MAY support others which are out of scope of this 166 document. 168 When the requested content type is "application/json" the following 169 schema MUST be used to return data to the client. 171 { 172 "dest_prefix": "192.0.2.0/24", 173 "paths": [{ 174 "id": "0x1", 175 "link_name": "prov-1", 176 "AS_Path": [64496, 64497, 64498] 177 }, 178 { 179 "id": "0x2", 180 "link_name": "IX-CH", 181 "AS_Path": [64496, 64498] 182 } 183 ] 184 } 186 Figure 2 188 When all the routes are requested the format of data returned is as 189 follows. 191 { 192 "links": [ 193 { 194 "id": "0x1", 195 "link_name": "prov-1", 196 "routes": [ 197 { 198 "prefix": "192.0.2.0/24", 199 "AS_Path": [64496, 64497, 64498] 200 } 201 ] 202 }, 203 { 204 "id": "0x2", 205 "link_name": "IX-CH", 206 "routes": [ 207 { 208 "prefix": "192.0.2.0/24", 209 "AS_Path": [64496, 64498] 210 } 211 ] 212 } 213 ] 214 } 216 Additionally a diff since a certain timestamp MAY be provided by an 217 implementation of this draft. Implementations that chose to provide 218 this functionality MUST do so by accepting the "since" query 219 parameter on the "/route/all" URL with a timestamp of seconds since 220 January 1, 1970. The server will then return routes which have been 221 added and / or removed since the specified timestamp. The format is 222 the same as the full route schema, except for two additional fields, 223 as specified below. 225 The objects contained within the "links" array MAY contain a "delta" 226 key which MUST be either "add" or "del". This means the link was 227 added or removed since the requested "since" time respectively. 228 Furthermore individual route objects contained within the "routes" 229 key MUST contain a "delta" key which MUST be either "add" or "del" if 230 the route has been added or removed over that link respectively. If 231 a route has not changed it MUST NOT be included in the diff message. 233 4. Acknowledgements 235 The authors would like to thank Brian Trammell and Milan Pandurov for 236 their valuable input and feedback. 238 5. IANA Considerations 240 IANA is asked to allocate a new string in the registry entitled 241 "Additional Information PvD Keys" for use in the provisioning domain 242 additional information JSON document. 244 6. Security Considerations 246 The explicit knowledge of paths within a network by end devices is 247 not considered a security risk, since this information can be 248 obtained through other mechanisms, albeit less reliably and in a non 249 uniform manner. Moreover, should a service provider not wish to 250 reveal the existence of a link, there is no obligation to provide 251 such information in the data returned, however the authors believe 252 having more transparency in the network is better for the ecosystem 253 as a whole. 255 This internet draft does not specify any security mechanisms for 256 ensuring the authenticity of information returned from the route 257 service, but such a mechanism may be proposed at a later point in 258 time. 260 7. References 262 7.1. Normative References 264 [1] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997, 266 . 268 [2] Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W. 269 Shao, "Discovering Provisioning Domain Names and Data", 270 draft-ietf-intarea-provisioning-domains-03 (work in 271 progress), October 2018. 273 7.2. Informative References 275 [3] Hurricane Electric Internet Services, "Hurricane Electric 276 Looking Glass", 2018, . 278 [4] Netherlands Network Operator Group, "NLNOG RING", 2018, 279 . 281 Author's Address 282 Rayhaan Jaufeerally 283 AS210036 284 Swiss Post Box 1610 285 Kasernenstasse 97 286 Zuerich 1 8021 287 CH 289 Phone: +41 22 518 16 29 290 Email: ietf@rayhaan.ch 291 URI: https://rayhaan.ch/