[Softwires] Protocol Action: 'Load Balancing for Mesh Softwires' to Proposed Standard
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Softwires] 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
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 at cisco.com) is the document shepherd.
Ralph Droms (rdroms at 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.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.