Skip to main content

BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute
draft-ietf-idr-encaps-safi-00

Document Type Expired Internet-Draft (idr WG)
Expired & archived
Authors Eric C. Rosen , Prodosh Mohapatra
Last updated 2007-08-31
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Expired
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

Abstract

In certain situations, transporting a packet from one 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 the cases where the signaling is required (such as L2TPv3, GRE with key), This draft 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 SAFI" and IPv4 or IPv6 AFI. In the cases where no encapsulation information needs to be signaled (such as GRE without key), this draft specifies a BGP extended community that can be attached to UPDATE messages that carry payload prefixes to indicate the encapsulation protocol type to be used.

Authors

Eric C. Rosen
Prodosh Mohapatra

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)