idnits 2.17.1 draft-filsfils-spring-sr-recursing-info-03.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 : ---------------------------------------------------------------------------- == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2016) is 2738 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) == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-09 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING C. Filsfils 3 Internet-Draft S. Previdi 4 Intended status: Standards Track P. Psenak 5 Expires: April 20, 2017 L. Ginsberg 6 Cisco Systems, Inc. 7 October 17, 2016 9 Segment Routing Recursive Information 10 draft-filsfils-spring-sr-recursing-info-03 12 Abstract 14 Segment Routing (SR) allows for a flexible definition of end-to-end 15 paths within IGP topologies by encoding paths as sequences of 16 topological sub-paths, called "segments". These segments are 17 advertised by the link-state routing protocols (IS-IS and OSPF). 19 There are use cases where it is desirable to utilize a SID associated 20 with a given node in order to transport traffic destined to different 21 local services supported by such node. This document defines the 22 mechanism to do so and illustrates it. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 20, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Segment Routing Recursing Information (SRRI) . . . . . . . . 3 67 4. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. Reference Diagram . . . . . . . . . . . . . . . . . . . . 5 69 4.2. Description . . . . . . . . . . . . . . . . . . . . . . . 5 70 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 74 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 Segment Routing (SR) as defined in [I-D.ietf-spring-segment-routing] 80 utilizes forwarding instructions called "segments" to direct packets 81 through the network. When an MPLS dataplane is in use Segment 82 Identifiers (SIDs) are assigned to prefixes and are associated with a 83 specific algorithm. SIDs may be Local or Global in scope. When a 84 SID has global scope the SID is mapped via the Segment Routing Global 85 Block (SRGB) to a node specific label which acts as the forwarding 86 instruction. 88 There are use cases where it is desirable to utilize a SID associated 89 with a node N to transport traffic destined to different local 90 services supported by N. This document defines the mechanism to do 91 so and illustrates it. 93 2. Use Cases 95 In some deployments, multiple loopback addresses are configured in a 96 single router. Each of these loopback addresses can serve as the 97 address of the node. Specific addresses within this set of node 98 addresses may be used as the endpoint for a particular service or 99 capability. If the number of labeled entries installed in the 100 forwarding plane is a concern, the use of a single label for the set 101 of node addresses (or for some subset of the set of node addresses) 102 can be used in order to reduce the number of forwarding entries 103 required to reach any of the node addresses. This, in turn, would 104 require sharing of a SID among multiple prefixes. 106 Some deployments attach different services to an edge router in a 107 network via unique interfaces. Rather than assigning a unique SID 108 for the address associated with each service the desired behavior is 109 to use a Node-SID to reach the edge router and then utilize a service 110 specific Local SID to direct the packet to the correct service. 112 The first use case is a sub-case of the second one where the local 113 SID is not present (e.g. encoded as implicit-null). Hence in the 114 remainder of this document, we will focus on the more generic use 115 case, i.e., utilizing a single Node-SID in combination with an 116 optional Local SID to transport traffic up to the node and then have 117 the node apply the correct service based on the local SID (if 118 present). 120 3. Segment Routing Recursing Information (SRRI) 122 This document introduces and defines the concept of a "Segment 123 Routing Recursing Information (SRRI) that needs to be carried into 124 IGPs (ISIS and OSPF), e.g., as a TLV (or SubTLV) attached to the 125 prefix advertisement. 127 The description in this document is protocol agnostic and can be 128 applied to both IGPs (IS-IS and OSPF). The protocol specific format 129 of this advertisement will be defined in protocol specific 130 specifications. 132 Advertisement of a prefix P with SRRI (R, Alg, SID-L) indicates that 133 a remote node M MUST use a segment list {SID(R), SID-L) to transport 134 traffic to P; where SID(R) is the prefix SID of R for the specified 135 algorithm. The generic advertisement format is then: 137 IPv4 SRRI 139 +-----------------------+ 140 | Flags | 1 byte 141 +-----------------------+ 142 | Algorithm | 1 byte 143 +-----------------------+ 144 | Recursing SID Address | 4 bytes 145 +-----------------------+ 146 | Local SID | 4 bytes (optional) 147 +-----------------------+ 149 IPv6 SRRI 151 +-----------------------+ 152 | Flags | 1 byte 153 +-----------------------+ 154 | Algorithm | 1 byte 155 +-----------------------+ 156 | Recursing SID Address | 16 bytes 157 +-----------------------+ 158 | Local SID | 4 bytes (optional) 159 +-----------------------+ 161 where: 163 o "Flags" is one byte field of flags. Only one flag is currently 164 defined: the V-flag. If set, the receiver of the SRRI MUST verify 165 that the originator of the prefix the SRRI is attached to and the 166 prefix covering the Recursing SID address are originated by the 167 same node ("same origin node"). 169 o "Algorithm" defines the algorithm related to the prefix 170 reachability as defined in [I-D.ietf-spring-segment-routing]. 172 o "Recursing SID Address" contains an IPv4 or IPv6 address whose 173 Node-SID is to be used in order to reach the prefix with which the 174 SRRI information is associated. 176 o "Local SID" is the local SID allocated to the prefix the SRRI is 177 attached to. 179 The SRRI is associated with a prefix reachability advertisement. The 180 manner of this association is protocol specific. 182 The following apply to the SRRI: 184 o The prefix reachability advertisement this SRRI is attached to 185 MUST NOT have a Prefix-SID assigned for the algorithm specified in 186 the SRRI. 188 o Multiple "Recursing SID Address" and "Local SID" MAY be associated 189 with the same parent prefix. 191 4. Illustration 193 4.1. Reference Diagram 195 The following reference topology diagram is used: 197 A----B----D 198 \ \ / 199 \ \/ 200 \ /\ 201 \ / \ 202 C----E 204 |------|------| 205 Area Area 206 0 1 208 A is in Area 0 209 B and C are ABRs 210 D and E are in Area 1 212 D has a loopback 1.0.0.4/32 and Node SID 16004 213 D has a local service 1.0.0.99/32 with Local SID 30004 214 E has a loopback 1.0.0.5/32 and Node SID 16005 215 E has a local service 1.0.0.99/32 with Local SID 30005 217 For simplicity, we abstracted the algorithm variable in the SRRI and 218 process. 220 4.2. Description 222 D advertises prefix 1.0.0.99/32 with SRRI (1.0.0.4, 30004, V=1) 224 B receives the 1.0.0.99/32 prefix advertisement from D. Since the 225 V-flag is set, B MUST confirm that D also originates the "Recursing 226 SID address" 1.0.0.4/32 (i.e.: "same origin node"). 228 If same origin node is not confirmed, then B does not install any SR 229 RIB entry for prefix 1.0.0.99/32. If same origin node is confirmed, 230 B installs an SR RIB entry for 1.0.0.99/32 which uses the segment 231 list {16004, 30004} and the OIF to 16004. 233 Furthermore, B leaks the prefix in area 0 and advertises it with the 234 SRRI (1.0.0.4, 30004, V=0). The V-flag unset indicates that area 0 235 nodes do not need to perform the "same origin node" check. 237 E advertises prefix 1.0.0.99/32 with the SRRI (1.0.0.5, 30005, V=1) 239 B does the same for the route from E as he did for the route from D. 241 Specifically, let us highlight two elements: 243 o First, B ends up with an ECMP SR-based RIB entry to 1.0.0.99/32: 245 - {16004, 30004} OIF to 16004 246 - {16005, 30005} OIF to 16005 248 o Second, B advertises 1.0.0.99/32 in area 0 with two SRRI's: 250 - (1.0.0.4, 30004, V=0) 251 - (1.0.0.5, 30005, V=0) 253 C does the same for the routes from D and E. Briefly, C advertises 254 1.0.0.99/32 in area 0 with two SRRI's: 256 - (1.0.0.4, 30004, V=0) 257 - (1.0.0.5, 30005, V=0) 259 A learns 1.0.0.99/32 from B and C and uses normal IGP process to 260 select one, the other or both. 262 Let us assume A prefers the path via B. 264 A receives the 1.0.0.99/32 prefix advertisement from B. Since the 265 V-flag is unset, no "same origin node" is verified. A installs an SR 266 RIB entry for 1.0.0.99/32 with an ECMP set of path: 268 path 1 is {16004, 30004} and the OIF to 16004 269 path 2 is {16005, 30005} and the OIF to 16005 271 5. Benefits 273 The mechanism and SR Recursive Information defined in this document 274 supports: 276 o single-area and multi-area deployments. 278 o single-homed and multi-homed prefixes. 280 o the presence of a Local-SID or not. 282 o Any combination of the above. 284 The Segment Routing Recursive Information minimize the number of 285 global prefix SID's. 287 Finally, the Segment Routing Recursive Information is consistent with 288 the MPLS FIB structure: different FEC's have different entries. 290 6. IANA Considerations 292 This document doesn't introduce any new code-point. 294 7. Security Considerations 296 TBD 298 8. Acknowledgements 300 We would like to thank Les Ginsberg and Ahmed Bashandy for their 301 contributions. 303 9. Normative References 305 [I-D.ietf-spring-segment-routing] 306 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 307 and R. Shakir, "Segment Routing Architecture", draft-ietf- 308 spring-segment-routing-09 (work in progress), July 2016. 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, 312 DOI 10.17487/RFC2119, March 1997, 313 . 315 Authors' Addresses 317 Clarence Filsfils 318 Cisco Systems, Inc. 319 Brussels 320 BE 322 Email: cfilsfil@cisco.com 323 Stefano Previdi 324 Cisco Systems, Inc. 325 Via Del Serafico, 200 326 Rome 00142 327 Italy 329 Email: sprevidi@cisco.com 331 Peter Psenak 332 Cisco Systems, Inc. 333 Apollo Business Center 334 Mlynske nivy 43 335 Bratislava 821 09 336 Slovakia 338 Email: ppsenak@cisco.com 340 Les Ginsberg 341 Cisco Systems, Inc. 342 US 344 Email: ginsberg@cisco.com