idnits 2.17.1 draft-ietf-grow-bmp-adj-rib-out-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 draft header indicates that this document updates RFC7854, but the abstract doesn't seem to directly say this. It does mention RFC7854 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2018) is 2237 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) -- Looks like a reference, but probably isn't: '1' on line 366 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Global Routing Operations T. Evens 3 Internet-Draft S. Bayraktar 4 Updates: 7854 (if approved) Cisco Systems 5 Intended status: Standards Track P. Lucente 6 Expires: September 3, 2018 NTT Communications 7 P. Mi 8 Tencent 9 S. Zhuang 10 Huawei 11 March 2, 2018 13 Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP) 14 draft-ietf-grow-bmp-adj-rib-out-01 16 Abstract 18 The BGP Monitoring Protocol (BMP) defines access to only the Adj-RIB- 19 In Routing Information Bases (RIBs). This document updates the BGP 20 Monitoring Protocol (BMP) RFC 7854 by adding access to the Adj-RIB- 21 Out RIBs. It adds a new flag to the peer header to distinguish Adj- 22 RIB-In and Adj-RIB-Out. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 3, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Per-Peer Header . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Adj-RIB-Out . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5.1. Post-Policy . . . . . . . . . . . . . . . . . . . . . . . 4 64 5.2. Pre-Policy . . . . . . . . . . . . . . . . . . . . . . . 4 65 6. BMP Messages . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6.1. Route Monitoring and Route Mirroring . . . . . . . . . . 5 67 6.2. Statistics Report . . . . . . . . . . . . . . . . . . . . 5 68 6.3. Peer Down and Up Notifications . . . . . . . . . . . . . 5 69 6.3.1. Peer Up Information . . . . . . . . . . . . . . . . . 6 70 7. Other Considerations . . . . . . . . . . . . . . . . . . . . 6 71 7.1. Peer and Update Groups . . . . . . . . . . . . . . . . . 6 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 9.1. BMP Peer Flags . . . . . . . . . . . . . . . . . . . . . 7 75 9.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 7 76 9.3. Peer UP Information TLV . . . . . . . . . . . . . . . . . 8 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 81 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 BGP Monitoring Protocol (BMP) defines monitoring of the received 87 (e.g. Adj-RIB-In) Routing Information Bases (RIBs) per peer. The 88 Adj-RIB-In pre-policy conveys to a BMP receiver all RIB data before 89 any policy has been applied. The Adj-RIB-In post-policy conveys to a 90 BMP receiver all RIB data after policy filters and/or modifications 91 have been applied. An example of pre-policy verses post-policy is 92 when an inbound policy applies attribute modification or filters. 93 Pre-policy would contain information prior to the inbound policy 94 changes or filters of data. Post policy would convey the changed 95 data or would not contain the filtered data. 97 Monitoring the received updates that the router received before any 98 policy has been applied is the primary level of monitoring for most 99 use-cases. Inbound policy validation and auditing is the primary 100 use-case for enabling post-policy monitoring. 102 In order for a BMP receiver to receive any BGP data, the BMP sender 103 (e.g. router) needs to have an established BGP peering session and 104 actively be receiving updates for an Adj-RIB-In. 106 Being able to only monitor the Adj-RIB-In puts a restriction on what 107 data is available to BMP receivers via BMP senders (e.g. routers). 108 This is an issue when the receiving end of the BGP peer is not 109 enabled for BMP or when it is not accessible for administrative 110 reasons. For example, a service provider advertises prefixes to a 111 customer, but the service provider cannot see what it advertises via 112 BMP. Asking the customer to enable BMP and monitoring of the Adj- 113 RIB- In is not feasible. 115 This document updates BGP Monitoring Protocol (BMP) RFC 7854 116 [RFC7854] peer header by adding a new flag to distinguish Adj-RIB-In 117 verses Adj-RIB-Out. 119 Adding Adj-RIB-Out enables the ability for a BMP sender to send to a 120 BMP receiver what it advertises to BGP peers, which can be used for 121 outbound policy validation and to monitor RIBs that were advertised. 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 3. Definitions 131 o Adj-RIB-Out: As defined in [RFC4271], "The Adj-RIBs-Out contains 132 the routes for advertisement to specific peers by means of the 133 local speaker's UPDATE messages." 135 o Pre-Policy Adj-RIB-Out: The result before applying the outbound 136 policy to an Adj-RIB-Out. This normally would match what is in the 137 local RIB. 139 o Post-Policy Adj-RIB-Out: The result of applying outbound policy to 140 an Adj-RIB-Out. This MUST be what is actually sent to the peer. 142 4. Per-Peer Header 144 The per-peer header has the same structure and flags as defined in 145 section 4.2 [RFC7854] with the following O flag addition: 147 0 1 2 3 4 5 6 7 148 +-+-+-+-+-+-+-+-+ 149 |V|L|A|O| Resv | 150 +-+-+-+-+-+-+-+-+ 152 o The O flag indicates Adj-RIB-In if set to 0 and Adj-RIB-Out if set 153 to 1. 155 The existing flags are defined in section 4.2 [RFC7854] and the 156 remaining bits are reserved for future use. They SHOULD be 157 transmitted as 0 and their values MUST be ignored on receipt. 159 5. Adj-RIB-Out 161 5.1. Post-Policy 163 The primary use-case in monitoring Adj-RIB-Out is to monitor the 164 updates transmitted to the BGP peer after outbound policy has been 165 applied. These updates reflect the result after modifications and 166 filters have been applied (e.g. Adj-RIB-Out Post-Policy). Some 167 attributes are set when the BGP message is transmitted, such as next- 168 hop. Adj-RIB-Out Post-Policy MUST convey what is actually 169 transmitted to the peer, next-hop and any attribute set during 170 transmission should also be set and transmitted to the BMP receiver. 172 The L flag MUST be set to 1 to indicate post-policy. 174 5.2. Pre-Policy 176 As with Adj-RIB-In policy validation, there are use-cases that pre- 177 policy Adj-RIB-Out is used to validate and audit outbound policies. 178 For example, a comparison between pre-policy and post-policy can be 179 used to validate the outbound policy. 181 Depending on BGP peering session type (IBGP, IBGP route reflector 182 client, EBGP) the candidate routes that make up the Pre-Policy Adj- 183 RIB-Out do not contain all local-rib routes. Pre-Policy Adj-RIB-Out 184 conveys only routes that are available based on the peering type. 185 Post-Policy represents the filtered/changed routes from the available 186 routes. 188 Some attributes are set only during transmission of the BGP message, 189 e.g. Post-Policy. It is common that next-hop may be null, loopback, 190 or similar during this phase. All mandatory attributes, such as 191 next-hop, MUST be either ZERO or have an empty length if they are 192 unknown at the Pre-Policy phase. The BMP receiver will treat zero or 193 empty mandatory attributes as self originated. 195 The L flag MUST be set to 0 to indicate pre-policy. 197 6. BMP Messages 199 Many BMP messages have a per-peer header but some are not applicable 200 to Adj-RIB-In or Adj-RIB-Out monitoring. Unless otherwise defined, 201 the O flag should be set to 0 in the per-peer header in BMP messages. 203 6.1. Route Monitoring and Route Mirroring 205 The O flag MUST be set accordingly to indicate if the route monitor 206 or route mirroring message conveys Adj-RIB-In or Adj-RIB-Out. 208 6.2. Statistics Report 210 Statistics report message has Stat Type field to indicate the 211 statistic carried in the Stat Data field. Statistics report messages 212 are not specific to Adj-RIB-In or Adj-RIB-Out and MUST have the O 213 flag set to zero. The O flag SHOULD be ignored by the BMP receiver. 215 The following new statistic types are added: 217 o Stat Type = TBD: (64-bit Gauge) Number of routes in Adj-RIBs-Out 218 Pre-Policy. 220 o Stat Type = TBD: (64-bit Gauge) Number of routes in Adj-RIBs-Out 221 Post-Policy. 223 o Stat Type = TBD: Number of routes in per-AFI/SAFI Adj-RIB-Out Pre- 224 Policy. The value is structured as: 2-byte Address Family 225 Identifier (AFI), 1-byte Subsequent Address Family Identifier 226 (SAFI), followed by a 64-bit Gauge. 228 o Stat Type = TBD: Number of routes in per-AFI/SAFI Adj-RIB-Out 229 Post-Policy. The value is structured as: 2-byte Address Family 230 Identifier (AFI), 1-byte Subsequent Address Family Identifier 231 (SAFI), followed by a 64-bit Gauge. 233 6.3. Peer Down and Up Notifications 235 PEER UP and DOWN notifications convey BGP peering session state to 236 BMP receivers. The state is independent of whether or not route 237 monitoring or route mirroring messages will be sent for Adj-RIB-In, 238 Adj-RIB-Out, or both. BMP receiver implementations SHOULD ignore the 239 O flag in PEER UP and DOWN notifications. BMP receiver 240 implementations MUST use the per-peer header O flag in route 241 monitoring and mirroring messages in order to identify if the message 242 is for Adj-RIB-In or Adj-RIB-Out. 244 6.3.1. Peer Up Information 246 The following peer UP information TLV types are added: 248 o Type = TBD: Admin Label. The Information field contains a free- 249 form UTF-8 string whose length is given by the Information Length 250 field. The value is administratively assigned. There is no 251 requirement to terminate the string with null or any other 252 character. 254 Multiple admin labels can be included in the Peer UP. When 255 multiple admin labels are included the BMP receiver MUST preserve 256 the order. 258 The TLV is optional. 260 7. Other Considerations 262 7.1. Peer and Update Groups 264 Peer and update groups are used to group updates shared by many 265 peers. This is a level of efficiency in the implementation, not a 266 true representation of what is conveyed to a peer in either Pre- 267 Policy or Post-Policy. 269 One of the use-cases to monitor Adj-RIB-Out Post-Policy is to 270 validate and continually ensure the egress updates match what is 271 expected. For example, wholesale peers should never have routes with 272 community X:Y sent to them. In this use-case, there maybe hundreds 273 of wholesale peers but a single peer could have represented the 274 group. 276 A single peer could be used to represent a group. From a BMP 277 perspective, this should be simple to include a group name in the 278 PEER UP, but it is more complex than that. BGP implementations have 279 evolved to provide comprehensive and structured policy grouping, such 280 as session, afi/safi, and template based group policy inheritances. 282 This level of structure and inheritance of polices does not provide a 283 simple peer group name or ID, such as wholesale peer. 285 Instead of requiring a group name to be used, a new administrative 286 label informational TLV (Section 6.3.1) is added to the Peer UP 287 message. These labels have administrative scope relevance. For 288 example, labels "type=wholesale" and "region=west" could be used to 289 monitor expected policies. 291 Configuration and assignment of labels to peers is BGP implementation 292 specific. 294 8. Security Considerations 296 It is not believed that this document adds any additional security 297 considerations. 299 9. IANA Considerations 301 This document requests that IANA assign the following new parameters 302 to the BMP parameters name space [1]. 304 9.1. BMP Peer Flags 306 This document defines the following new per-peer header flags 307 (Section 4): 309 o Flag 3 as O flag: The O flag indicates Adj-RIB-In if set to 0 and 310 Adj-RIB-Out if set to 1. 312 9.2. BMP Statistics Types 314 This document defines four new statistic types for statistics 315 reporting (Section 6.2): 317 o Stat Type = TBD: (64-bit Gauge) Number of routes in Adj-RIBs-Out 318 Pre-Policy. 320 o Stat Type = TBD: (64-bit Gauge) Number of routes in Adj-RIBs-Out 321 Post-Policy. 323 o Stat Type = TBD: Number of routes in per-AFI/SAFI Adj-RIB-Out Pre- 324 Policy. The value is structured as: 2-byte Address Family 325 Identifier (AFI), 1-byte Subsequent Address Family Identifier 326 (SAFI), followed by a 64-bit Gauge. 328 o Stat Type = TBD: Number of routes in per-AFI/SAFI Adj-RIB-Out 329 Post-Policy. The value is structured as: 2-byte Address Family 330 Identifier (AFI), 1-byte Subsequent Address Family Identifier 331 (SAFI), followed by a 64-bit Gauge. 333 9.3. Peer UP Information TLV 335 This document defines the following new BMP PEER UP informational 336 message TLV types (Section 6.3.1): 338 o Type = TBD: Admin Label. The Information field contains a free- 339 form UTF-8 string whose length is given by the Information Length 340 field. The value is administratively given by the Information 341 Length field. The value is administratively assigned. There is 342 no requirement to terminate the string with null or any other 343 character. 345 10. References 347 10.1. Normative References 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, 351 DOI 10.17487/RFC2119, March 1997, 352 . 354 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 355 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 356 DOI 10.17487/RFC4271, January 2006, 357 . 359 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 360 Monitoring Protocol (BMP)", RFC 7854, 361 DOI 10.17487/RFC7854, June 2016, 362 . 364 10.2. URIs 366 [1] https://www.iana.org/assignments/bmp-parameters/bmp- 367 parameters.xhtml 369 Acknowledgements 371 The authors would like to thank John Scudder for his valuable input. 373 Contributors 375 Manish Bhardwaj 376 Cisco Systems 377 3700 Cisco Way 378 San Jose, CA 95134 379 USA 380 Email: manbhard@cisco.com 382 Xianyuzheng 383 Tencent 384 Tencent Building, Kejizhongyi Avenue, 385 Hi-techPark, Nanshan District,Shenzhen 518057, P.R.China 387 Weiguo 388 Tencent 389 Tencent Building, Kejizhongyi Avenue, 390 Hi-techPark, Nanshan District,Shenzhen 518057, P.R.China 392 Shugang cheng 393 H3C 395 Authors' Addresses 397 Tim Evens 398 Cisco Systems 399 2901 Third Avenue, Suite 600 400 Seattle, WA 98121 401 USA 403 Email: tievens@cisco.com 405 Serpil Bayraktar 406 Cisco Systems 407 3700 Cisco Way 408 San Jose, CA 95134 409 USA 411 Email: serpil@cisco.com 413 Paolo Lucente 414 NTT Communications 415 Siriusdreef 70-72 416 Hoofddorp, WT 2132 417 NL 419 Email: paolo@ntt.net 420 Penghui Mi 421 Tencent 422 Tengyun Building,Tower A ,No. 397 Tianlin Road 423 Shanghai 200233 424 China 426 Email: kevinmi@tencent.com 428 Shunwan Zhuang 429 Huawei 430 Huawei Bld., No.156 Beiqing Rd. 431 Beijing 100095 432 China 434 Email: zhuangshunwan@huawei.com