idnits 2.17.1 draft-mmsn-bfd-on-lags-address-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 abstract seems to contain references ([BFD-ON-LAGS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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: De-multiplexing received BFD packets MUST not rely on destination address in the IP header. -- The document date (February 9, 2012) is 4450 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: 'RFC5882' is defined on line 171, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BFD-ON-LAGS' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bhatia 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track M. Binderberger 5 Expires: August 12, 2012 S. Boutros 6 N. Akiya 7 Cisco Systems, Inc. 8 February 9, 2012 10 IP Address Schemes for Bidirectional Forwarding Detection (BFD) on Link 11 Aggregation Group (LAG) Interfaces 12 draft-mmsn-bfd-on-lags-address-00 14 Abstract 16 This document describes techniques which can be used by a router to 17 obtain or discover remote neighbor IP address in order to establish 18 micro Bidirectional Forwarding Detection (BFD) sessions 19 [BFD-ON-LAGS]. 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 August 12, 2012. 44 Copyright Notice 46 Copyright (c) 2012 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 1. Introduction 61 [BFD-ON-LAGS] proposes a mechanism to run BFD on Link Aggregation 62 Group (LAG) interfaces. It does so by running an independent BFD 63 asynchronous session on each LAG member link. Transmitted BFD 64 packets will need to have neighbor IP address as the destination 65 address in the IP header. However, the exact mechanism by which a 66 router obtains the remote neighbor IP address is outside the scope of 67 [BFD-ON-LAGS]. This document describes a few mechanisms which can be 68 used by a router to discover the remote neighbor IP address in order 69 to run micro BFD sessions [BFD-ON-LAGS]. 71 2. Source IP Address 73 The source IP address in the IP header is the IP address configured 74 on the LAG for all BFD packets sent on a micro BFD session. This is 75 the case for all options described. 77 3. Remote Neighbor IP Address Discovery Mechanisms 79 Routers can use two different techniques to learn the remote neighbor 80 IP address to be used as the destination IP address for micro BFD 81 sessions. In the first approach, the destination IP address is 82 explicitly configured. In the second, the remote neighbor IP address 83 is learnt by automatic discovery. We define two distinct mechanisms 84 that can be used for automatic discovery. This following sections 85 describe the different mechanisms that can be employed for obtaining 86 the remote neighbor address for micro BFD sessions. 88 3.1. Explicit Configuration (Option 1) 90 This neighbor IP address is a mandatory configuration, and 91 destination address in the IP header of transmitted BFD packets is 92 solely controlled by this configuration. Micro BFD sessions MUST NOT 93 transmit any packets if this configuration has not been specified. 95 3.2. Auto-Discovery Using Multicast Address (Option 2a) 97 Neighbor IP address is not configured. Instead, micro BFD sessions 98 MUST use a well-known link-local multicast IP address (224.0.0.X for 99 IPv4, FF02::X for IPv6, to be assigned by IANA) as destination 100 address in the IP header. Initial BFD packet exchanges will take 101 place this way. BFD packets received will have IP address assigned 102 on the LAG as source address in the IP header. Each router will 103 discover the remote IP address by examining the source IP in micro 104 BFD session packets. When transitioning into INIT or UP states, 105 discovered neighbor IP address MUST be used as destination address in 106 the IP header. Micro BFD sessions are to proceed as described in 107 [RFC5880] and [BFD-ON-LAGS]. When a micro BFD session needs to start 108 over the session bring-up logic, destination address in the IP header 109 MUST be reset to a well-known link-local multicast IP address. If a 110 node detects that source address in the IP header of latest received 111 BFD packets differs from known neighbor IP address, then a node MUST 112 respect the latest address as neighbor IP address. Destination 113 address in the IP header of transmitted BFD packets are to get 114 reflected of the address change. 116 3.3. Auto-Discovery Using Loopback Address (Option 2b) 118 Most of the logic and the rules used in this mechanism are same as 119 the preceding option (option 2a). The only difference we use a 120 loopback address (127/8 for IPv4, 0:0:0:0:0:FFFF:7F00/104 for IPv6) 121 instead of a well-known link-local multicast IP address for the 122 initial BFD packets over the micro BFD sessions. 124 4. Interoperability 126 Ideally, two nodes connecting [BFD-ON-LAGS] enabled LAG are to use 127 same neighbor address discovery option described. However, all 128 described options can interoperate with each other, as long as 129 following rules, described in this section, are honored. Vendors 130 implementing the mechanisms described in this document SHOULD 131 implement with following rules considered. 133 4.1. Packet De-multiplexing (Rule 1) 135 De-multiplexing received BFD packets MUST not rely on destination 136 address in the IP header. 138 4.2. Packet Accepted (Rule 2) 140 A node MUST be implemented to allow and accept BFD packets with 141 unicast , well-known link-local multicast and loopback IP address. 143 5. IANA Considerations 145 The IANA is requested to assign a well-known link-local multicast IP 146 address: 224.0.0.X for IPv4 and FF02::X for IPv6. 148 6. Security Considerations 150 The proposal introduced in this document does not introduce any new 151 security considerations beyond that already apply to the base BFD 152 specification [RFC5880] and [RFC5881]. 154 7. Normative References 156 [BFD-ON-LAGS] 157 Bhatia, M., Chen, M., Boutros, S., Binderberger, M., and 158 J. Haas, "Bidirectional Forwarding Detection (BFD) on Link 159 Aggregation Group (LAG) Interfaces", February 2012. 161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 162 Requirement Levels", BCP 14, RFC 2119, March 1997. 164 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 165 (BFD)", RFC 5880, June 2010. 167 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 168 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 169 June 2010. 171 [RFC5882] Katz, D. and D. Ward, "Generic Application of 172 Bidirectional Forwarding Detection (BFD)", RFC 5882, 173 June 2010. 175 Authors' Addresses 177 Manav Bhatia 178 Alcatel-Lucent 179 Bangalore 560045 180 India 182 Email: manav.bhatia@alcatel-lucent.com 183 Marc Binderberger 184 Cisco Systems, Inc. 185 Rolle 186 Switzerland 188 Email: mbinderb@cisco.com 190 Sami Boutros 191 Cisco Systems, Inc. 192 San Jose 193 USA 195 Email: sboutros@cisco.com 197 Nobo Akiya 198 Cisco Systems, Inc. 199 Tokyo 200 Japan 202 Email: nobo@cisco.com