idnits 2.17.1 draft-hareskini-i2rs-pbr-info-model-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 344 has weird spacing: '...uter-id uint3...' == Line 356 has weird spacing: '...icy-ref uint1...' == 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o If a router doesn't support policy based routing, a router MUST use RIB and MUST not use PBR RIB. -- The document date (October 27, 2014) is 3468 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) == Unused Reference: 'RFC2119' is defined on line 666, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-hares-i2rs-bnp-info-model-00 == 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 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). 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 S. Kini 5 Expires: April 30, 2015 Ericsson 6 A. Ghanwani 7 Dell 8 R. Krishnan 9 Brocade 10 Q. Wu 11 Huawei 12 D. Bogdanovic 13 Juniper Networks 14 October 27, 2014 16 An Information Model for Basic Network Policy 17 draft-hareskini-i2rs-pbr-info-model-00 19 Abstract 21 This document defines the I2RS Policy-Based Routing (PBR) policy 22 information model describing I2RS interactions with the PBR in a 23 routing system. The PBR IM uses Policy Core Information Model (PCIM) 24 framework (RFC3060, RFC3460, and RFC3644) to specify the ordered 25 route list within the PBR RIB adapted to I2RS. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 30, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 63 3. The Policy Based Routing Information Model Overview . . . . . 4 64 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. PBR-RIB module . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. PBR RIB . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.2. PBR Rule Component . . . . . . . . . . . . . . . . . . . 10 68 4.3. I2RS PRB RIB interaction with PBR RIB . . . . . . . . . . 12 69 5. Relationship between PBR Rule Model and RIB Information Model 13 70 6. Discussion of I2RS related issues . . . . . . . . . . . . . . 14 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 9. Informative References . . . . . . . . . . . . . . . . . . . 15 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 The Interface to the Routing System (I2RS) 79 [I-D.ietf-i2rs-architecture] architecture calls out for read and 80 write access to the information and state within the routing 81 elements. The I2RS client interacts with the I2RS agent in one or 82 more network routing systems. 84 This I2RS Policy-Based Routing (PBR) Information model defined in 85 this document describes the I2RS interaction with PBR within a 86 routing element. 88 The PBR requires an ordered list of policy. This PBR informational 89 model uses the Policy Core Information Model (PCIM) framework as 90 described in [RFC3060] with its extensions in [RFC3460] and QOS model 91 in [RFC3644]. The adaptation of the PCIM model to I2RS use is 92 described in [I-D.hares-i2rs-bnp-info-model]. 94 2. Definitions and Acronyms 96 CLI 98 Command Line Interface 100 IGP 102 IGP is an Interior Gateway Protocol 104 Information Model 106 is an abstract model of a conceptual domain, independent of a 107 specific implementations or data representation 109 MPLS 111 Multi-Protocol Label Switching. 113 NETCONF 115 The Network Configuration Protocol 117 PBR 119 Policy Based Routing. 121 PBR Default RIB 123 The PBR Default RIB is the default Routing Information Based use 124 based for forwarding traffic for routes which do not match any 125 PBR. 127 PBR-RIB 129 Policy Based Routing-Routing Information Base 131 PCIM 133 Policy Core Information Model directly and indirectly the work of 134 the PCIM Working Group. 136 Policy Rule 138 The PCIM framework defines a policy rule is often represented by 139 "if Condition then action". The action may have set, modify, or 140 notify actions. The [I-D.hares-i2rs-bnp-info-model] provides 141 examines of how ACLs, Prefix lists, and more complex BGP policy 142 can be combined into a policy rule. 144 Policy Group 146 The PCIM Framework defines policy groups as a group of policy 147 rules into ordered and prioritized groups of policy. 149 Policy Set 151 The PCIM framework defines a the Policy set (specifically the 152 PolicySetComponent) as an aggregation class that allows 153 aggregation of Policy Groups and the nesting of Policy Groups 154 under Policy set rules. The PolicySet rules include nesting 155 policies and matching strategies (all-matching or first-match), 156 priorities between rules, and roles. One of the roles that must 157 be conditionally matched is the models denotation of "read-only" 158 or "read-write" policy rules into ordered and prioritized groups 159 of policy. The [I-D.hares-i2rs-bnp-info-model] suggests that non- 160 nested policy groups may be sufficient for initial I2RS and 161 configuration work. 163 RIB IM 165 RIB Informational Model (RIB IM) [I-D.ietf-i2rs-rib-info-model] 167 Routing instance 169 Routing Code often has the ability to spin up multiple copies of 170 itself into virtual machines. Each Routing code instance or each 171 protocol instance is denoted as N_INSTANCE in the text below. 173 SNMP 175 The Simple Network Management Protocol 177 3. The Policy Based Routing Information Model Overview 179 Policy Based Routing (PBR) is a widely used term in the industry to 180 describe a a technique used to make packet forwarding decisions 181 decisions based on policies set by the network administrator. PBR 182 enables network administrator to forward the packet based on other 183 criteria than the destination address in the packet, which is used to 184 lookup an entry in the routing table. 186 The PBR problem can be viewed as a resource allocation problem that 187 incorporates business decision with routing. PBR may be used to 188 provide many benefits, including better resource allocation, load 189 balancing and QoS. 191 Routing decisions in PBR are based on several criteria beyond 192 destination address, such as application, IP protocol used, identity 193 of the end system, and even packet size. Policy actions are 194 typically applied before applying QoS constraints since policy 195 actions may overrides QoS constraint. 197 The I2RS use cases which benefit from PBR are: Protocol independent 198 Use cases and large flow use cases described in 199 [I-D.hares-i2rs-usecase-reqs-summary] 201 The PBR policies are specified in most routers/switches as an ordered 202 set of rules. Each policy rule has a set of match conditions, and a 203 set of actions which may include forwarding actions and QoS actions. 204 Since policy rules, groups of policy, and ordered sets of policy are 205 used in other protocols (BGP or MPLS), these policy rules have been 206 abstracted into a basic network policy instantiation of the PCIM 207 ([RFC3060], [RFC3460], and [RFC3644]). This instantiation include in 208 the ordered policy rule the references to other policy match-action 209 conditions such as the ACLs ([I-D.bogdanovic-netmod-acl-model]), and 210 Prefix list ([I-D.zhdankin-netmod-bgp-cfg]). 212 3.1. Scope 214 A PBR IM can be considered in either a top-down view examining the 215 policy which controls the data flow or from a bottom-up view which 216 considers the data plane. A top-down view considers how policies 217 control protocols (BGP or IGPs (ISIS/OSPF)) transfer of routes to 218 determine how data flows. The bottoms-up view considers the 219 forwarding data planes that must be supported. In this view,the 220 match filters must consider IP [both IPv4 and IPv6], but may also 221 consider MPLS and encapsulated protocols such as TCP [RFC0793], UDP 222 [RFC0768], STCP [RFC4960], ICMP [RFC0792]. This draft takes the 223 bottoms-up viewpoint which looks at how the PBR RIB controls the data 224 plane. 226 This draft considers match and action filters for the data-planes 227 using IP (both IPv4 [RFC0791] and IPV6 [RFC2460]). 229 4. PBR-RIB module 231 A PBR-RIB is an entity that contains an ordered set of policy routes 232 and is analogous to a RIB defined in [I-D.ietf-i2rs-rib-info-model]. 233 An ordered set of policy routes implies that the insertion into a 234 PBR-RIB must allow for inserting of a PBR route at any specific 235 position and deleting a route at a specific position. The ability to 236 change a policy rule at a specific position combines these two 237 functions (deleting an existing policy rule and adding a new policy 238 rule). 240 Each PBR-RIB is contained within a routing instance, but one routing 241 instance (named by an INSTANCE_NAME) can contain multiple PBR RIBs. 242 Each routing instance is associated with a set of interfaces, a 243 router-id a PBR default-RIB, and list of PBR-RIBs. Only some of the 244 interfaces associated with a routing instance may be associated with 245 a PBR-RIB. Each interface can be associated with at most one PBR 246 RIB. 248 Packets arriving on an interface associated with a PBR-RIB will be 249 forwarded based on a PBR-RIB in the list or PBR Default RIB (if no 250 matches occur). The policy processing within the PBR process within 251 the routing system is expected to do the following: 253 o When a packet successfully matches a PBR Match term/entry, the 254 corresponding policy-actions are applied. 256 o If a packet does not match a PBR match term/entry, the PBR 257 processing, goes to the next term/entry in the order, and looks 258 for a match, within the current filter or goes to the next filter 259 in the list. This continues until either a PBR match term/entry 260 is successfully matched, or no more filters in the list exists. 262 o If no match has been found within the PBR filter list, then the 263 packet will be forwarded using the PBR Default-RIB if one exists. 264 If no PBR Default-RIB is specified, the packet will be discarded. 266 +-------------------------------+ 267 | routing instance | 268 +--|--------|---------------+---+ 269 * | | 270 | | | 271 +-----------+ +-------------+ +-----------+ 272 |interface* | |PBR_RIB *list| |PBR-Default| 273 | list | | | |-RIB | 274 +-----------+ +--|----------+ +---|-------+ 275 | RIB (RIB-info IM) 276 ^ 277 /|\ 278 +-----------^-----------+ 279 | PBR RIB* list | 280 +-----------|-----------+ 281 | 282 +-----------------------+ 283 | BNP Policy Set | [Note: This layer 284 | | can be skipped if 285 |(nested ordered policy | groups are not nested.] 286 | from RFC3466) | 287 +----------|------------+ 288 | 289 +-----------------------+ 290 | BNP-Policy-Group* | 291 | | 292 |(list of ordered groups| 293 | RFC3466 policy group | 294 | augmented with I2RS | 295 | scope) | 296 +-----------|-----------+ 297 | 298 +-----------------------+ 299 | BNP-Policy-Rule* | 300 | | 301 | (ordered list of | 302 | RFC3466 policy rules) | 303 | augmented with | 304 | policy-order, status, | 305 | and refcnt) with ACL | 306 | and other condition- | 307 | action matches | 308 +-----------------------+ 310 Figure 1: Routing instance with PBR RIB 312 The PBR entries associated with each PBR in a routing instance are: 314 pbr-instance-name 316 Name of Routing instance 318 pbr-router-id 320 router id associated with the PBR function of the Routing instance 322 Interface_list 324 A list of interfaces that all of the PBR RIBs operate over. This 325 list must be a subset of the interface_list associated with the 326 routing instance. 328 PBR Default RIB 330 A RIB contained in the same routing instance that can be used to 331 forward packets when the FIB entries in the PBR-RIB list do not 332 match the packets. The PBR Default-RIB forwards based on 333 destination based routing. 335 PBR-RIB* list 337 list of PBR-RIBs 339 The Top-level Yang structure for the PBR RIB is: 341 module: PBR 342 +--PRB-RIB-module 343 +--rw pbr-instance-name 344 +--rw pbr-router-id uint32 345 +--rw pbr-interface* 346 | +--rw pbr-interface interface-ref-id 347 +--rw PBR-Default-RIB 348 +--rw PBR-RIB 349 +--rw PBR-RIB-Name 350 +--rw PBR-RIB-AFI 351 +--rw PBR-RIB-intf* 352 +--rw PBR-status-info 353 | +--rw pbr-update-ref uint64 354 +--rw PBR-Ordered-Route-Policy 355 +--rw pbr-group-policy* [group-policy-ref] 356 | +--rw group-policy-ref uint16 357 | +--rw group-policy-name string 358 | +--ro group-policy-status-info 359 | | +--ro group-policy-status 360 | | +--ro group-policy-inactive-reason 361 | +--rw policy-rule* [policy-rule-ref] 362 | +--rw policy-rule-ref 363 | +--ro policy-rule-status-info 364 | | +--ro policy-rule-status enumeration 365 | | +--ro policy-rule-inactive-reason 366 | +--rw pbr-match-filter* [nr-policy-match] 367 | +--rw pbr-match-term 368 | | +--rw pbr-match-condition 369 | | | +--rw nr-policy-match 370 | | | +--rw pbr-ipv4-matches 371 | | | +--rw pbr-ipv6-matche 372 | | | +--rw pbr-transport-matches 373 | | | +--rw pbr-combo-operator 374 | | +--rw pbr-rule-action 375 | | +--rw pbr-QOS-acts [nbr-act] 376 | | +--rw npbr-act 377 | | +--rw set-in-ipv4-packet 378 | | | ... 379 | | +--rw set-in-ipv6-packet 380 | | | ... 381 | | +--rw set-vendor 382 | | | . . . 383 | +--rw pbr-forwarding-actions 384 | | +--rw pbr-std-fwd enumeration 385 | | +--rw pbr-vendor-fw enumeration 386 +--rw pbr-policy-set[policy-set-name] 387 +--rw policy-set-name 388 + . . . 390 Figure 2: PBR RIB Yang Structure 392 4.1. PBR RIB 394 Each PBR RIB has the following: 396 o PBR-RIB-Name - Name identifier for PBR RIB 398 o PBR-RIB-AFI - AFI Supported by the PBR RIB 400 o PBR-RIB-intf* - Interface PBR operates on. Note that an interface 401 can be associated with at most one PBR RIB. For example 402 interfaces eth1 and eth2 can be associated to PBR_RIB, but these 403 two interfaces cannot be connected to any other PBR RIB. 405 o PBR-Status-info - status at PBR RIB level which includes number of 406 times since reconfiguration this PBR has been updated. 408 o PBR-Ordered-Route-Policy contains two sub-elements: 410 * pbr-group-policy - group policy list indexed by group-policy- 411 ref number. Policy group contains a reference number (group- 412 policy-ref), name, status-info, and a list of policy-rules. the 413 group policy status can be one of the following: installed, 414 active, inactive, I2RS-active, and I2RS-inactive). The 415 inactive reason can be one of the following: null, poicy- 416 conflict, i2rs-supersedes, unsupported). 418 * pbr-policy-set - policy set identified by name 420 Initially, it is expected the simply group policy list will be 421 sufficient. (See [I-D.hares-i2rs-bnp-info-model] for an examples of 422 the policy rules can contain ACL policy, Prefix-list policy, and more 423 complex (match/set) policy.) 425 4.2. PBR Rule Component 427 A PBR policy rule used by has the following general architecture. 429 +-----------------------+ 430 | Policy Rule | 431 | (PBR usage) | 432 +--|-----------------|--+ 433 : : ....... 434 : : : : 435 +--------V-------+ +-------V-------+ : 436 | PBR Condition | | PBR Action |<... 437 +----------------+ +-+----------+--+ 438 /|\ /|\ 439 "extends"| | "extends" 440 +---+ +--------+ 441 | | 442 +-------^-------+ +-----^---------+ 443 | QoS Action | |Forward Action | 444 +---------------+ +---------------+ 445 : : : : : : 446 ....: : :..... .....: : :..... 447 : : : : : : 448 +----V---+ +---V----+ +--V---+ +-V------++--V-----++--V-----+ 449 |Set | |QoS | |QoS | |Forward ||Next Hop||Next Hop| 450 |Operator| |Variable| |Value | |Operator||Variable||Value | 451 +--------+ +--------+ +------+ +--------++--+-----++--------+ 452 /|\ 453 | "extends" 454 +---^----+ 455 |Next Hop| 456 |Type | 457 +--------+ 458 Figure 3: Policy Rules for PBR routing 460 The policy-rule contains the following: 462 o PBR-match-filter - ordered PBR match field for a route entry which 463 contains either: 465 * nr-policy-match - order number in match sequence 467 * pbr-ipv4-matches - one or more matches of IPv4 source address, 468 IPv4 destination address, IPv4 Protocol, IPv4 TOS/DSCP field, 469 IPv4 ICMP field, and the length of the packet. These matches 470 can be exact matches, longest prefix matches for addresses, or 471 range matches for values in TOS/DSCP field, ICMP field or 472 length of packet. 474 * pbr-iv6-matches - one or more match of IPv6 source address, 475 IPv6 destination address, IPvs Traffic class (DSCP), IPv6 Flow 476 label, IPv6 payload length, IPv6 next-header, hop-limit. These 477 matches can be exact matches, longest prefix matches for 478 addresses, or range matches. 480 * pbr-transport-matches - one or more matches in source port or 481 destination port 483 * pbr-combo-operator - logical OR or logical AND that combine 484 matches in one match filter. 486 o pbr-rule-action* - An ordered list of policy actions that includes 487 the following: 489 * npbr-acts - order number in action sequence 491 * Actions: set values in one or more of the following: 493 + IPv4 packets in IPv4 source address, IPv4 destination 494 address, IPv4 Protocol, IPv4 TOS/DSCP field, IPv4 ICMP field 495 or the length of the packet. (Please note that hardware 496 data plane forwarders may only be able to set TOS/DSCP while 497 software data plane forwarders may be able set additional 498 fields.) 500 + IPv6 packets in IPv6 source address, IPv6 destination 501 address, IPv6 Protocol value, IPv6 Flow, or IPv6 packet 502 length. 504 * pbr-forwarding-actions - which includes 506 + pbr-std-forwarding - (enumeration) forwarding packet 508 - Drop_Packet - drop packet 510 - Drop_Packet_ICMP - dropping packet with ICMP unreachable 511 sent 513 - Forward_Packet_specific - send to specific next hop 515 - Forward_Packet_default - forward based on PBR Default RIB 517 + pbr-vendor-fwd - Vendor specific action 519 4.3. I2RS PRB RIB interaction with PBR RIB 521 The I2RS client-agent pair PBR process within a routing process to 522 add ephemeral these changes to the PBR State so that 524 PBR-running = PBR-config + PBR-I2RS-ephemeral 525 The I2RS ephemeral state will not survive a reboot of the machine. 526 Upon a reboot, the I2RS client must reload the I2RS Agent with the 527 I2RS PBR RIB state lost in the reboot. 529 The PBR RIB module must allow both the I2RS client-agent to to read 530 the PBR IM as as query or as a notification stream. The pbr-update- 531 ref parameter of the PBR-status-info provides an update count for the 532 PBR configuration to indicate if the PBR has been updated with 533 additions or deletions of the PBR policy rules. This provides the 534 I2RS interface a quick way to check for changes by other entities to 535 the PBR route list. 537 5. Relationship between PBR Rule Model and RIB Information Model 539 The RIB in a router with I2RS is the following: 541 running RIB = configured-RIB + routes-installed-from-protocols + 542 I2RS-ephemeral-state 544 As described in [I-D.ietf-i2rs-rib-info-model], the I2RS ephemeral 545 RIB information in routing instance contains a collection of RIBs, 546 interfaces, and routing parameters including the following: 548 o The set of interfaces indicates which interfaces are associated 549 with this routing instance. 551 o The RIBs specify how incoming traffic is to be forwarded based on 552 destination (E.g. RIB and PBR-RIB). 554 o The routing parameters control the information in the RIBs. 556 PBR RIB and RIB can not be used at the same time, which means: 558 o If a router doesn't support policy based routing, a router MUST 559 use RIB and MUST not use PBR RIB. 561 o If a router supports policy based routing: 563 * PBR-RIB is used 565 * Multiple PBR-RIBs may exist within a routing instance 567 * An interface can be associated with at most one PBR-RIB 569 * The PBR Default RIB is used if several criteria beyond 570 destination address is not matched. 572 6. Discussion of I2RS related issues 574 This section record the issues with the initials of the person who 575 recorded it. 577 Forwarding per interface (JMH) 579 - The authors believe the forwarding per interface is covered by 580 the attachment of a PBR to interface-list. 582 Centralized or Distributed Policy Strategy (JMH) 584 The authors believe this structure can be used by either 585 centralized or distributed forwarding for configuration or the 586 I2RS ephemeral datastpre. 588 policy database-enforcement points architecture (JMH) 590 The authors believe this yang modules describes the PBR which 591 provides a specific enforcement of forwarding policy. The wider 592 constraints of how policy groups are stored, administered or 593 distributed should be engaged at a higher layer. The authors note 594 the Policy-Group project in OpenDaylight has an architecture for 595 policy enforcement that renders the results to a particular 596 instantiation in nodes. One such instantiation could be the I2RS 597 policy. 599 policy rule conflicts (JMH) 601 Detection of policy rule conflicts are done by the policy module 602 receiving the configuration or ephemeral I2RS stream. The policy 603 can be reject or installed and rejected from active use due to 604 conflicts at either the policy group level or the policy rule 605 level. At the policy group level the group-policy-status-info 606 contains a status of installed, active, or installed-inactive. If 607 the status is inactive the group-policy-inactive-reason can 608 indicate policy-conflicts. The policy-rule has a similar status 609 (policy-rule-status-info with policy-rule-status and policy-rule- 610 inactive-reason). 612 7. IANA Considerations 614 This draft includes no request to IANA. 616 8. Security Considerations 618 TBD. 620 9. Informative References 622 [I-D.bogdanovic-netmod-acl-model] 623 Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair, 624 "Network Access Control List (ACL) YANG Data Model", 625 draft-bogdanovic-netmod-acl-model-02 (work in progress), 626 October 2014. 628 [I-D.hares-i2rs-bnp-info-model] 629 Hares, S. and Q. Wu, "An Information Model for Basic 630 Network Policy", draft-hares-i2rs-bnp-info-model-00 (work 631 in progress), September 2014. 633 [I-D.hares-i2rs-usecase-reqs-summary] 634 Hares, S., "Summary of I2RS Use Case Requirements", draft- 635 hares-i2rs-usecase-reqs-summary-00 (work in progress), 636 July 2014. 638 [I-D.ietf-i2rs-architecture] 639 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 640 Nadeau, "An Architecture for the Interface to the Routing 641 System", draft-ietf-i2rs-architecture-05 (work in 642 progress), July 2014. 644 [I-D.ietf-i2rs-rib-info-model] 645 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 646 Information Base Info Model", draft-ietf-i2rs-rib-info- 647 model-03 (work in progress), May 2014. 649 [I-D.zhdankin-netmod-bgp-cfg] 650 Alex, A., Patel, K., and A. Clemm, "Yang Data Model for 651 BGP Protocol", draft-zhdankin-netmod-bgp-cfg-01 (work in 652 progress), October 2014. 654 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 655 August 1980. 657 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 658 1981. 660 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 661 RFC 792, September 1981. 663 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 664 793, September 1981. 666 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 667 Requirement Levels", BCP 14, RFC 2119, March 1997. 669 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 670 (IPv6) Specification", RFC 2460, December 1998. 672 [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, 673 "Policy Core Information Model -- Version 1 674 Specification", RFC 3060, February 2001. 676 [RFC3460] Moore, B., "Policy Core Information Model (PCIM) 677 Extensions", RFC 3460, January 2003. 679 [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. 680 Moore, "Policy Quality of Service (QoS) Information 681 Model", RFC 3644, November 2003. 683 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 684 4960, September 2007. 686 Authors' Addresses 688 Susan Hares 689 Huawei 690 7453 Hickory Hill 691 Saline, MI 48176 692 USA 694 Email: shares@ndzh.com 696 Sriganesh 697 Ericsson 699 Email: sriganesh.kini@ericsson.com 701 Anoop Ghanwani 702 Dell 704 Email: anoop@alumni.duke.edu 705 Ram Krishnan 706 Brocade 708 Email: ramk@Brocade.com 710 Qin Wu 711 Huawei 712 Beijing 713 China 715 Email: Bill.Wu@huawei.com 717 Dean Bogdanovic 718 Juniper Networks 719 Westford, MA 721 Email: deanb@juniper.net