Load-Balancing for Mesh Softwires
draft-ietf-softwire-lb-03

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    softwire mailing list <softwires@ietf.org>, 
    softwire chair <softwire-chairs@tools.ietf.org>
Subject: Protocol Action: 'Load Balancing for Mesh Softwires' to Proposed Standard

The IESG has approved the following document:

- 'Load Balancing for Mesh Softwires '
   <draft-ietf-softwire-lb-03.txt> as a Proposed Standard


This document is the product of the Softwires Working Group. 

The IESG contact persons are Ralph Droms and Jari Arkko.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-softwire-lb-03.txt

Ballot Text

Technical Summary

   Payloads carried over a Softwire mesh service as defined by BGP
   Encapsulation Subsequent Address Family Identifier (SAFI)
   information exchange often carry a number of identifiable, distinct
   flows. It can in some circumstances be desirable to distribute
   these flows over the equal cost multiple paths (ECMPs) that exist
   in the packet switched network. Currently, the payload of a packet
   entering the Softwire can only be interpreted by the ingress and
   egress routers.  Thus the load balancing decision of a core router
   is only based on the encapsulating header, presenting much less
   entropy than available in the payload or the encapsulated header
   since the Softwire encapsulation acts in a tunneling fashion. This
   document describes a method for achieving comparable load balancing
   efficiency in a network carrying Softwire mesh service over Layer
   Two Tunneling Protocol - Version 3 (L2TPv3) over IP or Generic
   Routing Encapsulation (GRE) encapsulation to what would be achieved
   without such encapsulation.

Working Group Summary

   The SOFTWIRE WG supports the development and advancement of this
   document. 

Document Quality

   This document was thoroughly reviewed by WG chairs and WG members,
   including those with expertise in IPv4 to IPv6 transitions and
   interworking. 

Personnel

   David Ward (dward@cisco.com) is the document shepherd.
   Ralph Droms (rdroms@cisco.com) is the responsible Area Director.

RFC Editor Note

Expanding section 4, Security Considerations:

OLD:

   There are no additional security risks introduced by this design.

NEW:

   This document defines a new sub-TLV for the BGP Tunnel Encapsulation
   Attribute.  Security considerations for the BGP Encapsulation SAFI
   and the BGP Tunnel Encapsulation Attribute are covered in [RFC5512].
   There are no additional security risks introduced by this design.

RFC Editor Note