I have no objection to any of Curtis' specific changes. Cheers, Andy
On Mon, Oct 7, 2013 at 2:06 PM, Curtis Villamizar <[email protected]> wrote: > > 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 _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
