idnits 2.17.1 draft-xu-ospf-service-function-adv-02.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 (June 29, 2014) is 3589 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.filsfils-spring-segment-routing' is defined on line 193, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-xu-spring-sfc-use-case-01 ** Downref: Normative reference to an Informational draft: draft-xu-spring-sfc-use-case (ref. 'I-D.xu-spring-sfc-use-case') ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) == Outdated reference: A later version (-04) exists of draft-filsfils-spring-segment-routing-03 -- Obsolete informational reference (is this intentional?): RFC 2740 (Obsoleted by RFC 5340) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu 3 Internet-Draft N. Wu 4 Intended status: Standards Track Huawei 5 Expires: December 31, 2014 H. Shah 6 Ciena 7 L. Contreras 8 Telefonica I+D 9 June 29, 2014 11 Advertising Service Functions Using OSPF 12 draft-xu-ospf-service-function-adv-02 14 Abstract 16 The Segment Routing mechanism can be leveraged to realize the service 17 path layer functionality of the Service Function Chaining (i.e, 18 steering traffic through the service function path). This document 19 describes how to advertise service functions and their corresponding 20 attributes (e.g., segment ID) using OSPF. Here the OSPF means both 21 OSPFv2 and OSPFv3. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 31, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 3. Advertising Service Functions and Corresponding SIDs . . . . 3 61 3.1. Service Function TLV . . . . . . . . . . . . . . . . . . 3 62 3.2. Service Function SID Sub-TLV . . . . . . . . . . . . . . 4 63 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 68 7.2. Informative References . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 [I-D.xu-spring-sfc-use-case] describes a particular use case for 74 SPRING where the Segment Routing (SR) mechanism is leveraged to 75 realize the service path layer functionality of the Service Function 76 Chaining (SFC), i.e, steering traffic through the service function 77 path. To allow a service classifier to encode the segment list 78 representing a particular service function path, the classifier needs 79 to know on which service node(s) a given service function is located 80 and what segment ID (SID) is used to indicate that service function 81 on a given service node. This document describes how to advertise 82 service functions and their corresponding attributes (e.g., SID) 83 using OSPF. Here the OSPF means both OSPFv2 [RFC2328] and OSPFv3 84 [RFC2740]. 86 1.1. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 2. Terminology 94 This memo makes use of the terms defined in [RFC4970] and 95 [I-D.xu-spring-sfc-use-case]. 97 3. Advertising Service Functions and Corresponding SIDs 99 Service nodes within the network need to advertise each service 100 function they are offering by using a TLV within the body of the OSPF 101 Router Information (RI) Opaque LSA [RFC4970]. This new TLV is called 102 as Service Function TLV. The Service Function TLV is applicable to 103 both OSPFv2 and OSPFv3. The Service Function TLV could appear 104 multiple times wihin a given Router Information (RI) Opaque LSA when 105 more than one service function needs to be advertised by a given 106 service node. The scope of the advertisement depends on the 107 application but it is recommended that it SHOULD be domain-wide. 108 Furthermore, service nodes need to allocate a corresponding SID to 109 each service function and meanwhile advertise it by using a sub-TLV 110 of the above Service Function TLV. In the MPLS-SR case, service 111 nodes within the network would allocate a locally significant MPLS 112 label to each service function they are offering. In the IPv6-SR 113 case, service nodes within the network would allocate a locally 114 unique link-local IPv6 address to each service function they are 115 offering. For a given service function, the service node offering 116 that service function could advertise the corresponding SID in the 117 format of an MPLS label, an IPv6 address, or both. 119 3.1. Service Function TLV 121 0 1 2 3 122 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Type=TBD | Length | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Service Function Identifier | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 ~ Sub-TLVs ~ 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Type: TBD. 133 Length: variable. 135 Service Function Identifier: A unique identifier that represents a 136 service function within an SFC-enabled domain. 138 Sub-TLVs: contains zero or more sub-TLVs corresponding to the 139 particular attributes of a given service function. The Service 140 Function SID sub-TLV as defined in Section 3.2 is one such sub-TLV 141 which is used to indicate the corrresponding service function SID. 142 Other sub-TLVs are to be defined in the future. 144 3.2. Service Function SID Sub-TLV 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Type=TBD | Length | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 ~ Service Function SID ~ 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Type: TBD 156 Length: variable (3 or 16). 158 Value: if the Length is set to 3, the rightmost 20 bits represent 159 an MPLS label. If the length is set to 16, the value represents 160 an IPv6 address. 162 4. Acknowledgements 164 TBD. 166 5. IANA Considerations 168 This memo includes a request to IANA for allocating type codes for 169 the Service Function sub-TLV and the Service Function SID sub-TLV. 171 6. Security Considerations 173 This document does not introduce any new security risk. 175 7. References 177 7.1. Normative References 179 [I-D.xu-spring-sfc-use-case] 180 Xu, X., Li, Z., and H. Shah, "Service Function Chaining 181 Use Case for SPRING", draft-xu-spring-sfc-use-case-01 182 (work in progress), June 2014. 184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 185 Requirement Levels", BCP 14, RFC 2119, March 1997. 187 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 188 Shaffer, "Extensions to OSPF for Advertising Optional 189 Router Capabilities", RFC 4970, July 2007. 191 7.2. Informative References 193 [I-D.filsfils-spring-segment-routing] 194 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 195 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 196 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 197 "Segment Routing Architecture", draft-filsfils-spring- 198 segment-routing-03 (work in progress), June 2014. 200 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 202 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 203 2740, December 1999. 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 222 Luis M. Contreras 223 Telefonica I+D 224 Ronda de la Comunicacion, s/n 225 Sur-3 building, 3rd floor 226 Madrid, 28050 227 Spain 229 Email: luismiguel.contrerasmurillo@telefonica.com 230 URI: http://people.tid.es/LuisM.Contreras/