[Softwires] RFC 5512 on The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute

A new Request for Comments is now available in online RFC libraries.

        RFC 5512

        Title:      The BGP Encapsulation Subsequent Address 
                    Family Identifier (SAFI) and the BGP 
                    Tunnel Encapsulation Attribute 
        Author:     P. Mohapatra, E. Rosen
        Status:     Standards Track
        Date:       April 2009
        Mailbox:    pmohapat@cisco.com, 
                    erosen@cisco.com
        Pages:      13
        Characters: 30554
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-softwire-encaps-safi-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5512.txt

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
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.  [STANDARDS TRACK]

This document is a product of the Softwires Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: 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.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute