Internet DRAFT - draft-suping-bfd-bgp-static-app
draft-suping-bfd-bgp-static-app
BFD Working Group Suping Zhai
Internet Draft Huawei Techonologies Co., Ltd.
Expires: December 2005 Xiaodong Duan
Lianyuan Li
China Mobile Communications Corporation
draft-suping-bfd-bgp-static-app-02.txt
BFD initializtion with BGP and static routes
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes the use of the Bidirectional Forwarding
Detection protocol with BGP and the static route over IPv4 or IPv6.
The main purpose of this draft is to solve the BFD bootstrap problem
with BGP and static routes. As to the encapsulation and
demultiplexing issues there have been descriptions in BFD single hop
draft [BFD-1HOP] and multi-hop draft [BFD-MULI]. With the BFD
interaction with BGP graceful restart, the rules described in BFD
single hop [BFD-1HOP] with IS-IS and OSPF graceful restart are also
applicable to the BFD with BGP graceful restart, and will not
iteratein in this draft.
Comments on this draft should be directed to rtg-bfd@ietf.org or
to author directly.
Conventions used in this document
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 [KEYWORDS].
Suping et al. [Page 1]
Internet Draft draft-suping-bfd-bgp-static-app-02.txt June, 2005
1 Introduction
One very desirable application for BFD [BFD] is to track IPv4 and
IPv6 connectivity between directly-connected systems. There are
two kinds of directly-connected systems, inter-AS and intra-AS
systems. For the BFD application in the intra-AS system there have
been single hop draft [BFD-1HOP] and multihop paths draft
[BFD-MULTI]. This document is to resolve the BFD initialization in
the inter-AS systems, especially BFD application with BGP. With the
BFD in static route over IPv4 or IPv6, there need management
configuration to bootstrap the BFD session, this document also list
some parameters should be configured to startup the BFD session.
2 Use BFD with BGP
The Border Gateway Protocol [BGP] is an inter-Autonomous System
routing protocol. BGP uses TCP [TCP] as its transport protocol.
TCP meets BGP's transport requirements and is present in virtually
all commercial routers and hosts.
BGP KEEPALIVE messages can be used to detect the path between
the BGP peers, but the granularity of failure detection time is
minimum two seconds. For the data plane today of Giga bit interface
this detection time will cause many traffic to be lost. So the
faster detection mechnism is needed in the data plane. BFD can
be used to verify the forwarding ability of an BGP router's
adjacencies for this purpose.
It should be noted that the purpose of using BFD in this context is
not to replace the adjacency timeout mechanism, nor is it to
demonstrate that the network is fully functional for the use of the
routing protocol, but is simply to advise the routing protocol that
there are problems forwarding the data protocol for which the BGP
session is running.
2.1 Initialization
When use BFD with BGP, this document lists two choices to bootstrap
BFD session as followings. And which mechanism is used in
implementation is out of the scope of this document.
2.1.1 BFD capabilities advertisement in BGP OPEN message
In the BGP protocol OPEN message, there is an Optional Parameters
field can contain a list of optional parameters, where each parameter
is endcode as a <Parameter Type, Parameter Length, Parameter Value>
triplet. In the document [BGP] Parameter Type 1 has been defined
for Authentication Information. And in document [BGP-CAP] there is
another definition about Parameter Type 2 for capabilities
advertisement. The parameter contains one or more triples <Capability
Code, Capability Length, Capability Value>, where each triple is
encoded as shown below:
Suping et al. [Page 2]
Internet Draft draft-suping-bfd-bgp-static-app-02.txt June, 2005
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
+------------------------------+
Here we use a new Capability code to indicate the BFD capability, the
code value is TBD. The Capability Length is 4, and Capability value
is the My Discriminator assigned by the BGP speaker and this
discriminator will used as the demultiplexing in the following BFD
session. If BFD capability advertisement is not presented in the
BGP OPEN message, it is not precluded that BFD discriminator
initializtion is supported by other means e.g. through static
configuration as shown in the 2.1.2 section.
Note that it is possible in some failure scenarios for the network to
be in a state such that the BGP comes up, but the BFD session cannot
be established, and, more particularly, some data cannot be
forwarded. For example in some situation TCP traffic can be forwarded
but UDP traffic can't forwarded. To avoid this situation, it would be
beneficial to not allow the BGP speaker to establish the session with
the BGP peer until the BFD session is up. However, this would
preclude the operation of the BGP in an environment in which not all
systems support BFD.
Therefore, if a BFD session is not in Up state (possibly because the
remote system does not support BFD), it is OPTIONAL to preclude the
establishment of an BGP session with the BGP peer. The choice
of whether to do so SHOULD be controlled by means outside the scope
of this specification, such as configuration or other mechanisms.
protocol.
2.1.2 Configuration manually
For the simplicity in the small scale network, it may be configured
manually to provide the necessary parameters to start up the BFD
session. The first my discriminator for demultiplexing BFD session
is needed to configured in the source/end host or router over which
the BFD session is to be running. The second if the BFD session is
enabled also needed to be configured. Then the system can run BFD
if necessary.
3 BFD initialization with static route
3.1 Initialization by configuration manually
When use BFD in the situation of static routes, there is no dedicated
route protocol can be used to bootstrap BFD session.
The simple way to start up BFD session is through the configuration.
My Discriminator for demultiplexing BFD session is needed to
configured in the source/end host or router over which the BFD
Suping et al. [Page 3]
Internet Draft draft-suping-bfd-bgp-static-app-02.txt June, 2005
session is to be running. Whether the BFD session enabled on
the system is also needed to be configured. Then the system can
start BFD session if necessary according to the configuration
parameters.
4 BFD Encapsulation and Demultiplexing with BGP and static routes
According to the BFD single hop draft [BFD-1HOP] the BFD payload
is encoded in the UDP packet. To consist with the [BFD-1HOP] and
when in the inter-AS environment and static routes, the BFD is
also encoded in UDP packet. BFD using UDP can be simple because
no requirment of retransmission, acknowledgement and sequencing.
As to the demultiplex, to align with the single-hop draft [BFD-1HOP]
and the multi-hop draft [BFD-MULTI], BFD session with one hop BGP
or static routes should be demultiplexed based on the interface
and in the multi-hop BGP or static routes BFD sessions can be
demultiplexed based on source/destination address pairs.
5 Security Considerations
As BFD applied in the BGP peer system, it is encouraged to use BFD
authentication functions to avoid BFD abuse. Considering BGP itself
has the security mechanisms, when use BGP OPEN message to start up
the BFD, it's not mandatory to have authentication in BFD session.
When use BFD with static routes, it's option to use BFD
authentication functions.
Normative References
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-02.txt, March, 2005
[BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single
Hop)", draft-ietf-bfd-v4v6-1hop-02.txt, March, 2005
[BFD-MULTI] D. Katz, and D. Ward, "BFD for Multihop Paths", draft
-ietf-bfd-multihop-02.txt, March, 2005
[BFD-LSP] Rahul Aggarwal et al, "BFD For MPLS LSPs", draft-ietf
-bfd-mpls-01.txt, expired date August 2005
[TCP] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", STD 7, RFC 793, DARPA,
September 1981
[BGP] Y. Rekhter, "A Border Gateway Protocol 4 (BGP-4)", RFC1771,
March 1995
[BGP-CAP] R. Chandra et al, "Capabilities Advertisement with BGP-4",
RFC3992, November 2002
[BGP-RESTART] Srihari R. Sangli et al, draft-ietf-idr-restart-10.txt,
expired date December 2004
Suping et al. [Page 4]
Internet Draft draft-suping-bfd-bgp-static-app-02.txt June, 2005
Author's Addresses
Suping Zhai
Huawei Technologies Co., LTD.
No. 3 Xinxi Road, Shangdi,
HaiDian District,
Beijing City,
The P.R.China
Email: zhaisuping@huawei.com
Xiaodong Duan
Lianyuan Li
China Mobile Communications Corporation
53A, Xibianmenneir Ave,
Xuanwu District,
Beijing City,
The P.R.China
Email: duanxiaodong@chinamobile.com
lilianyuan@chinamobile.com
Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Suping et al. [Page 5]
Internet Draft draft-suping-bfd-bgp-static-app-02.txt June, 2005
