Network Working Group P. Mohapatra
Request for Comments: 5512 E. Rosen
Category: Standards Track Cisco Systems, Inc.
April 2009
The BGP Encapsulation Subsequent Address Family Identifier (SAFI)
and the BGP Tunnel Encapsulation Attribute
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
In certain situations, transporting a packet from one Border Gateway
Protocol (BGP) speaker to another (the BGP next hop) requires that
the packet be encapsulated by the first BGP speaker and decapsulated
by the second. To support these situations, there needs to be some
agreement between the two BGP speakers with regard to the
"encapsulation information", i.e., the format of the encapsulation
header as well as the contents of various fields of the header.
The encapsulation information need not be signaled for all
encapsulation types. In cases where signaling is required (such as
Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic Routing
Encapsulation (GRE) with key), this document specifies a method by
which BGP speakers can signal encapsulation information to each
other. The signaling is done by sending BGP updates using the
Encapsulation Subsequent Address Family Identifier (SAFI) and the
IPv4 or IPv6 Address Family Identifier (AFI). In cases where no
encapsulation information needs to be signaled (such as GRE without
Mohapatra & Rosen Standards Track [Page 1]RFC 5512 BGP Encapsulation SAFI and Tunnel Encapsulation April 2009
key), this document specifies a BGP extended community that can be
attached to BGP UPDATE messages that carry payload prefixes in order
to indicate the encapsulation protocol type to be used.
Table of Contents
1. Introduction ....................................................2
2. Specification of Requirements ...................................4
3. Encapsulation NLRI Format .......................................4
4. Tunnel Encapsulation Attribute ..................................5
4.1. Encapsulation sub-TLV ......................................6
4.2. Protocol Type Sub-TLV ......................................7
4.3. Color Sub-TLV ..............................................8
4.3.1. Color Extended Community ............................8
4.4. Tunnel Type Selection ......................................8
4.5. BGP Encapsulation Extended Community .......................9
5. Capability Advertisement .......................................10
6. Error Handling .................................................10
7. Security Considerations ........................................10
8. IANA Considerations ............................................10
9. Acknowledgements ...............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
1. Introduction
Consider the case of a router R1 forwarding an IP packet P. Let D be
P's IP destination address. R1 must look up D in its forwarding
table. Suppose that the "best match" route for D is route Q, where Q
is a BGP-distributed route whose "BGP next hop" is router R2. And
suppose further that the routers along the path from R1 to R2 have
entries for R2 in their forwarding tables, but do NOT have entries
for D in their forwarding tables. For example, the path from R1 to
R2 may be part of a "BGP-free core", where there are no BGP-
distributed routes at all in the core. Or, as in [MESH], D may be an
IPv4 address while the intermediate routers along the path from R1 to
datatracker.ietf.org