idnits 2.17.1 draft-xu-isis-service-function-adv-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 (May 10, 2017) is 2541 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) == Unused Reference: 'I-D.ietf-sfc-architecture' is defined on line 187, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) == Outdated reference: A later version (-03) exists of draft-xu-mpls-service-chaining-00 == Outdated reference: A later version (-04) exists of draft-xu-mpls-unified-source-routing-instruction-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ISIS Working Group X. Xu 3 Internet-Draft N. Wu 4 Intended status: Standards Track Huawei 5 Expires: November 11, 2017 H. Shah 6 Ciena 7 L. Contreras 8 Telefonica I+D 9 May 10, 2017 11 Advertising Service Functions Using IS-IS 12 draft-xu-isis-service-function-adv-05 14 Abstract 16 The MPLS source routing mechanism developed by Source Packet Routing 17 in Networking (SPRING) WG can be leveraged to realize a unified 18 source routing instruction which works across both IPv4 and IPv6 19 underlays in addition to the MPLS underlay. The unified source 20 routing instruction can be used to realize a transport-independent 21 service function chaining by encoding the service function path 22 information or service function chain information as an MPLS label 23 stack. This document describes how to advertise service functions 24 and their corresponding attributes (e.g., service function label) 25 using IS-IS. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 11, 2017. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Solution Description . . . . . . . . . . . . . . . . . . . . 3 70 3.1. Service Function Sub-TLV . . . . . . . . . . . . . . . . 3 71 3.2. SF Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 4 72 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 77 7.2. Informative References . . . . . . . . . . . . . . . . . 5 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 80 1. Introduction 82 [I-D.xu-mpls-service-chaining] describes how to leverage the unified 83 source routing instruction 84 [I-D.xu-mpls-unified-source-routing-instruction] to realize a 85 transport-independent service function chaining by encoding the 86 Service Function Path (SFP) or Service Function Chain (SFC) 87 information as an MPLS label stack. To allow a service classifier to 88 attach the MPLS label stack which represents a particular SFP or SFC 89 to the selected traffic, the service classifier needs to know on 90 which Service Function Forwarder (SFF) a given Service Function (SF) 91 is located and what service function label is used to indicate that 92 SF. This document describes how to advertise SFs and their 93 corresponding attributes (e.g., service function label) using IS-IS. 95 2. Terminology 97 This memo makes use of the terms defined in 98 [I-D.xu-mpls-service-chaining] and [RFC4971]. 100 3. Solution Description 102 SFFs within the SFC domain need to advertise each SF they are 103 offering by using a new sub-TLV of the IS-IS Router CAPABILITY TLV 104 [RFC4971]. This new sub-TLV is called as Service Function sub-TLV. 105 The Service Function sub-TLV could appear multiple times wihin a 106 given IS-IS Router CAPABILITY TLV when more than one SF needs to be 107 advertised. The scope of the advertisement depends on the 108 application but it is recommended that it SHOULD be domain-wide. To 109 support the approach of encoding SFP information in the form of an 110 MPLS label stack as described in [I-D.xu-mpls-service-chaining], SFFs 111 SHOULD allocate a locally significant MPLS label to each SF they are 112 offering. Therefore, SFFs need to advertise the corresponding 113 service function label to each SF they are offering by using a sub- 114 TLV of the above Service Function sub-TLV, called SF Label sub-TLV. 116 3.1. Service Function Sub-TLV 118 0 1 2 3 119 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Type=TBD1 | Length | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Service Function Identifier | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 ~ Sub-TLVs ~ 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 Type: TBD1. 130 Length: variable. 132 Service Function Identifier: A unique identifier that represents 133 an SF within an SFC-enabled domain. 135 Sub-TLVs: contains zero or more sub-TLVs corresponding to the 136 particular attributes of a given SF. The SF Label sub-TLV as 137 defined in Section 3.2 is one such sub-TLV. Other sub-TLVs are to 138 be defined in the future. 140 3.2. SF Label Sub-TLV 142 0 1 2 3 143 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Type=TBD2 | Length | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Resv | SF Label | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 Type: TBD2. 152 Length: 3. 154 Value: The rightmost 20 bits represent an MPLS label which is the 155 SF Label of the corresponding SF. 157 4. Acknowledgements 159 TBD. 161 5. IANA Considerations 163 This document includes a request to IANA for allocating type codes 164 for the Service Function sub-TLV and the SF Label sub-TLV. 166 6. Security Considerations 168 This document does not introduce any new security risk. 170 7. References 172 7.1. Normative References 174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 175 Requirement Levels", BCP 14, RFC 2119, 176 DOI 10.17487/RFC2119, March 1997, 177 . 179 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 180 "Intermediate System to Intermediate System (IS-IS) 181 Extensions for Advertising Router Information", RFC 4971, 182 DOI 10.17487/RFC4971, July 2007, 183 . 185 7.2. Informative References 187 [I-D.ietf-sfc-architecture] 188 Halpern, J. and C. Pignataro, "Service Function Chaining 189 (SFC) Architecture", draft-ietf-sfc-architecture-11 (work 190 in progress), July 2015. 192 [I-D.xu-mpls-service-chaining] 193 Xu, X., Bryant, S., Assarpour, H., Shah, H., Contreras, 194 L., and d. daniel.bernier@bell.ca, "Service Chaining using 195 MPLS Source Routing", draft-xu-mpls-service-chaining-00 196 (work in progress), October 2016. 198 [I-D.xu-mpls-unified-source-routing-instruction] 199 Xu, X., Bryant, S., Raszuk, R., Chunduri, U., Contreras, 200 L., Jalil, L., and H. Assarpour, "Unified Source Routing 201 Instruction using MPLS Label Stack", draft-xu-mpls- 202 unified-source-routing-instruction-00 (work in progress), 203 March 2017. 205 Authors' Addresses 207 Xiaohu Xu 208 Huawei 210 Email: xuxiaohu@huawei.com 212 Nan Wu 213 Huawei 215 Email: eric.wu@huawei.com 217 Himanshu Shah 218 Ciena 220 Email: hshah@ciena.com 221 Luis M. Contreras 222 Telefonica I+D 223 Ronda de la Comunicacion, s/n 224 Sur-3 building, 3rd floor 225 Madrid, 28050 226 Spain 228 Email: luismiguel.contrerasmurillo@telefonica.com 229 URI: http://people.tid.es/LuisM.Contreras/