From agmalis@gmail.com Tue May 1 10:42:52 2012 Return-Path: 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 4C1B921E8252 for ; Tue, 1 May 2012 10:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 wYNoNkZW-uTq for ; Tue, 1 May 2012 10:42:51 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 827BD21E8050 for ; Tue, 1 May 2012 10:42:51 -0700 (PDT) Received: by yenq7 with SMTP id q7so305yen.31 for ; Tue, 01 May 2012 10:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Gw1iQibSQpnN1kOSIXu8m5lnq7fh+sZse5q9Kpmxc7U=; b=s9dkWl/WlRD72B3rJ8+sSowkm5KglXI+UkVERvgOTt9+QvBok94yT3bf9LKCn5YcmI TPHIIXmNWDlHdlxsVn6ESuHVTyZ6rJsanLpxRRRIW6FM32Gc5UDJC1j+UdEYVsVBeLOl 6el7NbZ25ByBGdx5yAVwy+WCMpPEIxoktW5Lyrku5yg+zDt2lk5z10PH9ixYpvDZPQy3 NFZngZ6seIth0VNFpJjrUY51WOrtN/9Kr17Obp/Hu1+QxdsCcLLCdda71nWhFtVXtlY2 13afV4Kg53K+PQNFCYDrdokRtPOq5j/yvkk5vBIkNQ++HTYGSbVfNUigWetsGXhla/fc YvfA== Received: by 10.50.179.104 with SMTP id df8mr2741718igc.11.1335894170618; Tue, 01 May 2012 10:42:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.184.231 with HTTP; Tue, 1 May 2012 10:42:30 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Tue, 1 May 2012 13:42:30 -0400 Message-ID: Subject: Re: Composite link drafts update and request To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 17:42:52 -0000 As agreed in the Paris meeting, the authors of draft-so-yong-rtgwg-cl-framework and draft-symmvo-rtgwg-cl-use-cases are requesting that these become working group documents. Thanks, Andy On Fri, Mar 30, 2012 at 9:55 AM, Andrew G. Malis wrote: > As was discussed in yesterday's rtgwg meeting, there are three > composite link drafts: > > https://tools.ietf.org/html/draft-ietf-rtgwg-cl-requirement-05 > > https://tools.ietf.org/html/draft-so-yong-rtgwg-cl-framework-05 > > https://tools.ietf.org/html/draft-symmvo-rtgwg-cl-use-cases-00 > > You can read the slides I presented on these drafts at > https://tools.ietf.org/agenda/83/slides/slides-83-rtgwg-3.pdf (it's a > quick read!). > > As Alia said, you are all requested to read and comment on these > drafts. In about a month's time, we will be requesting WG adoption of > draft-so and draft-symmvo, and it'll be great to have an informed > discussion at that time. > > Thanks much, > Andy From curtis@occnc.com Sun May 6 09:02:41 2012 Return-Path: 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 C4CE121F8444 for ; Sun, 6 May 2012 09:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, NO_RELAYS=-0.001] 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 Y1qfUFgVp1wE for ; Sun, 6 May 2012 09:02:40 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 607C521F8443 for ; Sun, 6 May 2012 09:02:39 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q46G2JMW089507; Sun, 6 May 2012 09:02:20 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201205061602.q46G2JMW089507@gateway.ipv6.occnc.com> To: Iftekhar Hussain From: Curtis Villamizar Subject: Re: Ref: Composite link drafts update and request In-reply-to: Your message of "Mon, 23 Apr 2012 17:51:51 -0000." Date: Sun, 06 May 2012 12:02:19 -0400 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 16:02:41 -0000 Iftekhar, Hello again and thanks for the follow up comments. I've left your response intact but reformated. It seems we are in agreement and there are some action items to be attended to. I've listed the action items here and briefly commented inline. #1 Some rewording is needed in Section 3 to clarify MPLS based component vs physical link component, the latter inclucing the link layer. #2 Add a cross reference to CL framework in Section 4.1. #3 Add cross reference to CL framework near FR#8 and FR#9 regarding delay metric granularity and inclusion of queuing delay and the potential impacts on performance, oscillations, and stability. #4 Add a cross reference to CL Use Cases in Section 4.3 to point toward the brief description and references that support the statement "Many techniques have been developed to balance the distribution of flows across component links that connect the same pair of nodes" and "...via composite links, other techniques have been developed." #5 Briefly explain the "delay discontinuity" that occurs when load balancing puts traffic on a new path and clarify what is meant by "minimally disruptive". #6 It may help in some cases to clarify that something must be implemented but must, should, or may be configurable and therefore may be optionally deployed. Doing so may require a small change to many requirements as in most cases we have only indicated where something must be implemented. The rest of the email exchange seems to be clarifications. Please let me know if I missed any of your suggestions in the action item list. I will wait a week or longer for further comments from the WG and from the other authors before making these changes and sending diffs to the WG mailing list and after the WG has time to read the diffs I'll send an updated draft. Thanks and best regards, Curtis In message Iftekhar Hussain writes: > Curtis, > > Please see comments inline. > > Thanks for the detailed responses. > > Iftekhar > > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > Sent: Thursday, April 19, 2012 7:10 PM > > To: Iftekhar Hussain > > Cc: rtgwg@ietf.org > > Subject: Re: Ref: Composite link drafts update and request > > > > > > Iftekhar, > > > > Responses inline. Some reformating of your email into plain text. > > > > Thanks for the interest and for the comments. > > > > Curtis > > > > > > In message > > Iftekhar Hussain writes: > > > > > Hi, > > > > > > I have following clarification questions/comments about the > > > https://tools.ietf.org/html/draft-ietf-rtgwg-cl-requirement-05 > > > document > > > > > > a) Section 3. "Examples of a physical link are: Lambda, Ethernet PHY, > > > and OTN". Should "OTN" be "OTU"? Furthermore, can a "component > > > link" be formed by set of Lambda? > > > > We are mixing physical and physical plus link layer in the examples. > > The distinction is not important in this context but if you feel > > strongly we could clarify. > > > > If we put ODU then others would complain that ODU is carried in OTU > > and then we run into the issue that OTU is a framing on an OPU and > > perhaps someone would argue that OTU is not a physical layer and that > > even OPU is not truly a physical layer. > > [Iftekhar] Yes the main confusion was it was specifically referring to > physical links. Your suggested change will help it clarify. This is action item #1. > > It might be best to change this to: > > > > Examples of a physical link (physical layer plus link layer) are: a > > lambda with any link layer(s), Ethernet, OTN. > > > > Examples of multiple link layers include POS/SONET, > > 10GbE/ODU2e/ODU4/OTU4/OPU4, etc. In the same way, WDM could be > > considered an example of multiple physical layers (the individual > > lambda multiplex using WDM). The problem is that any attempt to > > strictly apply the antiquated ISO 7-layer model falls apart even is we > > apply only the physical layer and link layer. For WDM we have the > > physical layer subdivided into a layer zero (optical) and a layer one > > (modulated signal aka single lambda). We have plenty of examples of > > multiple link layer (layer two) protocols. > > > > The important distinction is [CL running over] a physical link plus > > link layer [used as a component link] vs [CL running over] MPLS [used > > as a component link]. Rewritten without the []: The important > > distinction is a physical link plus link layer vs MPLS. > > > > > b) Section 4.1. In the context of "FR#1" from end-to-end perspective, > > > should there be some sort of network scale related requirement(s)? > > > For example, max number of pair of nodes connected via composite > > > links traversed etc. If this aspect is covered somewhere a > > > reference should be added. > > > > End-to-end in any MPLS context means edge-to-edge (and is not > > mentioned at all in FR#1 or elsewhere). Existing scaling techniques > > used in MPLS networks still apply. Scaling is the motivation for DR#5 > > (IGP extensions disallowed in multiple domain case). Scaling is > > directly addressed in DR#6 (fast convergence) and DR#7 (fast worst > > case failure convergence). > > > > Scalability and stability are covered in the framework document > > (draft-so-yong-rtgwg-cl-framework). For example in "3.1. Scalability > > Motivations" and "3.5. Avoiding Route Oscillation". Possible need > > for further work is suggested in "7.2.11. Performance, Scalability, > > and Stability" in the framework document. > > [Iftekhar] Okay. I will take a look at the " > draft-so-yong-rtgwg-cl-framework". You might consider adding a > reference to the framework document. This is action item #2. > > > c) Section 4.2, "Communication of other performance parameters (e.g., > > > delay variation) is desirable" seems to contradict "FR#17" in > > > section 4.3. > > > > The statement is: > > > > [...] Communication of the latency performance > > parameter is a very important requirement. Communication of other > > performance parameters (e.g., delay variation) is desirable. > > > > If jitter was described as "undesireable" then it might be a > > contradiction. The point is delay is very important and delay > > variation would be nice (maybe not IMHO). What is important (ie: > > normative) is what the implementation MUST support, and what the > > operator MAY enable or disable. What is unimportant is subjective > > verbiage about relative importance among parameters. The operator > > will decide what is important by using or not using a feature. > > > > FR#17 says: > > > > FR#17 The solution SHALL provide a means to indicate that a traffic > > flow shall select a component link with a maximum acceptable > > delay variation value as specified by protocol. > > > > There are two differences between the statement in Section 4.2 and the > > statement in FR#17. First "communication of other performance > > parameters" and "provide a means to indicate that a traffic flow shall > > select a component link with a maximum acceptable delay variation > > value" are two different things; the first is a IGP parameter (link > > delay or link delay variation), the second is an RSVP parameter > > (maximum allowable delay variation for a given LSP). Second, the > > wording in Section 4.2 is informative and the wording in FR#17 is > > normative. > > [Iftekhar] Okay. I interpreted jitter as "desirable" meaning it is an > objective i.e., it is not required. But then saw the requirement FR#17 > which I read as a requirement to support delay variation. For example > in FR#17 I was expecting "MAY" or "SHOULD" rather than "MUST". See later comment referring to item #6. > > > d) Section 4.2, FR#8" appears to use "latency" in the end-to-end > > > sense. While the next requirement "FR#9" appears to refer to this > > > term only between two nodes. I think, it would helpful to clarify > > > the usage of term "latency" e.g., what component of a node transit > > > delay it excludes or includes. Or add a reference to a document if > > > this is covered in some other document. > > > > BTW- I prefer delay over latency, but the term latency is used. The > > two mean the same thing. Neither word by itself does not indicate any > > one type of delay (fabric delay, transmit delay, queuing delay, > > geographic delay). Neither word by itself implies intra-node delay, > > or delay between adjacent nodes, or end-to-end delay. > > > > FR#8 applies to any measurement of delay, whether it is a measurement > > over a single physical link or over a component link carried over a > > multihop MPLS LSP. Also in FR#9 there is no indication that the nodes > > are adjacent, and the phrase "when the path between these nodes > > contains one or more pairs of nodes connected via a composite link" > > clearly indicates that multihop paths are being considered as well as > > delay between adjacent nodes. > > > > There are some hints as to which delays the operators may consider > > important in this context. FR#8 states that "The precision of latency > > reporting SHOULD be at least 10% of the one way latencies for latency > > of 1 ms or more." This excludes most equipment latencies which can be > > expected to be well under 100 usec (10% of 1 msec). > > > > The intent is to measure the predominant latency in most (well run) > > service provider networks, which is geographic delay on the order of > > msec or tens of msec and in some cases over 100 msec (intercontinental > > traffic). In a congested network (possibly not so well run network, > > or maybe a well run network with a substantial outage) queuing delay > > can be quite large. In a congested network measuring the queuing > > delay for the low priority traffic (the only traffic likely to be > > experiencing congestion, even in an outage) is more likely to add to > > problems by adding routing instability. > > > > The only real question in FR#8 and FR#9 is whether queuing delay is > > counted in the latency figure. The argument for including queuing > > delay is that it reflects the delay experienced by applications. The > > argument against including queuing delay is that it if used in routing > > decisions it can result in routing instability. > > > > There are quite a few documents that deal with this tradeoff. For > > example, in MPLS-TP it is noted that delay measurements should be made > > using the highest priority COS value (which in effect very nearly > > eliminates any queuing delay from the measurement). > > > > > > For the requirements document, this tradeoff is not discussed, however > > the stability and convergence requirements must be considered when > > coming up with a solution. Solutions should be described in the > > framework document and not in the requirments document. > > > > In the framework document (draft-so-yong-rtgwg-cl-framework) there is > > discussion of this tradeoff in "3.5. Avoiding Route Oscillation" and > > elsewhere. The framework document is a better place for discussion of > > requirements tradeoffs. > > [Iftekhar] Okay, will take a look at the framework document. A cross reference could be added. This is action item #3. > > > e) General comment section 4.3. "Many techniques have been developed > > > to balance the distribution of flows across component links that > > > connect the same pair of nodes" and "...via composite links, other > > > techniques have been developed." It would good to add a > > > reference(s) for each. > > > > There are a few RFCs on the topic. Inverse multiplexing, various > > forms of ECMP, and Ethernet Link Aggregation are all well known. The > > statement would certainly not be controversial without references. > > > > If you are looking for further information on this, the Use Cases > > draft (draft-symmvo-rtgwg-cl-use-cases) has references. "Appendix B. > > Existing Multipath Standards and Techniques" was moved from the > > requirements document to the Use Cases draft. > > > > We could add a reference to the use cases draft in the requirements > > draft if you think that would help. > > [Iftekhar] I believe the requirement document would read better and > easier to follow if the references are added. This is action item #4. > > > f) Section 4.3, "FR#12" is about latency while the example "...a user > > > experience objective (e.g. jitter buffer under/overrun)" appears to > > > refer to delay variation. I think, the example should be consistent > > > with the requirement. > > > > The requirement in FR#12 is in the first paragraph. > > > > FR#12 When a traffic flow is moved from one component link to > > another in the same composite link between a set of nodes (or > > sites), it MUST be done so in a minimally disruptive manner. > > > > The rest is discussion. > > > > When a flow is moved from a current link to a target link with > > different latency, reordering can occur if the target link > > latency is less than that of the current or clumping can occur > > if target link latency is greater than that of the current. > > Therefore, some flows (e.g., timing distribution, PW circuit > > emulation) are quite sensitive to these effects, which may be > > specified in an NPO or are needed to meet a user experience > > objective (e.g. jitter buffer under/overrun). > > > > The discussion exists primarily for the reader who might otherwise not > > realize why there would be a disruption at all (and therefore might > > not understand why we have to say "minimally disruptive" instead of > > "completely non-disruptive"). Perhaps the entire paragraph needs to > > start with "For example, [...]". > > > > In any case it is not inconsistent. When delay changes on the current > > big-bad-Internet (such as in VOIP), the change is often absorbed by a > > jitter buffer as long as the change is small. If a delay change of > > many milliseconds occurs, then it is unlikely that the typical > > relatively small jitter buffer can hide the delay change. > > [Iftekhar] Thanks for detailed response. To me then the requirement > then is about change in latency (i.e., delay variation). Delay variation or jitter is a continuous variation in delay. It is somewhat like white noise added to the otherwise constant delay, though queuing delay when congestion occurs adds less random patterns of delay change, often with a period of multiples of RTT. When a fault occurs or is reparied or load balancing puts traffic on a new path, there is a sudden one-time change in delay. This is referred to as a "delay discontinuity" and its magnitude is often far greater than the delay variation, including delay variation that results from queuing delay under congestion. An occasional delay discontinuity is considered minimally disruptive. It would not hurt to briefly explain this effect and introduce the term "delay discontinuity". This would clarify what we mean by "minimally disruptive", though this may be one example of a minimally disruptive behavior. I have listed this as action item #5. > > > g) Section 4.3, "FR#17". It is not clear why the delay variation is > > > considered in this context. Reading this requirement, one gets the > > > impression as if the composite link delay has two components (delay > > > and delay variation). I had understood that delay variation > > > (contributed through the nodal switching/queuing delays) is not > > > considered in this document. > > > > FR#16 is about delay. FR#17 is about delay variation. The wording > > "The solution SHALL provide a means" doesn't require the operator to > > use that feature. Therefore it is better to keep the two in separate > > requirements as it is more clear that one could be enabled and the > > other disabled. > > [Iftekhar] I think it would be clear if somehow the meaning of the > above sentence "i.e., doesn't require the operator...." is included in > the text. This is item #6. See text at the top of the email message. > > > h) DR#6, a minor typo "Solution" should be "solution"? > > > > Thanks for pointing this out. > > > > > Thanks, > > > Iftekhar > > > > > > > As was discussed in yesterday's rtgwg meeting, there are three > > > > composite link drafts: > > > > > > > > https://tools.ietf.org/html/draft-ietf-rtgwg-cl-requirement-05 > > > > > > > > https://tools.ietf.org/html/draft-so-yong-rtgwg-cl-framework-05 > > > > > > > > https://tools.ietf.org/html/draft-symmvo-rtgwg-cl-use-cases-00 > > > > > > > > You can read the slides I presented on these drafts at > > > > https://tools.ietf.org/agenda/83/slides/slides-83-rtgwg-3.pdf (it's > > > > a quick read!). > > > > > > > > As Alia said, you are all requested to read and comment on these > > > > drafts. In about a month's time, we will be requesting WG adoption > > > > of draft-so and draft-symmvo, and it'll be great to have an informed > > > > discussion at that time. > > > > > > > > Thanks much, > > > > Andy From curtis@occnc.com Sun May 6 11:14:08 2012 Return-Path: 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 92E6121F84E2 for ; Sun, 6 May 2012 11:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.272 X-Spam-Level: X-Spam-Status: No, score=0.272 tagged_above=-999 required=5 tests=[AWL=-2.128, BAYES_00=-2.599, GB_SUMOF=5, NO_RELAYS=-0.001] 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 HmP2yuJJwWJA for ; Sun, 6 May 2012 11:14:07 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB0E21F8459 for ; Sun, 6 May 2012 11:14:06 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q46IE3GQ099189; Sun, 6 May 2012 11:14:04 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201205061814.q46IE3GQ099189@gateway.ipv6.occnc.com> To: Iftekhar Hussain From: Curtis Villamizar Subject: Re: draft-so-yong-rtgwg-cl-framework In-reply-to: Your message of "Fri, 27 Apr 2012 21:55:13 -0000." Date: Sun, 06 May 2012 14:14:03 -0400 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 18:14:08 -0000 Iftekhar, Thank you for the detailed comments. Responses to individual comments/suggestions are inline. This is a long email message, so if I missed anything, please point out what I missed. Please let me know if you are in general agreement with the responses and if so I'll make specific proposals for replacement text or propose more detailed action items. Best Regards, Curtis In message Iftekhar Hussain writes: > Dear Authors, > > Please find below some comments on the > http://tools.ietf.org/html/draft-so-yong-rtgwg-cl-framework-05. > > > ---------------------------- > > 2.1. Flow Identification > > "Operator may have other objectives such as ...composite link energy > saving, and etc. These new requirements are described in > [I-D.ietf-rtgwg-cl-requirement]" > > Comment: > > I don't recall any energy saving related requirement (or discussion) > in the [I-D.ietf-rtgwg-cl-requirement. Suggest removing the text > "energy saving etc." You are entirely correct that there are no energy savings mentioned in the requirements document. This wording came from one of the other authors but I think I understand the intent. There is a daily cycle (and less so a weekly cycle) to traffic levels. During the low traffic hours (generally late at night for local hours of night) traffic can be rebalanced to reduce the number of active component links. Where it is possible to depower interfaces, this could result in energy savings. I'm OK with removing this example, though it is a very good example and an goal that we should be pursuing. Another option is to add a "MAY" in the requirements docuemt somewhere that indicates that "Load balancing MAY be used during sustained low traffic periods to reduce the number of active component links for the purpose of power reduction". I'll wait for further comments on this before making a suggestion on how we will proceed. > 2.2. Composite Link in Control Plane > > "LDP follows the IGP, therefore failure to forward on the IGP path > will often result in loss of connectivity if the IGP adjacency is not > withdrawn when an LDP FEC is refused. This is a pathologic case that > can occur if LDP is carried natively and there is a high volume of LDP > traffic. This situation can be avoided by carrying LDP within RSVP-TE > LSP." > > > Comment: > > Is it the loss of connectivity referring to LDP control plane > connectivity only or LDP signaled LSP data plane or both? The bottom line is that admission control cannot be applied to LDP without loss of connectivity. Complete loss of connectivity for a subset of traffic, no matter how low its priority, is unacceptable. LDP does not support TE. There are two options. Either don't carry enough LDP traffic such that this situation can occur (this is the case when a small subset of traffic is high priority traffic carried within LDP, such as VOIP or enterprise VPN traffic mixed with a much larger volume of Internet traffic). The alternative is to carry the LDP traffic within RSVP-TE LSP when enough LDP traffic is aggregated such that TE is needed. The goal was to refer to this problem without going into an excessively long explanation. If you think it is too brief and therefore is unclear, then I'll reword it. > Comment: > > "Composite link capacity is aggregated capacity and MAY be larger than > individual component link capacity." Before the MAY insert "LSP capacity" and the sentence makes more sense. I'll reread this and see if that is what was intended. > Composite link aggregate capacity should always be larger than > individual component link capacity. Did I misunderstand? The statement as written is not useful. The sum of positive quantities is always greater than the quantities being summed. Thanks for pointing out this statement. I'll look at the context and figure out the intent. > > "...1. If no other information is available the largest microflow is > bound by one of the following:" > > Suggested text: > > If no other information is available the largest microflow is bound > (i.e., signaling extensions don't indicate a bound) by one of the > following: I'll reword this. The other information could be signaled or configured. > Comment: > > Section 2.2 provides architectural guidelines e.g., " ...Available > capacity in other component links MUST be used to carry impacted > traffic. The available bandwidth after failure MUST be advertised > immediately to avoid looped crankback" and provides illustrative > examples e.g.,"... no microflow larger than 10 Gb/s will be present on > the RSVP-TE LSP that aggregate traffic across the core, even if the > core interfaces are 100 Gb/s interfaces." Be careful not to take the last sentence out of the context of the example (where no interface feeding the core is greater than 10 Gb/s). > In contrast, section 2.1 appears to be little bit too vague e.g., " > ... technique of grouping flows, such as hashing on the flow > identification criteria, becomes essential to reduce the stored state, > and is an essential scaling technique. Other means of grouping flows > may be possible" > > Suggestion: > > Add some examples which flow identification scheme to use for > composite links or add a reference to section 4.2 which discusses flow > identification trade-offs. The intent in Section 2.1 is to make three points. First, tracking every flow is not scalable. Second, IP src/dst address hashing has proven (in over two decades of experience) to be an excellent way of identifying groups of flows (for reasons briefly listed). Third, if you find a better way to identify groups of flows, then use it. We don't want to require the use of IP address hashing, but wanted to strongly encourage its use, given its long history of successful deployment. I'll look at rewording the section. > 4.1.4. Requirements for Contained LSP > > Comment: > > Add reference to specific relevant to requirements in > I-D.ietf-rtgwg-cl-requirement] similar to section 4.1.2 and 4.1.3. OK. The sentence "[I-D.ietf-rtgwg-cl-requirement] calls for new LSP constraints." needs followup indicating which requirements are being referred to. > 4.2. Data Plane Challenges > > Comment: > > Minor typo: "very course..." should be "very coarse..." Of coarse. How could I miss that? :-) I searched for other uses of the word "course" and found quite a few that should be "coarse". Thanks for the catch. > Comment: > > "In practice using the MPLS label stack alone has proven too course > to acheive a reasonably good load balance, due to bin-packing issues > and discrpencies between signaled bandwidth and actual traffic loads > on LSP." > > Suggest adding a reference to an IETF standard or best practices > document that discusses these issues. OK, if I can find something. This has been discussed on and off on the mailing lists for about a decade. There may be something in the original link bundling RFC or elsewhere. > Comment: > > Sections 4.2, 2.1, 2.3, appear to be somewhat redundant. Suggest > trimming section 2.1 and absorbing that information in section 4.2. Thanks for pointing this out. I'll reread and try to reduce redundancy, using cross references where appropriate rather than repeating a point. > 3. Architecture Tradeoffs > > Comment: > > "Composite Link is applicable to large networks, and therefore > scalability must be a major consideration." > > What is a typical definition of a large network? Suggestion: Add an > example (or a forward reference to section 3.3.1 which has an example) Any network that one of your customers wants to build would be a good example of large. :-) [But not a good definition of large.] By "large" we mean the type of networks that service providers or large content providers are building today. In the future we may find that enterprises are building large enough private networks to have certain scaling problems that had previously only been experienced by service providers and content providers in the past. A good example of that in the past is overuse of bridging. Some of the NSFNET regional networks in the late 1980s used bridging but experienced severe scaling issues very quickly. It wasn't until the early to mid 1990s that large enterprises began having similar problems. The point of the phrase "Composite Link is applicable to large networks" is that if you need parallel links because the single link capacity je jour is too small, then your network is large relative to most other networks. Considering the magnitude of "large" where 10Gb/s links are too small, the phrase "and therefore scalability must be a major consideration" may seem almost rhetorical to some with deployment experience with IP networks. The reason that the statement here is brief is that there are a number of IETF base documents dating back to the mid-1990s on the importance of scalability. These realization came from deployment experience. Despite this someone occasionally makes a naive comment about processors getting faster and memory getting larger, ignoring the fact that comparable grouth with order NlogN or N-squared growth in computation or memory requirements far outpaces Moore's Law improvements. I think at least one somewhat ancient RFC indicatea that scalability must be considered in every document in the IETF routing area. If I find it I'll cite it. It will probably have Brian Carpenter or Christian Huitman on the author list, making it easier to find. Maybe Fred Baker. I think it was an IAB or IESG RFC. > 3.1. Scalability Motivations > > Comment: > > "....a large routing change to be accomplished more quickly," > > What is a typical definition of a large routing change? Suggestion: > Add an example. Not entirely serious: Hurricane Katrina resulted in a number of "large routing changes". There was the collaspse of the Raratan River bridge in NJ taking out fibers on both sides of the bridge (thought to be redundant), an earthquake east of San Diego taking out three of four fiber paths, etc. This is again a relative term that has been used for quite some time. A customer circuit going down or a new customer coming online results in a tiny routing change. A metro fault may be handled entirely in the metro and have no effect at all on routing elsewhere in the provider network or global network. Major fiber outages generally result in large routing changes. In an MPLS context, a large routing change is one that affects a large number of LSP. A classic example is where one hop along one of two or three east-west paths across the continental US goes down (or comes up, though this can be made far less disruptive). Many LSP traverse the small number of US east-west paths and terminate in a large number of medium to large sized cities along either coast. Again, I'll look at clarifying, but in less words than this response. > 7.2.5. Dynamic Multipath Balance > > Comment: > > "...uses a course granularity, the adjustments would have to be > equally course, in the worst case moving entire LSP" > > Minor typo "course" should be "coarse". s/course/coarse/ with selective replacement. > 7. Required Protocol Extensions and Mechanisms > > Comment/suggestion: > > Organizing section 7 as a matrix containing something like: > Requirement#, Existing Mechanisms, Gaps, Ongoing/new extensions..., > might be more clearer. AT a minimum, add a traceability to each > requirement in [I-D.ietf-rtgwg-cl-requirement] and the section number > in framework document that addresses each requirement (or set of > requirement). Section 7.2 groups the requirements but there is no where that lists every requirement in numeric order and points to where in the grouping it falls. It should be easy enough to add that. At the moment, potential issues with the requirements or in this document are listed in Section 7.3. This is a different approach, listing the omissions rather than cross referencing. Ideally we address all of the issues and drop this section. Section 7.4 lists the requirements by protocol or functionality affected. This as stated in the first paragraph is for the benefit of implementors. Subsections of 7.4 refers back to the groupings in subsections of 7.2. It would not be difficult to put in the reverse cross references (functional group refers to protocol change or functionality supporting it). > Is there a minimal set of requirements which must be met to form a > deployable (useful) composite link based solution? That's a great question. "Enough to be useful" is interpreted differently by different network operators deploying a network. For an equipment vendor the best approach is to plan to implement everything over time under the assumption that every feature will appear in a check box in someone's RFI/RFP/RFQ eventually, but ask current key customers which features to prioritize. That process may yield a different answer for different equipment vendors, depending on who their current key customers are. BTW- Our friends at Verizon made sure that almost every requirement is a MUST, so ask them to identify the requirements that they are not really serious about. Wear protective fireproof undergarments. :-) > ----------------------- > > Regards, > Iftekhar From curtis@occnc.com Thu May 24 10:56:57 2012 Return-Path: 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 D773E21F85D3 for ; Thu, 24 May 2012 10:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 x-GArzqAOo1o for ; Thu, 24 May 2012 10:56:57 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 2C73621F85A4 for ; Thu, 24 May 2012 10:56:57 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q4OHuqIV042399; Thu, 24 May 2012 10:56:52 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201205241756.q4OHuqIV042399@gateway.ipv6.occnc.com> To: Iftekhar Hussain From: Curtis Villamizar Subject: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) In-reply-to: Your message of "Sun, 20 May 2012 17:39:19 -0000." Date: Thu, 24 May 2012 13:56:52 -0400 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 17:56:58 -0000 All, Note the change in subject line. In the discussion of the CL framework, a suggestion was made to change the requirements. Please comment on this suggestion. The following would be added somewhere. Load balancing MAY be used during sustained low traffic periods to reduce the number of active component links for the purpose of power reduction. I think the wording in the framework originally came from either Lucy or Verizon (maybe Ning or Dave?). Iftekhar is correct that it would be best to mention this in the requirements if we are going to mention it in the framework. Curtis btw- In each of these document we need to change Ning's affiliation. In message Iftekhar Hussain writes: > > > > > > > Please find below some comments on the > > > > http://tools.ietf.org/html/draft-so-yong-rtgwg-cl-framework-05. > > > > > > > > > ---------------------------- > > > > > > 2.1. Flow Identification > > > > > > "Operator may have other objectives such as ...composite link energy > > > saving, and etc. These new requirements are described in > > > [I-D.ietf-rtgwg-cl-requirement]" > > > > > > Comment: > > > > > > I don't recall any energy saving related requirement (or discussion) > > > in the [I-D.ietf-rtgwg-cl-requirement. Suggest removing the text > > > "energy saving etc." > > > > You are entirely correct that there are no energy savings mentioned in > > the requirements document. This wording came from one of the other > > authors but I think I understand the intent. There is a daily cycle > > (and less so a weekly cycle) to traffic levels. During the low > > traffic hours (generally late at night for local hours of night) > > traffic can be rebalanced to reduce the number of active component > > links. Where it is possible to depower interfaces, this could result > > in energy savings. > > > > I'm OK with removing this example, though it is a very good example > > and an goal that we should be pursuing. Another option is to add a > > "MAY" in the requirements docuemt somewhere that indicates that "Load > > balancing MAY be used during sustained low traffic periods to reduce > > the number of active component links for the purpose of power > > reduction". > > > [Iftekhar] OK. The latter option seems reasonable. > > > > I'll wait for further comments on this before making a suggestion on > > how we will proceed. From lucy.yong@huawei.com Thu May 24 11:42:34 2012 Return-Path: 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 EFC8221F84AF for ; Thu, 24 May 2012 11:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 3zBOHYaZWD44 for ; Thu, 24 May 2012 11:42:33 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 218B121F84A6 for ; Thu, 24 May 2012 11:42:33 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGF70870; Thu, 24 May 2012 14:42:32 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 11:40:46 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Thu, 24 May 2012 11:40:41 -0700 From: Lucy yong To: "curtis@occnc.com" , Iftekhar Hussain Subject: RE: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) Thread-Topic: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) Thread-Index: AQHNOdbxVdxVar5XdU2nTRLjM8h9R5bZRNpQ Date: Thu, 24 May 2012 18:40:41 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3310A7F5@dfweml506-mbx> References: Your message of "Sun, 20 May 2012 17:39:19 -0000." <201205241756.q4OHuqIV042399@gateway.ipv6.occnc.com> In-Reply-To: <201205241756.q4OHuqIV042399@gateway.ipv6.occnc.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 18:42:34 -0000 Agree on the suggestion. However, the text to be considered as following: Load distribution constraint MAY be used during sustained low traffic per= iods to reduce the number of active component links for the purpose of power reduction. Lucy -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of C= urtis Villamizar Sent: Thursday, May 24, 2012 12:57 PM To: Iftekhar Hussain Cc: rtgwg@ietf.org Subject: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) All, Note the change in subject line. In the discussion of the CL framework, a suggestion was made to change the requirements. Please comment on this suggestion. The following would be added somewhere. Load balancing MAY be used during sustained low traffic periods to reduce the number of active component links for the purpose of power reduction. I think the wording in the framework originally came from either Lucy or Verizon (maybe Ning or Dave?). Iftekhar is correct that it would be best to mention this in the requirements if we are going to mention it in the framework. Curtis btw- In each of these document we need to change Ning's affiliation. In message Iftekhar Hussain writes: > > > > > > > Please find below some comments on the=20 > > > > http://tools.ietf.org/html/draft-so-yong-rtgwg-cl-framework-05. > > > > > > > > > ---------------------------- > > > > > > 2.1. Flow Identification > > > > > > "Operator may have other objectives such as ...composite link energy= =20 > > > saving, and etc. These new requirements are described in=20 > > > [I-D.ietf-rtgwg-cl-requirement]" > > > > > > Comment: > > > > > > I don't recall any energy saving related requirement (or discussion)= =20 > > > in the [I-D.ietf-rtgwg-cl-requirement. Suggest removing the text=20 > > > "energy saving etc." > > =20 > > You are entirely correct that there are no energy savings mentioned in > > the requirements document. This wording came from one of the other > > authors but I think I understand the intent. There is a daily cycle > > (and less so a weekly cycle) to traffic levels. During the low > > traffic hours (generally late at night for local hours of night) > > traffic can be rebalanced to reduce the number of active component > > links. Where it is possible to depower interfaces, this could result > > in energy savings. > > =20 > > I'm OK with removing this example, though it is a very good example > > and an goal that we should be pursuing. Another option is to add a > > "MAY" in the requirements docuemt somewhere that indicates that "Load > > balancing MAY be used during sustained low traffic periods to reduce > > the number of active component links for the purpose of power > > reduction". > > =20 > [Iftekhar] OK. The latter option seems reasonable.=20 > > =20 > > I'll wait for further comments on this before making a suggestion on > > how we will proceed. _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From kireeti@juniper.net Thu May 24 12:22:13 2012 Return-Path: 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 A34C911E80AF for ; Thu, 24 May 2012 12:22:12 -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 1ANTyHZ7zzpb for ; Thu, 24 May 2012 12:22:12 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id A146311E8076 for ; Thu, 24 May 2012 12:22:09 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKT76KXuzGhhI6DQ2huxSny3QFrj/M4V9e@postini.com; Thu, 24 May 2012 12:22:09 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 24 May 2012 12:19:27 -0700 From: Kireeti Kompella To: Lucy yong Date: Thu, 24 May 2012 12:19:27 -0700 Subject: Re: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) Thread-Topic: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) Thread-Index: Ac054iMUti5UuIZXQaGmf8x++rfHkA== Message-ID: References: Your message of "Sun, 20 May 2012 17:39:19 -0000." <201205241756.q4OHuqIV042399@gateway.ipv6.occnc.com> <2691CE0099834E4A9C5044EEC662BB9D3310A7F5@dfweml506-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D3310A7F5@dfweml506-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Iftekhar Hussain , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 19:22:13 -0000 On May 24, 2012, at 11:40 , Lucy yong wrote: > However, the text to be considered as following: >=20 > Load distribution constraint MAY be used during sustained low traffic pe= riods to > reduce the number of active component links for the purpose of power > reduction. I'd phrase that as "Constrained load balancing MAY ...". I prefer balancin= g to distribution. In any case, you'd want to add something to the effect that "normal" load d= istribution SHOULD be resumed when traffic increases, with flows being affe= cted (again). Kireeti. From curtis@occnc.com Thu May 24 12:56:12 2012 Return-Path: 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 D65C011E80D5 for ; Thu, 24 May 2012 12:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 P3P-TrvmWHm3 for ; Thu, 24 May 2012 12:56:12 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 33FDA11E80D6 for ; Thu, 24 May 2012 12:56:11 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q4OJu4JF046481; Thu, 24 May 2012 12:56:04 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201205241956.q4OJu4JF046481@gateway.ipv6.occnc.com> To: Kireeti Kompella From: Curtis Villamizar Subject: Re: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) In-reply-to: Your message of "Thu, 24 May 2012 12:19:27 PDT." Date: Thu, 24 May 2012 15:56:04 -0400 Cc: Iftekhar Hussain , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 19:56:12 -0000 In message Kireeti Kompella writes: > On May 24, 2012, at 11:40 , Lucy yong wrote: > > > However, the text to be considered as following: > > > > Load distribution constraint MAY be used during sustained low > > traffic periods to > > reduce the number of active component links for the purpose of power > > reduction. > > I'd phrase that as "Constrained load balancing MAY ...". I prefer > balancing to distribution. Duh. Yeah. Not sure how I managed to mangle the wording so badly and not notice it so far. I think this is best: Load distribution MAY be used during sustained low traffic periods to reduce the number of active component links for the purpose of power reduction. The word "constraint" is dropped. > In any case, you'd want to add something to the effect that "normal" > load distribution SHOULD be resumed when traffic increases, with flows > being affected (again). > > Kireeti. I see your point except that I don't see this as quite a big a deviation from "normal" load balancing. For example, if there are N components, then one could configure the CL to shut off a component if a condition is met. One such condition would be the utilization of the composite would remain under some configured percentage if traffic remained at the same levels as was recorded over a prior interval. For example, if M components remain (where 1 < M <= N) and traffic was measured in 100 msec intervals for 20 minutes with no interval exceeding a level where M-1 components would be loaded over 80%, then the number of components is reduced by one and measurement starts over. If the composite is ever loaded over 80%, then a component is added back. That was just an example. The requirements would just indicate that some unspecified technique MAY be used to address the requirement. The framework might put a few more constraints on the technique, but only if we think that would be needed. Since coordination on both sides would be needed to power down components, a protocol extension would be needed ... eventually, if we could ever get past requirements and framework. A bit like LACP only not for Ethernet component links only, or like Avici Composite Link (abandonned trademark) only not just for component links using PPP (like POS). Curtis From kireeti@juniper.net Thu May 24 13:18:27 2012 Return-Path: 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 ED57211E80C8 for ; Thu, 24 May 2012 13:18:27 -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 uUsvhufneguz for ; Thu, 24 May 2012 13:18:27 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD4B11E809D for ; Thu, 24 May 2012 13:18:27 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKT76Xi1oWk+8FtD9+WN6ToaXZp6sRBCFL@postini.com; Thu, 24 May 2012 13:18:27 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 24 May 2012 11:31:49 -0700 From: Kireeti Kompella To: "curtis@occnc.com" Date: Thu, 24 May 2012 11:31:48 -0700 Subject: Re: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) Thread-Topic: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) Thread-Index: Ac0523r/GbfZWwFcT5O7XZjWvVrKyg== Message-ID: References: <201205241756.q4OHuqIV042399@gateway.ipv6.occnc.com> In-Reply-To: <201205241756.q4OHuqIV042399@gateway.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Iftekhar Hussain , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 20:18:28 -0000 On May 24, 2012, at 10:56 , Curtis Villamizar wrote: > In the discussion of the CL framework, a suggestion was made to change > the requirements. Please comment on this suggestion. >=20 > The following would be added somewhere. >=20 > Load balancing MAY be used during sustained low traffic periods to > reduce the number of active component links for the purpose of power > reduction. Is the intent: Load balancing MAY be _changed_ during sustained low traffic periods to reduce the number of active component links ... ? If so, a warning ("this may result in some packets being reordered, and a c= hange in delay and jitter of some flows") should probably be added. Kireeti. From kireeti@juniper.net Thu May 24 14:22:30 2012 Return-Path: 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 D735411E80B6 for ; Thu, 24 May 2012 14:22:30 -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 TNeKHir43HTj for ; Thu, 24 May 2012 14:22:30 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id E5FA011E8081 for ; Thu, 24 May 2012 14:22:29 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKT76mjmt3HY4T3/UWFOTJVPXRaTKBUKo7@postini.com; Thu, 24 May 2012 14:22:29 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 24 May 2012 14:18:09 -0700 From: Kireeti Kompella To: "curtis@occnc.com" Date: Thu, 24 May 2012 14:18:08 -0700 Subject: Re: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) Thread-Topic: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) Thread-Index: Ac058rd+c2AnwP+iQrOiv3MJdn3D/g== Message-ID: References: <201205241956.q4OJu4JF046481@gateway.ipv6.occnc.com> In-Reply-To: <201205241956.q4OJu4JF046481@gateway.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Iftekhar Hussain , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 21:22:30 -0000 Hi Curtis, On May 24, 2012, at 12:56 , Curtis Villamizar wrote: > I see your point except that I don't see this as quite a big a > deviation from "normal" load balancing. Shouldn't have said "normal"; shutting off a component doesn't make it "abn= ormal". > For example, if there are N components, then one could configure the > CL to shut off a component if a condition is met. My point is simply, shutting off a component means changing the load balanc= ing algorithm. Depending on how that's done, either the set of flows on th= e component being shut off, or all flows, will be affected. Resuming the use of a shut-off component similarly affects some (or all) fl= ows. An implementor may want to consider the trade-offs of saving power but affe= cting flows vs. not. Kireeti. From lucy.yong@huawei.com Thu May 24 14:24:52 2012 Return-Path: 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 E2D9E21F8454 for ; Thu, 24 May 2012 14:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 6txGRxW6MB8z for ; Thu, 24 May 2012 14:24:52 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5372921F843A for ; Thu, 24 May 2012 14:24:52 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGM81208; Thu, 24 May 2012 17:24:45 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 14:23:49 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Thu, 24 May 2012 14:23:46 -0700 From: Lucy yong To: Kireeti Kompella , "curtis@occnc.com" Subject: RE: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) Thread-Topic: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) Thread-Index: AQHNOdbxVdxVar5XdU2nTRLjM8h9R5bZuJ8A//+1W+A= Date: Thu, 24 May 2012 21:23:45 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3310A8F6@dfweml506-mbx> References: <201205241756.q4OHuqIV042399@gateway.ipv6.occnc.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Iftekhar Hussain , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 21:24:53 -0000 I do not concern much on this because during low traffic period, it is ofte= n the case that the number of flows inside of TE tunnel are reduced dramati= cally over the network than the case that a flow size change dramatically b= etween high traffic period and low traffic period. If operator want to cons= olidate the traffic and shutdown some component links during low traffic pe= riod, it should not cause BIG impact but bring the cost reduction. Of cause= , operator will need to manage the frequency of switching to minimize the i= mpact. =20 Lucy -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of K= ireeti Kompella Sent: Thursday, May 24, 2012 1:32 PM To: curtis@occnc.com Cc: Iftekhar Hussain; rtgwg@ietf.org Subject: Re: change to requirements (was Re: draft-so-yong-rtgwg-cl-framewo= rk) On May 24, 2012, at 10:56 , Curtis Villamizar wrote: > In the discussion of the CL framework, a suggestion was made to change > the requirements. Please comment on this suggestion. >=20 > The following would be added somewhere. >=20 > Load balancing MAY be used during sustained low traffic periods to > reduce the number of active component links for the purpose of power > reduction. Is the intent: Load balancing MAY be _changed_ during sustained low traffic periods to reduce the number of active component links ... ? If so, a warning ("this may result in some packets being reordered, and a c= hange in delay and jitter of some flows") should probably be added. Kireeti. _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From lucy.yong@huawei.com Thu May 24 14:33:12 2012 Return-Path: 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 E28DD11E80D5 for ; Thu, 24 May 2012 14:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 zja1hweqe2xX for ; Thu, 24 May 2012 14:33:10 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id ACBBF11E80C0 for ; Thu, 24 May 2012 14:33:10 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGM81748; Thu, 24 May 2012 17:33:10 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 14:29:27 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Thu, 24 May 2012 14:29:30 -0700 From: Lucy yong To: Kireeti Kompella , "curtis@occnc.com" Subject: RE: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) Thread-Topic: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) Thread-Index: AQHNOedAVdxVar5XdU2nTRLjM8h9R5bZ5vgA//+MfNA= Date: Thu, 24 May 2012 21:29:30 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3310A90E@dfweml506-mbx> References: <201205241956.q4OJu4JF046481@gateway.ipv6.occnc.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Iftekhar Hussain , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 21:33:12 -0000 Snip.. My point is simply, shutting off a component means changing the load balanc= ing algorithm. Depending on how that's done, either the set of flows on th= e component being shut off, or all flows, will be affected. [[LY]] This depends how the load balancing is implemented. It is not necess= ary to impact all the flows. The set of flows on the component being shut o= ff have to be moved to other components for sure. Resuming the use of a shut-off component similarly affects some (or all) fl= ows. [[LY]] Again, this may not be true, depending on the implementation. An implementor may want to consider the trade-offs of saving power but affe= cting flows vs. not. [[LY]] absolutely. Lucy Kireeti. _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From curtis@occnc.com Thu May 24 14:33:30 2012 Return-Path: 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 4FEDD11E80DE for ; Thu, 24 May 2012 14:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 bZ3ptZ+KyQ73 for ; Thu, 24 May 2012 14:33:29 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 8248B11E80C0 for ; Thu, 24 May 2012 14:33:29 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q4OLXPg2049546; Thu, 24 May 2012 14:33:25 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201205242133.q4OLXPg2049546@gateway.ipv6.occnc.com> To: Kireeti Kompella From: Curtis Villamizar Subject: Re: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) In-reply-to: Your message of "Thu, 24 May 2012 11:31:48 PDT." Date: Thu, 24 May 2012 17:33:25 -0400 Cc: "rtgwg@ietf.org" , Iftekhar Hussain X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 21:33:30 -0000 In message Kireeti Kompella writes: > On May 24, 2012, at 10:56 , Curtis Villamizar wrote: > > > In the discussion of the CL framework, a suggestion was made to change > > the requirements. Please comment on this suggestion. > > > > The following would be added somewhere. > > > > Load balancing MAY be used during sustained low traffic periods to > > reduce the number of active component links for the purpose of power > > reduction. > > Is the intent: > > Load balancing MAY be _changed_ during sustained low traffic > periods to reduce the number of active component links ... > > ? > > If so, a warning ("this may result in some packets being reordered, > and a change in delay and jitter of some flows") should probably be > added. > > Kireeti. Kireeti, You are correct that any change would be minimally disruptive. In the example I gave there could be no more than one change in 20 minutes, but still more than zero. I personally don't think a warning is needed here, but if you and/or others feel it is needed I have no objections to adding it. The text would then be: [FR#N] Load balancing MAY be used during sustained low traffic periods to reduce the number of active component links for the purpose of power reduction. As with any load balancing change, a change initiated for the purpose of power reduction may be minimally disruptive. Typically the disruption is limited to a change in delay characteristics and the potential for a very brief period with traffic reordering. The network operator when configuring a network for power reduction should weight the benefit of power reduction against the disadvantage of a minimal disruption. The first paragraph is a requirement. The second paragraph is discussion and should not appear within a numbered list of requirements. I would like comments from you and others. Do we need to add this requirement? If so do we need to add this warning? Curtis From IHussain@infinera.com Thu May 24 14:47:13 2012 Return-Path: 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 E31C011E80C6 for ; Thu, 24 May 2012 14:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[AWL=3.800, BAYES_00=-2.599] 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 IBxPYuNiufnD for ; Thu, 24 May 2012 14:47:13 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF4C11E80A3 for ; Thu, 24 May 2012 14:47:13 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0283.003; Thu, 24 May 2012 14:47:12 -0700 From: Iftekhar Hussain To: "curtis@occnc.com" , Kireeti Kompella Subject: RE: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) Thread-Topic: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) Thread-Index: AQHNOfTZENz7h4qBdECRbAx9q7WQ55bZdv2A Date: Thu, 24 May 2012 21:47:11 +0000 Message-ID: References: Your message of "Thu, 24 May 2012 11:31:48 PDT." <201205242133.q4OLXPg2049546@gateway.ipv6.occnc.com> In-Reply-To: <201205242133.q4OLXPg2049546@gateway.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 21:47:14 -0000 Curtis, I also think, it would be a good idea to indicate the consequences of such = load balancing change (if this event is going to cause service disruption).= FR#4 and FR#12 might be relevant. Regards, Iftekhar -----Original Message----- From: Curtis Villamizar [mailto:curtis@occnc.com]=20 Sent: Thursday, May 24, 2012 2:33 PM To: Kireeti Kompella Cc: curtis@occnc.com; Iftekhar Hussain; rtgwg@ietf.org Subject: Re: change to requirements (was Re: draft-so-yong-rtgwg-cl-framewo= rk) In message Kireeti Kompella writes: =20 > On May 24, 2012, at 10:56 , Curtis Villamizar wrote: > =20 > > In the discussion of the CL framework, a suggestion was made to=20 > > change the requirements. Please comment on this suggestion. > >=20 > > The following would be added somewhere. > >=20 > > Load balancing MAY be used during sustained low traffic periods to =20 > > reduce the number of active component links for the purpose of power =20 > > reduction. > =20 > Is the intent: > =20 > Load balancing MAY be _changed_ during sustained low traffic > periods to reduce the number of active component links ... > =20 > ? > =20 > If so, a warning ("this may result in some packets being reordered,=20 > and a change in delay and jitter of some flows") should probably be=20 > added. > =20 > Kireeti. Kireeti, You are correct that any change would be minimally disruptive. In the exam= ple I gave there could be no more than one change in 20 minutes, but still = more than zero. I personally don't think a warning is needed here, but if you and/or others= feel it is needed I have no objections to adding it. The text would then = be: [FR#N] Load balancing MAY be used during sustained low traffic periods to reduce the number of active component links for the purpose of power reduction. As with any load balancing change, a change initiated for the purpose of power reduction may be minimally disruptive. Typically the disruption is limited to a change in delay characteristics and the potential for a very brief period with traffic reordering. The network operator when configuring a network for power reduction should weight the benefit of power reduction against the disadvantage of a minimal disruption. The first paragraph is a requirement. The second paragraph is discussion a= nd should not appear within a numbered list of requirements. I would like comments from you and others. Do we need to add this requirem= ent? If so do we need to add this warning? Curtis From lucy.yong@huawei.com Thu May 24 14:52:17 2012 Return-Path: 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 E84F021F8473 for ; Thu, 24 May 2012 14:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 3dAXCfKAMNZd for ; Thu, 24 May 2012 14:52:17 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3111321F8469 for ; Thu, 24 May 2012 14:52:17 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGF82426; Thu, 24 May 2012 17:52:16 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 May 2012 14:50:46 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Thu, 24 May 2012 14:50:43 -0700 From: Lucy yong To: "curtis@occnc.com" , Kireeti Kompella Subject: RE: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) Thread-Topic: change to requirements (was Re: draft-so-yong-rtgwg-cl-framework) Thread-Index: AQHNOfTZVdxVar5XdU2nTRLjM8h9R5bZdr8g Date: Thu, 24 May 2012 21:50:43 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3310A954@dfweml506-mbx> References: Your message of "Thu, 24 May 2012 11:31:48 PDT." <201205242133.q4OLXPg2049546@gateway.ipv6.occnc.com> In-Reply-To: <201205242133.q4OLXPg2049546@gateway.ipv6.occnc.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Iftekhar Hussain , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 21:52:18 -0000 My preference is to add this requirement in the req. draft and add the warn= ing in the framework draft when describing load balancing. Load balancing a= lgorithm needs consider minimum impact when lost a component link or compon= ent link addition. This can happen when a component link fails or adding a = new component link. This is not just for shutting off component link for en= ergy saving. Lucy -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of C= urtis Villamizar Sent: Thursday, May 24, 2012 4:33 PM To: Kireeti Kompella Cc: rtgwg@ietf.org; Iftekhar Hussain Subject: Re: change to requirements (was Re: draft-so-yong-rtgwg-cl-framewo= rk) In message Kireeti Kompella writes: =20 > On May 24, 2012, at 10:56 , Curtis Villamizar wrote: > =20 > > In the discussion of the CL framework, a suggestion was made to change > > the requirements. Please comment on this suggestion. > >=20 > > The following would be added somewhere. > >=20 > > Load balancing MAY be used during sustained low traffic periods to > > reduce the number of active component links for the purpose of power > > reduction. > =20 > Is the intent: > =20 > Load balancing MAY be _changed_ during sustained low traffic > periods to reduce the number of active component links ... > =20 > ? > =20 > If so, a warning ("this may result in some packets being reordered, > and a change in delay and jitter of some flows") should probably be > added. > =20 > Kireeti. Kireeti, You are correct that any change would be minimally disruptive. In the example I gave there could be no more than one change in 20 minutes, but still more than zero. I personally don't think a warning is needed here, but if you and/or others feel it is needed I have no objections to adding it. The text would then be: [FR#N] Load balancing MAY be used during sustained low traffic periods to reduce the number of active component links for the purpose of power reduction. As with any load balancing change, a change initiated for the purpose of power reduction may be minimally disruptive. Typically the disruption is limited to a change in delay characteristics and the potential for a very brief period with traffic reordering. The network operator when configuring a network for power reduction should weight the benefit of power reduction against the disadvantage of a minimal disruption. The first paragraph is a requirement. The second paragraph is discussion and should not appear within a numbered list of requirements. I would like comments from you and others. Do we need to add this requirement? If so do we need to add this warning? Curtis _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From akatlas@gmail.com Wed May 30 09:58:56 2012 Return-Path: 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 9EE8811E80A4 for ; Wed, 30 May 2012 09:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 9ij60BXCLZyr for ; Wed, 30 May 2012 09:58:56 -0700 (PDT) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by ietfa.amsl.com (Postfix) with ESMTP id ED12E11E8099 for ; Wed, 30 May 2012 09:58:55 -0700 (PDT) Received: by ghbz22 with SMTP id z22so47251ghb.27 for ; Wed, 30 May 2012 09:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pMYI4n2CjwMNVKsaSeqSvkz3v0rZPPW5CWCHwDjZBzQ=; b=YOdJ7zk6o0d/bFaqClJkx2T6pWp3MUGq9ttnV2joNWYhvt+GRY8VikCy4E3K82jihc RxXQM13ZzmM0Wfosn/fcSs1edTpssf8JisqUOaRtvuDi2rRz14TQRbtGT9JxQSEktPPP c/+uWfD8IVAnYMWNcpowNBRvtrWhNQfpuwfSWFn7PoxCf45gZmZEOlWP3qrAauhUOacP zNCkTEwUPEbER1cYtlfUxQy7HwJDkDUve4WgtWT5ZveVA/TLKxe3gXunCahVUvRUrAtX cwLQ+khAtX+rRxwfjaZndP9ZKUGlVnrHwuCaS49LmB4qKZQVHMuQYqbL3F4cESXTqkbe Zv/Q== MIME-Version: 1.0 Received: by 10.42.130.199 with SMTP id w7mr10045126ics.23.1338397135225; Wed, 30 May 2012 09:58:55 -0700 (PDT) Received: by 10.50.34.162 with HTTP; Wed, 30 May 2012 09:58:55 -0700 (PDT) Date: Wed, 30 May 2012 12:58:55 -0400 Message-ID: Subject: opinions on adoption of draft-shand-remote-lfa as a WG draft From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 16:58:56 -0000 draft-shand-remote-lfa was presented favorably this last IETF. There is known IPR associated with it on file ( https://datatracker.ietf.org/ipr/1770/ ) This draft presents a solution for IP/LDP fast-reroute that does not guarantee 100% coverage but can substantially improve coverage over LFAs. We would like to initiate a WG poll to determine whether to adopt draft-shand-remote-lfa. We are, of course, interested in opinions and reasoning rather than simple yes/no. Thanks, Alia From zali@cisco.com Wed May 30 10:06:25 2012 Return-Path: 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 2766F21F8623 for ; Wed, 30 May 2012 10:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 5sEWq0XUX7cG for ; Wed, 30 May 2012 10:06:24 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6878921F85C4 for ; Wed, 30 May 2012 10:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zali@cisco.com; l=985; q=dns/txt; s=iport; t=1338397584; x=1339607184; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=s0KjF6CqpE7qVUCzRhofbaOE4suMOV9IO+U/J14xhb0=; b=D46E+DDcVPsO7LCKxI0/uSGDHrveaEusI+rwgxmUm4ZRMkpDBl2AOjL0 eq6VLg2K+wdjfqFR3LhYnKZuVw4O8aly8ocBUHPNjf4MQDOb8uGwc7NMe /pAw+7nXaTirPERD7kz184uH1h9NEwjfJ39cRgcfLUnj0hWE8gHARpJ5b c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAExSxk+tJXG8/2dsb2JhbABEtBGBB4IXAQEBBAEBAQ8BHQo0FwQCAQgOAwQBAQsGFwEGASYfCQgBAQQBEggTB4dpC5kYoAAEiwWEYmADiECaZYFmgn4 X-IronPort-AV: E=Sophos;i="4.75,685,1330905600"; d="scan'208";a="88020662" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 30 May 2012 17:06:24 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4UH6OZt021560; Wed, 30 May 2012 17:06:24 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 May 2012 12:06:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: opinions on adoption of draft-shand-remote-lfa as a WG draft Date: Wed, 30 May 2012 12:06:22 -0500 Message-ID: <7CC717E2F49DAA4A827DA3FEA237111B07F89630@XMB-RCD-103.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Index: Ac0+hYMVlL8N+pGSQgi424hvWjaBVAAAPS2w References: From: "Zafar Ali (zali)" To: "Alia Atlas" , X-OriginalArrivalTime: 30 May 2012 17:06:23.0844 (UTC) FILETIME=[8AC6DA40:01CD3E86] X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 17:06:25 -0000 Support,=20 Thanks Regards ... Zafar=20 > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > Of Alia Atlas > Sent: Wednesday, May 30, 2012 12:59 PM > To: rtgwg@ietf.org > Subject: opinions on adoption of draft-shand-remote-lfa as a WG draft >=20 > draft-shand-remote-lfa was presented favorably this last IETF. There > is known IPR > associated with it on file ( https://datatracker.ietf.org/ipr/1770/ ) > This draft presents > a solution for IP/LDP fast-reroute that does not guarantee 100% > coverage but can substantially > improve coverage over LFAs. >=20 > We would like to initiate a WG poll to determine whether to adopt > draft-shand-remote-lfa. > We are, of course, interested in opinions and reasoning rather than > simple yes/no. >=20 > Thanks, > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From Andras.Csaszar@ericsson.com Thu May 31 00:30:54 2012 Return-Path: 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 09D4821F8667 for ; Thu, 31 May 2012 00:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 6tewf8mVHTkb for ; Thu, 31 May 2012 00:30:53 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D2B6A21F866A for ; Thu, 31 May 2012 00:30:52 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-b1-4fc71e2b5849 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 13.96.00702.B2E17CF4; Thu, 31 May 2012 09:30:52 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.227]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 31 May 2012 09:30:51 +0200 From: =?utf-8?B?QW5kcsOhcyBDc8Ohc3rDoXI=?= To: Alia Atlas , "rtgwg@ietf.org" Date: Thu, 31 May 2012 09:30:49 +0200 Subject: RE: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Topic: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Index: Ac0+hYIIou84HfCjSlGKLgbxE3lNkwAcwfDQ Message-ID: <8DCD771BDA4A394E9BCBA8932E839297783CF647D0@ESESSCMS0363.eemea.ericsson.se> References: In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvra6O3HF/g9N/GS0+PbzEbHHhzW9m ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvjQ98KtoJjyhW33/M3MF5Q6mLk5JAQMJFY uG4uC4QtJnHh3nq2LkYuDiGBU4wSm++uhnIWMkp0/1/NCFLFJuAhcf/6X2YQW0TAVeJX9xd2 EJtFQFXizILTYJOEBTwl1h8+zgZR4yWxbMsHqHojid4/X8Hm8AqESxz/fBWsRkggQGLK7D4w m1MgUOLWxHNAczg4GAVkJR6utQAJMwuIS9x6Mp8J4lABiSV7zjND2KISLx//YwWxGQVkJD4s PcQG0sosoCmxfpc+RKuixJTuh+wQWwUlTs58wjKBUXQWkqmzEDpmIemYhaRjASPLKkbh3MTM nPRyc73Uoszk4uL8PL3i1E2MwOg4uOW3wQ7GTffFDjFKc7AoifPqqe73FxJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cC43y+qjj/Uw+UCk/9kobLfj8wOvOQ4aBPUZ3fqvNLP/zvFs1JWd5QF vr/qbrd4vYXQtxmLuz8/q77TfeJLwFfRlichXqvVnwudMq9ZXXQlJMv8NMcx3mAGhukbgpiC 7m8/EOv9SvO89+ZP3Q8OWbC//3F4g/hf7p6cfRsUbs1h+MCX1bV+o0O2EktxRqKhFnNRcSIA lT5pCFwCAAA= X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 07:30:54 -0000 SGkgQWxpYSBhbmQgQWxsLA0KDQoNCkluc3RlYWQgb2Ygc2F5aW5nIGFuIGV4cGxpY2l0IHllcyBv ciBubyBqdXN0IG5vdywgaGVyZSBhcmUgdGhlIHBvc3RpdmVzIEkgc2VlIGFuZCB0aGUgdGhpbmdz IHRoYXQgYm90aGVyIG1lLg0KDQpQb3NpdGl2ZToNCg0KKEEpIEFsZ29yaXRobWljIHNpbXBsaWNp dHksIHN0cmFpZ2h0Zm9yd2FyZCB0byB1bmRlcnN0YW5kDQoNCihCKSBJIHN1c3BlY3QgdGhhdCBp biBhIHJlZHVuZGFudCBuZXR3b3JrICh3aXRoIG5vIGN1dC1saW5rcyBhbmQgbm8gY3V0LW5vZGVz KSBpZiBsaW5rIGNvc3RzIGFyZSBlcXVhbCAodW5pdCksIHRoZW4gYWN0dWFsbHkgaXQgcHJvdmlk ZXMgfjEwMCUgY292ZXJhZ2UNCg0KKEMpIEl0IGlzIGEgbm9kZS1pbnRlcm5hbCBzb2x1dGlvbiwg bm90IHJlcXVpcmluZyBjb29wIHdpdGggYW55dGhpbmcuDQoNCg0KDQpXaGF0IGJvdGhlcnM6DQoN CihEKSBQb3RlbnRpYWxseSBiaWcgbnVtYmVyIG9mIHRhcmdldGVkIExEUCBzZXNzaW9ucw0KDQoo RSkgSW5hYmlsaXR5IHRvIHByb3ZpZGUgMTAwJSBjb3ZlcmFnZSB3aXRoIGFyYml0cmFyeSBjb3N0 IHN0cnVjdHVyZQ0KDQooRikgUHJlc2VudGVkIGNvdmVyYWdlIHZhbHVlcyBhcmUgbm90IGZ1bGx5 IGNvbnZpbmNpbmcgZHVlIHRvIHNldmVyYWwgcmVhc29ucyAoaWYgSSB3YXMganVzdCBtaXNzaW5n IHJlc3VsdHMsIHRoZW4gc29ycnkhKToNCg0KICAoRjEpIE9ubHkgcmVsYXRpdmVseSBkZW5zZSBj b3JlLWxpa2UgdG9wb2xvZ2llcyBoYXZlIGJlZW4gaW52ZXN0aWdhdGVkLCB3aGVyZSBMRkEgaXMg bW9zdGx5IGdvb2QgZW5vdWdoIGFueXdheS4gSG93ZXZlciwgSVAvTVBMUyBpcyBnZXR0aW5nIHB1 c2hlZCB0byB0aGUgYWdncmVnYXRpb24vYWNjZXNzLCB3aGVyZSB0aGUgdG9wb2xvZ3kgaXMgZmFy IGZyb20gYmVpbmcgdGhhdCBzcGFyc2UsIHRoZXJlIEFSRSByaW5ncyBhbmQgdGhlcmUgYXJlIChz cGFyc2UpIHRyZWUtbGlrZSB0b3BvbG9naWVzIHdoaWNoIGFyZSBleHRlbmRlZCB3aXRoIGEgZmV3 IGxpbmtzIGhlcmUgYW5kIHRoZXJlIHRvIGJvb3N0IHJlZHVuZGFuY3kuIEhvdyBkb2VzIGl0IHdv cmsgaW4gc3VjaCByZWxhdGl2ZWx5IHNwYXJzZSB0b3Bvcz8NCg0KICAoRjIpIEJpZGlyZWN0aW9u YWwgY292ZXJhZ2Ugd2FzIG5vdCBpbnZlc3RpZ2F0ZWQgKGkuZS4gZm9yIExGQSBpdCB3YXMgcXVp dGUgbGlrZWx5IHRoYXQgaW4gYSBub3Qtc28gZGVuc2UgdG9wb2xvZ3ksIGlmIGEgZmFpbHVyZSB3 YXMgY292ZXJlZCBpbiBvbmUgZGlyZWN0aW9uLCBpdCB3YXMgbm90IGNvdmVyZWQgaW4gdGhlIG90 aGVyIG9uZSwgbWVhbmluZyB0aGF0IGZvciBtb3N0IGJpZGlyIHRyYWZmaWMgaXQncyBub3Qgb2Yg dG9vIG11Y2ggdmFsdWUpDQoNCiAgKEYzKSBFdmVuIGlmIGFuIG9wZXJhdG9yIHR1bmVzIGl0cyB0 b3BvIHRvIGhhdmUgaGlnaCBSTEZBIGNvdmVyYWdlLCBhIHRvcG8gY2hhbmdlIG1pZ2h0IHJ1aW4g aXQgKGUuZy4gZmFpbHVyZXMsIGV0Yy4pLiBTbywgd2hhdCB3b3VsZCBiZSB2ZXJ5IHVzZWZ1bCBp cyB0byBzZWUgbnVtYmVycyBvbiB2YXJpb3VzIHRvcG9sb2dpZXMgaG93IGEgaGlnaCBjb3ZlcmFn ZSB2YWx1ZSBjaGFuZ2VzIHdpdGggYSBzbWFsbCBtb2RpZmljYXRpb24gb2YgdGhlIHRvcG9sb2d5 IChlLmcuIG9uZSBvciB0d28gZmFpbHVyZXMuLi4pDQoNCihHKSBIYXZlIG5vdCB5ZXQgc2VlbiBw YXBlcnMvZ3VpZGVsaW5lcyBob3cgdG8gdHVuZSB0aGUgbmV0d29yayB0byBiZSBtb3JlIFJMRkEg ZnJpZW5kbHkgKHdoaWNoIGlzIHBvc3NpYmxlLCBzZWUgZS5nLiAoQikpDQoNCihIKSBUaGUgZHJh ZnQgZG9lcyBub3QgbWVudGlvbiBTUkxHcyBvciBtdWx0aWNhc3QuIA0KDQoNCkkgZG8gdW5kZXJz dGFuZCB0aGF0IGFjY2VwdGluZyBpdCBhcyBhIFdHIGl0ZW0gc3RpbGwgbGVhdmVzIHRoZSBvcHBv cnR1bml0eSB0byBhbnN3ZXIgc29tZSBvZiB0aGVzZSBjb25jZXJucy4NCg0KDQpJZiB3ZSBhZG9w dCBpdCwgSSB0aGluayB3ZSBzaG91bGQgZ2l2ZSBndWlkZWxpbmVzIG9uIHRoZSBSTEZBIGZyaWVu ZGx5IHRvcG9sb2dpZXMgYW5kIGNvc3Qgc3RydWN0dXJlcy4NCg0KDQpBbmQsIGZpbmFsbHkgYSBt b3JlIGFkbWluaXN0cmF0aXZlIHF1ZXN0aW9uOiB3aHkgZG9lcyBpdCBuZWVkIHRvIGJlIFN0YW5k YXJkcyBUcmFjaz8gTmVpdGhlciBMRkEsIG5vciBSTEZBIGRvIG5vdCByZXF1aXJlIGFueSBzb3J0 IG9mIGNvb3BlcmF0aW9uIHdpdGggYW55IG90aGVyIGVudGl0eTogd2hhdCBuZWVkcyB0byBiZSBh IHN0YW5kYXJkIGluIHRoZWlyIGNhc2VzPyBCb3RoIHNvdW5kIGxpa2UgYSBub2RlLWludGVybmFs IGZlYXR1cmUgb3IgYSBiZXN0IHByYWN0aWNlIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQuDQoNCg0K QW5kcsOhcw0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBydGd3 Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRnd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmDQo+IE9mIEFsaWEgQXRsYXMNCj4gU2VudDogMjAxMi4gbcOhanVzIDMwLiAxODo1OQ0KPiBU bzogcnRnd2dAaWV0Zi5vcmcNCj4gU3ViamVjdDogb3BpbmlvbnMgb24gYWRvcHRpb24gb2YgZHJh ZnQtc2hhbmQtcmVtb3RlLWxmYSBhcyBhIFdHIGRyYWZ0DQo+IA0KPiBkcmFmdC1zaGFuZC1yZW1v dGUtbGZhIHdhcyBwcmVzZW50ZWQgZmF2b3JhYmx5IHRoaXMgbGFzdCBJRVRGLiAgVGhlcmUgaXMN Cj4ga25vd24gSVBSIGFzc29jaWF0ZWQgd2l0aCBpdCBvbiBmaWxlICgNCj4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9pcHIvMTc3MC8gKSAgVGhpcyBkcmFmdCBwcmVzZW50cyBhIHNvbHV0 aW9uDQo+IGZvciBJUC9MRFAgZmFzdC1yZXJvdXRlIHRoYXQgZG9lcyBub3QgZ3VhcmFudGVlIDEw MCUgY292ZXJhZ2UgYnV0IGNhbg0KPiBzdWJzdGFudGlhbGx5IGltcHJvdmUgY292ZXJhZ2Ugb3Zl ciBMRkFzLg0KPiANCj4gV2Ugd291bGQgbGlrZSB0byBpbml0aWF0ZSBhIFdHIHBvbGwgdG8gZGV0 ZXJtaW5lIHdoZXRoZXIgdG8gYWRvcHQgZHJhZnQtDQo+IHNoYW5kLXJlbW90ZS1sZmEuDQo+IFdl IGFyZSwgb2YgY291cnNlLCBpbnRlcmVzdGVkIGluIG9waW5pb25zIGFuZCByZWFzb25pbmcgcmF0 aGVyIHRoYW4NCj4gc2ltcGxlIHllcy9uby4NCj4gDQo+IFRoYW5rcywNCj4gQWxpYQ0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBydGd3ZyBtYWls aW5nIGxpc3QNCj4gcnRnd2dAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGd3Zw0K From stephane.litkowski@orange.com Thu May 31 00:34:31 2012 Return-Path: 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 4BA6E21F8667 for ; Thu, 31 May 2012 00:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 x1z1ZmUriKdH for ; Thu, 31 May 2012 00:34:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 85BF821F8666 for ; Thu, 31 May 2012 00:34:30 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 02EE73B44F9; Thu, 31 May 2012 09:34:29 +0200 (CEST) Received: from puexcc31.nanterre.francetelecom.fr (unknown [10.168.74.8]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id CB33435C064; Thu, 31 May 2012 09:34:28 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc31.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 May 2012 09:34:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: opinions on adoption of draft-shand-remote-lfa as a WG draft Date: Thu, 31 May 2012 09:34:27 +0200 Message-ID: <27906_1338449668_4FC71F04_27906_299_1_4FC3556A36EE3646A09DAA60429F5335086126CC@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Index: Ac0+hYIiKIxF1l9yTgSgfx0M2O1ZcwAedDwA References: From: To: "Alia Atlas" , X-OriginalArrivalTime: 31 May 2012 07:34:28.0850 (UTC) FILETIME=[CFDC0D20:01CD3EFF] X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.5.24.112414 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 07:34:31 -0000 Strong support, Our simulations show 100% percent coverage using remote LFA : our core netw= ork topo are complex and not very LFA friendly but remote LFA works very we= ll ! Solution is quite simple, automatic as LFA is basically ... We are currentl= y working with vendors for implementations (for those who are not already i= mplementing it ...)=20 -----Message d'origine----- De : rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] De la part de A= lia Atlas Envoy=E9 : mercredi 30 mai 2012 18:59 =C0 : rtgwg@ietf.org Objet : opinions on adoption of draft-shand-remote-lfa as a WG draft draft-shand-remote-lfa was presented favorably this last IETF. There is kn= own IPR associated with it on file ( https://datatracker.ietf.org/ipr/1770/= ) This draft presents a solution for IP/LDP fast-reroute that does not gu= arantee 100% coverage but can substantially improve coverage over LFAs. We would like to initiate a WG poll to determine whether to adopt draft-sha= nd-remote-lfa. We are, of course, interested in opinions and reasoning rather than simple = yes/no. Thanks, Alia _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From stephane.litkowski@orange.com Thu May 31 01:34:00 2012 Return-Path: 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 A2A6D21F869D for ; Thu, 31 May 2012 01:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001] 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 4lrkk69bnlW2 for ; Thu, 31 May 2012 01:33:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8F821F866C for ; Thu, 31 May 2012 01:33:52 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 2FCA026443A; Thu, 31 May 2012 10:33:51 +0200 (CEST) Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0720B23806F; Thu, 31 May 2012 10:33:51 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 May 2012 10:33:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: opinions on adoption of draft-shand-remote-lfa as a WG draft Date: Thu, 31 May 2012 10:33:01 +0200 Message-ID: <31979_1338453231_4FC72CEF_31979_8499_3_4FC3556A36EE3646A09DAA60429F533508612770@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <8DCD771BDA4A394E9BCBA8932E839297783CF647D0@ESESSCMS0363.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Index: Ac0+hYIIou84HfCjSlGKLgbxE3lNkwAcwfDQAAMBo0A= References: <8DCD771BDA4A394E9BCBA8932E839297783CF647D0@ESESSCMS0363.eemea.ericsson.se> From: To: =?iso-8859-1?B?QW5kcuFzIENz4XN64XI=?= , "Alia Atlas" , X-OriginalArrivalTime: 31 May 2012 08:33:51.0274 (UTC) FILETIME=[1B3AD0A0:01CD3F08] X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.5.31.34516 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 08:34:00 -0000 Some feedback : > (D) Potentially big number of targeted LDP sessions [SLI] Based on our simulation, only 4 T-LDP sessions at max is needed (for = our case), 2 or 1 only in most cases. (now routers are able to handle hundr= eds of LDP sessions without issue, so adding few is not a big deal) > (E) Inability to provide 100% coverage with arbitrary cost structure [SLI] What do you mean exactly ? Do you mean that with some topology, you a= re unable to have 100% coverage ? Yes, few topologies can't work with rLFA = as for LFA ... But is it really an issue ? I'm always trying to see simplic= ity vs gain ... As you mention rLFA is still an easy mechanism (as LFA is .= ..), it would provide you strong coverage extension.=20 Note that as already mentionned in the draft (and I'm currently writing som= e more detail stuff on this), it is still possible to achieve 100% coverage= but you should add explicit TE tunnel (implementation may be able to propo= se to establish it dynamically if it becomes a need). (F) Presented coverage values are not fully convincing due to several reaso= ns (if I was just missing results, then sorry!): (F1) Only relatively dense core-like topologies have been investigated, w= here LFA is mostly good enough anyway. However, IP/MPLS is getting pushed t= o the aggregation/access, where the topology is far from being that sparse,= there ARE rings and there are (sparse) tree-like topologies which are exte= nded with a few links here and there to boost redundancy. How does it work = in such relatively sparse topos? [SLI] It is already planned as far as I know to add new use cases within th= e doc. I can already say that rLFA works very well with rings. We have plen= ty variety of rings with different metric patterns, different size of ring,= and LFA provides 100% coverage in all of these cases (bidirectional). (F3) Even if an operator tunes its topo to have high RLFA coverage, a top= o change might ruin it (e.g. failures, etc.). So, what would be very useful= is to see numbers on various topologies how a high coverage value changes = with a small modification of the topology (e.g. one or two failures...) [SLI] This is clearly a good point, I think most people are already aware o= f (I hope :) ), as it concerns already LFA ... If you have a good coverage = with your nominal topo, a backup topology may not have a good coverage ...= =20 (G) Have not yet seen papers/guidelines how to tune the network to be more = RLFA friendly (which is possible, see e.g. (B)) [SLI] this point could be addressed easily ... I do understand that accepting it as a WG item still leaves the opportunity= to answer some of these concerns. If we adopt it, I think we should give guidelines on the RLFA friendly topo= logies and cost structures. [SLI] Doable easily and necessary ;) (I already talked about this with Clar= ence F.) > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf=20 > Of Alia Atlas > Sent: 2012. m=E1jus 30. 18:59 > To: rtgwg@ietf.org > Subject: opinions on adoption of draft-shand-remote-lfa as a WG draft >=20 > draft-shand-remote-lfa was presented favorably this last IETF. There=20 > is known IPR associated with it on file (=20 > https://datatracker.ietf.org/ipr/1770/ ) This draft presents a=20 > solution for IP/LDP fast-reroute that does not guarantee 100% coverage=20 > but can substantially improve coverage over LFAs. >=20 > We would like to initiate a WG poll to determine whether to adopt=20 > draft- shand-remote-lfa. > We are, of course, interested in opinions and reasoning rather than=20 > simple yes/no. >=20 > Thanks, > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bruno.decraene@orange.com Thu May 31 03:24:28 2012 Return-Path: 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 0D32021F866B for ; Thu, 31 May 2012 03:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, GUARANTEED_100_PERCENT=0.012, UNPARSEABLE_RELAY=0.001] 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 8wbj5jiTshfw for ; Thu, 31 May 2012 03:24:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2D78021F8646 for ; Thu, 31 May 2012 03:24:27 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 466F318C03D; Thu, 31 May 2012 12:24:26 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 2C45635C06B; Thu, 31 May 2012 12:24:26 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Thu, 31 May 2012 12:24:25 +0200 From: To: Alia Atlas Subject: RE: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Topic: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Index: AQHNPoWCxwU+8poLGU2usmf1dn0xk5bjrz5g Date: Thu, 31 May 2012 10:24:25 +0000 Message-ID: <4126_1338459866_4FC746DA_4126_7369_1_53C29892C857584299CBF5D05346208A08B03B@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.5.31.84517 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 10:24:28 -0000 Alia, Alvaro, I support adoption. As requested, below some (quickly written) opinions: Positive: ++ Incremental deployment with incremental benefits. (Eventually some focused deployments may be enough to solve the main LFA li= mitations.) + Relatively easy understanding (and possibly control) for the network oper= ator of the path taken by the traffic. Useful for capacity planning, networ= k manageability and respect of design rules (e.g. don't use a PE to backup = a P) + Relative simplicity + Can provide 100% coverage in some real networks. (at least one I am aware= of) Negative: - "esthetic": some "random" (from human design perspective) mesh of control= plane sessions. May have an impact on the management/monitoring. (e.g. how= many T-LDP sessions am I supposed on have on node XT6 ? Is one missing?). - lacks 100% guaranteed coverage. Could eventually be worked on (e.g. studi= es, addition of (virtual TE) links) but requires work :-) Positive definitely outweighs the negative. IMHO will be deployed, with or without the IETF. I would prefer with the IE= TF review and standardization. Regards, Bruno >From Alia Atlas >Sent: Wednesday, May 30, 2012 6:59 PM >Subject: opinions on adoption of draft-shand-remote-lfa as a WG draft > >draft-shand-remote-lfa was presented favorably this last IETF. There >is known IPR >associated with it on file ( https://datatracker.ietf.org/ipr/1770/ ) > This draft presents >a solution for IP/LDP fast-reroute that does not guarantee 100% >coverage but can substantially >improve coverage over LFAs. > >We would like to initiate a WG poll to determine whether to adopt >draft-shand-remote-lfa. >We are, of course, interested in opinions and reasoning rather than >simple yes/no. > >Thanks, >Alia >_______________________________________________ >rtgwg mailing list >rtgwg@ietf.org >https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From stbryant@cisco.com Thu May 31 03:36:16 2012 Return-Path: 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 1E48D21F8698 for ; Thu, 31 May 2012 03:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.652 X-Spam-Level: X-Spam-Status: No, score=-109.652 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] 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 ciyrOEWQW4pi for ; Thu, 31 May 2012 03:36:15 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 712BE21F865E for ; Thu, 31 May 2012 03:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=5924; q=dns/txt; s=iport; t=1338460574; x=1339670174; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=EiZVV8F1qvuXJZKLvGzXCuSOEFUxLLNpVqq/t20A1g4=; b=CA2S7ZVzgroF59UG6dEL1eGtIZYfyJHkGi8RmEmqwvDk+4eBi2NL7MQn A9Qdy3MlZF5sQwBfzZaNxs2FPMYUhZedkLQVITBfwHqz+jsLTwjz2yEIB qz6LY3w6ytzJFythiosDzGcz4YFFqyscFKuvQyDV08GPMBZJ4ZAiAv81u g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAFAIhIx0+Q/khL/2dsb2JhbABEhAawBYEHghgBAQEEEgECZBALGAklDwJGBg0BBQIBARcHh2mZH4NHEJwVixEChUQDlRiODYEEYoJh X-IronPort-AV: E=Sophos;i="4.75,691,1330905600"; d="scan'208,217";a="5197583" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 31 May 2012 10:36:09 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4VAa9L9028307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 May 2012 10:36:09 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q4VAa8d4013619; Thu, 31 May 2012 11:36:08 +0100 (BST) Message-ID: <4FC74998.70104@cisco.com> Date: Thu, 31 May 2012 11:36:08 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= Subject: Re: opinions on adoption of draft-shand-remote-lfa as a WG draft References: <8DCD771BDA4A394E9BCBA8932E839297783CF647D0@ESESSCMS0363.eemea.ericsson.se> <31979_1338453231_4FC72CEF_31979_8499_3_4FC3556A36EE3646A09DAA60429F533508612770@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <31979_1338453231_4FC72CEF_31979_8499_3_4FC3556A36EE3646A09DAA60429F533508612770@PUEXCBL0.nanterre.francetelecom.fr> Content-Type: multipart/alternative; boundary="------------000400050204080004030201" Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 10:36:16 -0000 This is a multi-part message in MIME format. --------------000400050204080004030201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andras I think that you omitted to note that RLFA supports incremental deployment well, and in particular needs no new protocols. This is in contrast to all of the alternatives that have been put on the table, which require the on-repair-path nodes to change. The approach proposed here is to publish RLFA in order to provide a solution for those networks that find LFA too limiting, but need a solution that they can deploy in the short term. Meanwhile we should take another look at the relative merits of MRT, not-via etc and understand whether any of them offer the sort of overwhelming advantage that would justify the deployment of a new approach that requires routing domain wide deployment. On 31/05/2012 09:33, stephane.litkowski@orange.com wrote: > (F3) Even if an operator tunes its topo to have high RLFA coverage, a > topo change might ruin it (e.g. failures, etc.). So, what would be > very useful is to see numbers on various topologies how a high > coverage value changes with a small modification of the topology (e.g. > one or two failures...) > [SLI] This is clearly a good point, I think most people are already > aware of (I hope :) ), as it concerns already LFA ... If you have a > good coverage with your nominal topo, a backup topology may not have a > good coverage ... Let's be careful here, it's not at all clear how the well the various virtual topology approaches will behave under multiple failures, since you need to concurrently manage the traffic patterns in both topologies. In any case I think that we can always construct pathological repair topologies which whilst they technically work, have properties that would be unacceptable to an operator. Rings were mentioned, and RLFA handles rings just fine. Remember that RLFA is really the viable subset of draft-bryant-ipfrr-tunnels-03, a draft where we have already explored a lot of the corner cases. The RLFA draft is a pragmatic approach that say's lets take the simple bits of the PQ technology, noting that it can be incrementally deployed, and then we have more time to think about what to do about the corner cases that LFA + RLFA cannot address. Stewart (as an RLFA author) --------------000400050204080004030201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Andras

