idnits 2.17.1 draft-lt-spring-sid-calculation-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 (October 19, 2015) is 3113 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: 'RFC4915' is defined on line 272, but no explicit reference was found in the text == Unused Reference: 'RFC4970' is defined on line 277, but no explicit reference was found in the text == Unused Reference: 'RFC5250' is defined on line 282, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-05 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-05 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-06 ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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 Fangwei. Hu 5 Expires: April 21, 2016 ZTE Corporation 6 October 19, 2015 8 SPRING SID Calculation 9 draft-lt-spring-sid-calculation-00.txt 11 Abstract 13 Segment Routing (SR) allows for a flexible definition of end-to-end 14 paths within IGP topologies by encoding paths as sequences of 15 topological sub-paths, called "segments". These segments are 16 advertised by the link-state routing protocols (IS-IS and OSPF). And 17 a segment is identified by a Segment Routing ID (SID). This document 18 proposes a method to calculate SID forwarding entry within SR 19 topology in a SR domain, and to guarantee the consistency of SR 20 encapsulation forwarding. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 21, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions and Abbreviations . . . . . . . . . . . . . . . . 3 58 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. SID calculation . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. SR independent topology . . . . . . . . . . . . . . . . . 4 61 4.2. SID calculation . . . . . . . . . . . . . . . . . . . . . 5 62 4.3. With SRMN or SRMS . . . . . . . . . . . . . . . . . . . . 5 63 4.3.1. Default label . . . . . . . . . . . . . . . . . . . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 Segment Routing (SR) allows for a flexible definition of end-to-end 73 paths within IGP topologies by encoding paths as sequences of 74 topological sub-paths, called "segments". The segments for its 75 attached prefixes and adjacencies are advertised by the link-state 76 routing protocols (IS-IS and OSPF). These segments are called IGP 77 segments or IGP SIDs. And an IGP-Prefix Segment is an IGP segment 78 attached to an IGP prefix. The segments forwarding entries are 79 learnt from its attached prefixes' egress information as described in 80 [I-D.ietf-spring-segment-routing], where wrote: A node N attaching a 81 Prefix-SID SID-R to its attached prefix R MUST maintain the following 82 FIB entry: Incoming Active Segment: SID-R Ingress Operation: NEXT 83 Egress interface: NULL A remote node M MUST maintain the following 84 FIB entry for any learned Prefix-SID SID-R attached to IP prefix R: 85 Incoming Active Segment: SID-R Ingress Operation: If the next-hop of 86 R is the originator of R and instructed to remove the active segment: 87 NEXT Else: CONTINUE Egress interface: the interface towards the next- 88 hop along the shortest-path to prefix R. 90 In some situations such as the SR need to be calculated as CSPF 91 calculation, the path calculated is not the shortest path, so the SR 92 needs to have the dependent topology. with the knowledge learnt from 93 [I-D.ietf-spring-segment-routing], the SR node does not have the 94 state about its neighbours. With the ldp interoperability as 95 described in [I-D.filsfils-spring-segment-routing-ldp-interop] 96 section 4.2, P6's next-hop for the IGP route "PE3" is not SR capable 97 (P7 does not advertise the SR capability). However, P6 has an LDP 98 label binding from that next-hop for the same FEC (e.g. LDP label 99 1037). Hence, P6 swaps 103 for 1037 and forwards to P7. The SR node 100 needs to judge its neighbour is SR or LDP. So it is still necessary 101 to maintain a SR topology to do the sid calculation. 103 This draft describes a mechanism to do the sid calculation. 105 2. Conventions and Abbreviations 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119] . 111 The following notations and abbreviations are used throughout this 112 draft. 114 SID: Segment Identifiers. 116 3. Motivation 118 As shown in the figure 1. 120 +--+ +--+ +--+ 121 ----|P1|---|P2|---|P3|---- 122 / +--+ +--+ +--+ \ 123 / \ 124 +---+ +---+ +---+ +---+ 125 |CE1|----|PE1| |PE2|----|CE2| 126 +---+ +---+ +---+ +---+ 127 \ / 128 \ +--+ +--+ / 129 ----|R5|----------|R6|---- 130 +--+ +--+ 132 Figure 1 Scenario 1 134 PE1\P1\P2\P3\PE2 are routers supporting mpls forwarding, while R5\R6 135 are routers do not enable mpls or occurred some error the mpls 136 neighbour between R5\R6 is broken. Such as the SID assigned to PE1 137 10001, P1 10002, P2 10003, P3 10004 and PE2 10005. From PE1 to PE2, 138 each link cost between the nodes is 1. So the shortest path is 139 PE1-R5-R6-PE2, with SR forwarding, the next hop with the forwarding 140 entry on PE1 to PE2 10005 is to R5 currently. It will causing the 141 mpls encapsulation packets forwarding to R5 who does not support mpls 142 forwarding, the packets will be dropped. 144 +--+ +--+ +--+ +--+ 145 ----|P1|---|P2|---|P3|---|P4|---- 146 / sr +--+ sr+--+ sr+--+ sr+--+ sr \ 147 / \ 148 +---+ +---+ +---+ +---+ 149 |CE1|----|PE1| |PE2|----|CE2| 150 +---+ +---+ +---+ +---+ 151 \ / 152 \sr +--+ ldp +--+ igp +--+ igp/ 153 ----|P5|------|P6|------|R7|---- 154 +--+ +--+ +--+ 156 Figure 2 Scenario 2 158 PE1\P1\P2\P3\P4\P5\P6\PE2 are routers supporting MPLS forwarding, 159 Such as the SID assigned to PE1 10001, P1 10002, P2 10003, P3 10004, 160 PE2 10005, P4 10006, P5 10007. While P5 and P6 is LDP neighbour, and 161 P6 and R7 is LDP neighbour , R7 and PE2 is LDP neighbour, with some 162 mistake, the LDP neighbour between P6-R7, R7-PE2 are off, and the IGP 163 neighbour between P6-R7, R7-PE2 are still on. From PE1 to PE2, each 164 link cost between the nodes is 1. So the shortest path is 165 PE1-P5-P6-R7-PE2, with SR forwarding, the next hop with the 166 forwarding entry on PE1 to PE2 10005 is to P5 currently. It will 167 causing the MPLS encapsulation packets forwarding to P5 with the 168 10005 in the outer label, and switches to the LDP label which the P6 169 assigned to PE2, and the MPLS packet forwarding to P6, P6 accept the 170 mpls packets, and find that the neighbour of the next hop is not ldp 171 neighbour, so the packets will be dropped either. 173 The problem in the SR dependent IGP topology is that the ingress 174 nodes has not have the full information with all the nodes on the 175 path. While the list includes nodes' information, all this nodes in 176 the list is SR enabled nodes, but the nodes' information is not all 177 the nodes on the path. So it is necessary to have the independent SR 178 topology to support the mixed network. After all, the network where 179 some nodes or links are not enabled mpls capabilities is commonly. 181 4. SID calculation 183 In the proposed mechanism, the SR will be an independent topology, 184 and the SID calculation will be calculated based in the topology. 186 4.1. SR independent topology 188 The SR topology will be an independent topology based on the SR- 189 Capabilities Sub-TLV (as described in 190 [I-D.ietf-isis-segment-routing-extensions] and 191 [I-D.ietf-ospf-segment-routing-extensions]. ) carried in each 192 router's LSP. If SR node A accepted an lsp sending from node B, with 193 the SR-Capabilities Sub-TLV carried in node B's LSP, the node A will 194 know that the node B is a SR capable node, and in node A's LSDB, it 195 will has an independent SR topology. 197 4.2. SID calculation 199 With the independent SR topology, SID calculation will be calculated 200 in the topology, and the SID forwarding entry will be maintained with 201 SID calculation. 203 As figure 1 described, PE1 will have an independent topology which 204 includes the SID information of PE1\P1\P2\P3\PE2, and will not 205 include the information of R5\R6, so when PE1 calculate the SID to 206 10005, even though the IGP shortest-path is through R5\R6, PE1 will 207 calculate the path to 10005 only in the SR topology. 209 4.3. With SRMN or SRMS 211 Optionally, If there are some SRMNs or SRMSes assigned by the NMS in 212 the network, they assign SID to other SR or non-SR nodes, with the SR 213 nodes, the SR nodes will sending out an TLV with it's SID and the SR- 214 Capabilities Sub-TLV, then other nodes will learn which nodes are the 215 SR nodes. With the non-SR nodes, this nodes can not sending out the 216 SR-Capabilities Sub-TLV, but other SR nodes need to learn this SIDs' 217 information, in this case, the SRMNs or SRMSes will sending an 218 default label TLV extension out, using the default label to instruct 219 the packet with the SID assigned to non-SR node forwarding to itself, 220 and then it is responsible for sending the packet to the non-SR node. 222 4.3.1. Default label 224 Optionally, the default label could either be an reserved and unused 225 label, or be configured by the NMS and will be known by each SR node. 227 5. Security Considerations 229 TBD. 231 6. Acknowledgements 233 In progress. 235 7. IANA Considerations 237 TBD. 239 8. Normative References 241 [I-D.filsfils-spring-segment-routing-ldp-interop] 242 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 243 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 244 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 245 "Segment Routing interoperability with LDP", draft- 246 filsfils-spring-segment-routing-ldp-interop-03 (work in 247 progress), March 2015. 249 [I-D.ietf-isis-segment-routing-extensions] 250 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 251 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 252 Extensions for Segment Routing", draft-ietf-isis-segment- 253 routing-extensions-05 (work in progress), June 2015. 255 [I-D.ietf-ospf-segment-routing-extensions] 256 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 257 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 258 Extensions for Segment Routing", draft-ietf-ospf-segment- 259 routing-extensions-05 (work in progress), June 2015. 261 [I-D.ietf-spring-segment-routing] 262 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 263 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 264 ietf-spring-segment-routing-06 (work in progress), October 265 2015. 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, 269 DOI 10.17487/RFC2119, March 1997, 270 . 272 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 273 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 274 RFC 4915, DOI 10.17487/RFC4915, June 2007, 275 . 277 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 278 S. Shaffer, "Extensions to OSPF for Advertising Optional 279 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 280 2007, . 282 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 283 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 284 July 2008, . 286 Authors' Addresses 288 Ting Liao 289 ZTE Corporation 290 No.50 Software Avenue 291 Nanjing, Jiangsu 210012 292 China 294 Phone: +86 25 88016576 295 Email: liao.ting@zte.com.cn 297 Ting Ao 298 ZTE Corporation 299 No.889 Bibo Rd 300 Shanghai 201203 301 China 303 Phone: +86 21 68896273 304 Email: ao.ting@zte.com.cn 306 Fangwei Hu 307 ZTE Corporation 308 No.889 Bibo Rd 309 Shanghai 201203 310 China 312 Phone: +86 21 68896273 313 Email: hu.fangwei@zte.com.cn