idnits 2.17.1 draft-hares-i2rs-bgp-compare-yang-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 200 has weird spacing: '...st-name str...' == Line 316 has weird spacing: '...icy-out poli...' == Line 421 has weird spacing: '...-status enume...' == Line 535 has weird spacing: '...-length uint8...' == Line 536 has weird spacing: '... +--rw route...' == (45 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 27, 2014) is 3462 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) == Missing Reference: 'AS-number' is mentioned on line 301, but not defined == Unused Reference: 'I-D.bogdanovic-netmod-acl-model' is defined on line 1290, but no explicit reference was found in the text == Unused Reference: 'I-D.hares-i2rs-info-model-service-topo' is defined on line 1301, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-architecture' is defined on line 1311, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 1317, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1332, but no explicit reference was found in the text == Unused Reference: 'RFC3060' is defined on line 1335, but no explicit reference was found in the text == Unused Reference: 'RFC3460' is defined on line 1339, but no explicit reference was found in the text == Unused Reference: 'RFC3644' is defined on line 1342, but no explicit reference was found in the text == Unused Reference: 'RFC5511' is defined on line 1346, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-hares-i2rs-info-model-service-topo-01 == Outdated reference: A later version (-02) exists of draft-hares-i2rs-usecase-reqs-summary-00 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-05 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-03 Summary: 1 error (**), 0 flaws (~~), 22 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS working group S. Hares 3 Internet-Draft Huawei 4 Intended status: Standards Track October 27, 2014 5 Expires: April 30, 2015 7 Comparison of I2RS and Config BGP Yang Modules 8 draft-hares-i2rs-bgp-compare-yang-01 10 Abstract 12 This document contains a comparison of two BGP yang models: draft- 13 zhdankin-netmod-bgp-cfg-01 and draft-wang-i2rs-bgp-dm. The yang 14 model in draft-zhdankin-netmod-bgp-cfg-01 is a model focused on 15 configuration. The yang model in draft-wang-i2rs-bgp-dm-00 is 16 focused on the status and ephemeral state changes needed for the I2RS 17 interface. The conclusion of comparison is that there little overlap 18 except the definitions of common bgp structures. The draft-wang- 19 i2rs-bgp-dm-00 is necessary to fulfil a majority of the requirement 20 drawn from the BGP use cases in the I2RS use cases (draft-i2rs-hares- 21 usecase-reqs-summary). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 30, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 59 3. BGP Yang Draft Comparison . . . . . . . . . . . . . . . . . . 4 60 4. Differences between the drafts . . . . . . . . . . . . . . . 4 61 4.1. Overlap of configuration draft-zhdankin-netmod-bgp-01 . . 7 62 4.2. Unique configuration for draft-zhdankin-netmod-bgp-01 . . 7 63 4.3. Unique configuration for draft-wang-bgp-dm-00 . . . . . . 8 64 5. Comparison of State needed versus BGP requirements . . . . . 9 65 5.1. BGP-REQ 01 . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.2. BGP-REQ 02 . . . . . . . . . . . . . . . . . . . . . . . 10 67 5.3. BGP-REQ 03 . . . . . . . . . . . . . . . . . . . . . . . 13 68 5.4. BGP-REQ 04 . . . . . . . . . . . . . . . . . . . . . . . 14 69 5.5. BGP-REQ 05 . . . . . . . . . . . . . . . . . . . . . . . 15 70 5.6. BGP-REQ 06 . . . . . . . . . . . . . . . . . . . . . . . 16 71 5.7. BGP-REQ 07 . . . . . . . . . . . . . . . . . . . . . . . 17 72 5.8. BGP-REQ 08 . . . . . . . . . . . . . . . . . . . . . . . 18 73 5.9. BGP-REQ 09 . . . . . . . . . . . . . . . . . . . . . . . 19 74 5.10. BGP-REQ 10 . . . . . . . . . . . . . . . . . . . . . . . 20 75 5.11. BGP-REQ 11 . . . . . . . . . . . . . . . . . . . . . . . 22 76 5.12. BGP-REQ 12 . . . . . . . . . . . . . . . . . . . . . . . 22 77 5.13. BGP-REQ 13 . . . . . . . . . . . . . . . . . . . . . . . 25 78 5.14. BGP-REQ 14 . . . . . . . . . . . . . . . . . . . . . . . 25 79 5.15. BGP-REQ 15 . . . . . . . . . . . . . . . . . . . . . . . 27 80 5.16. BGP-REQ 16 . . . . . . . . . . . . . . . . . . . . . . . 27 81 5.17. BGP-REQ 17 . . . . . . . . . . . . . . . . . . . . . . . 28 82 5.18. BGP-REQ 18 . . . . . . . . . . . . . . . . . . . . . . . 28 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 85 8. Informative References . . . . . . . . . . . . . . . . . . . 29 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 88 1. Introduction 90 The Interface to the Routing System (I2RS) provides read and write 91 access to the information and state within the routing process within 92 routing elements. The I2RS client interacts with one or more I2RS 93 agents to collect information from network routing systems. The 94 processing of collecting information at the I2RS agent may require 95 the I2RS Agent to filter certain information, group pieces of 96 information, or perform actions on the I2rs collected information 97 based on specific I2rs policies. 99 This draft is a comparison of the following two BGP yang models: 100 [I-D.zhdankin-netmod-bgp-cfg], and [I-D.wang-i2rs-bgp-dm]. The 101 comparison provides an overview of the differences, overlaps, and 102 unique features of each yang model. The analysis also evaluates 103 whether both models or a single model is necessary to satisfy the 104 requirements for the BGP use cases found in the 105 [I-D.hares-i2rs-usecase-reqs-summary]. 107 This draft concludes each of these two drafts focuses on the purpose 108 each draft was created for (configuration, I2rs status and ephemeral 109 state). The drafts have little overlap outside common definitions 110 for some of the BGP functions. Both drafts reference bgp policy 111 outside the basic structures (Prefix-lists, and policy-groups). Both 112 drafts have concepts of AFI level and BGP neighbor level features. 113 The status and ephemeral state found in [I-D.wang-i2rs-bgp-dm] is 114 necessary to fulfil the BGP use cases found in the 115 [I-D.hares-i2rs-usecase-reqs-summary]. Configuration knobs in 116 [I-D.zhdankin-netmod-bgp-cfg] were helpful to support these bgp use 117 cases, but the lack of state would not allow support of these 118 features. The recommendation is that the two drafts harmonize the 119 group structures and continue as two separate drafts for their 120 original purpose (config and I2RS). 122 One BGP requirement (BGP-REQ18) requires a re-computation of the 123 local BGP tables after policies have been modified by the ephemeral 124 interface. The exact methodology of this re-computation could be 125 part of ephemeral soft re-configuration. However, the I2RS WG has 126 not determine how ephemeral state acts. Neither draft has created 127 mechanism to do the ephemeral state re-configuration which is wise 128 since both the I2RS WG and netmod WG should develop a joint ephemeral 129 re-configuration process. 131 The rest of this draft is the details so those who desire "sounds 132 bytes" level reading may stop reading now. 134 2. Definitions and Acronyms 136 BGP - Border Gateway Protocol version 4 138 CLI: Command Line Interface 140 IGP: Interior Gateway Protocol 142 I2RS: Interface to (2) Routing system. 144 Information Model: An abstract model of a conceptual domain, 145 independent of a specific implementations or data representation 147 INSTANCE: Routing Code often has the ability to spin up multiple 148 copies of itself into virtual machines. Each Routing code 149 instance or each protocol instance is denoted as Foo_INSTANCE in 150 the text below. 152 NETCONF: The Network Configuration Protocol 154 3. BGP Yang Draft Comparison 156 The authors of [I-D.zhdankin-netmod-bgp-cfg] focused on the 157 configuration aspect of BGP (98%+ configuration, 2% status). The 158 [I-D.wang-i2rs-bgp-dm] is focused on the I2RS need for status with a 159 small amount of specific I2RS configuration for I2RS needs (95% 160 status, 2% config). The two drafts can be combined together, but 161 guidance is needed from the netmod group as the I2RS state is read- 162 write ephemeral. 164 Why is draft-wang-bgp-dm-00 mostly focused on routes, statistics, and 165 state? 167 The use cases specified in [I-D.hares-i2rs-usecase-reqs-summary] 168 demonstrate a need for the status found in [I-D.wang-i2rs-bgp-dm] 169 which includes: bgp-local-rib, bgp-rib-in, bgp-rib-out and all kinds 170 of statistics and state, such as protocol-status , bgp-rt-state-info, 171 peer-state-info, max-prefix-rcv-limit, etc. The status is both a the 172 AFI state and the BGP peer state (within the AFI). 174 Two versions of [I-D.zhdankin-netmod-bgp-cfg] have been released - a 175 -00.txt and a -01.txt he second version (-01 version) only updated 176 references to netmod and states on the yang modules. This draft will 177 use the -01 version of [I-D.zhdankin-netmod-bgp-cfg], 179 The [I-D.wang-i2rs-bgp-dm] was released mistakenly as 180 [I-D.hares-i2rs-bgp-dm]. A few corrections to the status fields were 181 included in the [I-D.wang-i2rs-bgp-dm]. This draft uses 182 [I-D.wang-i2rs-bgp-dm] for the comparison. 184 4. Differences between the drafts 186 The [I-D.zhdankin-netmod-bgp-cfg] is composed by two parts: BGP 187 Router Configuration and Prefix Lists. BGP Router Configuration 188 contains including 3 parts: af-configuration , bgp-neighbors, and 189 rpki-config (as shown in figure 1). 191 module: bgp 192 +--rw bgp-router 193 | +--rw rpki-config 194 | +--rw af-configuration 195 | +--rw bgp-neighbors (98% config, 2% state) 196 +--rw Prefix Lists 198 +--rw prefix-lists 199 +--rw prefix-list [prefix-list-name] 200 +--rw prefix-list-name string 201 +--rw prefixes 202 +--rw prefix [seq-nr] 203 +--rw seq-nr uint16 204 +--rw prefix-filter 205 +--rw (ip-address-group)? 206 | ..... 207 +--rw action actions-enum 208 +--rw statistics 209 ..... 211 Figure 1: draft-zhdankin-netmod-bgp-cfg structure 213 The [I-D.wang-i2rs-bgp-dm] is written with a status structure focus 214 where manipulation of every concrete route through controlling policy 215 and BGP attributes in different BGP address families. This does not 216 contain the rpki-config. These drafts have ~5% overlap in status/ 217 configuration. 219 module: bgp 220 +--rw bgp-protocols 221 | +--rw af-status 222 | | +--rw bgp-local-rib 223 | | +--rw bgp-neighbors (2% config, 98% state) 224 | | | +--rw policy-in 225 | | | +--rw policy-out 226 | | | +--rw peer-state 227 | | | +--rw bgp-rib-in 228 | | | +--rw-bgp-rib-out 230 module: ietf-pcim 231 +--rw Policy-sets 232 +--rw Policy-groups 233 +--rw Policy-Rules 235 Figure 2 draft-i2rs-wang-bgp-dm-00 237 o The focus is status-based based on AFI, but includes local-rib and 238 BGP neighbor's policy (in and out), peer state, rib-in, and rib- 239 out. 241 o prefix list policy being covered inline 242 ([I-D.zhdankin-netmod-bgp-cfg]) versus in the draft-hares-bnp- 243 im-01 which uses the policy descriptions created by RFC3060, 244 RFC3460, and other policy work. This methodology is being 245 utilized by the OpenDaylight Group policy as well. 247 o Redistribution being done inline ([I-D.zhdankin-netmod-bgp-cfg]) 248 as a configuration. The draft-i2rs-wang-bgp-dm-00 did not 249 configure af-configuration. 251 o [I-D.zhdankin-netmod-bgp-cfg] claims to list the aspath path was 252 well as the prefix configuration, but this section is missing in 253 the draft. The example is the expression of as-path in draft- 254 i2rs-wang-bgp-dm-00 is a actually string value of as-path which is 255 one of attributes in BGP route rather not a Boolean value as used 256 in [I-D.zhdankin-netmod-bgp-cfg]. 258 o The order of specifying the protocol elements is different in some 259 cases due to the status versus configuration focus. For example, 260 limiting maximum prefixes and maximum paths is done in a slightly 261 different way. A second example is that community and cluster 262 strings. 264 Below is an example of the AF-status structure found in draft-bgp- 265 dm-00 267 module: bgp-protocol 268 +--rw bgp-protocol 269 +--rw bgp-ipv4-uni-instance 270 | +--rw bgp-local-rib 271 | +--rw bgp-peer-list 272 | +--rw bgp-rib-in 273 | +--rw bgp-rib-out 274 ...... 275 +--rw bgp-evpn-instance 276 | +--rw bgp-local-rib 277 | +--rw bgp-peer-list 278 | +--rw bgp-rib-in 279 | +--rw bgp-rib-out 281 figure bgp-3 283 4.1. Overlap of configuration draft-zhdankin-netmod-bgp-01 285 The draft-zhdankin-netmod-bgp-01 and draft-wang-i2rs-bgp-dm-00 both 286 contain at the protocol level: 288 module: bgp 289 +--rw bgp router [bgp protocol] 290 +--rw local-as-number? unit32 291 +--rw local-as-identifier inet:ip-address (zhdankin) 292 +--rw router-id inet:ip-address (wang) 293 ... 294 figure bgp-3 296 The module contains at the peer level the association of a peer with 297 an AS 299 [draft-zhdank-netmod-bgp-01] 301 +--rw bgp-neighbors* [AS-number] 302 +--rw as-number 303 +--rw (peer-address-type)? 304 . . . 305 +--rw prefix-list prefix-list-ref 306 +--default-action? enumeration (permit/deny) 308 [[I-D.wang-i2rs-bgp-dm]] 310 +--rw bgp-peer-list* [bgp-peer-name] 311 +--rw peer-session-address? 312 . . . 313 +--rw peer-name 314 +--ro peer-type 315 +--rw bgp-policy-in policy-set-name 316 +--rw bgp-policy-out policy-set-name 318 figure bgp-5 320 4.2. Unique configuration for draft-zhdankin-netmod-bgp-01 322 [I-D.zhdankin-netmod-bgp-cfg] contains the unique configuration for 323 RPKI, AF-configuration and BGP peers. A sample of the unique 324 configuration for the AF-configuration is: 326 o cost-communities 328 o BGP-damping 330 o route-aggregation - this is policy so we could easily add, 331 o reflector clients 333 o best external advertisement 335 o aggregate timer (sending out aggregate times) 337 o flags to compare router-id as part of bgp bestpath selection 339 o MED-confederation 341 o administrative distance (cisco) 343 o packet forwarding over multiple paths 345 o allowances for slow peers 347 o BGP multi-path (ECMP peers) 349 o external fail-over for peer 351 o AS confederations 353 o deterministic MEDs 355 o Graceful-restart 357 o BGP AS listener only 359 o Logging of neighbor changes 361 o Transport options for BGP 363 o Removal of private AS 365 4.3. Unique configuration for draft-wang-bgp-dm-00 367 The following variables were included in [I-D.hares-i2rs-bgp-dm], but 368 not in [I-D.zhdankin-netmod-bgp-cfg]: 370 o protocol-status (ro) - needed for I2RS information 372 o shutdown protocol - needed if I2RS is to shutdown bgp protocol, 374 o AFI based local-rib 376 o BGP-peer-status information - [I-D.zhdankin-netmod-bgp-cfg] has 377 number of updates, but less status information in the draft. 379 The following pieces are needed by I2RS: 381 o At instance level, bgp-instance-name, bgp-instance-create (to 382 create bgp process), bgp-instance-type (to specify what type to 383 create), 385 o At AFI level in local rib, bgp_route_create (to add bgp route for 386 i2rs) and bgp_state_info for status updates. 388 o At peer level, there must be maximum prefixes per peer (received 389 and transmit), high water/low water prefix counts, and average 390 number of prefixes; 392 o Versions for instance publishing, 394 o Details on path attributes: ASpath strings, community and extend- 395 community attribute, cluster lists, aggregation, atomic 396 aggregator; 398 o Mechanisms for logging/publishing information 400 5. Comparison of State needed versus BGP requirements 402 5.1. BGP-REQ 01 404 BGP-REQ01 requirement is: I2RS client/agent exchange SHOULD support 405 the read, write and quick notification of status of the BGP peer 406 operational state on each router within a given Autonomous System 407 (AS). This operational status includes the quick notification of 408 protocol events that proceed a destructive tear-down of BGP session 410 [I-D.zhdankin-netmod-bgp-cfg] contains the following status related 411 to each peer's bgp operational state. 413 module: bgp 415 +--bgp-router 416 + . . . 417 +--rw bgp-neighbors 418 +--rw peer-address 419 | . . . 420 +--rw bgp-neighbor-state 421 +--rw bgp-peer-admin-status enumeration 422 +--rw in-lastupdatetime 423 Figure bgp-6 425 Conclusion: [I-D.zhdankin-netmod-bgp-cfg] does not provide support 426 required by I2RS. 428 [I-D.wang-i2rs-bgp-dm] contains the following status related to each 429 peer's BGP operational state: 431 module: bgp 433 +--bgp-protocol 434 + . . . 435 +rw bgp-ipv4-uni-instance (af-instance) 436 +--rw bgp-instance-name 437 | . . . 438 +--rw bgp-local-rib 439 | . . . 440 +--rw bgp-peer-list [bgp-peer-name] 441 | . . . 442 | +--rw peer-state-info 443 | | +--rw peer-current-state? peer-state 444 | | |--rw peer-last-state? peer-state 445 | | |--ro peer-down-reason 446 | | |--ro error code? enumeration 447 | | | +--ro (sub-error-code-type)? 448 | | | | +--: (head-error-sub-code) 449 | | | | +--ro head-error-sub-value? enumeration 450 | | | | +--: (open-error-sub-code) 451 | | | | +--ro open-error-sub-value? enumeration 452 | | | | +--: (update-error-sub-code) 453 | | | | +--ro-update-error-sub-value? enumeration 454 | | | | +--: (route-refresh-error-sub-code) 455 | | | | +--ro-route-refresh-error-sub-value? enumeration 457 figure bgp-7 459 Conclusion: [I-D.wang-i2rs-bgp-dm] provides for this requirement. 461 5.2. BGP-REQ 02 463 BGP-REQ02 requirement is: "I2RS client SHOULD be able to push BGP 464 routes with custom cost communities to specific I2RS agents on BGP 465 routers for insertion in specific BGP Peer(s) to aid Traffic 466 engineering of data paths. These routes SHOULD be tracked by the 467 I2RS Agent as specific BGP routes with customer cost communities. 468 These routes (will/will not) be installed via the RIB-Info." 470 Status: 472 [I-D.zhdankin-netmod-bgp-cfg] supports configuration related to 473 address family control of these features, but it does not have a 474 route level support. The AFI family configuration is shown in 475 context below: 477 module: bgp 478 +--rw bgp-router 479 | +--rw local-as-number? uint32 480 | +--rw local-as-identifier? inet:ip-address 481 | +--rw rpki-config 482 | | ..... 483 | +--rw af-configuration 484 | | +--rw ipv4 485 | | | +--rw mdt 486 | | | . . . 487 | | | +--rw multicast 488 | | | | +--rw bgp 489 | | | | | +--rw bgp-af-config 490 | | | | | | . . . 491 | | | | | | +--rw bestpath 492 | | | | | | | +--case as-path: 493 | | | | | | | ignore-as-path boolean 494 | | | | | | | +--case compare-routerid 495 | | | | | | | | ignore-routerid boolean 496 | | | | | | | + case cost-community 497 | | | | | | | | ignore-cost-community Boolean 498 | | | | . . . 499 | | | +--rw unicast 500 | | | | +--rw bgp 501 | | | | +--rw bgp-af-config 502 | | | | | . . . 503 | | | | | +--rw bestpath 504 | | | | | | . . . 505 | | | | | | +--case cost-community 506 | | | | | | | | ignore-cost-community Boolean 507 | | | +--rw unicast 508 | | | | +--rw bgp 509 | | | | +--rw bgp-af-config 510 | | | | | . . . 511 | | | | | +--rw bestpath 512 | | | | | | . . . 513 | | | | | | +--case cost-community 514 | | | | | | | | ignore-cost-community Boolean 516 (replicated for appropriate AFIs) 517 Figure bgp-8 519 Conclusion: This [I-D.zhdankin-netmod-bgp-cfg] does not adequately 520 support the I2RS BGP REQ02. . 522 [I-D.wang-i2rs-bgp-dm] does support per-route configuration tagging 523 of route with customer community in local BGP rib, and per peer 524 AdjRibIn and adjRibout 525 +--bgp-protocol 526 + . . . 527 +rw bgp-ipv4-uni-instance (af-instance) 528 +--rw bgp-instance-name 529 | . . . 530 +--rw afi 531 +--rw safi 532 +--rw bgp-local-rib 533 | +--rw bgp-route-list* [ipv4-route ipv4-prefix-length] 534 | | +--rw ipvr-route inet:ipv4-prefix 535 | | +--rw ipv4-prefix-length uint8 536 | | +--rw route-type? enumeration 537 | | +--rw bgp-attribute-list* 538 | | | +--rw bgp-origin? 539 | | | . . . 540 | | | +--rw bgp-extcommattr 541 | | | | +--rw custom-community 542 | | | | | +--rw valid boolean 543 | | | | | +--rw insertion point uint8 544 | | | | | +--rw community-id uint8 545 | | | | | +--rw cost-id uint32 546 | | | | +--rw useextcommsize uint16 547 | | | | +--rw ulrefcount? uint16 548 | | | | +--rw excmmattr-value string 549 | +--rw bgp-peer-list* (bgp-peer-name) 550 | | . . . 551 | | +--rw bgp-rib-in 552 | | | +--rw bgp-rib-in-list* (ipv4 route 553 | | | | ipvr-prefix-length route-distinguisher) 554 | | | | +--rw ipv4-route inet_ipv4-prefix 555 | | | | | +--rw bgp-attribute-list* 556 | | | | | | . . . 557 | | | | | | +--rw bgp-extcommattr 558 | | | | | | | +--rw custom-community 559 | | | | | | | +--rw valid boolean 560 | | | | | | | +--rw insertion point uint8 561 | | | | | | | +--rw community-id uint8 562 | | | | | | | +--rw cost-id uint32 563 | | | | | | | +--rw useextcommsize uint16 564 | | | | | | | +--rw ulrefcount? uint16 565 | | | | | | | +--rw excmmattr-value string 566 | | | . . . 567 | | +--rw bgp-rib-out 568 | | | +--rw bgp-rib-out-list* (ipv4 route 569 | | | | ipv4-prefix-length route-distinguisher) 570 | | | | +--rw ipv4-route inet_ipv4-prefix 571 | | | | | +--rw bgp-attribute-list* 572 | | | | | | . . . 574 | | | | | | +--rw bgp-extcommattr 575 | | | | | | | +--rw custom-community 576 | | | | | | | +--rw valid boolean 577 | | | | | | | +--rw insertion point uint8 578 | | | | | | | +--rw community-id uint8 579 | | | | | | | +--rw cost-id uint32 580 | | | | | | | +--rw useextcommsize uint16 581 | | | | | | | +--rw ulrefcount? uint16 582 | | | | | | | +--rw excmmattr-value string 584 Figure bgp-9 586 Conclusion: [I-D.wang-i2rs-bgp-dm] needed as well as 587 [I-D.zhdankin-netmod-bgp-cfg]. 589 5.3. BGP-REQ 03 591 BGP-REQ03 requirement is: "I2RS client SHOULD be able to track via 592 read or notifications all Traffic engineering changes applied via 593 I2RS agents to BGP route processes in all routers in a network." 595 Discussion on Requirement: Traffic engineering changes can include: 596 ORFs (RFC5291, 5292), flows specifications (RFC5575, draft-ietf-), TE 597 performance (draft-ietf-idr-te-pm-bgp-01), traffic-engineering state 598 (draft-ietf-idr-te-lsp-distribution), and route target filtering. 599 Additional input needs to be obtained from the i2rs WG on what 600 constitutes traffic engineering. 602 Status: 604 [I-D.zhdankin-netmod-bgp-cfg] has the following potential 605 configuration support: 607 o on most af configurations: af-bgp_config container supports 608 allowing the following features: add-path, best-external, 609 aggregation timer, damping, propagating dmz-link-bw, and 610 redistributing iBGP routes into IGP. 612 o af rtfilters - AFI for rtfilters. 614 These features do not provide any of the traffic engineering input. 616 [I-D.wang-i2rs-bgp-dm]: has per route status tracking for the local- 617 rib associated with each afi, and the virtual bgp AdjRibIn and BGP 618 AdjRibOut for each peer. Each route has a route type that include 619 route types for all valid NLRIs which includes: ipv4, ipv6, labeled 620 ipv4, labeled ipv6, flows, link-state (ls) data, evpn, mvpn, vpls, 621 l2vpn-singaling-nlri, rt-constraint, pw-route. 623 +--bgp-protocol 624 + . . . 625 +rw bgp-ipv4-uni-instance (af-instance) 626 +--rw bgp-instance-name 627 | . . . 628 +--rw afi 629 +--rw safi 630 +--rw bgp-local-rib 631 | +--rw bgp-route-list* [ipv4-route ipv4-prefix-length] 632 | | +--rw ipvr-route inet:ipv4-prefix 633 | | +--rw ipv4-prefix-length uint8 634 | | +--rw route-type? enumeration 635 | | +--rw route-admin-distance uint16 636 | | .... 637 | | +--rw bgp-attribute-list* 638 | | | +--rw bgp-origin? 640 Figure bgp-10 642 What needs to be added: Once the I2RS WG specifies what traffic 643 engineering flags to watch on the BGP routes at AFI local-rib level 644 or the BGP-peer routes (AdjRibIn, AdjRibOut), then the 645 [I-D.wang-i2rs-bgp-dm] can be augmented. 647 If the I2RS WG specifies configurations for traffic engineering at 648 the AFI or BGP-peer level, these ephemeral status will either need to 649 be added to draft-want-i2rs-bgp-dm-00 status or the peer. 651 5.4. BGP-REQ 04 653 BGP-REQ04 requirement is: "I2RS Agents SHOULD support identification 654 of routers as BGP ASBRs, PE routers, and IBGP routers." 656 [I-D.zhdankin-netmod-bgp-cfg]: No status provides a summation of the 657 BGP roles a BGP routing instance. The BGP-neighbor structure does 658 not provide a role structure. 660 [I-D.wang-i2rs-bgp-dm]: 662 module: bgp-protocol 663 +--rw bgp-protocol 664 +--rw router-id? inet:ip-address 665 +--rw as-number? uint32 666 + . . . 667 +--ro bgp-role? enumeration 668 +--rw af instance 669 | +--rw bgp-local-rib 670 | . . . 671 | +--rw bgp-peer-list* [bgp-peer-name] 672 | | +--rw bgp peer-session 673 | | +--rw bgp-peer-name 674 | | +--bgp-peer-type? enumeration 676 Figure bgp-11 678 The enumeration for bgp-role is asbr, pe, ibgp,rr where the role is a 679 bit mask indicating that one or more peer has this role on the 680 protocol instance. 682 The enumeration for bgp-peer-type is asbr, ibgp, rr, rr-client, pe, 683 ce, bgp-vendor-types; 685 Conclusion: [I-D.wang-i2rs-bgp-dm] supports BGP-REQ 04 687 5.5. BGP-REQ 05 689 BGP-REQ05 is: I2RS client-agent SHOULD support writing traffic flow 690 specifications to I2RS Agents that will install them in associated 691 BGP ASBRs and the PE routers. 693 Status: BGP-REQ05 is the ability to read the roles within a bgp 694 protocol instances at protocol level and at peer level, and to write 695 routes with traffic flow specifications to AFI database and 696 (optionally) bgp-peer AdjRibOut. 698 BGP-REQ 4 showed that the [I-D.wang-i2rs-bgp-dm] supports the 699 identification of BGP ASBR and PE routers at a peer level. It also 700 has a quick summary of the roles of BGP routers at the protocol 701 level. [I-D.wang-i2rs-bgp-dm] specifies a a route-type variable 702 within each route in the AFI local-rib or the BGP Peers routes 703 (AdjRibIn, AdjRibOut), and this route-type includes a enumeration 704 variable for flows. 706 [I-D.wang-i2rs-bgp-dm] 707 module: bgp protocol 708 +--bgp-protocol 709 + . . . 710 +rw bgp-ipv4-uni-instance (af-instance) 711 +--rw bgp-instance-name 712 | . . . 713 +--rw afi 714 +--rw safi 715 +--rw bgp-local-rib 716 | +--rw bgp-route-list* [ipv4-route ipv4-prefix-length] 717 | | +--rw ipv4-route inet:ipv4-prefix 718 | | +--rw ipv4-prefix-length uint8 719 | | +--rw route-type? enumeration 721 Figure bgp-12 723 Conclusion: [I-D.wang-i2rs-bgp-dm] supports BGP-REQ-05. 725 5.6. BGP-REQ 06 727 BGP-REQ06 requirement is: "I2RS Client SHOULD be able to track flow 728 specifications installed within a IBGP Cloud within an AS via reads 729 of BGP Flow Specification information in I2RS Agent, or via 730 notifications from I2RS agent." 732 Status: As section 3.5.5 on BGP-REQ04 shows [I-D.wang-i2rs-bgp-dm] 733 supports the tracking of flow-specification routes associated with 734 the local-rib for a AFI or a BGP Peer. 736 [I-D.wang-i2rs-bgp-dm]: 738 module: bgp protocol 739 +--bgp-protocol 740 + . . . 741 +rw bgp-ipv4-uni-instance (af-instance) 742 +--rw bgp-instance-name 743 | . . . 744 | +--rw bgp-local-rib 745 | | +--rw bgp-rib-in-list* (ipv4 route ipv4-prefix-length 746 | | | +--rw ipv4-route inet:ipv4-prefix 747 | | | +--rw ipv4-prefix-length uint8 748 | | | +--rw route-type? enumeration 749 | | . . . 750 | +--rw bgp-peer-list* (bgp-peer-name) 751 | | +--rw bgp-peer-session addres 752 | | +--rw bgp-peer-name 753 | | +--rw bgp-peer-type 754 | | +--rw bgp-rib-in 755 | | | +--rw bgp-rib-in-list* (ipv4 route ipv4-prefix-length 756 | | | | +--rw ipv4-route inet:ipv4-prefix 757 | | | | +--rw ipv4-prefix-length uint8 758 | | | | +--rw route-type? enumeration 760 Figure bgp-13 762 5.7. BGP-REQ 07 764 BGP-REQ07 requirement is: I2RS client-agent exchange SHOULD support 765 the I2RS client being able to prioritize and control BGP's 766 announcement of flow specifications after status information reading 767 BGP ASBR and PE router's capacity. BGP ASBRs and PE routers 768 functions within a router MAY forward traffic flow specifications 769 received from EBGP speakers to I2RS agents, so the I2RS Agent SHOULD 770 be able to send these flow specifications from EBGP sources to a 771 client in response to a read or notification. 773 Discussion: The I2RS WG needs to provide additional input on what 774 status information is key to track for the BGP ASBR and PE router's 775 capacity. 777 Status: 779 [I-D.zhdankin-netmod-bgp-cfg] has prefix-lists which can allow or 780 deny prefixes based on the NLRI family. This feature allows the 781 control of routes via the flow specification NLRI. However peer 782 status does not provide an easy way to detect BGP ASBR or PE status, 783 or the number of routes. 785 [I-D.wang-i2rs-bgp-dm] has the ability to specify flexible policy via 786 policy-sets for inbound and outbound policy that can filter based on 787 prefix or any match sequence within the route and peer. This draft 788 also provides a data model that tracks track which peers are ASBR and 789 PEs at the peer level via bgp-peer-type and at the protocol level via 790 bgp-role (as described above). This draft also specifies 791 administrative distance on route structures in the per AFI bgp-local- 792 rib or in the peers routes per AFI. 794 module: bgp protocol 795 +--bgp-protocol 796 + . . . 797 +rw bgp-ipv4-uni-instance (af-instance) 798 +--rw bgp-instance-name 799 | . . . 800 | +--rw bgp-local-rib 801 | | +--rw bgp-rib-in-list* (ipv4 route ipv4-prefix-length 802 | | | +--rw ipv4-route inet:ipv4-prefix 803 | | | +--rw ipv4-prefix-length uint8 804 | | | +--rw route-type? enumeration 805 | | | +--rw route-admin-distance uint32 806 | | | +--rw route-rpki-origin-validity 807 | | | | +--rw rt-rpki-origin-valid Boolean 808 | | | | +--rw rt-rpki-ref rpki-validity-ref 810 figure bgp-14 812 5.8. BGP-REQ 08 814 BGP-REQ08 requirement is: "I2RS Client SHOULD be able to read BGP 815 route filter information from I2RS Agents associated with legacy BGP 816 routers, and write filter information via the I2RS agent to be 817 installed in BGP RR. The I2RS Agent SHOULD be able to install these 818 routes in the BGP RR, and engage a BGP protocol action to push these 819 routers to ASBR and PE routers." 821 Discussion: The router filter information is determined to be the 822 prefix-filters or policy-filters associated with BGP routes found in 823 the AFI based bgp-local-rib or peer's structures (AdjRibIn, 824 AdjRibout). 826 Status: 828 [I-D.zhdankin-netmod-bgp-cfg] has prefix-lists which can allow or 829 deny prefixes based on the NLRI. This yang model does not provide an 830 easy way to detect peers as taking on the BGP RR, ABSR, and PE. (See 831 section 3.3 and yang model for the prefix-list descriptions). 833 [I-D.wang-i2rs-bgp-dm] has the ability to specify flexible policy via 834 policy-groups or policy sets for inbound and outbound policy that can 835 filter based on prefix or any match sequence within the route and 836 peer. This draft also provides a data model that tracks track which 837 peers are ASBR, PEs, and RR at the peer level via bgp-peer-type and 838 at the protocol level via bgp-role. (Please see draft-ietf-i2rs- 839 hares-bnp-info-model and draft-itef-hares-i2rs-bnp-dm for full 840 description). 842 5.9. BGP-REQ 09 844 BGP-REQ09: I2RS client(s) SHOULD be able to request the I2RS agent to 845 read BGP routes with all BGP parameters that influence BGP best path 846 decision, and write appropriate changes to the BGP Routes to BGP and 847 to the RIB-Info in order to manipulate BGP routes. 849 Discussion: Best-path is considered when policy evaluation is the 850 same. The best path could be considered based on origin-as, as-path, 851 router-id, cost-community. igp-metric, med-confed, missing-as-med, 852 rpki-origin validity. This requirement needs to be refined to 853 specify an initial set of BGP parameters that influence BGP best path 854 decisions. 856 Status: 858 [I-D.zhdankin-netmod-bgp-cfg] configures the parameters that 859 influence BGP bestpath decisions. However, this draft does not 860 provide these parameters within each bgp-route. 862 [I-D.wang-i2rs-bgp-dm] provides the per route status on origin-as, 863 as-path, router-id, cost-community, igp-metric, MED, and rpki-origin 864 validity. This route status is on the AFI level local-rib and the 865 per peer routes (AdjRibIn, AdjRibOut). 867 module: bgp protocol 868 +--bgp-protocol 869 + . . . 870 +rw bgp-ipv4-uni-instance (af-instance) 871 +--rw bgp-instance-name 872 | . . . 873 | +--rw bgp-local-rib 874 | | +--rw bgp-rib-in-list* (ipv4 route ipv4-prefix-length 875 | | | +--rw ipv4-route inet:ipv4-prefix 876 | | | +--rw ipv4-prefix-length uint8 877 | | | +--rw route-type? enumeration 878 | | | +--rw route-admin-distance uint32 879 | | | +--rw route-rpki-origin-validity 880 | | | | +--rw rt-rpki-origin-valid Boolean 881 | | | | +--rw rt-rpki-ref rpki-validity-ref 883 figure bgp-15 885 5.10. BGP-REQ 10 887 BGP-REQ10 requirement is: I2RS client SHOULD be able instruct the 888 I2RS agent(s) to notify the I2RS client when the BGP processes on an 889 associated routing system observe a route change to a specific set of 890 IP Prefixes and associated prefixes. Route changes include: 1) 891 prefixes being announced or withdrawn, 2) prefixes being suppressed 892 due to flap damping, or 3) prefixes using an alternate best-path for 893 a given IP Prefix. The I2RS agent should be able to notify the 894 client via publish or subscribe mechanism. 896 Discussion: RFC5277 indicates that a netconf-filter looks for 897 specific data value and data item. Therefore, the I2RS client must 898 specify the whether the data is in the AFI based local-rib or the BGP 899 (AdjRibIn, AdjRibOut) and the specific values. The specific values 900 indicated by BGP-REQ-10 are prefixes with: announce flags, withdrawn 901 flags, flap-dampened suppression flags, on-best-path-external or 902 rejected due to best-path external. This comparison assumes the 903 RFC5277 paths can be made to work for the ephemeral storage. 905 Sorting of these filters into critical or normal status requests is 906 not considered in this comparison as adding this upon a non-existent 907 definition of ephemeral services seems futile. 909 [I-D.zhdankin-netmod-bgp-cfg] configures the parameters that 910 influence BGP bestpath decisions or flap damping. However, this 911 draft does not provide these parameters within each bgp-route. 913 [I-D.wang-i2rs-bgp-dm]: 915 +--rw ipv4-route inet:ipv4-prefix 916 +--rw ipv4-prefix-length uint8 917 +--rw bgp-route-type? enumeration 918 +--rw bgp-attribute-list 919 ... 920 +--ro bgp-rt-state-in 921 +--ro rib-current-state? rib-state-def 922 +--ro rib-last-state? rib-state-def 923 +--ro rib-rejected-reason? enumeration 924 +--ro not-preferred-reason? enumeration 925 . . . 927 typedef rib-state-def { 928 type enumeration { 929 enum "active"; 930 enum "in-active"; 931 enum "primary"; 932 enum "backup"; 933 enum "suppressed (flap dampened)" 934 enum "suppressed non-flap dampen" 935 enum "active on alternate best path" 936 } 938 Leaf not-preferred-reason { 939 Type enumeration { 940 enum "peer-address"; 941 enum "router-id"; 942 enum "cluster-list-length"; 943 enum "igp-metric"; 944 enum "peer-type"; 945 enum "origin"; 946 enum "weight-or-preferred-value"; 947 enum "local-preference"; 948 enum "route-type"; 949 enum "as-path-length"; 950 enum "med"; 951 enum "flap-dampened route"; [new] 952 enum "not-this-path-prefix-uses-alternate-best-path"; [new] 953 enum "overlapping-route-marked-to-remove"; [new] (BGP-REQ17) 954 } 956 Figure bgp 16 958 Conclusion: [I-D.wang-i2rs-bgp-dm] status is needed for this BGP- 959 REQ10. 961 5.11. BGP-REQ 11 963 BGP-REQ11 requirement is the "I2RS client SHOULD be able to read BGP 964 route information from BGP routers on routes in received but rejected 965 from ADJ-RIB-IN due to policy, on routes installed in ADJ-RIB-IN, but 966 not selected as best path, and on route not sent to IBGP peers (due 967 to non-selection)." 969 Discussion: As discussed in BGP-REQ10, RFC5277 indicates that a 970 netconf-filter looks for specific data value and data item. 971 Therefore, the I2RS client must specify the whether the data is in 972 the AFI based local-rib, or the BGP (AdjRibIn, AdjRibOut) and the 973 specific values 975 Status: 977 [I-D.zhdankin-netmod-bgp-cfg] configures policy that indicates what 978 routes are filtered, but it does not provide the status parameter on 979 each BGP route. 981 [I-D.wang-i2rs-bgp-dm]: Shows that the status can be tracked in the 982 AFI based bgp local-rib and the per AFI per peer AdjRibIn and AdjRib 983 out. 985 Conclusion: [I-D.wang-i2rs-bgp-dm] status is needed for BGP-REQ10. 987 5.12. BGP-REQ 12 989 BGP-REQ12 requirement is: the "I2RS client SHOULD be able to request 990 the I2RS agent to read installed BGP Policies." 992 Discussion: BGP policies can be inbound filters, ACLs, or route maps. 993 Three yang drafts take different approaches to the filters: draft- 994 bogdanovic-netmod-acl-model-02, [I-D.zhdankin-netmod-bgp-cfg], and 995 draft-hares-2rs-bnp-dm-01. 997 The draft-bogdanovic-netmod-acl-model-02 takes the approach of 998 extending the firewall ACLs, and suggests that proprietary methods be 999 used to extend this to the ranges needed for BGP policy. The index 1000 to the ACLS is the rule-name. For a single prefix accept/deny the 1001 generic ACL policy may be sufficient. Prefix ranges or the ability 1002 to set custom cost communities or other extended communities must use 1003 a proprietary vendor's model. 1005 The [I-D.zhdankin-netmod-bgp-cfg] (10/1/2014) suggests prefix-list 1006 matches that should provide prefix matches an index of route ID 1007 number (uint16). The prefix matches can be either ip-address, 1008 prefix, host address, or prefix-range. The only actions taken are 1009 accept or deny the prefix. The usage statistics contains only the 1010 "hit count" for the usage of the prefix mask. 1012 The [I-D.wang-i2rs-bgp-dm] (10/23/2014) provides a policy link to the 1013 Basic Network Policy (draft-hares-i2rs-bnp-info-model/draft-hares- 1014 i2rs-bnp-dm-01) which provides ordered list of policy rules that can 1015 provide sequences of match, actions (accept/deny, set variable, and 1016 modify). A group of these policy rules is called a policy group 1017 which can be named. 1019 This model uses the policy definitions concept is also found in the 1020 Policy Core Information Model (PCIM) (RFC3060) and the Quality of 1021 Service QoS) Policy Information Model (QPIM)(RFC3644) and policy 1022 based routing. ACL-based policy (draft-bogdanovic-netmod-acl-model- 1023 02), and prefix-list policy (accept/deny) can be one of the policy 1024 rule extensions. The [I-D.zhdankin-netmod-bgp-cfg] can provide a 1025 second policy rule extension. 1027 The section below provides the specific modeling parameters for each 1028 draft. 1030 draft-bogdanovic-netmod-acl-model-02 1032 +--rw access-list-entry* [rule-name] 1033 +--rw rule-name string 1034 +--rw matches 1035 | +--rw (ace-type)? 1036 | | +--:(ace-ip) 1037 | | | +--rw source-port-range 1038 | | | | +--rw lower-port inet:port-number 1039 | | | | +--rw upper-port? inet:port-number 1040 | | +--rw destination-port-range 1041 | | | | +--rw lower-port inet:port-number 1042 | | | | +--rw upper-port? inet:port-number 1043 | | | +--rw dscp? inet:dscp 1044 | | | +--rw ip-protocol? uint8 1045 | | | +--rw (ace-ip-version)? 1046 | | | +--:(ace-ipv4) 1047 | | | | +--rw destination-ipv4-address? 1048 inet:ipv4-prefix 1049 | | | | +--rw source-ipv4-address? 1050 inet:ipv4-prefix 1051 | | | +--:(ace-ipv6) 1052 | | | +--rw destination-ipv6-address? 1053 inet:ipv6-prefix 1054 | | | +--rw source-ipv6-address? 1055 inet:ipv6-prefix 1056 | | | +--rw flow-label? inet:ipv6-flow-label 1057 | | +--:(ace-eth) 1058 | | +--rw destination-mac-address? 1059 yang:mac-address 1060 | | +--rw destination-mac-address-mask? 1061 yang:mac-address 1062 | | +--rw source-mac-address? 1063 yang:mac-address 1064 | | +--rw source-mac-address-mask? 1065 yang:mac-address 1066 | +--rw input-interface? string 1067 | +--rw absolute 1068 | +--rw start? yang:date-and-time 1069 | +--rw end? yang:date-and-time 1070 | +--rw active? boolean 1071 | +--rw actions 1072 | +--rw (packet-handling)? 1073 | +--:(deny) 1074 | | +--rw deny? empty 1075 | +--:(permit) 1076 | +--rw permit? empty 1077 +--ro ace-oper-data 1078 +--ro match-counter? ietf:counter64 1080 Figure bgp-17 1082 [I-D.zhdankin-netmod-bgp-cfg] (10/1/2014) 1084 +--rw prefix-lists 1085 +--rw prefix-list [prefix-list-name] 1086 +--rw prefix-list-name string 1087 +--rw prefixes 1088 +--rw prefix [seq-nr] 1089 +--rw seq-nr uint16 1090 +--rw prefix-filter 1091 +--rw (ip-address-group)? 1092 | (cases 1093 +--rw action actions-enum 1094 +--rw statistics 1095 .. 1096 Figure bgp-18 1098 [I-D.wang-i2rs-bgp-dm] 1099 module: bgp_protocol 1100 +--rw bgp-protocol 1101 + af config 1102 +--rw bgp-policy-in policy-group-ref 1103 +--rw bgp-policy-out policy-group-ref 1105 Figure bgp-19 1107 draft-bnp-i2rs-bnp-dm-00 1109 (To be Completed after bnp drafts) 1111 Figure bgp-20 1113 5.13. BGP-REQ 13 1115 BGP-REQ13 requirement is: the "I2RS client SHOULD be able to instruct 1116 the I2RS Agent to write BGP Policies into the running BGP protocols 1117 and into the BGP configurations." 1119 Discussion: BGP-REQ 13 indicates that the policy changes supported by 1120 BGP-REQ 12 must be able to operate in the running configuration. The 1121 I2RS and netmod groups are discussing the definition of ephemeral. 1122 Two definitions are being discussed - patch and pull-up configuration 1123 as described below: 1125 running = config + ephemeral patches [patch] 1127 running = config (copy) + ephemeral additions (pull-up) 1129 Either definition implies that the I2RS changes can alter the policy 1130 based on the bgp configuration and I2rs model. 1132 The writing of changes from I2RS to the configuration was 1133 specifically ignored. Writing of specific configuration options from 1134 the ephemeral store to the running configuration can initially be 1135 done by the I2RS client writing via the configuration interface to 1136 the datastore. 1138 Data models needed: The Policy data models for filter or filter and 1139 action are the same as in BGP-REQ13. 1141 5.14. BGP-REQ 14 1143 BGP-REQ14 requirement is: the "I2RS client-agent SHOULD be able to 1144 read BGP statistics associated with Peer, and to receive 1145 notifications when certain statistics have exceeded limits. An 1146 example of one of these protocol statistics is the max-prefix limit." 1147 Discussion: BGP-REQ01 examines the peer connectivity state. BGP- 1148 REQ14 examines BGP peer statistics. [I-D.zhdankin-netmod-bgp-cfg] 1149 provides statistics on the number of updates received or sent, but it 1150 does not have statistics on the max-prefix exceeded. It does provide 1151 a limit for maximum-prefix per peer. 1153 [I-D.wang-i2rs-bgp-dm] has statistics on the number of updates 1154 received or sent, number of routes received or sent plus maximum 1155 prefix high-water and low-water. This draft also has the limits 1156 copied into the status fields for easy reading. 1158 [I-D.zhdankin-netmod-bgp-cfg] (10/1/2014) 1160 module: bgp 1161 + .... 1162 +--rw bgp-neighbors 1163 | +--rw bgp-neighbor [as-number] 1164 | +--rw as-number uint32 1165 | +--rw (peer-address-type)? 1166 | | ..... 1167 | +--rw prefix-list? prefix-list-ref 1168 | +--rw default-action? actions-enum 1169 | +--rw af-specific-config 1170 | +--ro bgp-neighbor-state 1171 | | +--ro bgp-peer-admin-status; 1172 | +--ro bgp-neighbor-statistics 1173 | | +--ro nr-in-updates 1174 | | +--rw nr-out-updates 1176 [I-D.wang-i2rs-bgp-dm] 1177 | +--rw bgp-peer-list* [bgp-peer-name] 1178 | +--rw peer-session-address 1179 | | +--rw local-ipv4-address? inet:ipv4-prefix 1180 | | +--rw remote-ipv4-address? inet:ipv4-prefix 1181 | +--rw bgp-peer-name string 1182 | +--ro bgp-peer-type? enumeration 1183 | +--ro bgp-peer-create? enumeration 1184 | +--rw bgp-policy-in policy-group-ref 1185 | +--rw bgp-policy-out policy-group-ref 1186 | +--rw peer-state-info 1187 | | +--ro peer-current-state? peer-stat 1188 | | +--ro peer-last-state? peer-state 1189 | | +--ro peer-down-reason 1190 | | | +--ro error-code? enumeration 1191 | | | +--ro sub-error-code 1192 | | | | ... 1193 | | +--ro peer-transmit-update-cnt? uint64 1194 | | +--ro peer-recived-update-cnt uint64 1195 | | +--ro peer-received-route-cnt? uint64 1196 | | +--ro peer-send-route-cnt? uint64 1197 | | +--rw max-prefix-rcv-limit? uint64 1198 | | +--rw max-prefix-xmt-limit? uint64 1199 | | +--ro peer-prefix-high? uint64 1200 | | +--ro peer-prefix-low? uint64 1202 Conclusion: Full support of BGP-REQ 14 requires the 1203 [I-D.wang-i2rs-bgp-dm] draft. 1205 5.15. BGP-REQ 15 1207 BGP-REQ15 requirement is: the "I2RS client via the I2RS agent MUST 1208 have the ability to read the loc-RIB-In BGP table that gets all the 1209 routes that the CE has provided to a PE router." 1211 Discussion: The [I-D.zhdankin-netmod-bgp-cfg] provides no indication 1212 of a local-rib or a local-RIB-in associated with a BGP peer. The 1213 [I-D.wang-i2rs-bgp-dm] provides a local-rib per AFI, and a local-RIB- 1214 IN (AdjRIBIn and AdjRIBOut) associated with each peer. The route 1215 table format is presented in figure bgp-9. 1217 Conclusion: [I-D.wang-i2rs-bgp-dm] is necessary for this requirement. 1219 5.16. BGP-REQ 16 1221 BGP-REQ16 requirement is: the "I2RS client via the I2RS agent MUST 1222 have the ability to install destination based routes in the local RIB 1223 of the PE devices. This must include the ability to supply the 1224 destination prefix (NLRI), a table identifier, a route preference, a 1225 route metric, a next-hop tunnel through which traffic would be 1226 carried." 1228 Discussion: If this refers to the I2RS LOC-RIB, then both drafts have 1229 policy which could redistribute I2RS routes. 1231 If BGP-REQ 16 refers to a BGP local-rib per AFI and the bgp-peer 1232 based bgp-rib-in (AdjRibIn) and bgp-rib-out (AdjRibOut). As this 1233 previous discussion indicates, the [I-D.zhdankin-netmod-bgp-cfg] does 1234 not have a local rib-in. 1236 The document [I-D.wang-i2rs-bgp-dm] describes a per AFI bgp local-rib 1237 and the per peer bgp-rib-in (AdjRIBIn) and bgp-rib-out (AdjRibOut). 1238 The routes in these RIBs fall under a table identifier structure and 1239 have a destination prefix (NLRI), route administrative preference, 1240 route local-reference, and a next-hop. However, 1241 [I-D.wang-i2rs-bgp-dm] does not have a tunnel based definition for 1242 the next-hop. This would need to be added. 1244 Conclusion: Additions to [I-D.wang-i2rs-bgp-dm] may need to be made 1245 to fulfill this requirement. 1247 5.17. BGP-REQ 17 1249 BGP-REQ17 requirement is: the "I2RS client via the I2RS agent SHOULD 1250 have the ability to read the loc-RIB-in BGP table to discover 1251 overlapping routes, and determine which may be safely marked for 1252 removal." 1254 Discussion: As discussed in BGP-REQ15 and BGP-REQ16, draft 1255 [I-D.zhdankin-netmod-bgp-cfg] does not have a local-RIB-In BGP table. 1256 [I-D.wang-i2rs-bgp-dm] has a BGP local-rib per AFI and a per BGP Peer 1257 bgp-rib-in. As described in BGP REQ10, this each route may set a 1258 "remove overlapping route" status flag. 1260 Conclusion: [I-D.wang-i2rs-bgp-dm] supports BGP-REQ 17. 1262 5.18. BGP-REQ 18 1264 BGP-REQ18 requirement is the "I2RS client via the I2RS Agent SHOULD 1265 have the ability to modify filtering rules and initiate a re- 1266 computation of the local BGP table through those policies to cause 1267 specific routes to be marked for removal at the outbound eBGP edge." 1269 Discussion: This feature requires that I2RS should be able to do a 1270 re-computation of policies. This re-computation of policies is part 1271 of a soft-reconfig which [I-D.zhdankin-netmod-bgp-cfg] allows by 1272 configuration. However, the I2RS client will need a parameter to be 1273 set to do a reconfigure. 1275 Neither [I-D.zhdankin-netmod-bgp-cfg] or [I-D.wang-i2rs-bgp-dm] have 1276 this feature. 1278 Conclusion: This feature needs to be added to final model 1280 6. IANA Considerations 1282 This draft includes no request to IANA. 1284 7. Security Considerations 1286 TBD 1288 8. Informative References 1290 [I-D.bogdanovic-netmod-acl-model] 1291 Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair, 1292 "Network Access Control List (ACL) YANG Data Model", 1293 draft-bogdanovic-netmod-acl-model-02 (work in progress), 1294 October 2014. 1296 [I-D.hares-i2rs-bgp-dm] 1297 Wang, L., Hares, S., and S. Zhuang, "An I2RS BGP Data 1298 Modell", draft-hares-i2rs-bgp-dm-00 (work in progress), 1299 October 2014. 1301 [I-D.hares-i2rs-info-model-service-topo] 1302 Hares, S., Wu, W., and X. Guan, "An Information model for 1303 service topology", draft-hares-i2rs-info-model-service- 1304 topo-01 (work in progress), July 2014. 1306 [I-D.hares-i2rs-usecase-reqs-summary] 1307 Hares, S., "Summary of I2RS Use Case Requirements", draft- 1308 hares-i2rs-usecase-reqs-summary-00 (work in progress), 1309 July 2014. 1311 [I-D.ietf-i2rs-architecture] 1312 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1313 Nadeau, "An Architecture for the Interface to the Routing 1314 System", draft-ietf-i2rs-architecture-05 (work in 1315 progress), July 2014. 1317 [I-D.ietf-i2rs-rib-info-model] 1318 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 1319 Information Base Info Model", draft-ietf-i2rs-rib-info- 1320 model-03 (work in progress), May 2014. 1322 [I-D.wang-i2rs-bgp-dm] 1323 Wang, L., Hares, S., and S. Zhuang, "An I2RS BGP Data 1324 Modell", draft-wang-i2rs-bgp-dm-00 (work in progress), 1325 October 2014. 1327 [I-D.zhdankin-netmod-bgp-cfg] 1328 Alex, A., Patel, K., and A. Clemm, "Yang Data Model for 1329 BGP Protocol", draft-zhdankin-netmod-bgp-cfg-01 (work in 1330 progress), October 2014. 1332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1333 Requirement Levels", BCP 14, RFC 2119, March 1997. 1335 [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, 1336 "Policy Core Information Model -- Version 1 1337 Specification", RFC 3060, February 2001. 1339 [RFC3460] Moore, B., "Policy Core Information Model (PCIM) 1340 Extensions", RFC 3460, January 2003. 1342 [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. 1343 Moore, "Policy Quality of Service (QoS) Information 1344 Model", RFC 3644, November 2003. 1346 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1347 Used to Form Encoding Rules in Various Routing Protocol 1348 Specifications", RFC 5511, April 2009. 1350 Author's Address 1352 Susan Hares 1353 Huawei 1354 7453 Hickory Hill 1355 Saline, MI 48176 1356 USA 1358 Email: shares@ndzh.com