idnits 2.17.1 draft-hares-i2rs-im-read-info-policy-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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 464 has weird spacing: '... policy poli...' == Line 465 has weird spacing: '... Action manda...' == Line 466 has weird spacing: '...ty role prior...' == Line 470 has weird spacing: '...esource sco...' -- The document date (February 14, 2014) is 3695 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: '1-N' is mentioned on line 461, but not defined == Unused Reference: 'RFC2119' is defined on line 868, but no explicit reference was found in the text == Unused Reference: 'RFC3060' is defined on line 871, but no explicit reference was found in the text == Unused Reference: 'RFC3644' is defined on line 875, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 879, but no explicit reference was found in the text == Unused Reference: 'RFC5394' is defined on line 882, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-hares-i2rs-info-model-policy-00 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-01 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-01 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-07 == Outdated reference: A later version (-02) exists of draft-ji-i2rs-usecases-ccne-service-00 == Outdated reference: A later version (-04) exists of draft-keyupate-i2rs-bgp-usecases-00 == Outdated reference: A later version (-06) exists of draft-white-i2rs-use-case-01 Summary: 1 error (**), 0 flaws (~~), 18 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 Hickory Hill Consulting 4 Intended status: Standards Track Q. Wu 5 Expires: August 18, 2014 Huawei 6 February 14, 2014 8 An Information Model for I2RS Reading Information Policy 9 draft-hares-i2rs-im-read-info-policy-00 11 Abstract 13 The Interface to the routing system (I2RS) specifies a new interface 14 that a client (I2RS client) can utilize to interface to the routing 15 system. Some applications that utilize the services of I2RS client 16 may require a specific set of data in response to network events or 17 conditions based on pre-established rules. In order to reduce the 18 data flow through the network, the I2RS client needs to signal the 19 I2RS agent to filter some of the collected data or events prior to 20 transmission to the i2rs client. This functionality is necessary to 21 meet the requirements I2RS enabled services which include service- 22 layer routing improvements, and control of traffic flows and exit 23 points. 25 This document introduces a read-only I2RS RIB policy Informational 26 Model that provides filters for the reads and notifications from the 27 I2RS RIB Info Model (IM). This model utilizes a generic information 28 model (IM) for policy templates that is extensible and hierarchical. 29 These templates support the features described by the I2RS 30 architectural model. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 18, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Reading of Network Policy Information . . . . . . . . . . . . 4 68 3. Example of Use of Read Filter Policy Information Model . . . 6 69 3.1. Read Filtering for Distributed Reaction to Network Based 70 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.2. Remote Service Monitoring . . . . . . . . . . . . . . . . 11 72 3.3. Within Data Center Routing . . . . . . . . . . . . . . . 13 73 3.4. Temporary overlays between Data Centers . . . . . . . . . 13 74 4. Read Filter Policy Information Model . . . . . . . . . . . . 13 75 4.1. Read Filter Policies . . . . . . . . . . . . . . . . . . 14 76 4.2. Generic Informational Model Templates . . . . . . . . . . 14 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 79 7. Informative References . . . . . . . . . . . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 82 1. Introduction 84 The Interface to the Routing System (I2RS) 85 [[I-D.ietf-i2rs-architecture]] provides read and write access to the 86 information and state within the routing process within routing 87 elements. The I2RS client interacts with one or more I2RS agents to 88 collect information from network routing systems. One set of 89 protocol independent use cases that the I2RS interface be used in are 90 described in [I-D.white-i2rs-use-case] Protocol Independent Use Case 91 for the Interface. These scenarios suggest that require I2RS 92 interfaces to be able to: 94 o monitor available routes installed based on the routes installed 95 in a RIB for a routing instance associated with forwarding device 96 at a near real-time rate 98 o interact with various policies configured on the forwarding 99 devices, in order to inform the policies implemented by the 100 dynamic routing processes. 102 o interact with traffic flow and other network traffic level 103 measurement protocols and systems, in order to determine path 104 performance, top talkers, and other information required to make 105 an informed path decision based on locally configured policy. 107 Processing of collected information at the I2RS agent may require the 108 I2RS Agent to filter certain information or group pieces of 109 information in order to reduce the data flow through the network to 110 the I2RS client. Some applications utilizing the services of an I2RS 111 client may also wish to require specific data in response to network 112 events or conditions based on pre-established policy rules. For 113 example if the traffic flow measured by network devices exceeds some 114 limit, then the I2RS client may wish to query for all routes with 115 some match pattern. This will allow service-layer routing 116 improvements, and control of traffic flows and exit points. 118 This document introduces an information model (IM) for filtering 119 policies enacted at I2RS agent before transmitting data to the I2RS 120 client. The [I-D.ietf-i2rs-architecture] suggests that associated 121 with the I2RS RIB model there will be "Policy-based Routing (ACLs)" 122 and RIB "policy controls". This policy model utilizes the generic 123 policy model found in [I-D.hares-i2rs-info-model-policy] and operates 124 on the I2RS RIB information module [I-D.ietf-i2rs-rib-info-model]. 125 The use of a generic policy model allows the creation of named 126 templates for reading or writing to the I2RS RIB module that have 127 three levels of structure (policy group, network policy, and Local 128 elements of policy). The local elements of policy operate in the 129 monitoring stage as read functionality and as filters for the I2RS 130 agent transmission of data to the I2RS client. 132 Reading information via I2RS from the BGP protocol regarding BGP 133 routes, BGP protocol events, and BGP protocol statistics may also be 134 needed to filter the information an I2RS agent sends to an I2RS 135 client. The [I-D.keyupate-i2rs-bgp-usecases] provides a use case for 136 BGP monitoring in section 5 where it indicates it is important to 137 monitor prefixes of "high visibility" end-users for the announcement 138 or withdraw of prefixes, the suppression of prefix announcements (due 139 to flap damping), and alternate best path selections. It is also 140 important to trace dropped routes, and statistics per EBGP session. 141 These BGP prefixes may need to be tracked both at the BGP and at the 142 active RIB level. The read policy described here for use by the I2RS 143 agent for the RIB Information can be extended to support the read 144 filtering for BGP. 146 Policy about what I2RS can read from the RIB is contained in the 147 following: 149 Read Policy Group 151 Policy is described by a set of policy rules that may be grouped 152 into subsets. The read policy group provides model context (or 153 scope) for the Policy rules within it. The model context has an 154 identity, scope, role, precedence, priority and security model. 155 In a policy group, policy rules and policy groups can be nested 156 within other policy rules. 158 Network-Policy 160 contains a coherent set of rules to administer, manage, and 161 control access between the I2RS client and the I2RS Agent. 163 Local Config 165 defines individual rules kept in the I2RS agent that are utilized 166 to filter data sent to the I2RS client. The filters associated 167 with the I2RS RIB Model, will include filters on the RIB Info 168 model including: routing instance ID, RIB ID, route attributes, 169 route, next-hop list, installation in FIB, Active in RIB, and 170 unresolved. 172 2. Reading of Network Policy Information 174 This section provides an overview of the Network Policy information 175 model. The next section contains an example of the RIB Filtering 176 model. 178 I2RS client requesting filtered data from the I2RS agent sets the 179 policy into a Network Policy list for Read Filtering. This policy 180 list is created as a set of policy sets that contain a policy group 181 with its associated policy rules. These policy rules are saved in 182 the I2RS Agent's local store. 184 If the I2RS Agent fails, then these policy rules must be instantiated 185 by the I2RS Client. The templates for the I2RS Agent may be part of 186 the generic templates stored within the routing system and uploaded 187 by name by the I2RS client. This would provide easy of maintenance 188 for systems with these policy templates. However, this is not a 189 requirement for the proper function of this Read Filtering Policy 190 model. 192 Below is a diagram of the Read Filtering policy model. 194 +-------------------------+ 195 | Read Filtering | 196 | Policy for | 197 | I2RS Agent | 198 | Policy Set | 199 | | 200 +--+-------------------+--+ 201 ^ ^ 202 /|\ /|\ (sequence of) 203 | "extends" | "extends" 204 +--------^-------+ +-------^-------+ +------------+ 205 | 206 | Policy Group | | Policy Rule |<---|Local Policy| 207 | 208 +----------------+ +---------------+ +------------+ 209 : : 210 ......: :..... 211 : : 212 : : 213 +---------V---------+ +-V-------------+ 214 | Policy Condition | | Policy Action | 215 +-------------------+ +---------------+ 216 : : : : : : 217 .....: . :..... .....: . :..... 218 : : : : : : 219 +----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+ 220 | Match | |Policy | |Policy| | Set || Policy ||Policy| 221 |Operator| |Variable| |Value | |Operator||Variable|| Value| 222 +--------+ +--------+ +------+ +--------++--------++------+ 224 Figure 1: Overall model structure 226 Policy set for Read Filtering Policy for I2RS agent 228 It is a policy set that describes all filtering that the I2RS 229 Agent does prior to sending data to the I2RS Client. This policy 230 set contains a set policy groups with their associated policy 231 rules and an indication whether this will be stored locally at the 232 I2RS Agent. 234 Policy Group 236 The policy group is a policy set which links to a set of policy 237 rules, and contains an identity, scope, role, precedence, priority 238 and security model. 240 Policy Rule 241 The policy rules are a set of policies in which each policy is 242 defined as: "< policy variable> matches value" where the result of 243 the match can be a set operator of "SET policy variable TO value". 245 Policy Groups can include other policy groups. This aids in building 246 up the policy set as logical components. Operational groups can 247 utilize this to map the policy groups to actual operational service 248 policies. In a similar fashion, policy sets could contain other 249 policy sets. 251 3. Example of Use of Read Filter Policy Information Model 253 This section provides an example of the Read Filter Policy 254 Information model. The example is taken from the protocol 255 independent use cases use cases this I2RS architecture can be used in 256 are described in [I-D.white-i2rs-use-case] Protocol Independent Use 257 Case for the Interface which contains the following examples: 259 o Distributed reaction to Network Based Attacks 261 o Remote Service Routing 263 o Within Data Center Routing 265 o Temporary overlays between Data Centers 267 The specific read monitoring filtering policy is proposed for each 268 use case. 270 3.1. Read Filtering for Distributed Reaction to Network Based Attacks 272 scenario: 274 +----------+ 275 |i2rs-client|------------------- 276 | |-----------+ | 277 -----------+ | | 278 | +------+ | 279 | | ir2s | | 280 | | agent| | 281 Valid Source--\ | /---|R2 |-------+\ 282 +-------+/ +------+ | \ 283 |R1 i2rs| | R3--Valid 284 | agent| | Destination 285 +-------+ i2rs agent 286 Attack Source--/ \--Monitoring Device-----/ 288 Figure 2 - Distributed reaction to Network Attacks 290 Description: 292 In the scenario of the of the Distributed Reactions, an I2RS client 293 is attached to the routing functions on a two network devices (R1 and 294 R2), and a network monitoring device (see figure 2). The routing 295 device R1 has external ports upon which both valid sources and (upon 296 attack) invalid sources may send data. The I2RS client is learning 297 attack prefixes from the monitoring devices which are processing 298 samples of the traffic. A set of suspected prefixes are collected by 299 the I2RS client from the monitoring devices. The I2RS Client uses 300 these prefixes to control the attack mitigation reading and writing 301 RIB policy. 303 Currently, the [I-D.ietf-i2rs-rib-info-model] only includes a "route 304 change notification" or "next-hop resolution". Neither of these 305 change notifications directly imply listening to a stream of the data 306 below, but should. This draft is focused on the READ filters 307 installed for the stream of notifications suggested by the 308 [I-D.ietf-i2rs-architecture] 310 The I2RS Client sends command to the I2RS agent in R1 and R2 to 311 request event notification of route changes for any destination 312 routes matching (exact or longer) prefixes which begin with 129.10/16 313 or 192.169/16. The I2RS Client sends notification filter policies to 314 the I2RS Agents at R1 and R2 to collect with the notification: the 315 routing instance, the RIB, the Route(route-attributes, route-match, 316 and next-hop list) for the watched prefixes. The I2RS Client also 317 sends commands to the forwarding function of R1, R2, and the 318 monitoring device to provide traffic statistics regarding the number 319 of prefixes received with these routes beginning with the prefix 320 129.10/16 (match or longer), and 192.169/16 (match or longer). 322 The Read Filter policy is instantiated at R1 and R2 in order to 323 filter just the routes necessary to track. Previous attack patterns 324 have seen 192.169.10/24 or longer prefixes used to during the attack. 325 A special detailed receive policy is also set-up to prepare for these 326 attacks. 328 The policy filtering matches security attack vector named "red dog 1" 329 so the operator decides to give this policy set an identity of "red 330 dog 1" with a scope of read, a role of security monitoring, a 331 precedence of 1, a priority of 1, and a security model of secure TCP. 332 The network prefix 129.10/16 (exact or longer) is identified as red- 333 net, and the prefix 192.169/16 (exact or longer) is weak-red-net. 334 The 192.169.10/24 is identified as weak-red-watch. 336 The Read filters sent for the states are include filters for the 337 traffic statistics per interface (Eg. exterior interface to network, 338 attack source, and R1-R2 Interface). 340 The following diagram provides the filters for the first policy. The 341 policy filtering matches attack vector "red dog 1" so the operator 342 decides to give this policy set an identity of "red dog 1" with a 343 scope of read, a role of security monitoring, a precedence of 1, a 344 priority of 1, and a security model of secure TCP. 346 +-------------------------+ 347 | Read Filtering | 348 | Policy for I2RS Agent | 349 | Policy Set for | 350 | Attack filters | 351 +--+-----------------+----+ 352 ^ [1..N] ^ [1..N] 353 /|\ /|\ ------------------------------------+ 354 | "extends" |-----------------+ | 355 | | | | 356 +--------^-----+ +-------^-------+ +-----+---------+ +-------+------+ 357 | Policy Group | | Policy Rule 1 | | Policy Rule 2 | |Policy Rule 3 | .... 358 | Red Dog 1 | | red-net | | weak-red-net | |weak-red-watch| 359 +--------------+ +---------------+ +---------------+ +--------------+ 360 : : 361 ......: :..... 362 : : 363 : : 364 +---------V---------+ +-V-------------+ 365 | Policy Condition | | Policy Action | 366 +-------------------+ +---------------+ 367 : : : : : : 368 .....: . :..... .....: . :..... 369 : : : : : : 370 +----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+ 371 | Match | |Policy | |Policy| | Set || Policy ||Policy| 372 |Operator| |Variable| |Value | |Operator||Variable|| Value| 373 +--------+ +--------+ +------+ +--------++--------++------+ 374 IP-ADDRESS- Destination Send 375 AS-RESOLVED Address 129.10/16 Set Route yes 376 -BY-DNS info 378 Figure 3: Example of read statistics filter 380 The following is the Read Filtering Policy Set 1 382 Policy Group 383 The policy group has an identity of "red dog 1", and a scope of 384 "read", role: "security monitor", precedence of 1, priority of 1, 385 and security model of "secure TCP". 387 Policy Rule 1 389 The policy rule 1 has an identity of "red-net". The policy 390 condition is: has a policy variable of "IP-ADDRESS-AS-RESOLVED-BY- 391 DNS", a policy variable of "Destination Address", and a policy 392 value of 129.10/16. The Policy actions associated with Policy 393 Rule 1 indicates a "SET" operator for the forwarding of any route 394 matching 129.10/16 prefix with exact match or longer match, and an 395 ACTION of "notify I2RS Client". 397 Policy Rule 2 399 The policy rule 2 has an identity of "weak-red-net". The policy 400 condition is: has a policy variable of "IP-ADDRESS-AS-RESOLVED-BY- 401 DNS", a policy variable of "Destination Address", and a policy 402 value of 192.169/16. The Policy actions associated with Policy 403 Rule 2 indicates a "SET" operator for the forwarding of any route 404 matching 129.10/16 prefix with exact match or longer match, and an 405 ACTION of "notify I2RS Client". 407 Policy Rule 3 409 The policy rule 3 has an identity of "weak-red-watch". The policy 410 condition is: has a policy variable of "IP-ADDRESS-AS-RESOLVED-BY- 411 DNS", a policy variable of "Destination Address", and a policy 412 value of 192.168.10/24. The Policy actions associated with Policy 413 Rule 3 indicates a "SET" operator for the sending of forwarding 414 statistics on any data packet matching 192.168.10/24 prefix with 415 exact match or longer match, and an ACTION of "notify I2RS Client. 417 Policy Rule 4 419 The policy rule 4 has an identity of "red-net stats". The policy 420 condition is: has a policy variable of "IP-ADDRESS-AS-RESOLVED-BY- 421 DNS", a policy variable of "Destination Address", and a policy 422 value of 129.10/16. The Policy actions associated with Policy 423 Rule 4 indicates a "SET" operator for the sending of forwarding 424 statistics on any data packet matching 129.10/16 prefix with exact 425 match or longer match from designated interfaces, and an and an 426 ACTION of "notify I2RS Client". 428 Policy Rule 5 429 The policy rule 5 has an identity of "weak-red-net stats". The 430 policy condition is: has a policy variable of "IP-ADDRESS-AS- 431 RESOLVED-BY-DNS", a policy variable of "Destination Address", and 432 a policy value of 192.169/16. The Policy actions associated with 433 Policy Rule 5 indicates a "SET" operator for the sending of 434 forwarding statistics on any data packet matching 192.169/16 435 prefix with exact match or longer match from designated 436 interfaces, and an ACTION of "notify I2RS Client" 438 Policy Rule 6 440 The policy rule 6 has an identity of "weak-red-net stats". The 441 policy condition is: has a policy variable of "IP-ADDRESS-AS- 442 RESOLVED-BY-DNS", a policy variable of "Destination Address", and 443 a policy value of 192.169.10/24. The Policy actions associated 444 with Policy Rule 6 indicates a "SET" operator for the sending of 445 forwarding statistics on any data packet matching 192.169/16 446 prefix with exact match or longer match from designated 447 interfaces, and an ACTION of "notify I2RS Client" 449 Read Policy List 451 The read policy list has the summary structure below. All Structures 452 underneath the filter policies can utilize template from the three 453 layer generic policy model found in 454 [I-D.hares-i2rs-info-model-policy]. Note that policy groups can be 455 included in policy groups. 457 read filter-policies 458 0...N | 459 policy set 460 |------------------------| 461 |---policy group [1-N] policy rules [1-N]-- status 462 |----| | | | | 463 | | | | 464 +-------+----+-------+ policy policy enabled/disable 465 | | | | condition Action mandatory/optional 466 Identity role priority precedence 467 | 468 +----------+ 469 | | 470 resource scope 471 (read / write) 472 (event) 474 Figure 5 - read filter policies 476 3.2. Remote Service Monitoring 478 scenario: 480 +---------------------+ 481 | APP or Controller | 482 +---------------------+ 483 | 484 | 485 +----------------+ 486 / Centralized \ 487 + Route server + 488 ---------------------- 489 | hub (F) | 490 | 192.50.128/24 *---------+ 491 +--*----*---*------*-+ | 492 | | | | | | 493 +--*--+ | +-*--+ +*----+ | 494 source 1---| A |---| C |--| E |---- | 495 \ /+--+--+ | +----+ +-----+ | 496 \ / | | | | 497 \/ | | | | 498 /\ +-----+ | +-----+*-----------+ 499 source 2 \ | B *-| | D | 500 \| |-----| |----- 501 +-----+ +-----+ 503 *- are BGP RR connections 504 |- are hub/spoke connects 505 spokes: A,B,C,D,E nodes 506 hub: F node 508 The second use case mentioned in [I-D.white-i2rs-use-case] is an 509 improvement of the hub and spoke overlay networks. Current hub and 510 spoke networks balance between information held in the spoke table 511 and optimized routing in the overlay, and mobility of nodes. Most 512 solutions in this space use some form of centralized route server 513 which keeps all routes (reachable destination and next hops), and has 514 a protocol by which the route-server and spoke devices communicate, 515 and caches at remote site. [I-D.white-i2rs-use-case] suggests that 516 I2RS can provide an alternative control plane by allowing remote 517 sites to register (or transmit through BGP) the reachable 518 destinations at each site, along with the router within the 519 forwarding path. 521 The [I-D.ji-i2rs-usecases-ccne-service] also provides a more detailed 522 discussion of the centralized control element that supports using 523 I2rs plus BGP Route-Reflectors (RR), I2RS plus MPLS-TE and PCE 524 (RFC4655), (both stateless and stateful [I-D.ietf-pce-stateful-pce]). 526 For both use cases, the read filtering allows the centralized server 527 to obtain notification of route changes (installed, active, who) and 528 next-hop resolution per [I-D.ietf-i2rs-rib-info-model] for a 529 particular range of addresses. In addition, interface failures will 530 impact the possible route calculated at the hub. A notification 531 stream watching interfaces and nexthop changes can be tailored to 532 watch the interfaces for the main traffic path and backup paths. 534 Example Read Filters 536 Across the "*--*" links the hub passes the I2RS and BGP protocol 537 packets. Also across these links passes the the traffic forwarded to 538 the hub, and then forward to the correct destination. 540 The route server sets policy group CCNE-2 to look for address changes 541 in forwarding pathway routes in address range 192.50.128/18(match or 542 longer), nexthop changes on 192.150.150/24, interface failures in 543 192.150.160/24, and failures for Route installs. Policy is name 544 CCNE-2. 546 Policy Group 548 The policy group has an identity of "CCNE-2", and a scope of 549 "read", role: "route-server", precedence of 2, priority of 1, and 550 security model of "secure TCP". 552 Policy Rule 1 554 The policy rule 1 has an identity of "hub-net". The policy 555 condition is: has a policy variable of "IP-ADDRESS-AS-RESOLVED-BY- 556 DNS", a policy variable of "Destination Address", and a policy 557 value of 192.50.128/18. The Policy actions associated with Policy 558 Rule 1 indicates a "SET" operator for any route matching 128 559 prefix with exact match or longer match, and an ACTION of "notify 560 I2RS Client" 562 Policy Rule 2 564 The policy rule 2 has an identity of "CCNE NextHops". The policy 565 condition is: has a policy variable of "IP-ADDRESS-AS-RESOLVED-BY- 566 DNS", a policy variable of "NextHop Address", and a policy value 567 of 192.168.150/24, and a SET Operator of "prefix-match", and an 568 ACTION of "notify I2RS Client". 570 Policy Rule 3 572 The policy rule 3 has an identity of "CCNE Interfaces". The 573 policy condition is: has a policy variable of "IP-ADDRESS-AS- 574 RESOLVED-BY-DNS", a policy variable of "interface address", and a 575 policy value of 192.150.150/24, and status = "down". The Policy 576 actions associated with policy rule 3 indicates a "SET" for match 577 or longer, and "ACTION" is "notify I2RS Client". 579 Policy Rule 4 581 The policy rule 4 has an identity of "CCNE Install Watch". The 582 policy condition is: has a policy variable of "IP-ADDRESS-AS- 583 RESOLVED-BY-DNS", a policy variable of "Routes", and a policy 584 value of 192.150.128/18, Notification Status is "Route Change 585 notification Return Code "No", and policy actions indicate "SET" 586 for match or longer, and "ACTION" is "notify I2RS Client". 588 The following additions to the RIB Info model are needed to support 589 this use case 591 o Notification for interface change 593 o Notification for Route change 595 o Notification for NextHop change 597 3.3. Within Data Center Routing 599 scenario: TBD 601 3.4. Temporary overlays between Data Centers 603 scenario: TBD 605 4. Read Filter Policy Information Model 607 This section specifies the network policy information model in 608 Routing Backus-Naur Form (RBNF, [RFC5511]). The policy definitions 609 utilize the generic information model for policy. The RBNF form 610 below is split into two parts: specific read filter policies, and a 611 reference section for the generic information model 612 ([I-D.hares-i2rs-info-model-policy]) 614 4.1. Read Filter Policies 616 ::= [] 617 ::=[] 619 4.2. Generic Informational Model Templates 621 This section provides the RBNF definitions from utilized from the 622 generic information model ([I-D.hares-i2rs-info-model-policy]). This 623 section is informational and will be removed once referencing issues 624 to the generic model have been resolved. 626 ::= 627 628 629 630 631 [] 632 [] 634 ::= 635 | 637 ::= 638 | 640 ::= <> 641 ... 643 ::= (...) 645 ::= 646 647 648 649 ( 650 (...) 651 652 [] 654 ::= ( []) | 655 ( []) 656 ( []) 658 ::= | 660 ::= | 662 ::= | 663 ... 664 ::= 665 (...) 666 [] 667 [] 669 ::= 670 | 671 | 672 | 674 ::= | 675 ... 676 ::= 677 678 679 680 [ ] 682 ::= | 683 ... 685 ::= (...) 686 ::= 687 688 689 690 ( 691 (...) 692 694 ::= ( []) | 695 ( []) 697 ::= | 699 ::= | 700 701 ... 703 ::= 704 (...) 705 [] 706 [] 708 ::= 709 | 710 | 711 | 713 ::= | 714 ... 715 ::= 716 717 718 [] 720 ::= | 721 ... 723 The elements of the Policy Group information model are as follows: 725 o Each policy group is captured in its own list, distinguished via a 726 identity, role, priority, precedence. 728 o A policy group has a certain role, such as resource or scope. A 729 policy group can even have multiple roles simultaneously. The 730 role, are captured in the list of "role" component. 732 o A policy role has a certain Scope, such as read scope or write= 733 scope. A policy group can even have multiple scope 734 simultaneously. The scope, or scopes, are captured in the list of 735 "scope" components. 737 o A policy has a certain priority, such as priority 0-255. A policy 738 can only have one priority. The priority is captured in the list 739 of "priority" component. 741 o A policy rule can inherit properties (e.g., 742 identity,role,priority, precedence) from policy group. A policy 743 rule also can have its own properties, e.g., enabled, mandatory, 744 usage. 746 o The policy group elements can be extended with policy-specific 747 components (policy-extensions, policy-group-extension 748 respectively). 750 The elements of the Network-Policy Rule information model are as 751 follows: 753 o A policy can in turn be part of a hierarchy of policies, building 754 on top of other policies. Each policy is captured in its own 755 level, distinguished via a policy-identity. 757 o Policy rule inherit scope from policy group. A policy role has a 758 certain Scope, such as read scope or write scope. A policy rule 759 can even have multiple scope simultaneously. The scope, or 760 scopes, are captured in the list of "scope" components. 762 o Furthermore, a policy rule contains conditions and actions, each 763 captured in their own list. 765 o A condition contains a variable and a value and use a match 766 operator, to connect variable with value. An examples of an 767 operator might be a" IP ADDRESS AS RESOLVED BYDNS" or "Set to a 768 member". Also, a condition can in turn map onto other condition 769 in an underlay policy. This is captured in list"supporting- 770 condition". 772 o An action contains a variable and a value. An action uses Set 773 operator to connect variable with value. Analogous to a node, an 774 action can in turn map onto other actions in an underlay policy. 775 This is captured in list "supporting-action". 777 o The policy, condition, action and operator elements can be 778 extended with policy-specific components (policy-extensions, 779 condition-extension, action-extension and operator-extension 780 respectively). 782 The local network-policy model extends the Network-Policy Rule 783 information model. The elements of the local network-policy model 784 are the local network-policy model as follows: 786 o A local policy rule can in turn be part of a hierarchy of 787 policies, building on top of other policies. Each local 788 configuration policy is captured in its own level, distinguished 789 via a policy identity. 791 o A local policy rule inherit scope from policy group. A local 792 policy rule has a certain Scope, such as read scope or write 793 scope. A local policy rule can even have multiple scope 794 simultaneously. The scope, or scopes, are captured in the list of 795 "scope" components. 797 o Furthermore, a local policy contains conditions and actions, each 798 captured in their own list. 800 o A condition contains a variable and a value and use a match 801 operator, to connect variable with value. An examples of an 802 operator might be a" IP ADDRESS AS RESOLVED BYDNS" or "Set to a 803 member". Also, a condition can in turn map onto other condition 804 in an underlay policy. This is captured in list "supporting- 805 condition". 807 o An action contains a variable and a value. An action uses Set 808 operator to connect variable with value. Analogous to a node, an 809 action can in turn map onto other actions in an underlay policy. 810 This is captured in list "supporting-action". 812 o The local policy, condition, action and operator elements can be 813 extended with policy-specific components (condition-extension, 814 action-extension and operator-extension respectively). 816 5. IANA Considerations 818 This draft includes no request to IANA. 820 6. Security Considerations 822 TBD. 824 7. Informative References 826 [I-D.hares-i2rs-info-model-policy] 827 Hares, S. and W. Wu, "An Information Model for Network 828 policy", draft-hares-i2rs-info-model-policy-00 (work in 829 progress), January 2014. 831 [I-D.ietf-i2rs-architecture] 832 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 833 Nadeau, "An Architecture for the Interface to the Routing 834 System", draft-ietf-i2rs-architecture-01 (work in 835 progress), February 2014. 837 [I-D.ietf-i2rs-rib-info-model] 838 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 839 Information Base Info Model", draft-ietf-i2rs-rib-info- 840 model-01 (work in progress), October 2013. 842 [I-D.ietf-pce-stateful-pce] 843 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 844 Extensions for Stateful PCE", draft-ietf-pce-stateful- 845 pce-07 (work in progress), October 2013. 847 [I-D.ji-i2rs-usecases-ccne-service] 848 Ji, X., Zhuang, S., and T. Huang, "I2RS Use Cases for 849 Control of Forwarding Path by Central Control Network 850 Element (CCNE)", draft-ji-i2rs-usecases-ccne-service-00 851 (work in progress), October 2013. 853 [I-D.keyupate-i2rs-bgp-usecases] 854 Patel, K., Fernando, R., Gredler, H., and S. Amante, "Use 855 Cases for an Interface to BGP Protocol", draft-keyupate- 856 i2rs-bgp-usecases-00 (work in progress), March 2013. 858 [I-D.keyupate-i2rs-bgp-usecases] 859 Patel, K., Fernando, R., Gredler, H., and S. Amante, "Use 860 Cases for an Interface to BGP Protocol", draft-keyupate- 861 i2rs-bgp-usecases-00 (work in progress), March 2013. 863 [I-D.white-i2rs-use-case] 864 White, R., Hares, S., and A. Retana, "Protocol Independent 865 Use Cases for an Interface to the Routing System", draft- 866 white-i2rs-use-case-01 (work in progress), August 2013. 868 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 869 Requirement Levels", BCP 14, RFC 2119, March 1997. 871 [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, 872 "Policy Core Information Model -- Version 1 873 Specification", RFC 3060, February 2001. 875 [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. 876 Moore, "Policy Quality of Service (QoS) Information 877 Model", RFC 3644, November 2003. 879 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 880 Element (PCE)-Based Architecture", RFC 4655, August 2006. 882 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 883 "Policy-Enabled Path Computation Framework", RFC 5394, 884 December 2008. 886 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 887 Used to Form Encoding Rules in Various Routing Protocol 888 Specifications", RFC 5511, April 2009. 890 Authors' Addresses 892 Susan Hares 893 Hickory Hill Consulting 894 7453 Hickory Hill 895 Saline, CA 48176 896 USA 898 Email: shares@ndzh.com 899 Qin Wu 900 Huawei 901 101 Software Avenue, Yuhua District 902 Nanjing, Jiangsu 210012 903 China 905 Email: sunseawq@huawei.com