Internet DRAFT - draft-mmsn-bfd-on-lags-address
draft-mmsn-bfd-on-lags-address
Network Working Group M. Bhatia
Internet-Draft Alcatel-Lucent
Intended status: Standards Track M. Binderberger
Expires: August 12, 2012 S. Boutros
N. Akiya
Cisco Systems, Inc.
February 9, 2012
IP Address Schemes for Bidirectional Forwarding Detection (BFD) on Link
Aggregation Group (LAG) Interfaces
draft-mmsn-bfd-on-lags-address-00
Abstract
This document describes techniques which can be used by a router to
obtain or discover remote neighbor IP address in order to establish
micro Bidirectional Forwarding Detection (BFD) sessions
[BFD-ON-LAGS].
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 12, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bhatia, et al. Expires August 12, 2012 [Page 1]
Internet-Draft IP Addr Schemes for BFD on LAGs February 2012
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
[BFD-ON-LAGS] proposes a mechanism to run BFD on Link Aggregation
Group (LAG) interfaces. It does so by running an independent BFD
asynchronous session on each LAG member link. Transmitted BFD
packets will need to have neighbor IP address as the destination
address in the IP header. However, the exact mechanism by which a
router obtains the remote neighbor IP address is outside the scope of
[BFD-ON-LAGS]. This document describes a few mechanisms which can be
used by a router to discover the remote neighbor IP address in order
to run micro BFD sessions [BFD-ON-LAGS].
2. Source IP Address
The source IP address in the IP header is the IP address configured
on the LAG for all BFD packets sent on a micro BFD session. This is
the case for all options described.
3. Remote Neighbor IP Address Discovery Mechanisms
Routers can use two different techniques to learn the remote neighbor
IP address to be used as the destination IP address for micro BFD
sessions. In the first approach, the destination IP address is
explicitly configured. In the second, the remote neighbor IP address
is learnt by automatic discovery. We define two distinct mechanisms
that can be used for automatic discovery. This following sections
describe the different mechanisms that can be employed for obtaining
the remote neighbor address for micro BFD sessions.
3.1. Explicit Configuration (Option 1)
This neighbor IP address is a mandatory configuration, and
destination address in the IP header of transmitted BFD packets is
solely controlled by this configuration. Micro BFD sessions MUST NOT
transmit any packets if this configuration has not been specified.
Bhatia, et al. Expires August 12, 2012 [Page 2]
Internet-Draft IP Addr Schemes for BFD on LAGs February 2012
3.2. Auto-Discovery Using Multicast Address (Option 2a)
Neighbor IP address is not configured. Instead, micro BFD sessions
MUST use a well-known link-local multicast IP address (224.0.0.X for
IPv4, FF02::X for IPv6, to be assigned by IANA) as destination
address in the IP header. Initial BFD packet exchanges will take
place this way. BFD packets received will have IP address assigned
on the LAG as source address in the IP header. Each router will
discover the remote IP address by examining the source IP in micro
BFD session packets. When transitioning into INIT or UP states,
discovered neighbor IP address MUST be used as destination address in
the IP header. Micro BFD sessions are to proceed as described in
[RFC5880] and [BFD-ON-LAGS]. When a micro BFD session needs to start
over the session bring-up logic, destination address in the IP header
MUST be reset to a well-known link-local multicast IP address. If a
node detects that source address in the IP header of latest received
BFD packets differs from known neighbor IP address, then a node MUST
respect the latest address as neighbor IP address. Destination
address in the IP header of transmitted BFD packets are to get
reflected of the address change.
3.3. Auto-Discovery Using Loopback Address (Option 2b)
Most of the logic and the rules used in this mechanism are same as
the preceding option (option 2a). The only difference we use a
loopback address (127/8 for IPv4, 0:0:0:0:0:FFFF:7F00/104 for IPv6)
instead of a well-known link-local multicast IP address for the
initial BFD packets over the micro BFD sessions.
4. Interoperability
Ideally, two nodes connecting [BFD-ON-LAGS] enabled LAG are to use
same neighbor address discovery option described. However, all
described options can interoperate with each other, as long as
following rules, described in this section, are honored. Vendors
implementing the mechanisms described in this document SHOULD
implement with following rules considered.
4.1. Packet De-multiplexing (Rule 1)
De-multiplexing received BFD packets MUST not rely on destination
address in the IP header.
4.2. Packet Accepted (Rule 2)
A node MUST be implemented to allow and accept BFD packets with
unicast , well-known link-local multicast and loopback IP address.
Bhatia, et al. Expires August 12, 2012 [Page 3]
Internet-Draft IP Addr Schemes for BFD on LAGs February 2012
5. IANA Considerations
The IANA is requested to assign a well-known link-local multicast IP
address: 224.0.0.X for IPv4 and FF02::X for IPv6.
6. Security Considerations
The proposal introduced in this document does not introduce any new
security considerations beyond that already apply to the base BFD
specification [RFC5880] and [RFC5881].
7. Normative References
[BFD-ON-LAGS]
Bhatia, M., Chen, M., Boutros, S., Binderberger, M., and
J. Haas, "Bidirectional Forwarding Detection (BFD) on Link
Aggregation Group (LAG) Interfaces", February 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
June 2010.
[RFC5882] Katz, D. and D. Ward, "Generic Application of
Bidirectional Forwarding Detection (BFD)", RFC 5882,
June 2010.
Authors' Addresses
Manav Bhatia
Alcatel-Lucent
Bangalore 560045
India
Email: manav.bhatia@alcatel-lucent.com
Bhatia, et al. Expires August 12, 2012 [Page 4]
Internet-Draft IP Addr Schemes for BFD on LAGs February 2012
Marc Binderberger
Cisco Systems, Inc.
Rolle
Switzerland
Email: mbinderb@cisco.com
Sami Boutros
Cisco Systems, Inc.
San Jose
USA
Email: sboutros@cisco.com
Nobo Akiya
Cisco Systems, Inc.
Tokyo
Japan
Email: nobo@cisco.com
Bhatia, et al. Expires August 12, 2012 [Page 5]
