idnits 2.17.1 draft-dong-spring-srv6-inter-layer-programming-01.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 date (October 31, 2020) is 1273 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SL' is mentioned on line 140, but not defined == Unused Reference: 'RFC2629' is defined on line 282, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-24 ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-poi-applicability-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group J. Dong 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track Z. Du 5 Expires: May 4, 2021 China Mobile 6 October 31, 2020 8 SRv6 for Inter-Layer Network Programming 9 draft-dong-spring-srv6-inter-layer-programming-01 11 Abstract 13 This document defines a new SRv6 network function which can be used 14 for SRv6 inter-layer network programming. It is a variant of the 15 End.X function. Instead of pointing to an L3 adjacency, this 16 function points to an underlay interface. Such a interface can stand 17 for a underlay link or path/connection between two routers, which may 18 be invisible in the L3 topology. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 4, 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language and Terminology . . . . . . . . . . . . 3 56 3. END.XU Function . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Use Case for SRv6 Underlay Interface Function . . . . . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 63 8.2. Informative References . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 In many scenarios, operator owns a multi-layered network. In that 69 case, cross-layer design and optimization mechanisms are more 70 efficient in resource utilization and SLA assurance, but normally are 71 also considered more complicated. As an IP/MPLS based technology, 72 Segment Routing (SR) normally does not need to care about the network 73 layers beneath the IP layer. One exception is as described in 74 [RFC8668], IS-IS is extended to advertise the link attributes and 75 Segment Identifiers (SIDs) of Layer 2 (L2) bundle members, so that 76 operator can control traffic flows to traverse a particular 77 individual L2 link which comprises the L2 bundle interface 79 In [I-D.ietf-spring-srv6-network-programming], it is described that 80 for an outgoing interface bundle made of 10 member links, up to 11 81 End.X local SIDs for that bundle need to be allocated. One END.X for 82 the bundle itself and then up to one END.X for each member link. 83 However, there are some differences between the normal END.X function 84 for the bundle and the END.X function for the member link, as they 85 are not at the same network layer. Moreover, besides the L2 bundle 86 use case, there are other types of underlay interfaces or 87 connections, which can be integrated and programmed using SRv6. This 88 document aims to define a unified SRv6 function to support those 89 inter-layer network programming in SRv6. 91 As another example, the underlay of the IP network can be an optical 92 network. In many today's IP and optical transport networks, IP 93 network and optical network are maintained separately, and in most 94 cases, the optical network works as an underlay which is invisible to 95 the IP network. However, the optical path resource and the IP path 96 resource may not be one-to-one mapped so that some resource in 97 optical network can not be fully used. In some cases, there may be 98 some optical paths that is not visible in the L3 IP topology, and 99 thus they can not be used to carry IP traffic. 101 Following the SRv6 network programming concept in 102 [I-D.ietf-spring-srv6-network-programming], we can use a new SRv6 103 function to identify a specific optical path, and put the 104 corresponding SRv6 SID into an integrated SRv6 SID list. The optical 105 path can be either OTN based or DWDM based. Besides the optical 106 paths, it is also possible to use the SRv6 function to identify other 107 underlay paths/connenctions, such as a back-to-back Ethernet 108 connection, or some pre-configured tunnels. 110 The SRv6 function mentioned above can be considered as a variant of 111 the END.X function defined in 112 [I-D.ietf-spring-srv6-network-programming], so that it is suggested 113 to define a new SRv6 function for it. This document defines the 114 operation of this new SRv6 function, and describes some use cases of 115 this SRv6 underlay interface function. 117 2. Requirements Language and Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in 122 [RFC2119] when they appear in ALL CAPS. When these words are not in 123 ALL CAPS (such as "should" or "Should"), they have their usual 124 English meanings, and are not to be interpreted as [RFC2119] key 125 words. 127 3. END.XU Function 129 This section defines the new SRv6 underlay interface function. 131 The "Endpoint with cross-connect to an underlay interface" function 132 (End.XU for short) is a variant of the End.X function defined in 133 [I-D.ietf-spring-srv6-network-programming]. 135 When N receives a packet destined to S and S is a local End.XU SID, N 136 does: 138 1. IF NH=SRH and SL > 0 139 2. decrement SL 140 3. update the IPv6 DA with SRH[SL] 141 4. forward to underlay interface bound to the SID S 142 5. ELSE IF NH!=SRH 143 6. Send an ICMP parameter problem message; drop the packet 144 7. ELSE 145 8. drop the packet 147 Note that the underlay interface or connection in step 4 SHOULD be 148 established before this function and the associated SID is announced 149 into the network. 151 This End.XU function can be announced using IGP or BGP-LS in a 152 similar way to the announcement of END.X function. The detailed 153 protocol extension will be described in a separate document. 155 4. Use Case for SRv6 Underlay Interface Function 157 Assuming that an operator owns both the IP and optical network, and 158 the operator needs to deploy E2E service across IP and optical 159 network, with traditional approaches the planning and service 160 provisioning would be complex and time consuming due of the manual 161 synergy needed between the operator's IP team and optical team. With 162 the popularity of SR and SRv6, one straightforward way is to use a 163 SID list that integrates the path in both the IP layer and the 164 optical layer. 166 As the optical layer is not packet based, normally source routing 167 mechanism can not be directly used in the optical network. However, 168 we can expose the abstracted optical path and its associated 169 attribute and resource information into the network control system of 170 the IP network, by using the SRv6 End.XU function defined in this 171 document, so that E2E inter-layer paths can be programmed to meet 172 some specific traffic's SLA, such as low latency. 174 ----- ----- ----- 175 | P1 |--------| P2 |--------| P3 | 176 ----- ----- ----- 177 / |. |. |. \ 178 ----- / | . | . | . \ ----- 179 | P7 | | . | . | . | P8 | 180 ----- \ | . | . | ./ ----- 181 \ | . | . | / . 182 ----- . ----- . ----- . 183 | P4 |-------| P5 |--------| P6 | . 184 ----- . ----- . ----- . 185 . . . . . . 186 . ===== . ===== . ===== 187 . | O1 |----------| O2 |--------| O3 | 188 . ===== . ===== . ===== 189 . | . | . | 190 . | . | . | 191 . | . | . | 192 . | . | . | 193 .| .| .| 194 ===== ===== ===== 195 | O4 |----------| O5 |--------| O6 | 196 ===== ===== ===== 197 Figure 1. IP and Optical Layered Network Topology 199 In Figure 1, P1 to P8 are IP nodes, and O1 to O6 are optical nodes. 200 Assume we need to deploy a low latency path between P7 and P8. 201 According to traditional segment routing in IP layer, perhaps we can 202 choose the path along {P7, P1, P2, P3, P8}. But if an optical path 203 from O1 to O3 exists, and the End.XU function defined in this 204 document is used to announce this path into the IP domain with 205 specific attributes, the headend node or controller in IP domain can 206 choose the path along {P7, P1, END.XU, P3, P8} which provides lower 207 latency than the normal paths. 209 The creation of the optical path from O1 to O3 may be requested 210 either by the headend IP node P7 or the IP network controller (not 211 shown in the Figure). The creation should be done by the optical 212 network controller (not shown in the Figure), so that P7 or IP 213 network controller needs to inform the path requirements to the 214 optical network controller. The details of the process are out of 215 scope of this document, and may refer to 216 [I-D.ietf-teas-actn-poi-applicability] [I-D.lee-teas-actn-vpn-poi]. 218 We can also use the topology in Figure 1 to show another use case. 219 Assume there are two optical paths between P1 and P2. One is {O1, 220 O2} , and the other is {O1, O4, O5, O2}. We can assign two End.XU 221 functions for these two underlay paths separately. One is P1::C2 for 222 the path {O1, O2}, and the other is P1::C45 for the path {O1, O4, O5, 223 O2}. The headend P7 or the IP network controller will be informed 224 about the two SRv6 functions and the associated path attributes, so 225 that the headend or the controller can program different end-to-end 226 inter-layer paths using integrated SID lists for services with 227 different SLA requirement. 229 Assume the path {O1, O2} is owned by the operator with a higher 230 reliability, and the path {O1, O4, O5, O2} is not totally owned by 231 the operator, i.e., they are partly rented. In this use case, for 232 the traffic with high reliability requirement, the integrated SID 233 list implemented in P7 would be . The ellipsis 234 means some other possible SRv6 functions can be added along the path. 235 For traffic with normal reliability requirement, the integrated SID 236 list programmed in P7 can be . Before the 237 announcement of the two functions, the node P1 needs to map the 238 P1::C12 function to the optical path {O1, O2}, and map P1::C45 to the 239 optical path {O1, O4, O5, O2}. 241 5. Security Considerations 243 TBD 245 6. IANA Considerations 247 This document defines a new SRv6 function called END.XU. 249 IANA is requested to allocate four new code points from the "SRv6 250 Endpoint Behaviors" sub-registry in the "Segment-routing with IPv6 251 dataplane (SRv6) Parameters" registry: 253 +-------+--------+---------------------------+-----------+ 254 | Value | Hex | Endpoint function | Reference | 255 +-------+--------+---------------------------+-----------+ 256 | TBA | TBA | End.XU (no PSP, no USP) | [This.ID] | 257 | TBA | TBA | End.XU with PSP | [This.ID] | 258 | TBA | TBA | End.XU with USP | [This.ID] | 259 | TBA | TBA | End.XU with PSP&USP | [This.ID] | 260 +-------+--------+---------------------------+-----------+ 262 7. Acknowledgements 264 The authors would like to thank Xiaodong Chang for his review and 265 comments. 267 8. References 269 8.1. Normative References 271 [I-D.ietf-spring-srv6-network-programming] 272 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 273 Matsushima, S., and Z. Li, "SRv6 Network Programming", 274 draft-ietf-spring-srv6-network-programming-24 (work in 275 progress), October 2020. 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, 279 DOI 10.17487/RFC2119, March 1997, 280 . 282 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 283 DOI 10.17487/RFC2629, June 1999, 284 . 286 8.2. Informative References 288 [I-D.ietf-teas-actn-poi-applicability] 289 Peruzzini, F., Bouquier, J., Busi, I., King, D., and D. 290 Ceccarelli, "Applicability of Abstraction and Control of 291 Traffic Engineered Networks (ACTN) to Packet Optical 292 Integration (POI)", draft-ietf-teas-actn-poi- 293 applicability-00 (work in progress), October 2020. 295 [I-D.lee-teas-actn-vpn-poi] 296 Lee, Y., Wu, Q., Busi, I., and J. Tantsura, "Abstract", 297 draft-lee-teas-actn-vpn-poi-00 (work in progress), October 298 2018. 300 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 301 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 302 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 303 December 2019, . 305 Authors' Addresses 307 Jie Dong 308 Huawei Technologies 309 Huawei Campus, No.156 Beiqing Road 310 Beijing, 100095 311 China 313 Email: jie.dong@huawei.com 314 Zongpeng Du 315 China Mobile 316 No.32 XuanWuMen West Street 317 Beijing, 100053 318 China 320 Email: duzongpeng@foxmail.com