One document matched: draft-hares-i2rs-dataflow-req-00.txt
I2RS working group S. Hares
Internet-Draft Huawei
Intended status: Standards Track March 14, 2016
Expires: September 15, 2016
I2RS Data Flow Requirements
draft-hares-i2rs-dataflow-req-00.txt
Abstract
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.
Status of This Memo
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 15, 2016.
Copyright Notice
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.
Hares Expires September 15, 2016 [Page 1]
Internet-Draft I2RS Data Flow March 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary of I2RS Data Flow Requirements . . . . . . . . . . . 3
3. Generic Interfaces to Routing Functions . . . . . . . . . . . 5
3.1. I2RS-Generic Interface to Local-RIB . . . . . . . . . . . 5
3.2. I2RS-Generic interfaces to Policies . . . . . . . . . . . 5
3.3. I2RS Data Flow Requirements . . . . . . . . . . . . . . . 5
4. Large Data Flow Requirements . . . . . . . . . . . . . . . . 5
4.1. Large Data Flow Use Case Requirements . . . . . . . . . . 6
4.1.1. Data Requirements Supported in pub-sub Requirements . 7
4.1.2. Data Flow Requirements Outside of Pub/Sub
Requirements . . . . . . . . . . . . . . . . . . . . 7
4.1.3. I2RS Data Flow Requirements . . . . . . . . . . . . . 7
4.2. Traffic Flow Measurements . . . . . . . . . . . . . . . . 8
4.2.1. Protocol Requirements based on Traffic Flows . . . . 8
4.2.2. I2RS Data Flow Requirements . . . . . . . . . . . . . 9
4.3. CDNI Use case requirements . . . . . . . . . . . . . . . 9
4.3.1. CNDI Requirements for data flow . . . . . . . . . . . 10
4.3.2. I2RS Data Flow Requirements . . . . . . . . . . . . . 10
4.4. Action sequences in Data Models . . . . . . . . . . . . . 10
4.4.1. I2RS Data Flow Requirement . . . . . . . . . . . . . 11
4.5. Operation during network outages or attacks . . . . . . . 12
4.5.1. Periods of Network Outage . . . . . . . . . . . . . . 12
4.5.2. I2RS used for Security functions in routers (I2NSF
requirements) . . . . . . . . . . . . . . . . . . . . 12
4.5.3. I2RS Data Flow Requirements . . . . . . . . . . . . . 14
5. changes to YANG . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
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.
Hares Expires September 15, 2016 [Page 2]
Internet-Draft I2RS Data Flow March 2016
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:
o ephemeral state - as defined in [I-D.ietf-i2rs-ephemeral-state]
o notifications and events - as defined in
[I-D.ietf-i2rs-pub-sub-requirements]
o traceability - as defined in [I-D.ietf-i2rs-traceability]
o protocol security - as defined in
[I-D.ietf-i2rs-protocol-security-requirements]
o Generic interfaces to Protocol Local-RIBs or Policy Data bases,
o Large data flows,
o Traffic monitoring data,
o Data flows for Action sequences, and
o data flows during network outages or attacks
This document describes the protocol requirements for these last five
types of requirements. The first section summarizes the data flow
requirements. 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
2. Summary of I2RS Data Flow Requirements
Additional requirements from Generic Interface:None
The additional Data flow requirements are:
DF-REQ-01: Pull Publication/subscription mechanism
DF-REQ-02: The support of large data transfers in a data format
agnostic format. This the I2RS protocol should support transport
of data in any format including: XML, JSON, MTL (ALias/Waveformat,
.mtl), protobufs, and ascii text.
Hares Expires September 15, 2016 [Page 3]
Internet-Draft I2RS Data Flow March 2016
DF-REQ-03: Support of any transport,
DF-REQ-04 Support for the ability to send information using IPFIX
protocol and IPFIX templates,
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 or IPFIX tempalte formats over XML or JSON.
DF-REQ-06: Ability to carry ALTO protocol objects using ALTO
protocol transport (http) with JSON encodings (GET, POST-PUT) for
ALTO codes handling ALTO data errors, overload codes, and
temporary redirects plus ALTO resource directory requests. ALTO
error codes, overload codes, temporary redirets, and diretory
requetss should be transformed to I2RS events.
DF-REQ-07: 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-08: The I2RS should be able to support an action that
interacts with routing OAM functions.
I2RS-DF-09: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).
I2RS-DF-10: I2RS Agent-I2RS Client protocol must allow for a
common session level function that supports data flow resilence,
"chunking" of data appropriate sizes for congestion, message
integrity and replay protection so that during periods of DDoS and
bursty congestion due to security attacks. A common "session"
function will support an application layer "session" sending data
over multiple transports during periods of outage, network attack
or congestion.
DF-REQ11: The I2RS protocol must allow for security that exist at
the applications' "session" level that spans multiple transports.
DF-REQ-12: Support of the ability to send/receive IPFIX Templates,
and information using IPFIX template formats but use another
protocol to transport the data that can handle congestion and DDoS
attacks.
Hares Expires September 15, 2016 [Page 4]
Internet-Draft I2RS Data Flow March 2016
DF-REQ-13: Yang MUST have a way to indicate in a data model has
actions which allow: different transports, different resource
constraints, or different security.
DF-REQ-14: Yang MUST have a way to indicate a data model has
different levels of checking where: lowest level is message form
only, medium level checks message format plus data syntax, and
highest level uses the message format, data syntax and referential
check netconf configuration does. The default level for I2RS is
message format plus data syntax.
3. Generic Interfaces to Routing Functions
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.
3.1. I2RS-Generic Interface to Local-RIB
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.
3.2. I2RS-Generic interfaces to Policies
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.
3.3. I2RS Data Flow Requirements
These generic interfaces do not have any additional protocol
requirements.
4. Large Data Flow Requirements
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.
Hares Expires September 15, 2016 [Page 5]
Internet-Draft I2RS Data Flow March 2016
4.1. Large Data Flow Use Case Requirements
The I2RS use case for Large Data Collection systems
[I-D.ietf-i2rs-usecase-reqs-summary] requires the I2RS protocol and
data models:
o be able to be done at a high frequency and resolution with minimal
impact to devices memory or CPU (L-Data-REQ-01) ,
o use a data model which allows definition of the form as part of
the data model (L-Data-REQ-02) ,
o support a publication/subscription mechanism with push/pull
mechanism (L-Data-REQ-03),
o (supports capability negotiation for level of transport, security,
and error handling as a general configurations, per I2RS client-
agent protocol for all interfaces and all time instance, or per
I2RS interface client-agent protocol per specific interface or per
time instances. (L-Data-REQ-04,L-Data-REQ-06, L-Data-REQ-07, L-
Data-REQ-08, and L-Data-REQ-09),
o dynamic subscription model set-up via IPFIX (L-REQ-12c),
o support of subscriber and consumer I2RS-Agent pairs (L-REQ-12d),
o remapping of Node's databases,
o data format agnostic (L-Data-REQ-05),
o data models and I2RS protocol additions that support of query,
introspection using data-base model that support a set of
capabilities, data filters, and error handling (stale data,
repeated transport failures, and other errors.) Introspection
supports data verification, inclusion of legacy data, and merging
of data flows based on meta-data. (L-Data-REQ-11, L-Data-REQ-13),
o Support of push of data synchronously or asyncronously via
registered subscriptions (L-Data-REQ-12a).
o Pull of data in one-shot or multiple sequences (L-Data-REQ-12b),
and
o dynamic subscription model set-up via IPFIX (L-REQ-12c)
Hares Expires September 15, 2016 [Page 6]
Internet-Draft I2RS Data Flow March 2016
4.1.1. Data Requirements Supported in pub-sub Requirements
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.
4.1.2. Data Flow Requirements Outside of Pub/Sub Requirements
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). Support for the
IPFIX protocol or just the IPFIX data formats is required.
4.1.3. I2RS Data Flow Requirements
The following requirements are additional data flow requirements for
large data flows.
(DF-REQ-01): Support of Subscription/publication service in pull
model,
(DF-REQ-02): Support of any data format including: XML, JSON, (MTL
(Alias/WaveFormat,.mtl), protobufs, and ascii,
(DF-REQ-03): Support of any transport, and
(DF-REQ-04): support of the ability send information using IPFIX
templates as a reporting structure over the IPFIX protocol, or
over other data formats.
[I-D.ietf-netconf-yang-push] supports XML and JSON in its first
release, and provides an ability to register extra formats, but these
Hares Expires September 15, 2016 [Page 7]
Internet-Draft I2RS Data Flow March 2016
requirements should also support large data flows sent outside of the
publication-subscription service.
4.2. Traffic Flow Measurements
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:
o BGP Flow Specification (BGP-FS) ([RFC5575]
o IPFIX - IP Flow Information ([RFC7011]) that reports on a wide
variety of routing system statistics, and
o IPPM - IP Performance mangement ([RFC2330], [RFC7312]) that
reports on one-way or two-way end-to-end network performance
statistics,
In addition the SFLOW([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.
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:
o BGP Flow Specification (BGP-FS) yang model
[I-D.wu-idr-flowspec-yang-cfg] contains flow filter match
statistics.
o I2RS Filter-Based RIB yang model
([I-D.kini-i2rs-fb-rib-info-model],
[I-D.hares-i2rs-fb-rib-data-model])- yang model contains ephemeral
flow statistics,
o Filter-Based RIB (draft-hares-rtgwg-fb-rib-data-model) contains
both flow filter match statistics,
4.2.1. Protocol Requirements based on Traffic Flows
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
Hares Expires September 15, 2016 [Page 8]
Internet-Draft I2RS Data Flow March 2016
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.
4.2.2. I2RS Data Flow Requirements
(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 or IPFIX tempalte formats over XML or JSON.
4.3. CDNI Use case requirements
The CDNI use case has the two requirements for an I2RS interface:
interface that allows redirection of cDNI request via the Alto
protocol or query of ALTO information (CDNI-REQ-01s, CNDI-REQ-02,
Hares Expires September 15, 2016 [Page 9]
Internet-Draft I2RS Data Flow March 2016
interface using I2RS Client-Agent that allows I2RS agent to
redirect content request message to a downstream agent
CDNI meta data sent with CNDI metadata to determine how CNDI can
deliver or reroute CDNI content (CNDI-REQ-1b, CDNI-REQ-03.
4.3.1. CNDI Requirements for data flow
Alto protocol objects which include
* map-object with request resoponse data that includes:
* InfoResourceDirectory,
* InfoResourceNetworkMap,
* InfoResourceCostMap,
* InfoResourceEndpointProperties, and
* InfoResourceEndpointCostMap.
ALTO transport (http) and JSON encodings (GET, POST, PUT) for ALTO
codes
Receive ALTO Error data with error codes (Code = application/alto-
error+json), or overload (HTTP 503 ("Service Unavailable")), or
temporary redirect (HTTP 307 ("Temporary Redirect")) and re-
interpret as Events or responses on CDNI interface.
Transfer ALTO Resource directory information to CDNI meta data (
Jason encoded data with: "application/alto-directory+json")
4.3.2. I2RS Data Flow Requirements
DF-REQ-06: Support carry ALTO protocol objects using ALTO protocol
transport (http) with JSON encodings (GET, POST-PUT) for ALTO codes
handling ALTO data errors, overload codes, and temporary redirects
plus ALTO resource directory requests. ALTO error codes, overload
codes, temporary redirets, and diretory requetss should be
transformed to I2RS events.
4.4. Action sequences in Data Models
Several of the I2RS requirements from the use cases require a
sequence of events with the following actions:
Hares Expires September 15, 2016 [Page 10]
Internet-Draft I2RS Data Flow March 2016
1. query data in protocol independent model (topology, RIB, Filter-
RIB), or protocol),
2. start calculation (or re-calculation) in protocol function,
3. Report results,
4. install topology or RIB calculated,
5. check results,
6. recycle.
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:
o the ability to request a reservation of resources for this effort
so the action sequence does not start unless there is enough
calculation or response bandwidth in a node,
o the abilty ability to have validation on off-line calculated data
so this critical data does not have errors
o the ability to "prioritize" notification or reports ahead of other
I2RS data streams to allow process to work.
4.4.1. I2RS Data Flow Requirement
I2RS-DF-REQ-07: 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-08: The I2RS should be able to support an action that
interacts with routing OAM functions.
Hares Expires September 15, 2016 [Page 11]
Internet-Draft I2RS Data Flow March 2016
4.5. Operation during network outages or attacks
The router needs dynamic management during periods of outage or
periods of security attack.
4.5.1. Periods of Network Outage
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.
4.5.2. I2RS used for Security functions in routers (I2NSF requirements)
For protection, most network devices have basic firewalls and flow
filters. Some network routing devices have more advanced security.
An interface to Network Security Function (I2NSF) is a new interface
being defined by manage network security devices using the same
higher-level protocol concept as I2RS where the I2NSF will be
comprised of component protocols (see
[I-D.ietf-i2nsf-problem-and-use-cases] for a description of the
problem space and use cases for I2NSF), The intent of the I2NSF
interface is to utilize the I2RS protocol as a component protocol
which interfaces routing and forwarding functions in the security
devices or in routing/forwarding devices in the network which include
basic security devices (E.g. NAT firewalls or traffic filtesr in
routing devices). The I2NSF function supports configuration of
security devices as well as providing notification of events, logging
of security action, and reporting of statistics and traffic flow
measurement. The I2RS data functions described above will support
sending information most network conditions except during the high
loss and heavy congestion due DDoS or other security incidents. This
section provides a short review of these type of streams of data and
places to look-up additional input.
The common need for I2RS (and I2NSF) to support these functions via
an application layer services with to support data flow resilence,
"chunking" of data appropriate sizes for congestion, mesage integrity
and replay protection during periods of DDoS and bursty congestion
due to security attacks. A common "session" function as an I2RS data
flow can provide these functions.
Hares Expires September 15, 2016 [Page 12]
Internet-Draft I2RS Data Flow March 2016
4.5.2.1. DOTS - DDoS Open Threat Signaling
Sending information to signal information about DDoS threats occurs
during periods where the DDoS is congesting the network or causing
large packet losses. Management systems need to configure network
security functions (NSFs) on routers and on security devices to with
new filtering policy, pull events and logs from NSF, and receive
traffic monitoring data and logs regarding network security
incidents.
These features for routing devices are handled by the existing I2RS
data flow requirements except it does not support the network
resilience in the presence of loss or congestion.
The DOTS requirements for messages from devices with security
functions (such as firewalls in routing devices) are specified in:
[I-D.ietf-dots-requirements]. The following are DOTS descriptions of
the resiliency needed by the data
o Resilence (DOTS-G-003) in the face of severally constrained
severely constrained network conditions imposed by the attack
traffic. The protocol SHOULD be resilient, that is, continue
operating despite message loss and out-of-order or redundant
signal delivery.
o Small message sizes (DOTS-G-005) to prevent fragmentation so that
all of message goes through in attack,
o Message integrity (G-006) and Message level replay protection
(G-007) must exist for data streams even during periods of attack,
o Session-level Health monitoring (aka Heart beats) during attack
(DOTS-OP-003)
o Abiilty to request/stop mitigation quickly (DOTS-OP-005)
4.5.2.2. MILE - Managed Incident Lightweight Exchange
The MILE related protocols ([RFC5070] and [I-D.ietf-mile-rfc5070-bis]
provide data formats for reporting network security incidents during
time periods of network attack. Similar to DOTS, the data passed by
these protocols requires resilience, message integrity, message level
replay protection, and session-level health monitoring. During
attacks, the use of small message sizes is necessary.
Hares Expires September 15, 2016 [Page 13]
Internet-Draft I2RS Data Flow March 2016
4.5.3. I2RS Data Flow Requirements
I2RS-DF-09: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).
I2RS-DF-10: I2RS Agent-I2RS Client protocol must allow for a common
session level function that supports data flow resilence, "chunking"
of data appropriate sizes for congestion, mesage integrity and replay
protection so that during periods of DDoS and bursty congestion due
to security attacks. A common "session" function will support an
application layer "session" function that serves multiple transports.
DF-REQ10: The I2RS protocol must allow for security that exist at the
applications' "session" level that spans multiple transports.
DF-REQ-12: Support of the ability to send/receive IPFIX Templates,
and information using IPFIX template formats but use another protocol
to transport the data that can handle congestion and DDoS attacks.
congestion-friendly
5. changes to YANG
DF-REQ-13: Yang MUST have a way to indicate in a data model has
actions which allow: different transports, different resource
constraints, or different security.
DF-REQ-14: Yang MUST have a way to indicate a data model has
different levels of checking where: lowest level is message form
only, medium level checks message format plus data syntax, and
highest level uses the message format, data syntax and referential
check netconf configuration does. The default level for I2RS is
message format plus data syntax.
6. IANA Considerations
There are no IANA requirements for this document.
7. Security Considerations
The security requirements for the I2RS protocol are covered in
[I-D.ietf-i2rs-protocol-security-requirements] document.
Hares Expires September 15, 2016 [Page 14]
Internet-Draft I2RS Data Flow March 2016
8. Acknowledgements
The following people have aided in the discuss
o Russ White,and
o Robert Moskowitz.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References
[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", draft-
hares-i2rs-fb-rib-data-model-02 (work in progress),
February 2016.
[I-D.ietf-dots-requirements]
Mortensen, A., Moskowitz, R., and T. Reddy, "DDoS Open
Threat Signaling Requirements", draft-ietf-dots-
requirements-00 (work in progress), 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", draft-
ietf-i2nsf-problem-and-use-cases-00 (work in progress),
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", draft-ietf-i2rs-architecture-13 (work in
progress), February 2016.
[I-D.ietf-i2rs-ephemeral-state]
Haas, J. and S. Hares, "I2RS Ephemeral State
Requirements", draft-ietf-i2rs-ephemeral-state-03 (work in
progress), March 2016.
Hares Expires September 15, 2016 [Page 15]
Internet-Draft I2RS Data Flow March 2016
[I-D.ietf-i2rs-protocol-security-requirements]
Hares, S., Migault, D., and J. Halpern, "I2RS Security
Related Requirements", draft-ietf-i2rs-protocol-security-
requirements-03 (work in progress), March 2016.
[I-D.ietf-i2rs-pub-sub-requirements]
Voit, E., Clemm, A., and A. Prieto, "Requirements for
Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub-
requirements-05 (work in progress), February 2016.
[I-D.ietf-i2rs-rib-info-model]
Bahadur, N., Kini, S., and J. Medved, "Routing Information
Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work
in progress), 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", draft-ietf-i2rs-traceability-07 (work
in progress), February 2016.
[I-D.ietf-i2rs-usecase-reqs-summary]
Hares, S. and M. Chen, "Summary of I2RS Use Case
Requirements", draft-ietf-i2rs-usecase-reqs-summary-01
(work in progress), May 2015.
[I-D.ietf-mile-rfc5070-bis]
Danyliw, R., "The Incident Object Description Exchange
Format v2", draft-ietf-mile-rfc5070-bis-16 (work in
progress), February 2016.
[I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-09 (work in
progress), December 2015.
[I-D.ietf-netconf-yang-push]
Clemm, A., Prieto, A., Voit, E., Tripathy, A., and E.
Einar, "Subscribing to YANG datastore push updates",
draft-ietf-netconf-yang-push-01 (work in progress),
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", draft-kini-i2rs-fb-rib-info-model-03
(work in progress), February 2016.
Hares Expires September 15, 2016 [Page 16]
Internet-Draft I2RS Data Flow March 2016
[I-D.wu-idr-flowspec-yang-cfg]
Wu, N., Zhuang, S., and A. Choudhary, "A YANG Data Model
for Flow Specification", draft-wu-idr-flowspec-yang-cfg-02
(work in progress), 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,
<http://www.rfc-editor.org/info/rfc2330>.
[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, <http://www.rfc-editor.org/info/rfc3176>.
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070,
DOI 10.17487/RFC5070, December 2007,
<http://www.rfc-editor.org/info/rfc5070>.
[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,
<http://www.rfc-editor.org/info/rfc5575>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012,
<http://www.rfc-editor.org/info/rfc6536>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., 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,
<http://www.rfc-editor.org/info/rfc7011>.
Hares Expires September 15, 2016 [Page 17]
Internet-Draft I2RS Data Flow March 2016
[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling
Framework for IP Performance Metrics (IPPM)", RFC 7312,
DOI 10.17487/RFC7312, August 2014,
<http://www.rfc-editor.org/info/rfc7312>.
Author's Address
Susan Hares
Huawei
Saline
US
Email: shares@ndzh.com
Hares Expires September 15, 2016 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 02:42:22 |