I think that you omitted to note that RLFA supports incremental deployment
well, and in particular needs no new protocols. This is in contrast to all
of the alternatives that have been put on the table, which require the
on-repair-path nodes to change.

The approach proposed here is to publish RLFA in order to provide a
solution for those networks that find LFA too limiting, but need a
solution that they can deploy in the short term. Meanwhile we should
take another look at the relative merits of MRT, not-via etc and
understand whether any of them offer the sort of overwhelming
advantage that would justify the deployment of a new approach
that requires routing  domain wide deployment.


On 31/05/2012 09:33, stephane.litkowski@orange.com wrote:
(F3) Even if an operator tunes its topo to have high RLFA coverage, a topo change might ruin it (e.g. failures, etc.). So, what would be very useful is to see numbers on various topologies how a high coverage value changes with a small modification of the topology (e.g. one or two failures...)
[SLI] This is clearly a good point, I think most people are already aware of (I hope :) ), as it concerns already LFA ... If you have a good coverage with your nominal topo, a backup topology may not have a good coverage ...
Let's be careful here, it's not at all clear how the well the various
virtual topology approaches will behave under multiple failures,
since you need to concurrently manage the traffic patterns in
both topologies. In any case I think that we can always construct
pathological repair topologies which whilst they technically work,
have properties that would be unacceptable to an operator.

