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

[Curtis Villamizar <[e-mail]>]

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.