One document matched: draft-hares-i2rs-use-case-vn-vc-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!ENTITY I-D.ietf-i2rs-problem-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-problem-statement.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.ietf-i2rs-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-info-model.xml">
<!ENTITY I-D.ietf-idr-ls-distribution SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-ls-distribution.xml">
<!ENTITY I-D.bernstein-alto-topo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bernstein-alto-topo.xml">
<!ENTITY I-D.ji-i2rs-usecases-ccne-service SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ji-i2rs-usecases-ccne-service.xml">
<!ENTITY I-D.white-i2rs-use-case SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.white-i2rs-use-case.xml">
<!ENTITY I-D.hares-i2rs-info-model-service-topo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-info-model-service-topo.xml">
<!ENTITY I-D.medved-i2rs-topology-im SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-medved-i2rs-topology-im-01.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-hares-i2rs-use-case-vn-vc-03"
ipr="trust200902">
<front>
<title abbrev="I2RS Use Cases VCoD VNoD">Use Cases for Virtual Connections
on Demand (VCoD) and Virtual Network on Demand (VNoD) using Interface to
Routing System</title>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<email>shares@ndzh.com</email>
</address>
</author>
<author fullname="Mach Chen" initials="M" surname="Chen">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>mach.chen@huawei.com</email>
</address>
</author>
<date year="2014"/>
<area>Routing</area>
<workgroup>Routing Area Working Group</workgroup>
<abstract>
<t>Software Defined Networks (SDN) provide a way to virtualize and
abstract the network in order to present virtual or abstract
resources to third-party applications running in software. Applications
can utilize a programmable interface to receive these virtual or
abstract resource descriptions in a form that allows monitoring or
manipulation of resources within the network. The Interface to the
Routing System (I2RS) provides an interface directly to the routing
System to monitor best paths to any destination or change routes in the
routing information base (RIB) or MPLS Label Information Base (LIB). The
I2RS interfaces may be combined with other interfaces to the forwarding
plane (ForCES (RFC3746)), device configuration (NETCONF), or
mid-level/peer-to-peer (ALTO, draft-ietf-alto-protocol) system to create
these virtual pathways.</t>
<t>This document outlines how SDN networks can use the I2RS interface to
implement an automated set of network services for the Virtual
Connection on Demand (VCoD) and Virtual Network on Demand (VNoD). These
systems provide service routing a better way to create paths within a
hub and spoke environment, and provide service routing the ability to
create pathways based on service.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>The Interface to the Routing System (I2RS) architecture (<xref
target="I-D.ietf-i2rs-architecture"/>) describes a mechanism where the
distributed control plane can be augmented by an outside control plane
through an open accessible programmatic interface. I2RS provides a
"halfway point" between completely an architecture that replaces the traditional distributed
control planes and directly configuring devices via off-board
processes.</t>
<t>This draft proposes a set of use cases using I2RS mechanisms to
implement a Software Defined Network (SDN) to enact virtual connections
and virtual networks as automated services. This document focuses on how
I2RS would support two automated network services: Virtual Connection on
Demand (VCoD) and Virtual Network on Demand (VNoD). Virtual Connections
on Demand (VCoD) and Virtual Network on Demand (VNoD) may be used within
hub-spoke networks and improve service routing. In the future, an
application enabled SDN service may provide the Virtual Circuits (VCoD)
and Virtual Networks on Demand (VNoD) for any type of network
service.</t>
<t>This document contains a summary of I2RS requirements from VCoD and
VNoD use case, background to I2RS, a VCoD use case, a VNoD use case, and
a discussion of what the RIB Information Model is missing. Those
familiar with I2RS problem statement (<xref
target="I-D.ietf-i2rs-problem-statement"></xref>), I2RS architecture
(<xref target="I-D.ietf-i2rs-architecture"></xref>), and the concepts of Virtual
Connections (VCs) or Virtual Networks (VNs) may wish to skip the
background section.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Summary of I2RS requirements">
<t>This section contains a summary of what each use case indicates is
needed in the I2RS protocol (features and data). Section 3-5 provide
descriptions of the Virtual Circuit on Demand (VCoD), Virtual Network on
Demand (VNoD), and Automated on Demand Networks. Each of these sections
specifies a use case description followed by a summary of I2RS
requirements. </t>
<t> The use cases in this document have been numbered to
allow coherent compilation of the the I2RS requirements
into a single list. In this draft, each unique requirement for the
I2RS protocol(I2RS client-I2RS agent) for the Virtual Circuit on Demand (VCoD) use caes
has the label VCoD-REQnn where nn is an number. Each unique requirement for the VNoD
use case has the label VNoD-REQnn where nn is a number.
This use case also indicates things which are lacking in the
Each unique requirement for for VCoD additions to the I2RS RIB Informational
Model VCOD-IM-REQnn (where nn is a unique number). Similarly, each unique
requirement for VNoD additions to the RIB informational Model is identified
with VNoD-IM-REQnn where nn is a unique number. Section 6 contains a list
of what is missing in the RIB Informational Model. </t>
<t>The requirements for Virtual Connections on Demand (VCoD) use cases
are: <list style="symbols">
<t>VCoD-REQ01: I2RS Agent SHOULD provide the ability to read the
virtual network topology database for the technology supported to
determine nodes and connections. For optical, these are the optical
connections and what node they connect to, and the topologies
created. For MPLS, this is virtual circuit available, what nodes
they connect to, and the network topologies created. For IP
technologies, this could include the GRE tunnels, what interface it
connects to, and the topologies created. For Ethernet circuits this
should involve circuit type (e.g, point-to-point (P2P) or
point-to-multipoint (P2MP)) and what nodes it can reach, and the
topologies created.</t>
<t>VCoD-REQ02: I2RS Agent SHOULD provide the ability to influence
the configuration of a virtual circuit in a node.</t>
<t>VCod-REQ03: I2RS Agent SHOULD provide monitor and provide
statistics on the virtual connection to the I2RS client via a Read
request or status Notification. The I2RS client can then determine
if the connection falls below a quality level the application has
requested. If the I2RS client does determine the circuit is below
the required quality, it could create another circuit. The I2RS may
choose to create the second virtual circuit, transfer flows, and
then break the first circuit.</t>
</list>
</t>
<t> The Virtual Network on Demand (VCoD) contains the same first three
requirements. This means that:
<list style="symbols">
<t> VNoD-REQ01 = VCoD-REQ01,</t>
<t> VNoD-REQ02 = VCoD-REQ02, and </t>
<t> VNoD-REQ03 = VCoD-REQ03.</t>
</list>
These requirements will not be repeated, so the VNoD begin
with VNoD-REQ-04. </t>
<t>The requirements for the Virtual Networks on Demand (VNoD) are:
<list style="symbols">
<t>VT-VN-REQ04: I2RS Agent SHOULD provide the ability to influence
the configuration of a virtual network in a node.</t>
<t>VT-VN-REQ05: I2RS Agent SHOULD provide the ability to report
statistics on the network nodes and end-to-end traffic flows via
read of status data or via notifications of status.</t>
<t>VT-VN-REQ06: The I2RS protocol and RIB Informational Model (IM)
MUST support logical tunnels of type MPLS as well as IP, GRE, VxLAN,
and GRE. Large carrier networks utilize MPLS in a variety of forms
(LDP, static MPLS TE, or dynamic TE LSPs created by RSVP-TE).</t>
<t>VT-VN-REQ07: I2RS SHOULD support Informational Models and
features to allow MPLS technologies to create Hub-spoke topology and
service routing in networks in Carriers, Enterprise, and Data
Centers.</t>
<t>VT-VN-REQ08: I2RS protocols, Information Models, and Data Models
MUST be able to support Carriers using these MPLS technologies to
support networks for Mobile BackHaul, on-demand MPLS overlays, and
on-demand video conferencing networkings.</t>
</list></t>
</section>
<section title="Virtual Circuit on Demand" toc="default">
<t>Virtual Circuit on Demand (VCoD) application associates to I2RS
client (or clients) which can communicate with the I2RS agent (or
agents) which control the VCoD circuit's creation, deletion,
modification, query for information or status changes. Information for
this application needs to include for network topology, interface
statistics, available circuits per node, available bandwidth on
circuits. Interface statistics might be required on a historical and
instantaneous time basis. The circuit statistics might also need jitter,
delay, and exit-point performance.</t>
<t>The virtual circuits may be obtained via RIB Informational Model (RIB
IM) (<xref target="I-D.ietf-i2rs-rib-info-model"/>) from the interface
list, or from the nexthop lists. Write access to set-up new interfaces
is not clearly spelled out in the current version of the RIB IM, nor are
the statistics (historical or time). This use case points out additional
Information Models (IMs) that need to be added to the I2RS information
models.</t>
<t>In the example topology below, the VCoD application's I2RS client
communicates with I2RS agents to set-up virtual circuits from Edge 1 to
Edge 2. The I2RS client communicates with I2RS Agent-1 on node 1, I2RS
Agent-2 on node 2, I2RS Agent-3 on node 3, and I2RS Agent 4 on node 4
for to set-up the virtual circuit. The VCoD application contains the
necessary logic to determine the pathway from Edge 1 to Edge 2.</t>
<t>A second option for VCoD is to have an application communicate with
two I2RS clients who cooperate to set-up the virtual connections between
Edge 1 and Edge 2. Information passed between the two clients can be
done via other IETF protocols (E.g. stateful PCE or ALTO).</t>
<section title="Why I2RS enabled solutions are necessary">
<t>Past solutions in this area have included uses of device
configuration across multiple nodes (SNMP or NETCONF based) with
proprietary services combined with topology queries. The lack of
coordinated responses to routing topology queries has created problems
in quickly obtaining and configuring changes for Virtual Circuits. New
algorithms can create better services in routing and switching. These
algorithms include Fast-Reroute of RSVP or IGPs which aid the automatic
re-establishment of some circuits, but the complexity of some of these
algorithms increases cost within the network elements. It's often
difficult to justify the added complexity in the database and algorithms
of routing protocols to solve what is considered a point case.</t>
<t>While the set-up of these virtual circuits is possible with current
technology, the lack of the I2RS-like framework makes VCoD network
complex. With this support, VCoD may be able to reduce complexity on the
individual nodes.</t>
</section>
<section title="Why is not in scope for I2RS">
<t>The means by which the VCoD application determines which I2RS client
to associate with is outside the I2RS protocol and architecture. A list
of virtual circuits per node may be queried from the RIB Informational
Model's (RIB IM) (<xref target="I-D.ietf-i2rs-rib-info-model"/>)
interface and nexthop lists. However, other means may be used to
determine the possible interfaces on a node. For example, ALTO could
inform the application which nodes have an I2RS Agent supporting the
VCoD service, and SNMP/NETCONF could be used to determine which
interfaces were configured.</t>
</section>
<section title="Example Topology for Virtual Circuit on Demand (VCoD)">
<t>
<figure align="center" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="center" alt="" height="" name="" type="" width=""
xml:space="preserve">
+----------------------------+
| Application (VCoD) |
+---*------------------------+
| |
| |
+-------*------------+<NETCONF>+-------------------+< NETCONF
|I2RS client 1 |< PCE info> |I2RS Commissioner-2 |< PCEP
|VC controller | | VN controller |
+--*----------*--*-*-+ +-------------------+
| | | | | |
| | | |--------------------------+ |
| | |-----------+ | | |
| | | | | |
+--------+ +--------+ +---------+ +----------+
| I2RS | | I2RS | | I2RS | | I2RS |
| Agent-1| |Agent-2 | | Agent-3 | | Agent-4 |
|--------| |--------+ +---------+ +----------+
| node 1 | | node 2 | | node 3 | | node 4 |
+--------+ +--------+ +---------+ +----------+
| | | | | |
edge1 |--------| |------------| |
|----edge2
</artwork>
</figure></t>
</section>
<section title="I2RS Requirements for Virtual Circuit on Demand (VCoD)">
<t>The following things need to be supported for this application:
<list style="symbols">
<t>VCoD-REQ01: I2RS Agents SHOULD provide the ability to read the
virtual network topology database for the technology supported. For
optical, these are the optical connections and what node they
connect to, and the topologies created. For MPLS, this is virtual
circuit available, what nodes they connect to, and the network
topologies created. For IP technologies, this could include the GRE
tunnels, what interface it connects to, and the topologies created.
For Ethernet circuits this should involve circuit type (e.g,
point-to-point (p2p) or point-to-multipoint (p2mp)) and what nodes
it can reach, and the topologies created.</t>
<t>VCoD-REQ02: I2RS Agent SHOULD provide the ability to influence
the configuration of a virtual circuit in a node.</t>
<t>VCoD-REQ03: I2RS Agent SHOULD provide monitor and provide
statistics on the virtual connection to the I2RS client via a Read
request or status Notification. The I2RS client can then determine
if the connection falls below a quality level the application has
requested. If the I2RS client does determine the circuit is below
the required quality, it could create another circuit. The I2RS may
choose to create the second virtual circuit, transfer flows, and
then break the first circuit.</t>
</list></t>
<t> What is needed in the RIB IM Model </t>
<t><list style="symbols">
<t>VCoD-RIB_IM-REQ01: The RIB IM model (<xref
target="I-D.ietf-i2rs-rib-info-model"/> provides with each route an
associated nexthop-list 0-N members. Each nexthop-list is flagged
with a protection preference (1 or 2), and a Load balance weight (1
to 99). If the host routes for all nodes in the topology exist
within the RIB IM model's instantiation, then the nexthop member on
the nexthop-list SHOULD provide the following information: <list
style="symbols">
<t>identifier for interface</t>
<t>egress interface (logical, virtual, or physical)</t>
<t>address of physical interface (IP address or MAC) plus
RIB</t>
<t>tunnel encapsulation for interface (IP GRE, MPLS tunnel),</t>
<t>logical tunnel identifier</t>
<t>RIB name (for look-up resolution)</t>
<t>flags for specialized look-ups (Discard packets, discard with
error notification, receive)</t>
</list></t>
<t>VT-VC-RIB_IM-REQ02: The RIB IM model's primitives SHOULD include
circuit type (p2p, mp2mp), optical connection information, and
additional statistics per virtual circuit.</t>
<t>VT-VC_RIB_IM-REQ03:The RIB IM model's instantiation within the
protocol must provide an easy way to specify queries for this
information.</t>
</list></t>
</section>
</section>
<section title="Virtual Network on Demand (VNoD)" toc="default">
<t>Virtual Networks on Demand (VNoD) are simply extensions to the
Virtual Connections on Demand concept. The I2RS client is tasked to
create a virtual network instead of a single connection.</t>
<t>The example sequence would be that the application discovers the
appropriate I2RS clients (I2RS VNoD client 1 and I2RS VNoD Client 2)
which support VNoD via a protocol outside the I2RS framework (e.g.
ALTO). The I2RS Client-2 works with the I2RS Agents 1-4 to set-up a
virtual network. This involves the following: <list style="symbols">
<t>gathering potential topology information (in order to create the
network,</t>
<t>set-up the virtual network (via influencing configurations on
node),</t>
<t>monitoring changes in topology (in order to potential
failovers,</t>
<t>influencing changes to virtual network via configurations,
and</t>
<t>removing the virtual network after the demand has expired.</t>
</list></t>
<figure align="center" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="center" alt="" height="" name="" type="" width=""
xml:space="preserve">
+-------------------------+
| Application |
+-------------------------+
| |
| |
+------------------+< Policy +-------------------+<Policy
|I2RS VNoD client 1|<PCE info |I2RS client 2 |< PCEP
| | | |
+------------------+ +-------------------+
| | | |
|----------------------------+ | | |
| +------------------ | |
| | | |
+--------+ +--------+ +---------+ +----------+
| I2RS | | I2RS | | I2RS | | I2RS |
| Agent-1| |Agent-2 | | Agent-3 | | Agent-4 |
|--------| |--------+ +---------+ +----------+
| node 1 | | node 2 | | node 3 | | node 4 |
+--------+ +--------+ +---------+ +----------+
| | | | | | | | |
| |--------| |------------| | +------+ |-end-point-3
| | |
end-point-1 |
|----end-point2
</artwork>
</figure>
<t/>
<t>This topology shares some configuration needs with the central
membership computation for MPLS VPNs from (draft-white-i2rs-use-cases)
but the mechanisms are not specific to MPLS VPNs.</t>
<t>This requires the following from I2RS protocol (client-agent) <list
style="symbols">
<t>VCoD/VNoD-REQ01: I2RS Agents SHOULD provide the ability to read the
virtual network topology database for the technology supported. For
optical, these are the optical connections and what node they
connect to, and the topologies created. For MPLS, this is virtual
circuit available, what nodes they connect to, and the network
topologies created. For IP technologies, this could include the GRE
tunnels, what interface it connects to, and the topologies created.
For Ethernet circuits this should involve circuit type (e.g,
point-to-point (p2p) or point-to-multipoint (p2mp)) and what nodes
it can reach, and the topologies created.</t>
<t>VCoD/VNoD-REQ02: I2RS Agent SHOULD provide the ability to influence
the configuration of a virtual circuit in a node.</t>
<t>VCoD/VnoD-REQ03: I2RS Agent SHOULD provide the ability to report
statistics on the virtual connection to the I2RS client via read of
status data or via notifications of status. The I2RS client can then
determine if the connection falls below a quality level the
application has requested. If the I2RS client does determine the
circuit is below the required quality, it could create another
circuit. The I2RS may choose to create the second virtual circuit,
transfer flows, and then break the first circuit.</t>
<t>VNOD-REQ04: I2RS Agent SHOULD provide the ability to influence
the configuration of a virtual network in a node.</t>
<t>VNoD-REQ05: I2RS Agent SHOULD provide the ability to report
statistics on the network nodes and end-to-end traffic flows via
read of status data or via notifications of status.</t>
</list></t>
</section>
<section title="Automated On Demand Networks" toc="default">
<t>Automated On-Demand networks becomes a reasonable technology within a
network by utilizing the I2RS architecture. While automated on-demand
circuit provisioning and de-provisioning is possible now, the effort to
configure and reconfigure nodes to provide the Automatic On-Demand
circuits can be difficult. With I2RS, the I2RS client can instruct the
I2RS Agents within a network to create On-Demand circuits and then
remove the circuits returning the network to its configured state. With
I2RS enhanced monitoring capability, the monitoring needed for these
state changes is incorporated within the I2RS framework.</t>
<t>The current scope for these Automated On-Demand Circuits in the
IETF's I2RS working group's charter is limited to hub-spoke networks and
service routing. This section discusses the progress on the I2RS against
the use cases, and proposes additional additional Automated On-Demand
Circuits.</t>
<t>Current Status of the Automated On-Demand Functionality</t>
<t>Both the hub-spoke network and service network may include a
centralized control network element such as <xref
target="I-D.ji-i2rs-usecases-ccne-service"/>. These centralized control
network elements may use I2RS access to individual node's RIB
information via the I2RS RIB Information Model (IM) (<xref
target="I-D.ietf-i2rs-rib-info-model"/>), or obtain full network
topology information from other protocols (BGP Route Reflector, PCE
(<xref target="RFC4655"/>), or ALTO <xref
target="I-D.bernstein-alto-topo"/>). With the recent inclusion of IGP
(OSPF and ISIS) link-state information into BGP TLVs via <xref
target="I-D.ietf-idr-ls-distribution"/>, all of these sources can
provide centralized services that can provide topology maps at the AS
and IGP level.</t>
<t>I2RS Information Models (IM) are being proposed which can store:
<list style="symbols">
<t>Network Topologies (IM) <xref
target="I-D.medved-i2rs-topology-im"/>, and</t>
<t>Service Topologies IM) <xref
target="I-D.hares-i2rs-info-model-service-topo"/>.</t>
</list></t>
<t>I2RS features Needed Future On-Demand Networks</t>
<t><list style="symbols">
<t>VNoD-REQ06: The I2RS protocol and RIB Informational Model (IM)
MUST support logical tunnels of type MPLS as well as IP, GRE, VxLAN
and GRE. L Large Carrier networks utilize MPLS in a variety of forms
(LDP, static MPLS TE, or dynamic TE LSPS created by RSVP-TE or
CR-LDP).</t>
<t>VNoD-REQ07: I2RS SHOULD support Informational Models and
features to allow MPLS technologies to create Hub-spoke topology and
service routing in networks in Carriers, Enterprise, and Data
Centers.</t>
<t>VNoD-REQ08: I2RS protocols, Information Models, and Data Models
MUST be able to support Carriers using these MPLS technologies to
support networks for Mobile BackHaul, on-demand MPLS overlays, and
on-demand video conferencing networkings.</t>
</list></t>
</section>
<section title="What is Missing in RIB Informational Model (RIB IM)">
<t>Based on these requirements, the following is needed in the RIB IM
Model: <list style="symbols">
<t>VNoD-RIB_IM-REQ01: The RIB IM model (<xref
target="I-D.ietf-i2rs-rib-info-model"/> provides with each route an
associated nexthop-list 0-N members. Each nexthop-list is flagged
with a protection preference (1 or 2), and a Load balance weight (1
to 99). If the host routes for all nodes in the topology exist
within the RIB IM model's instantiation, then the nexthop member on
the nexthop-list SHOULD provide the following information: <list
style="symbols">
<t>identifier for interface</t>
<t>egress interface (logical, virtual, or physical)</t>
<t>address of physical interface (IP address or MAC) plus
RIB</t>
<t>tunnel encapsulation for interface (IP GRE, MPLS tunnel),</t>
<t>logical tunnel identifier</t>
<t>RIB name (for look-up resolution)</t>
<t>flags for specialized look-ups (Discard packets, discard with
error notification, receive)</t>
</list></t>
<t>VNoD-RIB_IM-REQ02: The RIB IM model's primitives SHOULD include
circuit type (p2p, mp2mp), optical connection information, and
additional statistics per virtual circuit.</t>
<t>VNoD_RIB_IM-REQ03:The RIB IM model's instantiation within the
protocol must provide an easy way to specify queries for this
information.</t>
</list></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document has no security issues as it just contains use
cases.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&RFC4655;
&I-D.ietf-i2rs-problem-statement;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-i2rs-rib-info-model;
&I-D.ietf-idr-ls-distribution;
&I-D.bernstein-alto-topo;
&I-D.ji-i2rs-usecases-ccne-service;
&I-D.hares-i2rs-info-model-service-topo;
&I-D.medved-i2rs-topology-im;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:48:38 |