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

[Ballot discuss]
The discussion of the Gen-ART Review by Avshalom Houri lead to a
  rewrite of the security considerations section.  The document does
  not reflect this update, and there is not an RFC Editor note in
  the tracker to update the text.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following assignment in
the "bgp-parameters" registry, in the sub-registry named "BGP Tunnel
Encapsulation Attribute Sub-TLVs" located at
:

Value = 5
Name = Load Balancing Block
Reference = [RFC-softwire-lb-03]

PROTO questionnaire for: draft-ietf-softwire-lb-03
> Intended status: Standards Track
> Prepared by: Dave Ward (dward@cisco.com)
>
>
> 1.a) Have the chairs personally reviewed this version of the Internet
> Draft (ID), and in particular, do they believe this ID is ready
> to forward to the IESG for publication? Which chair is the WG
> Chair Shepherd for this document?
>
> Yes. Dave Ward will be the WG Document Shepherd for this document.
>
>
> 1.b) Has the document had adequate review from both key WG members
> and key non-WG members? Do you have any concerns about the
> depth or breadth of the reviews that have been performed?
>
> The document has been reviewed in the softwire WG, and its WG Last
> Call
> was cross-posted to the softwire, L3VPN and PWE3 Workign Groups
> mailing
> lists. All review comments have been adequately addressed.
> There are no concerns about the extent of the reviews.
>
>
> 1.c) Do you have concerns that the document needs more review from a
> particular (broader) perspective (e.g., security, operational
> complexity, someone familiar with AAA, internationalization,
> XML, etc.)?
>
> No.
>
>
> 1.d) Do you have any specific concerns/issues with this document that
> you believe the ADs and/or IESG should be aware of? For
> example, perhaps you are uncomfortable with certain parts of the
> document, or have concerns whether there really is a need for
> it. In any event, if your issues have been discussed in the WG
> and the WG has indicated it that it still wishes to advance the
> document, detail those concerns in the write-up.
>
> No.
> All concerns raised in the softwire meetings and mailing list have
> been
> addressed in the revision -03 of the document. To my knowledge, there
> aren't any outstanding issues or concerns.
>
>
> 1.e) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with
> others being silent, or does the WG as a whole understand and
> agree with it?
>
> There is strong WG consensus behind this document and no one that has
> expressed concerns about its progression.
>
>
> 1.f) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email to the Responsible Area Director. (It should be
> separate email because this questionnaire will be entered into
> the tracker).
>
> No.
>
>
> 1.g) Have the chairs verified that the document checks out against
> all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
> Boilerplate checks are not enough; this check needs to be
> thorough.
>
> Yes. The document checks idnits without any issues found.
>
>
> 1.h) Has the document split its references into normative and
> informative? Are there normative references to IDs, where the
> IDs are not also ready for advancement or are otherwise in an
> unclear state? The RFC Editor will not publish an RFC with
> normative references to IDs (will delay the publication until
> all such IDs are also ready for RFC publicatioin). If the
> normative references are behind, what is the strategy for their
> completion? On a related matter, are there normative references
> that are downward references, as described in BCP 97, RFC 3967
> RFC 3967 [RFC3967]? Listing these supports the Area Director in
> the Last Call downref procedure specified in RFC 3967.
>
> The document only contains Normative references. So there is a
> single References section explicitly marked "Normative".
> All the normative references are to published PS and BCP RFCs.
> No downrefs and no references to IDs.
>
>
>
> Protocol write-up for: draft-ietf-softwire-lb-03
> by Dave Ward, dward@cisco.com
>
> 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.
>
>
> Protocol Quality
>
> This document was thoroughly reviewed by WG chairs and WG members,
> including those with expertise in IPv4 to IPv6 transitions and
> interworking.
>
> Dave Ward is the WG chair shepherd.
> Ralph Droms is the responsible Area Director.