< draft-hares-i2rs-usecase-reqs-summary-00.txt   draft-hares-i2rs-usecase-reqs-summary-01.txt >
i2rs S. Hares i2rs S. Hares
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational July 4, 2014 Intended status: Informational M. Chen
Expires: January 5, 2015 Expires: April 30, 2015 Huawei Technologies
October 27, 2014
Summary of I2RS Use Case Requirements Summary of I2RS Use Case Requirements
draft-hares-i2rs-usecase-reqs-summary-00 draft-hares-i2rs-usecase-reqs-summary-01
Abstract Abstract
The I2RS Working Group (WG) has described a set of use cases that the The I2RS Working Group (WG) has described a set of use cases that the
I2RS systems could fulfil. This document summarizes these use cases. I2RS systems could fulfil. This document summarizes these use cases.
It is designed to provide requirements that will aid the design of It is designed to provide requirements that will aid the design of
the I2RS architecture, Information Models, Data Models, Security, and the I2RS architecture, Information Models, Data Models, Security, and
protocols. protocols.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Protocol Independent Use Case Requirements . . . . . . . . . 4 2. Protocol Independent Use Case Requirements . . . . . . . . . 4
3. BGP Use Case Requirements . . . . . . . . . . . . . . . . . . 5 3. BGP Use Case Requirements . . . . . . . . . . . . . . . . . . 6
4. IGP Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 8 4. IGP Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 8
5. CCNE Use Cases . . . . . . . . . . . . . . . . . . . . . . . 9 5. CCNE Use Cases . . . . . . . . . . . . . . . . . . . . . . . 10
6. Topology Related Use Cases . . . . . . . . . . . . . . . . . 10 6. Topology Related Use Cases . . . . . . . . . . . . . . . . . 10
6.1. Virtual Connection Use Case Requirements . . . . . . . . 10 6.1. Virtual Connection Use Case Requirements . . . . . . . . 11
6.2. Virtual Network Use Case Requirements . . . . . . . . . . 11 6.2. Virtual Network Use Case Requirements . . . . . . . . . . 11
6.3. Topology Use Case . . . . . . . . . . . . . . . . . . . . 12 6.3. Topology Use Case . . . . . . . . . . . . . . . . . . . . 12
6.4. Virtual Topology Data Model . . . . . . . . . . . . . . . 17 6.4. Virtual Topology Data Model . . . . . . . . . . . . . . . 17
6.5. Virtual Topology IP Data Model . . . . . . . . . . . . . 18 6.5. Virtual Topology IP Data Model . . . . . . . . . . . . . 18
6.6. Virtual Topology Network Element . . . . . . . . . . . . 19 6.6. Virtual Topology Network Element . . . . . . . . . . . . 19
7. Requirements from SFC Use Cases . . . . . . . . . . . . . . . 20 7. Requirements from SFC Use Cases . . . . . . . . . . . . . . . 20
8. Requirements from Traffic Steering Use Cases . . . . . . . . 21 8. Requirements from Traffic Steering Use Cases . . . . . . . . 21
9. Requirements from MPLS TE Networks Use Cases . . . . . . . . 22 9. Requirements from MPLS TE Networks Use Cases . . . . . . . . 22
10. Requirements from MPLS LDP Networks Use Cases . . . . . . . . 24 10. Requirements from MPLS LDP Networks Use Cases . . . . . . . . 24
11. Requirements from Mobile Backhaul Ues Cases . . . . . . . . . 25 11. Requirements from Mobile Backhaul Ues Cases . . . . . . . . . 25
12. Requirements from :arge Data Flows are . . . . . . . . . . . 27 12. Requirements from Large Data Flows are . . . . . . . . . . . 27
13. Large Data Collection Systems . . . . . . . . . . . . . . . . 28 13. Large Data Collection Systems . . . . . . . . . . . . . . . . 28
14. CDNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 14. CDNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
16. Security Considerations . . . . . . . . . . . . . . . . . . . 30 16. Security Considerations . . . . . . . . . . . . . . . . . . . 31
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
17.1. Normative References . . . . . . . . . . . . . . . . . . 31 17.1. Normative References . . . . . . . . . . . . . . . . . . 31
17.2. Informative References . . . . . . . . . . . . . . . . . 31 17.2. Informative References . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
The Architecture for the Interface to the Routing System The Architecture for the Interface to the Routing System
[I-D.ietf-i2rs-architecture] allows for a mechanism where the [I-D.ietf-i2rs-architecture] allows for a mechanism where the
distributed control plane can be augmented by an outside control distributed control plane can be augmented by an outside control
plane through an open, accessible interface. This document plane through an open, accessible interface. This document
summarizes the use case requirements for theI2RS client-I2RS Agent summarizes the use case requirements for theI2RS client-I2RS Agent
exchange found in the following documents: exchange found in the following documents:
skipping to change at page 3, line 49 skipping to change at page 4, line 4
o IGP - IGP protocols o IGP - IGP protocols
o CCNE - CCNE control of forwarding path o CCNE - CCNE control of forwarding path
o VCoD - Virtual Connections on Demand o VCoD - Virtual Connections on Demand
o VNoD - Virtual Networks on Demand o VNoD - Virtual Networks on Demand
o Topo - Topology Information o Topo - Topology Information
o VT-TMD - Virtual Topology: Topology Data Model o VT-TMD - Virtual Topology: Topology Data Model
o VT-TDM-IP - Virtual Topology: Topology Data Mode for IP/MPLS o VT-TDM-IP - Virtual Topology: Topology Data Mode for IP/MPLS
o SFC - Service Chaining requirements o SFC - Service Chaining requirements
o TS - Traffic Steering o TS - Traffic Steering
o MPLS-LDP - MLPS Topologies supported by LDP o MPLS-LDP - MLPS Topologies supported by LDP
o MPLS-TE - MPLS-TE topologies o MPLS-TE - MPLS-TE topologies
o MBH - Mobile Back-Haul o MBH - Mobile Back-Haul
o L-Flow - Large Flows o L-Flow - Large Flows
o L-Data - Large Data Collection o L-Data - Large Data Collection
o CDNI - CDNI networks o CDNI - CDNI networks
Each use case is also augmented with a notation signifying whether it
is in or out of scope with regard to the current I2RS charter:
o IC: In charter
o OC: Out of charter
o NA: not applicable to I2RS protocol, agent, client or models.
Usually related to specific client-side app requirements.
o ??: indicates this item needs additional classification aid from
the WG.
In some cases a specific draft may be out of charter, but
(sub)components of it's requirement set may be in charter. In
charter. As such, (IC|OC|NA) designations may appear at the draft
level, at the requirement level, or at the sub requirement level. In
instances where designations do not appear at more specific level,
the designation at the parent level should be considered to be
inherited.
2. Protocol Independent Use Case Requirements 2. Protocol Independent Use Case Requirements
This is a summary of the I2RS requirements found in the Protocol This is a summary of the I2RS requirements found in the Protocol
Independent Use Cases described in: [I-D.white-i2rs-use-case]: Independent Use Cases described in: [I-D.white-i2rs-use-case] (IC):
o PI-REQ01: The ability to monitor the available routes installed in o PI-REQ01 (IC): The ability to monitor the available routes
the RIB of each forwarding device, including near real time installed in the RIB of each forwarding device, including near
notification of route installation and removal. This information real time notification of route installation and removal. This
must include the destination prefix (NLRI), a table identifier (if information must include the destination prefix (NLRI), a table
the forwarding device has multiple forwarding instances), the identifier (if the forwarding device has multiple forwarding
metric of the installed route, and an identifier indicating the instances), the metric of the installed route, and an identifier
installing process. indicating the installing process.
o PI-REQ02: The ability to install source and destination based o PI-REQ02 (IC): The ability to install source and destination based
routes in the local RIB of each forwarding device. This must routes in the local RIB of each forwarding device. This must
include the ability to supply the destination prefix (NLRI), the include the ability to supply the destination prefix (NLRI), the
source prefix (NLRI), a table identifier (if the forwarding device source prefix (NLRI), a table identifier (if the forwarding device
has multiple forwarding instances), a route preference, a route has multiple forwarding instances), a route preference, a route
metric, a next hop, an outbound interface, and a route process metric, a next hop, an outbound interface, and a route process
identifier. identifier.
o PI-REQ03: The ability to install a route to a null destination, o PI-REQ03 (IC): The ability to install a route to a null
effectively filtering traffic to this destination. destination, effectively filtering traffic to this destination.
o PI-REQ04: The ability to interact with various policies configured o PI-REQ04(??): The ability to interact with various policies
on the forwarding devices, in order to inform the policies configured on the forwarding devices, in order to inform the
implemented by the dynamic routing processes. This interaction policies implemented by the dynamic routing processes. This
should be through existing configuration mechanisms, such as interaction should be through existing configuration mechanisms,
NETCONF, and should be recorded in the configuration of the local such as NETCONF, and should be recorded in the configuration of
device so operators are aware of the full policy implemented in the local device so operators are aware of the full policy
the network from the running configuration. implemented in the network from the running configuration.
o PI-REQ05: The ability to interact with traffic flow and other o PI-REQ05 (OC): The ability to interact with traffic flow and other
network traffic level measurement protocols and systems, in order network traffic level measurement protocols and systems, in order
to determine path performance, top talkers, and other information to determine path performance, top talkers, and other information
required to make an informed path decision based on locally required to make an informed path decision based on locally
configured policy. configured policy.
o PI-REQ06: The ability to install destination based routes in the o PI-REQ06 (IC): The ability to install destination based routes in
local RIB of each forwarding device. This must include the the local RIB of each forwarding device. This must include the
ability to supply the destination prefix (NLRI), a table ability to supply the destination prefix (NLRI), a table
identifier (if the forwarding device has multiple forwarding identifier (if the forwarding device has multiple forwarding
instances), a route preference, a route metric, a next hop, an instances), a route preference, a route metric, a next hop, an
outbound interface, and a route process identifier. outbound interface, and a route process identifier.
o PI-REQ07: The ability to read the local RIB of each forwarding o PI-REQ07 (IC): The ability to read the local RIB of each
device, including the destination prefix (NLRI), a table forwarding device, including the destination prefix (NLRI), a
identifier (if the forwarding device has multiple forwarding table identifier (if the forwarding device has multiple forwarding
instances), the metric of each installed route, a route instances), the metric of each installed route, a route
preference, and an identifier indicating the installing process. preference, and an identifier indicating the installing process.
o PI-REQ08: The ability to read the tables of other local protocol o PI-REQ08 (IC): The ability to read the tables of other local
processes running on the device. This reading action should be protocol processes running on the device. This reading action
supported through an import/export interface which can present the should be supported through an import/export interface which can
information in a consistent manner across all protocol present the information in a consistent manner across all protocol
implementations, rather than using a protocol specific model for implementations, rather than using a protocol specific model for
each type of available process. each type of available process.
o PI-REQ09: The ability to inject information directly into the o PI-REQ09 (OC for some protocols): The ability to inject
local tables of other protocol processes running on the forwarding information directly into the local tables of other protocol
device. This injection should be supported through an import/ processes running on the forwarding device. This injection should
export interface which can inject routing information in a be supported through an import/export interface which can inject
consistent manner across all protocol implementations, rather than routing information in a consistent manner across all protocol
using a protocol specific model for each type of available implementations, rather than using a protocol specific model for
process. each type of available process.
o PI-REQ10: The ability to interact with policies and configurations o PI-REQ10 (OC): The ability to interact with policies and
on the forwarding devices using time based processing, either configurations on the forwarding devices using time based
through timed auto-rollback or some other mechanism. This processing, either through timed auto-rollback or some other
interaction should be through existing configuration mechanisms, mechanism. This interaction should be through existing
such as NETCONF, and should be recorded in the configuration of configuration mechanisms, such as NETCONF, and should be recorded
the local device so operators are aware of the full policy in the configuration of the local device so operators are aware of
implemented in the network from the running configuration. the full policy implemented in the network from the running
configuration.
3. BGP Use Case Requirements 3. BGP Use Case Requirements
This is a summary of the requirements listed in This is a summary of the requirements listed in
[I-D.keyupate-i2rs-bgp-usecases] are: [I-D.keyupate-i2rs-bgp-usecases] are (IC):
o BGP-REQ01: I2RS client/agent exchange SHOULD support the read, o BGP-REQ01 (IC): I2RS client/agent exchange SHOULD support the
write and quick notification of status of the BGP peer operational read, write and quick notification of status of the BGP peer
state on each router within a given Autonomous System (AS). This operational state on each router within a given Autonomous System
operational status includes the quick notification of protocol (AS). This operational status includes the quick notification of
events that proceed a destructive tear-down of BGP session protocol events that proceed a destructive tear-down of BGP
session
o BGP-REQ02: I2RS client SHOULD be able to push BGP routes with o BGP-REQ02 (IC): I2RS client SHOULD be able to push BGP routes with
custom cost communities to specific I2RS agents on BGP routers for custom cost communities to specific I2RS agents on BGP routers for
insertion in specific BGP Peer(s) to aid Traffic engineering of insertion in specific BGP Peer(s) to aid Traffic engineering of
data paths. These routes SHOULD be tracked by the I2RS Agent as data paths. These routes SHOULD be tracked by the I2RS Agent as
specific BGP routes with customer cost communities. These routes specific BGP routes with customer cost communities. These routes
(will/will not) installed via the RIB-Info. (will/will not) installed via the RIB-Info.
o BGP-REQ03: I2RS client SHOULD be able to track via read/ o BGP-REQ03 (IC): I2RS client SHOULD be able to track via read/
notifications all Traffic engineering changes applied via I2RS notifications all Traffic engineering changes applied via I2RS
agents to BGP route processes in all routers in a network. agents to BGP route processes in all routers in a network.
o BGP-REQ04: I2RS Agents SHOULD support identification of routers as o BGP-REQ04 (IC): I2RS Agents SHOULD support identification of
BGP ASBRs, PE routers, and IBGP routers. routers as BGP ASBRs, PE routers, and IBGP routers.
o BGP-REQ05: I2RS client-agent SHOULD support writing traffic flow o BGP-REQ05 (IC): I2RS client-agent SHOULD support writing traffic
specifications to I2RS Agents that will install them in associated flow specifications to I2RS Agents that will install them in
BGP ASBRs and the PE routers. associated BGP ASBRs and the PE routers.
o BGP-REQ06: I2RS Client SHOULD be able to track flow specifications o BGP-REQ06 (IC): I2RS Client SHOULD be able to track flow
installed within a IBGP Cloud within an AS via reads of BGP Flow specifications installed within a IBGP Cloud within an AS via
Specification information in I2RS Agent, or via notifications from reads of BGP Flow Specification information in I2RS Agent, or via
I2RS agent notifications from I2RS agent
o BGP-REQ07: I2RS client-agent exchange SHOULD support the I2RS o BGP-REQ07 (IC): I2RS client-agent exchange SHOULD support the I2RS
client being able to prioritize and control BGP's announcement of client being able to prioritize and control BGP's announcement of
flow specifications after status information reading BGP ASBR and flow specifications after status information reading BGP ASBR and
PE router's capacity. BGP ASBRs and PE routers functions within a PE router's capacity. BGP ASBRs and PE routers functions within a
router MAY forward traffic flow specifications received from EBGP router MAY forward traffic flow specifications received from EBGP
speakers to I2RS agents, so the I2RS Agent SHOULD be able to send speakers to I2RS agents, so the I2RS Agent SHOULD be able to send
these flow specifications from EBGP sources to a client in these flow specifications from EBGP sources to a client in
response to a read or notification. response to a read or notification.
o BGP-REQ08: I2RS Client SHOULD be able to read BGP route filter o BGP-REQ08 (IC): I2RS Client SHOULD be able to read BGP route
information from I2RS Agents associated with legacy BGP routers, filter information from I2RS Agents associated with legacy BGP
and write filter information via the I2RS agent to be installed in routers, and write filter information via the I2RS agent to be
BGP RR. The I2RS Agent SHOULD be able to install these routes in installed in BGP RR. The I2RS Agent SHOULD be able to install
the BGP RR, and engage a BGP protocol action to push these routers these routes in the BGP RR, and engage a BGP protocol action to
to ASBR and PE routers. push these routers to ASBR and PE routers.
o BGP-REQ09: I2RS client(s) SHOULD be able to request the I2RS agent o BGP-REQ09 (IC): I2RS client(s) SHOULD be able to request the I2RS
to read BGP routes with all BGP parameters that influence BGP best agent to read BGP routes with all BGP parameters that influence
path decision, and write appropriate changes to the BGP Routes to BGP best path decision, and write appropriate changes to the BGP
BGP and to the RIB-Info in order to manipulate BGP routes Routes to BGP and to the RIB-Info in order to manipulate BGP
routes
o BGP-REQ10: I2RS client SHOULD be able instruct the I2RS agent(s) o BGP-REQ10 (IC): I2RS client SHOULD be able instruct the I2RS
to notify the I2RS client when the BGP processes on an associated agent(s) to notify the I2RS client when the BGP processes on an
routing system observe a route change to a specific set of IP associated routing system observe a route change to a specific set
Prefixes and associated prefixes. Route changes include: 1) of IP Prefixes and associated prefixes. Route changes include: 1)
prefixes being announced or withdrawn, 2) prefixes being prefixes being announced or withdrawn, 2) prefixes being
suppressed due to flap damping, or 3) prefixes using an alternate suppressed due to flap damping, or 3) prefixes using an alternate
best-path for a given IP Prefix. The I2RS agent should be able to best-path for a given IP Prefix. The I2RS agent should be able to
notify the client via publish or subscribe mechanism. notify the client via publish or subscribe mechanism.
o BGP-REQ11: I2RS client SHOULD be able to read BGP route o BGP-REQ11 (IC): I2RS client SHOULD be able to read BGP route
information from BGP routers on routes in received but rejected information from BGP routers on routes in received but rejected
from ADJ-RIB-IN due to policy, on routes installed in ADJ-RIB-IN, from ADJ-RIB-IN due to policy, on routes installed in ADJ-RIB-IN,
but not selected as best path, and on route not sent to IBGP peers but not selected as best path, and on route not sent to IBGP peers
(due to non-selection). (due to non-selection).
o BGP-REQ12: I2RS client SHOULD be able to request the I2RS agent to o BGP-REQ12 (IC): I2RS client SHOULD be able to request the I2RS
read installed BGP Policies. agent to read installed BGP Policies.
o BGP-REQ13: I2RS client SHOULD be able to instruct the I2RS Agent o BGP-REQ13 (IC): I2RS client SHOULD be able to instruct the I2RS
to write BGP Policies into the running BGP protocols and into the Agent to write BGP Policies into the running BGP protocols and
BGP configurations. into the BGP configurations.
o BGP-REQ14: I2RS client-agent SHOULD be able to read BGP statistics o BGP-REQ14 (IC): I2RS client-agent SHOULD be able to read BGP
associated with Peer, and to receive notifications when certain statistics associated with Peer, and to receive notifications when
statistics have exceeded limits. An example of one of these certain statistics have exceeded limits. An example of one of
protocol statistics is the max-prefix limit. these protocol statistics is the max-prefix limit.
o BGP-REQ15: The I2RS client via the I2RS agent MUST have the o BGP-REQ15 (IC): The I2RS client via the I2RS agent MUST have the
ability to read the loc-RIB-In BGP table that gets all the routes ability to read the loc-RIB-In BGP table that gets all the routes
that the CE has provided to a PE router. that the CE has provided to a PE router.
o BGP-REQ16: The I2RS client via the I2RS agent MUST have the o BGP-REQ16 (IC): The I2RS client via the I2RS agent MUST have the
ability to install destination based routes in the local RIB of ability to install destination based routes in the local RIB of
the PE devices. This must include the ability to supply the the PE devices. This must include the ability to supply the
destination prefix (NLRI), a table identifier, a route preference, destination prefix (NLRI), a table identifier, a route preference,
a route metric, a next-hop tunnel through which traffic would be a route metric, a next-hop tunnel through which traffic would be
carried carried
o BGP-REQ17: The I2RS client via the I2RS agent SHOULD have the the o BGP-REQ17 (IC): The I2RS client via the I2RS agent SHOULD have the
ability to read the loc-RIB-in BGP table to discover overlapping the ability to read the loc-RIB-in BGP table to discover
routes, and determine which may be safely marked for removal. overlapping routes, and determine which may be safely marked for
removal.
o BGP-REQ18: The I2RS client via the I2RS Agent SHOULD have the o BGP-REQ18 (IC): The I2RS client via the I2RS Agent SHOULD have the
ability to modify filtering rules and initiate a re-computation of ability to modify filtering rules and initiate a re-computation of
the local BGP table through those policies to cause specific the local BGP table through those policies to cause specific
routes to be marked for removal at the outbound eBGP edge. routes to be marked for removal at the outbound eBGP edge.
4. IGP Use Cases 4. IGP Use Cases
This is a summary of the requirements listed in (ietf-draft-wu-ir2s- This is a summary of the requirements listed in (ietf-draft-wu-ir2s-
igp-usecases-00.txt) igp-usecases-00.txt) (OC):
o IGP-REQ-01: I2RS Client/Agent SHOULD Be able to read/write the the o IGP-REQ-01 (OC): I2RS Client/Agent SHOULD Be able to read/write
unique IGP identification for router within an AS (router-id, the the unique IGP identification for router within an AS (router-
system-id, or others). I2RS agents may notify the I2RS client of id, system-id, or others). I2RS agents may notify the I2RS client
the detection of another router with the same unique ID of the detection of another router with the same unique ID.
o IGP-REQ-02: I2RS Client SHOULD BE able to aid in IGP table o IGP-REQ-02 (OC): I2RS Client SHOULD BE able to aid in IGP table
reduction by actively monitoring IGP tables, allowing updates of reduction by actively monitoring IGP tables and by allowing
IGP configuration in order to partition the IGPS and place ABR and changes to the IGP configuration in order to partition the IGPS
ASBRs. The I2RS Client/Agent exchange must allopw for a rapid and place ABRs and ASBRs. The I2RS Client/Agent exchange must
cycle of querying of IGP topology information and downloading of a allow for a rapid cycle of querying of IGP topology information
new protocol configuration to rapidly switch to new temporary IGP and downloading of a new protocol configuration or updating of IGP
topologies. nexthops in RIBs and FIBs to rapidly switch to new temporary IGP
topologies. These alternate topologies may be calculated by a
application attached to the i2rs client and updated to the i2rs
agent, or determined at the i2rs agent.
o IGP-REQ-03: I2RS protocol and models should support Loop-Free o IGP-REQ-03 (OC): I2RS protocol and models should support Loop-Free
Alternative (LFAs) [RFC5286] deployments in in pure IP and MPLS/ Alternative (LFAs) [RFC5286] deployments in in pure IP and MPLS/
LDP networks to provide single-point-failure protection for LDP networks to provide single-point-failure protection for
unicast traffic. This includes the configuration, monitoring of unicast traffic. This includes the configuration, monitoring of
LFA changes, and letting off-line pre-computed paths for LFA LFA changes, and letting off-line pre-computed paths for LFA
backup of all links and prefixes in the network and calculating backup of all links and prefixes in the network and calculating
the protection coverage and recognizing optimization to be the protection coverage and recognizing optimization to be
downloaded to appropriate devices via the I2RS interface (Client- downloaded to appropriate devices via the I2RS interface (Client-
Agent). Again, it is important to have deployment of changes Agent). Again, it is important to have deployment of changes
followed by real-time feedback. followed by real-time feedback.
o IGP-REQ-04: The I2RS programmatic interface SHOULD allow the o IGP-REQ-04 (OC): The I2RS programmatic interface SHOULD allow the
balancing of both ECMP traffic flows and end-to-end traffic flows balancing of both ECMP traffic flows and end-to-end traffic flows
in the IGP. The I2RS SHOULD support monitoring of the dynamic in the IGP. The I2RS SHOULD support monitoring of the dynamic
traffic flow in the network, and the query of the maximum capacity traffic flow in the network, and the query of the maximum capacity
of the network. This include the I2RS client's transmission to of the network. This include the I2RS client's transmission to
the I2RS agent of updated configuration after an off-line the I2RS agent of updated configuration after an off-line
optimization to either spread traffic (across ECMP pathways) or optimization to either spread traffic (across ECMP pathways) or
aggregation of traffic onto a single path so the rest of the aggregation of traffic onto a single path so the rest of the
devices may power off saving power (and money. devices may power off saving power (and money.
o IGP-REQ-05: The I2RS interface (protocol and data models) SHOULD o IGP-REQ-05 (OC): The I2RS interface (protocol and data models)
use the subscription mechanism to filter the topology changes to SHOULD use the subscription mechanism to filter the topology
interested events and use the publish mechanism to control the changes to interested events and use the publish mechanism to
pace these events are notified. This filtering should protect the control the pace these events are notified. This filtering should
I2RS Client or even applications who depend on topology data from protect the I2RS Client or even applications who depend on
being drowned by massive original events or duplicate events from topology data from being drowned by massive original events or
different sources duplicate events from different sources
o IGP-REQ-06: Since IGP protocol is essential to the whole network, o IGP-REQ-06 (OC): Since IGP protocol is essential to the whole
the I2RS Clients SHOULD monitor about the protocol's running network, the I2RS Clients SHOULD monitor about the protocol's
status before forwarding is impacted. Performance data can be running status before forwarding is impacted. Performance data
collected through collecting static configuration and observing can be collected through collecting static configuration and
dynamic status. Static data includes the number of instances, observing dynamic status. Static data includes the number of
interfaces, nodes in the network and etc. Dynamic data includes instances, interfaces, nodes in the network and etc. Dynamic data
adjacency status, the number of entries in link-state database and includes adjacency status, the number of entries in link-state
in the routing table, the calculation status, the overload status, database and in the routing table, the calculation status, the
the graceful switch-over status, and others overload status, the graceful switch-over status, and others
o IGP-REQ-07: The I2RS interface (protocol and IMs) should support a o IGP-REQ-07 (OC): The I2RS interface (protocol and IMs) should
mechanism where the I2RS Clients can subscribe to the I2RS Agent's support a mechanism where the I2RS Clients can subscribe to the
notification of critical node IGP events. For example, link-state I2RS Agent's notification of critical node IGP events. For
database or routing table is under the status of overflow or the example, link-state database or routing table is under the status
overflow status is released, the calculation continues for a long of overflow or the overflow status is released, the calculation
time, the system is under graceful reboot. continues for a long time, the system is under graceful reboot.
o IGP-REQ-08: The I2RS interface (protocol and IMs) should support o IGP-REQ-08 (OC): The I2RS interface (protocol and IMs) should
the reporting of IGP statistic such as dropped packet statistics. support the reporting of IGP statistic such as dropped packet
These statistics will aid detection of network failures or statistics. These statistics will aid detection of network
secruity attacks. failures or secruity attacks.
5. CCNE Use Cases 5. CCNE Use Cases
The use cases in I2RS Use Cases for Control of the Forwarding Path by The use cases in I2RS Use Cases for Control of the Forwarding Path by
a Central Control Network Element (CCNE) a Central Control Network Element (CCNE)
[I-D.ji-i2rs-usecases-ccne-service] indicate the following [I-D.ji-i2rs-usecases-ccne-service] indicate the following
requirements for I2RS: requirements for I2RS (OC):
o CCNE-REQ-01: I2RS interface should support I2RS client running on o CCNE-REQ-01 (IC): I2RS interface should support I2RS client
a CCNE to be able to pull information from both the BGP RR and the running on a CCNE to be able to pull information from both the BGP
PCE. This information can include: BGP topology information, BGP RR and the PCE. This information can include: BGP topology
routes, BGP statistics, BGP Peer topologies, PCE topology information, BGP routes, BGP statistics, BGP Peer topologies, PCE
information, and PCE state information. The I2RS Client's request topology information, and PCE state information. The I2RS
for reading of the RR and PCE topology information needs to have Client's request for reading of the RR and PCE topology
timely and rapid response from the I2RS Agent. information needs to have timely and rapid response from the I2RS
Agent.
o CCNE-REQ-02: I2RS client should be able to set resource o CCNE-REQ-02 (IC for some constraints): I2RS client should be able
constraints at the I2RS Agent, and receive status information on to set resource constraints at the I2RS Agent, and receive status
the setting of resource constraints. information on the setting of resource constraints.
o CCNE-REQ-03: I2RS interface should be able to set service goal o CCNE-REQ-03 (IC for some constraints): I2RS interface should be
value to CCNE. able to set service goal value to CCNE.
o CCNE-REQ-04: I2RS client should be able support information models o CCNE-REQ-04 (OC): I2RS client should be able support information
that allow re-optimization traffic model at at CCNE . models that allow re-optimization traffic model at at CCNE .
o CCNE-REQ-05: I2RS client should be able to receive notification at o CCNE-REQ-05 (IC): I2RS client should be able to receive
the CCNE, and be able to send status to the I2RS agent. notification at the CCNE, and be able to send status to the I2RS
agent.
o CCNE-REQ-06: I2RS client should work in parallel with traditional o CCNE-REQ-06 (NA): I2RS client should work in parallel with
network management or OAM protocols sent to the general NE. traditional network management or OAM protocols sent to the
general NE.
o CCNE-REQ-07: I2RS clients should be able to to be light weight o CCNE-REQ-07 (NA): I2RS clients should be able to to be light
enough to be able to support running on a variety of devices weight enough to be able to support running on a variety of
(routers, centralized servers, or devices doing both). devices (routers, centralized servers, or devices doing both).
6. Topology Related Use Cases 6. Topology Related Use Cases
This section describes Topology or Virtual Topology related This section describes Topology or Virtual Topology related
requirements the I2RS interface (protocol and information model (IM) requirements the I2RS interface (protocol and information model (IM)
included in the following types of use cases: included in the following types of use cases:
o Virtual Connections on Demand: VCoD-REQ o Virtual Connections on Demand: VCoD-REQ
o Virtual Networks on Demand: VNoD-REQ o Virtual Networks on Demand: VNoD-REQ
skipping to change at page 10, line 38 skipping to change at page 11, line 19
o Virtual Topology Information Topo-REQ o Virtual Topology Information Topo-REQ
o Virtual Topology Data Model: VT-TDM-REQ o Virtual Topology Data Model: VT-TDM-REQ
o Virtual Topology IP Data Model: VT-TDMIP-REQ o Virtual Topology IP Data Model: VT-TDMIP-REQ
o Virtual Topology Network Element: VT-NE-REQ (TMF-GEN-1) o Virtual Topology Network Element: VT-NE-REQ (TMF-GEN-1)
6.1. Virtual Connection Use Case Requirements 6.1. Virtual Connection Use Case Requirements
o VCoD-REQ01: I2RS Agents SHOULD provide the ability to read the o VCoD-REQ01 (OC): I2RS Agents SHOULD provide the ability to read
virtual network topology database for the technology supported. the virtual network topology database for the technology
For optical, these are the optical connections and what node they supported. For optical, these are the optical connections and
connect to, and the topologies created. For MPLS, this is virtual what node they connect to, and the topologies created. For MPLS,
circuit available, what nodes they connect to, and the network this is virtual circuit available, what nodes they connect to, and
topologies created. For IP technologies, this could include the the network topologies created. For IP technologies, this could
GRE tunnels, what interface it connects to, and the topologies include the GRE tunnels, what interface it connects to, and the
created. For Ethernet circuits this should involve circuit type topologies created. For Ethernet circuits this should involve
(e.g, point-to-point (p2p) or point-to-multipoint (p2mp)) and what circuit type (e.g, point-to-point (p2p) or point-to-multipoint
nodes it can reach, and the topologies created. (p2mp)) and what nodes it can reach, and the topologies created.
o VCoD-REQ02: I2RS Agent SHOULD provide the ability to influence the o VCoD-REQ02 (OC): I2RS Agent SHOULD provide the ability to
configuration of a virtual circuit in a node. influence the configuration of a virtual circuit in a node.
o VCoD-REQ03: I2RS Agent SHOULD provide monitor and provide o VCoD-REQ03 (OC): I2RS Agent SHOULD provide monitor and provide
statistics on the virtual connection to the I2RS client via a Read statistics on the virtual connection to the I2RS client via a Read
request or status Notification. The I2RS client can then request or status Notification. The I2RS client can then
determine if the connection falls below a quality level the determine if the connection falls below a quality level the
application has requested. If the I2RS client does determine the application has requested. If the I2RS client does determine the
circuit is below the required quality, it could create another circuit is below the required quality, it could create another
circuit. The I2RS may choose to create the second virtual circuit. The I2RS may choose to create the second virtual
circuit, transfer flows, and then break the first circuit. circuit, transfer flows, and then break the first circuit.
6.2. Virtual Network Use Case Requirements 6.2. Virtual Network Use Case Requirements
The requirements for the Virtual Networks on Demand (VCoD) are: The requirements for the Virtual Networks on Demand (VCoD) are:
o VT-VN-REQ01: I2RS Agents SHOULD provide the ability to read the o VT-VN-REQ01 (IC): I2RS Agents SHOULD provide the ability to read
virtual network topology database for the technology supported to the virtual network topology database for the technology supported
determine nodes and connections. For optical, these are the to determine nodes and connections. For optical, these are the
optical connections and what node they connect to, and the optical connections and what node they connect to, and the
topologies created. For MPLS, this is virtual circuit available, topologies created. For MPLS, this is virtual circuit available,
what nodes they connect to, and the network topologies created. what nodes they connect to, and the network topologies created.
For IP technologies, this could include the GRE tunnels, what For IP technologies, this could include the GRE tunnels, what
interface it connects to, and the topologies created. For interface it connects to, and the topologies created. For
Ethernet circuits this should involve circuit type (e.g, point-to- Ethernet circuits this should involve circuit type (e.g, point-to-
point (p2p) or point-to-multipoint (p2mp)) and what nodes it can point (p2p) or point-to-multipoint (p2mp)) and what nodes it can
reach, and the topologies created. reach, and the topologies created.
o VNoD-REQ02: I2RS Agent SHOULD provide the ability to influence the o VNoD-REQ02 (IC): I2RS Agent SHOULD provide the ability to
configuration of a virtual circuit in a node. influence the configuration of a virtual circuit in a node.
o VNoD-REQ03: I2RS Agent SHOULD provide monitor and provide o VNoD-REQ03 (IC): I2RS Agent SHOULD provide monitor and provide
statistics on the virtual connection to the I2RS client via a Read statistics on the virtual connection to the I2RS client via a Read
request or status Notification. The I2RS client can then request or status Notification. The I2RS client can then
determine if the connection falls below a quality level the determine if the connection falls below a quality level the
application has requested. If the I2RS client does determine the application has requested. If the I2RS client does determine the
circuit is below the required quality, it could create another circuit is below the required quality, it could create another
circuit. The I2RS may choose to create the second virtual circuit. The I2RS may choose to create the second virtual
circuit, transfer flows, and then break the first circuit. circuit, transfer flows, and then break the first circuit.
o VNoD-REQ04: I2RS Agent SHOULD provide the ability to influence the o VNoD-REQ04 (IC): I2RS Agent SHOULD provide the ability to
configuration of a virtual network in a node. influence the configuration of a virtual network in a node.
o VNoD-REQ05: I2RS Agent SHOULD provide the ability to report o VNoD-REQ05 (OC): I2RS Agent SHOULD provide the ability to report
statistics on the network nodes and end-to-end traffic flows via statistics on the network nodes and end-to-end traffic flows via
read of status data or via notifications of status. read of status data or via notifications of status.
o VNoD-REQ06: The I2RS protocol and RIB Informational Model (IM) o VNoD-REQ06 (IC): The I2RS protocol and RIB Informational Model
must support logical tunnels of type MPLS as well as IP, GRE, (IM) must support logical tunnels of type MPLS as well as IP, GRE,
VxLAN and GRE. Large Carrier networks utilize MPLS in a variety VxLAN and GRE. Large Carrier networks utilize MPLS in a variety
of forms (LDP, static MPLS TE, or dynamic TE LSPS created by RSVP- of forms (LDP, static MPLS TE, or dynamic TE LSPS created by RSVP-
TE or CR-LDP). TE or CR-LDP).
o VNoD-REQ07: I2RS SHOULD support Informational Models and featurs o VNoD-REQ07 (IC): I2RS SHOULD support Informational Models and
to allow MPLS technologies to create Hub-spoke topology and features to allow MPLS technologies to create Hub-spoke topology
service routing in networks in Carriers, Enterprise, and Data and service routing in networks in Carriers, Enterprise, and Data
Centers. Centers.
o VNoD-REQ08: I2RS protocols, Information Models, and Data Models o VNoD-REQ08 (IC): I2RS protocols, Information Models, and Data
must be able to support Carriers using these MPLS technologies to Models must be able to support Carriers using these MPLS
support networks for Mobile BackHaul, on-demand MPLS overlays, and technologies to support networks for Mobile BackHaul, on-demand
on-demand video conferencing networkings. MPLS overlays, and on-demand video conferencing networkings.
6.3. Topology Use Case 6.3. Topology Use Case
The requirements in [I-D.amante-i2rs-topology-use-cases] topology use The requirements in [I-D.amante-i2rs-topology-use-cases] topology use
cases focus around the architecture of topology manager, cases focus around the architecture of topology manager,
orchestration manager, and policy in the figure below: orchestration manager, and policy in the figure below (IC):
+---------------+ +---------------+
+----------------+ | +----------------+ |
| Applications |-+ | Applications |-+
+----------------+ +----------------+
^ Websockets, ReST, XMPP... ^ Websockets, ReST, XMPP...
+------------------------+-------------------------+ +------------------------+-------------------------+
| | | | | |
+------------+ +------------------------+ +-------------+ +------------+ +------------------------+ +-------------+
| Policy |<----| Topology Manager |---->|Orchestration| | Policy |<----| Topology Manager |---->|Orchestration|
skipping to change at page 13, line 39 skipping to change at page 13, line 39
+------------------------+------------------------+ +------------------------+------------------------+
| | | | | |
+---------------+ +---------------+ +---------------+ +---------------+ +---------------+ +---------------+
|Network Element| |Network Element| |Network Element| |Network Element| |Network Element| |Network Element|
| +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ |
| |Information| |<-LLDP->| |Information| |<-LMP-->| |Information| | | |Information| |<-LLDP->| |Information| |<-LMP-->| |Information| |
| | Model | | | | Model | | | | Model | | | | Model | | | | Model | | | | Model | |
| +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ | | +-----------+ |
+---------------+ +---------------+ +---------------+ +---------------+ +---------------+ +---------------+
o Topo-REQ:01 The Topology Manager Should be able to collect o Topo-REQ-01 (IC): The Topology Manager Should be able to collect
topological information via the I2RS Client-Exchange exchange from topological information via the I2RS Client-Exchange exchange from
a variety of sources in a normalized topological model. These a variety of sources in a normalized topological model. These
sources can be: sources can be:
* Live Layer IGP IGPs with information about the active topology * Live Layer IGP IGPs with information about the active topology
such as the LSDB database or IGP updates, such as the LSDB database or IGP updates,
* The I2RS must enable the inventory system information to query * The I2RS must enable the inventory system information to query
for information about network components which are not not for information about network components which are not not
visible to active L3. These systems can be active or simply visible to active L3. These systems can be active or simply
invisible to the L3. Examples of this are L2 Ethernet switches invisible to the L3. Examples of this are L2 Ethernet switches
or ROADMS. or ROADMS.
* Statistic Collection systems that provide traffic information, * Statistic Collection systems that provide traffic information,
such as traffic demands or link utilizations. such as traffic demands or link utilizations.
(from section 3.2) (from section 3.2)
o Topo-REQ-02: Topology information is provided from Clients to o Topo-REQ-02 (OC): Topology information is provided from Clients to
high-layer applications via a northbound interface (such as ReST, high-layer applications via a northbound interface (such as ReST,
Websockts, or XMPP. Websockts, or XMPP.
o Topo-REQ-03: Topology Manager should be able to collect and keep o Topo-REQ-03 (IC): Topology Manager should be able to collect and
current topology information for multiple layers of the network: keep current topology information for multiple layers of the
Transport, Ethernet and IP/MPLS, as well as information for network: Transport, Ethernet and IP/MPLS, as well as information
multiple Layer 3 IGP areas and multiple Autonomous Systems (ASes). for multiple Layer 3 IGP areas and multiple Autonomous Systems
This information must contain cross-layer unerlying Shared Risk (ASes). This information must contain cross-layer unerlying
Link Groups (SRLG) within transport or Ethernet layers. (from Shared Risk Link Groups (SRLG) within transport or Ethernet
section 3.2) layers. (from section 3.2)
o Topo-REQ-04: Topology manager be able to use I2RS Client-Agent o Topo-REQ-04 (OC): Topology manager be able to use I2RS Client-
protocol to to collect dynamic inventory information from network Agent protocol to to collect dynamic inventory information from
elements. An example of these protocols are the Link Layer network elements. An example of these protocols are the Link
discovery protocols (LLDP, LMP, etc.) which automatically identify Layer discovery protocols (LLDP, LMP, etc.) which automatically
remote nodes and ports. (from section 3.2) identify remote nodes and ports. (from section 3.2)
o Topo-REQ-05:I2RS Should enable the Policy manager to query and o Topo-REQ-05 (IC):I2RS Should enable the Policy manager to query
store the following types of policies: and store the following types of policies:
* Policies that contain Logical identifier Numbering in order to * Policies that contain Logical identifier Numbering in order to
correlate IP Prefixes to correlate IP Prefixes to
+ link based on link type (P-P, P-PE, or PE-CE), + link based on link type (P-P, P-PE, or PE-CE),
+ IGP Area + IGP Area
+ L2 VLAN assignments + L2 VLAN assignments
skipping to change at page 15, line 5 skipping to change at page 15, line 5
+ BGP node related policies (aggregation routes at node, max- + BGP node related policies (aggregation routes at node, max-
prefix (per node), or AFI/SAFI per node prefix (per node), or AFI/SAFI per node
+ Security policies - with ACLs or rate-limits + Security policies - with ACLs or rate-limits
+ Network Component access policies (for management + Network Component access policies (for management
(from section 3.3) (from section 3.3)
o Topo-REQ-06: I2RS should enable a orchestration manager attached o Topo-REQ-06 (OC): I2RS should enable a orchestration manager
to an I2RS client to communicate with I2RS agents into order to attached to an I2RS client to communicate with I2RS agents into
stitch together End-to-end services for network bandwidth order to stitch together End-to-end services for network bandwidth
optimization, load balancing, and Class-of-Service with point optimization, load balancing, and Class-of-Service with point
services (Firewall or NAT) within the end-to-end service). The services (Firewall or NAT) within the end-to-end service). The
orchestration manager should also be able to immediately schedule orchestration manager should also be able to immediately schedule
any of these resources via the I2RS-Client I2RS agent exchange. any of these resources via the I2RS-Client I2RS agent exchange.
(from section 3.4) (from section 3.4)
o Topp-REQ-07: The I2RS exchange should enable a statistics o Topp-REQ-07 (OC): The I2RS exchange should enable a statistics
collector to collect statistics from the routing function of the collector to collect statistics from the routing function of the
network nodes and archive and aggregate the statistics into a network nodes and archive and aggregate the statistics into a
statistics warehouse. Statistics must be given and stored in an statistics warehouse. Statistics must be given and stored in an
normalized form. Metadata must be stored with the statistics. normalized form. Metadata must be stored with the statistics.
(from section 4.1.1.2) (Editor: there is some suggestion of (from section 4.1.1.2) (Editor: there is some suggestion of
periodic reports) periodic reports)
o Topo-REQ-08: I2RS Client-I2RS agent exchange must be provide o Topo-REQ-08 (IC): I2RS Client-I2RS agent exchange must be provide
enough interoperability that the Topology manager, Policy manager, enough interoperability that the Topology manager, Policy manager,
and inventory systems can be available from different vendors and inventory systems can be available from different vendors
o Topo-REQ-09: TE tunnels must be able to be created by the exchange o Topo-REQ-09 (IC): TE tunnels must be able to be created by the
between the I2RS client and the I2RS agent. (from section 4.1.1) exchange between the I2RS client and the I2RS agent. (from section
4.1.1)
o Topo-Req-10: I2RS must provide a common and up-to-date normalized o Topo-Req-10 (NA): I2RS must provide a common and up-to-date
view of the topologies that that support security auditing, and normalized view of the topologies that that support security
IP/MPLS Provisioning (L2/L3) which includes: auditing, and IP/MPLS Provisioning (L2/L3) which includes:
* Identifying Service PE's in all markets/cities where the * Identifying Service PE's in all markets/cities where the
customer has identified they want service, customer has identified they want service,
* Identifying one or more existing Servies PE's in each city with * Identifying one or more existing Servies PE's in each city with
connectivity to the access network(s) ( e.g.: SONET/TDM) used connectivity to the access network(s) ( e.g.: SONET/TDM) used
to deliver the PE-CE tail circuits to the Service's PE), to deliver the PE-CE tail circuits to the Service's PE),
* Obtain via query/notification the available capacity on * Obtain via query/notification the available capacity on
Services PE in both the PE-CE access interface and its uplinks Services PE in both the PE-CE access interface and its uplinks
to terminate the tail circuit to terminate the tail circuit
* Providing the context in I2RS for an iterative query mechanism * Providing the context in I2RS for an iterative query mechanism
needed by I2RS client attached to the the Topology to narrow needed by I2RS client attached to the the Topology to narrow
down the scope of resources to the set of Services PEs with the down the scope of resources to the set of Services PEs with the
appropriate uplink bandwidth and access circuit capability plus appropriate uplink bandwidth and access circuit capability plus
capacity to realize the requested VPN service. capacity to realize the requested VPN service.
(from section 4.1.2) (from section 4.1.2)
o Topo-REQ-11: The VPN application attached to the I2RS client o Topo-REQ-11 (NA): The VPN application attached to the I2RS client
should be able to hand the I2RS Client a candidate list of Service should be able to hand the I2RS Client a candidate list of Service
PE's and associated access circuits to set up a Customer's VPN PE's and associated access circuits to set up a Customer's VPN
service into the network. (from section 4.1.3) [Editor's note service into the network. (from section 4.1.3) [Editor's note
This request shares requirements with VCoD-REQ-01.] This request shares requirements with VCoD-REQ-01.]
o Topo-REQ-12: The Topology Manager associated with the I2RS client o Topo-REQ-12 (NA): The Topology Manager associated with the I2RS
must be able to use the normalized view of the network to set up client must be able to use the normalized view of the network to
additional queries (or notification publications) to provide an set up additional queries (or notification publications) to
accurate and comprehensive picture in order a) diagnose faults/ provide an accurate and comprehensive picture in order a) diagnose
failures, and b) augment the network with additional services, and faults/failures, and b) augment the network with additional
c) provide network topology maps for different purposes. (from services, and c) provide network topology maps for different
section 4.1.3) purposes. (from section 4.1.3)
o Topo-REQ-13:The I2RS client-agent exchange and informational o Topo-REQ-13 (IC):The I2RS client-agent exchange and informational
models should support a Virtual Network Topology (VNT) comprise of models should support a Virtual Network Topology (VNT) comprise of
one or more LSPS and lower layer resources. The VNT of MPLS must one or more LSPS and lower layer resources. The VNT of MPLS must
be able to link lower layer resources with the higher layer, and be able to link lower layer resources with the higher layer, and
present a normalize form the the PCE as defined [RFC5623]. present a normalize form the the PCE as defined [RFC5623].
o Topo-REQ-14: The I2RS client-agent protocol and models should o Topo-REQ-14 (OC): The I2RS client-agent protocol and models should
support the use of a PCE to compute MPLS-TE paths within an support the use of a PCE to compute MPLS-TE paths within an
"domain" (IGP area), or across multiple "domains" (multi-area AS, "domain" (IGP area), or across multiple "domains" (multi-area AS,
multiple ASes") as specified in [RFC4655]. This means the PCE multiple ASes") as specified in [RFC4655]. This means the PCE
Informational model should support: Informational model should support:
* enhanced computation in the single IGP domain * enhanced computation in the single IGP domain
* cross-AS path computation based on the multiple entrance of * cross-AS path computation based on the multiple entrance of
exit points from an AS, exit points from an AS,
* linking multiple PEs in multiple domains together, and * linking multiple PEs in multiple domains together, and
* synchronization of TED associated with the PCE to the topology * synchronization of TED associated with the PCE to the topology
manager (via I2RS client/messages), and manager (via I2RS client/messages), and
* sending read/writes to the head-end-nodes * sending read/writes to the head-end-nodes
(section 4.3) (section 4.3)
o Topo-REQ-15: the I2RS protocol and Information models should o Topo-REQ-15 (OC): the I2RS protocol and Information models should
support the ALTO ([RFC5693]) generation of abstract network support the ALTO ([RFC5693]) generation of abstract network
topology models and the APIs it support over web-service API. The topology models and the APIs it support over web-service API. The
ALTO abstract network topology comes in two forms: Network Map ALTO abstract network topology comes in two forms: Network Map
(based prefix-to PID mapping), and Cost map. The ALTO map is (based prefix-to PID mapping), and Cost map. The ALTO map is
automatically generated from BGP and IGP data which the ALTO automatically generated from BGP and IGP data which the ALTO
server queries from the network and makes available to server queries from the network and makes available to
applications via web-service API. (from section 4.4) applications via web-service API. (from section 4.4)
6.4. Virtual Topology Data Model 6.4. Virtual Topology Data Model
The [I-D.medved-i2rs-topology-requirements] specifies the following The [I-D.medved-i2rs-topology-requirements] specifies the following
Topology Data Model requirements: Topology Data Model requirements (IC):
VT-TDM-REQ1: The topology data model MAY be able to describe VT-TDM-REQ1 (IC): The topology data model MAY be able to describe
topology and characteristics of the following layers: topology and characteristics of the following layers:
* Optical DWDM (optional), * Optical DWDM (optional) (OC),
* Optical OTN (optional), * Optical OTN (optional) (OC),
* L2 (Aggregated links, L2 topologies), * L2 (Aggregated links, L2 topologies) (IC),
* IP/MPLS, * IP/MPLS (IC),
* VPNs, and * VPNs (IC), and
* Services (such as cloud services, or CDNs). * Services (such as cloud services, or CDNs).
VT-TDM-REQ2: The topology data model MUST support multiple VT-TDM-REQ2 (IC): The topology data model MUST support multiple
Autonomous System deployments. Autonomous System deployments.
VT-TDM-REQ3: The I2RS topology data model must support include VT-TDM-REQ3 (IC): The I2RS topology data model must support
topology information from multiple Administrative Domains or include topology information from multiple Administrative Domains
multiple elements into a single common format. or multiple elements into a single common format.
VT-TDM-REQ4: The I2RS topology data model MUST be able to convey VT-TDM-REQ4 (IC): The I2RS topology data model MUST be able to
enough information so that an I2RS client can correlate topologies convey enough information so that an I2RS client can correlate
in different layers and multiple Autonomous Systems. topologies in different layers and multiple Autonomous Systems.
VT-TDM-REQ5: The topology data model MUST support multi-layer VT-TDM-REQ5 (NA): The topology data model MUST support multi-layer
group of elements as a means of coalescing different SFF Nodes and group of elements as a means of coalescing different SFF Nodes and
links into a network layers from various layers. For example, links into a network layers from various layers. For example,
links with IPv4 addresses might represent Layer 3 of the network links with IPv4 addresses might represent Layer 3 of the network
topology while links with Ethernet MAC addresses might represent topology while links with Ethernet MAC addresses might represent
Layer 2. Layer 2.
VT-TDM-REQ6: The topology model should allow association between VT-TDM-REQ6 (IC): The topology model should allow association
components of different layers. For example, Layer 2 port may between components of different layers. For example, Layer 2 port
have several IPv4/IPv6 interfaces. The Layer-2 port and the IPv4/ may have several IPv4/IPv6 interfaces. The Layer-2 port and the
IPv6 interfaces would have an association. IPv4/IPv6 interfaces would have an association.
VT-TDM-REQ7: The topology model MUST represent both inactive and VT-TDM-REQ7 (NA): The topology model MUST represent both inactive
active topologies in the topology Data base. Inactive topologies and active topologies in the topology Data base. Inactive
may include new line cards, ports in down state, etc. topologies may include new line cards, ports in down state, etc.
VT-TMF-DM-REQ8: The topology data model MUST be hierarchical and VT-TMF-DM-REQ8 (NA): The topology data model MUST be hierarchical
MUST support summarization of sub-topologies. Topology and MUST support summarization of sub-topologies. Topology
summarization and creation of abstract topologies can be provided summarization and creation of abstract topologies can be provided
by either by the application associated with the I2RS client, or by either by the application associated with the I2RS client, or
by the I2RS Agent prior to transmission to the I2RS client. by the I2RS Agent prior to transmission to the I2RS client.
VT-TDM-REQ9: The topology data model MUST be able to describe VT-TDM-REQ9 (IC): The topology data model MUST be able to describe
abstract topologies. Abstract topologies can contain real and abstract topologies. Abstract topologies can contain real and
abstract nodes and real and abstract links. An abstract topology abstract nodes and real and abstract links. An abstract topology
MAY be used by a provider to describe characteristics of a transit MAY be used by a provider to describe characteristics of a transit
network (bandwidth, delay, protection, etc.) network (bandwidth, delay, protection, etc.)
VT-TDM-REQ10: The topology data model MUST support dynamic data, VT-TDM-REQ10 (OC): The topology data model MUST support dynamic
such as link and node utilizations (perhaps as optional data, such as link and node utilizations (perhaps as optional
attributes). attributes).
VT-TDM-REQ11a: The topology data model MUST allow I2RS client- VT-TDM-REQ11a (??): The topology data model MUST allow I2RS
agent to be able to identify and query for the path between two client-agent to be able to identify and query for the path between
nodes. two nodes.
VT-TDM-REQ11b: The topology data model should support the I2RS VT-TDM-REQ11b (OC): The topology data model should support the
Client requesting the I2RS Agent to trace the path at all network I2RS Client requesting the I2RS Agent to trace the path at all
layers that participate in the delivery of packets between two network layers that participate in the delivery of packets between
nodes. This trace MAY involve either an I2RS Agent information two nodes. This trace MAY involve either an I2RS Agent
trace or the I2RS Agent requesting the routing function trace the information trace or the I2RS Agent requesting the routing
path at multiple levels (L3/L2.5/L2/L1) function trace the path at multiple levels (L3/L2.5/L2/L1)
VT-TDM-REQ12: The topology data model MUST support multiple BGP VT-TDM-REQ12 (IC): The topology data model MUST support multiple
Autonomous Systems and multiple IGP areas. Support for multiple BGP Autonomous Systems and multiple IGP areas. Support for
administrative domains is for further study. multiple administrative domains is for further study.
VT-TDM-REQ13: The topology data model MUST be human-friendly, i.e. VT-TDM-REQ13 (IC): The topology data model MUST be human-friendly,
not SNMP MIBs, but something much more analogous to YANG models. i.e. not SNMP MIBs, but something much more analogous to YANG
models.
VT-TDM-REQ14: The data model SHOULD support topology abstraction, VT-TDM-REQ14 (IC): The data model SHOULD support topology
allowing clients that consume topology information in a abstraction, allowing clients that consume topology information in
constrained manner. For example, a client wishing to view only a constrained manner. For example, a client wishing to view only
interfaces and nodes present in a sub-graph of the Layer 3 interfaces and nodes present in a sub-graph of the Layer 3
topology should be able to specify an interest in this subset of topology should be able to specify an interest in this subset of
information rather than having to read out and parse through the information rather than having to read out and parse through the
entire set of links and nodes. entire set of links and nodes.
6.5. Virtual Topology IP Data Model 6.5. Virtual Topology IP Data Model
The [I-D.medved-i2rs-topology-requirements] specifies the following The [I-D.medved-i2rs-topology-requirements] specifies the following
requirements for the Virtual Topology IP Data Model's IP/MPLS links requirements for the Virtual Topology IP Data Model's IP/MPLS links
and topologies: and topologies (IC):
o VT-TDM-IP-REQ1: The I2RS topology data model for the IP/MPLS layer o VT-TDM-IP-REQ1 (IC): The I2RS topology data model for the IP/MPLS
MUST support both link topology and prefixes, layer MUST support both link topology and prefixes,
o VT-TDM-IP-REQ2: The I2RS agent may import topology information o VT-TDM-IP-REQ2 (IC): The I2RS agent may import topology
from the routing processes, IGP process, BGP-LS information, or information from the routing processes, IGP process, BGP-LS
management processes. information, or management processes.
o TM-DM-IP-REQ3: The I2RS SFC Data model must support links that are o TM-DM-IP-REQ3 (IC): The I2RS SFC Data model must support links
IP/MPLS with the following attributes: that are IP/MPLS with the following attributes:
* local and Remote anchor node IDs (Router ID, AS#, Area ID, MT * local and Remote anchor node IDs (Router ID, AS#, Area ID, MT
topology), topology),
* metrics, * metrics,
* admin group, * admin group,
* max bandwidth links * max bandwidth links
skipping to change at page 19, line 41 skipping to change at page 19, line 41
* link characteristics (BW, Delay, error rate) * link characteristics (BW, Delay, error rate)
* Link Description, and * Link Description, and
* Link-specific timers (Hello and Holddown). * Link-specific timers (Hello and Holddown).
6.6. Virtual Topology Network Element 6.6. Virtual Topology Network Element
The [I-D.medved-i2rs-topology-requirements] specifies the following The [I-D.medved-i2rs-topology-requirements] specifies the following
requirements: requirements (IC):
o VT-NE-01: Each network element should contain an inventory data o VT-NE-01 (IC): Each network element should contain an inventory
base which should be a definitive source of information with data base which should be a definitive source of information with
respect to the physical HW and Logical, logically significant respect to the physical HW and Logical, logically significant
identifiers (E.g. VLANs). The I2RS client should be able to identifiers (E.g. VLANs). The I2RS client should be able to
import data from this DB into the I2RS Node IM or SFC IM. import data from this DB into the I2RS Node IM or SFC IM.
o VT-NE-02: The inventory DB of the network element should be o VT-NE-02 (IC): The inventory DB of the network element should be
augmented with the physical properties associated with the ports/ augmented with the physical properties associated with the ports/
interfaces that are directly connected to the device (BW, media interfaces that are directly connected to the device (BW, media
type). The I2RS client should be able to import data from this type). The I2RS client should be able to import data from this
augmented DB into the I2RS Node IM or SFC IM. augmented DB into the I2RS Node IM or SFC IM.
o NE-3: The I2RS client may write information into the NE inventory o NE-3 (NA): The I2RS client may write information into the NE
data base via the Network-element Data Model that the network inventory data base via the Network-element Data Model that the
element may not be able to learn on its own. This information may network element may not be able to learn on its own. This
include the physical location (address), rack/bay information. information may include the physical location (address), rack/bay
information.
7. Requirements from SFC Use Cases 7. Requirements from SFC Use Cases
The SFC use case document in [I-D.bitar-i2rs-service-chaining] The SFC use case document in [I-D.bitar-i2rs-service-chaining]
suggests that the following requirements: suggests that the following requirements (OC):
SFC-Use-REQ01:Address SFC-Use-REQ01 (IC):Address
has the following address requirements: has the following address requirements:
* IP address * IP address
* service-node tuple (service node IP address, Host system * service-node tuple (service node IP address, Host system
address) address)
* host-node tuple (hosting system IP-address, system internal * host-node tuple (hosting system IP-address, system internal
identifier) identifier)
SFC-Use-REQ02:Supported Service Types SFC-Use-REQ02 (IC):Supported Service Types
SHOULD include: NAT, IP Firewall, Load balancer, DPI, and others SHOULD include: NAT, IP Firewall, Load balancer, DPI, and others
SFC-Use-REQ03:Virtual contexts SFC-Use-REQ03 (IC):Virtual contexts
SHOULD include: SHOULD include:
* Maximum Number of virtual contexts supported * Maximum Number of virtual contexts supported
* Current number of virtual contexts in use * Current number of virtual contexts in use
* Number of virtual contexts available * Number of virtual contexts available
* Supported Context (VRF) * Supported Context (VRF)
SFC-Use-REQ04: Customers currently on node SFC-Use-REQ04 (IC): Customers currently on node
SFC-Use-REQ05: Customer Support Table (per customer ID) SFC-Use-REQ05 (IC): Customer Support Table (per customer ID)
* Customer-id * Customer-id
* List of supported Virtual Contexts * List of supported Virtual Contexts
[SFC-Use-REQ06] Service Resource table SFC-Use-REQ06 (OC): Service Resource table
which includes: which includes:
* index: Comprised of service node, virtual context, service type * index: Comprised of service node, virtual context, service type
* service bandwidth capacity * service bandwidth capacity
* supported packet rate (packets/second) * supported packet rate (packets/second)
* supported bandwidth (kps) * supported bandwidth (kps)
* IP Forwarding support: specified as routing-instance(s), RIBs, * IP Forwarding support: specified as routing-instance(s), RIBs,
Address-families supported Address-families supported
* Maximum RIB-size * Maximum RIB-size (WG Note: problematic)
* Maximum Forward Data Base size * Maximum Forward Data Base size (WG Note: problematic)
* Maximum Number of 64 bit statistics counters for policy * Maximum Number of 64 bit statistics counters for policy
accounting accounting
* Maximum number of supported flows for services * Maximum number of supported flows for services (WG Note:
problematic)
[SFC-Use-REQ07] Virtual Network Topology (VNT) SFC-Use-REQ07 (IC): Virtual Network Topology (VNT)
which includes: which includes:
* number of access points to which service topology applies * number of access points to which service topology applies
* topology of access points * topology of access points
8. Requirements from Traffic Steering Use Cases 8. Requirements from Traffic Steering Use Cases
The requirements from the Traffic Steering use case described in The requirements from the Traffic Steering use case described in
[I-D.chen-i2rs-ts-use-case] are: [I-D.chen-i2rs-ts-use-case] are (OC):
o TS-REQ01: The I2RS Client-Agent must be able to collect the o TS-REQ01 (IC): The I2RS Client-Agent must be able to collect the
topology (especially the exit links) and the traffic load of each topology (especially the exit links) and the traffic load of each
link; link;
o TS-REQ02: The I2RS Client-Agent must be able to read the local rib o TS-REQ02 (IC): The I2RS Client-Agent must be able to read the
of each DC/Metro gateway and the policies deployed on each local rib of each DC/Metro gateway and the policies deployed on
gateway; each gateway;
o TS-REQ03: The I2RS Client-Agent must be able to add or delete or o TS-REQ03 (IC): The I2RS Client-Agent must be able to add or delete
modify the relevant rib items and relevant polices to steer the or modify the relevant rib items and relevant polices to steer the
traffic as expected; and adjust traffic placement. traffic as expected; and adjust traffic placement.
o TS-REQ-04: The I2RS Client-Agent must have the ability to collect o TS-REQ-04 (IC): The I2RS Client-Agent must have the ability to
the LSP information either from the PCE or directly from network collect the LSP information either from the PCE or directly from
devices; network devices;
o TS-REQ-05: The I2RS Client-Agent must have the ability to collect o TS-REQ-05 (OC): The I2RS Client-Agent must have the ability to
the traffic matrix of the network, this is used to help the I2RS collect the traffic matrix of the network, this is used to help
client to determine how to adjust the traffic placement; the I2RS client to determine how to adjust the traffic placement;
o TS-REQ-06: The I2RS Client-Agent must have the ability to read the o TS-REQ-06 (IC): The I2RS Client-Agent must have the ability to
rib information and relevant policies of each network node; read the rib information and relevant policies of each network
node;
o TS-REQ-07:collect the topology and segment information needed to o TS-REQ-07 (OC):collect the topology and segment information needed
help the I2RS client to compute the end-to-end path; to help the I2RS client to compute the end-to-end path;
o TS-REQ-08:read rib (especially the segment routing rib) o TS-REQ-08 (OC):read rib (especially the segment routing rib)
information; information;
o TS-REQ-09: add/delete/modify the segment rib, this finally o TS-REQ-09 (??): add/delete/modify the segment rib, this finally
determines how the traffic is forwarded. determines how the traffic is forwarded.
9. Requirements from MPLS TE Networks Use Cases 9. Requirements from MPLS TE Networks Use Cases
Theses are the requirements from the Traffic Steering use case Theses are the requirements from the Traffic Steering use case
described in [I-D.huang-i2rs-mpls-te-usecases]: described in [I-D.huang-i2rs-mpls-te-usecases] (OC):
o MPLS-TE-REQ-01: Network programming software managing the static o MPLS-TE-REQ-01 (OC): Network programming software managing the
CR-LSP devices may incorporate an I2RS Client along with a path static CR-LSP devices may incorporate an I2RS Client along with a
calculation entity, a label management entity, and a bandwidth path calculation entity, a label management entity, and a
management entity. The I2RS Client should be abl to communicate bandwidth management entity. The I2RS Client should be abl to
the static configuration to the network nodes, and monitor the communicate the static configuration to the network nodes, and
status of the CR-LSPs. monitor the status of the CR-LSPs.
o MPLS-TE-REQ-02: The I2Client should be able to synchronously send o MPLS-TE-REQ-02 (OC): The I2Client should be able to synchronously
the configuration for all of the network nodes from egress node to send the configuration for all of the network nodes from egress
ingress node via the I2RS Agents attached to each node, and be node to ingress node via the I2RS Agents attached to each node,
able to delay the final ingress node configuration until all the and be able to delay the final ingress node configuration until
I2RS AGents on all other nodes toward the egress have denoted a all the I2RS AGents on all other nodes toward the egress have
successful path set-up. denoted a successful path set-up.
o [MPLS-TE-REQ-03:] MPLS TE defines abundant constraints such as o MPLS-TE-REQ-03 (OC): MPLS TE defines abundant constraints such as
explicit path, bandwidth, affinity, SRLG, priority, hop limit, and explicit path, bandwidth, affinity, SRLG, priority, hop limit, and
others. The I2RS Client Agent exchange should be able to signal others. The I2RS Client Agent exchange should be able to signal
concurrent local path calculation could obtain an optimized result concurrent local path calculation could obtain an optimized result
and allow more services to be held in a TE network. The I2RS and allow more services to be held in a TE network. The I2RS
Agent should be able to trigger a global concurrent re- Agent should be able to trigger a global concurrent re-
optimization at a specific time on multiple nodes by communicating optimization at a specific time on multiple nodes by communicating
with each node's I2RS agent. with each node's I2RS agent.
o [MPLS-TE-REQ-04:] The I2RS client should be able to manually o MPLS-TE-REQ-04 (NA): The I2RS client should be able to manually
calculate a re-optimization of the the MPLS TE network and send calculate a re-optimization of the the MPLS TE network and send
the new constraints including the calculated path to each node via the new constraints including the calculated path to each node via
the I2RS agent with an indication to re-signal the TE LSPs with the I2RS agent with an indication to re-signal the TE LSPs with
make-before-break method. make-before-break method.
o [MPLS-TE-REQ-05] With I2RS, the node's I2RS agent should be able o MPLS-TE-REQ-05 (OC): With I2RS, the node's I2RS agent should be
to send to an I2RS client a status notification that not enough able to send to an I2RS client a status notification that not
resources exist for a back up LSP and TE tunnel. Upon receiving enough resources exist for a back up LSP and TE tunnel. Upon
this notification the I2RS client should be able to trigger receiving this notification the I2RS client should be able to
concurrent calculation for the failed path calculation of the trigger concurrent calculation for the failed path calculation of
backup LSP or TE tunnel and send the updated paths to I2RS agents the backup LSP or TE tunnel and send the updated paths to I2RS
with a command to re-signal the TE LSPS with make-before-break agents with a command to re-signal the TE LSPS with make-before-
Method. break Method.
o [MPLS-TE-REQ-06] With I2RS, upon receipt the failure notification o MPLS-TE-REQ-06 (NA): With I2RS, upon receipt the failure
from an I2RS Agent, the I2RS client would create a global notification from an I2RS Agent, the I2RS client would create a
concurrent optimization to handle the failure event. This would global concurrent optimization to handle the failure event. This
occur by the I2RS client signalling the I2RS agents on all nodes would occur by the I2RS client signalling the I2RS agents on all
to: a) trigger a new concurrent calculation of the backup LSP or nodes to: a) trigger a new concurrent calculation of the backup
TE tunnel via failed path calculation, and b) re-signal updates to LSP or TE tunnel via failed path calculation, and b) re-signal
the TE LSPs process with a make-before-break method. updates to the TE LSPs process with a make-before-break method.
o [MPLS-TE-REQ-07] Upon receiving a signal an upgrade event signal o MPLS-TE-REQ-07 (NA): Upon receiving a signal an upgrade event
(from operator), the I2RS client could calculate another path for signal (from operator), the I2RS client could calculate another
the affected TE tunnels to deviate traffic away from the resource path for the affected TE tunnels to deviate traffic away from the
being upgraded, and then send the request to I2RS agents on the resource being upgraded, and then send the request to I2RS agents
appropriate nodes to move the traffic. After the upgrade on the appropriate nodes to move the traffic. After the upgrade
completes, the I2RS client can simply remove I2RS configurations completes, the I2RS client can simply remove I2RS configurations
causing the traffic to revert to the original path. Or, the I2RS causing the traffic to revert to the original path. Or, the I2RS
can re-optimize the TE tunnels for another pathways (E.g. as a can re-optimize the TE tunnels for another pathways (E.g. as a
part of a sequence of upgrades). part of a sequence of upgrades).
o [MPLS-TE-REQ-08] I2RS agents can notify I2RS Clients of impending o MPLS-TE-REQ-08 (OC): I2RS agents can notify I2RS Clients of
or existing MPLS TE overload conditions that might cause TE LSP impending or existing MPLS TE overload conditions that might cause
rejections. This overload conditions include: due to CPU, memory, TE LSP rejections. This overload conditions include: due to CPU,
LSP label space, or LSP numbers. memory, LSP label space, or LSP numbers.
o [MPLS-TE-09] Automatic bandwidth adjustment applications can also o MPLS-TE-09 (IC): Automatic bandwidth adjustment applications can
be linked to the I2RS clients need to monitor the traffic on TE also be linked to the I2RS clients need to monitor the traffic on
tunnels in order to provide traffic analysis. The I2RS client TE tunnels in order to provide traffic analysis. The I2RS client
should be able to read the TE Tunnel topology and the bandwidth should be able to read the TE Tunnel topology and the bandwidth
analysis in order to automatically calculate a new path for the TE analysis in order to automatically calculate a new path for the TE
tunnel if it is needed. The I2RS Client also needs to be able to tunnel if it is needed. The I2RS Client also needs to be able to
the I2RS agents in the nodes to install the new TE Tunnels with the I2RS agents in the nodes to install the new TE Tunnels with
the make-before-break option. the make-before-break option.
o [MPLS-TE-REQ-10] With I2RS, the node failure or link failure can o MPLS-TE-REQ-10 (IC): With I2RS, the node failure or link failure
be part of the notification stream sent by an I2RS Agent to an can be part of the notification stream sent by an I2RS Agent to an
I2RS Client on a centralized server gathering information. I2RS Client on a centralized server gathering information.
o [MPLS-TE-REQ-11] The I2RS client can notify the I2RS agents on o MPLS-TE-REQ-11 (IC): The I2RS client can notify the I2RS agents on
specific nodes (or devices) to re-signal TE LSPs one by one if specific nodes (or devices) to re-signal TE LSPs one by one if
there is a resource dependency. [MPLS-TE-REQ-12] The I2RS Client there is a resource dependency.
can gather the TE LSPs' state from I2RS Agents on all nodes in
order to coordinate such handling of LSP resources.
o [MPLS-TE-REQ-13] The I2RS Clients collecting information from I2RS o MPLS-TE-REQ-12 (IC): The I2RS Client can gather the TE LSPs' state
Agents can be arranged in a hierarchy to provide scaling of from I2RS Agents on all nodes in order to coordinate such handling
of LSP resources.
o MPLS-TE-REQ-13 (OC): The I2RS Clients collecting information from
I2RS Agents can be arranged in a hierarchy to provide scaling of
collections. An application hosting an I2RS client collecting collections. An application hosting an I2RS client collecting
information from I2RS Agents on nodes can have an I2RS Agent that information from I2RS Agents on nodes can have an I2RS Agent that
reports combined information to a single location. reports combined information to a single location.
10. Requirements from MPLS LDP Networks Use Cases 10. Requirements from MPLS LDP Networks Use Cases
These are the I2RS requirements for the MPLS LDP use case described These are the I2RS requirements for the MPLS LDP use case described
in [I-D.chen-i2rs-mpls-ldp-usecases]: in [I-D.chen-i2rs-mpls-ldp-usecases]:
o [MPLS-LDP-REQ-01]: The I2RS Client-agent exchange should allow the o MPLS-LDP-REQ-01 (IC): The I2RS Client-agent exchange should allow
distribution of the configuration for PWE3, MPLS LDP and the distribution of the configuration for PWE3, MPLS LDP and
associated protocols to be distributed from a central location associated protocols to be distributed from a central location
where the global PWE3 provisioning information could be stored. where the global PWE3 provisioning information could be stored.
The I2RS Client-Agent exchange should also be able to push the The I2RS Client-Agent exchange should also be able to push the
configuration of the local LDP LSR ID and peer addresses to set up configuration of the local LDP LSR ID and peer addresses to set up
the targeted session to the pseudowire endpoints. the targeted session to the pseudowire endpoints.
o [MPLS-LDP-REQ-02] When an the end-user wants to disable IPoMPLS o MPLS-LDP-REQ-02 (IC): When an the end-user wants to disable
(IP over MPLS) application on a L2VPN/PW Targeted LDP session, the IPoMPLS (IP over MPLS) application on a L2VPN/PW Targeted LDP
I2RS Client-I2RS agent should be able to set type of application session, the I2RS Client-I2RS agent should be able to set type of
over the established LDP session. In this way LDP speaker can application over the established LDP session. In this way LDP
only advertise to its peer the application data which the user is speaker can only advertise to its peer the application data which
interested in. the user is interested in.
o [MPLS-LDP-REQ-03] The I2RS Agent notifications should allow an o MPLS-LDP-REQ-03 (OC): The I2RS Agent notifications should allow an
I2RS client to subscribe to a stream of state changes regarding I2RS client to subscribe to a stream of state changes regarding
the LDP sessions or LDP LSPs from the I2RS Agent. Specifically it the LDP sessions or LDP LSPs from the I2RS Agent. Specifically it
is important that LDP session is tract for sessions state coming is important that LDP session is tract for sessions state coming
up or going down. The I2RS Client-I2RS Agent exchange should up or going down. The I2RS Client-I2RS Agent exchange should
allow additional queries to the AGent to determine a) why the allow additional queries to the AGent to determine a) why the
service is invalid, b) calculating whether an alternate path service is invalid, b) calculating whether an alternate path
should be switched to, and c) determining how to switch to other should be switched to, and c) determining how to switch to other
links or nodes in order to recover from the link failure or node links or nodes in order to recover from the link failure or node
failure. failure.
o [MPLS-LDP-REQ04] The I2RS interface provides way to monitor and o MPLS-LDP-REQ04 (IC): The I2RS interface provides way to monitor
control the limited resources on these access devices. The I2RS and control the limited resources on these access devices. The
client should be able to instruct the I2RS agent in each of these I2RS client should be able to instruct the I2RS agent in each of
devices to set the maximum number of LDP LSPs in each device prior these devices to set the maximum number of LDP LSPs in each device
to enabling LDP on the devices. The I2RS client should also be prior to enabling LDP on the devices. The I2RS client should also
able to enable a notification service on each device with a with a be able to enable a notification service on each device with a
warning threshold. Once the number of LDP LSPs reaches the with a warning threshold. Once the number of LDP LSPs reaches the
threshold, the I2RS agent will send a notification message to the threshold, the I2RS agent will send a notification message to the
I2RS client. Often the I2RS client will be associated a network I2RS client. Often the I2RS client will be associated a network
management agent that can determine what next steps need to be management agent that can determine what next steps need to be
done based on policy or operator input. done based on policy or operator input.
11. Requirements from Mobile Backhaul Ues Cases 11. Requirements from Mobile Backhaul Ues Cases
Mobile BackHaul Use cases described in [draft-ietf-zhang-mbb- Mobile BackHaul Use cases described in [draft-ietf-zhang-mbb-
usecases-01] are: usecases-01] are:
o MBH-REQ-01: The I2RS client-agent communication can distribute o MBH-REQ-01 (OC): The I2RS client-agent communication can
position-critical changes to IGP nodes using this global knowledge distribute position-critical changes to IGP nodes using this
to quicken changes to support traffic during failures or traffic global knowledge to quicken changes to support traffic during
overloads. To enable this feature, the I2RS Clients-Agent failures or traffic overloads. To enable this feature, the I2RS
communication needs to pass information on which IGP process or Clients-Agent communication needs to pass information on which IGP
Level or Area the given node and links belong to. process or Level or Area the given node and links belong to.
o MBH-REQ-02: I2RS must allow operators to use of I2RS clients to o MBH-REQ-02 (OC): I2RS must allow operators to use of I2RS clients
distribute time-critical changes in configuration to I2RS agents to distribute time-critical changes in configuration to I2RS
associated with each routing node. This feature will simplify and agents associated with each routing node. This feature will
automate configuration and monitoring of a mobile backhaul network simplify and automate configuration and monitoring of a mobile
to allow it to readily adapt to changing network sizes (and backhaul network to allow it to readily adapt to changing network
scales) and radio applications. sizes (and scales) and radio applications.
o MBB-REQ-03: I2RS Clients-Agent communication needs to pass o MBB-REQ-03 (OC): I2RS Clients-Agent communication needs to pass
information on: information on:
* T-LDP configurations and status; * T-LDP configurations and status;
* BGP peer configurations, peer topologies and status; * BGP peer configurations, peer topologies and status;
* BGP-based LSP topologies and status; * BGP-based LSP topologies and status;
* Reset VPN topologies, and per node configurations; * Reset VPN topologies, and per node configurations;
o MBB-REQ04: Route policy enforcement in mobile backhaul networks o MBB-REQ04 (IC): Route policy enforcement in mobile backhaul
needs to be more dynamic and flexible than the current methods networks needs to be more dynamic and flexible than the current
take hours (or even days) to configure route policy across a methods take hours (or even days) to configure route policy across
network. The I2RS interface must provide a programmatic way to a network. The I2RS interface must provide a programmatic way to
configure (both policy and device) and monitor thousands of configure (both policy and device) and monitor thousands of
devices individually whose configuration is based on the devices devices individually whose configuration is based on the devices
role (such as ASRSs in one AS, ASBRs between ASs and other role (such as ASRSs in one AS, ASBRs between ASs and other
service-touch nodes). service-touch nodes).
o MBB-REQ-05: I2RS clients should be able to contact I2RS agents on o MBB-REQ-05 (NA): I2RS clients should be able to contact I2RS
nodes to query role-based information from the network status. agents on nodes to query role-based information from the network
After collecting the status, the I2RS client can develop the BGP status. After collecting the status, the I2RS client can develop
policies based on role information and push the BGP policies to the BGP policies based on role information and push the BGP
the I2RS agents that would load the alternate policies into the policies to the I2RS agents that would load the alternate policies
network device. The I2RS Agents loading the alternate policies into the network device. The I2RS Agents loading the alternate
could then send status back to the I2RS Client. policies could then send status back to the I2RS Client.
o MBH-REQ06: I2RS clients can provide centralized control of many o MBH-REQ06 (??): I2RS clients can provide centralized control of
network devices via the I2RS Client-Agent communication. The I2RS many network devices via the I2RS Client-Agent communication. The
programmatic interface can automate the collection and analysis of I2RS programmatic interface can automate the collection and
each device's capability so that the centralized I2RS client could analysis of each device's capability so that the centralized I2RS
calculate the optimal LSP path and distribute the configuration to client could calculate the optimal LSP path and distribute the
individual devices. Automation of the collection of device configuration to individual devices. Automation of the collection
capability should be available as query, notification, or a of device capability should be available as query, notification,
published stream. or a published stream.
o MBH-REQ07: While the I2RS RIB Information Model o MBH-REQ07 (NA): While the I2RS RIB Information Model
[[I-D.ietf-i2rs-rib-info-model]] provides for routes with tunnels [[I-D.ietf-i2rs-rib-info-model]] provides for routes with tunnels
or MPLS LSP, the features defined in this model are not sufficient or MPLS LSP, the features defined in this model are not sufficient
to configure both types of LSPs needed for the VPN technology in to configure both types of LSPs needed for the VPN technology in
mobile backhaul networks. Additional I2RS Informational models mobile backhaul networks. Additional I2RS Informational models
need to be created to support these features. need to be created to support these features.
o MBH-REQ08: The hierarchical protection architecture in mobile o MBH-REQ08 (NA): The hierarchical protection architecture in mobile
backhaul network offer high network reliability and more backhaul network offer high network reliability and more
flexibility to meet the various needs of the tunnels and services. flexibility to meet the various needs of the tunnels and services.
The I2RS interface in this use case is needed to automate the The I2RS interface in this use case is needed to automate the
configuration and monitoring so that tunnel protection and service configuration and monitoring so that tunnel protection and service
protection interwork in a flexible and reliable manner. protection interwork in a flexible and reliable manner.
o MBB-REQ09: The I2RS architecture (client-agent) should allow the o MBB-REQ09 (OC): The I2RS architecture (client-agent) should allow
two features for network monitoring naturally in its basic modes: the two features for network monitoring naturally in its basic
modes:
* allow a combination of multi-layer network monitor tools with * allow a combination of multi-layer network monitor tools with
exact detection parameters to be configured on the network exact detection parameters to be configured on the network
device device
* Facilitate the reporting the detection result as notification * Facilitate the reporting the detection result as notification
or publication stream or publication stream
It is important the result of these features allow the outages and It is important the result of these features allow the outages and
traffic congestion or discards to be detected real-time with I2RS traffic congestion or discards to be detected real-time with I2RS
Client(s) in each node, and the detection result will be reported Client(s) in each node, and the detection result will be reported
to the I2RS agents to get the exact status of the network. to the I2RS agents to get the exact status of the network.
12. Requirements from :arge Data Flows are 12. Requirements from Large Data Flows are
Each of these requirements has been given an an ID number of L-Flow- Each of these requirements has been given an an ID number of L-Flow-
nn for ease of reference. nn for ease of reference.
The requirements from the Large Data Flows use case described in The requirements from the Large Data Flows use case described in
[I-D.krishnan-i2rs-large-flow-use-case] are: [I-D.krishnan-i2rs-large-flow-use-case] are (IC):
L-Flow-REQ-01: For redirecting large flows to a specific L-Flow-REQ-01 (IC): For redirecting large flows to a specific
component, a PBR entry should be programmable for the flow with component, a PBR entry should be programmable for the flow with
its nexthop that identifies the specific LAG or ECMP component. its nexthop that identifies the specific LAG or ECMP component.
L-Flow-REQ-02: For adjusting the weights used to distribute L-Flow-REQ-02 (IC): For adjusting the weights used to distribute
traffic across components of the LAG or ECMP, I2RS should provide traffic across components of the LAG or ECMP, I2RS should provide
a programmable mechanism should be provided that identifies ECMP a programmable mechanism should be provided that identifies ECMP
entries and is able to associate weights that can be programmed entries and is able to associate weights that can be programmed
for each of the components. To do this in a scalable fashion, it for each of the components. To do this in a scalable fashion, it
would be useful to have the notion of an ECMP nexthop that is used would be useful to have the notion of an ECMP nexthop that is used
by multiple routes by multiple routes
L-Flow-REQ-03: The I2RS interface (protocol/IMs) should allow for L-Flow-REQ-03 (IC): The I2RS interface (protocol/IMs) should allow
a globally optimal path is programmed in the IP network using hop- for a globally optimal path is programmed in the IP network using
by-hop PBR rules. These PBR rules may include: hop-by-hop PBR rules. These PBR rules may include:
* Being able to adjust the weights of the ECMP table for * Being able to adjust the weights of the ECMP table for
different nexthops should be adjusted to factor the large flows different nexthops should be adjusted to factor the large flows
* Being able to address an ECMP group, so that all routes sharing * Being able to address an ECMP group, so that all routes sharing
an ECMP group are addressed together. an ECMP group are addressed together.
* the ability to program PBR entries at the edge LSR, and * the ability to program PBR entries at the edge LSR, and
* the ability to program new LSPs in the network. * the ability to program new LSPs in the network.
L-Flow-REQ-04: The I2RS protocol should be able to invoke the link L-Flow-REQ-04 (OC): The I2RS protocol should be able to invoke the
aggregation IEEE 802.1AX Marker Protocol via the I2RS protocol. link aggregation IEEE 802.1AX Marker Protocol via the I2RS
This is useful during a period of rebalancing occurs before flows protocol. This is useful during a period of rebalancing occurs
are moved. before flows are moved.
L-Flow-REQ-05: The I2rs protocol should allow Quality of Service L-Flow-REQ-05 (IC): The I2rs protocol should allow Quality of
(QoS) actions such as rate-limiting, re-marking, or discarding can Service (QoS) actions such as rate-limiting, re-marking, or
be performed on the flows based on configured policies and nexthop discarding can be performed on the flows based on configured
redirection actions to be programmed, and to be programmed policies and nexthop redirection actions to be programmed, and to
independently of of each other. be programmed independently of of each other.
L-Flow-REQ-06: Once a large flow has been detected, I2RS must be L-Flow-REQ-06 (IC): Once a large flow has been detected, I2RS must
used to modify the forwarding tables in the router to: be used to modify the forwarding tables in the router to:
* In the case of large flow load balancing, be able to * In the case of large flow load balancing, be able to
redirecting the large flow to a particular member with the LAG redirecting the large flow to a particular member with the LAG
or ECMP group and readjusting the weights of the other members or ECMP group and readjusting the weights of the other members
to account for the large flow to account for the large flow
* In the case of DDoS mitigation, the action involves rate * In the case of DDoS mitigation, the action involves rate
limiting, remarking or potentially discarding the large flow in limiting, remarking or potentially discarding the large flow in
question. question.
13. Large Data Collection Systems 13. Large Data Collection Systems
The requirements from the Large Data Collection Systems Use cases The requirements from the Large Data Collection Systems Use cases
described in [draft-swhyte-i2rs-data-collection-system] are: described in [draft-swhyte-i2rs-data-collection-system] are (OC):
L-Data-REQ-01: I2rs must be able to collect large data set from L-Data-REQ-01 (OC): I2rs must be able to collect large data set
the network with high frequency and resolution with minimal impact from the network with high frequency and resolution with minimal
to the device's CPU and memory. impact to the device's CPU and memory.
L-Data-REQ-02: I2RS must be able to use a database model where the L-Data-REQ-02 (IC): I2RS must be able to use a database model
data on the network node must be able to be described in the I2RS where the data on the network node must be able to be described in
exchange as the data plus the structure of the data. The I2RS the I2RS exchange as the data plus the structure of the data. The
management system consumes and understand the data only after it I2RS management system consumes and understand the data only after
consumes and understand the database model or has been trained by it consumes and understand the database model or has been trained
vendor published model by vendor published model
L-Data-REQ-03: I2RS should use a pub-sub model which allows L-Data-REQ-03 (IC): I2RS should use a pub-sub model which allows
scaling plus push or pull of data. scaling plus push or pull of data.
L-Data-REQ-04: I2RS should support capability negotiation to L-Data-REQ-04 (IC): I2RS should support capability negotiation to
inform a subscriber of the options for publication of data. The inform a subscriber of the options for publication of data. The
options include transport, security, and error handling. options include transport, security, and error handling.
L-Data-REQ-05: The I2RS data tansfer should be format agnostic. L-Data-REQ-05 (IC): The I2RS data tansfer should be format
This means the publisher and subscriber may agree upon XML, JSON, agnostic. This means the publisher and subscriber may agree upon
MTL, protobufs or any other format. XML, JSON, MTL, protobufs or any other format.
L-Data-REQ-06: I2RS Transports must be able to be chosen by a I2RS L-Data-REQ-06 (IC): I2RS Transports must be able to be chosen by a
Client-I2RS Agent pair. An I2RS Client-I2RS Agent pair should be I2RS Client-I2RS Agent pair. An I2RS Client-I2RS Agent pair
allowed to negotiate the transport options from a list of options. should be allowed to negotiate the transport options from a list
of options.
L-DATA-REQ-07: The I2RS interface (protocol and IMs) should allow L-DATA-REQ-07 (IC): The I2RS interface (protocol and IMs) should
a subscribe to select portions of the data model. allow a subscribe to select portions of the data model.
L-Data-REQ-08: The I2RS interface (protocol and IMs) should allow L-Data-REQ-08 (IC): The I2RS interface (protocol and IMs) should
for multiple publish subscriptions at a time. allow for multiple publish subscriptions at a time.
L-Data-REQ-09: Timestaps should be associated with data that L-Data-REQ-09 (IC): Timestaps should be associated with data that
requires it. Not all data will require a time stamp. Additional requires it. Not all data will require a time stamp. Additional
time stamps may be added. time stamps may be added.
L-Data-REQ-10: The I2RS should support the query and L-Data-REQ-10 (IC): The I2RS should support the query and
"introspection" of the data model. The Introspections provides "introspection" of the data model. The Introspections provides
support for data verification, easier inclusion in legacy data, support for data verification, easier inclusion in legacy data,
and easier merging with data streams. and easier merging with data streams.
L-Data-REQ-11: After the I2rs Client-Agent have exchanged L-Data-REQ-11 (IC): After the I2rs Client-Agent have exchanged
capabilities, a database model, and filters used to select capabilities, a database model, and filters used to select
elements of the model to subscribe to, the framework should elements of the model to subscribe to, the framework should
support a standard way to register for all the data desired, using support a standard way to register for all the data desired, using
whatever capabilities were advertised by the node. Once whatever capabilities were advertised by the node. Once
registration is complete, the control channel can be closed. registration is complete, the control channel can be closed.
Ensuring subscriptions are correct, complete, and replicated or Ensuring subscriptions are correct, complete, and replicated or
not, is up to the overall system and not the agent on the network not, is up to the overall system and not the agent on the network
node. node.
L-Data-REQ-12: The I2RS interface should support user L-Data-REQ-12 (IC): The I2RS interface should support user
subscriptions to data with the following parameters: subscriptions to data with the following parameters:
* push of data synchronously or asynchronously via registered * push of data synchronously or asynchronously via registered
subscriptions subscriptions
* pull data off in a one-shot pull or in multiple sequences * pull data off in a one-shot pull or in multiple sequences
* provide dynamic subscriptions that can be setup via IPFIX feed * provide dynamic subscriptions that can be setup via IPFIX feed
* support of subscriber and consumer I2RS Client-agent pairs * support of subscriber and consumer I2RS Client-agent pairs
* allow remapping of a node's databases * allow remapping of a node's databases
L-Data-REQ-13: The I2RS interface must handle and report errors L-Data-REQ-13 (IC): The I2RS interface must handle and report
that occur with data subscription, stale data, repeated transport errors that occur with data subscription, stale data, repeated
failures, and other (yet unknown) errors transport failures, and other (yet unknown) errors
14. CDNI 14. CDNI
The requirements from the Large Data Collection Systems Use cases The requirements from the Content Delivery Network Interaction
described in [I-D.shin-i2rs-usecases-cdni-request-routing] are: described in [I-D.shin-i2rs-usecases-cdni-request-routing] are (OC):
o CDNI-REQ-01: The I2RS interface should support two CDNI o CDNI-REQ-01 (OC): The I2RS interface should support two CDNI
functionalities [I-D.ietf-cdni-framework]: functionalities [I-D.ietf-cdni-framework]:
* Request Routing Interface - Footprint and Capabilities * Request Routing Interface - Footprint and Capabilities
Advertisement; the asynchronous advertisement of footprint and Advertisement; the asynchronous advertisement of footprint and
capabilities by a dCDN that allows a uCDN to decide whether to capabilities by a dCDN that allows a uCDN to decide whether to
redirect particular user requests to that dCDN via the ALTO redirect particular user requests to that dCDN via the ALTO
protocol; and protocol; and
* Request Routing Interface - Redirection; the synchronous * Request Routing Interface - Redirection; the synchronous
operation of actually redirecting a user request via I2RS operation of actually redirecting a user request via I2RS
manipulation of the routing plane. manipulation of the routing plane.
o CDNI-REQ-02: The I2RS (Protocol and IM) should provide facilities o CDNI-REQ-02 (OC): The I2RS (Protocol and IM) should provide
to enable the query/response of information from an ALTO services facilities to enable the query/response of information from an
in a node routing functions so that the upstream CDN provider can ALTO services in a node routing functions so that the upstream CDN
select a proper downstream CDN provider for a given end user provider can select a proper downstream CDN provider for a given
request. end user request.
o CDNI-REQ-03: I2RS (protocol and IM) should provide facilties to o CDNI-REQ-03 (OC): I2RS (protocol and IM) should provide facilties
enable I2RS can help the upstream CDN provider to redirect a to enable I2RS can help the upstream CDN provider to redirect a
content request message to a downstream CDN provider for a given content request message to a downstream CDN provider for a given
end user request as with the following features: end user request as with the following features:
* The uCDN relays this message between I2RS Clients and I2RS * The uCDN relays this message between I2RS Clients and I2RS
agents with content distribution metadata, and queries the dCDN agents with content distribution metadata, and queries the dCDN
whether user request message can be delivered. This query can whether user request message can be delivered. This query can
have multiple dDCN that the user message can be delivered to. have multiple dDCN that the user message can be delivered to.
* the I2RS agent associated with the dCDN delivery requests * the I2RS agent associated with the dCDN delivery requests
indicating which dCDN (if any) the user message can be indicating which dCDN (if any) the user message can be
skipping to change at page 31, line 39 skipping to change at page 31, line 49
draft-bitar-i2rs-service-chaining-01 (work in progress), draft-bitar-i2rs-service-chaining-01 (work in progress),
February 2014. February 2014.
[I-D.chen-i2rs-mpls-ldp-usecases] [I-D.chen-i2rs-mpls-ldp-usecases]
Chen, X. and Z. Li, "Use Cases for an Interface to LDP Chen, X. and Z. Li, "Use Cases for an Interface to LDP
Protocol", draft-chen-i2rs-mpls-ldp-usecases-00 (work in Protocol", draft-chen-i2rs-mpls-ldp-usecases-00 (work in
progress), October 2013. progress), October 2013.
[I-D.chen-i2rs-ts-use-case] [I-D.chen-i2rs-ts-use-case]
Chen, M. and S. Hares, "I2RS Traffic Steering Use Case", Chen, M. and S. Hares, "I2RS Traffic Steering Use Case",
draft-chen-i2rs-ts-use-case-00 (work in progress), draft-chen-i2rs-ts-use-case-01 (work in progress), July
February 2014. 2014.
[I-D.hares-i2rs-use-case-vn-vc] [I-D.hares-i2rs-use-case-vn-vc]
Hares, S. and M. Chen, "Use Cases for Virtual Connections Hares, S. and M. Chen, "Use Cases for Virtual Connections
on Demand (VCoD) and Virtual Network on Demand (VNoD) on Demand (VCoD) and Virtual Network on Demand (VNoD)
using Interface to Routing System", draft-hares-i2rs-use- using Interface to Routing System", draft-hares-i2rs-use-
case-vn-vc-02 (work in progress), February 2014. case-vn-vc-03 (work in progress), July 2014.
[I-D.huang-i2rs-mpls-te-usecases] [I-D.huang-i2rs-mpls-te-usecases]
Huang, T., Li, Z., and S. Hares, "Use Cases for an Huang, T., Li, Z., and S. Hares, "Use Cases for an
Interface to MPLS TE", draft-huang-i2rs-mpls-te- Interface to MPLS TE", draft-huang-i2rs-mpls-te-
usecases-01 (work in progress), February 2014. usecases-02 (work in progress), July 2014.
[I-D.ietf-i2rs-architecture] [I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-04 (work in System", draft-ietf-i2rs-architecture-05 (work in
progress), June 2014. progress), July 2014.
[I-D.ietf-i2rs-problem-statement] [I-D.ietf-i2rs-problem-statement]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Problem Statement", draft-ietf-i2rs- Routing System Problem Statement", draft-ietf-i2rs-
problem-statement-04 (work in progress), June 2014. problem-statement-04 (work in progress), June 2014.
[I-D.ietf-i2rs-rib-info-model] [I-D.ietf-i2rs-rib-info-model]
Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing
Information Base Info Model", draft-ietf-i2rs-rib-info- Information Base Info Model", draft-ietf-i2rs-rib-info-
model-03 (work in progress), May 2014. model-03 (work in progress), May 2014.
[I-D.ietf-sfc-problem-statement] [I-D.ietf-sfc-problem-statement]
Quinn, P. and T. Nadeau, "Service Function Chaining Quinn, P. and T. Nadeau, "Service Function Chaining
Problem Statement", draft-ietf-sfc-problem-statement-07 Problem Statement", draft-ietf-sfc-problem-statement-10
(work in progress), June 2014. (work in progress), August 2014.
[I-D.ji-i2rs-usecases-ccne-service] [I-D.ji-i2rs-usecases-ccne-service]
Ji, X., Zhuang, S., Huang, T., and S. Hares, "I2RS Use Ji, X., Zhuang, S., Huang, T., and S. Hares, "I2RS Use
Cases for Control of Forwarding Path by Central Control Cases for Control of Forwarding Path by Central Control
Network Element (CCNE)", draft-ji-i2rs-usecases-ccne- Network Element (CCNE)", draft-ji-i2rs-usecases-ccne-
service-01 (work in progress), February 2014. service-02 (work in progress), July 2014.
[I-D.keyupate-i2rs-bgp-usecases] [I-D.keyupate-i2rs-bgp-usecases]
Patel, K., Fernando, R., Gredler, H., Amante, S., White, Patel, K., Fernando, R., Gredler, H., Amante, S., White,
R., and S. Hares, "Use Cases for an Interface to BGP R., and S. Hares, "Use Cases for an Interface to BGP
Protocol", draft-keyupate-i2rs-bgp-usecases-03 (work in Protocol", draft-keyupate-i2rs-bgp-usecases-04 (work in
progress), June 2014. progress), July 2014.
[I-D.krishnan-i2rs-large-flow-use-case] [I-D.krishnan-i2rs-large-flow-use-case]
ramki, r., Ghanwani, A., Kini, S., McDysan, D., and D. ramki, r., Ghanwani, A., Kini, S., McDysan, D., and D.
Lopez, "Large Flow Use Cases for I2RS PBR and QoS", draft- Lopez, "Large Flow Use Cases for I2RS PBR and QoS", draft-
krishnan-i2rs-large-flow-use-case-04 (work in progress), krishnan-i2rs-large-flow-use-case-04 (work in progress),
April 2014. April 2014.
[I-D.lapukhov-bgp-routing-large-dc] [I-D.lapukhov-bgp-routing-large-dc]
Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for
routing in large-scale data centers", draft-lapukhov-bgp- routing in large-scale data centers", draft-lapukhov-bgp-
skipping to change at page 33, line 24 skipping to change at page 33, line 35
progress), July 2014. progress), July 2014.
[I-D.swhyte-i2rs-data-collection-system] [I-D.swhyte-i2rs-data-collection-system]
Whyte, S., Hines, M., and W. Kumari, "Bulk Network Data Whyte, S., Hines, M., and W. Kumari, "Bulk Network Data
Collection System", draft-swhyte-i2rs-data-collection- Collection System", draft-swhyte-i2rs-data-collection-
system-00 (work in progress), October 2013. system-00 (work in progress), October 2013.
[I-D.white-i2rs-use-case] [I-D.white-i2rs-use-case]
White, R., Hares, S., and A. Retana, "Protocol Independent White, R., Hares, S., and A. Retana, "Protocol Independent
Use Cases for an Interface to the Routing System", draft- Use Cases for an Interface to the Routing System", draft-
white-i2rs-use-case-05 (work in progress), June 2014. white-i2rs-use-case-06 (work in progress), July 2014.
[I-D.zhang-i2rs-mbb-usecases] [I-D.zhang-i2rs-mbb-usecases]
Zhang, L., Li, Z., Liu, D., and S. Hares, "Use Cases of Zhang, L., Li, Z., Liu, D., and S. Hares, "Use Cases of
I2RS in Mobile Backhaul Network", draft-zhang-i2rs-mbb- I2RS in Mobile Backhaul Network", draft-zhang-i2rs-mbb-
usecases-01 (work in progress), February 2014. usecases-01 (work in progress), February 2014.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
skipping to change at page 34, line 5 skipping to change at page 34, line 13
Reroute: Loop-Free Alternates", RFC 5286, September 2008. Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
"Framework for PCE-Based Inter-Layer MPLS and GMPLS "Framework for PCE-Based Inter-Layer MPLS and GMPLS
Traffic Engineering", RFC 5623, September 2009. Traffic Engineering", RFC 5623, September 2009.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, October Optimization (ALTO) Problem Statement", RFC 5693, October
2009. 2009.
Author's Address Authors' Addresses
Susan Hares Susan Hares
Huawei Huawei
Email: shares@ndzh.com Email: shares@ndzh.com
Mach Chen
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: mach.chen@huawei.com
 End of changes. 199 change blocks. 
496 lines changed or deleted 537 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/