idnits 2.17.1 draft-ietf-grow-bmp-adj-rib-out-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 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 (June 16, 2017) is 2504 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 280 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: December 18, 2017 NTT Communications 7 P. Mi 8 Tencent 9 S. Zhuang 10 Huawei 11 June 16, 2017 13 Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP) 14 draft-ietf-grow-bmp-adj-rib-out-00 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 http://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 December 18, 2017. 41 Copyright Notice 43 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . 3 62 5. Adj-RIB-Out . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5.1. Post-Policy . . . . . . . . . . . . . . . . . . . . . . . 4 64 5.2. Pre-Policy . . . . . . . . . . . . . . . . . . . . . . . 4 65 6. BMP Messages . . . . . . . . . . . . . . . . . . . . . . . . 4 66 6.1. Route Monitoring and Route Mirroring . . . . . . . . . . 4 67 6.2. Statistics Report . . . . . . . . . . . . . . . . . . . . 4 68 6.3. Peer Down and Up Notifications . . . . . . . . . . . . . 5 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 71 8.1. BMP Peer Flags . . . . . . . . . . . . . . . . . . . . . 5 72 8.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 6 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 75 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 77 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 BGP Monitoring Protocol (BMP) defines monitoring of the received 83 (e.g. Adj-RIB-In) Routing Information Bases (RIBs) per peer. The 84 Adj-RIB-In pre-policy conveys to a BMP receiver all RIB data before 85 any policy has been applied. The Adj-RIB-In post-policy conveys to a 86 BMP receiver all RIB data after policy filters and/or modifications 87 have been applied. An example of pre-policy verses post-policy is 88 when an inbound policy applies attribute modification or filters. 89 Pre-policy would contain information prior to the inbound policy 90 changes or filters of data. Post policy would convey the changed 91 data or would not contain the filtered data. 93 Monitoring the received updates that the router received before any 94 policy has been applied is the primary level of monitoring for most 95 use-cases. Inbound policy validation and auditing is the primary 96 use-case for enabling post-policy monitoring. 98 In order for a BMP receiver to receive any BGP data, the BMP sender 99 (e.g. router) needs to have an established BGP peering session and 100 actively be receiving updates for an Adj-RIB-In. 102 Being able to only monitor the Adj-RIB-In puts a restriction on what 103 data is available to BMP receivers via BMP senders (e.g. routers). 104 This is an issue when the receiving end of the BGP peer is not 105 enabled for BMP or when it is not accessible for administrative 106 reasons. For example, a service provider advertises prefixes to a 107 customer, but the service provider cannot see what it advertises via 108 BMP. Asking the customer to enable BMP and monitoring of the Adj- 109 RIB- In is not feasible. 111 This document updates BGP Monitoring Protocol (BMP) RFC 7854 112 [RFC7854] peer header by adding a new flag to distinguish Adj-RIB-In 113 verses Adj-RIB-Out. 115 Adding Adj-RIB-Out enables the ability for a BMP sender to send to a 116 BMP receiver what it advertises to BGP peers, which can be used for 117 outbound policy validation and to monitor RIBs that were advertised. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 3. Definitions 127 o Adj-RIB-Out: As defined in [RFC4271], "The Adj-RIBs-Out contains 128 the routes for advertisement to specific peers by means of the 129 local speaker's UPDATE messages." 131 o Pre-Policy Adj-RIB-Out: The result before applying the outbound 132 policy to an Adj-RIB-Out. This normally would match what is in the 133 local RIB. 135 o Post-Policy Adj-RIB-Out: The result of applying outbound policy to 136 an Adj-RIB-Out. This MUST be what is actually sent to the peer. 138 4. Per-Peer Header 140 The per-peer header has the same structure and flags as defined in 141 section 4.2 [RFC7854] with the following O flag addition: 143 0 1 2 3 4 5 6 7 144 +-+-+-+-+-+-+-+-+ 145 |V|L|A|O| Resv | 146 +-+-+-+-+-+-+-+-+ 148 o The O flag indicates Adj-RIB-In if set to 0 and Adj-RIB-Out if set 149 to 1. 151 The existing flags are defined in section 4.2 [RFC7854] and the 152 remaining bits are reserved for future use. They SHOULD be 153 transmitted as 0 and their values MUST be ignored on receipt. 155 5. Adj-RIB-Out 157 5.1. Post-Policy 159 The primary use-case in monitoring Adj-RIB-Out is to monitor the 160 updates transmitted to the BGP peer after outbound policy has been 161 applied. These updates reflect the result after modifications and 162 filters have been applied (e.g. Adj-RIB-Out Post-Policy). The L 163 flag MUST be set to 1 in this case to indicate post-policy. 165 5.2. Pre-Policy 167 As with Adj-RIB-In policy validation, there are use-cases that pre- 168 policy Adj-RIB-Out is used to validate and audit outbound policies. 169 For example, a comparison between pre-policy and post-policy can be 170 used to validate the outbound policy. The L flag MUST be set to 0 in 171 this case to indicate pre-policy. 173 6. BMP Messages 175 Many BMP messages have a per-peer header but some are not applicable 176 to Adj-RIB-In or Adj-RIB-Out monitoring. Unless otherwise defined, 177 the O flag should be set to 0 in the per-peer header in BMP messages. 179 6.1. Route Monitoring and Route Mirroring 181 The O flag MUST be set accordingly to indicate if the route monitor 182 or route mirroring message conveys Adj-RIB-In or Adj-RIB-Out. 184 6.2. Statistics Report 186 Statistics report message has Stat Type field to indicate the 187 statistic carried in the Stat Data field. Statistics report messages 188 are not specific to Adj-RIB-In or Adj-RIB-Out and MUST have the O 189 flag set to zero. The O flag SHOULD be ignored by the BMP receiver. 191 The following new statistic types are added: 193 o Stat Type = TBD: (64-bit Gauge) Number of routes in Adj-RIBs-Out 194 Pre-Policy. 196 o Stat Type = TBD: (64-bit Gauge) Number of routes in Adj-RIBs-Out 197 Post-Policy. 199 o Stat Type = TBD: Number of routes in per-AFI/SAFI Adj-RIB-Out Pre- 200 Policy. The value is structured as: 2-byte Address Family 201 Identifier (AFI), 1-byte Subsequent Address Family Identifier 202 (SAFI), followed by a 64-bit Gauge. 204 o Stat Type = TBD: Number of routes in per-AFI/SAFI Adj-RIB-Out 205 Post-Policy. The value is structured as: 2-byte Address Family 206 Identifier (AFI), 1-byte Subsequent Address Family Identifier 207 (SAFI), followed by a 64-bit Gauge. 209 6.3. Peer Down and Up Notifications 211 PEER UP and DOWN notifications convey BGP peering session state to 212 BMP receivers. The state is independent of whether or not route 213 monitoring or route mirroring messages will be sent for Adj-RIB-In, 214 Adj-RIB-Out, or both. BMP receiver implementations SHOULD ignore the 215 O flag in PEER UP and DOWN notifications. BMP receiver 216 implementations MUST use the per-peer header O flag in route 217 monitoring and mirroring messages in order to identify if the message 218 is for Adj-RIB-In or Adj-RIB-Out. 220 7. Security Considerations 222 It is not believed that this document adds any additional security 223 considerations. 225 8. IANA Considerations 227 This document requests that IANA assign the following new parameters 228 to the BMP parameters name space [1]. 230 8.1. BMP Peer Flags 232 This document defines the following new per-peer header flags 233 (Section 4): 235 o Flag 3 as O flag: The O flag indicates Adj-RIB-In if set to 0 and 236 Adj-RIB-Out if set to 1. 238 8.2. BMP Statistics Types 240 This document defines four new statistic types for statistics 241 reporting (Section 6.2): 243 o Stat Type = TBD: (64-bit Gauge) Number of routes in Adj-RIBs-Out 244 Pre-Policy. 246 o Stat Type = TBD: (64-bit Gauge) Number of routes in Adj-RIBs-Out 247 Post-Policy. 249 o Stat Type = TBD: Number of routes in per-AFI/SAFI Adj-RIB-Out Pre- 250 Policy. The value is structured as: 2-byte Address Family 251 Identifier (AFI), 1-byte Subsequent Address Family Identifier 252 (SAFI), followed by a 64-bit Gauge. 254 o Stat Type = TBD: Number of routes in per-AFI/SAFI Adj-RIB-Out 255 Post-Policy. The value is structured as: 2-byte Address Family 256 Identifier (AFI), 1-byte Subsequent Address Family Identifier 257 (SAFI), followed by a 64-bit Gauge. 259 9. References 261 9.1. Normative References 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, 265 DOI 10.17487/RFC2119, March 1997, 266 . 268 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 269 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 270 DOI 10.17487/RFC4271, January 2006, 271 . 273 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 274 Monitoring Protocol (BMP)", RFC 7854, 275 DOI 10.17487/RFC7854, June 2016, 276 . 278 9.2. URIs 280 [1] https://www.iana.org/assignments/bmp-parameters/bmp- 281 parameters.xhtml 283 Acknowledgements 285 The authors would like to thank John Scudder for his valuable input. 287 Contributors 289 Manish Bhardwaj 290 Cisco Systems 291 3700 Cisco Way 292 San Jose, CA 95134 293 USA 295 Email: manbhard@cisco.com 297 Xianyuzheng 298 Tencent 299 Tencent Building, Kejizhongyi Avenue, 300 Hi-techPark, Nanshan District,Shenzhen 518057, P.R.China 302 Weiguo 303 Tencent 304 Tencent Building, Kejizhongyi Avenue, 305 Hi-techPark, Nanshan District,Shenzhen 518057, P.R.China 307 Shugang cheng 308 H3C 310 Authors' Addresses 312 Tim Evens 313 Cisco Systems 314 2901 Third Avenue, Suite 600 315 Seattle, WA 98121 316 USA 318 Email: tievens@cisco.com 319 Serpil Bayraktar 320 Cisco Systems 321 3700 Cisco Way 322 San Jose, CA 95134 323 USA 325 Email: serpil@cisco.com 327 Paolo Lucente 328 NTT Communications 329 Siriusdreef 70-72 330 Hoofddorp, WT 2132 331 NL 333 Email: paolo@ntt.net 335 Penghui Mi 336 Tencent 337 Tengyun Building,Tower A ,No. 397 Tianlin Road 338 Shanghai 200233 339 China 341 Email: kevinmi@tencent.com 343 Shunwan Zhuang 344 Huawei 345 Huawei Bld., No.156 Beiqing Rd. 346 Beijing 100095 347 China 349 Email: zhuangshunwan@huawei.com