One document matched: draft-hares-i2rs-dataflow-req-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2330 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2330.xml">
<!ENTITY RFC3176 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3176.xml">
<!ENTITY RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6536 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6536.xml">
<!ENTITY RFC7011 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7011.xml">
<!ENTITY RFC7312 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7312.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.ietf-i2rs-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-info-model.xml">
<!ENTITY I-D.ietf-i2rs-rib-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-data-model.xml">
<!ENTITY I-D.ietf-i2rs-yang-network-topo
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-yang-network-topo.xml">
<!ENTITY I-D.ietf-i2rs-yang-l2-network-topology
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-yang-l2-network-topology.xml">
<!ENTITY I-D.ietf-i2rs-yang-l3-topology
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-yang-l3-topology.xml">
<!ENTITY I-D.ietf-i2rs-ephemeral-state SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-ephemeral-state.xml">
<!ENTITY I-D.ietf-i2rs-traceability SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-traceability.xml">
<!ENTITY I-D.ietf-i2rs-usecase-reqs-summary SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-usecase-reqs-summary.xml">
<!ENTITY I-D.ietf-i2rs-pub-sub-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-pub-sub-requirements.xml">
<!ENTITY I-D.ietf-i2rs-protocol-security-requirements
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-protocol-security-requirements.xml">
<!ENTITY I-D.ietf-netmod-acl-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-acl-model.xml">
<!ENTITY I-D.ietf-netmod-yang-metadata SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-yang-metadata.xml">
<!ENTITY I-D.ietf-netconf-restconf SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-restconf.xml">
<!ENTITY I-D.ietf-netconf-yang-push SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-yang-push.xml">
<!ENTITY I-D.kini-i2rs-fb-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kini-i2rs-fb-rib-info-model.xml">
<!ENTITY I-D.hares-i2rs-fb-rib-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-fb-rib-data-model.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-hares-i2rs-dataflow-req-04.txt" ipr="trust200902">
<front>
<title abbrev="I2RS Data Flow">I2RS Data Flow Requirements </title>
<author fullname="Susan Hares" initials="S." surname="Hares">
<organization> Huawei </organization>
<address>
<postal>
<street></street>
<city>Saline</city>
<country>US</country>
</postal>
<email>shares@ndzh.com </email>
</address>
</author>
<author fullname="Amit Daas" initials="A." surname="Dass">
<organization> Ericsson </organization>
<address>
<email>amit.dass@ericsson.com</email>
</address>
</author>
<date year="2016" />
<area>Routing Area</area>
<workgroup>I2RS working group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>I2RS</keyword>
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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 <xref target="I-D.ietf-i2rs-architecture"></xref> abstractly documents a number
of requirements for implementing the I2RS requirements.</t>
<t>
The I2RS Working Group has chosen to use the YANG data modeling
language <xref target="RFC6020"></xref> as the basis to implement its mechanisms.
</t>
<t>
Additionally, the I2RS Working group has chosen to use the NETCONF
<xref target="RFC6241"></xref> and its similar but lighter-weight relative RESTCONF
<xref target="I-D.ietf-netconf-restconf"></xref> 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 <xref target="I-D.ietf-i2rs-usecase-reqs-summary"></xref>.
The requirements for these functionalities have been specified:
<list style="symbols">
<t>ephemeral state - as defined in
<xref target="I-D.ietf-i2rs-ephemeral-state"></xref></t>
<t>notifications and events - as defined in
<xref target="I-D.ietf-i2rs-pub-sub-requirements"></xref>
</t>
<t>traceability - as defined in
<xref target="I-D.ietf-i2rs-traceability"></xref>
</t>
<t>protocol security - as defined in
<xref target="I-D.ietf-i2rs-protocol-security-requirements">
</xref></t>
</list>
</t>
<t>The requirements for the data flows in the following use cases have not been
specified:
<list>
<t>Generic interfaces to Protocol Local-RIBs or Policy Data bases, </t>
<t>Large data flows, </t>
<t>Traffic monitoring data,</t>
<t>Data flows for action sequences, and </t>
<t>data flows during network outages or attacks</t>
</list>
</t>
<t>This document describes the protocol requirements for these
last five types of requirements. The first summarizes the
data flow requirements for the I2RS protocol version 1, and
data flow requirements that may occur in future I2RS protocol versions.
</t>
<t>Section 3 provides details on the data flow requirements for the
generic interfaces. Section 4 considers large data flows and traffic monitoring
data flows. Section 5 considers data flows and constraints during action
and attacks.
</t>
<section title="Requirements language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
</section>
<section title="Summary of I2RS Data Flow Requirements">
<t> The following are the data flow related requirements
for I2RS protocol version 1:
<list style="hanging">
<t hangText="I2RS-DF-REQ-01:No Validation RPCs "> I2RS generic interfaces
in I2RS protocol independent modules or I2RS protocol dependent modules
should be able to optionally create rpcs which store configuration data in the I2RS
ephemeral data store without the normal configuration checking.
The only thing check will be the syntax within the protocol packets.
The data models allowing must provide a "no-checking flag" at
the level the rpc stores the data. For example, the
I2RS RIB could create a rpc for a route-add that allowed
a flag that indicates validation status ("full or no-checks")
</t>
<t hangText="I2RS-DF-REQ-02: XML and JSON: "> encoding formats
SHOULD be supported in RESTCONF and NETCONF.
</t>
<t hangText="I2RS-DF-REQ-03: Transport Protocols: ">MAY be negotiated
between I2RS client and I2RS agent from a list of mandatory
transports and optional transports.
</t>
<t hangText="I2RS-DF-REQ-04: Insecure Transport: ">For a few select
data models, the communication between the I2RS client and I2RS agent
MAY run over an insecure transports. The I2RS client and I2RS agent
should negotiate this insecure protocol, and the portion of the
data model which can be sent via the insecure transport SHOULD
be marked in YANG data model with "i2rs-insecure-transport ok".
</t>
<t hangText="I2RS-DF-REQ-05: Resource Contraints on the I2RS Agent: ">
should have the ability to constraints for OAM functions operating
to limit CPU processing, data rate across a transport,
the rate of publication of data in a subscription,
and logging rates.
</t>
<t hangText="I2RS-DF-REQ-06: Alternative Transport protocols or ports: ">
The I2RS should be able to support an OAM actions that select
alternate transports from available list of transports,
and to support selection of alternate ports for these protocols.
The alternate transports may have constraints
specified for security levels, sizes of messages, or data
flow priorities.
</t>
<t hangText="I2RS-DF-REQ-07: Priorization of Data Flows: ">
The I2RS Agent should be able to prioritize some of the
management data flows in the I2RS Agent-I2RS Client data flows.
This prioriziation can for data schedule for publication,
data flows within a single transport, or data flows
flows within a single transport, or between multiple
data flow streams an I2RS Agent is sending.
This priorization may be for the data flows the
I2RS Agent is receiving.
</t>
<t hangText="DF-REQ-08: Yang indicates rpc with no validation:">
Yang MUST have a way to indicate rpc can write without validating
data except for syntax of data because I2RS client has validated
data.
<list>
<t>ephemeral-validation nocheck"</t>
</list>
</t>
<t hangText="DF-REQ-09: Yang for Data sent over insecure transport :">
Yang MUST have a way to indicate in a data model that insecure transmission is
ok.
<list>
<t>i2rs-transport-insecure ok"</t>
</list>
</t>
</list>
</t>
<t>Requirement for Future versions of I2RS Protocol:
<list style="Hanging">
<t hangText="Future-DF-REQ-01: IPFIX Protocol and templates:" >
SHOULD be supported as an optional component protocol
by the I2RS protocol.</t>
</list>
</t>
</section>
<section title="Generic Interfaces to Routing Functions">
<t> The generic interfaces to the routing system includes
generic interface to the RIB, forwarding policies,
and an interface to the topology information. The existing
I2RS protocol independent data models have provided these generic models
in the I2RS RIB (<xref target="I-D.ietf-i2rs-rib-info-model"></xref>,
<xref target="I-D.ietf-i2rs-rib-data-model"></xref>),
the I2RS Filter-Based RIB (<xref target="I-D.kini-i2rs-fb-rib-info-model"></xref>,
<xref target="I-D.hares-i2rs-fb-rib-data-model"></xref>),
and the topology genetric model (<xref target="I-D.ietf-i2rs-yang-network-topo"></xref>)
and plus layer models (<xref target="I-D.ietf-i2rs-yang-l2-network-topology"></xref>,
<xref target="I-D.ietf-i2rs-yang-l3-topology"></xref>.
</t>
<t>
The only addition to the generic model is the ability for the
I2RS client to be able to do all of the data value checking, and
simply download the data to the I2RS Agent. The I2RS RIB updates
are done with rpcs (rib-add, rib-delete, route-add, route-delete,
route-update, nh-add, nh-delete). The I2RS FB-RIB updates are
done with rpcs (fset-add, fs-dete, fpolicy-add, fpolicy-delete,
fpolicy-update, fgroup-add, fgoup-delete, fgroup-update).
The requirement is to allow create rpcs that do not
require validation, but simply input syntax.
</t>
<section title="I2RS Data Flow Requirements">
<t>
<list style="hanging">
<t hangText="[DF-REQ-01:No Validation RPCs"> I2RS generic interfaces
in I2RS protocol independent modules or I2RS protocol dependent modules
should be able to optionally create rpcs which store configuration data in the I2RS
ephemeral data store without the normal configuration checking.
The only thing check will be the syntax within the protocol packets.
The data models allowing must provide a "no-checking flag" at
the level the rpc stores the data. For example, the
I2RS RIB could create a rpc for a route-add that allowed
a flag that indicates no validation checks.
</t>
</list>
</t>
</section>
</section>
<section title="Large Data Flow Requirements">
<t>This section decribes the I2RS management data flow requirements
for data transfers for large data flows, traffic measurments,
and non-secure data flows.
</t>
<t>Large data transfers to/from the I2RS Agent can be from
tables relating to generic interfaces (RIB, FIB,
Filter-Based RIB policy, generic connectivity topologies),
protocol state, traffic measurements or user state.
The generic interfaces were described in the section above.
</t>
<t>
The I2RS interaction with the protocol are to configure the protocols,
and retrieve general state information (RIB, FIB, topologies and policy).
The data flow for the management of protocol state has the same type of flows.
</t>
<t>The unique type of data flows are management flows based on
traffic flow measurement or I2RS data traveling across insecure connections.
These requirements are described in this section.
</t>
<t>
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. The data flow problems involved in sending monitoring
data during network congestion or outage are considered
in section 5 on operations during network outages or congestoin.
</t>
<section title="Use Case Requirements for Traffic Flow Measurements">
<t>
The I2RS requirements for the Protocol independent use cases
requires the support of traffic flow measurements protocols
(requirements PI-REQ-05, PI-REQ06
in <xref target="I-D.ietf-i2rs-usecase-reqs-summary"></xref>),
and operational state regarding flow filtering.
</t>
<t>The following IETF protocol pass traffic flow measurements:
<list style="symbols">
<t>IPFIX - IP Flow Information (<xref target="RFC7011"></xref>)
that reports on a wide variety of routing system statistics, and
</t>
<t>IPPM - IP Performance mangement
(<xref target="RFC2330"></xref>, <xref target="RFC7312"></xref>)
that reports on one-way or two-way end-to-end network performance statistics,
</t>
</list>
In addition the SFLOW(<xref target="RFC3176"></xref>)
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.
</t>
<t> Flow Filtering data models with policy rules (BGP Flow Specification,
I2RS Filter-Based RIB, and n-tuple policy routing RIB) often save
operational state on how often these policies are match.
</t>
<t>Traffic flow data can provide large streams of traffic.
The I2RS mechanism for handling the data bursts in these protocols
is to utilize a traffic monitoring protocol, IPFIX) or to
utilize a publication/subscription service in order to
send just what clients want.
</t>
</section>
<section title="Protocol Requirements based on Traffic Measurement Data Flows">
<t>
Due to the potentially large data flow the traffic measurment
statistics generate, these statistics are best handled by
publication techniques within NETCONF or a separate protocol such as IPFIX.
The publication/subscription model within NETCONF could use either push
pub-sub model or a pull pub-sub model. Thresholds for reporting can be
set per data models or per client so the pub-sub model allows 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 <xref target="I-D.ietf-netconf-yang-push"></xref>, but
the pull portion of the pub-sub model is not defined.
</t>
<t>The support of IPFIX protocol (<xref target="RFC7011"></xref>)
as a component protocol in I2RS requires the I2RS Agent
supports an IPFIX exporting process sending data to
a I2RS client running an IPFIX collector process.
The IPFIX templates could be stored as ephemeral state or
reference configured 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.
</t>
</section>
<section title="Publication/Subscription Service">
<t>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
<xref target="I-D.ietf-i2rs-pub-sub-requirements"></xref>, and
an example protocol addition to netconf is include in
<xref target="I-D.ietf-netconf-yang-push"></xref>.
</t>
<t>
The requirements for the publication/subscription service for the pull model
are not specified in the <xref target="I-D.ietf-i2rs-pub-sub-requirements"></xref>, 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. </t>
<t>At this time, the pull-model of the publication/subscription model is
not being requested by vendors or operators.
</t>
</section>
<section title="Data Flow Requirements for Transports">
<t>The use case requirements (<xref target="I-D.ietf-i2rs-usecase-reqs-summary"></xref>)
for large data flows also include support for data flows
via any transport (L-Dat-REQ-04) and any data format (L-Data-REQ-05).
</t>
<t>One of the requirements is to be able to support
an insecure transport for a small set of data.
Examples of this type of data may be outage/restoration information the
operator wishes to make public.
</t>
</section>
<section title="I2RS Requirements for Large Data Flow">
<t>Current Data Flow Requirements:
<list style="hanging">
<t hangText="I2RS-DF-REQ-02: XML and JSON: "> encoding formats
SHOULD be supported in RESTCONF and NETCONF.
</t>
<t hangText="I2RS-DF-REQ-03: Transport Protocols: ">MAY be negotiated
between I2RS client and I2RS agent from a list of mandatory
transports and optional transports.
</t>
<t hangText="I2RS-DF-REQ-04: Insecure Transport: ">For a few select
data models, the communication between the I2RS client and I2RS agent
MAY run over an insecure transports. The I2RS client and I2RS agent
should negotiate this insecure protocol, and the portion of the
data model which can be sent via the insecure transport SHOULD
be marked in YANG data model with "i2rs-insecure-transport ok".
</t>
</list>
</t>
<t>Future Data Flow Requirements:
<list style="hanging">
<t hangText="Future-DF-REQ-01: IPFIX Protocol and templates:" >
SHOULD be supported as an optional component protocol
by the I2RS protocol.</t>
</list>
</t>
</section>
</section>
<section title="I2RS Data Flow during OAM or Outages">
<t>
The data flow requirements for Operations and Management (OAM)
actions must be able to be constrained in order not to impact
the routing system. During periods of normal connectivity,
it is important that any OAM function not impact the
the routing systems function. During periods of outage, the I2RS protocol
must operate when data bandwidth is reduced and
network connectivity fluctuates. The constraints on
the I2RS client-agent communication may be increased
or decreased from the normal state depending on what management traffic needs
to flow in order to help detect outages or resist attacks.
</t>
<t>
I2RS agents must be able to adjust operation of
event notifications, logging, or data traffic during these outage periods.
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.
</t>
<t>
A quick list of some of the types of
outages may illustrate why the I2RS agent need the ability to
balance internal processing and the rate of communication
with the I2RS client. Network Outages may occur due
connectivity failures or security attacks. Security attacks
can be distributed or target incidents that exploit
vulnerabilities in software, network devices,
protocols using botnets, malware attacks, identity theft,
port spams, icmp blasts, and other attacks.
Some outages are caused by Distributed Denial of Service (DDoS)
attacks may impact multiple routing systems so
the constraints on management data flow
may be required even when the routing system is not the
specific device under attack.
</t>
<section title="I2RS Data Flow Requirements during OAM or Outages">
<t>
<list style="hanging">
<t hangText="I2RS-DF-REQ-05: Resource Contraints on the I2RS Agent: ">
should have the ability to constraints for OAM functions operating
to limit CPU processing, data rate across a transport,
the rate of publication of data in a subscription,
and logging rates.
</t>
<t hangText="I2RS-DF-REQ-06: Alternative Transport protocols or ports: ">
The I2RS should be able to support an OAM actions that select
alternate transports from available list of transports,
and to support selection of alternate ports for these protocols.
The alternate transports may have constraints
specified for security levels, sizes of messages, or priority
</t>
<t hangText="I2RS-DF-REQ-07: Priorization of Data Flows: ">
The I2RS Agent should be able to prioritize some of the
management data flows in the I2RS Agent-I2RS Client data flows.
This prioriziation can for data schedule for publication,
data flows within a single transport, or data flows
flows within a single transport, or between multiple
data flow streams an I2RS Agent is sending.
</t>
</list>
</t>
</section>
</section>
<section title="Changes to YANG">
<t> To support the above requirements, the
yang modules will need to support the following features:
<list style="hanging">
<t hangText="DF-REQ-08: Yang indicates rpc with no validation:">
Yang MUST have a way to indicate rpc can write without validating
data except for syntax of data because I2RS client has validated
data.
<list>
<t>ephemeral-validation nocheck"</t>
</list>
</t>
<t hangText="DF-REQ-09: Yang for Data sent over insecure transport :">
Yang MUST have a way to indicate in a data model that insecure transmission is
ok.
<list>
<t>i2rs-transport-insecure ok"</t>
</list>
</t>
</list>
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>There are no IANA requirements for this document.</t>
</section>
<section title="Security Considerations">
<t>The security requirements for the I2RS protocol are
covered in <xref target="I-D.ietf-i2rs-protocol-security-requirements"></xref> document.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
The following people have aided in the discuss
<list style="symbols">
<t>Russ White, </t>
<t>Joel Halpern, </t>
<t> Linda Dunbar, </t>
<t> Frank Xia, and </t>
<t>Robert Moskowitz</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&RFC2330;
&RFC3176;
&RFC6020;
&RFC6241;
&RFC7011;
&RFC7312;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-i2rs-usecase-reqs-summary;
&I-D.ietf-i2rs-traceability;
&I-D.ietf-i2rs-pub-sub-requirements;
&I-D.ietf-i2rs-protocol-security-requirements;
&I-D.ietf-i2rs-ephemeral-state;
&I-D.ietf-i2rs-rib-info-model;
&I-D.ietf-i2rs-rib-data-model;
&I-D.ietf-i2rs-yang-network-topo;
&I-D.ietf-i2rs-yang-l2-network-topology;
&I-D.ietf-i2rs-yang-l3-topology;
&I-D.kini-i2rs-fb-rib-info-model;
&I-D.hares-i2rs-fb-rib-data-model;
&I-D.ietf-netconf-yang-push;
&I-D.ietf-netconf-restconf;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 04:05:10 |