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]