draft-ietf-teas-interconnected-te-info-exchange-00.txt   draft-ietf-teas-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: June 8, 2015 Expires: August 7, 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
December 8, 2014 February 7, 2015
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-00.txt draft-ietf-teas-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-tfo-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.
In order to determine the potential to establish a TE path through a In order to determine the potential to establish a TE path through a
series of connected networks, it is necessary to have available a series of connected networks, it is necessary to have available a
certain amount of TE information about each network. This need not certain amount of TE information about each network. This need not
be the full set of TE information available within each network, but be the full set of TE information available within each network, but
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) 2014 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
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 4, line 21 skipping to change at page 4, line 21
10. Scoping Future Work ......................................... 49 10. Scoping Future Work ......................................... 49
10.1. Not Solving the Internet .................................. 49 10.1. Not Solving the Internet .................................. 49
10.2. Working With "Related" Domains ............................ 49 10.2. Working With "Related" Domains ............................ 49
10.3. Not Finding Optimal Paths in All Situations ............... 49 10.3. Not Finding Optimal Paths in All Situations ............... 49
10.4. Not Breaking Existing Protocols ........................... 49 10.4. Not Breaking Existing Protocols ........................... 49
10.5. Sanity and Scaling ........................................ 49 10.5. Sanity and Scaling ........................................ 49
11. Manageability Considerations ................................ 50 11. Manageability Considerations ................................ 50
12. IANA Considerations ......................................... 50 12. IANA Considerations ......................................... 50
13. Security Considerations ..................................... 50 13. Security Considerations ..................................... 50
14. Acknowledgements ............................................ 50 14. Acknowledgements ............................................ 50
15. References .................................................. 50 15. References .................................................. 51
15.1. Informative References .................................... 50 15.1. Informative References .................................... 51
Authors' Addresses ............................................... 54 Authors' Addresses ............................................... 55
Contributors ..................................................... 55 Contributors ..................................................... 55
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
skipping to change at page 41, line 4 skipping to change at page 40, line 52
5.6. Addressing Considerations 5.6. Addressing Considerations
[Editor Note: Need to work up some text on addressing to cover the case [Editor Note: Need to work up some text on addressing to cover the case
of each domain having a different (potentially overlapping) address of each domain having a different (potentially overlapping) address
space and the need for inter-domain addressing. In fact, this should be space and the need for inter-domain addressing. In fact, this should be
quite simple but needs discussion. quite simple but needs discussion.
Also needed is a discussion of the case where two client networks share Also needed is a discussion of the case where two client networks share
an abstraction network (section 5.3.3.2). How does addressing work here? an abstraction network (section 5.3.3.2). How does addressing work here?
Are there security issues?] Are there security issues?]
<TBD>
6. Building on Existing Protocols 6. Building on Existing Protocols
This section is not intended to prejudge a solutions framework or any This section is not intended to prejudge a solutions framework or any
applicability work. It does, however, very briefly serve to note the applicability work. It does, however, very briefly serve to note the
existence of protocols that could be examined for applicability to existence of protocols that could be examined for applicability to
serve in realizing the model described in this document. 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 as invention of new protocols or additional protocol extensions as
mentioned in Section 3.1. mentioned in Section 3.1.
skipping to change at page 50, line 21 skipping to change at page 50, line 21
<TBD> <TBD>
12. IANA Considerations 12. IANA Considerations
This document makes no requests for IANA action. The RFC Editor may This document makes no requests for IANA action. The RFC Editor may
safely remove this section. safely remove this section.
13. Security Considerations 13. Security Considerations
<TBD> Security of signaling routing protocols is usually administered and
achieved within the boundaries of a domain. Thus, and for example,
a domain with a GMPLS control plane [RFC3945] would apply the
security mechanisms and considerations that are appropriate to GMPLS
[RFC5920]. Furthermore, domain-based security relies strongly on
ensuring that control plane messages are not allowed to enter the
domain from outside. Thus, the proposals in this document for inter-
domain exchange of control plane information naturally raise
additional questions of security.
In this context additional security considerations arising from this
document relate to the exchange of control plane information between
domains. Messages are passed between domains using control plane
protocols operating between peers that have predicted relationships
(for example, UNI-C to UNI-N, or between BGP-LS speakers). Thus,
the security that needs to be given additional attention for
inter-domain TE concentrates on authentication of peers, assertion
that messages have not been tampered with, and to a lesser extent
protecting the content of the messages from inspection since that
might give away sensitive information about the networks. The
protocols described in Section 6 and which are likely to provide
the foundation to solutions to this architecture already include
such protection and further can be run over protected transports
such as IPsec [RFC6701], TLS [RFC5246], and the TCP Authentication
Option (TCP-AO) [RFC5925].
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, Dhruv Dhody, and Thanks to Deborah Brungard, Dieter Beller, Dhruv Dhody, and
skipping to change at page 53, line 31 skipping to change at page 54, line 10
RFC 5152, February 2008. RFC 5152, February 2008.
[RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based [RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based
Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008. Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
M., and D. Brungard, "Requirements for GMPLS-Based Multi- M., and D. Brungard, "Requirements for GMPLS-Based Multi-
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July
2008. 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5251] Fedyk, D., Rekhter, Y., Papadimitriou, D., Rabbat, R., and [RFC5251] Fedyk, D., Rekhter, Y., Papadimitriou, D., Rabbat, R., and
L. Berger, "Layer 1 VPN Basic Mode", RFC 5251, July 2008. L. Berger, "Layer 1 VPN Basic Mode", RFC 5251, July 2008.
[RFC5252] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN Auto- [RFC5252] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN Auto-
Discovery", RFC 5252, July 2008. Discovery", RFC 5252, July 2008.
[RFC5305] Li, T., and Smit, H., "IS-IS Extensions for Traffic [RFC5305] Li, T., and Smit, H., "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008. Engineering", RFC 5305, October 2008.
[RFC5440] Vasseur, JP. and Le Roux, JL., "Path Computation Element [RFC5440] Vasseur, JP. and Le Roux, JL., "Path Computation Element
skipping to change at page 54, line 13 skipping to change at page 54, line 41
5523, April 2009. 5523, April 2009.
[RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource
Reservation Protocol (RSVP) Extensions for Path Key Reservation Protocol (RSVP) Extensions for Path Key
Support", RFC 5553, May 2009. Support", RFC 5553, May 2009.
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
"Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic
Engineering", RFC 5623, September 2009. Engineering", RFC 5623, September 2009.
[RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[RFC6005] Nerger, L., and D. Fedyk, "Generalized MPLS (GMPLS) Support [RFC6005] Nerger, L., and D. Fedyk, "Generalized MPLS (GMPLS) Support
for Metro Ethernet Forum and G.8011 User Network Interface for Metro Ethernet Forum and G.8011 User Network Interface
(UNI)", RFC 6005, October 2010. (UNI)", RFC 6005, October 2010.
[RFC6107] Shiomoto, K., and A. Farrel, "Procedures for Dynamically [RFC6107] Shiomoto, K., and A. Farrel, "Procedures for Dynamically
Signaled Hierarchical Label Switched Paths", RFC 6107, Signaled Hierarchical Label Switched Paths", RFC 6107,
February 2011. February 2011.
[RFC6701] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6701,
February 2011.
[RFC6805] King, D., and A. Farrel, "The Application of the Path [RFC6805] King, D., and A. Farrel, "The Application of the Path
Computation Element Architecture to the Determination of a Computation Element Architecture to the Determination of a
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
skipping to change at page 55, line 4 skipping to change at page 55, line 43
John Drake John Drake
Juniper Networks Juniper Networks
EMail: jdrake@juniper.net EMail: jdrake@juniper.net
Nabil Bitar Nabil Bitar
Verizon Verizon
40 Sylvan Road 40 Sylvan Road
Waltham, MA 02145 Waltham, MA 02145
EMail: nabil.bitar@verizon.com 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
Huawei Technologies
Email: zhang.xian@huawei.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Via A. Negrone 1/A Via A. Negrone 1/A
Genova - Sestri Ponente Genova - Sestri Ponente
Italy Italy
EMail: daniele.ceccarelli@ericsson.com EMail: daniele.ceccarelli@ericsson.com
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Contributors Contributors
Gert Grammel Gert Grammel
Juniper Networks Juniper Networks
Email: ggrammel@juniper.net Email: ggrammel@juniper.net
Vishnu Pavan Beeram Vishnu Pavan Beeram
Juniper Networks Juniper Networks
Email: vbeeram@juniper.net Email: vbeeram@juniper.net
 End of changes. 14 change blocks. 
13 lines changed or deleted 51 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/