idnits 2.17.1 draft-hadi-i2rs-forces-gap-analysis-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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 11, 2013) is 3816 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Hadi Salim 3 Internet-Draft Mojatatu Networks 4 Intended status: Informational November 11, 2013 5 Expires: May 15, 2014 7 ForCES For I2RS 8 draft-hadi-i2rs-forces-gap-analysis-00 10 Abstract 12 This document provide a gap-analysis on ForCES meeting the 13 requirements for I2RS. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on May 15, 2014. 32 Copyright Notice 34 Copyright (c) 2013 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 51 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. ForCES overview . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. ForCES protocol . . . . . . . . . . . . . . . . . . . . . 4 55 3.2. ForCES Model . . . . . . . . . . . . . . . . . . . . . . . 6 56 4. Meeting I2RS requirements . . . . . . . . . . . . . . . . . . 7 57 4.1. Simplicity, Extensibility and Model-Driven 58 Programmatic Interfaces . . . . . . . . . . . . . . . . . 7 59 4.2. Protocol Structure . . . . . . . . . . . . . . . . . . . . 7 60 4.3. Channel . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.4. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.5. Notifications . . . . . . . . . . . . . . . . . . . . . . 8 63 4.6. Identity and Security Role . . . . . . . . . . . . . . . . 9 64 4.7. Multi-Headed Control . . . . . . . . . . . . . . . . . . . 10 65 4.8. Transactions . . . . . . . . . . . . . . . . . . . . . . . 10 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Terminology and Conventions 75 1.1. Requirements Language 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 1.2. Definitions 83 This document reiterates the terminology defined by the ForCES 84 architecture in various documents for the sake of clarity. 86 FE Model - The ForCES model used for describing resources to be 87 managed/controlled. This includes three components; the LFB 88 modeling of individual Logical Functional Block (LFB model), the 89 logical interconnection between LFBs (LFB topology), and the FE- 90 level attributes, including LFB components, capabilities and 91 events. The FE model provides the basis to define the information 92 elements exchanged between the CE and the FE in the ForCES 93 protocol [RFC5810]. 95 LFB (Logical Functional Block) Class - A template that represents 96 a resource that is being modeled. Most LFBs relate to packet 97 processing in the data path; however, that is not always the case. 98 LFB classes are the basic building blocks of the FE model. 100 LFB Instance - A runtime instantiation of an LFB class. 102 ForCES Component - A ForCES Component is a well-defined, uniquely 103 identifiable and addressable ForCES model building block. A 104 component has a 32-bit ID, name, type, and an optional synopsis 105 description. These are often referred to simply as components. 107 ForCES Protocol - Protocol that runs in the Fp reference points in 108 the ForCES Framework [RFC3746]. 110 ForCES Protocol Layer (ForCES PL) - A layer in the ForCES protocol 111 architecture that defines the ForCES protocol messages, the 112 protocol state transfer scheme, and the ForCES protocol 113 architecture itself as defined in the ForCES Protocol 114 Specification [RFC5810]. 116 ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 117 ForCES protocol architecture that uses the capabilities of 118 existing transport protocols to specifically address protocol 119 message transportation issues, such as how the protocol messages 120 are mapped to different transport media (like TCP, IP, ATM, 121 Ethernet, etc.), and how to achieve and implement reliability, 122 ordering, etc. the ForCES SCTP TML [RFC5811] describes a TML that 123 is mandated for ForCES. 125 2. Introduction 127 The ForCES architecture constitutes of: 129 1. Data model definition [RFC5812] serving as a basis for the 130 architecture constructs acted on by the protocol. 132 2. The ForCES protocol(PL) [RFC5810] which acts on the model 133 component constructs. 135 3. A transport mapping layer(TML) which takes the PL constructs and 136 maps them to underlying convinient transport(s) and delivers them 137 to the target end points. There is One TML currently defined 138 based on SCTP, [RFC5811]. 140 This document presents the ForCES architecture as a basis for I2RS. 142 3. ForCES overview 144 In this section we do a quick overview of ForCEs. The reader is 145 encouraged to read the relevant documents (In particular RFC 5810, 146 5812 and 5811). 148 The origins of ForCES lie in desire to separate control and datapath; 149 where "datapath" was intended to be packet processing resources. 150 Over time, however, due to the convinience of ForCES architecture it 151 has been used for managing arbitrary (other than packet processing) 152 resources. As long as one can model the resources using the ForCES 153 model, the protocol semantics allows using ForCES protocol to control 154 and manage said resources. In the case of I2RS, for example, a RIB 155 is a resource (which is not to be confused with a datapath FIB). For 156 this reason we may refer interchangeably to datapath as "resource" to 157 avoid the confusion. 159 3.1. ForCES protocol 161 The ForCES protocol features can be summarized as: 163 1. Transport independence. The ForCEs protocol is intended to run 164 on a variety of chosen protocols. This was design intent to 165 separate the PL from the different transports for given 166 resources and environments. As an example, one of the original 167 desires was to directly run over PCI-Express. 169 2. Simplified ForCES layer when possible: 171 * Security is left up to the transport choice keeping the 172 ForCES layer simple. As an example, RFC 5811 defines running 173 ForCES on top of SCTP with IPSEC for security. 175 * Optional Controller high availability. FEs(resource owners) 176 when desired can connect to multiple controllers in both cold 177 or hot standby mode. 179 * Controller-controller connectivity could be taken care of by 180 other existing technologies. 182 3. Transport dependence. Experience with ForCES as depicted in the 183 SCTP TML (RFC 5811) has shown absolute need for a variety of 184 shades of reliability. Requests from the control to the 185 resource must be reliably delivered, pronto (think a FIB 186 update). So are the response back; however, items like 187 synchronous reports of statistics could afford to be lost once 188 in a while; and retransmitting such stats is not useful since 189 they are monotonically incrementing. This helps reduce noise in 190 situations of congestion. Likewise, packet redirects coming 191 from outside the box could afford to be lost since the end peer 192 will end up retransmiting anyways. (Think OSPF link state 193 updates for example or BGP on top of TCP). 195 4. Node overload. Experience has shown need to protect against 196 node overload in a work-conserving mode(thus optimal resource 197 usage). The SCTP TML prioritizes both compute and wire 198 resources to request to the controlled-resource and responses to 199 the controller over events; whereas, event are prioritized over 200 redirect packets. With this approach, there is no need to 201 provide hacks like non-work conserving approaches (such as rate 202 limiting redirects to the controller). Example, a SET to update 203 the FIB is way more important vs an incoming packet requiring 204 further policy processing or a link going down then back up. 206 5. Transactional capabilities in the form of 2 phase commits. 208 6. Transactional scalability, low latency and high throughput. 209 Given that the original desire of ForCES was to be able to 210 achieve very high throughput transactions for the purpose of 211 updating one or more datapath tables (depending on the table 212 contents, achieving 10s to 100s of thousands of table updates/ 213 second is possible). The choice of making the underlying 214 protocol as binary, topped with allowing for command batching 215 allows the protocol achieve these goals. 217 7. Various execution modes for transactions {Execute-all-or-none, 218 Execute-until-error, Execute-all-despite-errors}. The default 219 mode of execution in ForCES is the atomic Execute-all-or-none 220 where the resource controller(CE) asks the resource owner(FE) to 221 run a transaction and abort if anything fails. The reader is 222 refered to look at RFC 5810 for more details. 224 8. Simple verbs in the form of {GET, SET, DELETE, REPORT and a few 225 helpers} 227 9. Traffic sensitive protocol level connectivity detection. ForCES 228 layer heartbeats could be sent in either or both directions. 229 Heartbeats, however are only sent when the link is idle. 231 10. Dynamic association of FEs to CEs. FEs register and unregister 232 to controllers and advertise their capabilities and capacities. 234 3.2. ForCES Model 236 The ForCES Model features can be summarized as: 238 1. Data model modularity through LFB class definition. 240 2. Data model type definitions via atomic types, complex/compound 241 types, grouping of compound types in the form of structures and 242 indexed/keyed tables which then end up composing addressable 243 components within an LFB class. 245 3. Hierarchical/tree definition of control/config/state components 246 which is acted on by a controller via the ForCES protocol. 248 4. Information-modeled metadata and expectations. 250 5. Built in LFB class resource capability definition/advertisement. 252 6. Publish/subscribe LFB event model with expressive trigger and 253 report definitions. 255 7. Data model flexibility/extensibility through augmentations, and 256 inheritance. 258 8. Backward and forward compatibility via LFB design and versioning 259 rules. 261 9. Formal constraints for validation of defined components. 263 4. Meeting I2RS requirements 265 This document assumes the floated RIB information model can be 266 described using the ForCES modelling language. Another document will 267 be published in the future to describe the RIB data model from a 268 ForCES point of view. 270 4.1. Simplicity, Extensibility and Model-Driven Programmatic Interfaces 272 If one was to provide an executive summary of the ForCES protocol 273 semantics, then it would be this: 275 The ForCES architecture provides (very) few simple protocol verbs 276 which act upon a multitude of nouns as represented by the ForCES 277 model. This allows powerful programmatic interfaces i.e the "API" 278 construct boils down to a formulation of operations in the form of 279 a "verb" acting on a "noun" followed by "optional arguements". In 280 other words, the ForCES semantic allows composing of rich services 281 on top of the basic grammar. 283 The expressive simplicity of the protocol is achieved due to the few 284 verbs (Refer to RFC 5810, section 7.1.6) which act on the agreed-to 285 modelled LFB components. The protocol is totaly agnostic of the 286 nature of the resource being controlled/managed. It is upto the 287 modeller to describe the resource in the manner that is fitting 288 (although frowned-upon, one could describe the resource model 289 _exactly_ as it is implemented and reduce the generalities and 290 therefore translation overhead). The model is highly extensible and 291 for this reason, the knowledge of the resource control is offloaded 292 to the service layer and a basic infrastructure is all that is 293 needed. 295 The author believes ForCES meets the requirements in these I2RS 296 prescribed needs. 298 4.2. Protocol Structure 300 The ForCES protocol using currently defined TML is binary for reasons 301 of conserving wire, memory and compute resources (needed for 302 scaling). The data model provides a _formal definition_ for 303 describing a variety of underlying structures (if you want to 304 describe /proc layout, then go ahead) and because the ForCES model 305 allows you to do this, the author believes it will be sufficient to 306 keep the transport encoding binary to maintain the efficiency desire. 307 However, given the ForCES architecture allows one to have different 308 transports (in the form of TML), if needed then one could for example 309 use XMPP to transport ForCES syntax. 311 The author believes ForCES meets the requirements in these I2RS- 312 prescribed needs. 314 4.3. Channel 316 ForCES leaves the decions on the number channels upto the underlying 317 TML. For example, the SCTP TML provides 3 channels which are used in 318 a strict priority. RFC 5811 provides guidelines for usage of these 319 channels. The High priority (HP) channel is isolated to carry 320 Requests from the Controller and responses from the resources and is 321 fully reliable and is always serviced first. The Medium priority is 322 for event updates from the resource and is partially reliable; and 323 last, the lowest priority is used for packet redirects and is less 324 reliable than the MP channel. IOW, during onsets of congestion MP 325 will be ignored over HP and LP will be ignored over MP. 327 The SCTP TML above is used for illustration, further study is needed 328 to pick one (or more) TMLs for I2RS. 330 The author believes ForCES meets the requirements in these I2RS 331 prescribed needs. 333 4.4. Negotiation 335 ForCES model definition allows a resource defined as an LFB to define 336 capabilities (Refer to RFC 5812, section 3.1 and section 4.7.5). It 337 also allows versioning of different LFBs(refer to RFC 5812 section 338 3.2.7). 340 The author believes ForCES meets the requirements in these I2RS 341 prescribed needs. 343 4.5. Notifications 345 The ForCES architecture exposes a pub-sub event model. 347 Event filtering is further defined. Filters include: 349 o Hysteresis - used to suppress generation of notifications for 350 oscillations around a condition value. Example, "generate an 351 event if the link laser goes below 10 or goes above 15". 353 o Count - used to suppress event generation around occurence count. 354 Example, "report the event to the client only after 5 consecutive 355 occurances". 357 o Time interval - used to suppress event generation around a time 358 limit. Example, "Generate an event if table foo row hasnt been 359 used in the last 10 minutes". 361 There could be multiple filters defined per event. Example of 362 compound filtering: "Generate an event when the count reaches 5 or 363 every 10 minutes when there is at least one event". 365 The events are published using the ForCES model on a per resource 366 level (refer to section 4.7.6 for more details on the semantics). 367 Event targets and what is to be reported is defined in the 368 definition. 370 Event subscription is achieved by using the protocol verb SET- 371 PROPERTY to the path of the published event. 373 The author believes ForCES meets the requirements in these I2RS 374 prescribed needs. 376 4.6. Identity and Security Role 378 The ForCES model defines basic ACLs to be used for components 379 (read,write,reset and access approach). The original intent was to 380 keep the resource/Datapath state very simple (refer to RFC 5812 381 section 4.7.6) and not need to store a lot of state. 383 The author believes there is a gap on ForCES to properly meet this 384 I2RS requirement that needs to be addressed. 386 The Identity and Security Role could be solved by adding TLS support 387 to the current SCTP TML(or any new one). This may be sufficient and 388 we let the controller to arbitrate on which client gets to write the 389 RIB. In case that turns out to be insufficient, then there are 390 several things that would need to be done: 392 1. Optionally, add userids and/or group ids to the ForCES component 393 ACL properties. These would be 32 bit IDs so not expensive to 394 store in the datapath. In addition to the existing ForCES ACLs, 395 the resulting changes would be equivalent to Unix file 396 permissions(which are well understood). The richness of details 397 of what a specific uid/gid means expected to sits in the 398 controller and at the resource level only the 32-bit ids are 399 used. 401 2. If we are to do the above, then we need to modify the protocol to 402 carry the uid/pid since the CE will be acting on behalf of the 403 different clients. 405 XXX: The outstanding question is whether we need to extend the ACLs 406 per LFB class or per LFB class Instance or per-component and whether 407 the controller can at runtime change permissions of the different 408 components. The challenge is to weigh-in usability vs efficiency.. 409 (kinda like IETF 88 Hyatt Elevators). 411 4.7. Multi-Headed Control 413 ForCES only allows a single master writter and multiple readers. 414 This was done for the sake of simplicity of the HA mode. The author 415 believes this requirement is not met by ForCES. 417 During the re-charter of the WG a request was made for this feature 418 but was rejected because we needed to constrain the deliverables to 419 only a few that could be met within a short period. (refer to: 420 http://www.ietf.org/proceedings/86/slides/slides-86-forces-7.pdf). 422 We may need to revisit the requirement in order to use ForCES for 423 I2RS. 425 4.8. Transactions 427 I2RS requires a Perform all or none, Perform until error, and Perform 428 all storing errors capabilities. 430 The author believes this requirement is fully met by ForCES. 432 5. IANA Considerations 434 TBD 436 6. Security Considerations 438 TBD 440 7. References 442 7.1. Normative References 444 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 445 "Forwarding and Control Element Separation (ForCES) 446 Framework", RFC 3746, April 2004. 448 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 449 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 450 Control Element Separation (ForCES) Protocol 451 Specification", RFC 5810, March 2010. 453 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 454 Layer (TML) for the Forwarding and Control Element 455 Separation (ForCES) Protocol", RFC 5811, March 2010. 457 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 458 Element Separation (ForCES) Forwarding Element Model", 459 RFC 5812, March 2010. 461 7.2. Informative References 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, March 1997. 466 Author's Address 468 Jamal Hadi Salim 469 Mojatatu Networks 470 Suite 400, 303 Moodie Dr. 471 Ottawa, Ontario K2H 9R4 472 Canada 474 Email: hadi@mojatatu.com