Re: WG Last Call for draft-ietf-rtgwg-cl-requirement-11

["Andrew G. Malis" <[e-mail]>]

I have no objection to any of Curtis' specific changes.

Cheers,
Andy


On Mon, Oct 7, 2013 at 2:06 PM, Curtis Villamizar <[e-mail]> wrote:
>
> In message <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg