idnits 2.17.1 draft-xu-ospf-service-sid-adv-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 date (April 25, 2014) is 3644 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 176, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-xu-spring-sfc-use-case-00 ** 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-00 -- 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 Huawei 4 Intended status: Standards Track April 25, 2014 5 Expires: October 27, 2014 7 Signaling Services and Service SIDs Using OSPF 8 draft-xu-ospf-service-sid-adv-00 10 Abstract 12 The Segment Routing mechanism can be leveraged to realize the service 13 path layer functionality of the Service Function Chaining (i.e, 14 steering traffic through the service function path). This document 15 describes how to advertise services and the corresponding service 16 segment IDs using OSPF. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 27, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Advertising Services and Service SIDs . . . . . . . . . . . . 2 56 3.1. Service TLVs . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Service SID Sub-TLVs . . . . . . . . . . . . . . . . . . 3 58 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 7.2. Informative References . . . . . . . . . . . . . . . . . 4 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1. Introduction 68 [I-D.xu-spring-sfc-use-case] describes a particular use case for 69 SPRING where the Segment Routing (SR) mechanism is leveraged to 70 realize the service path layer functionality of the SFC (i.e, 71 steering traffic through the service function path). To allow the 72 service classifier to encode the segment list represeting a 73 particular service path, the classifier needs to know on which 74 service node(s) a given service is located and what segment ID (SID) 75 is used to indicate that service on a given service node. This 76 document describes how to advertise services and the corresponding 77 service SIDs using OSPF including both OSPFv2 [RFC2328] and OSPFv3 78 [RFC2740]. 80 1.1. Requirements Language 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 2. Terminology 88 This memo makes use of the terms defined in [RFC4970]. 90 3. Advertising Services and Service SIDs 92 Service nodes within the network need to advertise each service they 93 are offering by using a TLV within the body of the OSPF Router 94 Information (RI) Opaque LSA [RFC4970]. These TLVs are called as 95 Service TLVs. These Service TLVs are applicable to both OSPFv2 and 96 OSPFv3. The scope of the advertisement depends on the application 97 but it is recommended that it SHOULD be domain-wide. Furthermore, 98 they may need to allocate at least one corresponding SID for each 99 service and meanwhile advertise it by using a sub-TLV of the 100 corresponding Service TLV for that service, called Service SID sub- 101 TLV. In the MPLS-SR case, service nodes within the network would 102 allocate a locally significant MPLS label to each service they are 103 offering. In the IPv6-SR case, service nodes within the network 104 would allocate a locally unique link-local IPv6 address to each 105 service they are offering. For a given service, the service node 106 offering that service could advertise the service ID in MPLS label 107 format or the one in IPv6 address format, or both. 109 3.1. Service TLVs 111 0 1 2 3 112 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 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Type=TBD | Length | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 ~ Sub-TLVs ~ 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 Type: each service is allocated with a unique type code. 121 Length: variable 123 Value: contains zero or more sub-TLVs. Besides the Service SID 124 sub-TLVs, other sub-TLVs (to be defined in future) which are used 125 to describe some characters of a service could also be contained 126 in this field. 128 3.2. Service SID Sub-TLVs 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Type=TBD | Length | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 ~ Service SID ~ 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 Type: TBD1 for the service SID in MPLS label format and TBD2 for 139 the service SID in IPv6 address format. 141 Length: variable (3 or 16). 143 Value: if the Length is set to 3, the 20 rightmost bits represent 144 a MPLS label. If the length is set to 16, the value represents an 145 IPv6 address. 147 4. Acknowledgements 149 TBD. 151 5. IANA Considerations 153 TBD. 155 6. Security Considerations 157 This document does not introduce any new security risk. 159 7. References 161 7.1. Normative References 163 [I-D.xu-spring-sfc-use-case] 164 Xu, X., "Service Function Chaining Use Case", draft-xu- 165 spring-sfc-use-case-00 (work in progress), April 2014. 167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 168 Requirement Levels", BCP 14, RFC 2119, March 1997. 170 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 171 Shaffer, "Extensions to OSPF for Advertising Optional 172 Router Capabilities", RFC 4970, July 2007. 174 7.2. Informative References 176 [I-D.filsfils-spring-segment-routing] 177 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 178 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 179 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 180 "Segment Routing Architecture", draft-filsfils-spring- 181 segment-routing-00 (work in progress), April 2014. 183 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 185 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 186 2740, December 1999. 188 Author's Address 190 Xiaohu Xu 191 Huawei 193 Email: xuxiaohu@huawei.com