draft-ietf-teas-interconnected-te-info-exchange-06.txt   draft-ietf-teas-interconnected-te-info-exchange-07.txt 
Network Working Group A. Farrel (Ed.) Network Working Group A. Farrel (Ed.)
Internet-Draft J. Drake Internet-Draft J. Drake
Intended status: Best Current Practice Juniper Networks Intended status: Best Current Practice Juniper Networks
Expires: November 10, 2016 Expires: November 21, 2016
N. Bitar N. Bitar
Nokia Nokia
G. Swallow G. Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
X. Zhang X. Zhang
Huawei Huawei
May 10, 2016 May 21, 2016
Problem Statement and Architecture for Information Exchange Problem Statement and Architecture for Information Exchange
Between Interconnected Traffic Engineered Networks Between Interconnected Traffic Engineered Networks
draft-ietf-teas-interconnected-te-info-exchange-06.txt draft-ietf-teas-interconnected-te-info-exchange-07.txt
Abstract Abstract
In Traffic Engineered (TE) systems, it is sometimes desirable to In Traffic Engineered (TE) systems, it is sometimes desirable to
establish an end-to-end TE path with a set of constraints (such as establish an end-to-end TE path with a set of constraints (such as
bandwidth) across one or more network from a source to a destination. bandwidth) across one or more network from a source to a destination.
TE information is the data relating to nodes and TE links that is TE information is the data relating to nodes and TE links that is
used in the process of selecting a TE path. TE information is used in the process of selecting a TE path. TE information is
usually only available within a network. We call such a zone of usually only available within a network. We call such a zone of
visibility of TE information a domain. An example of a domain may be visibility of TE information a domain. An example of a domain may be
skipping to change at page 3, line 7 skipping to change at page 3, line 7
(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 ................................................. 5 1. Introduction .................................................. 5
1.1. Terminology ................................................ 6 1.1. Terminology ................................................ 6
1.1.1. TE Paths and TE Connections .............................. 6 1.1.1. TE Paths and TE Connections ............................... 6
1.1.2. TE Metrics and TE Attributes ............................. 6 1.1.2. TE Metrics and TE Attributes .............................. 6
1.1.3. TE Reachability .......................................... 7 1.1.3. TE Reachability ........................................... 7
1.1.4. Domain ................................................... 7 1.1.4. Domain .................................................... 7
1.1.5. Server Network ........................................... 7 1.1.5. Server Network ............................................ 7
1.1.6. Client Network ........................................... 7 1.1.6. Client Network ............................................ 7
1.1.7. Aggregation .............................................. 7 1.1.7. Aggregation ............................................... 7
1.1.8. Abstraction .............................................. 8 1.1.8. Abstraction ............................................... 8
1.1.9. Abstract Link ............................................ 8 1.1.9. Abstract Link ............................................. 8
1.1.10. Abstract Node or Virtual Node ........................... 8 1.1.10. Abstract Node or Virtual Node ............................ 8
1.1.11. Abstraction Layer Network ............................... 9 1.1.11. Abstraction Layer Network ................................ 9
2. Overview of Use Cases ........................................ 9 2. Overview of Use Cases ......................................... 9
2.1. Peer Networks .............................................. 9 2.1. Peer Networks ............................................... 9
2.2. Client-Server Networks ..................................... 11 2.2. Client-Server Networks ...................................... 11
2.3. Dual-Homing ................................................ 13 2.3. Dual-Homing ................................................. 13
2.4. Requesting Connectivity .................................... 14 2.4. Requesting Connectivity ..................................... 14
2.4.1. Discovering Server Network Information ................... 16 2.4.1. Discovering Server Network Information .................... 16
3. Problem Statement ............................................ 16 3. Problem Statement ............................................. 16
3.1. Policy and Filters ......................................... 17 3.1. Policy and Filters .......................................... 17
3.2. Confidentiality ............................................ 17 3.2. Confidentiality ............................................. 17
3.3. Information Overload ....................................... 18 3.3. Information Overload ........................................ 18
3.4. Issues of Information Churn ................................ 18 3.4. Issues of Information Churn ................................. 18
3.5. Issues of Aggregation ...................................... 19 3.5. Issues of Aggregation ....................................... 19
4. Architecture ................................................. 20 4. Architecture .................................................. 20
4.1. TE Reachability ............................................ 20 4.1. TE Reachability ............................................. 20
4.2. Abstraction not Aggregation ................................ 21 4.2. Abstraction not Aggregation ................................. 21
4.2.1. Abstract Links ........................................... 22 4.2.1. Abstract Links ............................................ 22
4.2.2. The Abstraction Layer Network ............................ 22 4.2.2. The Abstraction Layer Network ............................. 22
4.2.3. Abstraction in Client-Server Networks..................... 25 4.2.3. Abstraction in Client-Server Networks...................... 25
4.2.4. Abstraction in Peer Networks ............................. 30 4.2.4. Abstraction in Peer Networks .............................. 30
4.3. Considerations for Dynamic Abstraction ..................... 32 4.3. Considerations for Dynamic Abstraction ...................... 32
4.4. Requirements for Advertising Links and Nodes ............... 33 4.4. Requirements for Advertising Links and Nodes ................ 33
4.5. Addressing Considerations .................................. 34 4.5. Addressing Considerations ................................... 34
5. Building on Existing Protocols ............................... 34 5. Building on Existing Protocols ................................ 34
5.1. BGP-LS ..................................................... 35 5.1. BGP-LS ...................................................... 35
5.2. IGPs ....................................................... 35 5.2. IGPs ........................................................ 35
5.3. RSVP-TE .................................................... 35 5.3. RSVP-TE ..................................................... 35
5.4. Notes on a Solution ........................................ 35 5.4. Notes on a Solution ......................................... 35
6. Applicability to Optical Domains and Networks ................. 37 6. Application of the Architecture to Optical Domains and Networks 37
7. Modeling the User-to-Network Interface ....................... 41 7. Application of the Architecture to the User-to-Network Interface
8. Abstraction in L3VPN Multi-AS Environments ................... 43 41
9. Scoping Future Work .......................................... 44 8. Application of the Architecture to L3VPN Multi-AS Environments 43
9.1. Not Solving the Internet ................................... 44 9. Scoping Future Work ........................................... 44
9.2. Working With "Related" Domains ............................. 44 9.1. Not Solving the Internet .................................... 44
9.3. Not Finding Optimal Paths in All Situations ................ 44 9.2. Working With "Related" Domains .............................. 44
9.4. Sanity and Scaling ......................................... 44 9.3. Not Finding Optimal Paths in All Situations ................. 44
10. Manageability Considerations ................................ 45 9.4. Sanity and Scaling .......................................... 44
10.1. Managing the Abstraction Layer Network .................... 45 10. Manageability Considerations ................................. 45
10.2. Managing Interactions of Client and Abstraction Layer Networks 10.1. Managing the Abstraction Layer Network ..................... 45
10.2. Managing Interactions of Client and Abstraction Layer Networks
46 46
10.3. Managing Interactions of Abstraction Layer and Server Networks 10.3. Managing Interactions of Abstraction Layer and Server Networks
46 46
11. IANA Considerations ......................................... 47 11. IANA Considerations .......................................... 47
12. Security Considerations ..................................... 47 12. Security Considerations ...................................... 47
13. Acknowledgements ............................................ 48 13. Acknowledgements ............................................. 48
14. References .................................................. 49 14. References ................................................... 49
14.1. Informative References .................................... 49 14.1. Informative References ..................................... 49
Authors' Addresses ............................................... 52 Authors' Addresses ............................................... 52
Contributors ..................................................... 53 Contributors ..................................................... 53
A. Existing Work ................................................ 55 A. Existing Work ................................................. 55
A.1. Per-Domain Path Computation ................................ 55 A.1. Per-Domain Path Computation ................................. 55
A.2. Crankback .................................................. 55 A.2. Crankback ................................................... 55
A.3. Path Computation Element ................................... 56 A.3. Path Computation Element .................................... 56
A.4. GMPLS UNI and Overlay Networks ............................. 58 A.4. GMPLS UNI and Overlay Networks .............................. 58
A.5. Layer One VPN .............................................. 58 A.5. Layer One VPN ............................................... 58
A.6. Policy and Link Advertisement .............................. 59 A.6. Policy and Link Advertisement ............................... 59
B. Additional Features .......................................... 60 B. Additional Features ........................................... 60
B.1. Macro Shared Risk Link Groups .............................. 60 B.1. Macro Shared Risk Link Groups ............................... 60
B.2. Mutual Exclusivity ......................................... 61 B.2. Mutual Exclusivity .......................................... 61
1. Introduction 1. Introduction
Traffic Engineered (TE) systems such as MPLS-TE [RFC2702] and GMPLS Traffic Engineered (TE) systems such as MPLS-TE [RFC2702] and GMPLS
[RFC3945] offer a way to establish paths through a network in a [RFC3945] offer a way to establish paths through a network in a
controlled way that reserves network resources on specified links. controlled way that reserves network resources on specified links.
TE paths are computed by examining the Traffic Engineering Database TE paths are computed by examining the Traffic Engineering Database
(TED) and selecting a sequence of links and nodes that are capable of (TED) and selecting a sequence of links and nodes that are capable of
meeting the requirements of the path to be established. The TED is meeting the requirements of the path to be established. The TED is
constructed from information distributed by the IGP running in the constructed from information distributed by the IGP running in the
skipping to change at page 25, line 17 skipping to change at page 25, line 17
Figure 9 shows the basic architectural concepts for a client-server Figure 9 shows the basic architectural concepts for a client-server
network. The client network nodes are C1, C2, CE1, CE2, C3, and C4. network. The client network nodes are C1, C2, CE1, CE2, C3, and C4.
The server (core) network nodes are CN1, CN2, CN3, and CN4. The The server (core) network nodes are CN1, CN2, CN3, and CN4. The
interfaces CE1-CN1 and CE2-CN2 are the interfaces between the client interfaces CE1-CN1 and CE2-CN2 are the interfaces between the client
and server networks. and server networks.
The technologies (switching capabilities) of the client and server The technologies (switching capabilities) of the client and server
networks may be the same or different. If they are different, the networks may be the same or different. If they are different, the
client network traffic must be tunneled over a server network LSP. client network traffic must be tunneled over a server network LSP.
If they are the same, the client network LSP may be routed over the If they are the same, the client network LSP may be routed over the
server network links, tunneled over a server network LSP, or server network links, tunneled over a server network LSP, or
constructed from the concatenation (stitching) of client network and constructed from the concatenation (stitching) of client network and
server network LSP segments. server network LSP segments.
: : : :
Client Network : Server Network : Client Network Client Network : Server Network : Client Network
: : : :
-- -- --- --- -- -- -- -- --- --- -- --
|C1|--|C2|--|CE1|................................|CE2|--|C3|--|C4| |C1|--|C2|--|CE1|................................|CE2|--|C3|--|C4|
-- -- | | --- --- | | -- -- -- -- | | --- --- | | -- --
| |===|CN1|================|CN4|===| | | |===|CN1|================|CN4|===| |
skipping to change at page 34, line 33 skipping to change at page 34, line 33
from S to T, it must map those addresses from its own address space from S to T, it must map those addresses from its own address space
to that of the client network. to that of the client network.
This form of address mapping will become particularly important in This form of address mapping will become particularly important in
cases where one abstraction layer network is constructed from cases where one abstraction layer network is constructed from
connectivity in multiple server networks, or where one abstraction connectivity in multiple server networks, or where one abstraction
layer network provides connectivity for multiple client networks. layer network provides connectivity for multiple client networks.
5. Building on Existing Protocols 5. Building on Existing Protocols
This section is not intended to prejudge a solutions framework or any This section is non-normative and is not intended to prejudge a
applicability work. It does, however, very briefly serve to note the solutions framework or any applicability work. It does, however,
existence of protocols that could be examined for applicability to very briefly serve to note the existence of protocols that could be
serve in realizing the model described in this document. examined for applicability to serve in realizing the model described
in this document.
The general principle of protocol re-use is preferred over the The general principle of protocol re-use is preferred over the
invention of new protocols or additional protocol extensions, and it invention of new protocols or additional protocol extensions, and it
would be advantageous to make use of an existing protocol that is would be advantageous to make use of an existing protocol that is
commonly implemented on network nodes and is currently deployed, or commonly implemented on network nodes and is currently deployed, or
to use existing computational elements such as Path Computation to use existing computational elements such as Path Computation
Elements (PCEs). This has many benefits in network stability, time Elements (PCEs). This has many benefits in network stability, time
to deployment, and operator training. to deployment, and operator training.
It is recognized, however, that existing protocols are unlikely to be It is recognized, however, that existing protocols are unlikely to be
skipping to change at page 37, line 30 skipping to change at page 37, line 30
become available for use by traffic in the client network. become available for use by traffic in the client network.
Sections 6, 7, and 8 discuss the applicability of this architecture Sections 6, 7, and 8 discuss the applicability of this architecture
to different network types and problem spaces, while Section 9 gives to different network types and problem spaces, while Section 9 gives
some advice about scoping future work. Section 9 on manageability some advice about scoping future work. Section 9 on manageability
considerations is particularly relevant in the context of this considerations is particularly relevant in the context of this
section because it contains a discussion of the policies and section because it contains a discussion of the policies and
mechanisms for indicating connectivity and link availability between mechanisms for indicating connectivity and link availability between
network layers in this architecture. network layers in this architecture.
6. Applicability to Optical Domains and Networks 6. Application of the Architecture to Optical Domains and Networks
Many optical networks are arranged as a set of small domains. Each Many optical networks are arranged as a set of small domains. Each
domain is a cluster of nodes, usually from the same equipment vendor domain is a cluster of nodes, usually from the same equipment vendor
and with the same properties. The domain may be constructed as a and with the same properties. The domain may be constructed as a
mesh or a ring, or maybe as an interconnected set of rings. mesh or a ring, or maybe as an interconnected set of rings.
The network operator seeks to provide end-to-end connectivity across The network operator seeks to provide end-to-end connectivity across
a network constructed from multiple domains, and so (of course) the a network constructed from multiple domains, and so (of course) the
domains are interconnected. In a network under management control domains are interconnected. In a network under management control
such as through an Operations Support System (OSS), each domain is such as through an Operations Support System (OSS), each domain is
skipping to change at page 41, line 28 skipping to change at page 41, line 28
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Domain 1 Domain 2 Domain 3 Domain 1 Domain 2 Domain 3
Key Optical Layer Key Optical Layer
... Layer separation ... Layer separation
--- Physical link --- Physical link
=== Abstract link === Abstract link
Figure 21 : The Optical Network Implemented Through the Figure 21 : The Optical Network Implemented Through the
Abstraction Layer Network Abstraction Layer Network
7. Modeling the User-to-Network Interface 7. Application of the User-to-Network Interface
The User-to-Network Interface (UNI) is an important architectural The User-to-Network Interface (UNI) is an important architectural
concept in many implementations and deployments of client-server concept in many implementations and deployments of client-server
networks especially those where the client and server network have networks especially those where the client and server network have
different technologies. The UNI can be seen described in [G.8080], different technologies. The UNI can be seen described in [G.8080],
and the GMPLS approach to the UNI is documented in [RFC4208]. Other and the GMPLS approach to the UNI is documented in [RFC4208]. Other
GMPLS-related documents describe the application of GMPLS to specific GMPLS-related documents describe the application of GMPLS to specific
UNI scenarios: for example, [RFC6005] describes how GMPLS can support UNI scenarios: for example, [RFC6005] describes how GMPLS can support
a UNI that provides access to Ethernet services. a UNI that provides access to Ethernet services.
skipping to change at page 43, line 5 skipping to change at page 43, line 5
the UNI. This can be particularly important when reachability across the UNI. This can be particularly important when reachability across
the server network is limited or when two diverse paths are desired the server network is limited or when two diverse paths are desired
(for example, to provide protection). However, in the model (for example, to provide protection). However, in the model
described in this network, the edge node (the UNI-C) is part of the described in this network, the edge node (the UNI-C) is part of the
abstraction layer network and can see sufficient topology information abstraction layer network and can see sufficient topology information
to make these decisions. If the approach introduced in this document to make these decisions. If the approach introduced in this document
is used to model the UNI as described in this section, there is no is used to model the UNI as described in this section, there is no
need to enhance the signaling protocols at the GMPLS UNI nor to add need to enhance the signaling protocols at the GMPLS UNI nor to add
routing exchanges at the UNI. routing exchanges at the UNI.
8. Abstraction in L3VPN Multi-AS Environments 8. Application of the Architecture to L3VPN Multi-AS Environments
Serving layer-3 VPNs (L3PVNs) across a multi-AS or multi-operator Serving layer-3 VPNs (L3PVNs) across a multi-AS or multi-operator
environment currently provides a significant planning challenge. environment currently provides a significant planning challenge.
Figure 6 shows the general case of the problem that needs to be Figure 6 shows the general case of the problem that needs to be
solved. This section shows how the abstraction layer network can solved. This section shows how the abstraction layer network can
address this problem. address this problem.
In the VPN architecture, the CE nodes are the client network edge In the VPN architecture, the CE nodes are the client network edge
nodes, and the PE nodes are the server network edge nodes. The nodes, and the PE nodes are the server network edge nodes. The
abstraction layer network is made up of the CE nodes, the CE-PE abstraction layer network is made up of the CE nodes, the CE-PE
skipping to change at page 44, line 16 skipping to change at page 44, line 16
at the same PE. Alternatively, multiple VPNs can share the same at the same PE. Alternatively, multiple VPNs can share the same
abstraction layer network if that is operationally preferable. abstraction layer network if that is operationally preferable.
Lastly, just as for the UNI discussed in Section 7, the issue of Lastly, just as for the UNI discussed in Section 7, the issue of
dual-homing of VPN sites is a function of the abstraction layer dual-homing of VPN sites is a function of the abstraction layer
network and so is just a normal routing problem in that network. network and so is just a normal routing problem in that network.
9. Scoping Future Work 9. Scoping Future Work
The section is provided to help guide the work on this problem and to The section is provided to help guide the work on this problem and to
ensure that oceans are not knowingly boiled. ensure that oceans are not knowingly boiled. This guidance is non-
normative for this architecture description.
9.1. Not Solving the Internet 9.1. Not Solving the Internet
The scope of the use cases and problem statement in this document is The scope of the use cases and problem statement in this document is
limited to "some small set of interconnected domains." In limited to "some small set of interconnected domains." In
particular, it is not the objective of this work to turn the whole particular, it is not the objective of this work to turn the whole
Internet into one large, interconnected TE network. Internet into one large, interconnected TE network.
9.2. Working With "Related" Domains 9.2. Working With "Related" Domains
skipping to change at page 55, line 8 skipping to change at page 55, line 8
Cyril Margaria Cyril Margaria
Email: cyril.margaria@googlemail.com Email: cyril.margaria@googlemail.com
Victor Lopez Victor Lopez
Email: vlopez@tid.es Email: vlopez@tid.es
Appendix A. Existing Work Appendix A. Existing Work
This appendix briefly summarizes relevant existing work that is used This appendix briefly summarizes relevant existing work that is used
to route TE paths across multiple domains. to route TE paths across multiple domains. It is non-normative.
A.1. Per-Domain Path Computation A.1. Per-Domain Path Computation
The per-domain mechanism of path establishment is described in The per-domain mechanism of path establishment is described in
[RFC5152] and its applicability is discussed in [RFC4726]. In [RFC5152] and its applicability is discussed in [RFC4726]. In
summary, this mechanism assumes that each domain entry point is summary, this mechanism assumes that each domain entry point is
responsible for computing the path across the domain, but that responsible for computing the path across the domain, but that
details of the path in the next domain are left to the next domain details of the path in the next domain are left to the next domain
entry point. The computation may be performed directly by the entry entry point. The computation may be performed directly by the entry
point or may be delegated to a computation server. point or may be delegated to a computation server.
skipping to change at page 60, line 8 skipping to change at page 60, line 8
connectivity from client edge to client edge is achieved using connectivity from client edge to client edge is achieved using
dynamic signalling then there is need for the end points to exchange dynamic signalling then there is need for the end points to exchange
the link properties that they should advertise within the client the link properties that they should advertise within the client
network, and in the case of support for more than one client network, network, and in the case of support for more than one client network,
it will be necessary to indicate which client network or networks can it will be necessary to indicate which client network or networks can
use the link. This capability it provided in [RFC6107]. use the link. This capability it provided in [RFC6107].
Appendix B. Additional Features Appendix B. Additional Features
This Appendix describes additional features that may be desirable and This Appendix describes additional features that may be desirable and
that can be achieved within this architecture. that can be achieved within this architecture. It is non-normative.
B.1. Macro Shared Risk Link Groups B.1. Macro Shared Risk Link Groups
Network links often share fate with one or more other links. That Network links often share fate with one or more other links. That
is, a scenario that may cause a link to fail could cause one or more is, a scenario that may cause a link to fail could cause one or more
other links to fail. This may occur, for example, if the links are other links to fail. This may occur, for example, if the links are
supported by the same fiber bundle, or if some links are routed down supported by the same fiber bundle, or if some links are routed down
the same duct or in a common piece of infrastructure such as a the same duct or in a common piece of infrastructure such as a
bridge. A common way to identify the links that may share fate is to bridge. A common way to identify the links that may share fate is to
label them as belonging to a Shared Risk Link Group (SRLG) [RFC4202]. label them as belonging to a Shared Risk Link Group (SRLG) [RFC4202].
 End of changes. 16 change blocks. 
80 lines changed or deleted 83 lines changed or added

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