idnits 2.17.1 draft-lt-6man-sr-listid-encapsulation-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 19, 2015) is 3112 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: 'RFC2460' is mentioned on line 170, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) -- Looks like a reference, but probably isn't: '0' on line 185 == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 224, but no explicit reference was found in the text == Unused Reference: 'RFC4915' is defined on line 241, but no explicit reference was found in the text == Unused Reference: 'RFC4970' is defined on line 246, but no explicit reference was found in the text == Unused Reference: 'RFC5250' is defined on line 251, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-06 ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING WG Ting. Liao 3 Internet-Draft Ting. Ao 4 Intended status: Standards Track ZTE Corporation 5 Expires: April 21, 2016 October 19, 2015 7 SPRING IPv6 ListID Encapsulation 8 draft-lt-6man-sr-listid-encapsulation-00.txt 10 Abstract 12 Segment Routing allows a node to steer a packet through an ordered 13 list of instructions, called segments. The ingress node prepends a 14 SR header to a packet containing a set of "segments". A segment can 15 represent any instruction topological or service-based. Segment 16 Routing can be applied to the IPv6 architecture, with a new type of 17 routing extension header. A segment is encoded as an IPv6 address. 18 An ordered list of segments is encoded as an ordered list of IPv6 19 addresses in the routing extension header. The segment to process is 20 indicated by a pointer in the routing extension header. Upon 21 completion of a segment, the pointer is incremented. This document 22 describes how to decrease the length of the IPv6 list with ListID 23 carried. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 21, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions and Abbreviations . . . . . . . . . . . . . . . . 2 61 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1.1. SLID Encapsulating . . . . . . . . . . . . . . . . . 4 64 3.1.1.1. A new type of Routing Extension Header . . . . . 4 65 3.1.1.2. R-flags defined in draft-previdi-6man-segment- 66 routing-header to identify . . . . . . . . . . . 4 67 3.1.2. SLID Forwarding . . . . . . . . . . . . . . . . . . . 4 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 71 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 Segment Routing can be applied to the IPv6 data plane with the 77 addition of a new type of Routing Extension Header as described in 78 [I-D.previdi-6man-segment-routing-header]. A segment is encoded as 79 an IPv6 address. An ordered list of segments is encoded as an 80 ordered list of IPv6 addresses in the routing extension header. 81 There may be many specified nodes or links included in the path based 82 on policy, each ipv6 address is 128 bits, this will greatly increase 83 the length of header. This document describes a method by mapping a 84 segment list to a ListID and carrying the ListID in the header. It 85 will decrease the length of the segment routing header. 87 2. Conventions and Abbreviations 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119] . 93 The following notations and abbreviations are used throughout this 94 draft. 96 SR:Segment Routing SID:Segment Identifier SLID: Segment List 97 Identifier, a segment list is identified by a Segment list ID (SLID). 99 3. Solution 101 In this document, we define the Segment List Identifier (SLID). The 102 segment list is identified by a Segment list ID (SLID). Segment list 103 ID (SLID) is allocated by the controller. The segment list and the 104 SLID can be advertised to the related nodes. When the node receives 105 the mapping message, it generates a mapping table about the SLID to 106 the Segment List. The segment routing header could be a new type of 107 Routing Extension Header, or be identified by the R-flags as defined 108 in [I-D.previdi-6man-segment-routing-header]. 110 3.1. Example 112 As shown in the figure 1. 114 __ +----------------------+ 115 / _ | Controller | __ 116 / / +----------------------+_ \ 117 / / | | | | | \ \ \ 118 / / | | | | | \ \ \ 119 +---+ / +---+ | | +---+ | +---+ \ \+---+ 120 -------- |R1 |---/---|R3 |--|---|--|R5 |---|-|R7 |---\-- |R9 | 121 +---+ / +---+ | | +---+ | +---+ \ +---+ 122 | / | / \ | \ | \ | 123 | / | / \ | \ | \ | 124 +---+ +---+ +---+ +---+ +---+ 125 |R2 |-------|R4 |--------|R6 |-----|R8 |-------|R10|----------- 126 +---+ +---+ +---+ +---+ +---+ 128 Figure 1 Scenario 1 130 In this example, we assumes that: o All nodes are SR capable. o Each 131 SR node has a global IPv6 address configured by operator to identify 132 the node. o The operator (likely via the SDN Controller) as 133 provisioned the Node-SIDs 2001::1001, 2001::1002, 2001::1003, 134 2001::1004, 2001::1005, 2001::1006, 2001::1007, 2001::1008, 135 2001::1009,and 2001::1010 respectively at nodes R1, R2, R3, R4, R5, 136 R6, R7, R8, R9 and R10. o The controller computes a list for: {R1, 137 R2, R4, R3, R5, R6, R8, R7, R9, and R10}, and allocates an unused ID 138 2001::1100 to identify the segment list. o The controller advertises 139 the mapping Segment list ID (SLID) 2001::1100 for segment list {R1, 140 R2, R4, R3, R5, R6, R8, R7, R9, and R10} to all the nodes in the 141 list. o Each node receives the mapping message, generates the 142 mapping table of the SLID to the List. 144 3.1.1. SLID Encapsulating 146 3.1.1.1. A new type of Routing Extension Header 148 A new type of Routing Extension Headers is shown in the figure 2. 149 The ingress node could encapsulate frames with SLID carried. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | RESV | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | | 159 | Segment List ID (128 bits ipv6 address) | 160 | | 161 | | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Figure 2 A new type of Routing Extension Header 166 o Next Header: 8-bit selector. Identifies the type of header 167 immediately following the SRH. o Hdr Ext Len: 8-bit unsigned 168 integer, is the length of the SRH header in 8-octet units, not 169 including the first 8 octets. o Routing Type: TBD, to be assigned by 170 IANA. o Segments Left: It is optional, as defined in [RFC2460], it 171 contains the index, in the Segment List, of the next segment to 172 inspect. Segments Left is decremented at each segment in the list. 173 o RESV: Reserved and for future use. o Segment List ID: 128 bit IPv6 174 addresses identifying the Segment List. Used to look up the next 175 hop, and then the next hop exchanges the destination of the IPv6 176 encapsulation. 178 3.1.1.2. R-flags defined in draft-previdi-6man-segment-routing-header 179 to identify 181 As the R-flags have reserved and defined in 182 [I-D.previdi-6man-segment-routing-header], such as one of R-flags 183 set, it means the SLID instead of the Segment List[n] carrying in the 184 encapsulation, there is no need to carry the segment 185 list[0]...segment list[n] in this solution. 187 3.1.2. SLID Forwarding 189 As each node receives the mapping message, each node knows which one 190 is the next node of itself. Such as R1 receives the message of 191 Segment list ID (SLID) 2001::1100 mapping to the segment list {R1, 192 R2, R4, R3, R5, R6, R8, R7, R9, and R10}, R1 will know R2 is my next 193 segment in the LIST, and when some packets need to forward on the 194 path of this list, it encapsulates the packet with the SLID 195 2001::1100 carried, the destination of the packet is the addresses of 196 R2 which is the next segment of R1. 198 When the packet transit to R2, with the next header is routing 199 extension header, and the routing extension header is the type of 200 SLID carried, or the SRH carried with the R-flags to identify the 201 SLID carried. R2 learns the SLID 2001::1100 mapping to the segment 202 list {R1, R2, R4, R3, R5, R6, R8, R7, R9, and R10}, and the next 203 segment of R2 in this list is R4. R2 changes the destination of this 204 packet with the address of R4, and then the packet transits to R4. 206 R4 knows R3, changes the destination,and the packet transits to R3. 207 ... and then R10 receives the packet, it knows itself is the last 208 segment in the list, and decapsulates the IPv6 SR header. 210 4. Security Considerations 212 TBD. 214 5. Acknowledgements 216 In progress. 218 6. IANA Considerations 220 TBD. 222 7. Normative References 224 [I-D.ietf-spring-segment-routing] 225 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 226 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 227 ietf-spring-segment-routing-06 (work in progress), October 228 2015. 230 [I-D.previdi-6man-segment-routing-header] 231 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 232 J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment 233 Routing Header (SRH)", draft-previdi-6man-segment-routing- 234 header-08 (work in progress), October 2015. 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, 238 DOI 10.17487/RFC2119, March 1997, 239 . 241 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 242 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 243 RFC 4915, DOI 10.17487/RFC4915, June 2007, 244 . 246 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 247 S. Shaffer, "Extensions to OSPF for Advertising Optional 248 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 249 2007, . 251 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 252 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 253 July 2008, . 255 Authors' Addresses 257 Ting Liao 258 ZTE Corporation 259 No.50 Software Avenue 260 Nanjing, Jiangsu 210012 261 China 263 Phone: +86 25 88016576 264 Email: liao.ting@zte.com.cn 266 Ting Ao 267 ZTE Corporation 268 No.889 Bibo Rd 269 Shanghai 201203 270 China 272 Phone: +86 21 68897642 273 Email: ao.ting@zte.com.cn