idnits 2.17.1 draft-chen-rtgwg-srv6-midpoint-protection-01.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 (September 13, 2019) is 1684 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: 'SL' is mentioned on line 203, but not defined == Unused Reference: 'I-D.bashandy-isis-srv6-extensions' is defined on line 229, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 240, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-segment-routing-extensions' is defined on line 246, but no explicit reference was found in the text == Unused Reference: 'I-D.li-ospf-ospfv3-srv6-extensions' is defined on line 252, but no explicit reference was found in the text == Unused Reference: 'RFC7356' is defined on line 262, but no explicit reference was found in the text == Unused Reference: 'I-D.bashandy-rtgwg-segment-routing-ti-lfa' is defined on line 269, but no explicit reference was found in the text == Unused Reference: 'I-D.hegde-spring-node-protection-for-sr-te-paths' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 282, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 288, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 294, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-hu-spring-segment-routing-proxy-forwarding-04 == Outdated reference: A later version (-07) exists of draft-li-ospf-ospfv3-srv6-extensions-05 == Outdated reference: A later version (-07) exists of draft-hegde-spring-node-protection-for-sr-te-paths-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 Summary: 0 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chen 3 Internet-Draft China Telecom 4 Intended status: Standards Track Z. Hu 5 Expires: March 16, 2020 Huawei Technologies 6 H. Chen 7 Futurewei 8 September 13, 2019 10 SRv6 Proxy Forwarding 11 draft-chen-rtgwg-srv6-midpoint-protection-01 13 Abstract 15 The endpoints of a SRv6 path are given by a SRv6 Policy. When an 16 endpoint node fails, we need bypass this failed endpoint node and 17 forward the packets to the failed node's next endpoint node. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 https://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 March 16, 2020. 42 Copyright Notice 44 Copyright (c) 2019 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 (https://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. Endpoint Node Protection for Segment List . . . . . . . . . . 3 61 2.1. Transit Node as PLR . . . . . . . . . . . . . . . . . . . 3 62 2.2. Endpoint Node as PLR . . . . . . . . . . . . . . . . . . 3 63 2.3. Endpoint x Node as PLR . . . . . . . . . . . . . . . . . 4 64 2.4. Endpoint t Node as PLR . . . . . . . . . . . . . . . . . 5 65 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 6.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 "Segment Routing Proxy Forwarding" for IPv4 is defined in 76 [I-D.hu-spring-segment-routing-proxy-forwarding]. It provides the 77 protections for the middle endpoints of a SR path. This document 78 specifies the proxy forwarding for SRv6, which supports the 79 protections for the middle endpoints of a SRv6 path. 81 The endpoints of a SRv6 path are given by a SRv6 Policy. When an 82 endpoint node fails, we need bypass this failed endpoint node and 83 forward the packets to the failed node's next endpoint node. On the 84 PLR (i.e., the previous hop node of the failed endpoint node), it 85 performs the bypass protection as follows if NH = SRH and SL != 0. 87 If the outbound interface fails and the failed endpoint node (FN for 88 short) is directly connected to the PLR, then the PLR forwards the 89 packets through a bypass to the FN's next endpoint node. If it is 90 not directly connected, the normal Ti-LFA is executed. 92 If it is a FIB miss, the PLR forwards the packets through a bypass to 93 the FN's next endpoint node. There is no need to check if the failed 94 endpoint node is directly connected to the PLR. 96 2. Endpoint Node Protection for Segment List 98 2.1. Transit Node as PLR 100 When the PLR is a transit node, it provides fast protection against 101 the endpoint node failure as follows after looking up the FIB. 103 IF the primary outbound interface used to forward the packet failed 104 IF NH = SRH && SL != 0, and 105 the failed endpoint is directly connected to the PLR THEN 106 SL--; update the IPv6 DA with SRH[SL]; 107 FIB lookup on the updated DA; 108 forward the packet according to the matched entry; 109 ELSE 110 forward the packet according to the backup nexthop; 111 ELSE // there is no FIB entry for forwarding the packet 112 IF NH = SRH && SL != 0 THEN 113 SL--; update the IPv6 DA with SRH[SL]; 114 FIB lookup on the updated DA; 115 forward the packet according to the matched entry; 116 ELSE 117 drop the packet; 119 Figure 1: PLR transit 121 2.2. Endpoint Node as PLR 123 When a node N receives a packet, if the destination address (DA) of 124 the packet is a local END SID, then node N is an endpoint node. 126 When the PLR is an endpoint node, it provides fast protections for 127 the failure through executing the following procedure after looking 128 up the FIB for the updated DA. 130 IF the primary outbound interface used to forward the packet failed 131 IF NH = SRH && SL != 0, and 132 the failed endpoint is directly connected to the PLR THEN 133 SL--; update the IPv6 DA with SRH[SL]; 134 FIB lookup on the updated DA; 135 forward the packet according to the matched entry; 136 ELSE 137 forward the packet according to the backup nexthop; 138 ELSE // there is no FIB entry for forwarding the packet 139 IF NH = SRH && SL != 0 THEN 140 SL--; update the IPv6 DA with SRH[SL]; 141 FIB lookup on the updated DA; 142 forward the packet according to the matched entry; 143 ELSE 144 drop the packet; 145 //ELSE 146 // forward accordingly to the matched entry; 148 Figure 2: PLR endpoint 150 2.3. Endpoint x Node as PLR 152 An endpoint node with cross-connect (End.X for short) is an endpoint 153 node with an array of layer 3 adjacencies. 155 When a node N receives a packet, if the destination address (DA) of 156 the packet is a local END.X SID, then node N as PLR provides fast 157 protections for the failure through executing the following procedure 158 after updating DA. 160 IF the layer-3 adjacency interface is down THEN 161 FIB lookup on the updated DA; 162 IF the primary interface used to forward the packet failed THEN 163 IF NH = SRH && SL != 0, and 164 the failed endpoint is directly connected to the PLR THEN 165 SL--; update the IPv6 DA with SRH[SL]; 166 FIB lookup on the updated DA; 167 forward the packet according to the matched entry; 168 ELSE 169 forward the packet according to the backup nexthop; 170 ELSE // there is no FIB entry for forwarding the packet 171 IF NH = SRH && SL != 0 THEN 172 SL--; update the IPv6 DA with SRH[SL]; 173 FIB lookup on the updated DA; 174 forward the packet according to the matched entry; 175 ELSE 176 drop the packet; 177 //ELSE 178 // forward accordingly to the matched entry; 180 Figure 3: PLR endpoint cross-connect 182 2.4. Endpoint t Node as PLR 184 An endpoint node with specific IPv6 table (End.T for short) is an 185 endpoint node with specific IPv6 table lookup function. 187 When a node N receives a packet, if the destination address (DA) of 188 the packet is a local END.T SID, then node N as PLR provides fast 189 protections for the failure through executing the following procedure 190 after looking up the next segment in IPv6 table T associated with the 191 SID. 193 IF the primary interface used to forward the packet failed THEN 194 IF NH = SRH && SL != 0, and 195 the failed endpoint is directly connected to the PLR THEN 196 SL--; update the IPv6 DA with SRH[SL]; 197 lookup the next segment in IPv6 table T associated with the SID; 198 forward the packet according to the matched entry; 199 ELSE 200 forward the packet according to the backup nexthop; 201 ELSE // there is no FIB entry for forwarding the packet 202 IF NH = SRH && SL != 0 THEN 203 SL--; update the IPv6 DA with SRH[SL]; 204 lookup the next segment in IPv6 table T associated with the SID; 205 forward the packet according to the matched entry; 206 ELSE 207 drop the packet; 208 //ELSE 209 // forward accordingly to the matched entry; 211 Figure 4: PLR endpoint table 213 3. IANA Considerations 215 TBD 217 4. Security Considerations 219 TBD 221 5. Acknowledgements 223 TBD 225 6. References 227 6.1. Normative References 229 [I-D.bashandy-isis-srv6-extensions] 230 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 231 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 232 Dataplane", draft-bashandy-isis-srv6-extensions-05 (work 233 in progress), March 2019. 235 [I-D.hu-spring-segment-routing-proxy-forwarding] 236 Hu, Z., Chen, H., Yao, J., Bowers, C., and Y. Zhu, "SR-TE 237 Path Midpoint Protection", draft-hu-spring-segment- 238 routing-proxy-forwarding-04 (work in progress), July 2019. 240 [I-D.ietf-isis-segment-routing-extensions] 241 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 242 Gredler, H., and B. Decraene, "IS-IS Extensions for 243 Segment Routing", draft-ietf-isis-segment-routing- 244 extensions-25 (work in progress), May 2019. 246 [I-D.ietf-ospf-segment-routing-extensions] 247 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 248 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 249 Extensions for Segment Routing", draft-ietf-ospf-segment- 250 routing-extensions-27 (work in progress), December 2018. 252 [I-D.li-ospf-ospfv3-srv6-extensions] 253 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 254 "OSPFv3 Extensions for SRv6", draft-li-ospf- 255 ospfv3-srv6-extensions-05 (work in progress), August 2019. 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, 259 DOI 10.17487/RFC2119, March 1997, 260 . 262 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 263 Scope Link State PDUs (LSPs)", RFC 7356, 264 DOI 10.17487/RFC7356, September 2014, 265 . 267 6.2. Informative References 269 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 270 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 271 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 272 Camarillo, "Topology Independent Fast Reroute using 273 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 274 lfa-05 (work in progress), October 2018. 276 [I-D.hegde-spring-node-protection-for-sr-te-paths] 277 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 278 "Node Protection for SR-TE Paths", draft-hegde-spring- 279 node-protection-for-sr-te-paths-05 (work in progress), 280 July 2019. 282 [I-D.ietf-spring-segment-routing-policy] 283 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 284 bogdanov@google.com, b., and P. Mattes, "Segment Routing 285 Policy Architecture", draft-ietf-spring-segment-routing- 286 policy-03 (work in progress), May 2019. 288 [I-D.sivabalan-pce-binding-label-sid] 289 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 290 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 291 in PCE-based Networks.", draft-sivabalan-pce-binding- 292 label-sid-07 (work in progress), July 2019. 294 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 295 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 296 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 297 2009, . 299 Authors' Addresses 301 Huanan Chen 302 China Telecom 303 109, West Zhongshan Road, Tianhe District 304 Guangzhou 510000 305 China 307 Email: chenhn8.gd@chinatelecom.cn 309 Zhibo Hu 310 Huawei Technologies 311 Huawei Bld., No.156 Beiqing Rd. 312 Beijing 100095 313 China 315 Email: huzhibo@huawei.com 317 Huaimo Chen 318 Futurewei 319 Boston, MA 320 USA 322 Email: Huaimo.chen@futurewei.com