RE: WG Last Call for draft-ietf-rtgwg-cl-requirement-11
Lucy yong <lucy.yong@huawei.com> Tue, 08 October 2013 14:15 UTC
Return-Path: <lucy.yong@huawei.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B54221E809D for <rtgwg@ietfa.amsl.com>; Tue, 8 Oct 2013 07:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Kes90dujdRJr for <rtgwg@ietfa.amsl.com>; Tue, 8 Oct 2013 07:15:28 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 85BCC21E809B for <rtgwg@ietf.org>; Tue, 8 Oct 2013 07:15:26 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWO36610; Tue, 08 Oct 2013 14:15:24 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 15:15:02 +0100
Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 15:15:23 +0100
Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Tue, 8 Oct 2013 07:15:19 -0700
From: Lucy yong <lucy.yong@huawei.com>
To: Ning So <Ning.So@tatacommunications.com>, "Andrew G. Malis" <agmalis@gmail.com>, "curtis@ipv6.occnc.com" <curtis@ipv6.occnc.com>
Subject: RE: WG Last Call for draft-ietf-rtgwg-cl-requirement-11
Thread-Topic: WG Last Call for draft-ietf-rtgwg-cl-requirement-11
Thread-Index: AQHOw4hm4CdYA99Pgka4IexdiMqcHZnrSNGAgAAFQ4D//4yYwA==
Date: Tue, 08 Oct 2013 14:15:19 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D41A5@dfweml509-mbx.china.huawei.com>
References: <CAG4d1re-0Nk1t-fzjWGF59yZnNPdi7quAM8DPgbjMLQjMNxo1Q@mail.gmail.com> <201310071806.r97I6eeV070034@gateway1.orleans.occnc.com> <CAA=duU30-CAS2LzMrqcbFnXTg=mRtd1Yg2kQ68D0=zPHL2oHJw@mail.gmail.com> <F03A6CD051CB7946A6E58423E26D99A970FB307C@uswv1vdag02.vsnl.co.in>
In-Reply-To: <F03A6CD051CB7946A6E58423E26D99A970FB307C@uswv1vdag02.vsnl.co.in>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.138.187]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "rtgwg@ietf.org" <rtgwg@ietf.org>, "draft-ietf-rtgwg-cl-requirement@tools.ietf.org" <draft-ietf-rtgwg-cl-requirement@tools.ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Oct 2013 14:15:33 -0000
+1 lucy -----Original Message----- From: Ning So [mailto:Ning.So@tatacommunications.com] Sent: Tuesday, October 08, 2013 9:09 AM To: Andrew G. Malis; curtis@ipv6.occnc.com Cc: Alia Atlas; draft-ietf-rtgwg-cl-requirement@tools.ietf.org; rtgwg@ietf.org Subject: RE: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 I am fine as well. Best regards, Ning So Head of Network Architecture Mobile Broadband Services Tata Communications (Cell) 972-955-0914 -----Original Message----- From: Andrew G. Malis [mailto:agmalis@gmail.com] Sent: Tuesday, October 08, 2013 8:50 AM To: curtis@ipv6.occnc.com Cc: Alia Atlas; draft-ietf-rtgwg-cl-requirement@tools.ietf.org; rtgwg@ietf.org Subject: Re: WG Last Call for draft-ietf-rtgwg-cl-requirement-11 I have no objection to any of Curtis' specific changes. Cheers, Andy On Mon, Oct 7, 2013 at 2:06 PM, Curtis Villamizar <curtis@ipv6.occnc.com> wrote: > > In message > <CAG4d1re-0Nk1t-fzjWGF59yZnNPdi7quAM8DPgbjMLQjMNxo1Q@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 > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg
- WG Last Call for draft-ietf-rtgwg-cl-requirement-… Alia Atlas
- Re: WG Last Call for draft-ietf-rtgwg-cl-requirem… Alia Atlas
- Re: WG Last Call for draft-ietf-rtgwg-cl-requirem… Alia Atlas
- Re: WG Last Call for draft-ietf-rtgwg-cl-requirem… Curtis Villamizar
- Re: WG Last Call for draft-ietf-rtgwg-cl-requirem… Curtis Villamizar
- Re: WG Last Call for draft-ietf-rtgwg-cl-requirem… Andrew G. Malis
- RE: WG Last Call for draft-ietf-rtgwg-cl-requirem… Ning So
- RE: WG Last Call for draft-ietf-rtgwg-cl-requirem… Lucy yong
- Re: WG Last Call for draft-ietf-rtgwg-cl-requirem… Curtis Villamizar