idnits 2.17.1 draft-li-sbfd-over-srv6-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 has text resembling RFC 2119 boilerplate text. -- The document date (July 8, 2021) is 1022 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '0' on line 126 looks like a reference -- Missing reference section? '5' on line 152 looks like a reference Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft T. Sun 4 Intended status: Informational China Mobile 5 Expires: January 9, 2022 W. Cheng 6 J. Wang 7 Centec 8 July 8, 2021 10 S-BFD over SRv6 11 draft-li-sbfd-over-srv6-00 13 Abstract 15 Bidirectional Forwarding Detection (BFD) can be used to monitor paths 16 between node. Seamless BFD (S-BFD) provides a simplified mechanism 17 which is suitable for monitoring of paths that are setup dynamically 18 and on a large scale network. This draft describes a method to 19 simplify the implementation of S-BFD over SRv6 by using SRH.flag to 20 instruct the S-BFD peer node to do reverse operation of SRv6 SID 21 list. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in . 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 9, 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Motiviation for Proposing S-BFD over SRv6 . . . . . . . . . . 2 65 3. The benefits of S-BFD over SRv6 . . . . . . . . . . . . . . . 4 66 4. Future Considerations and Enhancements of S-BFD over SRv6 . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 With the increasing adoption of segment routing (SR) technology, ISPs 74 have upgraded their networks seamlessly from MPLS to SR MPLS, and 75 their next goal might be the overall upgrading of the IPv6 underlay 76 network forwarding plane. 78 We hope to implement BFD over SRv6 while retaining the bidirectional 79 detection capabilities of traditional BFD, rather than using 80 asymmetrical path detection only. Another problem relates to the 81 bidirectional detection mechanism in BFD over SRv6, Using SR Policy 82 or using TLV to carry the return path brings extra load to the 83 message parsing depth on existing SRv6 device. 85 In order to accelerate applying BFD in SRv6 networks, this paper 86 proposed a S-BFD over SRv6 implementation solution. 88 2. Motiviation for Proposing S-BFD over SRv6 90 As shown in the figure below, the BFD initiator is A and the peer 91 node is D, while bfd packets forwarding from A to D via the path: 92 A->B->C->D, and return via the path: D->C->B->A. 94 +-----B-------C-----+ 95 / \ 96 A-----------E-----------D 97 \ / 98 +-----F-------G-----+ 100 Forward Paths: A-B-C-D 101 Return Paths: D-C-B-A 103 Traditional BFD in SRv6 Data Plane 105 SRv6 SID operations on the initial node A: The SRv6 SID list {A, B, 106 C, D} is pushed into Node A. 108 SRv6 SID operations on the terminal node D: The SRv6 SID list {A, B, 109 C, D} is swapped in Node D, and the updated SRv6 SID list is : {D, C, 110 B, A}, and the Last Entry, Segment Left, and other fields are 111 updated.Return Path: D->C->B->A. 113 As shown in the figure below, the length of the flags field in the 114 SRH header is 8-bit. This draft uses the left third bit 115 (0|0|R|0|0|0|0|0) to represent the reverse operation of the SRv6 SID 116 list. 118 0 1 2 3 119 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 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Next Hdr=144 | Hdr Ext Len | Routing Type | Segments Left | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Last Entry | Flags | Tag | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | | 126 | Segment List[0] (128-bit IPv6 address) | 127 | | 128 | | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | | 131 | | 132 ... 133 | | 134 | | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | | 137 | Segment List[n] (128-bit IPv6 address) | 138 | | 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 | SRv6 SPAN Header | 143 | | 144 | | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Origin Packet | 147 | | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 The reverse operations for S-BFD of SRv6 Flag 152 BFD peer node D check if SRH.Flags[5] == 1, it means that this device 153 requires the reverse operation of the SRv6 SID list. 155 3. The benefits of S-BFD over SRv6 157 This solution does not need to use the SRv6 Policy to add length of 158 the SID list or to carry the SID list of the return path by TLV. It 159 only needs to support reverse SRv6 SID in the reflector node to solve 160 the issue of S-BFD over SRv6 described in the previous. 162 4. Future Considerations and Enhancements of S-BFD over SRv6 164 In future versions of this paper, we will also consider the 165 compatibility of using compressed IDs in SRv6, such as seamlessly 166 merging S-BFD over G-SRv6. Furthermore, there will be no effect on 167 intermediate nodes within the SRv6 network and it only requires S-BFD 168 reflector support the SID reverse operation. 170 5. Security Considerations 172 TBD. 174 6. IANA Considerations 176 TBD. 178 Authors' Addresses 180 Zhiqiang Li 181 China Mobile 182 Beijing 100053 183 China 185 Email: lizhiqiangyjy@chinamobile.com 187 Tao Sun 188 China Mobile 189 Beijing 100053 190 China 192 Email: suntao@chinamobile.com 194 Wei Cheng 195 Centec 196 Suzhou 215000 197 China 199 Email: chengw@centecnetworks.com 201 Junjie Wang 202 Centec 203 Suzhou 21500 204 China 206 Email: wangjj@centecnetworks.com