idnits 2.17.1 draft-gulkohegde-routing-planes-using-sr-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 (March 13, 2017) is 2600 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: 'SR-OSPFv3' is defined on line 262, but no explicit reference was found in the text == Unused Reference: 'RFC7684' is defined on line 269, but no explicit reference was found in the text == Unused Reference: 'SR-ARCH' is defined on line 274, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-11 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-11 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-06 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-09 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING S. Hegde 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track A. Gulko 5 Expires: September 14, 2017 Thomson Reuters 6 March 13, 2017 8 Separating Routing Planes using Segment Routing 9 draft-gulkohegde-routing-planes-using-sr-00 11 Abstract 13 Many network deployments arrange the network topologies in two or 14 more planes. The traffic generally uses one of the planes and fails 15 over to the other plane when there are link or node failure. Certain 16 applications require the traffic to be strictly restricted to a 17 particular plane and should not failover to the other plane. This 18 document proposes a solution for the strict planar routing using 19 Segment Routing. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 14, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.1. Routing-plane SID . . . . . . . . . . . . . . . . . . . . 3 65 3.1.1. Elements of procedure . . . . . . . . . . . . . . . . 4 66 3.2. Multi-topology SID . . . . . . . . . . . . . . . . . . . 4 67 4. Backward compatibility . . . . . . . . . . . . . . . . . . . 5 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 8.2. Informative References . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 A3----------------------A4 79 / | /| 80 / | / | 81 / | / | 82 A1---|-------------------A2 | 83 | B3------------------|---B4 84 | / | / 85 | / | / 86 | / | / 87 B1-----------------------B2 89 Figure 1: Network Planes 91 The above Figure 1 represents a network topology in two planes.Nodes 92 A1, A2, A3, A4 are in plane A and B1, B2, B3, B4 are in plane B. 93 A1->B1, A2->B2, A3->B3, A4->B4 represent the "shunt links" which 94 connect the two planes. Certain applications require that the 95 traffic follows plane A and remains in plane A in case of failures 96 and does not cross over to plane B. Strict routing plane 97 requirements can be met using multiple techniques. This draft 98 focuses on solutions using Segment Routing technology. 100 2. Motivation 102 The motivation of this document is to provide solutions to strict 103 routing plane requirements using Segment Routing. The following 104 objectives help to accomplish this in a range of deployment 105 scenarios. 107 1. Maintain strict routing within routing planes. 109 2. Allow traffic to failover within routing plane and do not allow 110 traffic to failover to other planes 112 3. Achieve ease of configuration and operational management 114 3. Solutions 116 There are multiple ways to address the strict routing plane 117 requirements. Section 3.1 describes a mechanism by using diferrent 118 SIDs for each plane.Another option is to use Multi-topology SIDs as 119 defined in Section 3.2. 121 3.1. Routing-plane SID 123 A new SID called Routing-Plane SID is defined and associated with new 124 algorithm values. This document proposes 4 new algorithm values 125 which represent SPF in routing-planes. When the network topology is 126 organized into two different planes, each node in plane A associates 127 a new Routing-Plane SID to one of it's loopback addresses and 128 advertises the SID in the segment routing extension defined in [SR- 129 OSPF] section 2.1 and [SR-IS-IS] section 5. The prefix-SID sub-TLV 130 carries the new algorithm values corresponding to the routing-plane. 131 The traffic which needs to be restricted to a certain routing- 132 plane,should use the Routing-Plane SID corresponding to that plane to 133 forward the traffic. The paths through the Routing planes MAY use 134 single Routing Plane SID or a stack of multiple Routing Plane SIDs. 135 Adjacency-SIDs can also be used build paths across routing planes. 136 Adjacency-SIDs are not scoped per-algorithm and it is possible that 137 the protection path for the adjacency SIDs uses a path going over a 138 different routing-plane.It is recommended to use non-protected 139 adjacency-SIDs to avoid backup traffic flowing through different 140 plane. 142 3.1.1. Elements of procedure 144 All the nodes that belong to a certain routing-plane MUST advertise 145 the algorithm corresponding to that routing-plane in the algorithm 146 sub-TLV as defined in [SR-OSPF] and [SR-IS-IS]. The nodes SHOULD 147 also advertise Routing-Plane SID corresponding to that algorithm in 148 the prefix-SID Sub-TLV. 150 A node that receives the algorithm sub-TLV with new algorithm value 151 specified in Section 6 MUST compute SPF with all the nodes that 152 advertised the new algorithm. The next-hops and RIB entries for the 153 Routing-Plane SIDs MUST be computed from the routing-plane SPF. 154 Certain nodes MAY belong to multiple routing-planes. Such nodes MUST 155 compute SPF corresponding to each plane and compute the next-hops for 156 the SIDs corresponding to each plane. 158 Each router MAY assign different IP address corresponding to each 159 plane or MAY use the same IP address to assign the node-SIDs and 160 Routing-Plane SIDs. The ingress routers MAY advertise binding-SIDs 161 as defined in [SR-ARCH]section 3.5.2, for the label stacks that are 162 constructed using routing-Plane SIDs. The ingress routers MAY map 163 the incoming IP traffic onto the Routing-Plane SIDs, the mechanisms 164 to do so is implementation dependant and outside the scope of this 165 document. 167 When the network topology is organized into multiple IGP levels or 168 areas, the Routing Plane SIDs MAY be re-originated from one IGP 169 domain into the other domain by the border routers. The border IGP 170 routers MUST re-advertise the Routing-Plane SIDs if they belong to 171 the corresponding Routing plane and has advertised the algorithm 172 corresponding to the routing-plane. 174 3.2. Multi-topology SID 176 Multi topology Routing defines mechanisms to support multiple 177 topologies in a single physical network. ISIS and OSPF extensions to 178 support multi-topology routing is defined in [RFC5120] and [RFC4915] 179 respectively. Multi-topology routing defined in [RFC5120] and 180 [RFC4915] describes mechanisms to separate topologies in ISIS and 181 OSPF by advertising separate MT-TLVs in ISIS and multi-topology 182 scoped Router LSA in OSPF. The different routing planes in customer 183 network can be assigned with different MT-ID for each routing-plane 184 and the multi-topology SIDs can be advertised for each MT-ID as 185 described in [SR-OSPF] and [SR-IS-IS]. Multi-topology SIDs are 186 associated with algorithm 0 and no new algorithm definition is 187 required. All the nodes in the network MUST also support multi- 188 topology routing as defined in [RFC5120] and [RFC4915]. All the 189 nodes in the network compute separate SPF per MT-ID and program the 190 forwarding planes with MT-SIDs accordingly. Multi-topology SIDs are 191 used to build the explicit paths through the network. Multi-topology 192 based solution has an advantage of possibility of assigning different 193 IGP costs to links for different MTs. For deployments that do not 194 need separate IGP costs and topologies for each routing plane, it 195 comes with an additional operational overhead of maintaining multi- 196 topology configurations. 198 4. Backward compatibility 200 The mechanism described in the document is fully backward compatible. 201 If a node does not support the extensions defined in this document, 202 it will not advertise the additional algorithm values in the 203 algorithm sub-TLV. All the computing nodes will not consider the 204 node in the SPF computation if it has not advertised the specific 205 algorithm. For the multi-topology based solution backward 206 compatibility mechanism described in [RFC5120] and [RFC4915] are 207 applicable. 209 5. Security Considerations 211 This document does not introduce any further security issues other 212 than those discussed in [SR-OSPF] and [SR-IS-IS]. 214 6. IANA Considerations 216 This specification updates OSPF and ISIS registry: 218 OSPF Router Information (RI) TLVs Registry 220 8 (IANA Preallocated) - SR-Algorithm TLV 222 Algorithm 2 -5 : SPF in routing plane 224 ISIS Sub TLVs for Type 242 226 Type: TBD (suggested value 19) 228 Description: Segment Routing Algorithm 230 Algorithm 2-5 : SPF in Routing Plane 232 7. Acknowledgements 233 8. References 235 8.1. Normative References 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, 239 DOI 10.17487/RFC2119, March 1997, 240 . 242 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 243 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 244 RFC 4915, DOI 10.17487/RFC4915, June 2007, 245 . 247 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 248 Topology (MT) Routing in Intermediate System to 249 Intermediate Systems (IS-ISs)", RFC 5120, 250 DOI 10.17487/RFC5120, February 2008, 251 . 253 [SR-IS-IS] 254 "IS-IS Extensions for Segment Routing, draft-ietf-isis- 255 segment-routing-extensions-11(work in progress)", October 256 2016. 258 [SR-OSPF] "OSPF Extensions for Segment Routing, draft-ietf-ospf- 259 segment-routing-extensions-11(work in progress)", July 260 2016. 262 [SR-OSPFv3] 263 "OSPFv3 Extensions for Segment Routing, draft-ietf-ospf- 264 ospfv3-segment-routing-extensions-06(work in progress)", 265 July 2016. 267 8.2. Informative References 269 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 270 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 271 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 272 2015, . 274 [SR-ARCH] "Segment Routing Architecture, draft-ietf-spring-segment- 275 routing-09(work in progress)", July 2016. 277 Authors' Addresses 279 Shraddha Hegde 280 Juniper Networks, Inc. 281 Embassy Business Park 282 Bangalore, KA 560093 283 India 285 Email: shraddha@juniper.net 287 Arkadiy Gulko 288 Thomson Reuters 290 Email: arkadiy.gulko@thomsonreuters.com