Andy, The current is 11. I got the filenames 12-preview1 and 12-preview2 right but in the file 12-preview1 the document says 11-preview1. Please ignore that mistake.
There are two previews because if anyone wants to see the differnces between the text before the changes and after the changes, diff would not work if the requirements text was both reordered and changed. The solution to make the diffs work is to first reorder the requirements text without changing the text and save that as preview1, then make the changes to the text and add any new text and save that as preview2. This is done only to make it easy for the reader to find the new text and find the changes to existing text. If there is no need for further change, 12-preview2 would be submitted as draft-ietf-rtgwg-cl-requirement-12 with a filename and date change. If there is need for change and a need for pre-submit review of changes, then there would be a 12-preview3 before submitting 12. Curtis In message <ce7ac98b.4c244%[email protected]> "Malis, Andrew G (Andy)" writes: Curtis, OK, I'll admit to being confused. The current revision is -11. However, the first of your two preview files says draft-ietf-rtgwg-cl-requirement-11-preview1 at the top. So it is an old preview of 11? A halfway point to -12? And why two previews? Thanks, Andy On 10/8/2013 23:19 , "Curtis Villamizar" <[email protected]> wrote: RTGWG, Two preview versions were created to make it easier to see differences. draft-ietf-rtgwg-cl-requirement-12-preview1 This first preview contains no edits except to rearrange the set of paragraphs and bullets and create new sections. The section naming is not quite as suggested below. The prior subsection 3.3 is broken into these three subsections. 3.3. Component Links with Different Characteristics 3.4. Considerations for Bidirectional Client LSP 3.5. Multipath Load Balancing Dynamics Note that the old FR#10 was deleted as noted below, being deemed as redundant if the old FR#17 and FR#18 mention meeting Performance Objectives. draft-ietf-rtgwg-cl-requirement-12-preview2 In this preview none of the requirements are reordered. Instead, the contents of the bullets and paragraphs are edited. The edits are mostly as described below. Additional edits are: 1. s/ITU/ITU-T/ in a few places. (request by Loa) 2. The document has been spell checked. 3. Wording in one paragraph in the intro section had to be changed to reflect the section renaming. It was improved a bit. 4. s/1 ms/1 msec/ 5. Added paragraph(s) before the list of requirements in each of the new subsections to indicate the purpose of the set of requirements. Added paragraph(s) after the list of requirements with discussion, generally providing caveats. These new paragraphs are generally in line with discussion below but were not explicitly cited as changes below. 6. The requirement now numbered FR#15 was reworded. OLD The solution SHALL provide a means that communicates whether the flows within an client LSP can be split across multiple component links. The solution SHOULD provide a means to indicate the flow identification field(s) which can be used along the flow path which can be used to perform this function. NEW The solution SHALL provide a means that indicates whether any of the flows within an client LSP MUST NOT be split across multiple component links. The sense is reversed (identify those sensitive to load balancing rather than those insensitive to it). The entire client LSP is treated the same (either balanced or not). Signaling enhancement to identify flows within the client LSP is no longer called for. 7. FR#16 refers to "prior requirements in Section 3.3" rather than just "prior requirements". 8. s/nodes (or sites)/nodes/ (only occurance of sites) 9. s/bounded by a configured value/bounded by a specific value/ (it could be signaled or configured, decide in the framework) 10. In FR#21, the reminder of the definition of "flows" is removed (not needed). 11. First paragraph in renamed section "General Requirements for Protocol Solutions" is edited to reflect the discussion below regarding the renaming. Other changes described in detail below were made. Both versions are available at these URLs. http://www.occnc.com/draft-ietf-rtgwg-cl-requirement-12-preview1.txt http://www.occnc.com/draft-ietf-rtgwg-cl-requirement-12-preview2.txt The two versions can be diffed using the IETF diff tool. Either go to the URL http://tools.ietf.org/rfcdiff and type in the two URLs above or paste in the following (eliminating white space, making one line). http://tools.ietf.org/rfcdiff ?url1=http://www.occnc.com/draft-ietf-rtgwg-cl-requirement-12-preview1.txt &url2=http://www.occnc.com/draft-ietf-rtgwg-cl-requirement-12-preview2.txt It is also possible to diff the -11 version and either preview version with this tool, but due to the reordering of requirements and new sections, this diff doesn't work well. Using the diff tool on the two preview versions is a good way to see only the changes that were made. Please also reread the document. This is a WG doc and RTGWG should be providing the AD and IESG with a high quality document. More review at this stage is better. Curtis ------- Forwarded Message Return-Path: [email protected] Delivery-Date: Mon Oct 7 17:38:25 2013 Return-Path: <[email protected]> Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) by harbor1.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id r97LcPEG091422 for <[email protected]>; Mon, 7 Oct 2013 17:38:25 -0400 (EDT) (envelope-from [email protected]) Received: (from curtis@localhost) by harbor1.ipv6.occnc.com (8.14.5/8.14.5/Submit) id r97LcPpU091420 for curtis; Mon, 7 Oct 2013 17:38:25 -0400 (EDT) (envelope-from [email protected]) Received: from maildrop0.ipv6.occnc.com [2001:470:1f07:1545::2:830] by harbor1.ipv6.occnc.com with IMAP (fetchmail-6.3.21) for <curtis@localhost> (single-drop); Mon, 07 Oct 2013 17:38:25 -0400 (EDT) Received: from deliver ([unix socket]) by maildrop0.ipv6.occnc.com (Cyrus v2.4.16) with LMTPA; Mon, 07 Oct 2013 14:09:44 -0400 X-Sieve: CMU Sieve 2.4 Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:123a::1:1e]) by maildrop0.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id r97I9dQ7087297 for <[email protected]>; Mon, 7 Oct 2013 14:09:44 -0400 (EDT) (envelope-from [email protected]) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA1E21E80BA; Mon, 7 Oct 2013 11:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1381169373; bh=pz9B3Q/VoFV3XJrB1+4MiatTdgEQFiAYrq9GfGqAq18=; h=Message-Id:To:From:Subject:In-reply-to:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=R4sRGOfdY4RZS8CamMpIrLP81JBgUfayzhrTkK/rdqCa9U/FBFYCyRO4q1t6qiEfA G+n3aAwAA3icSJVXnTduUDbkI+NNZQt5Unh1YRqxIY2M6qkBY/7x5FG1o5k7xhe0Ou qshOUJJVhwcATdqXTyN/I4jf1xyNY5kalDlhy9K0= X-Original-To: [email protected] Delivered-To: [email protected] Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7240621E81B2 for <[email protected]>; Mon, 7 Oct 2013 11:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Score: -0.495 X-Spam-Level: Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjwLNrLPIpfn for <[email protected]>; Mon, 7 Oct 2013 11:09:17 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 550C911E8102 for <[email protected]>; Mon, 7 Oct 2013 11:09:13 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r97I6eeV070034; Mon, 7 Oct 2013 14:06:40 -0400 (EDT) (envelope-from [email protected]) Message-Id: <[email protected]> To: Alia Atlas <[email protected]> From: Curtis Villamizar <[email protected]> Subject: Re: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 In-reply-to: Your message of "Tue, 01 Oct 2013 17:38:14 EDT." <cag4d1re-0nk1t-fzjwgf59yznnpdi7quam8dpgbjmlqjmnx...@mail.gmail.com> Date: Mon, 07 Oct 2013 14:06:39 -0400 Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> X-BeenThere: [email protected] X-Mailman-Version: 2.1.12 Precedence: list Reply-To: [email protected] List-Id: Routing Area Working Group <rtgwg.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:[email protected]?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg> List-Post: <mailto:[email protected]> List-Help: <mailto:[email protected]?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:[email protected]?subject=subscribe> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: [email protected] Errors-To: [email protected] In message <cag4d1re-0nk1t-fzjwgf59yznnpdi7quam8dpgbjmlqjmnx...@mail.gmail.com> Alia Atlas writes: > This second WG Last Call got absolutely no comments. Does this group > of generally opinionated and thoughtful people truly have nothing to > say? > > If so and given the previous WGLC succeeded, then on Oct 9, I will > take silence as consent and indicate that on the draft shepherd's > write-up... > > Alia Alia, et al. Silence could mean lots of people read the document and could see no way to further improve it. I doubt that is the case. Silence could also mean that the document has been around for so long that people are tired or reading it and haven't bothered to read it again. More likely IMHO. It isn't clear (to me) in the above email if you were extending WGLC until Oct 9. As co-author, I wanted to give others a chance to comment first during WGLC and they have had plenty of time to do so. Given that there are multiple co-authors, there has been some compromise in the document. While combining contributions, there was some tendency to "go along to keep moving forward". That can be bad if there are too few critical reviewers outside the set of co-authors. With co-author hat off, I reread the document and here are my personal review comments. If there is agreement to make changes, I will put co-author hat back on and make these edits. If there is dissenting discussion, I'll edit as best as I can judge consensus and we can disuss at IETF-88 if we need to. If there is silence, I'll let Alia and Alvaro interpret the silence. (full agreement with all changes? lack of interest?) This *is* a WG doc, so WG please speak up. Curtis - ---------------------------------------- General Comments (See specific instances of each in detailed comments): The section naming and grouping of requirements could stand some improvement. Some of the requirement wording are awkwardly worded. A few sentences border on meaningless. Some of the requirements are infeasible as worded. Most can be made feasible by replacing "flows or group of flows" with "client LSP". The following paragraph in the introduction gives a hint as to why these are feasible for client LSP but not flows: The ingress and egress of a multipath may be midpoint LSRs with respect to a given client LSP. A midpoint LSR does not participate in the signaling of any clients of the client LSP. Therefore, in general, multipath endpoints cannot determine requirements of clients of a client LSP through participation in the signaling of the clients of the client LSP. One requirement (bidirectional placement on components) is infeasible for flows and infeasible for all but small client LSP that fit into a single compoent link. The framework points this out. Specific Comments: wording: s/no significantly exceed/not significantly exceed/ FR#4 contains one awkward excessively wordy sentence followed by one that I struggle to find any meaning in if I didn't already know what the intent was. It may also be better to replace "path for a flow" with "set of paths for an LSP" and then specify the requirements for flows within that LSP. OLD FR#4 The solution SHALL provide a mechanism to select a path for a flow across a network that contains a number of paths comprised of pairs of nodes connected by advanced multipath in such a way as to automatically distribute the load over the network nodes connected by advanced multipaths while meeting all of the other mandatory requirements stated above. The solution SHOULD work in a manner similar to that of current networks without any advanced multipath protocol enhancements when the characteristics of the individual component links are advertised. NEW FR#4 The solution shall provide a mechanism to select a set of paths for an LSP across a network in such a way that flows within the LSP are distributed across the set of paths while meeting all of the other requirements stated above. The solution SHOULD work in a manner similar to existing multipath techniques except as necessary to accommodate advanced multipath requirements. I think these say pretty much the same thing, but with improved clarity in the new text. FR#10 and FR#11 are the following: FR#10 The solution SHALL provide a means to limit the latency to meet a Performance Objective target on a per flow basis or group of flow basis, where flows or groups of flows are identifiable in the forwarding plane and are signaled using in the control plane or set up using the management plane. The Performance Objectives differ across the services, and some services have different Performance Objectives for different QoS classes, for example, one QoS class may have a much larger latency bound than another. Overload can occur which would violate a Performance Objective parameter (e.g., loss) and some remedy to handle this case for an advanced multipath is required. FR#11 If the total demand offered by traffic flows exceeds the capacity of the advanced multipath, the solution SHOULD define a means to cause some traffic flows or groups of flows to move to some other point in the network that is not congested. These "preempted flows" may not be restored if there is no uncongested path in the network. FR#10 and FR#11 currently fall under the section "Component Links Provided by Lower Layer Networks" but have nothing to do with lower layer networks. These would fit better with the existing section named "Parallel Component Links with Different Characteristics" (though see comments below on rearranging that section). FR#10 may be redundant due to FR#17 and FR#18 which specify minimul latency and bounded latency. The first paragraph in FR#10 adds nothing to FR#17 and FR#18 except that the result should meet "a Performance Objective target". The second paragraph seems to be unrelated discussion and perhaps belongs in FR#11. If so, FR#10 can be eliminated possibly adding a statement about "a Performance Objective target" in FR#17 and FR#18, but preferably leaving them alone. FR#10 and FR#11 are infeasible if applied to "client LSP" rather than "flows or groups of flows" for reasons stated in General Comments above. (So are FR#17 and FR#18; see below). In FR#10 s/signaled using in the control plane/signaled using the control plane/ FR#11 needs to be about preemption of LSP, not preemption of flows. Since there is no signaling of flows, there is no prioritization of flows. There is OTOH diffserv, which will enforce prioritization, even among traffic within a microflow (AF service where some traffic is marked AFx2 or AFx3, aka yellow or red). In FR#11 s/traffic flows or groups of traffic flows/clent LSP/ makes the requirement feasible. In FR#11 s/some other point in the network/an alternate set of paths/ makes the requirement more clear. NEW FR#10 [Deleted] FR#11 If the total demand offered by traffic flows exceeds the capacity of the advanced multipath, the solution SHOULD define a means to cause some client LSP to move to an alternate set of paths that are not congested. These "preempted LSP" may not be restored if there is no uncongested path in the network. The title "Parallel Component Links with Different Characteristics" should be changed, dropping the word "Parallel". The requirements also apply to very diverse paths through a network with different characteristics. The set of requirements currently in "Component Links with Different Characteristics" are mostly of two types: 1. Load Balance Dynamics (FR#12-FR#15, FR#20-FR#23) 2. Requirements for Carrying Client LSP (FR#16-FR#19, FR#24). FR#22 and FR#23 could be in either category but apply more to dynamics of load balancing. It might be better to reorder these requirements and create two subsections. Both still do apply to "Component Links with Different Characteristics", but form two distinct subsets. In requirements FR#17-FR#19 s/a traffic flow/the traffic flows within a client LSP/ Signaling is applied to client LSP, not flows as mentioned in General Comments above. FR#24 is extremely problematic. The existing framework document indicates that there are significant feasibility issues associated with supporting this requirement for all but small client LSP and requiring a fallback to link bundling for these small cleint LSP. There has been no discussion supporting a feasible means to do this for large client LSP. Therefore it may be wise to either drop this requirement entirely or at the very least change it to a SHOULD. If the requirement is kept, perhaps a qualifier indicating "for small client LSP only (ones that fit on a single component)" is required. If link bundling is the solution, the requirement is a NOOP but the requirement may serve to indicate that link bundling must co-exist with hash based load balancing for a subset of LSP requiring that a both directions take the same component. If FR#24 is relaxed to say that both directions traverse the same set of nodes, then FR#24 becomes feasible for large client LSP. This would, for example, allow MPLS-TP OAM to function corrently for MPLS-TP LSP carried within client MPLS LSP. If this is desirable it should be a separate requirement. The section title "Derived Requirements" has irked a number of people. These requirements are distinct in that they reference protocols which would be used within a solution, but they are not truly "derived" from the "Functional Requirements" in the prior section. I prefer "General Requirements for Protocol Solutions". Therefore s/Derived Requirements/GeneralRequirements for Protocol Solutions/ s/DR/GR/ I suggest rewording DR#1 as follows: OLD DR#1 The solution SHOULD attempt to extend existing protocols wherever possible, developing a new protocol only if this adds a significant set of capabilities. NEW GR#1 The solution SHOULD extend existing protocols wherever possible, developing a new protocol only where doing so adds a significant set of capabilities. I dropped "attempt to". The solution SHOULD get it right. No E for Effort for trying but getting it wrong. :-) In DR#3, I'm not sure what the last sentence means as worded, though I think I know the intent. OLD Other functional requirements should be supported as independently of signaling protocol as possible. NEW Function requirements SHOULD, where possible, be supported in a manner that supports LDP signaled LSP, RSVP signaled LSP, and LSP set up using management plane mechanisms. Either the management section is perfect or I forgot to read it. :-) The Ack section should say that after some discussion Tom Yu suggested replacement text that was used as the basis for the security section. The Ack section should indicate that the document was renamed as a result of potential problems with terminology collision that were pointed out by Lou Berger in the RtgDir review. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg ------- End of Forwarded Message _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
