draft-ietf-teas-te-topo-and-tunnel-modeling-01.txt   draft-ietf-teas-te-topo-and-tunnel-modeling-02.txt 
TEAS Working Group Igor Bryskin TEAS Working Group Igor Bryskin
Internet Draft Huawei Technologies Internet Draft Huawei Technologies
Intended status: Informational Vishnu Pavan Beeram Intended status: Informational Vishnu Pavan Beeram
Juniper Networks Juniper Networks
Tarek Saad Tarek Saad
Cisco Systems Inc Cisco Systems Inc
Xufeng Liu Xufeng Liu
Jabil Volta Networks
Expires: September 5, 2018 March 5, 2018 Expires: January 2, 2019 July 2, 2018
TE Topology and Tunnel Modeling for Transport Networks TE Topology and Tunnel Modeling for Transport Networks
draft-ietf-teas-te-topo-and-tunnel-modeling-01 draft-ietf-teas-te-topo-and-tunnel-modeling-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 5, 2018. This Internet-Draft will expire on January 2, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 35 skipping to change at page 2, line 35
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents Table of Contents
1. Modeling Considerations........................................3 1. Modeling Considerations........................................3
1.1. TE Topology Model.........................................3 1.1. TE Topology Model.........................................3
1.2. TE Topology Modeling Constructs...........................5 1.2. TE Topology Modeling Constructs...........................5
1.3. Abstract TE Topology Calculation, Configuration and 1.3. Abstract TE Topology Calculation, Configuration and
Maintenance...................................................22 Maintenance...................................................22
1.3.1. Single-Node Abstract TE Topology....................24 1.3.1. Single-Node Abstract TE Topology....................23
1.3.2. Full Mesh Link Abstract TE Topology.................26 1.3.2. Full Mesh Link Abstract TE Topology.................25
1.3.3. Star-n-Spokes Abstract TE Topology..................28 1.3.3. Star-n-Spokes Abstract TE Topology..................27
1.3.4. Arbitrary Abstract TE Topology......................29 1.3.4. Arbitrary Abstract TE Topology......................28
1.3.5. Customized Abstract TE Topologies...................30 1.3.5. Customized Abstract TE Topologies...................29
1.3.6. Hierarchical Abstract TE Topologies.................31 1.3.6. Hierarchical Abstract TE Topologies.................30
1.4. Merging TE Topologies Provided By Multiple Providers.....32 1.4. Merging TE Topologies Provided By Multiple Providers.....31
1.4.1. Dealing With Multiple Abstract TE Topologies Provided By 1.4.1. Dealing With Multiple Abstract TE Topologies Provided By
The Same Provider..........................................35 The Same Provider..........................................34
1.5. Configuring Abstract TE Topologies.......................37 1.5. Configuring Abstract TE Topologies.......................36
1.6. TE Tunnel Model..........................................38 1.6. TE Tunnel Model..........................................37
1.7. TE Tunnel/Transport Service Modeling Constructs..........40 1.7. TE Tunnel/Transport Service Modeling Constructs..........39
1.8. Transport Service Mapping................................54 1.8. Transport Service Mapping................................53
1.9. Multi-Domain Transport Service Coordination..............55 1.9. Multi-Domain Transport Service Coordination..............54
2. Use Cases.....................................................59 2. Use Cases.....................................................59
2.1. Use Case 1. Transport service control on a single layer 2.1. Use Case 1. Transport service control on a single layer
multi-domain transport network................................59 multi-domain transport network................................59
2.2. Use Case 2. End-to-end TE tunnel control on a single layer 2.2. Use Case 2. End-to-end TE tunnel control on a single layer
multi-domain transport network................................67 multi-domain transport network................................67
2.3. Use Case 3. Transport service control on a ODUk/Och multi- 2.3. Use Case 3. Transport service control on a ODUk/Och multi-
domain transport network with Ethernet access links...........71 domain transport network with Ethernet access links...........71
2.4. Use Case 4. Transport service control on a ODUk/Och multi- 2.4. Use Case 4. Transport service control on a ODUk/Och multi-
domain transport network with multi-function access links.....78 domain transport network with multi-function access links.....78
2.5. Use Case 5. Real time updates of IP/MPLS layer TE link 2.5. Use Case 5. Real time updates of IP/MPLS layer TE link
attributes that depend on supporting transport connectivity (e.g. attributes that depend on supporting transport connectivity (e.g.
transport SRLGs, propagation delay, etc.).....................81 transport SRLGs, propagation delay, etc.).....................81
2.6. Use Case 6. Virtual Network Service......................82 2.6. Use Case 6. Virtual Network Service......................82
3. Security Considerations.......................................85 3. Security Considerations.......................................85
4. IANA Considerations...........................................86 4. IANA Considerations...........................................85
5. References....................................................86 5. References....................................................86
5.1. Normative References.....................................86 5.1. Normative References.....................................86
5.2. Informative References...................................86 5.2. Informative References...................................86
6. Acknowledgments...............................................86 6. Acknowledgments...............................................86
Appendix A. Data Examples........................................87 Appendix A. Data Examples........................................87
A.1. Use Case 1...............................................87 A.1. Use Case 1...............................................87
A.1.1. Domain 1............................................87 A.1.1. Domain 1............................................87
A.1.2. Domain 2............................................94 A.1.2. Domain 2............................................94
A.1.3. Domain 3...........................................100 A.1.3. Domain 3...........................................100
Authors' Addresses..............................................106 Authors' Addresses..............................................106
skipping to change at page 58, line 21 skipping to change at page 58, line 5
Figure 24. Transport Service Placement Based on Abstract TE Topology Figure 24. Transport Service Placement Based on Abstract TE Topology
While processing the received from HC configuration request to set up While processing the received from HC configuration request to set up
the transport service, each DC is expected to carry out the transport the transport service, each DC is expected to carry out the transport
service mapping procedures (as described in 1.8) resulting in the set service mapping procedures (as described in 1.8) resulting in the set
up of all the necessary underlay TE tunnels, as well as one or more up of all the necessary underlay TE tunnels, as well as one or more
connections supporting the transport service. As a result, the connections supporting the transport service. As a result, the
requested transport service will be provisioned as shown in Figure requested transport service will be provisioned as shown in Figure
25. 25.
o In the example above the TE tunnel segments that each DC has to
set up are the head TE tunnel segment (for domain 1) and the tail
TE tunnel segment (for domain 2). For head TE tunnel segment HC
can specify in the configuration request only the source TTP
(located in node s3 in the example), but not the tunnel's
destination TTP, because it is outside of the domain controlled by
the DC.
Therefore, the outbound hand-off point (in the form of outbound
inter-domain TE link ID/label pair) of each connection segment
supporting a TE tunnel non-tail segment (such as head or transit
tunnel segment) is expected to be found at the end of the route-
object-include-exclude list of the explicit-route-objects
configured for that connection segment.
o Likewise, the inbound hand-off point (in the form of inbound
inter-domain TE link ID/label pair) of each connection segment
supporting a TE tunnel non-head segment (such as tail or transit
tunnel segment) is expected to be found at the beginning of the
route-object-include-exclude list of the explicit-route-objects
configured for that connection segments.
o For example, in the figure above the HC can specify the outbound
hand-off point of the primary path supporting the head TE tunnel
segment. The configuration is to be the in the form of the pair of
the TE link ID, identifying the inter domain link terminating on
node s7, and of the TE label used on that link.
o In case (not present in this example) we need to setup a Transit
Tunnel Segment since the endpoints of the E2E Tunnel are both
outside the domain controlled by that DC, the HC would not specify
any source or destination TTP (i.e., it would leave the source,
destination, src-tp-id and dst-tp-id attributes empty)and it would
use the the route-object-include-exclude list of the explicit-
route-objects to specify the inbound and outbound hand-off points
of each connection segment supporting the Transit Tunnel Segment.
The multi-domain transport service tear down coordination entails The multi-domain transport service tear down coordination entails
issuing to each of the involved DCs a configuration request to delete issuing to each of the involved DCs a configuration request to delete
the transport service in the controlled by the DC domain. DCs are the transport service in the controlled by the DC domain. DCs are
expected in this case to release all network resources allocated for expected in this case to release all network resources allocated for
the transport service. the transport service.
The multi-domain transport service modify coordination implies The multi-domain transport service modify coordination implies
issuing to each of the involved DCs a configuration request to issuing to each of the involved DCs a configuration request to
replace the transport service connections according to the newly replace the transport service connections according to the newly
provided paths and/or modify the connection parameters according to provided paths and/or modify the connection parameters according to
skipping to change at page 106, line 37 skipping to change at page 106, line 37
Vishnu Pavan Beeram Vishnu Pavan Beeram
Juniper Networks Juniper Networks
Email: vbeeram@juniper.net Email: vbeeram@juniper.net
Tarek Saad Tarek Saad
Cisco Systems Inc Cisco Systems Inc
Email: tsaad@cisco.com Email: tsaad@cisco.com
Xufeng Liu Xufeng Liu
Jabil Volta Networks
Email: Xufeng_Liu@jabil.com Email: xufeng.liu.ietf@gmail.com
 End of changes. 9 change blocks. 
18 lines changed or deleted 55 lines changed or added

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