draft-ietf-teas-interconnected-te-info-exchange-03.txt   draft-ietf-teas-interconnected-te-info-exchange-04.txt 
Network Working Group A. Farrel (Ed.) Network Working Group A. Farrel (Ed.)
Internet-Draft J. Drake Internet-Draft J. Drake
Intended status: Standards Track Juniper Networks Intended status: Best Current Practice Juniper Networks
Expires: April 15, 2016 Expires: September 20, 2016
N. Bitar N. Bitar
Verizon Networks Nuage Networks
G. Swallow G. Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
X. Zhang X. Zhang
Huawei Huawei
October 15, 2015 March 20, 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-03.txt draft-ietf-teas-interconnected-te-info-exchange-04.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 2, line 17 skipping to change at page 2, line 17
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."
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 3, line 16 skipping to change at page 3, line 16
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 .......................................... 6 1.1.3. TE Reachability .......................................... 6
1.1.4. Domain ................................................... 7 1.1.4. Domain ................................................... 7
1.1.5. Aggregation .............................................. 7 1.1.5. Aggregation .............................................. 7
1.1.6. Abstraction .............................................. 7 1.1.6. Abstraction .............................................. 7
1.1.7. Abstract Link ............................................ 7 1.1.7. Abstract Link ............................................ 7
1.1.8. Abstraction Layer Network ................................ 8 1.1.8. Abstract Node or Virtual Node ............................ 8
1.1.9. Abstraction Layer Network ................................ 8
2. Overview of Use Cases ........................................ 8 2. Overview of Use Cases ........................................ 8
2.1. Peer Networks .............................................. 8 2.1. Peer Networks .............................................. 8
2.2. Client-Server Networks ..................................... 10 2.2. Client-Server Networks ..................................... 10
2.3. Dual-Homing ................................................ 12 2.3. Dual-Homing ................................................ 12
2.4. Requesting Connectivity .................................... 13 2.4. Requesting Connectivity .................................... 13
2.4.1. Discovering Server Network Information ................... 15 2.4.1. Discovering Server Network Information ................... 15
3. Problem Statement ............................................ 15 3. Problem Statement ............................................ 15
3.1. Policy and Filters ......................................... 15 3.1. Policy and Filters ......................................... 15
3.2. Confidentiality ............................................ 15 3.2. Confidentiality ............................................ 15
3.3. Information Overload ....................................... 17 3.3. Information Overload ....................................... 17
skipping to change at page 8, line 5 skipping to change at page 8, line 5
1.1.7. Abstract Link 1.1.7. Abstract Link
An abstract link is the representation of the characteristics of a An abstract link is the representation of the characteristics of a
path between two nodes in a domain produced by abstraction. The path between two nodes in a domain produced by abstraction. The
abstract link is advertised outside that domain as a TE link for use abstract link is advertised outside that domain as a TE link for use
in signaling in other domains. Thus, an abstract link represents in signaling in other domains. Thus, an abstract link represents
the potential to connect between a pair of nodes. the potential to connect between a pair of nodes.
More details of abstract links are provided in Section 4.2.1. More details of abstract links are provided in Section 4.2.1.
1.1.8. Abstraction Layer Network 1.1.8. Abstract Node or Virtual Node
An abstract node was defined in [RFC3209] as a group of nodes whose
internal topology is opaque to an ingress node of the LSP. More
generally, an abstract node or virtual node is the representation as
a single node in a TE topology of one or more nodes and the links
that connect them. An abstract node may be advertised outside the
domain as a TE node for use in path computation and signaling in
other domains.
Sections 3.5 and 4.2.2.1 provide more information about the uses
and issues of abstract nodes and virtual nodes.
1.1.9. Abstraction Layer Network
The abstraction layer network is introduced in Section 4.2.2. It may The abstraction layer network is introduced in Section 4.2.2. It may
be seen as a brokerage layer network between one or more server be seen as a brokerage layer network between one or more server
networks and one or more client network. The abstraction layer networks and one or more client network. The abstraction layer
network is the collection of abstract links that provide potential network is the collection of abstract links that provide potential
connectivity across the server network(s) and on which path connectivity across the server network(s) and on which path
computation can be performed to determine edge-to-edge paths that computation can be performed to determine edge-to-edge paths that
provide connectivity as links in the client network. provide connectivity as links in the client network.
In the simplest case, the abstraction layer network is just a set of In the simplest case, the abstraction layer network is just a set of
skipping to change at page 8, line 39 skipping to change at page 8, line 52
the wrong point of interconnection can lead to a sub-optimal path, or the wrong point of interconnection can lead to a sub-optimal path, or
even fail to make a path available. Note that peer networks are even fail to make a path available. Note that peer networks are
assumed to have the same technology type: that is, the same assumed to have the same technology type: that is, the same
"switching capability" to use the term from GMPLS [RFC3945]. "switching capability" to use the term from GMPLS [RFC3945].
For example, when Domain A attempts to select a path, it may For example, when Domain A attempts to select a path, it may
determine that adequate bandwidth is available from Src through both determine that adequate bandwidth is available from Src through both
interconnection points x1 and x2. It may pick the path through x1 interconnection points x1 and x2. It may pick the path through x1
for local policy reasons: perhaps the TE metric is smaller. However, for local policy reasons: perhaps the TE metric is smaller. However,
if there is no connectivity in Domain Z from x1 to Dst, the path if there is no connectivity in Domain Z from x1 to Dst, the path
cannot be established. Techniques such as crankback (see Section cannot be established. Techniques such as crankback may be used to
4.1) may be used to alleviate this situation, but do not lead to alleviate this situation, but do not lead to rapid setup or
rapid setup or guaranteed optimality. Furthermore RSVP signalling guaranteed optimality. Furthermore RSVP signalling creates state in
creates state in the network that is immediately removed by the the network that is immediately removed by the crankback procedure.
crankback procedure. Frequent events of such a kind impact Frequent events of such a kind impact scalability in a non-
scalability in a non-deterministic manner. deterministic manner. More details of crankback can be found in
Section A.2.
-------------- -------------- -------------- --------------
| Domain A | x1 | Domain Z | | Domain A | x1 | Domain Z |
| ----- +----+ ----- | | ----- +----+ ----- |
| | Src | +----+ | Dst | | | | Src | +----+ | Dst | |
| ----- | x2 | ----- | | ----- | x2 | ----- |
-------------- -------------- -------------- --------------
Figure 1 : Peer Networks Figure 1 : Peer Networks
There are countless more complicated examples of the problem of peer There are countless more complicated examples of the problem of peer
networks. Figure 2 shows the case where there is a simple mesh of networks. Figure 2 shows the case where there is a simple mesh of
domains. Clearly, to find a TE path from Src to Dst, Domain A must domains. Clearly, to find a TE path from Src to Dst, Domain A must
not select a path leaving through interconnect x1 since Domain B has not select a path leaving through interconnect x1 since Domain B has
no connectivity to Domain Z. Furthermore, in deciding whether to no connectivity to Domain Z. Furthermore, in deciding whether to
select interconnection x2 (through Domain C) or interconnection x3
though Domain D, Domain A must be sensitive to the TE connectivity
available through each of Domains C and D, as well the TE
connectivity from each of interconnections x4 and x5 to Dst within
Domain Z. The problem may be further complicated when the source
domain does not know in which domain the destination node is located,
since the choice of a domain path clearly depends on the knowledge of
the destination domain: this issue is obviously mitigated in IP
networks by inter-domain routing [RFC4271].
-------------- --------------
| Domain B | | Domain B |
| | | |
| | | |
/-------------- /--------------
/ /
/ /
/x1 /x1
--------------/ -------------- --------------/ --------------
skipping to change at page 9, line 47 skipping to change at page 10, line 5
\ / \ /
\ /x5 \ /x5
\--------------/ \--------------/
| Domain D | | Domain D |
| | | |
| | | |
-------------- --------------
Figure 2 : Peer Networks in a Mesh Figure 2 : Peer Networks in a Mesh
select interconnection x2 (through Domain C) or interconnection x3
though Domain D, Domain A must be sensitive to the TE connectivity
available through each of Domains C and D, as well the TE
connectivity from each of interconnections x4 and x5 to Dst within
Domain Z. The problem may be further complicated when the source
domain does not know in which domain the destination node is located,
since the choice of a domain path clearly depends on the knowledge of
the destination domain: this issue is obviously mitigated in IP
networks by inter-domain routing [RFC4271].
Of course, many network interconnection scenarios are going to be a Of course, many network interconnection scenarios are going to be a
combination of the situations expressed in these two examples. There combination of the situations expressed in these two examples. There
may be a mesh of domains, and the domains may have multiple points of may be a mesh of domains, and the domains may have multiple points of
interconnection. interconnection.
2.2. Client-Server Networks 2.2. Client-Server Networks
Two major classes of use case relate to the client-server Two major classes of use case relate to the client-server
relationship between networks. These use cases have sometimes been relationship between networks. These use cases have sometimes been
referred to as overlay networks. In both cases, the client and referred to as overlay networks. In both cases, the client and
server network may have the same switching capability, or may be server network may have the same switching capability, or may be
built from nodes and links that have different technology types in built from nodes and links that have different technology types in
the client and server networks. the client and server networks.
The first group of use cases, shown in Figure 3, occurs when domains The first group of use cases, shown in Figure 3, occurs when domains
belonging to one network are connected by a domain belonging to belonging to one network are connected by a domain belonging to
another network. In this scenario, once connectivity is formed another network. In this scenario, once connectivity is formed
across the lower layer network, the domains of the upper layer across the lower layer network, the domains of the upper layer
network can be merged into a single domain by running IGP adjacencies network can be merged into a single domain by running IGP adjacencies
and by treating the server layer connectivity as links in the higher
layer network. The TE relationship between the domains (higher and
lower layer) in this case is reduced to determining what server layer
connectivity to establish, how to trigger it, how to route it in the
server layer, and what resources and capacity to assign within the
server layer. As the demands in the higher layer network vary, the
connectivity in the server layer may need to be modified. Section
2.4 explains in a little more detail how connectivity may be
requested.
-------------- -------------- -------------- --------------
| Domain A | | Domain Z | | Domain A | | Domain Z |
| | | | | | | |
| ----- | | ----- | | ----- | | ----- |
| | Src | | | | Dst | | | | Src | | | | Dst | |
| ----- | | ----- | | ----- | | ----- |
| | | | | | | |
--------------\ /-------------- --------------\ /--------------
\x1 x2/ \x1 x2/
\ / \ /
\ / \ /
\---------------/ \---------------/
| Server Domain | | Server Domain |
| | | |
| | | |
--------------- ---------------
Figure 3 : Client-Server Networks Figure 3 : Client-Server Networks
and by treating the server layer connectivity as links in the higher
layer network. The TE relationship between the domains (higher and
lower layer) in this case is reduced to determining what server layer
connectivity to establish, how to trigger it, how to route it in the
server layer, and what resources and capacity to assign within the
server layer. As the demands in the higher layer network vary, the
connectivity in the server layer may need to be modified. Section
2.4 explains in a little more detail how connectivity may be
requested.
The second class of use case of client-server networking is for The second class of use case of client-server networking is for
Virtual Private Networks (VPNs). In this case, as opposed to the Virtual Private Networks (VPNs). In this case, as opposed to the
former one, it is assumed that the client network has a different former one, it is assumed that the client network has a different
address space than that of the server layer where non-overlapping IP address space than that of the server layer where non-overlapping IP
addresses between the client and the server networks cannot be addresses between the client and the server networks cannot be
guaranteed. A simple example is shown in Figure 4. The VPN sites guaranteed. A simple example is shown in Figure 4. The VPN sites
comprise a set of domains that are interconnected over a core domain, comprise a set of domains that are interconnected over a core domain,
the provider network. the provider network.
-------------- -------------- -------------- --------------
skipping to change at page 16, line 20 skipping to change at page 16, line 20
points from the domain when signaling an end-to-end TE path that points from the domain when signaling an end-to-end TE path that
will extend across multiple domains. will extend across multiple domains.
Thus, the problem is one of information collection and presentation, Thus, the problem is one of information collection and presentation,
not about signaling. Indeed, the existing signaling mechanisms for not about signaling. Indeed, the existing signaling mechanisms for
TE LSP establishment are likely to prove adequate [RFC4726] with the TE LSP establishment are likely to prove adequate [RFC4726] with the
possibility of minor extensions. Similarly, TE information may possibility of minor extensions. Similarly, TE information may
currently be distributed in a domain by TE extensions to one of the currently be distributed in a domain by TE extensions to one of the
two IGPs as described in OSPF-TE [RFC3630] and ISIS-TE [RFC5305], two IGPs as described in OSPF-TE [RFC3630] and ISIS-TE [RFC5305],
and TE information may be exported from a domain (for example, and TE information may be exported from a domain (for example,
northbound) using link state extensions to BGP [I-D.ietf-idr-ls- northbound) using link state extensions to BGP [RFC7752].
distribution].
An interesting annex to the problem is how the path is made available An interesting annex to the problem is how the path is made available
for use. For example, in the case of a client-server network, the for use. For example, in the case of a client-server network, the
path established in the server network needs to be made available as path established in the server network needs to be made available as
a TE link to provide connectivity in the client network. a TE link to provide connectivity in the client network.
3.1. Policy and Filters 3.1. Policy and Filters
A solution must be amenable to the application of policy and filters. A solution must be amenable to the application of policy and filters.
That is, the operator of a domain that is sharing information with That is, the operator of a domain that is sharing information with
skipping to change at page 34, line 22 skipping to change at page 34, line 22
It is recognized, however, that existing protocols are unlikely to be It is recognized, however, that existing protocols are unlikely to be
immediately suitable to this problem space without some protocol immediately suitable to this problem space without some protocol
extensions. Extending protocols must be done with care and with extensions. Extending protocols must be done with care and with
consideration for the stability of existing deployments. In extreme consideration for the stability of existing deployments. In extreme
cases, a new protocol can be preferable to a messy hack of an cases, a new protocol can be preferable to a messy hack of an
existing protocol. existing protocol.
5.1. BGP-LS 5.1. BGP-LS
BGP-LS is a set of extensions to BGP described in BGP-LS is a set of extensions to BGP described in [RFC7752]. It's
[I-D.ietf-idr-ls-distribution]. It's purpose is to announce topology purpose is to announce topology information from one network to a
information from one network to a "north-bound" consumer. "north-bound" consumer. Application of BGP-LS to date has focused on
Application of BGP-LS to date has focused on a mechanism to build a a mechanism to build a TED for a PCE. However, BGP's mechanisms
TED for a PCE. However, BGP's mechanisms would also serve well to would also serve well to advertise abstract links from a server
advertise abstract links from a server network into the abstraction network into the abstraction layer network, or to advertise potential
layer network, or to advertise potential connectivity from the connectivity from the abstraction layer network to the client
abstraction layer network to the client network. network.
5.2. IGPs 5.2. IGPs
Both OSPF and IS-IS have been extended through a number of RFCs to Both OSPF and IS-IS have been extended through a number of RFCs to
advertise TE information. Additionally, both protocols are capable advertise TE information. Additionally, both protocols are capable
of running in a multi-instance mode either as ships that pass in the of running in a multi-instance mode either as ships that pass in the
night (i.e., completely separate instances using different address) night (i.e., completely separate instances using different address)
or as dual instances on the same address space. This means that or as dual instances on the same address space. This means that
either IGP could probably be used as the routing protocol in the either IGP could probably be used as the routing protocol in the
abstraction layer network. abstraction layer network.
skipping to change at page 48, line 41 skipping to change at page 48, line 41
Multiprotocol Label Switching (GMPLS) External Network Multiprotocol Label Switching (GMPLS) External Network
Network Interface (E-NNI): Virtual Link Enhancements for Network Interface (E-NNI): Virtual Link Enhancements for
the Overlay Model", draft-beeram-ccamp-gmpls-enni, work in the Overlay Model", draft-beeram-ccamp-gmpls-enni, work in
progress. progress.
[I-D.ietf-ccamp-rsvp-te-srlg-collect] [I-D.ietf-ccamp-rsvp-te-srlg-collect]
Zhang, F. (Ed.) and O. Gonzalez de Dios (Ed.), "RSVP-TE Zhang, F. (Ed.) and O. Gonzalez de Dios (Ed.), "RSVP-TE
Extensions for Collecting SRLG Information", draft-ietf- Extensions for Collecting SRLG Information", draft-ietf-
ccamp-rsvp-te-srlg-collect, work in progress. ccamp-rsvp-te-srlg-collect, work in progress.
[I-D.ietf-idr-ls-distribution] [RFC7752] Gredler, H., Medved, J., Previdi, S., Farrel, A., and Ray,
Gredler, H., Medved, J., Previdi, S., Farrel, A., and Ray, S., "North-Bound Distribution of Link-State and Traffic
S., "North-Bound Distribution of Link-State and TE Engineering (TE) Information Using BGP", RFC 7752, March
Information using BGP", draft-ietf-idr-ls-distribution, 2016.
work in progress.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and
McManus, J., "Requirements for Traffic Engineering Over McManus, J., "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999. MPLS", RFC 2702, September 1999.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] L. Berger, "Generalized Multi-Protocol Label Switching [RFC3473] L. Berger, "Generalized Multi-Protocol Label Switching
skipping to change at page 52, line 16 skipping to change at page 52, line 16
Adrian Farrel Adrian Farrel
Juniper Networks Juniper Networks
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
John Drake John Drake
Juniper Networks Juniper Networks
EMail: jdrake@juniper.net EMail: jdrake@juniper.net
Nabil Bitar Nabil Bitar
Verizon Nuage Networks
40 Sylvan Road EMail: nbitar40@gmail.com
Waltham, MA 02145
EMail: nabil.bitar@verizon.com
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
EMail: swallow@cisco.com EMail: swallow@cisco.com
Xian Zhang Xian Zhang
Huawei Technologies Huawei Technologies
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
 End of changes. 16 change blocks. 
51 lines changed or deleted 64 lines changed or added

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