<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.ietf-idr-encaps-safi" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-encaps-safi-00">
   <front>
      <title>BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute</title>
      <author initials="E. C." surname="Rosen" fullname="Eric C. Rosen">
         <organization>Cisco Systems</organization>
      </author>
      <author initials="P." surname="Mohapatra" fullname="Prodosh Mohapatra">
         <organization>Cisco Systems</organization>
      </author>
      <date month="August" day="31" year="2007" />
      <abstract>
	 <t>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 &quot;encapsulation information&quot;, 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
   &quot;Encapsulation SAFI&quot; 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.
	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-idr-encaps-safi-00" />
   
</reference>
