The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, softwire mailing list <email@example.com>, softwire chair <firstname.lastname@example.org> Subject: Protocol Action: 'BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute' to Proposed Standard The IESG has approved the following document: - 'BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute ' <draft-ietf-softwire-encaps-safi-05.txt> as a Proposed Standard This document is the product of the Softwires Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-encaps-safi-05.txt
Technical Summary 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 the cases where the signaling is required (such as Layer Two Tunneling Protocol - Version 3 (L2TPv3), Generic Routing Encapsulation (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 Subsequent Address Family Identifier (SAFI)" and IPv4 or IPv6 Address Family Identifier (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 BGP UPDATE messages that carry payload prefixes to indicate the encapsulation protocol type to be used. Working Group Summary The SOFTWIRE WG supports the development and advancement of this document. Protocol Quality This document was thoroughly reviewed by WG chairs and WG members, including those with expertise in IPv4 to IPv6 transitions and interworking.