idnits 2.17.00 (12 Aug 2021) /tmp/idnits20844/draft-adubey-bfd-service-redundancy-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The BFD control packet with the new Diag code and the bitmap will be sent after the BFD session came up in the BFD control packets for at least twice the detection multiplier count. Only the non-revertive services associated bits in the bitmap will be set by a service node acting as a backup for those services after a primary node failure recovery. Primary node upon receiving the BFD control packet with the bit set for the corresponding non-revertive service MUST not attempt to activate the service, but should remain in standby state for the service until the backup node that took over fails. -- The document date (May 14, 2017) is 1832 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: 'RFC2119' is mentioned on line 105, but not defined == Unused Reference: 'RFC5880' is defined on line 189, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Sami Boutros 3 Intended Status: Standard Track Ankur Dubey 4 VMware 6 Reshad Rahman 7 Cisco 9 Expires: November 15, 2017 May 14, 2017 11 Service Redundancy using BFD 12 draft-adubey-bfd-service-redundancy-00 14 Abstract 16 In a data center, when multiple routing/service nodes are providing 17 single active redundancy for a set of L2, L3 and/or L4-L7 services. 18 Both non-revertive and revertive fail over modes are required for the 19 services. This draft describes a method to achieve the non-revertive 20 and revertive fail over modes for services using Bidirectional 21 Forwarding Detection (BFD). 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 4 64 3 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 5 66 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 67 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1 Introduction 72 This document describes how can a group of service/routing nodes in a 73 data center providing single active redundancy for multiple L2/L3 74 and/or L4/L7 services, can use BFD protocol to support non-revertive 75 as well as revertive fail over mode. 77 Typically, BFD is used between the group of service nodes to verify 78 the connectivity as well as the aliveness of the service nodes. The 79 assignment of which node in the group is the primary designated 80 forwarder for a given service can be determined using a centralized 81 or distributed control plane. 83 The use of BFD will be to communicate the set of services that are 84 being currently active on a given service node to the other service 85 nodes. On a given node failure, for a given service the backup node 86 will take over. If the service was configured to have a non-revertive 87 fail over mode, then the backup node should continue to perform the 88 service forwarding even after the primary node recovers and comes 89 back up. In order to do that, the backup node MUST inform the primary 90 node that it is currently active for the service. This is achieved 91 through the extension we are proposing to the BFD protocol as will be 92 described in the following sections. 94 It is to be noted that for revertive fail over mode of operation, the 95 primary node should be able to take over the active role from the 96 backup node when the primary node goes back to an operational state. 97 This can be as well communicated using the BFD session establishment 98 between the primary node and the backup node. 100 1.1 Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 2. Solution Overview 108 +----------+ 109 |Controller| 110 +----------+ 111 // | \ 112 // | \ 113 // | \ 114 +-------+ +-------+ +-------+ 115 |Node1 |-BFD-|Node2 |-BFD-|Node3 | 116 +-------+ +-------+ +-------+ 117 |--------------BFD--------| 119 Figure 1: 121 Figure 1 shows 3 routing nodes using BFD to implement the single 122 active redundancy for revertive and non-revertive services. 124 Multiple L2/L3 and/or L4/L7 services are offered in a data center by 125 a set of routing/service nodes providing single active redundancy. 126 The provisioning of the services can be done using a centralized 127 control plane implemented in a controller or using a distributed 128 dynamic control plane. 130 Every L2/L3 and/or L4/L7 service is identified by a unique ID known 131 across the routing/service nodes providing the services. 133 A bitmap will be used to represent the services, where each service 134 is represented by one bit in the bit map. All the service nodes MUST 135 have the same mapping of the bit position to the service unique ID. 136 The bitmap position and the unique service ID could be maintained by 137 a network controller. The bitmap will be used in the payload of the 138 BFD packets sent by the service node to indicate which service the 139 node maintain an active status for. 141 Service nodes providing single active redundancy will communicate 142 using BFD this bitmap carried in the BFD control packet payload. When 143 a backup service node takes over a service with a non-revertive fail 144 over mode after primary node failure. The backup node once the BFD 145 session comes up with the recovered primary node, will set the bit 146 associated with this service in the bitmap payload carried in the BFD 147 control packet sent to the primary node. Furthermore, the backup node 148 will use a new Diag code in the BFD control packet to inform the 149 primary node that it out-lived it and took over the set of non- 150 preemptive services encoded in the bitmap of the BFD control packet 151 payload. 153 The BFD control packet with the new Diag code and the bitmap will be 154 sent after the BFD session came up in the BFD control packets for at 155 least twice the detection multiplier count. Only the non-revertive 156 services associated bits in the bitmap will be set by a service node 157 acting as a backup for those services after a primary node failure 158 recovery. Primary node upon receiving the BFD control packet with the 159 bit set for the corresponding non-revertive service MUST not attempt 160 to activate the service, but should remain in standby state for the 161 service until the backup node that took over fails. 163 Revertive services are assumed to revert back to the primary node 164 after primary node recovers. Once the BFD session comes up between 165 the primary and backup node, the backup node should stop forwarding 166 for any revertive services. A node MUST start forwarding all 167 revertive services for which it is configured as a primary once the 168 BFD session comes up with the corresponding backup nodes. A node MUST 169 stop forwarding for revertive services for which it is a backup once 170 the BFD session comes up with the corresponding primary. 172 3 Acknowledgements 174 4 Security Considerations 176 This document does not introduce any additional security constraints. 178 5 IANA Considerations 180 IANA is requested to assign a new diag code from the "BFD Diagnostic 181 Codes" 183 Value BFD Diagnostic Code Name 184 ----- ------------------------------------------------------------ 185 0xNN Out-lived and BitMap payload set with non-revertive services 187 6 References 189 [RFC5880] D. Katz, D. Ward "Bidirectional Forwarding Detection 190 (BFD)". 192 Authors' Addresses 193 Sami Boutros 194 VMware 195 Email: sboutros@vmware.com 197 Ankur Dubey 198 VMware 199 Email: adubey@vmware.com 201 Reshad Rahman 202 Cisco 203 Email: rrahman@cisco.com