draft-clemm-i2rs-yang-network-topo-03.txt   draft-clemm-i2rs-yang-network-topo-04.txt 
Network Working Group A. Clemm Network Working Group A. Clemm
Internet-Draft J. Medved Internet-Draft J. Medved
Intended status: Experimental R. Varga Intended status: Experimental R. Varga
Expires: September 6, 2015 T. Tkacik Expires: September 10, 2015 T. Tkacik
Cisco Cisco
N. Bahadur N. Bahadur
Bracket Computing Bracket Computing
H. Ananthakrishnan H. Ananthakrishnan
Packet Design Packet Design
March 5, 2015 March 9, 2015
A Data Model for Network Topologies A Data Model for Network Topologies
draft-clemm-i2rs-yang-network-topo-03.txt draft-clemm-i2rs-yang-network-topo-04.txt
Abstract Abstract
This document defines an abstract (generic) YANG data model for This document defines an abstract (generic) YANG data model for
network/service topologies and inventories. The model serves as a network/service topologies and inventories. The model serves as a
base model which is augmented with technology-specific details in base model which is augmented with technology-specific details in
other, more specific topology and inventory models. other, more specific topology and inventory models.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 September 6, 2015. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 7 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 7
3. Model Structure Details . . . . . . . . . . . . . . . . . . . 7 3. Model Structure Details . . . . . . . . . . . . . . . . . . . 7
3.1. Base Network Model . . . . . . . . . . . . . . . . . . . 7 3.1. Base Network Model . . . . . . . . . . . . . . . . . . . 7
3.2. Base Network Topology Model . . . . . . . . . . . . . . . 9 3.2. Base Network Topology Model . . . . . . . . . . . . . . . 9
3.3. Discussion and selected design decisions . . . . . . . . 11 3.3. Extending the model . . . . . . . . . . . . . . . . . . . 11
3.3.1. Container structure . . . . . . . . . . . . . . . . . 11 3.4. Discussion and selected design decisions . . . . . . . . 11
3.3.2. Underlay hierarchies and mappings . . . . . . . . . . 11 3.4.1. Container structure . . . . . . . . . . . . . . . . . 12
3.3.3. Use of groupings . . . . . . . . . . . . . . . . . . 11 3.4.2. Underlay hierarchies and mappings . . . . . . . . . . 12
3.3.4. Cardinality and directionality of links . . . . . . . 12 3.4.3. Use of groupings . . . . . . . . . . . . . . . . . . 12
3.3.5. Multihoming and link aggregation . . . . . . . . . . 12 3.4.4. Cardinality and directionality of links . . . . . . . 13
3.3.6. Mapping redundancy . . . . . . . . . . . . . . . . . 12 3.4.5. Multihoming and link aggregation . . . . . . . . . . 13
3.3.7. Typing . . . . . . . . . . . . . . . . . . . . . . . 12 3.4.6. Mapping redundancy . . . . . . . . . . . . . . . . . 13
3.3.8. Representing the same device in multiple networks . . 13 3.4.7. Typing . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. Items for further discussion . . . . . . . . . . . . . . 14 3.4.8. Representing the same device in multiple networks . . 14
4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 14 3.5. Items for further discussion . . . . . . . . . . . . . . 15
4.1. Defining the Abstract Network: network.yang . . . . . . . 14 4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Creating Abstract Network Topology: network-topology.yang 16 4.1. Defining the Abstract Network: network.yang . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 4.2. Creating Abstract Network Topology: network-topology.yang 18
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
This document introduces an abstract (base) YANG [RFC6020] [RFC6021] This document introduces an abstract (base) YANG [RFC6020] [RFC6021]
data model to represent networks and topologies. The data model is data model to represent networks and topologies. The data model is
divided into two parts. The first part of the model defines a divided into two parts. The first part of the model defines a
network model that allows to define network hierarchies (i.e. network network model that allows to define network hierarchies (i.e. network
stacks) and to maintain an inventory of nodes contained in a network. stacks) and to maintain an inventory of nodes contained in a network.
The second part of the model augments the basic network model with The second part of the model augments the basic network model with
information to describe topology information. Specifically, it adds information to describe topology information. Specifically, it adds
skipping to change at page 4, line 20 skipping to change at page 4, line 20
| |
+-------+-------+ +-------+-------+
| | | |
V V V V
+------------+ .............. +------------+ ..............
| Abstract | : Inventory : | Abstract | : Inventory :
| Topology | : Model(s) : | Topology | : Model(s) :
| Model | : : | Model | : :
+------------+ '''''''''''''' +------------+ ''''''''''''''
| |
+-------------+-------------+ +-------------+-------------+-------------+
| | | | | | |
V V V V V V V
............ ............ ............ ............ ............ ............ ............
: L2 : : L3 : : Service : : L1 : : L2 : : L3 : : Service :
: Topology : : Topology : : Topology : : Topology : : Topology : : Topology : : Topology :
: Model : : Model : : Model : : Model : : Model : : Model : : Model :
'''''''''''' '''''''''''' '''''''''''' '''''''''''' '''''''''''' '''''''''''' ''''''''''''
Figure 1: The network model structure Figure 1: The network model structure
The network-topology YANG module introduced in this document, The network-topology YANG module introduced in this document,
entitled "network-topology.yang", defines a generic topology model at entitled "network-topology.yang", defines a generic topology model at
its most general level of abstraction. The module defines a topology its most general level of abstraction. The module defines a topology
graph and components from which it is composed: nodes, edges and graph and components from which it is composed: nodes, edges and
termination points. Nodes (from the network.yang module) represent termination points. Nodes (from the network.yang module) represent
graph vertices and links represent graph edges. Nodes also contain graph vertices and links represent graph edges. Nodes also contain
termination points that anchor the links. A network can contain termination points that anchor the links. A network can contain
skipping to change at page 11, line 7 skipping to change at page 11, line 7
A link is identified by a link-id that uniquely identifies the link A link is identified by a link-id that uniquely identifies the link
within a given topology. Links are point-to-point and within a given topology. Links are point-to-point and
unidirectional. Accordingly, a link contains a source and a unidirectional. Accordingly, a link contains a source and a
destination. Both source and destination reference a corresponding destination. Both source and destination reference a corresponding
node, as well as a termination point on that node. Similar to a node, as well as a termination point on that node. Similar to a
node, a link can map onto one or more links in an underlay topology node, a link can map onto one or more links in an underlay topology
(which are terminated by the corresponding underlay termination (which are terminated by the corresponding underlay termination
points). This is captured in the list "supporting-link". points). This is captured in the list "supporting-link".
3.3. Discussion and selected design decisions 3.3. Extending the model
3.3.1. Container structure In order to derive a model for a specific type of network, the base
model can be extended. This can be done roughly as follows: for the
new network type, a new YANG module is introduced. In this module a
number of augmentations are defined against the network and network-
topology YANG modules.
We start with augmentations against the network.yang module. First,
a new network type needs to be defined. For this, a presence
container that resembles the new network type is defined. It is
inserted by means of augmentation below the network-types container.
Subsequently, data nodes for any network-type specific node
parameters are defined and augmented into the node list. The new
data nodes can be defined as conditional ("when") on the presence of
the corresponding network type in the containing network. In cases
where there are any requirements or restrictions in terms of network
hierarchies, such as when a network of a new network-type requires a
specific type of underlay network, it is possible to define
corresponding constraints as well and augment the supporting-network
list accordingly. However, care should be taken to avoid excessive
definitions of constraints.
Subsequently, augmentations are defined against network-
topology.yang. Data nodes are defined both for link parameters, as
well as termination point parameters, that are specific to the new
network type. Those data nodes are inserted by way of augmentation
into the link and termination-point lists, respectively. Again, data
nodes can be defined as conditional on the presence of the
corresponding network-type in the containing network, by adding a
corresponding "when"-statement.
It is possible, but not required, to group data nodes for a given
network-type under a dedicated container. Doing so introduces
further structure, but lengthens data node path names.
In cases where a hierarchy of network types is defined, augmentations
can in turn against augmenting modules, with the module of a network
"sub-type" augmenting the module of a network "super-type".
3.4. Discussion and selected design decisions
3.4.1. Container structure
Rather than maintaining lists in separate containers, the model is Rather than maintaining lists in separate containers, the model is
kept relatively flat in terms of its containment structure. Lists of kept relatively flat in terms of its containment structure. Lists of
nodes, links, termination-points, and supporting-nodes, supporting- nodes, links, termination-points, and supporting-nodes, supporting-
links, and supporting-termination-points are not kept in separate links, and supporting-termination-points are not kept in separate
containers. Therefore, path specifiers used to refer to specific containers. Therefore, path specifiers used to refer to specific
nodes, be it in management operations or in specifications of nodes, be it in management operations or in specifications of
constraints, can remain relatively compact. Of course, this means constraints, can remain relatively compact. Of course, this means
there is no separate structure in instance information that separates there is no separate structure in instance information that separates
elements of different lists from one another. Such structure is elements of different lists from one another. Such structure is
semantically not required, although it might enhance human semantically not required, although it might enhance human
readability in some cases. readability in some cases.
3.3.2. Underlay hierarchies and mappings 3.4.2. Underlay hierarchies and mappings
To minimize assumptions of what a particular entity might actually To minimize assumptions of what a particular entity might actually
represent, mappings between networks, nodes, links, and termination represent, mappings between networks, nodes, links, and termination
points are kept strictly generic. For example, no assumptions are points are kept strictly generic. For example, no assumptions are
made whether a termination point actually refers to an interface, or made whether a termination point actually refers to an interface, or
whether a node refers to a specific "system" or device; the model at whether a node refers to a specific "system" or device; the model at
this generic level makes no provisions for that. this generic level makes no provisions for that.
Where additional specifics about mappings between upper and lower Where additional specifics about mappings between upper and lower
layers are required, those can be captured in augmenting modules. layers are required, those can be captured in augmenting modules.
For example, to express that a termination point in a particular For example, to express that a termination point in a particular
network type maps to an interface, an augmenting module can introduce network type maps to an interface, an augmenting module can introduce
an augmentation to the termination point which introduces a leaf of an augmentation to the termination point which introduces a leaf of
type ifref that references the corresponding interface [RFC7223]. type ifref that references the corresponding interface [RFC7223].
Similarly, if a node maps to a particular device or network element, Similarly, if a node maps to a particular device or network element,
an augmenting module can augment the node data with a leaf that an augmenting module can augment the node data with a leaf that
references the network element. references the network element.
3.3.3. Use of groupings It is possible for links at one level of a hierarchy to map to
multiple links at another level of the hierarchy. For example, a VPN
topology might model VPN tunnels as links. Where a VPN tunnel maps
to a path that is composed of a chain of several links, the link will
contain a list of those supporting links. Likewise, it is possible
for a link at one level of a hierarchy to aggregate a bundle of links
at another level of the hierarchy.
3.4.3. Use of groupings
The model makes use of groupings, instead of simply defining data The model makes use of groupings, instead of simply defining data
nodes "in-line". This allows to more easily include the nodes "in-line". This allows to more easily include the
corresponding data nodes in notifications, which then do not need to corresponding data nodes in notifications, which then do not need to
respecify each data node that is to be included. The tradeoff for respecify each data node that is to be included. The tradeoff for
this is that it makes the specification of constraints more complex, this is that it makes the specification of constraints more complex,
because constraints involving data nodes outside the grouping need to because constraints involving data nodes outside the grouping need to
be specified in conjunction with a "uses" statement where the be specified in conjunction with a "uses" statement where the
grouping is applied. This also means that constraints and XPath- grouping is applied. This also means that constraints and XPath-
statements need to specified in such a way that they navigate "down" statements need to specified in such a way that they navigate "down"
first and select entire sets of nodes, as opposed to being able to first and select entire sets of nodes, as opposed to being able to
simply specify them against individual data nodes. simply specify them against individual data nodes.
3.3.4. Cardinality and directionality of links 3.4.4. Cardinality and directionality of links
The topology model includes links that are point-to-point and The topology model includes links that are point-to-point and
unidirectional. It does not directly support multipoint and unidirectional. It does not directly support multipoint and
bidirectional links. While this may appear as a limitation, it does bidirectional links. While this may appear as a limitation, it does
keep the model simple, generic, and allows it to very easily be keep the model simple, generic, and allows it to very easily be
subjected to applications that make use of graph algorithms. Bi- subjected to applications that make use of graph algorithms. Bi-
directional connections can be represented through pairs of directional connections can be represented through pairs of
unidirectional links. Multipoint networks can be represented through unidirectional links. Multipoint networks can be represented through
pseudo-nodes (similar to IS-IS, for example). By introducing pseudo-nodes (similar to IS-IS, for example). By introducing
hierarchies of nodes, with nodes at one level mapping onto a set of hierarchies of nodes, with nodes at one level mapping onto a set of
other nodes at another level, and introducing new links for nodes at other nodes at another level, and introducing new links for nodes at
that level, topologies with connections representing non-point-to- that level, topologies with connections representing non-point-to-
point communication patterns can be represented. point communication patterns can be represented.
3.3.5. Multihoming and link aggregation 3.4.5. Multihoming and link aggregation
Links are terminated by a single termination point, not sets of Links are terminated by a single termination point, not sets of
termination points. Connections involving multihoming or link termination points. Connections involving multihoming or link
aggregation schemes need to be represented using multiple point-to- aggregation schemes need to be represented using multiple point-to-
point links, then defining a link at a higher layer that is supported point links, then defining a link at a higher layer that is supported
by those individual links. by those individual links.
3.3.6. Mapping redundancy 3.4.6. Mapping redundancy
In a hierarchy of networks, there are nodes mapping to nodes, links In a hierarchy of networks, there are nodes mapping to nodes, links
mapping to links, and termination points mapping to termination mapping to links, and termination points mapping to termination
points. Some of this information is redundant. Specifically, if the points. Some of this information is redundant. Specifically, if the
link-to-links mapping known, and the termination points of each link link-to-links mapping known, and the termination points of each link
known, termination point mapping information can be derived via known, termination point mapping information can be derived via
transitive closure and does not have to be explicitly configured. transitive closure and does not have to be explicitly configured.
Nonetheless, in order to not constrain applications regarding which Nonetheless, in order to not constrain applications regarding which
mappings they want to configure and which should be derived, the mappings they want to configure and which should be derived, the
model does provide for the option to configure this information model does provide for the option to configure this information
explicitly. The model includes integrity constraints to allow for explicitly. The model includes integrity constraints to allow for
validating for consistency. validating for consistency.
3.3.7. Typing 3.4.7. Typing
A network's network types are represented using a container which A network's network types are represented using a container which
contains a data node for each of its network types. A network can contains a data node for each of its network types. A network can
encompass several types of network simultaneously, hence a container encompass several types of network simultaneously, hence a container
is used instead of a case construct, with each network type in turn is used instead of a case construct, with each network type in turn
represented by a dedicated presence container itself. The reason for represented by a dedicated presence container itself. The reason for
not simply using an empty leaf, or even simpler, do away even with not simply using an empty leaf, or even simpler, do away even with
the network container and just use a leaf-list of network-type the network container and just use a leaf-list of network-type
instead, is to be able to represent "class hierarchies" of network instead, is to be able to represent "class hierarchies" of network
types, with one network type refining the other. Network-type types, with one network type refining the other. Network-type
specific containers are to be defined in the network-specific specific containers are to be defined in the network-specific
modules, augmenting the network-types container. modules, augmenting the network-types container.
3.3.8. Representing the same device in multiple networks 3.4.8. Representing the same device in multiple networks
One common requirement concerns the ability to represent that the One common requirement concerns the ability to represent that the
same device can be part of multiple networks and topologies. same device can be part of multiple networks and topologies.
However, the model defines a node as relative to the network that it However, the model defines a node as relative to the network that it
is contained in. The same node cannot be part of multiple is contained in. The same node cannot be part of multiple
topologies. In many cases, a node will be the abstraction of a topologies. In many cases, a node will be the abstraction of a
particular device in a network. To reflect that the same device is particular device in a network. To reflect that the same device is
part of multiple topologies, the following approach might be chosen: part of multiple topologies, the following approach might be chosen:
A "physical" (or "device") network is introduced, with nodes A new type of network to represent a "physical" (or "device") network
representing devices. This network forms an underlay network for is introduced, with nodes representing devices. This network forms
logical networks above it, with nodes of the logical network mapping an underlay network for logical networks above it, with nodes of the
onto nodes in the physical network. logical network mapping onto nodes in the physical network.
This scenario is depicted in the following figure. It depicts three This scenario is depicted in the following figure. It depicts three
networks with two nodes each. A physical network P consists of an networks with two nodes each. A physical network P consists of an
inventory of two nodes, D1 and D2, each representing a device. A inventory of two nodes, D1 and D2, each representing a device. A
second network, X, has a third network, Y, as its underlay. Both X second network, X, has a third network, Y, as its underlay. Both X
and Y also have the physical network P as underlay. X1 has both Y1 and Y also have the physical network P as underlay. X1 has both Y1
and D1 as underlay nodes, while Y1 has D1 as underlay node. and D1 as underlay nodes, while Y1 has D1 as underlay node.
Likewise, X2 has both Y2 and D2 as underlay nodes, while Y2 has D2 as Likewise, X2 has both Y2 and D2 as underlay nodes, while Y2 has D2 as
underlay node. The fact that X1 and Y1 are both instantiated on the underlay node. The fact that X1 and Y1 are both instantiated on the
same physical node D1 can be easily derived. same physical node D1 can be easily derived.
skipping to change at page 14, line 5 skipping to change at page 15, line 21
/ [Y1]____[Y2]....: / :.. : / [Y1]____[Y2]....: / :.. :
+------|-------|-------+ :.. :... +------|-------|-------+ :.. :...
Y(L3) | +---------------------:-----+ : Y(L3) | +---------------------:-----+ :
| +----:----|-:----------+ | +----:----|-:----------+
+------------------------/---[D1] [D2] / +------------------------/---[D1] [D2] /
+----------------------+ +----------------------+
P (Physical network) P (Physical network)
Figure 6: Topology hierarchy example - multiple underlays Figure 6: Topology hierarchy example - multiple underlays
3.4. Items for further discussion In the case of a physical network, nodes represent physical devices
and termination points physical ports. It should be noted that it is
also conceivable to augment the model for a physical network-type,
defining augmentations that have nodes reference system information
and termination points reference physical interfaces, in order to
provide a bridge between network and device models.
3.5. Items for further discussion
YANG requires data needs to be designated as either configuration or YANG requires data needs to be designated as either configuration or
operational data, but not both, yet it is important to have all operational data, but not both, yet it is important to have all
network information, including vertical cross-network dependencies, network information, including vertical cross-network dependencies,
captured in one coherent model. In most cases network topology captured in one coherent model. In most cases network topology
information is discovered about a network; the topology is considered information is discovered about a network; the topology is considered
a property of the network that is reflected in the model. That said, a property of the network that is reflected in the model. That said,
it is conceivable that certain types of topology need to also be it is conceivable that certain types of topology need to also be
configurable by an application. configurable by an application.
skipping to change at page 15, line 14 skipping to change at page 16, line 37
import ietf-inet-types { prefix inet; } import ietf-inet-types { prefix inet; }
organization "TBD"; organization "TBD";
contact contact
"WILL-BE-DEFINED-LATER"; "WILL-BE-DEFINED-LATER";
description description
"This module defines a common base model for a collection "This module defines a common base model for a collection
of nodes in a network. Node definitions s are further used of nodes in a network. Node definitions s are further used
in network topologies and inventories."; in network topologies and inventories.";
revision 2014-3-5 { revision 2014-3-9 {
description description
"Initial revision."; "Initial revision.";
reference "draft-clemm-i2rs-yang-network-topo-03"; reference "draft-clemm-i2rs-yang-network-topo-04";
} }
typedef node-id { typedef node-id {
type inet:uri; type inet:uri;
} }
typedef network-id { typedef network-id {
type inet:uri; type inet:uri;
} }
skipping to change at page 17, line 17 skipping to change at page 18, line 41
import ietf-inet-types { prefix inet; } import ietf-inet-types { prefix inet; }
import nodes { prefix nd; } import nodes { prefix nd; }
organization "TBD"; organization "TBD";
contact contact
"WILL-BE-DEFINED-LATER"; "WILL-BE-DEFINED-LATER";
description description
"This module defines a common base model for a collection of links "This module defines a common base model for a collection of links
connecting nodes."; connecting nodes.";
revision 2014-3-5 { revision 2014-3-9 {
description description
"Initial revision."; "Initial revision.";
reference "draft-clemm-i2rs-yang-network-topo-03"; reference "draft-clemm-i2rs-yang-network-topo-04";
} }
typedef link-id { typedef link-id {
type inet:uri; type inet:uri;
description description
"An identifier for a link in a topology. "An identifier for a link in a topology.
The identifier may be opaque. The identifier may be opaque.
The identifier SHOULD be chosen such that the same link in a The identifier SHOULD be chosen such that the same link in a
real network topology will always be identified through the real network topology will always be identified through the
same identifier, even if the model is instantiated in separate same identifier, even if the model is instantiated in separate
datastores. An implementation MAY choose to capture semantics datastores. An implementation MAY choose to capture semantics
in the identifier, for example to indicate the type of link in the identifier, for example to indicate the type of link
and/or the type of topology that the link is a part of."; and/or the type of topology that the link is a part of.";
} }
typedef tp-id { typedef tp-id {
type inet:uri; type inet:uri;
skipping to change at page 22, line 22 skipping to change at page 23, line 42
o Tom Nadeau, Brocade o Tom Nadeau, Brocade
o Aleksandr Zhdankin, Cisco o Aleksandr Zhdankin, Cisco
7. Acknowledgements 7. Acknowledgements
We wish to acknowledge the helpful contributions, comments, and We wish to acknowledge the helpful contributions, comments, and
suggestions that were received from Alia Atlas, Vishna Pavan Beeram, suggestions that were received from Alia Atlas, Vishna Pavan Beeram,
Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan
Hares, Xufeng Liu, Ladislav Lhotka, Carlos Pignataro, and Juergen Hares, Xufeng Liu, Ladislav Lhotka, Carlos Pignataro, Juergen
Schoenwaelder. Schoenwaelder, and Xian Zhang.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
 End of changes. 23 change blocks. 
52 lines changed or deleted 108 lines changed or added

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