idnits 2.17.1 draft-ietf-grow-bmp-adj-rib-out-03.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 (December 19, 2018) is 1953 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 376 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: June 22, 2019 NTT Communications 7 P. Mi 8 Tencent 9 S. Zhuang 10 Huawei 11 December 19, 2018 13 Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP) 14 draft-ietf-grow-bmp-adj-rib-out-03 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 June 22, 2019. 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 . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . 9 81 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 9 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. The 158 following fields in Per-Peer Header are redefined: 160 o Peer Address: The remote IP address associated with the TCP 161 session over which the encapsulated PDU was sent. 163 o Peer AS: The Autonomous System number of the peer from which the 164 encapsulated PDU was sent. 166 o Peer BGP ID: The BGP Identifier of the peer from which the 167 encapsulated PDU was sent. 169 5. Adj-RIB-Out 171 5.1. Post-Policy 173 The primary use-case in monitoring Adj-RIB-Out is to monitor the 174 updates transmitted to the BGP peer after outbound policy has been 175 applied. These updates reflect the result after modifications and 176 filters have been applied (e.g. Adj-RIB-Out Post-Policy). Some 177 attributes are set when the BGP message is transmitted, such as next- 178 hop. Adj-RIB-Out Post-Policy MUST convey what is actually 179 transmitted to the peer, next-hop and any attribute set during 180 transmission should also be set and transmitted to the BMP receiver. 182 The L flag MUST be set to 1 to indicate post-policy. 184 5.2. Pre-Policy 186 As with Adj-RIB-In policy validation, there are use-cases that pre- 187 policy Adj-RIB-Out is used to validate and audit outbound policies. 188 For example, a comparison between pre-policy and post-policy can be 189 used to validate the outbound policy. 191 Depending on BGP peering session type (IBGP, IBGP route reflector 192 client, EBGP, BGP confederations, Route Server Client) the candidate 193 routes that make up the Pre-Policy Adj-RIB-Out do not contain all 194 local-rib routes. Pre-Policy Adj-RIB-Out conveys only routes that 195 are available based on the peering type. Post-Policy represents the 196 filtered/changed routes from the available routes. 198 Some attributes are set only during transmission of the BGP message, 199 e.g. Post-Policy. It is common that next-hop may be null, loopback, 200 or similar during this phase. All mandatory attributes, such as 201 next-hop, MUST be either ZERO or have an empty length if they are 202 unknown at the Pre-Policy phase. The BMP receiver will treat zero or 203 empty mandatory attributes as self originated. 205 The L flag MUST be set to 0 to indicate pre-policy. 207 6. BMP Messages 209 Many BMP messages have a per-peer header but some are not applicable 210 to Adj-RIB-In or Adj-RIB-Out monitoring. Unless otherwise defined, 211 the O flag should be set to 0 in the per-peer header in BMP messages. 213 6.1. Route Monitoring and Route Mirroring 215 The O flag MUST be set accordingly to indicate if the route monitor 216 or route mirroring message conveys Adj-RIB-In or Adj-RIB-Out. 218 6.2. Statistics Report 220 Statistics report message has Stat Type field to indicate the 221 statistic carried in the Stat Data field. Statistics report messages 222 are not specific to Adj-RIB-In or Adj-RIB-Out and MUST have the O 223 flag set to zero. The O flag SHOULD be ignored by the BMP receiver. 225 The following new statistic types are added: 227 o Stat Type = 14: (64-bit Gauge) Number of routes in Adj-RIBs-Out 228 Pre-Policy. 230 o Stat Type = 15: (64-bit Gauge) Number of routes in Adj-RIBs-Out 231 Post-Policy. 233 o Stat Type = 16: Number of routes in per-AFI/SAFI Adj-RIB-Out Pre- 234 Policy. The value is structured as: 2-byte Address Family 235 Identifier (AFI), 1-byte Subsequent Address Family Identifier 236 (SAFI), followed by a 64-bit Gauge. 238 o Stat Type = 17: Number of routes in per-AFI/SAFI Adj-RIB-Out Post- 239 Policy. The value is structured as: 2-byte Address Family 240 Identifier (AFI), 1-byte Subsequent Address Family Identifier 241 (SAFI), followed by a 64-bit Gauge. 243 6.3. Peer Down and Up Notifications 245 PEER UP and DOWN notifications convey BGP peering session state to 246 BMP receivers. The state is independent of whether or not route 247 monitoring or route mirroring messages will be sent for Adj-RIB-In, 248 Adj-RIB-Out, or both. BMP receiver implementations SHOULD ignore the 249 O flag in PEER UP and DOWN notifications. BMP receiver 250 implementations MUST use the per-peer header O flag in route 251 monitoring and mirroring messages in order to identify if the message 252 is for Adj-RIB-In or Adj-RIB-Out. 254 6.3.1. Peer Up Information 256 The following peer UP information TLV types are added: 258 o Type = 4: Admin Label. The Information field contains a free-form 259 UTF-8 string whose length is given by the Information Length 260 field. The value is administratively assigned. There is no 261 requirement to terminate the string with null or any other 262 character. 264 Multiple admin labels can be included in the Peer UP. When 265 multiple admin labels are included the BMP receiver MUST preserve 266 the order. 268 The TLV is optional. 270 7. Other Considerations 272 7.1. Peer and Update Groups 274 Peer and update groups are used to group updates shared by many 275 peers. This is a level of efficiency in the implementation, not a 276 true representation of what is conveyed to a peer in either Pre- 277 Policy or Post-Policy. 279 One of the use-cases to monitor Adj-RIB-Out Post-Policy is to 280 validate and continually ensure the egress updates match what is 281 expected. For example, wholesale peers should never have routes with 282 community X:Y sent to them. In this use-case, there maybe hundreds 283 of wholesale peers but a single peer could have represented the 284 group. 286 A single peer could be used to represent a group. From a BMP 287 perspective, this should be simple to include a group name in the 288 PEER UP, but it is more complex than that. BGP implementations have 289 evolved to provide comprehensive and structured policy grouping, such 290 as session, afi/safi, and template based group policy inheritances. 292 This level of structure and inheritance of polices does not provide a 293 simple peer group name or ID, such as wholesale peer. 295 Instead of requiring a group name to be used, a new administrative 296 label informational TLV (Section 6.3.1) is added to the Peer UP 297 message. These labels have administrative scope relevance. For 298 example, labels "type=wholesale" and "region=west" could be used to 299 monitor expected policies. 301 Configuration and assignment of labels to peers is BGP implementation 302 specific. 304 8. Security Considerations 306 It is not believed that this document adds any additional security 307 considerations. 309 9. IANA Considerations 311 This document requests that IANA assign the following new parameters 312 to the BMP parameters name space [1]. 314 9.1. BMP Peer Flags 316 This document defines the following new per-peer header flags 317 (Section 4): 319 o Flag 3 as O flag: The O flag indicates Adj-RIB-In if set to 0 and 320 Adj-RIB-Out if set to 1. 322 9.2. BMP Statistics Types 324 This document defines four new statistic types for statistics 325 reporting (Section 6.2): 327 o Stat Type = 14: (64-bit Gauge) Number of routes in Adj-RIBs-Out 328 Pre-Policy. 330 o Stat Type = 15: (64-bit Gauge) Number of routes in Adj-RIBs-Out 331 Post-Policy. 333 o Stat Type = 16: Number of routes in per-AFI/SAFI Adj-RIB-Out Pre- 334 Policy. The value is structured as: 2-byte Address Family 335 Identifier (AFI), 1-byte Subsequent Address Family Identifier 336 (SAFI), followed by a 64-bit Gauge. 338 o Stat Type = 17: Number of routes in per-AFI/SAFI Adj-RIB-Out Post- 339 Policy. The value is structured as: 2-byte Address Family 340 Identifier (AFI), 1-byte Subsequent Address Family Identifier 341 (SAFI), followed by a 64-bit Gauge. 343 9.3. Peer UP Information TLV 345 This document defines the following new BMP PEER UP informational 346 message TLV types (Section 6.3.1): 348 o Type = 4: Admin Label. The Information field contains a free-form 349 UTF-8 string whose length is given by the Information Length 350 field. The value is administratively given by the Information 351 Length field. The value is administratively assigned. There is 352 no requirement to terminate the string with null or any other 353 character. 355 10. References 357 10.1. Normative References 359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 360 Requirement Levels", BCP 14, RFC 2119, 361 DOI 10.17487/RFC2119, March 1997, 362 . 364 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 365 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 366 DOI 10.17487/RFC4271, January 2006, 367 . 369 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 370 Monitoring Protocol (BMP)", RFC 7854, 371 DOI 10.17487/RFC7854, June 2016, 372 . 374 10.2. URIs 376 [1] https://www.iana.org/assignments/bmp-parameters/bmp- 377 parameters.xhtml 379 Acknowledgements 381 The authors would like to thank John Scudder for his valuable input. 383 Contributors 385 Manish Bhardwaj 386 Cisco Systems 387 3700 Cisco Way 388 San Jose, CA 95134 389 USA 391 Email: manbhard@cisco.com 393 Xianyuzheng 394 Tencent 395 Tencent Building, Kejizhongyi Avenue, 396 Hi-techPark, Nanshan District,Shenzhen 518057, P.R.China 398 Weiguo 399 Tencent 400 Tencent Building, Kejizhongyi Avenue, 401 Hi-techPark, Nanshan District,Shenzhen 518057, P.R.China 403 Shugang cheng 404 H3C 406 Authors' Addresses 408 Tim Evens 409 Cisco Systems 410 2901 Third Avenue, Suite 600 411 Seattle, WA 98121 412 USA 414 Email: tievens@cisco.com 415 Serpil Bayraktar 416 Cisco Systems 417 3700 Cisco Way 418 San Jose, CA 95134 419 USA 421 Email: serpil@cisco.com 423 Paolo Lucente 424 NTT Communications 425 Siriusdreef 70-72 426 Hoofddorp, WT 2132 427 NL 429 Email: paolo@ntt.net 431 Penghui Mi 432 Tencent 433 Tengyun Building,Tower A ,No. 397 Tianlin Road 434 Shanghai 200233 435 China 437 Email: kevinmi@tencent.com 439 Shunwan Zhuang 440 Huawei 441 Huawei Bld., No.156 Beiqing Rd. 442 Beijing 100095 443 China 445 Email: zhuangshunwan@huawei.com