idnits 2.17.00 (12 Aug 2021) /tmp/idnits35571/draft-camwinget-i2rs-pubsub-sec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 507: '...s and the Message Broker, is REQUIRED....' RFC 2119 keyword, line 508: '...e Message Broker MUST be established a...' RFC 2119 keyword, line 517: '...EQ3: A Publisher SHOULD define the sec...' RFC 2119 keyword, line 519: '...stance). Its transport SHOULD provide...' RFC 2119 keyword, line 520: '...fidentiality and MUST provide message ...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2013) is 3229 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.keyupate-i2rs-bgp-usecases' is mentioned on line 391, but not defined == Outdated reference: A later version (-01) exists of draft-amante-i2rs-topology-use-cases-00 == Outdated reference: A later version (-02) exists of draft-atlas-i2rs-problem-statement-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force K. Beck 3 Internet-Draft N. Cam-Winget 4 Intended status: Informational D. McGrew 5 Expires: January 12, 2014 Cisco Systems 6 July 11, 2013 8 Using the Publish-Subscribe Model in the Interface to the Routing System 9 draft-camwinget-i2rs-pubsub-sec-00 11 Abstract 13 In the Publish-Subscribe model, subscribers express their interest in 14 an event, or a pattern of events, and are subsequently notified of 15 any event generated by a publisher that matches their registered 16 interest. The model is well suited for communication in large-scale 17 and loosely coupled distributed systems. This document describes how 18 the model fits into Interface to the Routing System (I2RS) and 19 Software Defined Networking (SDN) architectures, and analyzes its 20 advantages, its security requirements, and its use in providing 21 security within I2RS. 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 January 12, 2014. 40 Copyright Notice 42 Copyright (c) 2013 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 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Publish-Subscribe Models . . . . . . . . . . . . . . . . . . . 4 71 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. An I2RS Publish-Subscribe Model . . . . . . . . . . . . . . . 5 73 3.1. Role of the Message Broker . . . . . . . . . . . . . . . . 6 74 4. Proposed Taxonomy based on Use Cases . . . . . . . . . . . . . 6 75 5. Security Requirements . . . . . . . . . . . . . . . . . . . . 11 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 84 1. Introduction 86 This document describes the use of a publish-subscribe (or pub-sub) 87 model to facilitate communication and authorized access for the 88 different types of programmatic interfaces and types of applications 89 that may be available in the I2RS and SDN architectures. It also 90 analyzes the advantages in both scalability and security in its use 91 within I2RS. The security requirements of a pub-sub system are given 92 special attention, to ensure that the system meets the requirements 93 when it is used to provide security. 95 2. Publish-Subscribe Models 97 There are two classical publish-subscribe models: topic- or content- 98 based [manyfaces][pub.sub.evolution]. In a topic-based model, 99 information is exchanged through a set of predefined "topics" or 100 subjects; where a publisher is responsible for defining the classes 101 of information to which a subscriber registers. In a content-based 102 model, information is only shared to a subscriber if the specific 103 information matches the subscriber's criteria. 105 In some important scenarios, a publish-subscribe model has 106 significant advantages over a client-server model. When a source 107 generates data intermittently, a client-server model can be used by 108 having the client poll the server. But this method suffers from 109 overhead in both processing and bandwidth, and it introduces a 110 latency between the time the data is generated at the source, and the 111 time that it is transported to the client. In contrast, a publish- 112 subscribe model avoids the extra processing, bandwidth, and latency 113 by establishing a channel by which the source asynchronously 114 communicates its data. 116 2.1. Terminology 118 o Publisher: defines an entry point or handle by which a protocol or 119 programmatic interface and its capabilities such as its time 120 delivery capabilities, protocol transport and security properties 121 can be used. 123 o Subscriber: defines an interested routing element or application 124 requiring access to a protocol or programmatic interface. 126 o Message Broker (MB): the authorization agent and broker used to 127 manage the supported protocols and interfaces inclusive of their 128 (access and transport) capabilities and manages the authorization 129 of subscribers. 131 3. An I2RS Publish-Subscribe Model 133 Use cases and framework architectures for I2RS and SDN define the 134 need for interfaces for acquiring information about the routing 135 system as well as manipulating and controlling the topology and 136 behavior of such routing system. The uses cases and frameworks 137 described in [I-D.amante-i2rs-topology-use-cases] and 138 [I-D.ward-i2rs-framework], respectively, describe the need for 139 interfaces with varying capabilities. The characteristics of these 140 capabilities include: 142 o Time delivery sensitivity: interfaces or operations to be executed 143 in the I2RS may come with different time constraints. Per section 144 3.5 of [I-D.ward-i2rs-framework], it is necessary in some cases to 145 define when an operation is to be handled. In particular, there 146 are operations that initially require synchronization of state. 148 o Support for multiple protocols or implementation layers: it is 149 expected that there would be more than a single mechanism defined 150 to acquire, manipulate and control the routing system. 152 o Secure, authorized communications: as the application(s) control 153 the behavior of the routing system, the application must be 154 authorized to manipulate and control the routing system, and that 155 system must check that the application has the appropriate 156 authorizations. 158 o Support for a range of data delivery content: especially in 159 interfaces where information (such as topology data or security 160 monitoring or auditing data) is being conveyed, the size or amount 161 of data to be transmitted can be very large. Conversely, 162 interfaces that control routing may transmit very short packets. 164 Given the different characteristics and presence of multi-protocol 165 support, a publish-subscribe model can be used as a means to 166 facilitate secure authorized communications. Publishers can define 167 the characteristics and capabilities supported by the particular 168 interface through the message broker from which subscribers can 169 register. Furthermore, as suggested by 170 [I-D.amante-i2rs-topology-use-cases] and 171 [I-D.atlas-i2rs-policy-framework], a "Policy manager" or "Policy 172 Framework" is needed to ensure authorized communications. The 173 message broker of a publish-subscribe model can behave as the 174 authorizing agent and determine if a subscriber is authorized to 175 register to specific subscriptions. Similarly, the message broker 176 can also decide whether a publisher is authorized to provide the 177 protocols and interfaces it is attempting to publish. 179 The use of the publish-subscribe pattern handles scalability issues 180 especially given the many to many relationships. It is expected that 181 an application will establish connections to more than one interface; 182 similarly, an interface will be communicating with many applications. 183 Given the many to many expected communications, the need to manage 184 the connections and its security properties can be diminished through 185 the use of the publish-subscribe model. The publish-subscribe model 186 reduces the number of relationships to [P+S] (where P are the number 187 of publishers and S are the number of subscribers) versus the 188 potential for having to manage P*S relationships. 190 3.1. Role of the Message Broker 192 In using the publish-subscribe model, there is a Message Broker that 193 mediates between the publishers and subscribers. The Message Broker 194 as the intermediary, allows publishers to post their information 195 while allowing subscribers to register to the types of information it 196 wants to receive. As the intermediary, the Message Broker can also 197 provide filtering capabilities to allow for a publisher to post its 198 information once but filter according to what subscribers may be 199 interested or is authorized to receive in a subset of what a 200 publisher may post. 202 In the I2RS and Software Defined Networking (SDN) use case, the 203 Message Broker (MB) can establish the authorizations of both 204 publishers and subscribers. When a publisher registers with the MB, 205 the publisher and MB authenticate each other and the MB authorizes 206 the publisher as being authoritative for a particular topic (or if 207 the MB is not authorized, its registration is rejected). When a 208 subscriber registers with the MB, the subscriber and MB authenticate, 209 and the MB authorizes the subscriber to receive the topic (or its 210 registration is rejected). 212 4. Proposed Taxonomy based on Use Cases 214 Suggested architectures of the I2RS system contains I2RS Clients 215 [I-D.amante-i2rs-topology-use-cases] 216 [I-D.atlas-i2rs-problem-statement] (also called Commissioners 217 [I-D.atlas-i2rs-policy-framework]) at the application level, I2RS 218 Agents at the network level with the I2RS protocol as the interface 219 between the two. The specific details and nature of the Clients or 220 Commissioners and Agents require more investigation. This discussion 221 assumes little about them and focuses on the I2RS Protocol and how 222 the publish-subscribe model can address many of the stated 223 requirements and use cases, and bring additional benefits such as 224 scalability and security. 226 A suggestive network architecture diagram from [I-D.atlas-i2rs- 227 problem-statement] below: 229 +***************+ +***************+ +***************+ 230 * Application * * Application * * Application * 231 +***************+ +***************+ +***************+ 232 ^ ^ ^ 233 * * * 234 * * **************** 235 * * * 236 v v v 237 +---------------+ +---------------+ 238 | I2RS Client | | I2RS Client | 239 +--------------+ +---------------+ 240 ^ ^ 241 |________________ | 242 | | <== I2RS Protocol 243 | | 244 ...........................|..|.................................. 245 . v v . 246 . +*************+ +---------------+ +****************+ . 247 . * Policy * | | * Routing & * . 248 . * Database *<***>| I2RS Agent |<****>* Signaling * . 249 . +*************+ | | * Protocols * . 250 . +---------------+ +****************+ . 251 . ^ ^ ^ ^ . 252 . +*************+ * * * * . 253 . * Topology * * * * * . 254 . * Database *<*******+ * * v . 255 . +*************+ * * +****************+ . 256 . * +********>* RIB Manager * . 257 . * +****************+ . 258 . * ^ . 259 . v * . 260 . +*******************+ * . 261 . * Subscription & * * . 262 . * Configuration * v . 263 . * Templates for * +****************+ . 264 . * Measurements, * * FIB Manager * . 265 . * Events, QoS, etc. * * & Data Plane * . 266 . +*******************+ +****************+ . 267 ................................................................. 269 <--> interfaces inside the scope of I2RS 270 +--+ objects inside the scope of I2RS 272 <**> interfaces NOT within the scope of I2RS 273 +**+ objects NOT within the scope of I2RS 275 .... boundary of a router participating in the I2RS 276 I2RS Architectural Model 278 The I2RS Agent communicates with the network platform on which it 279 resides presumably largely with a platform specific interface, i.e. 280 CLI or REST, and with existing protocols where appropriate. There 281 are opportunities to facilitate the publish-subscribe model within 282 the network platform also. Here the applicability would most likely 283 be to new areas of functionality where no existing broadly adopted 284 standards are used; additionally where such existing standards might 285 be extended by adoption of publish-subscribe . It is unlikely the 286 standards themselves would be modified but rather publish-subscribed 287 might be layered on top to better facilitate sharing of state 288 maintained by such standards. 290 As suggested, the standards used would be publish-subscribed as a new 291 layer to improve the overall system scalability and facilitate 292 operations such as: 294 o Discovery: to address the many versions of interfaces and 295 protocols supported, a discovery mechanism may be introduced by 296 which I2RS Agents register as publishers or subscribers. As a 297 publisher, an interface, schema or protocol may be "advertised" 298 with its capabilities such as the supported versions, security and 299 data transport properties. 301 o Security: it is imperative that I2RS Agents be authenticated and 302 authorized to employ the different interfaces and protocols. To 303 address the many-to-many relationships, the use of a publish- 304 subscribe model as a new layer on top helps address the security 305 requirements in a scalable manner as well. 307 Taxonomy is still being developed for I2RS and there is inconsistent 308 terminology being used to date. The terminology used here and its 309 relationship to terminologies of others is as follows: 311 Application 313 I2RS application that uses the I2RS interface to interact with 314 the routing system. This may include a Client which actually 315 implements the application side of the I2RS interface. This 316 has also been called the Commissioner. 318 Router 320 The network element that supports the I2RS interface acts as a 321 northbound API. This may include an I2RS Agent or Server. 323 Areas where publish-subscribe can be deployed to satisfy stated 324 requirements and use cases: 326 Asynchronous Router to application notifications 328 In the publish-subscribe model, routers register as 329 publishers of notifications and applications interested in 330 receiving notifications register as subscribers. The I2RS 331 Agent in the router need only publish a notification to 332 publish-subscribe and is unburdened from maintaining which, 333 if any, application is interested in the notification. 334 Similarly, the application need only express interest in 335 receiving notifications and is unburdened from monitoring 336 about routers. The publish-subscribe mechanism handles the 337 asynchronous notification connecting router notifications 338 with interested applications. Note that an application can 339 also act as a publisher and an I2RS agent can act as a 340 subscriber. 342 Many to Many 344 [I-D.amante-i2rs-topology-use-cases] and 345 [I-D.ward-i2rs-framework] both discuss the need for the I2RS 346 interface to support multiple applications interfacing with 347 multiple routers and the required capability of each 348 application to be made aware of changes made by another. 349 With publish-subscribe routers register to publish change 350 notifications, applications register to receive change 351 notifications and the publish-subscribe mechanism handles 352 the change notifications connecting router notifications 353 with interested applications. 355 Topology 357 [I-D.amante-i2rs-topology-use-cases] and 358 [I-D.ward-i2rs-framework] discuss the requirement for 359 applications to monitor network topology and changes to the 360 topology whether made by devices appearing or disappearing 361 due device reboot or failure, modifications by other 362 applications or by some other autonomic mechanism and the 363 limitations of existing protocols to satisfy this 364 requirement. Here, device agents, applications and other 365 entities modifying topology would register as publishers of 366 topology info, with publish-subscribe handling distributing 367 change notifications to interested applications. This 368 particular use case highlights the need for an initial 369 synchronization to enable a subscriber to learn the current 370 network topology as well as an asynchronous method to learn 371 the changes and updates to that topology as they occur. 373 RIB Updates 375 [I-D.ward-i2rs-framework] and others describe the need for 376 router RIB updates to be available to I2RS applications. 377 This is another case where routers can register as 378 publishers of RIB changes with publish-subscribe handling 379 the distribution of these changes to interested 380 applications. 382 Policy Management 384 [I-D.atlas-i2rs-policy-framework] discusses the need for 385 applications to monitor policy changes, including those made 386 by other applications. This would be a subset of the Many 387 to Many publish-subscribe case. 389 Other cases which it is clear would be well handled by publish- 390 subscribed include Events and Configuration Changes. Use cases from 391 [I-D.keyupate-i2rs-bgp-usecases] would include: 393 BGP Error Notifications. Notification of Routing Events. 395 BGP Protocol Statistics. Routing agents could publish BGP errors, 396 other BGP events and BGP statistics on the router. 398 Tracing Dropped BGP Routes. Routers can publish learning of BGP 399 routes which would enable applications the monitor the propagation 400 of routes through the AS. 402 5. Security Requirements 404 This section describes security requirements as needed to sustain an 405 I2RS or SDN. These requirements are based on the use cases defining 406 the need for multiple protocol (using multiple layers) that need to 407 act at different time sensitivities. It is expected that 408 applications will need to gain appropriate authorization to use one 409 or more of these protocols within an I2RS or SDN. 411 In access control models, it is common to describe access control on 412 data in terms of the entities that are permitted to read that data, 413 and the entities that are permitted to write that data. These models 414 naturally apply to a publish-subscribe model: a subscriber to a topic 415 is authorized to read data on that topic, and a publisher is 416 authorized to write data on it. In a pub-sub model, there may be 417 many subscribers to a topic, and there may be more than one publisher 418 on a topic as well. 420 Published data requires the following protections, which are stated 421 in terms of a specific topic: 423 Authentication: it must not be possible for any entity other than 424 the publisher to create a message that a subscriber will accept as 425 authentic. It must not be possible for one subscriber to create 426 messages that are accepted by the other subscribers to the same 427 topic. When there are multiple publishers on a particular topic, 428 it must be possible for the subscribers to authenticate the actual 429 publisher of each message. 431 Anti-replay: if a subscriber receives the same exact message twice 432 (e.g. because an attacker has copied and then re-injected the 433 message), it must be detectable, and the subscriber must reject 434 the replayed message. 436 Ordering: it must not be possible for any entity to re-order the 437 authentic messages in such a way that the subscriber would accept 438 the messages in a sequence other than the one intended by the 439 publisher. If there are multiple publishers and the system does 440 not ensure that they are delivered in a particular order, then 441 subscribers (and the applications that use them) must not rely on 442 any particular ordering. 444 Confidentiality: it should not be possible for any entity other 445 than a subscriber to read the messages. 447 Authenticity, anti-replay, and ordering are required, because those 448 protections are essential to prevent the manipulation of the routing 449 system. Confidentiality may not always be necessary, but it is 450 strongly recommended that it be available within the pub-sub system. 451 Anti-replay and ordering can be easily achieved whenever 452 authentication is available, through the use of sequence numbers 453 and/or timestamps. 455 There are different cryptographic techniques that can be used to 456 provide the security services outlined above. One method is to use 457 pairwise communications security, such as TLS or IPsec, between each 458 subscriber and the MB and between each publisher and the MB (in the 459 case that all communication goes through the MB). Mutual 460 authentication between the MB and the publishers and subscribers is 461 required. The minimum configuration that is necessary is that each 462 publisher, and each subscriber, be configured with the information 463 needed to authenticate the MB. Because each communication channel is 464 separately protected, all of the needed security services are 465 provided and separation is enforced between different publishers and 466 subscribers. The advantage of this method is its simplicity. It 467 does have disadvantages when there are many subscribers and/or 468 publishers: cryptographic operations will need to be performed for 469 each subscriber, and if the MB is compromised, then the security of 470 the entire system is compromised. If the MB functionality is 471 distributed to multiple nodes in the network, that may help 472 scalability, but at the expense of security, since it creates 473 additional points in the system whose compromise will undermine its 474 security. 476 In some cases the communication may go directly between a publisher 477 and a subscriber, instead of through the MB. Those cases have 478 similar advantages and disadvantages. In these cases, the MB must 479 provide the subscribers and publishers with the information that they 480 need to authenticate each other, and to check the authorizations of 481 the other side of the secure communications channel. This 482 authentication and authorization information can be provided by the 483 MB on a per-session basis, or it could be persistent across multiple 484 sessions. If the data can persist for a long time, then it is 485 important to have a method by which the MB can revoke the 486 authorizations. 488 Another method is to use cryptography on the messages themselves. 489 Digital signatures can be used to provide authentication of each 490 message, in which each publisher has a private key, and each 491 subscriber has the corresponding public key. Confidentiality can be 492 provided using a group key that is shared by each publisher and the 493 set of corresponding subscribers. This method has the advantage that 494 cryptographic operations need only be done once on each method, thus 495 enabling the system to scale well when there are large numbers of 496 subscribers. It also reduces the number of keys used, and the amount 497 of session state that needs to be maintained by the MB (or by the 498 publishers, in the case of direct communication). The compromise of 499 the MB does not directly compromise the entire system in this case 500 (though if the MB is authoritative regarding which public keys should 501 be trusted, an attacker who compromises it can always perpetrate a 502 man-in-the-middle attack). 504 Security requirements using the publish-subscribe model include: 506 o REQ1: Mutual authentication between the Publishers and the Message 507 Broker, and the Subscribers and the Message Broker, is REQUIRED. 508 Authentication to the Message Broker MUST be established as the 509 minimum to determine authorization as either a publisher or 510 subscriber. 512 o REQ2: A Message Broker must exist to determine whether the routing 513 element or application is authorized to access the particular 514 protocol or interface (e.g. whether it is allowed to publish or 515 subscribe). 517 o REQ3: A Publisher SHOULD define the security properties of its 518 protocol or program interface (e.g. how its messages are secured, 519 using TLS for instance). Its transport SHOULD provide 520 confidentiality and MUST provide message authentication. 522 o REQ4: A Publisher SHOULD describe the latency with which it can 523 deliver messages, and a Subscriber SHOULD verify that the latency 524 is acceptable. This is needed to protect applications from 525 attacks that block the timely delivery of critical information. 527 o REQ5: The I2RS interface's communication channel must provide 528 confidentiality and message authentication. 530 o REQ6: When there are multiple subscribers, it should be possible 531 to provide cryptographic authentication in such a way that no 532 subscriber can pose as a publisher for which it subscribed. 534 o REQ7: Versioning MUST be supported. Backwards compatibility of 535 interfaces greatly simplifies the system, but cannot always be 536 expected. Version negotiation SHOULD be provided, and can be 537 facilitated through the publish-subscribe layer as the Message 538 Broker must account for the existence of multiple versions of 539 interfaces and protocols. 541 o REQ8: A discovery mechanism, when used, must be secured. At a 542 minimum, it must be possible to configure an element with 543 information that enables it to authenticate the provider of the 544 discovery service, or the discovered data, and reject data from 545 untrusted sources. A discovery service SHOULD have the ability to 546 authenticate its clients and choose to withhold information from a 547 client based on its authorizations. 549 6. Security Considerations 551 As the interfaces and frameworks being defined within I2RS and SDN 552 are purposed to inform, manipulate and control topology or behavior 553 of a routing system they must be secured through proper 554 authentication and authorization. Section Section 5 defines the 555 security requirements to address appropriate control access, privacy 556 and authenticity. 558 7. IANA Considerations 560 This memo includes no request to IANA. 562 8. Acknowledgements 564 The authors thank Allan Thomson and Anthony Grieco for valuable 565 review and comments on this draft. 567 9. References 569 9.1. Normative References 571 [I-D.amante-i2rs-topology-use-cases] 572 Amante, S., Medved, J., Previdi, S., and T. Nadeau, 573 "Topology API Use Cases", 574 draft-amante-i2rs-topology-use-cases-00 (work in 575 progress), February 2013. 577 [I-D.atlas-i2rs-policy-framework] 578 Atlas, A., Hares, S., and J. Halpern, "A Policy Framework 579 for the Interface to the Routing System", 580 draft-atlas-i2rs-policy-framework-00 (work in progress), 581 February 2013. 583 [I-D.atlas-i2rs-problem-statement] 584 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 585 Routing System Problem Statement", 586 draft-atlas-i2rs-problem-statement-00 (work in progress), 587 February 2013. 589 [I-D.ward-i2rs-framework] 590 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 591 Routing System Framework", draft-ward-i2rs-framework-00 592 (work in progress), February 2013. 594 9.2. Informative References 596 [manyfaces] 597 Eugster, P., Felber, P., Guerraoui, R., and A-M. 598 Kermarrec, "The many faces of publish/subscribe", 599 ACM Computing Surveys, Volume 35, Issue 2, pages 114-131, 600 2003. 602 [pub.sub.evolution] 603 Schiper, A., "The Evolution of Publish/Subscribe 604 Communication Systems", Springer Volume 2584 of Lecture 605 Notes in Computer Science, pages 137-141, 2003. 607 Authors' Addresses 609 Ken Beck 610 Cisco Systems 612 Email: kebeck@cisco.com 614 Nancy Cam-Winget 615 Cisco Systems 617 Email: ncamwing@cisco.com 619 David McGrew 620 Cisco Systems 622 Email: mcgrew@cisco.com