draft-ietf-ccamp-interconnected-te-info-exchange-00.txt   draft-ietf-ccamp-interconnected-te-info-exchange-01.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: Standards Track Juniper Networks
Expires: May 10, 2015 Expires: May 20, 2015
N. Bitar N. Bitar
Verizon Networks Verizon Networks
G. Swallow G. Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
X. Zhang X. Zhang
Huawei Huawei
November 10, 2014 November 20, 2014
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-ccamp-interconnected-te-info-exchange-00.txt draft-ietf-ccamp-interconnected-te-info-exchange-01.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. The availability of TE used in the process of selecting a TE path. The availability of TE
information is usually limited to within a network (such as an IGP information is usually limited to within a network (such as an IGP
area) often referred to as a domain. area) often referred to as a domain.
skipping to change at page 3, line 40 skipping to change at page 3, line 40
3.6. Issues of Aggregation ...................................... 19 3.6. Issues of Aggregation ...................................... 19
3.7. Virtual Network Topology ................................... 20 3.7. Virtual Network Topology ................................... 20
4. Existing Work ................................................ 21 4. Existing Work ................................................ 21
4.1. Per-Domain Path Computation ................................ 21 4.1. Per-Domain Path Computation ................................ 21
4.2. Crankback .................................................. 22 4.2. Crankback .................................................. 22
4.3. Path Computation Element ................................... 23 4.3. Path Computation Element ................................... 23
4.4. GMPLS UNI and Overlay Networks ............................. 24 4.4. GMPLS UNI and Overlay Networks ............................. 24
4.5. Layer One VPN .............................................. 25 4.5. Layer One VPN .............................................. 25
4.6. VNT Manager and Link Advertisement ......................... 25 4.6. VNT Manager and Link Advertisement ......................... 25
4.7. What Else is Needed and Why? ............................... 26 4.7. What Else is Needed and Why? ............................... 26
5. Architectural Concepts ....................................... 26 5. Architectural Concepts ....................................... 27
5.1. Basic Components ........................................... 26 5.1. Basic Components ........................................... 27
5.1.1. Peer Interconnection ..................................... 27 5.1.1. Peer Interconnection ..................................... 27
5.1.2. Client-Server Interconnection ............................ 27 5.1.2. Client-Server Interconnection ............................ 27
5.2. TE Reachability ............................................ 28 5.2. TE Reachability ............................................ 28
5.3. Abstraction not Aggregation ................................ 29 5.3. Abstraction not Aggregation ................................ 29
5.3.1. Abstract Links ........................................... 30 5.3.1. Abstract Links ........................................... 30
5.3.2. The Abstraction Layer Network ............................ 30 5.3.2. The Abstraction Layer Network ............................ 30
5.3.3. Abstraction in Client-Server Networks..................... 33 5.3.3. Abstraction in Client-Server Networks..................... 33
5.3.4. Abstraction in Peer Networks ............................. 34 5.3.4. Abstraction in Peer Networks ............................. 34
5.4. Considerations for Dynamic Abstraction ..................... 40 5.4. Considerations for Dynamic Abstraction ..................... 40
5.5. Requirements for Advertising Links and Nodes ............... 40 5.5. Requirements for Advertising Links and Nodes ............... 40
skipping to change at page 24, line 13 skipping to change at page 24, line 13
responsible for navigating a path across the domain mesh and for responsible for navigating a path across the domain mesh and for
coordinating intra-domain computations by the child PCEs coordinating intra-domain computations by the child PCEs
responsible for each domain. This approach makes computing an end- responsible for each domain. This approach makes computing an end-
to-end path across a mesh of domains far more tractable. However, to-end path across a mesh of domains far more tractable. However,
it still leaves unanswered the issue of determining the location of it still leaves unanswered the issue of determining the location of
the destination (i.e., discovering the destination domain) as the destination (i.e., discovering the destination domain) as
described in Section 2.1.1. Furthermore, it raises the question of described in Section 2.1.1. Furthermore, it raises the question of
who operates the parent PCE especially in networks where the who operates the parent PCE especially in networks where the
domains are under different administrative and commercial control. domains are under different administrative and commercial control.
Further issues and considerations of the use of PCE can be found in It should also be noted that [RFC5623] discusses how PCE is used in a
[I-D.farrkingel-pce-questions]. multi-layer network with coordination between PCEs operating at each
network layer. Further issues and considerations of the use of PCE
can be found in [RFC7399].
4.4. GMPLS UNI and Overlay Networks 4.4. GMPLS UNI and Overlay Networks
[RFC4208] defines the GMPLS User-to-Network Interface (UNI) to [RFC4208] defines the GMPLS User-to-Network Interface (UNI) to
present a routing boundary between an overlay network and the core present a routing boundary between an overlay network and the core
network, i.e. the client-server interface. In the client network, network, i.e. the client-server interface. In the client network,
the nodes connected directly to the core network are known as edge the nodes connected directly to the core network are known as edge
nodes, while the nodes in the server network are called core nodes. nodes, while the nodes in the server network are called core nodes.
In the overlay model defined by [RFC4208] the core nodes act as a In the overlay model defined by [RFC4208] the core nodes act as a
skipping to change at page 47, line 42 skipping to change at page 47, line 42
Figure 22 : Ethernet UNI Reference Model Figure 22 : Ethernet UNI Reference Model
An issue that is often raised concerns how a dual-homed client edge An issue that is often raised concerns how a dual-homed client edge
node (such as that shown at the bottom left-hand corner of Figure 22) node (such as that shown at the bottom left-hand corner of Figure 22)
can make determinations about how they connect across the UNI. This can make determinations about how they connect across the UNI. This
can be particularly important when reachability across the server can be particularly important when reachability across the server
network is limited or when two diverse paths are desired (for network is limited or when two diverse paths are desired (for
example, to provide protection). However, in the model described in example, to provide protection). However, in the model described in
this network, the edge node (the UNI-C) is part of the Abstraction this network, the edge node (the UNI-C) is part of the Abstraction
Layer Network and can see sufficient topology information to make Layer Network and can see sufficient topology information to make
these decisions. There is, therefore, no need to enhance the these decisions. If the approach introduced in this document is used
signaling protocols at the GMPLS UNI nor to add routing exchanges at to model the UNI as described in this section, there is no need to
the UNI. enhance the signaling protocols at the GMPLS UNI nor to add routing
exchanges at the UNI.
9. Abstraction in L3VPN Multi-AS Environments 9. Abstraction in 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
skipping to change at page 50, line 28 skipping to change at page 50, line 31
<TBD> <TBD>
14. Acknowledgements 14. Acknowledgements
Thanks to Igor Bryskin for useful discussions in the early stages of Thanks to Igor Bryskin for useful discussions in the early stages of
this work. this work.
Thanks to Gert Grammel for discussions on the extent of aggregation Thanks to Gert Grammel for discussions on the extent of aggregation
in abstract nodes and links. in abstract nodes and links.
Thanks to Deborah Brungard, Dieter Beller, and Vallinayakam Thanks to Deborah Brungard, Dieter Beller, Dhruv Dhody, and
Somasundaram for review and input. Vallinayakam Somasundaram for review and input.
Particular thanks to Vishnu Pavan Beeram for detailed discussions and Particular thanks to Vishnu Pavan Beeram for detailed discussions and
white-board scribbling that made many of the ideas in this document white-board scribbling that made many of the ideas in this document
come to life. come to life.
Text in Section 5.3.3 is freely adapted from the work of Igor Text in Section 5.3.3 is freely adapted from the work of Igor
Bryskin, Wes Doonan, Vishnu Pavan Beeram, John Drake, Gert Grammel, Bryskin, Wes Doonan, Vishnu Pavan Beeram, John Drake, Gert Grammel,
Manuel Paul, Ruediger Kunze, Friedrich Armbruster, Cyril Margaria, Manuel Paul, Ruediger Kunze, Friedrich Armbruster, Cyril Margaria,
Oscar Gonzalez de Dios, and Daniele Ceccarelli in Oscar Gonzalez de Dios, and Daniele Ceccarelli in
[I-D.beeram-ccamp-gmpls-enni] for which the authors of this document [I-D.beeram-ccamp-gmpls-enni] for which the authors of this document
skipping to change at page 51, line 12 skipping to change at page 51, line 12
[G.8080] ITU-T, "Architecture for the automatically switched optical [G.8080] ITU-T, "Architecture for the automatically switched optical
network (ASON)", Recommendation G.8080. network (ASON)", Recommendation G.8080.
[I-D.beeram-ccamp-gmpls-enni] [I-D.beeram-ccamp-gmpls-enni]
Bryskin, I., Beeram, V. P., Drake, J. et al., "Generalized Bryskin, I., Beeram, V. P., Drake, J. et al., "Generalized
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.farrkingel-pce-questions]
Farrel, A., and D. King, "Unanswered Questions in the Path
Computation Element Architecture", draft-farrkingel-pce-
questions, work in progress.
[I-D.ietf-ccamp-general-constraint-encode] [I-D.ietf-ccamp-general-constraint-encode]
Bernstein, G., Lee, Y., Li, D., and Imajuku, W., "General Bernstein, G., Lee, Y., Li, D., and Imajuku, W., "General
Network Element Constraint Encoding for GMPLS Controlled Network Element Constraint Encoding for GMPLS Controlled
Networks", draft-ietf-ccamp-general-constraint-encode, work Networks", draft-ietf-ccamp-general-constraint-encode, work
in progress. in progress.
[I-D.ietf-ccamp-gmpls-general-constraints-ospf-te] [I-D.ietf-ccamp-gmpls-general-constraints-ospf-te]
Zhang, F., Lee, Y,. Han, J, Bernstein, G., and Xu, Y., Zhang, F., Lee, Y,. Han, J, Bernstein, G., and Xu, Y.,
"OSPF-TE Extensions for General Network Element "OSPF-TE Extensions for General Network Element
Constraints", draft-ietf-ccamp-gmpls-general-constraints- Constraints", draft-ietf-ccamp-gmpls-general-constraints-
skipping to change at page 54, line 36 skipping to change at page 54, line 33
Sequence of Domains in MPLS and GMPLS", RFC 6805, November Sequence of Domains in MPLS and GMPLS", RFC 6805, November
2012. 2012.
[RFC6827] Malis, A., Lindem, A., and D. Papadimitriou, "Automatically [RFC6827] Malis, A., Lindem, A., and D. Papadimitriou, "Automatically
Switched Optical Network (ASON) Routing for OSPFv2 Switched Optical Network (ASON) Routing for OSPFv2
Protocols", RFC 6827, January 2013. Protocols", RFC 6827, January 2013.
[RFC6996] J. Mitchell, "Autonomous System (AS) Reservation for [RFC6996] J. Mitchell, "Autonomous System (AS) Reservation for
Private Use", BCP 6, RFC 6996, July 2013. Private Use", BCP 6, RFC 6996, July 2013.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399, October 2014.
Authors' Addresses Authors' Addresses
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
 End of changes. 9 change blocks. 
17 lines changed or deleted 18 lines changed or added

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