Subject: draft-ietf-rtgwg-cl-requirement preview of -12 version

From: Curtis Villamizar <[email-masked]>
Date: Tue, 08 Oct 2013 23:19:50 -0400

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

Delivery-Date: Mon Oct  7 17:38:25 2013
To: Alia Atlas <[email-masked]>
From: Curtis Villamizar <[email-masked]>
Subject: Re: WG Last Call for draft-ietf-rtgwg-cl-requirement-11
Date: Mon, 07 Oct 2013 14:06:39 -0400
Cc: "[email-masked]"
	<[email-masked]>,
        "[email-masked]" <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
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-masked]
https://www.ietf.org/mailman/listinfo/rtgwg

------- End of Forwarded Message

---

From: "Malis, Andrew G (Andy)" <[email-masked]>
Date: Wed, 9 Oct 2013 08:53:07 -0400

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-masked]> wrote:

RTGWG,

    4.  s/1 ms/1 msec/

        OLD

        NEW

Curtis

Delivery-Date: Mon Oct  7 17:38:25 2013
[IPv6:2001:470:1f07:1545::2:819])
        by harbor1.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id r97LcPEG091422
        for <[email-masked]>; Mon, 7 Oct 2013 17:38:25 -0400 (EDT)
        (envelope-from [email-masked])
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-masked])
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)
To: Alia Atlas <[email-masked]>
From: Curtis Villamizar <[email-masked]>
Subject: Re: WG Last Call for draft-ietf-rtgwg-cl-requirement-11
Date: Mon, 07 Oct 2013 14:06:39 -0400
Cc: "[email-masked]"
        <[email-masked]>,
        "[email-masked]" <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

In message
<[email-masked]>

Alia, et al.

Curtis

Specific Comments:

 OLD

 NEW

In FR#10

 NEW

   FR#10  [Deleted]

Therefore

 OLD

 NEW

 OLD

 NEW

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 09 Oct 2013 09:28:26 -0400

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 <[email-masked]>
"Malis, Andrew G (Andy)" writes:

Curtis,

Thanks,
Andy

RTGWG,

    4.  s/1 ms/1 msec/

        OLD

        NEW

Curtis

In message

Alia, et al.

Curtis

Specific Comments:

 OLD

 NEW

In FR#10

 NEW

   FR#10  [Deleted]

Therefore

 OLD

 NEW

 OLD

 NEW