[Softwires] Protocol Action: 'BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute' to Proposed Standard

The IESG <iesg-secretary@ietf.org> Wed, 11 March 2009 15:17 UTC

Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: softwires@ietf.org
Delivered-To: softwires@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id EEA7B3A69C4; Wed, 11 Mar 2009 08:17:06 -0700 (PDT)
X-idtracker: yes
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <20090311151706.EEA7B3A69C4@core3.amsl.com>
Date: Wed, 11 Mar 2009 08:17:06 -0700
Cc: softwire mailing list <softwires@ietf.org>, Internet Architecture Board <iab@iab.org>, softwire chair <softwire-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Softwires] Protocol Action: 'BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute' to Proposed Standard
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2009 15:17:07 -0000

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.