| I2RS working group | S. Hares |
| Internet-Draft | Huawei |
| Intended status: Standards Track | A. Dass |
| Expires: September 22, 2016 | Ericsson |
| March 21, 2016 |
I2RS Data Flow Requirements
draft-hares-i2rs-dataflow-req-03.txt
This document covers requests to the netmod and netconf Working Groups for functionality to support the data flows described in the I2RS architecture and the I2RS use cases requirements summary.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The Interface to the Routing System (I2RS) Working Group is chartered with providing architecture and mechanisms to inject into and retrieve information from the routing system. The I2RS Architecture document [I-D.ietf-i2rs-architecture] abstractly documents a number of requirements for implementing the I2RS requirements.
The I2RS Working Group has chosen to use the YANG data modeling language [RFC6020] as the basis to implement its mechanisms.
Additionally, the I2RS Working group has chosen to use the NETCONF [RFC6241] and its similar but lighter-weight relative RESTCONF [I-D.ietf-netconf-restconf] as the protocols for carrying I2RS. NETCONF and RESTCONF are suitable for handling the configuration portion of the I2RS protocol, but need extensions to handle the I2RS use cases described in [I-D.ietf-i2rs-usecase-reqs-summary]. The requirements for these functionalities include:
This document describes the protocol requirements for these last five types of requirements. The first section summarizes the data flow requirements gathered from the Use Cases. These list of requirements are being presented to the I2RS Working group to determine if the requirement is need for the first revision of the I2RS protocol. Future revisions may add additional data flow requirement. The authors have indicated their suggestion with the following abbreviation:
Section 2 details how the I2RS use case requirements for Generic interfaces to protocol RIBS or policy data base do not add any requirements to the I2RS protocol. Section 3 describes how the describes
Additional requirements from Generic Interface:None
The additional Data flow requirements are:
The I2RS use case requirement suggests that a generic interface be created to protocol local RIBs and a generic interface be available to configure policies.
The I2RS requirements ([I-D.ietf-i2rs-usecase-reqs-summary]) require that a generic interface be defined to the local-RIB in protocols. This type of data flow does not require a new type of data flow, but the definition of a new data model that creates a generic local RIB and has operations to funnel this generic Local-RIB to a specific protocol.
The Protocol Independent Use case (PI-REQ-11) Local RIB use case suggest the I2RS protocol has three levels of checks: minimal data reception checks (TLVs of data align), all non-referential checks (e.g. do not do leafref, MUST, instance identifiers), and do referential checks. This feature could be supported through different rpc calls to the LOCAL RIB.
The I2RS requirements suggest that I2RS have a generic interface to routing policies for protocols, routing distribution, or routing protocols. This generic interface is currently being implemented as common definitions for data models. At this time, This generic interface does not need additional protocol requirements.
[DF-REQ-01] Support writing to the ephemeral copy of the Local RIB with three different types of checks: minimal data reception checks (TLVs of data oacket valid), all non-referential checks (e.g. do not do leafref, MUST, instance identifiers), and do referential checks via three different rpcs.
This section decribes the data flow requirements for large data flows, traffic flows measurements, CDNI traffic flows, OAM and Action rqeuests, data flows during outages or network attacks (DDoS (Distributed Denial of Service) or other network attacks), and non-secure data flows. These data flows are data flows which are not configuration based data flows.
The I2RS use case for Large Data Collection systems [I-D.ietf-i2rs-usecase-reqs-summary] requires the I2RS protocol and data models:
All use case requirements for the publication/subscription service for the push service from large data requirements 01-04 and 6-12 is found in [I-D.ietf-i2rs-pub-sub-requirements], and an example protocol addition to netconf is include in [I-D.ietf-netconf-yang-push].
The requirements for the publication/subscription service for the pull model are not specified in the [I-D.ietf-i2rs-pub-sub-requirements], but a majority of the pub-sub requirements and mechanisms can be reused. In a pull, the publisher prepares the data that is pulled by a few receivers who then distribute it to the receivers. The pull mechanism would have a different "pull latency" versus the push latencey, and a set of parameters which indicate the amount of data stored if receivers did not pull the data within a certain time.
At this time, the pull-model of the publication/subscription model is not being requested by vendors or operators.
The data flow requirements for large data flows also include support for data flows outside of publication/subscription via any transport (L-Dat-REQ-04) and any data format (L-Data-REQ-05). It is unclear whether the L-DATA-REQ-12 really wants to utilize IPFIX protocol or just IPFIX templates to handle the montoring data.
Editor note: It becomes a question for the WG as to whether these are necessary for version 1 of the I2RS protocol, version 2 or never.
The following requirements are additional data flow requirements for large data flows.
[I-D.ietf-netconf-yang-push] supports XML and JSON in its first release, and provides an ability to register extra formats, but these requirements should also support large data flows sent outside of the publication-subscription service.
The I2RS requirements for the Protocol independent use cases requires the support off interactions with traffic flow and other network management Protocols (requirements PI-REQ-05, PI-REQ06) in [I-D.ietf-i2rs-usecase-reqs-summary]).
The following IETF protocol pass traffic related information: [RFC3176]) of layer 2 devices is supported by many routers. Other traffic flows may be measured in support of IDS/IPS, but these will be covered in the section on security flows.
In addition the SFLOW(
Additional traffic flow models are being defined to configure traffic flow policy and to monitor the statistics on the use of the traffic flow statistics:
Due to the potentially large data flow these statistics should be handle by push pub-sub model or a pull pub-sub model. Thresholds for data models may be passed by the event portion of the push/pull pub-sub model. The pub-sub model will allow the I2RS client-I2RS Agent to meter the amount of data flow these statistics carry. The push portion of the pub-sub model is supported by [I-D.ietf-netconf-yang-push], but the pull portion of the pub-sub model is not defined.
Alternatively I2RS can use the the IPFIX protocol ([RFC7011]) as a component protocol. I2RS processes can support an IPFIX exporting process sendinging dta to a node to a node on a collector process. The IPFIX templates can be configured as ephemeral state or configuration state. The IPFIX data flows may run over SCTP, UDP, or TCP utilizing the congestion services at each time. The IPFIX connections assumes that: a) congestion is an temporary anomaly, b) dropping data during a congestion is reported, and c) for some exporiting process it is acceptable to have drop data in a reliable protocol. The I2RS protocol must support the establishment of an IPFIX connection.
Traffic monitoring can occur in a network under DDoS with high levels of congestion and loss the use of these protocols which rely on transport-level retransmission may not be as resilient as needed for network security functions (NSF). These are considered in section 5 on operations during network outages or congestoin.
The Flow Filtering data models with policy rules (BGP Flow Specification, I2RS Filter-Based RIB, and n-tuple policy routing RIB) often track how often these policies are match. These statistics can also be pushed/pulled in a publication/subscription with yang data-model defined format or an IPFIX exporting process format. Similarly IPPM statistics or SFLOW data, be sent via publication/subscription service in yang data model format or in a IPFIX Template or as XML or JSON representation of a yang data model. These additional sources do not change the requirements for the push publication/subscription or expand the
Summary: The pub-sub model push or pull may have to support additional formats (E.g. SFLOW, IPFIX) as well as yang data models.
DF-REQ-04: Support for the ability to send traffic monitoring information using IPFIX protocol and IPFIX templates, [Editor: This requirement is unclear in the use case so this requirement is to confirm the I2RS WG desire for NETCONF/RESTCONF + IPFIX == I2RS protocol]
(DF-REQ-05): Support of traffic statistics for filter-based policies (BGP-FS, I2RS FB-RIB, policy routing), IPPM, SFLOW, and others in yang data model format.
This section considers the data flow requirements in sequences of actions (e.g. calculate topology and install), and actions that interact with TCAMs (e.g. putting filters in TCAMs).
Several of the I2RS requirements from the use cases require a sequence of events with the following actions:
The actions included looking for overlapping BGP routes, IGP LFA calculation, ECMP load balancing traffic, optimizing paths via MPLS-TE, CCNE re-optimization, and virtual topology creation.
An alternate pattern within the requirements is if the topology is calculated off-line, and uploaded.
These action patterns may involve an interaction of the I2RS action sequences with existing OAM functions in the routing system.
NETCONF/RESTCONF have the concepts of an "rpc" for a configuration enabled action, but these action sequences should have the abilty to have the following characteristics:
Note: TCAM (hardware memory)in general is used in m ost of the routing devices for faster address lookup that enables fast routing. The TCAM also provides the flexibility to manually specify how much TCAM space you want to allocate to a specific feature or action (like routing, switching, security , ACL etc.). There may be cases when a manual allocation of memory (H/W or S/W) could restrict the I2RS functions. To allow operators the control they need, the manual allocation must be considered.
A few questions need to be consider:
I2RS-DF-REQ-06: I2RS should be able to support an action which allocates internal resources for the I2RS agent (memory, processing time, interrupts) and outbound data flow bandwidth. It is expected that an action would be included in a data model in an "rpc"-like format in yang.
DF-REQ-07: The I2RS should be able to support an action that interacts with routing OAM functions. [Editor: Operator-applied priorities and manual control must support limiting I2RS actions with OAM.]
The router needs dynamic management during periods of outage or periods of security attack.
During periods of outage, the I2RS protocol must operate when data bandwidth is reduced and network connectivity fluctuates. I2RS agents must be able to adjust operation of event notifications, logging, or data traffic during this period. Data Models and I2RS agent configuration must allow operator-applied policy to prioritize data during this period. The I2RS Agent should be able to signal the I2RS Client that such a time period is occuring.
Some periods of outage are caused by security attacks (DDoS or target incident that exploit vulnerabilities in software, network devices, protocols.) [I-D.hares-i2nsf-mgtflow-reqs] provides a description of the data flow needed from network security controllers to the network security devices or firewalls in routers. Editor's Note: I2NSF is reviewing this draft, and will give feedback on this requirement.
Network Outages may occur due to several issues including the security reasons but network downtimes caused by security reasons may also be quite diverse, for example a network outage due to DDoS attack, botnets, malware attack, identity theft, or incidents that incident that exploit vulnerabilities in software, network devices, protocols. And if an outage has occurred due to security reasons then other safeguard measures could overlap with the I2RS based prioritization.
Since these outages can overlap with the network security controllers using I2NSF protocol to contact the network service functions (NSF) or virtual service functions (vNSF), the I2NSF working group should be consulted to determine what I2RS versus I2NSF needs are, and what conflicts exist. [I-D.hares-i2nsf-mgtflow-reqs] provides a description of the data flow needed from network security controllers to the network security devices or firewalls in routers. The I2NSF WG is reviewing this draft.
Editor's note: Do we want a general OAM feature or a feature specific to DDoS and security attack case?
DF-REQ-08: The I2RS Agent must be able signals that it will be using different protocol with different constraints (security, priority of data, or transport) or different constraints on the existing protocol (smaller message sizes, different priorities on data carried, or different security levels). [Editor's Note: Should this be for network outages or for just security attacks?]
To support the above requirements, the yang modules will need to support the following features:
There are no IANA requirements for this document.
The security requirements for the I2RS protocol are covered in [I-D.ietf-i2rs-protocol-security-requirements] document.
The following people have aided in the discuss
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [I-D.hares-i2nsf-mgtflow-reqs] | Hares, S., "I2NSF Management Traffic Flow Requirement", Internet-Draft draft-hares-i2nsf-mgtflow-reqs-01, March 2016. |
| [I-D.hares-i2rs-fb-rib-data-model] | Hares, S., Kini, S., Dunbar, L., Krishnan, R., Bogdanovic, D. and R. White, "Filter-Based RIB Data Model", Internet-Draft draft-hares-i2rs-fb-rib-data-model-02, February 2016. |
| [I-D.ietf-dots-requirements] | Mortensen, A., Moskowitz, R. and T. Reddy, "DDoS Open Threat Signaling Requirements", Internet-Draft draft-ietf-dots-requirements-00, October 2015. |
| [I-D.ietf-i2nsf-problem-and-use-cases] | Hares, S., Dunbar, L., Lopez, D., Zarny, M. and C. Jacquenet, "I2NSF Problem Statement and Use cases", Internet-Draft draft-ietf-i2nsf-problem-and-use-cases-00, February 2016. |
| [I-D.ietf-i2rs-architecture] | Atlas, A., Halpern, J., Hares, S., Ward, D. and T. Nadeau, "An Architecture for the Interface to the Routing System", Internet-Draft draft-ietf-i2rs-architecture-13, February 2016. |
| [I-D.ietf-i2rs-ephemeral-state] | Haas, J. and S. Hares, "I2RS Ephemeral State Requirements", Internet-Draft draft-ietf-i2rs-ephemeral-state-04, March 2016. |
| [I-D.ietf-i2rs-protocol-security-requirements] | Hares, S., Migault, D. and J. Halpern, "I2RS Security Related Requirements", Internet-Draft draft-ietf-i2rs-protocol-security-requirements-03, March 2016. |
| [I-D.ietf-i2rs-pub-sub-requirements] | Voit, E., Clemm, A. and A. Prieto, "Requirements for Subscription to YANG Datastores", Internet-Draft draft-ietf-i2rs-pub-sub-requirements-05, February 2016. |
| [I-D.ietf-i2rs-rib-info-model] | Bahadur, N., Kini, S. and J. Medved, "Routing Information Base Info Model", Internet-Draft draft-ietf-i2rs-rib-info-model-08, October 2015. |
| [I-D.ietf-i2rs-traceability] | Clarke, J., Salgueiro, G. and C. Pignataro, "Interface to the Routing System (I2RS) Traceability: Framework and Information Model", Internet-Draft draft-ietf-i2rs-traceability-07, February 2016. |
| [I-D.ietf-i2rs-usecase-reqs-summary] | Hares, S. and M. Chen, "Summary of I2RS Use Case Requirements", Internet-Draft draft-ietf-i2rs-usecase-reqs-summary-01, May 2015. |
| [I-D.ietf-mile-rfc5070-bis] | Danyliw, R., "The Incident Object Description Exchange Format v2", Internet-Draft draft-ietf-mile-rfc5070-bis-16, February 2016. |
| [I-D.ietf-netconf-restconf] | Bierman, A., Bjorklund, M. and K. Watsen, "RESTCONF Protocol", Internet-Draft draft-ietf-netconf-restconf-10, March 2016. |
| [I-D.ietf-netconf-yang-push] | Clemm, A., Prieto, A., Voit, E., Tripathy, A. and E. Einar, "Subscribing to YANG datastore push updates", Internet-Draft draft-ietf-netconf-yang-push-01, February 2016. |
| [I-D.kini-i2rs-fb-rib-info-model] | Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan, R., Bogdanovic, D. and R. White, "Filter-Based RIB Information Model", Internet-Draft draft-kini-i2rs-fb-rib-info-model-03, February 2016. |
| [I-D.wu-idr-flowspec-yang-cfg] | Wu, N., Zhuang, S. and A. Choudhary, "A YANG Data Model for Flow Specification", Internet-Draft draft-wu-idr-flowspec-yang-cfg-02, October 2015. |
| [RFC2330] | Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998. |
| [RFC3176] | Phaal, P., Panchen, S. and N. McKee, "InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks", RFC 3176, DOI 10.17487/RFC3176, September 2001. |
| [RFC5070] | Danyliw, R., Meijer, J. and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, DOI 10.17487/RFC5070, December 2007. |
| [RFC5575] | Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J. and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009. |
| [RFC6020] | Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010. |
| [RFC6241] | Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011. |
| [RFC6536] | Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012. |
| [RFC7011] | Claise, B., Trammell, B. and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013. |
| [RFC7312] | Fabini, J. and A. Morton, "Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)", RFC 7312, DOI 10.17487/RFC7312, August 2014. |