idnits 2.17.1 draft-chen-opsawg-nettunnel-model-considerations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 19, 2015) is 3102 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.zheng-intarea-gre-yang' is mentioned on line 370, but not defined == Missing Reference: 'I-D.liu-rtgwg-ipipv4-tunnel-yang' is mentioned on line 360, but not defined == Missing Reference: 'I-D.tran-ipecme-yang-ipsec' is mentioned on line 365, but not defined == Missing Reference: 'I-D.ietf-teas-yang-te' is mentioned on line 354, but not defined Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Chen 3 Internet-Draft S. Zhuang 4 Intended status: Informational Huawei 5 Expires: April 21, 2016 October 19, 2015 7 Considerations on Layered Network Tunnel Service Model 8 draft-chen-opsawg-nettunnel-model-considerations-00 10 Abstract 12 Tunnel is one typical service provided by carrier IP network. 13 Network Tunnel service model can provide the northbound interface of 14 network-level tunnel service of the controller to try to simplify the 15 Tunnel provision without involving too much details of Tunnel 16 implementation on the device. This document gives exploratory 17 description about the requirement of network-level Tunnel service and 18 how to define the data model which will provide the guidance for the 19 future definition of the concrete data model. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 21, 2016. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Consideration of Tunnel Service Model . . . . . . . . . . . . 3 64 4. Network Tunnel Service Model . . . . . . . . . . . . . . . . 4 65 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.2. Design of Data Model . . . . . . . . . . . . . . . . . . 5 67 5. Network MPLS TE Tunnel Service Model . . . . . . . . . . . . 5 68 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 69 5.2. Design of Data Model . . . . . . . . . . . . . . . . . . 6 70 6. Network IP Tunnel Service Model . . . . . . . . . . . . . . . 7 71 7. Pre-configuration and Operational Data . . . . . . . . . . . 7 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 10.2. References . . . . . . . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 Tunnel is one typical service provided by carrier IP network. The 82 network tunnel service model is defined to satisfy the common 83 requirement of most tunnel services. It's convenient for the 84 operators to set up the tunnel which serves for the network 85 applications without caring about the details of different types of 86 tunnels which are eventually setup in the network device. The 87 generic properties of the different tunnels and the properties which 88 the network-level tunnels need such as source address of the tunnel 89 are defined and such service model is referred to as network tunnel 90 service model. 92 Some tunnels can support traffic engineering such as bandwidth 93 assurance, setting up the tunnel according to the explicit path which 94 is specified by the user. The generic traffic engineering properties 95 are defined for the network-level applications and such service model 96 is referred to as network MPLS TE tunnel service model. This service 97 model is based on the network tunnel service model. 99 This document introduces the description of northbound interface of 100 network-level tunnel service and give the pseudo data model tree to 101 explain the idea. 103 2. Scope 105 The network tunnel service model is defined to satisfy the common 106 requirement of most tunnel services. The network tunnel service 107 defined here is only based on Layer 3 topology and called L3 tunnel. 108 The tunnel will be used for carrying VPN service and the tunnel used 109 for IPv6 transition is not within the scope. Currently the 110 northbound interface of network tunnel service only includes the 111 point-to-point tunnel and in the future the model would include 112 point-to-multipoint and multipoint-to-multipoint tunnel to support 113 the multicast service. 115 The controller will process the network tunnel service model and 116 finally notify the network device to create the tunnel. The 117 configured network tunnels on the controller includes mainly IP 118 tunnel and MPLS TE tunnel. The LDP and SR-BE path which are able to 119 be created on network device can carry VPN service too. But such 120 tunnels are automatically set up according to the route and are not 121 necessary to set up by controller. 123 3. Consideration of Tunnel Service Model 125 The network tunnel service model is defined to satisfy the common 126 requirement of most tunnel services. It's convenient for the 127 operators to set up the tunnel which serves for the network 128 applications without caring about the details of different types of 129 tunnels which are eventually setup in the network device. Now there 130 are several device-level data models about tunnel are proposed in 131 IETF. I-D.zheng-intarea-gre-yang [I-D.zheng-intarea-gre-yang] 132 defines the data model of GRE tunnel. I-D.liu-rtgwg-ipipv4-tunnel- 133 yang [I-D.liu-rtgwg-ipipv4-tunnel-yang] defines the data model of IP 134 in IP tunnel. I-D.tran-ipecme-yang-ipsec 135 [I-D.tran-ipecme-yang-ipsec] defines the data model of IPsec tunnel. 136 I-D.ietf-teas-yang-te [I-D.ietf-teas-yang-te] defines the data model 137 of MPLS RSVP-TE tunnel. Different types of tunnels have specific 138 tunnel attributes and there are some generic attributes all of these 139 tunnels possess. The operators are normally interested in these 140 common attributes. The generic network tunnel data model is made up 141 of these common properties and the properties which the network-level 142 tunnels need like source address of the tunnel. 144 In case of MPLS TE tunnel service the services of traffic engineering 145 include bandwidth assurance, setting up the tunnel according to the 146 explicit path which is specified by the user etc. The generic 147 traffic engineering properties are configured for the network-level 148 applications and the tunnel services which support traffic 149 engineering can be provided, There is the requirement of global 150 reoptimization of the network-level tunnels which means the network 151 usability can be increased by computing the new path for all the 152 tunnels and rebuilding the tunnels. Therefore the data model should 153 define the actions used by operator to trigger the progress of global 154 reoptimization. such data model is referred to as network MPLS TE 155 tunnel data model. This data model is based on the network tunnel 156 data model. 158 In case of IP tunnel service the common attributes has been defined 159 in network tunnel data model. If there are other generic specific 160 attributes for IP tunnel and how to define the generic network IP 161 tunnel data model should be discussed. 163 The relationship of the network tunnel data model, network MPLS TE 164 tunnel data model, network IP tunnel data model is shown in the 165 following figure: 167 +---------------------+ 168 | network tunnel | o: augment 169 +---------------------+ 170 o o 171 / \ 172 / \ 173 +------------------------+ +-------------------+ 174 | network MPLS TE tunnel | | network IP tunnel | 175 +------------------------+ +-------------------+ 176 Figure 1: Relationship of Network Tunnel Service Model, 177 Network MPLS TE Tunnel Model, Network IP Tunnel Model 179 4. Network Tunnel Service Model 181 4.1. Overview 183 When the operators use the tunnel service they normally only indicate 184 the addresses of both network devices to set up the tunnel. They 185 don't care about the specific tunnel technology. The controller has 186 internal or preconfigured policy to choose the proper specific tunnel 187 technology. The users may consider the tunnel is unidirectional or 188 bidirectional or the tunnel is IP tunnel or MPLS TE tunnel. If they 189 don't configure the controller creates unidirectional tunnel and the 190 MPLS TE tunnel by default. The default policy is implementation- 191 specific. 193 The network tunnel data model is provided to users to customize their 194 requirement for tunnel services on the controller. 196 4.2. Design of Data Model 198 The configuration of network tunnel service model should include: the 199 tunnel name, the source and destination addresses, the type of tunnel 200 which indicates the tunnel is IP or MPLS TE, the direction indicator 201 of the tunnel which defines the tunnel is unidirectional or 202 bidirectional. The user can control the state of the tunnel by 203 manually to set the tunnel down . Different tunnel with the different 204 tunnel name can have the same pair of source and destination 205 addresses. 207 Following is a simplified tree representation of the data model for 208 generic network tunnel service configuration. 210 +--rw network-tunnel 211 +--rw p2p-network-tunnels 212 +--rw tunnel* [tunnel-name] 213 +--rw tunnel-name 214 +--rw tunnel-type 215 +--rw direction 216 +--rw admin-status? 217 +--rw source 218 +--rw destination 220 5. Network MPLS TE Tunnel Service Model 222 5.1. Overview 224 The operators often configure the following traffic engineering 225 attributes: bandwidth, the explicit-path, priority, color, protection 226 and different TE technology can support the common attributes. The 227 generic traffic engineering properties are configured for the 228 network-level applications by the network MPLS TE tunnel data model 229 on the controller. The network-level tunnel services configured on 230 the controller are supported by RSVP-TE tunnel, Segment-Routing TE 231 tunnel, static TE tunnel created on network device. 233 The requirement of global reoptimization of the network-level tunnels 234 is the network usability can be increased by computing the new path 235 for all the tunnels and rebuilding the tunnels. Sometimes the 236 operators require the reoptimization to specific tunnel. Therefore 237 the data model should define the actions used by operator to trigger 238 the progress of reoptimization. 240 The network MPLS TE tunnel data model is based on the network tunnel 241 data model. 243 5.2. Design of Data Model 245 The configuration of network tunnel service model should include: 246 bandwidth of the tunnel, the explicit path which is made up of one or 247 more hops, priority where the tunnel the higher priority can be setup 248 and hold than lower priority, color which is defined by affinity, if 249 the end-to-end hotstandby protection is needed. 251 The rpc defines the global reoptimization and the reoptimization of 252 the specific tunnel. 254 Following is a simplified graphical representation of the data model 255 for generic MPLS TE tunnel service configuration. 257 module: network-te-tunnel 258 augment /network-tunnel/p2p-network-tunnels/tunnel: 259 +--rw te-tunnel-constraints 260 +--rw bandwidth? 261 +--rw priority? 262 +--rw affinities? 263 +--rw path-constraint? 264 | +--rw hop list? 265 | +--rw hop-limit? 266 +--rw hotstandby? 267 +--rw affinities? 268 +--rw path-constraint? 269 +--rw hop list? 270 +--rw hop-limit? 272 Following is a simplified graphical representation of the data model 273 for generic MPLS TE tunnel service rpc. 275 module: network-te-tunnel 276 augment /network-tunnel/p2p-network-tunnels/tunnel: 277 +---x reoptimization 278 | +--ro input 279 | +--ro if-reoptimization 280 +---x reoptimization-by-tunnel 281 | +--ro input 282 | +--ro tunnel-name 284 6. Network IP Tunnel Service Model 286 The common attributes for IP tunnel service have been defined in 287 network tunnel data model. After the controller processes and 288 converts the network tunnel data model the controller can notify the 289 network device to create one specific type of IP tunnel. It's not 290 necessary for the operator to care about the details of different 291 types of IP tunnels which are eventually setup in the network device. 292 But if the operator would like to specify the more attributes of IP 293 tunnel by the northbound interface the network IP tunnel data model 294 is needed to be defined through augment of Network Tunnel Service 295 Model. 297 The different IP tunnel technology can be applied in different 298 application scenario such as MPLS in UDP used for load balance, GRE 299 used for load balance or security, IPsec used for security. Even for 300 the same usage of load balance, MPLS in UDP and GRE will adopt 301 different implementation parameters. Thus the IP tunnel attributes 302 to satisfy different uses are hard to be unified and maybe all IP 303 tunnel specific attributes have to be defined in the service model 304 which will deviate the rules of definition of service models. There 305 should be further discussion. 307 7. Pre-configuration and Operational Data 309 This document focuses on the design of the data model of the service 310 configuration which the business users care about. Actually system 311 administrators have to configure the pre-configuration data to help 312 the controller convert the network service configuration to the 313 device-level configuration. The typical of pre-configuration of 314 network Tunnel service models may provide the policy of the models 315 conversion and the resources used for conversion. For example the 316 network MPLS TE tunnel model can be implemented by RSVP-TE tunnel, 317 SR-TE tunnel, static CR-LSP. The pre-configuration can define the 318 policy to select the implementation mode for specific Network TE 319 Tunnel service model. On the other hand, when implement the network 320 TE Tunnel model with RSVP-TE tunnel, the tunnel ID of RSVP-TE tunnel 321 needs to be allocated dynamically by the controller. The pre- 322 configuration can define the resource pool of tunnel ID for 323 allocation. 325 It's challenging to define the operational data of network service 326 data model because the normal users and the system administrators 327 have different perspective. The business users maybe care only about 328 the limited maintenance information but the system administrators 329 need to know more details. For network MPLS TE tunnel model the 330 state and the path information of the tunnel maybe sufficient to the 331 business users but system administrators maybe need to know the type, 332 tunnel identifier and specific attributes of the tunnel. There 333 should be further discussion. 335 8. IANA Considerations 337 This document makes no request of IANA. 339 9. Security Considerations 341 This document does not introduce new security threat. 343 10. References 345 10.1. Normative References 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, 349 DOI 10.17487/RFC2119, March 1997, 350 . 352 10.2. References 354 [I-D.ietf-teas-yang-te] 355 Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., Chen, 356 X., Jones, R., and B. Wen, "A YANG Data Model for Traffic 357 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 358 te-01 (work in progress), October 2015. 360 [I-D.liu-rtgwg-ipipv4-tunnel-yang] 361 Liu, Y. and A. Foldes, "Yang Data Model for IPIPv4 362 Tunnel", draft-liu-rtgwg-ipipv4-tunnel-yang-01 (work in 363 progress), July 2015. 365 [I-D.tran-ipecme-yang-ipsec] 366 Tran, K., "Yang Data Model for Internet Protocol Security 367 (IPSec)", draft-tran-ipecme-yang-ipsec-00 (work in 368 progress), May 2015. 370 [I-D.zheng-intarea-gre-yang] 371 Zheng, L., Pignataro, C., Penno, R., and Z. Wang, "Yang 372 Data Model for Generic Routing Encapsulation (GRE)", 373 draft-zheng-intarea-gre-yang-00 (work in progress), July 374 2015. 376 Authors' Addresses 378 Xia Chen 379 Huawei 380 Huawei Bld., No.156 Beiqing Rd. 381 Beijing 100095 382 China 384 Email: jescia.chenxia@huawei.com 386 Shunwan Zhuang 387 Huawei 388 Huawei Bld., No.156 Beiqing Rd. 389 Beijing 100095 390 China 392 Email: zhuangshunwan@huawei.com