idnits 2.17.1 draft-xu-spring-islands-connection-over-ip-05.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 (March 7, 2016) is 2972 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-03 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-06 == Outdated reference: A later version (-09) exists of draft-ietf-ospf-encapsulation-cap-00 == Outdated reference: A later version (-07) exists of draft-xu-isis-encapsulation-cap-06 == Outdated reference: A later version (-06) exists of draft-xu-sfc-using-mpls-spring-04 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. Xu 3 Internet-Draft Huawei 4 Intended status: Informational R. Raszuk 5 Expires: September 8, 2016 Bloomberg LP 6 U. Chunduri 7 Ericsson 8 L. Contreras 9 Telefonica I+D 10 L. Jalil 11 Verizon 12 March 7, 2016 14 Connecting MPLS-SPRING Islands over IP Networks 15 draft-xu-spring-islands-connection-over-ip-05 17 Abstract 19 MPLS-SPRING is an MPLS-based source routing paradigm in which a 20 sender of a packet is allowed to partially or completely specify the 21 route the packet takes through the network by imposing stacked MPLS 22 labels to the packet. To facilitate the incremental deployment of 23 this new technology, this document describes a mechanism which allows 24 the outermost LSP be replaced by an IP-based tunnel. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 8, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Packet Forwarding Procedures . . . . . . . . . . . . . . . . 3 64 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 69 7.2. Informative References . . . . . . . . . . . . . . . . . 4 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 72 1. Introduction 74 MPLS-SPRING [I-D.ietf-spring-segment-routing-mpls] is a MPLS-based 75 source routing paradigm in which a sender of a packet is allowed to 76 partially or completely specify the route the packet takes through 77 the network by imposing stacked MPLS labels to the packet. To 78 facilitate the incremental deployment of this new technology, this 79 document describes a mechanism which allows the outermost LSP to be 80 replaced by an IP-based tunnel (e.g., MPLS-in-IP/GRE tunnel 81 [RFC4023], MPLS-in-UDP tunnel [RFC7510] or MPLS-in-L2TPv3 tunnel 82 [RFC4817] and etc) when the nexthop along the LSP is not MPLS-SPRING- 83 enabled. The tunnel destination address would be the address of the 84 egress of the outmost LSP (e.g., the egress of the active segment). 86 This mechanism is much useful in the MPLS-SPRING-based Service 87 Function Chainning (SFC) case [I-D.xu-sfc-using-mpls-spring] where 88 only a few specific routers (e.g., Service Function Forwarders (SFF) 89 and classifiers) are required to be MPLS-SPRING-capable while the 90 remaining routers are just required to support IP forwarding 91 capability. In addition, this mechanism is also useful in some 92 specific Traffic Engineering scenarios where only a few routers 93 (e.g., the entry and exit nodes of each plane in the dual-plane 94 network ) are specified as segments of explicit paths. In this way, 95 only a few routers are required to support the MPLS-SPRING capability 96 while all the other routers just need to support IP forwarding 97 capability, which would significantly reduce the deployment cost of 98 this new technology. Furthermore, since there is no need to run any 99 other label distribution protocol (e.g., LDP), the network 100 provisioning is greatly simplified, which is one of the major claimed 101 benefits of the MPLS-SPRING technology. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 2. Terminology 111 This memo makes use of the terms defined in [RFC3031], 112 [I-D.ietf-spring-segment-routing-mpls] and 113 [I-D.xu-sfc-using-mpls-spring] . 115 3. Packet Forwarding Procedures 117 Assume an MPLS-SPRING-enabled router X prepares to forward an MPLS 118 packet to the next segment (i.e., the node segment of MPLS-SPRING- 119 enabled router Y) which is identified by the top label of the MPLS 120 packet. If the next-hop router of the best path to Y is a non-MPLS 121 router, X couldn't map the packet's top label into an Next Hop Label 122 Forwarding Entry (NHLFE) , even though the top label itself is a 123 valid incoming label. If the label is not a Penultimate Hop Popping 124 (PHP) label (i.e., the NP-flag 125 [I-D.ietf-isis-segment-routing-extensions] associated with the 126 corresponding prefix SID of that top label is set), X SHOULD swap the 127 top label to the corresponding label significant to Y and then 128 encapsulate the MPLS packet into an IP-based tunnel. The tunnel 129 destination address is the IP address of Y (e.g., the /32 or /128 130 prefix FEC associated with that top label) and the tunnel source 131 address is the IP address of X. If the top label is a PHP label and 132 not at the bottom of the label stack, X SHOULD pop that top label 133 before performing the above encapsulation. The IP encapsulated 134 packet would be forwarded according to the IP forwarding table. Upon 135 receipt of that IP encapsulated packet, Y would decapsulate it and 136 then process the decapsulated MPLS packet accordingly. 138 As for which tunnel encapsulation type should be used by X, it can be 139 manually specified on X or learnt from Y's advertisement of its 140 tunnel encapsulation capability. How to advertise the tunnel 141 encapsulation capability using IS-IS or OSPF are specified in 142 [I-D.xu-isis-encapsulation-cap] and [I-D.ietf-ospf-encapsulation-cap] 143 respectively. 145 4. Acknowledgements 147 Thanks Joel Halpern, Bruno Decraene and Loa Andersson for their 148 insightful comments on this draft. 150 5. IANA Considerations 152 No action is required for IANA. 154 6. Security Considerations 156 TBD. 158 7. References 160 7.1. Normative References 162 [I-D.ietf-spring-segment-routing-mpls] 163 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 164 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 165 and E. Crabbe, "Segment Routing with MPLS data plane", 166 draft-ietf-spring-segment-routing-mpls-03 (work in 167 progress), February 2016. 169 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 170 Requirement Levels", BCP 14, RFC 2119, 171 DOI 10.17487/RFC2119, March 1997, 172 . 174 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 175 Label Switching Architecture", RFC 3031, 176 DOI 10.17487/RFC3031, January 2001, 177 . 179 7.2. Informative References 181 [I-D.ietf-isis-segment-routing-extensions] 182 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 183 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 184 Extensions for Segment Routing", draft-ietf-isis-segment- 185 routing-extensions-06 (work in progress), December 2015. 187 [I-D.ietf-ospf-encapsulation-cap] 188 Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, 189 L., and L. Jalil, "Advertising Tunnelling Capability in 190 OSPF", draft-ietf-ospf-encapsulation-cap-00 (work in 191 progress), October 2015. 193 [I-D.xu-isis-encapsulation-cap] 194 Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, 195 L., and L. Jalil, "Advertising Tunnelling Capability in 196 IS-IS", draft-xu-isis-encapsulation-cap-06 (work in 197 progress), November 2015. 199 [I-D.xu-sfc-using-mpls-spring] 200 Xu, X., Li, Z., Shah, H., and L. Contreras, "Service 201 Function Chaining Using MPLS-SPRING", draft-xu-sfc-using- 202 mpls-spring-04 (work in progress), September 2015. 204 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 205 "Encapsulating MPLS in IP or Generic Routing Encapsulation 206 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 207 . 209 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and 210 J. Young, "Encapsulation of MPLS over Layer 2 Tunneling 211 Protocol Version 3", RFC 4817, DOI 10.17487/RFC4817, March 212 2007, . 214 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 215 "Encapsulating MPLS in UDP", RFC 7510, 216 DOI 10.17487/RFC7510, April 2015, 217 . 219 Authors' Addresses 221 Xiaohu Xu 222 Huawei 224 Email: xuxiaohu@huawei.com 226 Robert Raszuk 227 Bloomberg LP 229 Email: robert@raszuk.net 231 Uma Chunduri 232 Ericsson 234 Email: uma.chunduri@ericsson.com 235 Luis M. Contreras 236 Telefonica I+D 237 Ronda de la Comunicacion, s/n 238 Sur-3 building, 3rd floor 239 Madrid, 28050 240 Spain 242 Email: luismiguel.contrerasmurillo@telefonica.com 243 URI: http://people.tid.es/LuisM.Contreras/ 245 Luay Jalil 246 Verizon 248 Email: luay.jalil@verizon.com