Rings were mentioned, and RLFA handles rings just fine.

Remember that RLFA is really the viable subset of
draft-bryant-ipfrr-tunnels-03, a draft where we have already explored
a lot of the corner cases. The RLFA draft is a pragmatic approach
that say's lets take the simple bits of the PQ technology, noting that it
can be incrementally deployed, and then we have more time to think
about what to do about the corner cases that LFA + RLFA cannot
address.

Stewart
(as an RLFA author)


--------------000400050204080004030201-- From pierre.francois@imdea.org Thu May 31 03:36:47 2012 Return-Path: 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 9C1EF21F8697 for ; Thu, 31 May 2012 03:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GUARANTEED_100_PERCENT=0.012] 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 g1YsRjMcF7Er for ; Thu, 31 May 2012 03:36:47 -0700 (PDT) Received: from estafeta.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id B918121F8658 for ; Thu, 31 May 2012 03:36:46 -0700 (PDT) Received: from localhost (estafeta21.imdea.org [172.17.99.144]) by estafeta21.imdea.org (Postfix) with ESMTP id C732118AEAD; Thu, 31 May 2012 12:36:35 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta.imdea.org ([172.17.99.144]) by localhost (estafeta21.imdea.org [172.17.99.144]) (amavisd-new, port 10024) with ESMTP id w8i4KCKl251Q; Thu, 31 May 2012 12:36:35 +0200 (CEST) Received: from dory-2.local (unknown [193.145.14.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta21.imdea.org (Postfix) with ESMTP id 7384018AEAC; Thu, 31 May 2012 12:36:35 +0200 (CEST) Message-ID: <4FC749B3.2070101@imdea.org> Date: Thu, 31 May 2012 12:36:35 +0200 From: Pierre Francois User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: bruno.decraene@orange.com Subject: Re: opinions on adoption of draft-shand-remote-lfa as a WG draft References: <4126_1338459866_4FC746DA_4126_7369_1_53C29892C857584299CBF5D05346208A08B03B@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <4126_1338459866_4FC746DA_4126_7369_1_53C29892C857584299CBF5D05346208A08B03B@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 10:36:47 -0000 Alia, Alvaro, +1, I think Bruno is summarizing the situation perfectly. Pierre. On 5/31/12 12:24 PM, bruno.decraene@orange.com wrote: > Alia, Alvaro, > > I support adoption. > > As requested, below some (quickly written) opinions: > > Positive: > ++ Incremental deployment with incremental benefits. > (Eventually some focused deployments may be enough to solve the main LFA limitations.) > + Relatively easy understanding (and possibly control) for the network operator of the path taken by the traffic. Useful for capacity planning, network manageability and respect of design rules (e.g. don't use a PE to backup a P) > + Relative simplicity > + Can provide 100% coverage in some real networks. (at least one I am aware of) > > > Negative: > - "esthetic": some "random" (from human design perspective) mesh of control plane sessions. May have an impact on the management/monitoring. (e.g. how many T-LDP sessions am I supposed on have on node XT6 ? Is one missing?). > - lacks 100% guaranteed coverage. Could eventually be worked on (e.g. studies, addition of (virtual TE) links) but requires work :-) > > > Positive definitely outweighs the negative. > IMHO will be deployed, with or without the IETF. I would prefer with the IETF review and standardization. > > Regards, > Bruno > > > From Alia Atlas>Sent: Wednesday, May 30, 2012 6:59 PM >> Subject: opinions on adoption of draft-shand-remote-lfa as a WG draft >> >> draft-shand-remote-lfa was presented favorably this last IETF. There >> is known IPR >> associated with it on file ( https://datatracker.ietf.org/ipr/1770/ ) >> This draft presents >> a solution for IP/LDP fast-reroute that does not guarantee 100% >> coverage but can substantially >> improve coverage over LFAs. >> >> We would like to initiate a WG poll to determine whether to adopt >> draft-shand-remote-lfa. >> We are, of course, interested in opinions and reasoning rather than >> simple yes/no. >> >> Thanks, >> Alia >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From adrian@olddog.co.uk Thu May 31 07:18:22 2012 Return-Path: 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 4FBFC21F86AA for ; Thu, 31 May 2012 07:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] 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 vriEcd7ice5O for ; Thu, 31 May 2012 07:18:21 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 8473921F866B for ; Thu, 31 May 2012 07:18:21 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q4VEIEDj005280; Thu, 31 May 2012 15:18:14 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q4VEIBSM005224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 May 2012 15:18:12 +0100 From: "Adrian Farrel" To: "'Alia Atlas'" , References: In-Reply-To: Subject: RE: opinions on adoption of draft-shand-remote-lfa as a WG draft Date: Thu, 31 May 2012 15:18:08 +0100 Message-ID: <014401cd3f38$34e231d0$9ea69570$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINsmT7m2dbJeNTi3KH28ld/EoOiZZjCzPw Content-Language: en-gb X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 14:18:22 -0000 Just a personal (non AD comment). I would prefer that polls were conducted on extant I-Ds, not ones that have expired. Cheers, Adrian > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Alia Atlas > Sent: 30 May 2012 17:59 > To: rtgwg@ietf.org > Subject: opinions on adoption of draft-shand-remote-lfa as a WG draft > > draft-shand-remote-lfa was presented favorably this last IETF. There > is known IPR > associated with it on file ( https://datatracker.ietf.org/ipr/1770/ ) > This draft presents > a solution for IP/LDP fast-reroute that does not guarantee 100% > coverage but can substantially > improve coverage over LFAs. > > We would like to initiate a WG poll to determine whether to adopt > draft-shand-remote-lfa. > We are, of course, interested in opinions and reasoning rather than > simple yes/no. > > Thanks, > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From jdrake@juniper.net Thu May 31 12:27:19 2012 Return-Path: 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 A570D21F8628 for ; Thu, 31 May 2012 12:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.277 X-Spam-Level: X-Spam-Status: No, score=-6.277 tagged_above=-999 required=5 tests=[AWL=0.322, 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 x-CzT1SfzqWC for ; Thu, 31 May 2012 12:27:19 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id F40E521F8627 for ; Thu, 31 May 2012 12:27:18 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT8fGFXXC3Uaxhd9WM4q6wovsPy1kHlLm@postini.com; Thu, 31 May 2012 12:27:19 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 31 May 2012 12:26:40 -0700 From: John E Drake To: Alia Atlas , "rtgwg@ietf.org" Date: Thu, 31 May 2012 12:26:39 -0700 Subject: RE: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Topic: opinions on adoption of draft-shand-remote-lfa as a WG draft Thread-Index: Ac0+hYWOV4jpzD3AQfWdIJeaBZ6DVwA23Atg Message-ID: <5E893DB832F57341992548CDBB333163A578C238D5@EMBX01-HQ.jnpr.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 19:27:19 -0000 Alia, I support the WG adopting draft-shand-remote-lfa. It provides a straightfo= rward, low cost, and effective extension to LFAs. Thanks, John Sent from my iPhone >-----Original Message----- >From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf >Of Alia Atlas >Sent: Wednesday, May 30, 2012 9:59 AM >To: rtgwg@ietf.org >Subject: opinions on adoption of draft-shand-remote-lfa as a WG draft > >draft-shand-remote-lfa was presented favorably this last IETF. There is >known IPR associated with it on file ( >https://datatracker.ietf.org/ipr/1770/ ) This draft presents a solution >for IP/LDP fast-reroute that does not guarantee 100% coverage but can >substantially improve coverage over LFAs. > >We would like to initiate a WG poll to determine whether to adopt draft- >shand-remote-lfa. >We are, of course, interested in opinions and reasoning rather than >simple yes/no. > >Thanks, >Alia >_______________________________________________ >rtgwg mailing list >rtgwg@ietf.org >https://www.ietf.org/mailman/listinfo/rtgwg