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
