draft-ietf-teas-te-topo-and-tunnel-modeling-02.txt   draft-ietf-teas-te-topo-and-tunnel-modeling-03.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
Volta Networks Volta Networks
Expires: January 2, 2019 July 2, 2018 Expires: April 22, 2019 October 22, 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-02 draft-ietf-teas-te-topo-and-tunnel-modeling-03
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 January 2, 2019. This Internet-Draft will expire on April 22, 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 47 skipping to change at page 2, line 47
1.3.3. Star-n-Spokes Abstract TE Topology..................27 1.3.3. Star-n-Spokes Abstract TE Topology..................27
1.3.4. Arbitrary Abstract TE Topology......................28 1.3.4. Arbitrary Abstract TE Topology......................28
1.3.5. Customized Abstract TE Topologies...................29 1.3.5. Customized Abstract TE Topologies...................29
1.3.6. Hierarchical Abstract TE Topologies.................30 1.3.6. Hierarchical Abstract TE Topologies.................30
1.4. Merging TE Topologies Provided By Multiple Providers.....31 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..........................................34 The Same Provider..........................................34
1.5. Configuring Abstract TE Topologies.......................36 1.5. Configuring Abstract TE Topologies.......................36
1.6. TE Tunnel Model..........................................37 1.6. TE Tunnel Model..........................................37
1.7. TE Tunnel/Transport Service Modeling Constructs..........39 1.7. TE Tunnel/Transport Service Modeling Constructs..........39
1.8. Transport Service Mapping................................53 1.7.1. Bidirectional Tunnels...............................53
1.9. Multi-Domain Transport Service Coordination..............54 1.8. Transport Service Mapping................................55
2. Use Cases.....................................................59 1.9. Multi-Domain Transport Service Coordination..............56
2. Use Cases.....................................................61
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................................61
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................................69
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...........73
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.....80
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.).....................83
2.6. Use Case 6. Virtual Network Service......................82 2.6. Use Case 6. Virtual Network Service......................84
3. Security Considerations.......................................85 3. Security Considerations.......................................87
4. IANA Considerations...........................................85 4. IANA Considerations...........................................87
5. References....................................................86 5. References....................................................88
5.1. Normative References.....................................86 5.1. Normative References.....................................88
5.2. Informative References...................................86 5.2. Informative References...................................88
6. Acknowledgments...............................................86 6. Acknowledgments...............................................88
Appendix A. Data Examples........................................87 Appendix A. Data Examples........................................89
A.1. Use Case 1...............................................87 A.1. Use Case 1...............................................89
A.1.1. Domain 1............................................87 A.1.1. Domain 1............................................89
A.1.2. Domain 2............................................94 A.1.2. Domain 2............................................96
A.1.3. Domain 3...........................................100 A.1.3. Domain 3...........................................102
Authors' Addresses..............................................106 Authors' Addresses..............................................108
1. Modeling Considerations 1. Modeling Considerations
1.1. TE Topology Model 1.1. TE Topology Model
The TE Topology Model is written in YANG modeling language. It is The TE Topology Model is written in YANG modeling language. It is
defined and developed by the IETF TEAS WG and is documented as "YANG defined and developed by the IETF TEAS WG and is documented as "YANG
Data Model for TE Topologies" [I-D.ietf-teas-yang-te-topo]. The model Data Model for TE Topologies" [I-D.ietf-teas-yang-te-topo]. The model
describes a TE network provider's Traffic Engineering data store as describes a TE network provider's Traffic Engineering data store as
it is seen by a client. It allows for the provider to convey to each it is seen by a client. It allows for the provider to convey to each
skipping to change at page 53, line 16 skipping to change at page 53, line 16
| | | | | | +--ro name string | | | | | | +--ro name string
/* Computed path sub-objects */ /* Computed path sub-objects */
| | | | | +--ro path-computed-route-objects | | | | | +--ro path-computed-route-objects
.............................................................. ..............................................................
_____________________________________________________________________ _____________________________________________________________________
o Connection actual path - an active connection's path as o Connection actual path - an active connection's path as
provisioned in the layer network's data plane in the form of a TE provisioned in the layer network's data plane in the form of a TE
path over a TE topology describing the layer network/domain path over a TE topology describing the layer network/domain
1.7.1. Bidirectional Tunnels
The TE Tunnel model supports the setup of unidirectional connections
as well as multiple types of bidirectional connections.
The bidirectional flag is used to indicate whether the TE Tunnel is
unidirectional or bidirectional. In case of bidirectional TE Tunnels,
the p2p-reverse-primary-path presense container is used to indicate
whether the bidirectional TE Tunnel is native or not. This presense
container cannot be instantiated for unidirectional TE Tunnels.
Unidirectional TE Tunnel: the bidirectional flag is set to "False".
The unidirectional path constraints are configured in the p2p-
primary-path container (the p2p-reverse-primary-path presense
container is not created).
The server computes one unidirectional path and report it and its
properties within the p2p-primary-path container.
The server setup unidirectional LSPs and reports them under the p2p-
primary-path container.
Native bidirectional TE Tunnel: the bidirectional flag is set to
"True" and the p2p-reverse-primary-path container is not created.
The path constraints, applicable to both directions, are configured
in the p2p-primary-path container.
The server computes one bidirectional path and report it and its
properties within the p2p-primary-path container.
The server setup bidirectional LSPs and reports them under the p2p-
primary-path container.
Note that asymmetric bandwdith configuration is not supported with
native bidirectional tunnels.
Bidirectional (non-courouted) TE Tunnel: the bidirectional flag is
set to "True" and the p2p-reverse-primary-path container is created.
The path constraints, applicable to the forward direction, are
configured in the p2p-primary-path container, while the path
constraints applicable to the reverse direction are configured in the
p2p-reverse-primary-path container. It is therefore possible to
configure different set of path constraints, including different
bandwdith, in the two directions. If there are no path constraints
applicable to the backward direction, the p2p-reverse-primary-path
container can be empty (but it shall be present).
The server computes two indepedent paths in the forward and reverse
direction: the computed path in the forward direction and its
properties are reported within the p2p-primary-path container, while
the computed path in the reverse direction and its properties
reported within the p2p-reverse-primary-path container.
The server setup associated unidirectional LSPs in both directions:
unidirectional LSPs setup in the forward direction are reported
within the p2p-primary-path container, while unidirectional LSPs
setup in the backward direction are reported within the p2p-reverse-
primary-path container.
Bidirectional courouted TE Tunnel with asymmetric constraints: the
bidirectional flag is set to "True" and the p2p-reverse-primary-path
container is created.
The path constraints, applicable to the forward direction, are
configured in the p2p-primary-path container. The p2p-reverse-
primary-path container is configured with use-path-computation flag
set to False and an empty route-object-exclude-always container (to
indicate that the directions should be corouted). It is possible to
configure different bandwdiths in the two directions but no different
path constraints.
Note that in case of a bidirectional (non-courouted) TE Tunnel it is
also possible to configure the p2p-reverse-primary-path container
with the use-path-computation flag set to False, when the reverse
path is configured by the client and not computed by the server: in
this case route-object-exclude-always container is not empty but
specifies the complete explicit-path within the.
The server computes one bidirectional path and report it and its
properties within the p2p-primary-path container. No path properties
are reported within the p2p-reverse-primary-path container.
The server setup associated unidirectional LSPs in both directions:
unidirectional LSPs setup in the forward direction are reported
within the p2p-primary-path container, while unidirectional LSPs
setup in the backward direction are reported within the p2p-reverse-
primary-path container.
The label hops used in bidirectional routers (either for path
constraints or for path routes or for LSP routes) should report the
labels used in the two directions (forward and backward):
o in case the same label is used in both direction, there will be
only one label hop with an empty direction leaf;
o in case different labels are used in the two directions, there
will be two label hops, one specifying the label in the forward
direction and another for the label in the reverse direction.
Associated unidirectional TE Tunnels: two unidirectional TE Tunnels
(with the bidirectional flag is set to "False") are configured in the
forward and reverse direction and associated for bidirectionality
using the association container.
1.8. Transport Service Mapping 1.8. Transport Service Mapping
Figure 21. Transport Service Mapping Figure 21. Transport Service Mapping
Let's assume that a provider has exposed to a client its network Let's assume that a provider has exposed to a client its network
domain in the form of an abstract TE topology, as shown on the left domain in the form of an abstract TE topology, as shown on the left
side of Figure 21. From then on, the provider should be prepared to side of Figure 21. From then on, the provider should be prepared to
receive from the client, a request to set up or manipulate a receive from the client, a request to set up or manipulate a
transport service with TE path(s) computed for the service transport service with TE path(s) computed for the service
connection(s) based on and expressed in terms of the provided connection(s) based on and expressed in terms of the provided
skipping to change at page 106, line 22 skipping to change at page 108, line 22
} }
} }
] ]
} }
] ]
} }
] ]
} }
} }
Contributors
Italo Busi
Huawei
Email: italo.busi@huawei.com
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Authors' Addresses Authors' Addresses
Igor Bryskin Igor Bryskin
Huawei Technologies Huawei Technologies
Email: Igor.Bryskin@huawei.com Email: Igor.Bryskin@huawei.com
Vishnu Pavan Beeram Vishnu Pavan Beeram
Juniper Networks Juniper Networks
Email: vbeeram@juniper.net Email: vbeeram@juniper.net
 End of changes. 11 change blocks. 
24 lines changed or deleted 142 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/