From acee.lindem@ericsson.com Fri Feb 1 08:41:46 2013 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 0DDA721F8F66; Fri, 1 Feb 2013 08:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKxWvHrIBEws; Fri, 1 Feb 2013 08:41:44 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id EBDBC21F8F63; Fri, 1 Feb 2013 08:41:43 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-a5-510bf047326a Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 41.87.03705.740FB015; Fri, 1 Feb 2013 17:41:43 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 11:41:42 -0500 From: Acee Lindem To: "" Subject: Re: [RTG-DIR] Routing Directorate Review of "Framework for Loop-free convergence using oFIB" Thread-Topic: [RTG-DIR] Routing Directorate Review of "Framework for Loop-free convergence using oFIB" Thread-Index: AQHN/+vjIMzOHGj7rEKXcaQ9o4gGD5hlif4A Date: Fri, 1 Feb 2013 16:41:42 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470B7F70@eusaamb101.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE470B5BF8@eusaamb101.ericsson.se> <510ACA65.9010307@cisco.com> In-Reply-To: <510ACA65.9010307@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <996F1415CE3C724DAF2DE455F808C68C@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZXLonXNf9A3egwfazihY7Z/ewWTz/eoHZ 4kbDDxaLN+/+sFksWPOU3eLCm9/MFut3P2KyOPd0DqMDh8eU3xtZPZYs+cnk8X3tNWaPV8e+ swSwRHHZpKTmZJalFunbJXBldF08xF5wwaVi/Y2HjA2MC0y7GDk5JARMJM6d/MMGYYtJXLi3 Hsjm4hASOMIo8e5DFzOEs4xR4viCBmaQKjYBHYnnj/6B2SIC+hJHPuwEK2IWOMAkcXT1CUaQ hLBAusTvoxOgijIkni3/xghhG0ksvfQBzGYRUJGYO2UtC4jNK+At8fDoTSYQW0ggS+L+0e9g cU4BTYkV246C2YxA530/tQashllAXOLWk/lMEGcLSCzZc54ZwhaVePn4HyuErSzxfc4jFoh6 HYkFuz+xQdjWElsev2WEsLUlli18zQxxg6DEyZlPWCYwis9CsmIWkvZZSNpnIWmfhaR9ASPr KkaO0uLUstx0I8NNjMBIPSbB5riDccEny0OM0hwsSuK8oa4XAoQE0hNLUrNTUwtSi+KLSnNS iw8xMnFwSjUwxjyPeW73wf+f1032fy0THdzfS03+dkVPR/SkTdeByct9+SbxnfozOXXBtcnr My6YbTj9geFdfW5shCRHXtny7Z26l4T2rBdbsc8ruHN5iEx1bUraft8bq2dzPU/Lk2/vqhav 0U80TC8zjZ294O26e292Pbh3ZOvRLw7luoI2RmYmH7pfvOXtVGIpzkg01GIuKk4EAA99elmi AgAA Cc: "rtg-dir@ietf.org" , Olivier Bonaventure , "Stefano Previdi \(sprevidi\)" , "Mike Shand \(mshand\)" , "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: Fri, 01 Feb 2013 16:41:46 -0000 Hi Stewart, I'm looking at the -09 version. I'm happy with it. I only have one comment = that I think could be a further improvement - see #1 below.=20 =20 On Jan 31, 2013, at 2:47 PM, Stewart Bryant wrote: > On 30/01/2013 18:33, Acee Lindem wrote: >> Authors, et al, >> I have been selected as the Routing Directorate reviewer for this draft.= The Routing Directorate seeks to review all routing or routing-related dra= fts as they pass through IETF last call and IESG review, and sometimes on s= pecial request. The purpose of the review is to provide assistance to the R= outing ADs. For more information about the Routing Directorate, please see = http://www.ietf.org/iesg/directorate/routing.html >> Although these comments are primarily for the use of the Routing ADs, it= would be helpful if you could consider them along with any other IETF Last= Call comments that you receive, and strive to resolve them through discuss= ion or by updating the draft. >> Document: draft-ietf-rtgwg-ipfrr-ordered-fib-08 >> Reviewer: Acee Lindem >> Review Date: January 30, 2013 >> IETF LC End Date: January 31, 2013 >> Intended Status: informational >> Summary: This document is basically ready for publication, but has clari= fication that should be considered prior to publication. >> Comments: The document accomplishes what it sets out to achieve in docum= enting the ordered FIB mechanism for avoidance of transient loops. While Ap= pendix B is useful, I think the document would be better without Appendix A= . Of course, this is just my opinion. >=20 > AAH took a lot of thought, so we would rather not loose it, if it works b= etter I could reverse the order of the appendixes. Ok - it does take a lot of effort to understand the AAH state machines but = since it is in an appendix, the reader can choose to skip it.=20 >>=20 >> Major Issues: None >>=20 >> Minor Issues: >> 1. The document could benefit for a precise definition of a = "non-urgent topology change". From what I gathered, this is any change that= can be deferred during the ordered FIB delay. > The abstract now says > "This mechanism can be used in the case of non-urgent (management action)= link or node shutdowns and restarts or link metric changes." >=20 > 3.1.1 says >=20 > "First consider the non-urgent failure of a link (i.e. where an operator = or a network management system (NMS) shuts down a link thereby removing it = from the currently active topology) or the increase of a link metric by the= operator or NMS ." >=20 > The point is of course that although a link is shut down rather than fail= ing, a remote node cannot distinguish the two cases. Ok. For both 3.1.1 and 3.1.2, you may also want to point out the use case o= f reconvergence of IPFRR repaired path.=20 >=20 >> 2. Similarly, the document could benefit from a precise defi= nition of the "rSPF". I checked RFC 5715 and it is not defined there either= . I believe our discussions indicate that this is simply an SPF where the s= hortest path back to us is used as the cost. For example, for the first pas= s, the SPF would use our neighbor's link cost rather than our own. > We use rSPT in here. >=20 > As you know we are looking for a formal definition. >=20 > I have put in Section 5 >=20 > This computation required the introduction of the concept of a reverse Sh= ortest Path Tree (rSPT). The rSPT uses the cost towards the root rather tha= n from it and yields the best paths towards the root from other nodes in th= e network > [I-D.draft-bryant-ipfrr-tunnels]. Ok. I think this will suffice for anyone who has been remotely following th= e IPFRR discussion.=20 >=20 > If there is a better ref we can swap in Auth48. >=20 >=20 >=20 >=20 >> 3. It would be good to state early on that the current oFIB = mechanism is limited to a single link or node failure and that multiple unr= elated failures result in reversion to normal FIB convergence. > Done (in section 2). >> 4. Make sure the hold down timer is defined precisely and ea= rly in the document. Currently, this doesn't happen until section 8.2. > On first use it says: >=20 > If all events received within some hold-down period (the time that a rout= er waits to acquire a set of LSPs which should be processed together) h Right. I see that now.=20 >> 5. Upon the initial reading, one may think there is some cor= respondence between the Router (R) in sections 4 and the Router (R) in sect= ion 5. Can this be clearer? Perhaps, (R) is not needed in section 4 since i= n all other sections, it refers to the computing router. > R is now removed. >=20 > As has been described, a single event such as the failure or restoration = of a single link, single router or a linecard may be notified to the rest o= f the network as a set of individual link change events. It is necessary to= deduce from this collection of link state notifications the type of event = that has occurred in the network and hence the required ordering. >=20 > When a link change event is received which impacts the receiving router's= FIB, the routers at the near and far end of the link are noted. >=20 > If all events received within some hold-down period (the time that a rout= er waits to acquire a set of LSPs which should be processed together) have = a single router in common, then it is assumed that the change reflects an e= vent (line-card or router change) concerning that router. >=20 > In the case of a link change event, the router at the far end of the link= is deemed to be the common router. >=20 > All ordering computations are based on treating the common router as the = root for both link and node events. Good.=20 >=20 >=20 >> 6. In section 5, I have trouble envisioning a case where a r= outer would not be in an pre or post failure SPT. I guess if it had no loop= backs and only unnumbered interfaces or only interfaces to broadcast links = offering a longer path??? > This is the case where you have an unused link (due to costs), i.e. a lin= k not on any shortest path. That would make sense for a link failure. For a node failure, it is harder = to visualize such a topology.=20 >=20 >> 7. In section 6.2, it would be instructive to say that a Lin= k Down condition is represented by an infinite metric (or otherwise cover t= his condition). > I have added "Inclusion or removal of link" to the information list. Explicit specification works as well.=20 >> 8. In section 8.5, I believe this a different hold down time= r than the one used to group LSPs related to the same failure. > Yes. >=20 > I have changes this to AAH_Hold_down_timer expires Great.=20 >=20 > Pierre and Mike please check this. >>=20 >> Nits: >>=20 >> 1. Abstract - replace "However mechanism" with "However the mechan= ism". I chose singular since it is singular in the preceding text. > done >> 2. Introduction - replace "base (FIB)" with "bases (FIBs)" in the = first sentence. > Done >=20 >> 3. Page 5, replace "change order no" with "change order, no". > Done >> 4. Page 9, suggest adding "IGP " to "reverse connectivity check". > Done >> 5. Page 10, suggest using parenthesis rather than relying on arith= metic precedence for equations, e.g., T0 + H + (rank * MAX_FIB) > Done >> 6. There is a mixture of "neighbor" and "neighbour" in the documen= t. Of course, I prefer the US English to UK English since this is what all = the OSPF RFCs use. > I will deal - but given we are Europeans... :) I figured that. ;^) You did miss one:=20 A.3.2. Per Neighbor State Machine >=20 >> 7. Section 8.1, the actions are formatting inconsistently. In one = case, as a paragraph and the other as a list. > Done > 8. Page 19, replace "algorithms i.e." with "algorithm= s, i.e.". > Done >> 9. Page 19 and Page 22, use of (PNSM) and (PN) is inconsistent. > Done >> 10. Page 23, Run-on sentence beginning "Manual configuration...". > Done >> 11. There some instances where the opening clause for a sentence is p= receded with a comma and some where it is not. I prefer the former. For exa= mple, section 4.2 appears to be written in a different style with missing p= unctuation. >>=20 >>=20 > I think I got them, but RFC Editor will get this Thanks, Acee=20 >=20 > Thanks for the review >=20 > Stewart >=20 >> Thanks, >> Acee >>=20 >>=20 >>=20 >>=20 >=20 >=20 > --=20 > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 From curtis@occnc.com Mon Feb 4 12:38:40 2013 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 3EC2421F8ACE for ; Mon, 4 Feb 2013 12:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.014 X-Spam-Level: X-Spam-Status: No, score=-0.014 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2f7eFB6KeFk for ; Mon, 4 Feb 2013 12:38:39 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id A6A0521F8A71 for ; Mon, 4 Feb 2013 12:38:37 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r14KZwix062366; Mon, 4 Feb 2013 15:35:58 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302042035.r14KZwix062366@gateway1.orleans.occnc.com> To: "Andrew Malis" , "Curtis Villamizar" , "Dave McDysan" , "So Ning" , "Lucy Yong" , "Alvaro Retana" , "Alia Atlas" From: Curtis Villamizar Subject: Re: Expiration impending: In-reply-to: Your message of "Mon, 04 Feb 2013 04:42:04 PST." <20130204124204.13940.98983.idtracker@ietfa.amsl.com> Date: Mon, 04 Feb 2013 15:35:58 -0500 Cc: RTGWG Working Group 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: Mon, 04 Feb 2013 20:38:40 -0000 In message <20130204124204.13940.98983.idtracker@ietfa.amsl.com> IETF Secretariat writes: > The following draft will expire soon: > > Name: draft-ietf-rtgwg-cl-requirement > Title: Requirements for MPLS Over a Composite Link > State: I-D Exists > Expires: 2013-02-13 (in 1 week, 1 day) Changes so far since 08 are just Andy Malis contact info. There is one thing I would like to change that I have mentioned before. OLD: 2. Assumptions - The services supported include L3VPN RFC 4364 [RFC4364], RFC 4797 - [RFC4797]L2VPN RFC 4664 [RFC4664] (VPWS, VPLS (RFC 4761 [RFC4761], - RFC 4762 [RFC4762]) and VPMS VPMS Framework - [I-D.ietf-l2vpn-vpms-frmwk-requirements]), Internet traffic encapsulated by at least one MPLS label (RFC 3032 [RFC3032]), and dynamically signaled MPLS (RFC 3209 [RFC3209] or RFC 5036 [RFC5036]) - or MPLS-TP LSPs (RFC 5921 [RFC5921]) and pseudowires (RFC 3985 - [RFC3985]). The MPLS LSPs supporting these services may be point-to- point, point-to-multipoint, or multipoint-to-multipoint. NEW: 2. Assumptions + The services supported include pseudowire based services [RFC3985], + including VPN services, Internet traffic encapsulated by at least one MPLS label (RFC 3032 [RFC3032]), and dynamically signaled MPLS (RFC 3209 [RFC3209] or RFC 5036 [RFC5036]) + or MPLS-TP LSPs (RFC 5921 [RFC5921]). The MPLS LSPs supporting these + services may be point-to- point, point-to-multipoint, or multipoint-to-multipoint. The removal of the reference to I-D.ietf-l2vpn-vpms-frmwk-requirements eliminates an unnecessary barrier to advancement. There is no need to enumerate all of the types of VPN services. Note that the change is a move of pseudowires from last to first, and changing the the pseudowires plus the list of VPN services to "pseudowire based services [RFC3985], including VPN services". If this is OK with co-authors and the WG, I will make this change and submit. Curtis From akatlas@gmail.com Mon Feb 4 12:42:16 2013 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 0348821F879D for ; Mon, 4 Feb 2013 12:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUsiy2yyjgAG for ; Mon, 4 Feb 2013 12:42:15 -0800 (PST) Received: from mail-la0-x232.google.com (la-in-x0232.1e100.net [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id DD4DE21F8783 for ; Mon, 4 Feb 2013 12:42:14 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id ec20so4934869lab.23 for ; Mon, 04 Feb 2013 12:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bFZ+iX3+bEbcHXYd6ap3D8wG6P5mjI93yjWKcn8/SlI=; b=SHgkaTmn968jtn1CGEO31SXuyMwv3Fo5mPlofBhR7JSlgZFbSbSW2HRg/s+vEXTX1h WBnpXDuPGYfyUXpA0CiD/neR5FmoMvCxRuu0DAl9mQqTAlDVBv8YKGPsRaipOrP4pRlp xqA/g52jOvJUhuChOc2mVZmd7w75avmMHqnqE0OERXlc0kNjta59vsMsRiPGIA3IyvAT mqsinYflOkBqI6pgTkni1PhQky+oCYi58j/lvnGiI4hFPRkCRTdLen6ChwrD1SEGWRBE FK2+vt5eeMjE+QvDd1o/cB+KKqQzdRY7nUz/wrzKzbVWeGsEtaxe1+Alor5odjtmEmrj N65g== MIME-Version: 1.0 X-Received: by 10.112.50.109 with SMTP id b13mr8733468lbo.8.1360010532896; Mon, 04 Feb 2013 12:42:12 -0800 (PST) Received: by 10.112.49.3 with HTTP; Mon, 4 Feb 2013 12:42:12 -0800 (PST) In-Reply-To: <201302042035.r14KZwix062366@gateway1.orleans.occnc.com> References: <20130204124204.13940.98983.idtracker@ietfa.amsl.com> <201302042035.r14KZwix062366@gateway1.orleans.occnc.com> Date: Mon, 4 Feb 2013 15:42:12 -0500 Message-ID: Subject: Re: Expiration impending: From: Alia Atlas To: curtis@occnc.com Content-Type: multipart/alternative; boundary=f46d0401fbc9b4424004d4ec2084 Cc: So Ning , Andrew Malis , RTGWG Working Group 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: Mon, 04 Feb 2013 20:42:16 -0000 --f46d0401fbc9b4424004d4ec2084 Content-Type: text/plain; charset=ISO-8859-1 That sounds good to me. I would really like to see the composite link work advance - preferably by or just after the next IETF. I encourage everyone to read and comment on it; I will do so as well and send comments separately. Alia On Mon, Feb 4, 2013 at 3:35 PM, Curtis Villamizar wrote: > > In message <20130204124204.13940.98983.idtracker@ietfa.amsl.com> > IETF Secretariat writes: > > > The following draft will expire soon: > > > > Name: draft-ietf-rtgwg-cl-requirement > > Title: Requirements for MPLS Over a Composite Link > > State: I-D Exists > > Expires: 2013-02-13 (in 1 week, 1 day) > > > Changes so far since 08 are just Andy Malis contact info. > > There is one thing I would like to change that I have mentioned > before. > > OLD: > > 2. Assumptions > > - The services supported include L3VPN RFC 4364 [RFC4364], RFC 4797 > - [RFC4797]L2VPN RFC 4664 [RFC4664] (VPWS, VPLS (RFC 4761 [RFC4761], > - RFC 4762 [RFC4762]) and VPMS VPMS Framework > - [I-D.ietf-l2vpn-vpms-frmwk-requirements]), Internet traffic > encapsulated by at least one MPLS label (RFC 3032 [RFC3032]), and > dynamically signaled MPLS (RFC 3209 [RFC3209] or RFC 5036 [RFC5036]) > - or MPLS-TP LSPs (RFC 5921 [RFC5921]) and pseudowires (RFC 3985 > - [RFC3985]). The MPLS LSPs supporting these services may be point-to- > point, point-to-multipoint, or multipoint-to-multipoint. > > NEW: > > 2. Assumptions > > + The services supported include pseudowire based services [RFC3985], > + including VPN services, Internet traffic > encapsulated by at least one MPLS label (RFC 3032 [RFC3032]), and > dynamically signaled MPLS (RFC 3209 [RFC3209] or RFC 5036 [RFC5036]) > + or MPLS-TP LSPs (RFC 5921 [RFC5921]). The MPLS LSPs supporting these > + services may be point-to- > point, point-to-multipoint, or multipoint-to-multipoint. > > The removal of the reference to I-D.ietf-l2vpn-vpms-frmwk-requirements > eliminates an unnecessary barrier to advancement. There is no need to > enumerate all of the types of VPN services. > > Note that the change is a move of pseudowires from last to first, and > changing the the pseudowires plus the list of VPN services to > "pseudowire based services [RFC3985], including VPN services". > > If this is OK with co-authors and the WG, I will make this change and > submit. > > Curtis > --f46d0401fbc9b4424004d4ec2084 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That sounds good to me.

I would really like to see the c= omposite link work advance - preferably by or just after the next IETF.
I encourage everyone to read and comment on it; =A0I will do so as w= ell and send comments separately.

Alia

On Mon, Feb 4, 2= 013 at 3:35 PM, Curtis Villamizar <curtis@occnc.com> wrote:

In message <20130204124204.13940.98983.idtracker@ietfa.amsl.com>
IETF Secretariat writes:

> The following draft will expire soon:
>
> Name: =A0 =A0 draft-ietf-rtgwg-cl-requirement
> Title: =A0 =A0Requirements for MPLS Over a Composite Link
> State: =A0 =A0I-D Exists
> Expires: =A02013-02-13 (in 1 week, 1 day)


Changes so far since 08 are just Andy Malis contact info.

There is one thing I would like to change that I have mentioned
before.

OLD:

=A0 2. =A0Assumptions

- =A0 The services supported include L3VPN RFC 4364 [RFC4364], RFC 4797
- =A0 [RFC4797]L2VPN RFC 4664 [RFC4664] (VPWS, VPLS (RFC 4761 [RFC4761], - =A0 RFC 4762 [RFC4762]) and VPMS VPMS Framework
- =A0 [I-D.ietf-l2vpn-vpms-frmwk-requirements]), Internet traffic
=A0 =A0encapsulated by at least one MPLS label (RFC 3032 [RFC3032]), and =A0 =A0dynamically signaled MPLS (RFC 3209 [RFC3209] or RFC 5036 [RFC5036])=
- =A0 or MPLS-TP LSPs (RFC 5921 [RFC5921]) and pseudowires (RFC 3985
- =A0 [RFC3985]). =A0The MPLS LSPs supporting these services may be point-t= o-
=A0 =A0point, point-to-multipoint, or multipoint-to-multipoint.

NEW:

=A0 2. =A0Assumptions

+ =A0 The services supported include pseudowire based services [RFC3985], + =A0 including VPN services, Internet traffic
=A0 =A0encapsulated by at least one MPLS label (RFC 3032 [RFC3032]), and =A0 =A0dynamically signaled MPLS (RFC 3209 [RFC3209] or RFC 5036 [RFC5036])=
+ =A0 or MPLS-TP LSPs (RFC 5921 [RFC5921]). =A0The MPLS LSPs supporting the= se
+ =A0 services may be point-to-
=A0 =A0point, point-to-multipoint, or multipoint-to-multipoint.

The removal of the reference to I-D.ietf-l2vpn-vpms-frmwk-requirements
eliminates an unnecessary barrier to advancement. =A0There is no need to enumerate all of the types of VPN services.

Note that the change is a move of pseudowires from last to first, and
changing the the pseudowires plus the list of VPN services to
"pseudowire based services [RFC3985], including VPN services".
If this is OK with co-authors and the WG, I will make this change and
submit.

Curtis

--f46d0401fbc9b4424004d4ec2084-- From curtis@occnc.com Tue Feb 5 11:56:43 2013 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 4423521F863F for ; Tue, 5 Feb 2013 11:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.305 X-Spam-Level: X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8z+xZOBBM3p for ; Tue, 5 Feb 2013 11:56:42 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id AC49321F8635 for ; Tue, 5 Feb 2013 11:56:42 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r15Js12Y072536; Tue, 5 Feb 2013 14:54:01 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302051954.r15Js12Y072536@gateway1.orleans.occnc.com> To: Alia Atlas From: Curtis Villamizar Subject: Re: Expiration impending: In-reply-to: Your message of "Mon, 04 Feb 2013 15:42:12 EST." Date: Tue, 05 Feb 2013 14:54:01 -0500 Cc: So Ning , Andrew Malis , RTGWG Working Group 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: Tue, 05 Feb 2013 19:56:43 -0000 In message Alia Atlas writes: > That sounds good to me. > > I would really like to see the composite link work advance - > preferably by or just after the next IETF. I encourage everyone to > read and comment on it; I will do so as well and send comments > separately. > > Alia Alia, Perhaps we should consider advancing CL Requirements alone. It has been quite stable for a long time. Perhaps repeat last call and advance to the AD review. CL Use Cases has also been stable, but it has received so few comments that it is hard to say there is concensus. It could stand some improvement IMHO, and I'm an author. CL Framework will take some time. Progress may be needed on some of the docs referenced by CL Framework before we can consider advancing it. Referenced docs should at least all be WG docs with a reasonable chance of advancing rather than being abandonned. Curtis From internet-drafts@ietf.org Tue Feb 5 12:46:06 2013 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 6562921F86A6; Tue, 5 Feb 2013 12:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAbSGqzux5W3; Tue, 5 Feb 2013 12:46:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16DD21F8702; Tue, 5 Feb 2013 12:46:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-cl-use-cases-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130205204605.15261.59588.idtracker@ietfa.amsl.com> Date: Tue, 05 Feb 2013 12:46:05 -0800 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: Tue, 05 Feb 2013 20:46:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Composite Link Use Cases and Design Considerations Author(s) : So Ning Andrew Malis Dave McDysan Lucy Yong Curtis Villamizar Filename : draft-ietf-rtgwg-cl-use-cases-02.txt Pages : 23 Date : 2013-02-05 Abstract: This document provides a set of use cases and design considerations for composite links. Composite link is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to multipath techniques. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-cl-use-cases-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-cl-use-cases-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From balajivenkat299@gmail.com Tue Feb 5 22:22:34 2013 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 61CA821F847C for ; Tue, 5 Feb 2013 22:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OCruoApDoN8 for ; Tue, 5 Feb 2013 22:22:32 -0800 (PST) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id 755D821F84CE for ; Tue, 5 Feb 2013 22:22:32 -0800 (PST) Received: by mail-oa0-f54.google.com with SMTP id n12so1162279oag.13 for ; Tue, 05 Feb 2013 22:22:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=3KfcgdIC4PDplNULzGdt6ML2G/LWIaVtX2cRjHcB3YQ=; b=B/x/R6xWkCgz7raDxo1XXbhaLz2mXnWcfqKT++BVkGODimQJcKr+M4m6JKMalfTQd4 /WBf1IpuOd9g7xyE6CNv0DEOF0XV04Yk5cLSUztLVyJg+2ahaa11I2dWe/5XltcZH0Cy jyDH4R6GHgxP+nFUN8uu5/miW8IfSzcGplRLmU8HPpGzvCYA+1H4XUnqG6CcPhMlTZPm R/2ur2kfUgy12+LS6oi2vVLSBnuzHuVWxaAX1XyXz6srDfMTXj3K4MCzr5rgnhPXiA+i /5H89s23JZYthz6oBig1dKWdBfw/11+iluwuoOw5SOrOe5//SiJ7pE0zwi93A7bhV6rQ KwCw== MIME-Version: 1.0 X-Received: by 10.60.8.199 with SMTP id t7mr20834533oea.26.1360131751565; Tue, 05 Feb 2013 22:22:31 -0800 (PST) Received: by 10.60.55.71 with HTTP; Tue, 5 Feb 2013 22:22:31 -0800 (PST) Date: Wed, 6 Feb 2013 11:52:31 +0530 Message-ID: Subject: Power aware networks : Comments requested from routing community From: Balaji venkat Venkataswami To: rtgwg@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff1ce46e6584804d50859ce Cc: Shankar Raman M J 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, 06 Feb 2013 06:22:34 -0000 --e89a8ff1ce46e6584804d50859ce Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear all, We are a group of research and industry individuals tied together with a common goal towards reducing the energy consumption in the core and edge networks. We present a metric-based hierarchical approach to reduce power consumption in core and edge networks. The proposal considers both unicast and the multicast cases. For unicast, the metric considered is *consumed-power to available-bandwidth* and for multicast the metric is *consumed-power to available-replication-capacity.* With unicast, the metric is used to determine a low-power path between sources and destinations. With multicast, the metric serves the twin purpose of finding low-power multicast paths as well as multicast replication points. We evolve multiple techniques at various hierarchical levels. One at the Inter-AS level, Inter-Area level within the AS and intra-Area within an AS. Additionally, the proposed method can also be used to determine disjoint or redundant paths for load balancing or fault tolerance. Additionally since TCAMs are one of the biggest power guzzlers in all the components on a router/switch, we have presented a solution for intra-AS purposes to use the TCAM according to the traffic matrix passing through the system and shut down those TCAM banks that are unused. With this in mind, we have also advocated taking into account a TCAM-POWER-Ratio in order to compute the paths from source to destination based on this metric. Once low-power paths, in either the unicast or the multicast cases, are identified then currently available traffic engineering techniques could be used to route the data packets. In the case of inter-AS BGP path selection is also modified to arrive at paths which are low-power paths. Our main objective is as follows... We now outline four important aspects that any approach for power reduction should be capable of addressing. *Should cater for both unicast and multicast scenarios* Multicast provides an important scenario for the Internet. Today, most proposals consider mainly low-power path routing with unicast traffic. Multicast traffic has received a lot of attention in wireless networks, but not in the wired domain. Any new proposal should be able to address both the unicast and the multicast traffic scenarios. Having different methods for these two scenarios might lead to unnecessary processing burden in the routers, which might hinder its scalability. *Should not rely on just switching off unused links* Most approaches to optimize energy pursue the following approach: measure, monitor and respond to the system energy usage by switching off unused or under-utilized links. Such an approach could be effective for reducing power locally. The effect on the network is not clearly understood. Further, the power usage involved in turning on and rebooting/reconfiguring the device is often not explicitly considered. We note that Service Level Agreement (SLA) requirements may not even permit the links to be switched off. Also services provided by ISPs like Virtual Private Networks (VPNs) can be affected by such re-routing decisions. *Should follow an hierarchical and distributed approach* For scalability, it is important that the algorithms proposed for inter-AS should also be applicable to intra-AS situations. Networks do not work in isolation, so any proposal should be both distributed and hierarchical. The algorithms should be applicable at every level of the hierarchy. *Should provide incentives for ISP for adoption* The engineering proposals should be aligned with commercial incentives for rapid and widespread adoption. Today, the device manufacturers and the ISPs operate independently of each other, and there is no incentive for manufacturers to work towards low-power and high bandwidth devices. An ISP=92s revenue model is based on the consumed bandwidth, which in turn lea= d naturally to more power consumption. If the proposed method chooses routers that consume low-power and increase the data flow through them, then this indirectly provides encouragement for ISPs to purchase low-power and high bandwidth devices. We now present our metric-based proposals in the below mentioned drafts which addresses the aforementioned design aspects. We would like the routing community to provide feedback on these drafts. We also intend to present this work in an abridged format in the upcoming IETF= . The drafts are as follows.... - mjsraman-panet-bgp-power-path (timeline) Inter-AS-Proposal - mjsraman-panet-ecmp-redirect-power-repl-cap (timeline) Multicast - mjsraman-panet-inter-as-power-source (timeline) Inter-AS Proposal - mjsraman-panet-inter-as-psp (timeline) Inter-AS Proposal - mjsraman-panet-inter-as-psp-protect (timeline) Inter-AS Proposal - mjsraman-panet-pce-power-mcast-replic (timeline) Multicast - mjsraman-panet-pim-power (timeline) Multicast - mjsraman-panet-tcam-power-efficiency (timeline) TCAM related - mjsraman-panet-tcam-power-ratio (timeline) TCAM related - mjsraman-pce-power-replic (timeline) Multicast - mjsraman-panet-intra-as-psp-te-leak (timeline) Inter-Area within an AS - mjsraman-panet-ospf-power-topo (timeline) Intra-Area within an AS We understand it is a lot of matter to go through. We would much appreciate if some of you could review the inter-AS proposals while others take up multicast and Intra-AS unicast and multicast. Thanks again for your time on this matter. thanks and regards, balaji venkat --e89a8ff1ce46e6584804d50859ce Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Dear all,

We are a group of research and industry individuals tied together with a co= mmon goal towards reducing the energy consumption in the core and edge netw= orks.

We present a metric-based hierarchical approach to reduce power consumption= in core and edge networks. The proposal considers both unicast and the mul= ticast cases. For unicast, the metric considered is=A0consumed-power to = available-bandwidth=A0and for multicast the metric is=A0consumed-pow= er to available-replication-capacity.

=A0With unicast, the metric is=A0used= to determine a low-power path between sources and destinations.=A0<= span lang=3D"EN-US" style=3D"background-color:transparent">With multicast, = the=A0me= tric serves the twin purpose of finding low-power multicast paths as well a= s multicast replication points.=A0=A0We evolve multiple techniques at variou= s hierarchical levels. One at the Inter-AS level, Inter-Area level within t= he AS and intra-Area within an AS. Additionally, the proposed method can al= so be used to determine disjoint or redundant paths for load balancing or f= ault tolerance. Additionally since TCAMs are one of the biggest power guzzl= ers in all the components on a router/switch, we have presented a solution = for intra-AS purposes to use the TCAM according to the traffic matrix passi= ng through the system and shut down those TCAM banks that are unused. With = this in mind, we have also advocated taking into account a TCAM-POWER-Ratio= in order to compute the paths from source to destination based on this met= ric. Once low-power paths, in either the unicast or the multicast cases, ar= e identified then currently available traffic engineering techniques could = be used to route the data packets. In the case of inter-AS BGP path selecti= on is also modified to arrive at paths which are low-power paths.

=A0Our main object= ive is as follows...

We now outline four important aspects that any approach for power reduction should be capable o= f addressing.

=A0Should cater for both unicast and multicast scenarios

=

Multicast provides an important scenario for the Internet. Today, most proposals consider mainly low-power path routing with unicast traffic. Multicast traffic has received a lot of attention in wireless networks, but= not in the wired domain. Any new proposal should be able to address both the unicast and the multicast traffic scenarios. Having different methods for t= hese two scenarios might lead to unnecessary processing burden in the routers, w= hich might hinder its scalability.=A0=A0=A0=A0=A0=A0=A0=A0

=A0Should not rely on just switching off unused links

Most approaches to optimize energy pursue the following approach: measure, monitor and respond to the system energy usage by switch= ing off unused or under-utilized links. Such an approach could be effective for reducing power locally. The effect on the network is not clearly understood= . Further, the power usage involved in turning on and rebooting/reconfiguring= the device is often not explicitly considered. We note that Service Level Agree= ment (SLA) requirements may not even permit the links to be switched off. Also services provided by ISPs like Virtual Private Networks (VPNs) can be affec= ted by such re-routing decisions.

=A0Should follow an hierarchical and distributed approach

For scalability, it is important that the algorithms proposed for inter-AS should also be applicable to intra-AS situations. Networks do not work in isolation, so any proposal should be both distribut= ed and hierarchical. The algorithms should be applicable at every level of the hierarchy.=A0=A0

=A0Should=A0=A0provide = incentives for ISP for adoption

The engineering proposals should be aligned with commercial incentives for rapid and widespread adoption. Today, the device manufacturers and the ISPs operate independently of each other, and there i= s no incentive for manufacturers to work towards low-power and high bandwidth devices. An ISP=92s revenue model is based on the consumed bandwidth, which= in turn lead naturally to more power consumption. If the proposed method choos= es routers that consume low-power and increase the data flow through them, the= n this indirectly provides encouragement for ISPs to purchase low-power and h= igh bandwidth devices.=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0

We now present our metric-based proposals in the below mentioned drafts= which addresses the aforementioned design aspects.

We would like the routing communi= ty to provide feedback on these drafts. We also intend to present this work= in an abridged format in the upcoming IETF.

=A0The drafts are as follows....



  • mjs= raman-panet-bgp-power-path=A0(timeline)=A0Inter-= AS-Proposal
  • mjsraman-panet-= ecmp-redirect-power-repl-cap=A0(timeli= ne)=A0Multicast
  • mjsraman-panet-inter-a= s-power-source=A0(timeline)=A0Inter-AS = Proposal
  • mjsraman-panet-inter-as-psp= =A0(timeline)=A0Inter-AS Proposal
  • mjsraman-panet-inter-as= -psp-protect=A0(timeline)=A0Inter-AS Propo= sal
  • mjsraman-panet-pce-po= wer-mcast-replic=A0(timeline)=A0Multicas= t
  • mjsraman-panet-pim-power=A0(timeline)=A0Multicast
  • mjsraman-panet-tcam-po= wer-efficiency=A0(timeline)=A0TCAM rela= ted
  • mjsraman-panet-tcam-power-= ratio=A0(timeline) TCAM related
  • mjsraman-pce-power-replic=A0<= a href=3D"http://www.arkko.com/tools/lifecycle/draft-mjsraman-pce-power-rep= lic-timing.html" target=3D"_blank" style=3D"color:rgb(68,0,136);border-bott= om-width:0px">(timeline)=A0Multicast
  • mjsraman-panet-intra-as= -psp-te-leak=A0(timeline)=A0Inter-Area wit= hin an AS
  • mjsraman-panet-ospf-power-= topo=A0(timeline)=A0Intra-Area within an AS
    We understand it is a lot of matter to = go through. We would much appreciate if some of you could review the inter-= AS proposals while others take up multicast and Intra-AS unicast and multic= ast.

    Thanks again for your time on this matter.

    thanks and = regards,
    balaji venkat

    --e89a8ff1ce46e6584804d50859ce-- From curtis@occnc.com Wed Feb 6 10:43:45 2013 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 90B0521F8A48 for ; Wed, 6 Feb 2013 10:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.318 X-Spam-Level: X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4yPRCIs2K3G for ; Wed, 6 Feb 2013 10:43:44 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 19DCA21F86EB for ; Wed, 6 Feb 2013 10:43:43 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r16IfBn5084352; Wed, 6 Feb 2013 13:41:11 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> To: Balaji venkat Venkataswami From: Curtis Villamizar Subject: Re: Power aware networks : Comments requested from routing community In-reply-to: Your message of "Wed, 06 Feb 2013 11:52:31 +0530." Date: Wed, 06 Feb 2013 13:41:11 -0500 Cc: Shankar Raman M J , 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: Wed, 06 Feb 2013 18:43:45 -0000 Balaji, "We" in the context of your first paragraph seems to be a misrepresentation. The authors of all of these drafts seem to be from the same university in India. From prior attempts on your part to get a draft of this sort into IDR and a brief reading of a few of the drafts that you have just submitted, you don't seem to have a good understanding of how networks are built and how network equipment is built from which to begin to attack the problem of reducing the power consumption of these networks. If you want to try to advance a research paper with your theories on power reduction, please choose an appropriate venue such as a refereed technical journal. Curtis In message Balaji venkat Venkataswami writes: > Dear all, > > We are a group of research and industry individuals tied together with a > common goal towards reducing the energy consumption in the core and edge > networks. > > We present a metric-based hierarchical approach to reduce power consumption > in core and edge networks. The proposal considers both unicast and the > multicast cases. For unicast, the metric considered is *consumed-power to > available-bandwidth* and for multicast the metric is *consumed-power to > available-replication-capacity.* > > With unicast, the metric is used to determine a low-power path between > sources and destinations. With multicast, the metric serves the twin > purpose of finding low-power multicast paths as well as multicast > replication points. We evolve multiple techniques at various hierarchical > levels. One at the Inter-AS level, Inter-Area level within the AS and > intra-Area within an AS. Additionally, the proposed method can also be used > to determine disjoint or redundant paths for load balancing or fault > tolerance. Additionally since TCAMs are one of the biggest power guzzlers > in all the components on a router/switch, we have presented a solution for > intra-AS purposes to use the TCAM according to the traffic matrix passing > through the system and shut down those TCAM banks that are unused. With > this in mind, we have also advocated taking into account a TCAM-POWER-Ratio > in order to compute the paths from source to destination based on this > metric. Once low-power paths, in either the unicast or the multicast cases, > are identified then currently available traffic engineering techniques > could be used to route the data packets. In the case of inter-AS BGP path > selection is also modified to arrive at paths which are low-power paths. > > Our main objective is as follows... > > We now outline four important aspects that any approach for power reduction > should be capable of addressing. > > *Should cater for both unicast and multicast scenarios* > > Multicast provides an important scenario for the Internet. Today, most > proposals consider mainly low-power path routing with unicast traffic. > Multicast traffic has received a lot of attention in wireless networks, but > not in the wired domain. Any new proposal should be able to address both > the unicast and the multicast traffic scenarios. Having different methods > for these two scenarios might lead to unnecessary processing burden in the > routers, which might hinder its scalability. > > *Should not rely on just switching off unused links* > > Most approaches to optimize energy pursue the following approach: measure, > monitor and respond to the system energy usage by switching off unused or > under-utilized links. Such an approach could be effective for reducing > power locally. The effect on the network is not clearly understood. > Further, the power usage involved in turning on and rebooting/reconfiguring > the device is often not explicitly considered. We note that Service Level > Agreement (SLA) requirements may not even permit the links to be switched > off. Also services provided by ISPs like Virtual Private Networks (VPNs) > can be affected by such re-routing decisions. > > *Should follow an hierarchical and distributed approach* > > For scalability, it is important that the algorithms proposed for inter-AS > should also be applicable to intra-AS situations. Networks do not work in > isolation, so any proposal should be both distributed and hierarchical. The > algorithms should be applicable at every level of the hierarchy. > > *Should provide incentives for ISP for adoption* > > The engineering proposals should be aligned with commercial incentives for > rapid and widespread adoption. Today, the device manufacturers and the ISPs > operate independently of each other, and there is no incentive for > manufacturers to work towards low-power and high bandwidth devices. An > ISP=92s revenue model is based on the consumed bandwidth, which in turn lea= > d > naturally to more power consumption. If the proposed method chooses routers > that consume low-power and increase the data flow through them, then this > indirectly provides encouragement for ISPs to purchase low-power and high > bandwidth devices. > > > > We now present our metric-based proposals in the below mentioned drafts > which addresses the aforementioned design aspects. > > We would like the routing community to provide feedback on these drafts. We > also intend to present this work in an abridged format in the upcoming IETF= > . > > The drafts are as follows.... > > > > > - mjsraman-panet-bgp-power-path n-panet-bgp-power-path> > (timeline) p-power-path-timing.html> > Inter-AS-Proposal > - mjsraman-panet-ecmp-redirect-power-repl-cap /draft-mjsraman-panet-ecmp-redirect-power-repl-cap> > (timeline) mp-redirect-power-repl-cap-timing.html> > Multicast > - mjsraman-panet-inter-as-power-source mjsraman-panet-inter-as-power-source> > (timeline) ter-as-power-source-timing.html> > Inter-AS > Proposal > - mjsraman-panet-inter-as-psp panet-inter-as-psp> > (timeline) ter-as-psp-timing.html> > Inter-AS > Proposal > - mjsraman-panet-inter-as-psp-protect jsraman-panet-inter-as-psp-protect> > (timeline) ter-as-psp-protect-timing.html> > Inter-AS > Proposal > - mjsraman-panet-pce-power-mcast-replic -mjsraman-panet-pce-power-mcast-replic> > (timeline) e-power-mcast-replic-timing.html> > Multicast > - mjsraman-panet-pim-power et-pim-power> > (timeline) m-power-timing.html> > Multicast > - mjsraman-panet-tcam-power-efficiency mjsraman-panet-tcam-power-efficiency> > (timeline) am-power-efficiency-timing.html> > TCAM > related > - mjsraman-panet-tcam-power-ratio man-panet-tcam-power-ratio> > (timeline m-power-ratio-timing.html>) > TCAM related > - mjsraman-pce-power-replic e-power-replic> > (timeline) r-replic-timing.html> > Multicast > - mjsraman-panet-intra-as-psp-te-leak jsraman-panet-intra-as-psp-te-leak> > (timeline) tra-as-psp-te-leak-timing.html> > Inter-Area > within an AS > - mjsraman-panet-ospf-power-topo an-panet-ospf-power-topo> > (timeline) pf-power-topo-timing.html> > Intra-Area > within an AS > > We understand it is a lot of matter to go through. We would much appreciate > if some of you could review the inter-AS proposals while others take up > multicast and Intra-AS unicast and multicast. > > Thanks again for your time on this matter. > > thanks and regards, > balaji venkat From balajivenkat299@gmail.com Wed Feb 6 10:53:02 2013 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 11F3E21F84ED for ; Wed, 6 Feb 2013 10:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.838 X-Spam-Level: X-Spam-Status: No, score=-3.838 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-o3MRszv1AI for ; Wed, 6 Feb 2013 10:53:00 -0800 (PST) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4231521F84EA for ; Wed, 6 Feb 2013 10:52:55 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wc20so1828234obb.29 for ; Wed, 06 Feb 2013 10:52:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xIhDyHRttn8D0JdpUaUgw36mI8KZm4GiG6g452TQ+ps=; b=Dhwe6hUqq0vfMaHsyd1tIkJiS0Ug53JpHATNudzZUXniVcuzw3RNfsabgWczGkw3K9 ulQYyPQPE9qhaRrrpkbX7dPOblHJPvlSLrzI4Umo6i4FYnkVglWw/ejchBlovPLIBlmi hSyiKtV8zna4TiS+hVpbRka9L3eVwVed17dzc39sDjV5vtDAxFW5HhAPkMoPR+ANWls+ HDasIYaobkn/dS4UUOAEPJddv4F1iPfrUOKPqFrptXdOk5eAWTFJh56M4LCEBUriwh/+ i9hALABwPRHQAxNFEO0a/ZskRN5EFtgyYV1mPwipXihAvck/WcgqVLbtC1iSawA2H+EF /Bog== MIME-Version: 1.0 X-Received: by 10.182.194.2 with SMTP id hs2mr21674456obc.97.1360176774614; Wed, 06 Feb 2013 10:52:54 -0800 (PST) Received: by 10.60.55.71 with HTTP; Wed, 6 Feb 2013 10:52:54 -0800 (PST) In-Reply-To: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> Date: Thu, 7 Feb 2013 00:22:54 +0530 Message-ID: Subject: Re: Power aware networks : Comments requested from routing community From: Balaji venkat Venkataswami To: curtis@occnc.com Content-Type: multipart/alternative; boundary=f46d0444ea7f7b901d04d512d5a2 Cc: Shankar Raman M J , 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: Wed, 06 Feb 2013 18:53:02 -0000 --f46d0444ea7f7b901d04d512d5a2 Content-Type: text/plain; charset=ISO-8859-1 Dear Curtis, As already stated to you in a private email, "We" are a group of people with 40 years of collective industry experience in the networking industry. We dont need to be patronized by anybody since we have independent minds that have the capability to digest information not based on somebody else's interpretation of how future networks need to be built and how power reduction needs to play a part in it. As you might recall one such research paper on GreenTE by Beichuan Zhang rang a lot of bells in the IETF by collecting the ANRP prize. So please dont misstate facts as you might know them and shove your ideas of how networks are built down our throats. We think the IETF is a free and fair body that accepts opinions and ideas from all sides. We want to keep this a free and fair organization. So incumbent people like you ought to encourage us and have a fair argument when we present such work to you. Dont follow the policy of exclusion to the nth degree. It is but fair to say that you seem to be in a minority on this matter. Nobody else responded with unkind misstatements of facts and mis-understanding of our technical antecedents. Suffice to say that if we get an opportunity to present this (since IETF is OUR organization too) you need not sit through it. If you want to give us a fair hearing please follow a policy of kind inclusion and not create a ruckus about us research folks trying to make an earnest attempt at some practical research that could well save the planet. Yours sincerely, Thanks and regards, balaji venkat and shankar raman On Thu, Feb 7, 2013 at 12:11 AM, Curtis Villamizar wrote: > > Balaji, > > "We" in the context of your first paragraph seems to be a > misrepresentation. The authors of all of these drafts seem to be from > the same university in India. From prior attempts on your part to get > a draft of this sort into IDR and a brief reading of a few of the > drafts that you have just submitted, you don't seem to have a good > understanding of how networks are built and how network equipment is > built from which to begin to attack the problem of reducing the power > consumption of these networks. > > If you want to try to advance a research paper with your theories on > power reduction, please choose an appropriate venue such as a refereed > technical journal. > > Curtis > > > In message < > CAHF4apO9bEkPk7QwA9fgJq9BNUNHNv+OFon_9_4Oij61e11r9w@mail.gmail.com> > Balaji venkat Venkataswami writes: > > > Dear all, > > > > We are a group of research and industry individuals tied together with a > > common goal towards reducing the energy consumption in the core and edge > > networks. > > > > We present a metric-based hierarchical approach to reduce power > consumption > > in core and edge networks. The proposal considers both unicast and the > > multicast cases. For unicast, the metric considered is *consumed-power to > > available-bandwidth* and for multicast the metric is *consumed-power to > > available-replication-capacity.* > > > > With unicast, the metric is used to determine a low-power path between > > sources and destinations. With multicast, the metric serves the twin > > purpose of finding low-power multicast paths as well as multicast > > replication points. We evolve multiple techniques at various > hierarchical > > levels. One at the Inter-AS level, Inter-Area level within the AS and > > intra-Area within an AS. Additionally, the proposed method can also be > used > > to determine disjoint or redundant paths for load balancing or fault > > tolerance. Additionally since TCAMs are one of the biggest power guzzlers > > in all the components on a router/switch, we have presented a solution > for > > intra-AS purposes to use the TCAM according to the traffic matrix passing > > through the system and shut down those TCAM banks that are unused. With > > this in mind, we have also advocated taking into account a > TCAM-POWER-Ratio > > in order to compute the paths from source to destination based on this > > metric. Once low-power paths, in either the unicast or the multicast > cases, > > are identified then currently available traffic engineering techniques > > could be used to route the data packets. In the case of inter-AS BGP path > > selection is also modified to arrive at paths which are low-power paths. > > > > Our main objective is as follows... > > > > We now outline four important aspects that any approach for power > reduction > > should be capable of addressing. > > > > *Should cater for both unicast and multicast scenarios* > > > > Multicast provides an important scenario for the Internet. Today, most > > proposals consider mainly low-power path routing with unicast traffic. > > Multicast traffic has received a lot of attention in wireless networks, > but > > not in the wired domain. Any new proposal should be able to address both > > the unicast and the multicast traffic scenarios. Having different methods > > for these two scenarios might lead to unnecessary processing burden in > the > > routers, which might hinder its scalability. > > > > *Should not rely on just switching off unused links* > > > > Most approaches to optimize energy pursue the following approach: > measure, > > monitor and respond to the system energy usage by switching off unused or > > under-utilized links. Such an approach could be effective for reducing > > power locally. The effect on the network is not clearly understood. > > Further, the power usage involved in turning on and > rebooting/reconfiguring > > the device is often not explicitly considered. We note that Service Level > > Agreement (SLA) requirements may not even permit the links to be switched > > off. Also services provided by ISPs like Virtual Private Networks (VPNs) > > can be affected by such re-routing decisions. > > > > *Should follow an hierarchical and distributed approach* > > > > For scalability, it is important that the algorithms proposed for > inter-AS > > should also be applicable to intra-AS situations. Networks do not work in > > isolation, so any proposal should be both distributed and hierarchical. > The > > algorithms should be applicable at every level of the hierarchy. > > > > *Should provide incentives for ISP for adoption* > > > > The engineering proposals should be aligned with commercial incentives > for > > rapid and widespread adoption. Today, the device manufacturers and the > ISPs > > operate independently of each other, and there is no incentive for > > manufacturers to work towards low-power and high bandwidth devices. An > > ISP=92s revenue model is based on the consumed bandwidth, which in turn > lea= > > d > > naturally to more power consumption. If the proposed method chooses > routers > > that consume low-power and increase the data flow through them, then this > > indirectly provides encouragement for ISPs to purchase low-power and high > > bandwidth devices. > > > > > > > > We now present our metric-based proposals in the below mentioned drafts > > which addresses the aforementioned design aspects. > > > > We would like the routing community to provide feedback on these drafts. > We > > also intend to present this work in an abridged format in the upcoming > IETF= > > . > > > > The drafts are as follows.... > > > > > > > > > > - mjsraman-panet-bgp-power-path< > http://tools.ietf.org/html/draft-mjsrama= > > n-panet-bgp-power-path> > > (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-bg= > > p-power-path-timing.html> > > Inter-AS-Proposal > > - mjsraman-panet-ecmp-redirect-power-repl-cap< > http://tools.ietf.org/html= > > /draft-mjsraman-panet-ecmp-redirect-power-repl-cap> > > (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-ec= > > mp-redirect-power-repl-cap-timing.html> > > Multicast > > - mjsraman-panet-inter-as-power-source< > http://tools.ietf.org/html/draft-= > > mjsraman-panet-inter-as-power-source> > > (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in= > > ter-as-power-source-timing.html> > > Inter-AS > > Proposal > > - mjsraman-panet-inter-as-psp< > http://tools.ietf.org/html/draft-mjsraman-= > > panet-inter-as-psp> > > (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in= > > ter-as-psp-timing.html> > > Inter-AS > > Proposal > > - mjsraman-panet-inter-as-psp-protect< > http://tools.ietf.org/html/draft-m= > > jsraman-panet-inter-as-psp-protect> > > (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in= > > ter-as-psp-protect-timing.html> > > Inter-AS > > Proposal > > - mjsraman-panet-pce-power-mcast-replic< > http://tools.ietf.org/html/draft= > > -mjsraman-panet-pce-power-mcast-replic> > > (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-pc= > > e-power-mcast-replic-timing.html> > > Multicast > > - mjsraman-panet-pim-power< > http://tools.ietf.org/html/draft-mjsraman-pan= > > et-pim-power> > > (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-pi= > > m-power-timing.html> > > Multicast > > - mjsraman-panet-tcam-power-efficiency< > http://tools.ietf.org/html/draft-= > > mjsraman-panet-tcam-power-efficiency> > > (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-tc= > > am-power-efficiency-timing.html> > > TCAM > > related > > - mjsraman-panet-tcam-power-ratio< > http://tools.ietf.org/html/draft-mjsra= > > man-panet-tcam-power-ratio> > > (timeline< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-tca= > > m-power-ratio-timing.html>) > > TCAM related > > - mjsraman-pce-power-replic< > http://tools.ietf.org/html/draft-mjsraman-pc= > > e-power-replic> > > (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-pce-powe= > > r-replic-timing.html> > > Multicast > > - mjsraman-panet-intra-as-psp-te-leak< > http://tools.ietf.org/html/draft-m= > > jsraman-panet-intra-as-psp-te-leak> > > (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in= > > tra-as-psp-te-leak-timing.html> > > Inter-Area > > within an AS > > - mjsraman-panet-ospf-power-topo< > http://tools.ietf.org/html/draft-mjsram= > > an-panet-ospf-power-topo> > > (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-os= > > pf-power-topo-timing.html> > > Intra-Area > > within an AS > > > > We understand it is a lot of matter to go through. We would much > appreciate > > if some of you could review the inter-AS proposals while others take up > > multicast and Intra-AS unicast and multicast. > > > > Thanks again for your time on this matter. > > > > thanks and regards, > > balaji venkat > --f46d0444ea7f7b901d04d512d5a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Curtis,

    As already stated to you in a private email= , "We" are a group of people with 40 years
    of collectiv= e industry experience in the networking industry. We dont need to be
    patronized by anybody since we have independent minds that have the ca= pability
    to digest information not based on somebody else's i= nterpretation of how future
    networks need to be built and how pow= er reduction needs to play a part in it.

    As you might recall one such research paper on GreenTE = by Beichuan Zhang=A0
    rang a lot of bells in the IETF by collectin= g the ANRP prize. So please dont misstate
    facts as you might know= them and shove your ideas of how networks are built
    down our throats.=A0

    We think the IETF is a f= ree and fair body that accepts opinions and ideas from
    all sides.= We want to keep this a free and fair organization. So incumbent=A0
    people like you ought to encourage us and have a fair argument when we pres= ent
    • such work to you. Dont follow the policy of exclusion to the = nth degree.=A0

    It is but fair to say that you seem= to be in a minority on this matter. Nobody else
    responded with unkind misstatements of facts and mis-understanding of = our=A0
    technical antecedents.

    Suffice to= say that if we get an opportunity to present this (since IETF is OUR
    organization too) you need not sit through it. If you want to give us = a fair hearing
    please follow a policy of kind inclusion and not c= reate a ruckus about us research
    folks trying to make an earnest = attempt at some practical research that could=A0
    well save the planet.

    Yours sincerely,
    <= div>Thanks and regards,
    balaji venkat and shankar raman

    On Thu, Feb 7, 2013 at 12:11 AM, Curtis Vil= lamizar <curtis@occnc.com> wrote:

    Balaji,

    "We" in the context of your first paragraph seems to be a
    misrepresentation. =A0The authors of all of these drafts seem to be from the same university in India. =A0From prior attempts on your part to get a draft of this sort into IDR and a brief reading of a few of the
    drafts that you have just submitted, you don't seem to have a good
    understanding of how networks are built and how network equipment is
    built from which to begin to attack the problem of reducing the power
    consumption of these networks.

    If you want to try to advance a research paper with your theories on
    power reduction, please choose an appropriate venue such as a refereed
    technical journal.

    Curtis


    In message <CAHF4apO9bEkPk7QwA9fgJq9BNUNHNv+OFon_9_4Oij61e1= 1r9w@mail.gmail.com>
    Balaji venkat Venkataswami writes:

    > Dear all,
    >
    > We are a group of research and industry individuals tied together with= a
    > common goal towards reducing the energy consumption in the core and ed= ge
    > networks.
    >
    > We present a metric-based hierarchical approach to reduce power consum= ption
    > in core and edge networks. The proposal considers both unicast and the=
    > multicast cases. For unicast, the metric considered is *consumed= -power to
    > available-bandwidth* and for multicast the metric is *consumed-power t= o
    > available-replication-capacity.*
    >
    > =A0With unicast, the metric is used to determine a low-power path betw= een
    > sources and destinations. With multicast, the metric serves the twin > purpose of finding low-power multicast paths as well as multicast
    > replication points. =A0We evolve multiple techniques at various hierar= chical
    > levels. One at the Inter-AS level, Inter-Area level within the AS and<= br> > intra-Area within an AS. Additionally, the proposed method can also be= used
    > to determine disjoint or redundant paths for load balancing or fault > tolerance. Additionally since TCAMs are one of the biggest power guzzl= ers
    > in all the components on a router/switch, we have presented a solution= for
    > intra-AS purposes to use the TCAM according to the traffic matrix pass= ing
    > through the system and shut down those TCAM banks that are unused. Wit= h
    > this in mind, we have also advocated taking into account a TCAM-POWER-= Ratio
    > in order to compute the paths from source to destination based on this=
    > metric. Once low-power paths, in either the unicast or the multicast c= ases,
    > are identified then currently available traffic engineering techniques=
    > could be used to route the data packets. In the case of inter-AS BGP p= ath
    > selection is also modified to arrive at paths which are low-power path= s.
    >
    > =A0Our main objective is as follows...
    >
    > We now outline four important aspects that any approach for power redu= ction
    > should be capable of addressing.
    >
    > =A0*Should cater for both unicast and multicast scenarios*
    >
    > Multicast provides an important scenario for the Internet. Today, most=
    > proposals consider mainly low-power path routing with unicast traffic.=
    > Multicast traffic has received a lot of attention in wireless networks= , but
    > not in the wired domain. Any new proposal should be able to address bo= th
    > the unicast and the multicast traffic scenarios. Having different meth= ods
    > for these two scenarios might lead to unnecessary processing burden in= the
    > routers, which might hinder its scalability.
    >
    > =A0*Should not rely on just switching off unused links*
    >
    > Most approaches to optimize energy pursue the following approach: meas= ure,
    > monitor and respond to the system energy usage by switching off unused= or
    > under-utilized links. Such an approach could be effective for reducing=
    > power locally. The effect on the network is not clearly understood. > Further, the power usage involved in turning on and rebooting/reconfig= uring
    > the device is often not explicitly considered. We note that Service Le= vel
    > Agreement (SLA) requirements may not even permit the links to be switc= hed
    > off. Also services provided by ISPs like Virtual Private Networks (VPN= s)
    > can be affected by such re-routing decisions.
    >
    > =A0*Should follow an hierarchical and distributed approach*
    >
    > For scalability, it is important that the algorithms proposed for inte= r-AS
    > should also be applicable to intra-AS situations. Networks do not work= in
    > isolation, so any proposal should be both distributed and hierarchical= . The
    > algorithms should be applicable at every level of the hierarchy.
    >
    > =A0*Should =A0provide incentives for ISP for adoption*
    >
    > The engineering proposals should be aligned with commercial incentives= for
    > rapid and widespread adoption. Today, the device manufacturers and the= ISPs
    > operate independently of each other, and there is no incentive for
    > manufacturers to work towards low-power and high bandwidth devices. An=
    > ISP=3D92s revenue model is based on the consumed bandwidth, whic= h in turn lea=3D
    > d
    > naturally to more power consumption. If the proposed= method chooses routers
    > that consume low-power and increase the data flow through them, then t= his
    > indirectly provides encouragement for ISPs to purchase low-power and h= igh
    > bandwidth devices.
    >
    >
    >
    > We now present our metric-based proposals in the below mentioned draft= s
    > which addresses the aforementioned design aspects.
    >
    > We would like the routing community to provide feedback on these draft= s. We
    > also intend to present this work in an abridged format in the up= coming IETF=3D
    > .
    >
    > =A0The drafts are as follows....
    >
    >
    >
    >
    > =A0 =A0- mjsraman-panet-bgp-power-path<http://tools.ietf.org/h= tml/draft-mjsrama=3D
    > n-panet-bgp-power-path>
    > =A0 =A0 (timeline)<http://www.arkko.com/tools/li= fecycle/draft-mjsraman-panet-bg=3D
    > p-power-path-timing.html>
    > =A0 =A0 Inter-AS-Proposal
    > =A0 =A0- mjsraman-panet-ecmp-redirect-power-repl-cap<http://tools.ietf.org/html=3D=
    > /draft-mjsraman-panet-ecmp-redirect-power-repl-cap>
    > =A0 =A0 (timeline)<http://www.arkko.com/tools/li= fecycle/draft-mjsraman-panet-ec=3D
    > mp-redirect-power-repl-cap-timing.html>
    > =A0 =A0 Multicast
    > =A0 =A0- mjsraman-panet-inter-as-power-source<http://tools.ietf.org/html/dr= aft-=3D
    > mjsraman-panet-inter-as-power-source>
    > =A0 =A0 (timeline)<http://www.arkko.com/tools/li= fecycle/draft-mjsraman-panet-in=3D
    > ter-as-power-source-timing.html>
    > Inter-AS
    > =A0 =A0Proposal
    > =A0 =A0- mjsraman-panet-inter-as-psp<http://tools.ietf.org/html/dr= aft-mjsraman-=3D
    > panet-inter-as-psp>
    > =A0 =A0 (timeline)<http://www.arkko.com/tools/li= fecycle/draft-mjsraman-panet-in=3D
    > ter-as-psp-timing.html>
    > Inter-AS
    > =A0 =A0Proposal
    > =A0 =A0- mjsraman-panet-inter-as-psp-protect<http://tools.ietf.org/html/dr= aft-m=3D
    > jsraman-panet-inter-as-psp-protect>
    > =A0 =A0 (timeline)<http://www.arkko.com/tools/li= fecycle/draft-mjsraman-panet-in=3D
    > ter-as-psp-protect-timing.html>
    > Inter-AS
    > =A0 =A0Proposal
    > =A0 =A0- mjsraman-panet-pce-power-mcast-replic<http://tools.ietf.org/html/dr= aft=3D
    > -mjsraman-panet-pce-power-mcast-replic>
    > =A0 =A0 (timeline)<http://www.arkko.com/tools/li= fecycle/draft-mjsraman-panet-pc=3D
    > e-power-mcast-replic-timing.html>
    > =A0 =A0 Multicast
    > =A0 =A0- mjsraman-panet-pim-power<http://tools.ietf.org/html/dr= aft-mjsraman-pan=3D
    > et-pim-power>
    > =A0 =A0 (timeline)<http://www.arkko.com/tools/li= fecycle/draft-mjsraman-panet-pi=3D
    > m-power-timing.html>
    > =A0 =A0 Multicast
    > =A0 =A0- mjsraman-panet-tcam-power-efficiency<http://tools.ietf.org/html/dr= aft-=3D
    > mjsraman-panet-tcam-power-efficiency>
    > =A0 =A0 (timeline)<http://www.arkko.com/tools/li= fecycle/draft-mjsraman-panet-tc=3D
    > am-power-efficiency-timing.html>
    > TCAM
    > =A0 =A0related
    > =A0 =A0- mjsraman-panet-tcam-power-ratio<http://tools.ietf.org/html/dr= aft-mjsra=3D
    > man-panet-tcam-power-ratio>
    > =A0 =A0 (timeline<http://www.arkko.com/tools/li= fecycle/draft-mjsraman-panet-tca=3D
    > m-power-ratio-timing.html>)
    > =A0 =A0TCAM related
    > =A0 =A0- mjsraman-pce-power-replic<http://tools.ietf.org/html/dr= aft-mjsraman-pc=3D
    > e-power-replic>
    > =A0 =A0 (timeline)<http://www.arkko.com/tools/li= fecycle/draft-mjsraman-pce-powe=3D
    > r-replic-timing.html>
    > =A0 =A0 Multicast
    > =A0 =A0- mjsraman-panet-intra-as-psp-te-leak<http://tools.ietf.org/html/dr= aft-m=3D
    > jsraman-panet-intra-as-psp-te-leak>
    > =A0 =A0 (timeline)<http://www.arkko.com/tools/li= fecycle/draft-mjsraman-panet-in=3D
    > tra-as-psp-te-leak-timing.html>
    > Inter-Area
    > =A0 =A0within an AS
    > =A0 =A0- mjsraman-panet-ospf-power-topo<http://tools.ietf.org/html/dr= aft-mjsram=3D
    > an-panet-ospf-power-topo>
    > =A0 =A0 (timeline)<http://www.arkko.com/tools/li= fecycle/draft-mjsraman-panet-os=3D
    > pf-power-topo-timing.html>
    > Intra-Area
    > =A0 =A0within an AS
    >
    > We understand it is a lot of matter to go through. We would much appre= ciate
    > if some of you could review the inter-AS proposals while others take u= p
    > multicast and Intra-AS unicast and multicast.
    >
    > Thanks again for your time on this matter.
    >
    > thanks and regards,
    > balaji venkat

    --f46d0444ea7f7b901d04d512d5a2-- From curtis@occnc.com Wed Feb 6 12:07:45 2013 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 D544021F88E3 for ; Wed, 6 Feb 2013 12:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.329 X-Spam-Level: X-Spam-Status: No, score=-0.329 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSiuJoGrA2pC for ; Wed, 6 Feb 2013 12:07:45 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4C221F8652 for ; Wed, 6 Feb 2013 12:07:45 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r16K5CQS084848; Wed, 6 Feb 2013 15:05:12 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302062005.r16K5CQS084848@gateway1.orleans.occnc.com> To: Balaji venkat Venkataswami From: Curtis Villamizar Subject: Re: Power aware networks : Comments requested from routing community In-reply-to: Your message of "Thu, 07 Feb 2013 00:22:54 +0530." Date: Wed, 06 Feb 2013 15:05:12 -0500 Cc: Shankar Raman M J , 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: Wed, 06 Feb 2013 20:07:45 -0000 In message Balaji venkat Venkataswami writes: > As you might recall one such research paper on GreenTE by Beichuan > Zhang rang a lot of bells in the IETF by collecting the ANRP prize. So > please dont misstate facts as you might know them and shove your ideas > of how networks are built down our throats. That was a research paper published in IEEE International Conference on Network Protocols (ICNP). Power savings potential (a computation, not a measurement) were as high as 20-40%. That is good but ... Line cards considered were old OC3, OC48, and one port OC192 cards. The paper ignores the reality that shutting off one port on a multiport card makes little difference, certainly far less than a reduction of 1/N. The power consumption of transport was not included. Impact on fault restoration was not considered. Lots of other flaws, but still good work and a potential 20-40% is nice, even if factoring in reality might get only half that or less. The point though is that a 1 port OC192 at 174 watts (10 Gb/s) is no match for a 500 Gb/s card at roughly 650 watts. That is more than 40%. It is more than a decimal order of magnitude greater. It is not comparing apples to oranges, one is an IP/MPLS router with full routing tables and short haul interfaces, the other does OTN switching drives either short haul or long haul transport interfaces, and could do IP/MPLS, but with only IGP routes and MPLS LSPs at that power figure. So maybe the way the network is built needs to change. Anyway, if *I* were to continue this discussion, then *I* should get off the IETF lists and go write an academic paper. [Or better yet, work for a service provider or equipment vendor and work toward building better equipment and networks.] The point is that efficiency has gone up by orders of magnitude as we went from OC3 to OC12 to OC48 to OC192 (circa 1995-2000) and then multiport OC192 and OC768 and 10GbE (circa 2005-2010) to 100GbE and ODU4 (somewhat recent) to multiport 100GbE and ODU4 (even more recent). Power per bit drops about one to two decimal order of magnitude per decade and for any given a specific snapshot in the technology timeline, there are means to reduce power that get far more than the 20-40% that GreenTE potentially offers. Of course a new generation of equipment means CapEx and GreenTE is perceived as just routing and therefore free, so therefore the interest. Another point is that no one ever tried this on a real network. With RSVP-TE no protocol changes would be necessary, just offline computation, a configured preferred explicit-path, and some interface shutdowns. I don't know that anyone has even measured the reduction in power of an idled or administratively shut down interface or line card. There was nothing in the paper on this. > > If you want to try to advance a research paper with your theories on > > power reduction, please choose an appropriate venue such as a refereed > > technical journal. I repeat my main point. [And hope to be among the reviewers] Also IMHO GreenTE as described by Zhang is more likely to be feasible with MPLS and RSVP-TE than with OSPF or BGP or PIM, etc. But then, the feasibility and potential benefits of GreenTE using IGP, BGP, and PIM is what your academic paper can try to defend. Thank you, Curtis From agmalis@gmail.com Wed Feb 6 12:14:20 2013 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 77B2221F88E3 for ; Wed, 6 Feb 2013 12:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Z3PDuyLjIG5 for ; Wed, 6 Feb 2013 12:14:19 -0800 (PST) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id 5F20921F891D for ; Wed, 6 Feb 2013 12:14:19 -0800 (PST) Received: by mail-qe0-f46.google.com with SMTP id 1so834592qec.19 for ; Wed, 06 Feb 2013 12:14:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=YzJxNOWF4hXWS3SQ4daDOg37kR7dyRqDrXC4L0T7Wxw=; b=HQLTEJNHPLmN9gGXu7ZsxYva+vel+/k7prYBzwmOmZtVcnYLHCjUZk+6kgNJB9l35m W4VD9NoLK2ynXVz/TSng6Wh9YwFdLS1oQSWVwKTeYadL+xy6wQ9T6i9xo9WYFDnTKP+F r1VkznMYkqlrnuP34wc178IeqKJ4RRlxx0owWfxfSMGY1VXDyTJYkcyU1K3qVmf3AlWv YPwBWePwMmO7PjMB3kphaX0HdMp5305vP0RIrVKlm2zgNAwBcZ9qK4KRzHz1rGK26yVG O4tWdBku2oaq4ttm075TmZQyHBNgryB5vW0xWngDkiSqJb5klEFj7WAZQ82hI8S5lx1I r/+A== X-Received: by 10.224.179.205 with SMTP id br13mr21766787qab.37.1360181658901; Wed, 06 Feb 2013 12:14:18 -0800 (PST) MIME-Version: 1.0 Sender: agmalis@gmail.com Received: by 10.229.78.72 with HTTP; Wed, 6 Feb 2013 12:13:58 -0800 (PST) In-Reply-To: <201302051954.r15Js12Y072536@gateway1.orleans.occnc.com> References: <201302051954.r15Js12Y072536@gateway1.orleans.occnc.com> From: "Andrew G. Malis" Date: Wed, 6 Feb 2013 15:13:58 -0500 X-Google-Sender-Auth: Q4uwFvVsZf082bzPw-LaQ9xo0nw Message-ID: Subject: Re: Expiration impending: To: Curtis Villamizar Content-Type: multipart/alternative; boundary=485b397dcd5b9bdd0404d513f8af Cc: RTGWG Working Group , So Ning 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, 06 Feb 2013 20:14:20 -0000 --485b397dcd5b9bdd0404d513f8af Content-Type: text/plain; charset=ISO-8859-1 I agree with Curtis' suggested plan to advance CL Requirements now and continue work on the other two drafts. Cheers, Andy On Tue, Feb 5, 2013 at 2:54 PM, Curtis Villamizar wrote: > > In message M20V5ye76EW8xZ3CmA@mail.gmail.com> > Alia Atlas writes: > > > That sounds good to me. > > > > I would really like to see the composite link work advance - > > preferably by or just after the next IETF. I encourage everyone to > > read and comment on it; I will do so as well and send comments > > separately. > > > > Alia > > > Alia, > > Perhaps we should consider advancing CL Requirements alone. It has > been quite stable for a long time. Perhaps repeat last call and > advance to the AD review. > > CL Use Cases has also been stable, but it has received so few comments > that it is hard to say there is concensus. It could stand some > improvement IMHO, and I'm an author. > > CL Framework will take some time. Progress may be needed on some of > the docs referenced by CL Framework before we can consider advancing > it. Referenced docs should at least all be WG docs with a reasonable > chance of advancing rather than being abandonned. > > Curtis > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --485b397dcd5b9bdd0404d513f8af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    I agree with Curtis' suggested plan to advance CL= Requirements now and continue work on the other two drafts.

    C= heers,
    Andy



    On Tue, Feb 5, 2013 at 2:54 PM, Curtis Villamizar <curtis@occnc.com>= wrote:

    In message <CAG4d1rej2s37bt0ESO7NKUm6xjSe1ui=3DM20V5ye76EW8xZ3CmA@mail.gmail.com>
    Alia Atlas writes:

    > That sounds good to me.
    >
    > I would really like to see the composite link work advance -
    > preferably by or just after the next IETF. =A0I encourage everyone to<= br> > read and comment on it; I will do so as well and send comments
    > separately.
    >
    > Alia


    Alia,

    Perhaps we should consider advancing CL Requirements alone. =A0It has
    been quite stable for a long time. =A0Perhaps repeat last call and
    advance to the AD review.

    CL Use Cases has also been stable, but it has received so few comments
    that it is hard to say there is concensus. =A0It could stand some
    improvement IMHO, and I'm an author.

    CL Framework will take some time. =A0Progress may be needed on some of
    the docs referenced by CL Framework before we can consider advancing
    it. =A0Referenced docs should at least all be WG docs with a reasonable
    chance of advancing rather than being abandonned.

    Curtis
    _______________________________________________
    rtgwg mailing list
    rtgwg@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/rtgwg

    --485b397dcd5b9bdd0404d513f8af-- From eosborne@cisco.com Wed Feb 6 12:20:35 2013 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 D922721F868D for ; Wed, 6 Feb 2013 12:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.441 X-Spam-Level: X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNwEIOxxeKuF for ; Wed, 6 Feb 2013 12:20:33 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id EC0BC21F860A for ; Wed, 6 Feb 2013 12:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15936; q=dns/txt; s=iport; t=1360182032; x=1361391632; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+OJS1s9Joi5EIFKwEBBcg9B7DaK1Y8oumUe/YufhO5A=; b=FI0cZQhAIlv6roa8MP/ZIEFrYLEP2n6wxmkKZ6J6uh8rnIfeOrwPY802 KhE0j5PBmu/ih6+8ZKfxmvB5n3p4Us+QKCDneBMWRD2bSI7L/JZ9suWLh 8Z/YSbhQ3L2aOaijM06VOos9JTuOl4duNDIk1In2qCpFW0fRDZAK/WQsn U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAEu6ElGtJV2b/2dsb2JhbABFFsA2FnOCGAMEAQEBAgEBOjABCAYMBAIBCBEEAQEBCgsJCQcyFAkIAgQBDQUIDAcBBIUpB4IjDAMJBgyyYw2JVo0QARABgQKCVGEDaJFGOoRWiiWFEIJ+gW81 X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; d="scan'208";a="174167229" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 06 Feb 2013 20:20:31 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r16KKVdC013180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Feb 2013 20:20:31 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Wed, 6 Feb 2013 14:20:30 -0600 From: "Eric Osborne (eosborne)" To: Balaji venkat Venkataswami , "curtis@occnc.com" Subject: RE: Power aware networks : Comments requested from routing community Thread-Topic: Power aware networks : Comments requested from routing community Thread-Index: AQHOBJmILt1Dff9vjkCrdfxQNrUVWphtkbkA//+h48A= Date: Wed, 6 Feb 2013 20:20:29 +0000 Message-ID: <20ECF67871905846A80F77F8F4A27572100BEE0B@xmb-rcd-x09.cisco.com> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.23.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Shankar Raman M J , "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: Wed, 06 Feb 2013 20:20:35 -0000 You aim to optimize core networks through traffic engineering such that som= e links can be shut down when not in use, or switched to lower power. Have you done studies in core networks with real equipment that show the ac= tual amount of money you could save with this approach? Let's walk through= a quick hypothetical network, you tell me where I got it wrong. draft-mjsraman-panet-bgp-power-path says " Power consumption can be reduced by trading off performance related measures like latency. For example, power savings while switching from 1 Gbps to 100 Mbps is approximately 4 W and from 100 Mbps to 10 Mbps around 0.1 Watts." but provides no documentation to back these costs up nor itemization of whe= re the power is consumed (amortized across the router? linecard optics? D= WDM gear?) Let's assume that this is true and that it is linear, so that you burn 4W p= er Gb. (side note: I suspect this is inaccurate and that scaling is sublin= ear, but let's go with it because if it's sub-linear you have even less of = a use case. I also think the real world is far more complex, as you have a= ll the optical transport gear to worry about. But let's go with it for now= .) Running a 100Gb link thus draws 400W. Let's say you have a backbone with (300) 100Gb links. Total power consumpt= ion is thus (300*400) =3D=3D 120 kW Running all these links for 24 hours thus draws 120*24 =3D=3D 2,880 kWh = =3D=3D 2.8mWh Power costs are maybe $0.10/kWh in the US. Double that to cover the cost o= f cooling, so $0.20/kWh. Thus, running the entire backbone costs $0.2 * 2,880 =3D $576/day. $210,00= 0/year. Let's say your approach can save one third of the power cost, which means a= bout $70,000. An operator with 300 100Gb links in a network has hundreds of millions of d= ollars worth of gear and millions or tens of millions in payroll alone. If= you cut $70k from their opex they probably wouldn't even notice. That's o= ne or two salaries, or 0.002% of what Time Warner spent on advertising in 2= 006 (see: http://gaia.adage.com/images/random/FactPack06.pdf). It is a dro= p in the bucket, if that. And your proposal comes with significant work at= tached to it, and significant risk. If your 40 years of experience in the = network industry don't help you understand the risks you're asking an opera= tor to take then you're missing a crucial part of any potential real world = solution. I do not think your work should be presented at the IETF unless = it makes a much stronger argument that its benefits outweigh its costs. These sorts of power optimizations all seem to be "here's how you reshape t= he problem so that you can throw a linear problem solver at it". For examp= le, [ http://www.cs.berkeley.edu/~suchara/publications/GreenNetsBundles.pdf= ]. I've never seen anything which shows how much more work it will be for= a network operator or which quantifies the actual savings. If you can demonstrate significant savings in real networks at little or no= cost to operators, you have an idea worth pursuing. If your idea will cau= se more operational angst (e.g. not knowing whether your unused capacity wi= ll be there when you need it because you shut a third of it off all the tim= e, increased risk of equipment failure from constant power-cycling, operati= onal tools and training and expertise required to manage, deploy and troubl= eshoot variable-power links and the centralized NMS required to run them, e= tc etc etc) then it will find little traction. Green-TE and power-aware BG= P have been floating around for a while and have seen no real uptake in the= WGs as far as I can see. Is that not to be taken as an indication that th= ere may be no real-world interest in them? If not, what would it take to c= onvince you? eric > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Balaji venkat Venkataswami > Sent: Wednesday, February 06, 2013 1:53 PM > To: curtis@occnc.com > Cc: Shankar Raman M J; rtgwg@ietf.org > Subject: Re: Power aware networks : Comments requested from routing > community >=20 > Dear Curtis, >=20 > As already stated to you in a private email, "We" are a group of people w= ith 40 > years of collective industry experience in the networking industry. We do= nt > need to be patronized by anybody since we have independent minds that hav= e > the capability to digest information not based on somebody else's > interpretation of how future networks need to be built and how power > reduction needs to play a part in it. >=20 > As you might recall one such research paper on GreenTE by Beichuan Zhang > rang a lot of bells in the IETF by collecting the ANRP prize. So please d= ont > misstate facts as you might know them and shove your ideas of how network= s > are built down our throats. >=20 > We think the IETF is a free and fair body that accepts opinions and ideas= from > all sides. We want to keep this a free and fair organization. So incumben= t > people like you ought to encourage us and have a fair argument when we > present such work to you. Dont follow the policy of exclusion to the nth = degree. >=20 > It is but fair to say that you seem to be in a minority on this matter. N= obody > else responded with unkind misstatements of facts and mis-understanding o= f > our technical antecedents. >=20 > Suffice to say that if we get an opportunity to present this (since IETF = is OUR > organization too) you need not sit through it. If you want to give us a f= air > hearing please follow a policy of kind inclusion and not create a ruckus = about us > research folks trying to make an earnest attempt at some practical resear= ch > that could well save the planet. >=20 > Yours sincerely, > Thanks and regards, > balaji venkat and shankar raman >=20 > On Thu, Feb 7, 2013 at 12:11 AM, Curtis Villamizar wro= te: >=20 >=20 >=20 > Balaji, >=20 > "We" in the context of your first paragraph seems to be a > misrepresentation. The authors of all of these drafts seem to be from > the same university in India. From prior attempts on your part to get > a draft of this sort into IDR and a brief reading of a few of the > drafts that you have just submitted, you don't seem to have a good > understanding of how networks are built and how network equipment > is > built from which to begin to attack the problem of reducing the power > consumption of these networks. >=20 > If you want to try to advance a research paper with your theories on > power reduction, please choose an appropriate venue such as a > refereed > technical journal. >=20 > Curtis >=20 >=20 > In message > com > mail.gmail.com> > >=20 > Balaji venkat Venkataswami writes: >=20 > > Dear all, > > > > We are a group of research and industry individuals tied together > with a > > common goal towards reducing the energy consumption in the core > and edge > > networks. > > > > We present a metric-based hierarchical approach to reduce power > consumption > > in core and edge networks. The proposal considers both unicast and > the >=20 > > multicast cases. For unicast, the metric considered is *consumed- > power to > > available-bandwidth* and for multicast the metric is *consumed- > power to > > available-replication-capacity.* >=20 > > > > With unicast, the metric is used to determine a low-power path > between > > sources and destinations. With multicast, the metric serves the twin > > purpose of finding low-power multicast paths as well as multicast > > replication points. We evolve multiple techniques at various > hierarchical > > levels. One at the Inter-AS level, Inter-Area level within the AS and > > intra-Area within an AS. Additionally, the proposed method can also > be used > > to determine disjoint or redundant paths for load balancing or fault > > tolerance. Additionally since TCAMs are one of the biggest power > guzzlers > > in all the components on a router/switch, we have presented a > solution for > > intra-AS purposes to use the TCAM according to the traffic matrix > passing > > through the system and shut down those TCAM banks that are > unused. With > > this in mind, we have also advocated taking into account a TCAM- > POWER-Ratio > > in order to compute the paths from source to destination based on > this > > metric. Once low-power paths, in either the unicast or the multicast > cases, > > are identified then currently available traffic engineering techniques > > could be used to route the data packets. In the case of inter-AS BGP > path > > selection is also modified to arrive at paths which are low-power > paths. > > > > Our main objective is as follows... > > > > We now outline four important aspects that any approach for power > reduction > > should be capable of addressing. > > >=20 > > *Should cater for both unicast and multicast scenarios* >=20 > > > > Multicast provides an important scenario for the Internet. Today, > most > > proposals consider mainly low-power path routing with unicast > traffic. > > Multicast traffic has received a lot of attention in wireless networks= , > but > > not in the wired domain. Any new proposal should be able to address > both > > the unicast and the multicast traffic scenarios. Having different > methods > > for these two scenarios might lead to unnecessary processing burden > in the > > routers, which might hinder its scalability. > > >=20 > > *Should not rely on just switching off unused links* >=20 > > > > Most approaches to optimize energy pursue the following approach: > measure, > > monitor and respond to the system energy usage by switching off > unused or > > under-utilized links. Such an approach could be effective for reducing > > power locally. The effect on the network is not clearly understood. > > Further, the power usage involved in turning on and > rebooting/reconfiguring > > the device is often not explicitly considered. We note that Service > Level > > Agreement (SLA) requirements may not even permit the links to be > switched > > off. Also services provided by ISPs like Virtual Private Networks > (VPNs) > > can be affected by such re-routing decisions. > > >=20 > > *Should follow an hierarchical and distributed approach* >=20 > > > > For scalability, it is important that the algorithms proposed for inte= r- > AS > > should also be applicable to intra-AS situations. Networks do not work > in > > isolation, so any proposal should be both distributed and hierarchical= . > The > > algorithms should be applicable at every level of the hierarchy. > > >=20 > > *Should provide incentives for ISP for adoption* >=20 > > > > The engineering proposals should be aligned with commercial > incentives for > > rapid and widespread adoption. Today, the device manufacturers and > the ISPs > > operate independently of each other, and there is no incentive for > > manufacturers to work towards low-power and high bandwidth > devices. An >=20 > > ISP=3D92s revenue model is based on the consumed bandwidth, which > in turn lea=3D > > d >=20 > > naturally to more power consumption. If the proposed method > chooses routers > > that consume low-power and increase the data flow through them, > then this > > indirectly provides encouragement for ISPs to purchase low-power > and high > > bandwidth devices. > > > > > > > > We now present our metric-based proposals in the below mentioned > drafts > > which addresses the aforementioned design aspects. > > > > We would like the routing community to provide feedback on these > drafts. We >=20 > > also intend to present this work in an abridged format in the > upcoming IETF=3D >=20 > > . > > > > The drafts are as follows.... > > > > > > > > >=20 > > - mjsraman-panet-bgp-power-path mjsrama=3D > > n-panet-bgp-power-path> > > (timeline) panet-bg=3D > > p-power-path-timing.html> > > Inter-AS-Proposal > > - mjsraman-panet-ecmp-redirect-power-repl- > cap > /draft-mjsraman-panet-ecmp-redirect-power-repl-cap> > > (timeline) panet-ec=3D > > mp-redirect-power-repl-cap-timing.html> > > Multicast > > - mjsraman-panet-inter-as-power- > source > mjsraman-panet-inter-as-power-source> > > (timeline) panet-in=3D > > ter-as-power-source-timing.html> > > Inter-AS > > Proposal > > - mjsraman-panet-inter-as-psp mjsraman-=3D > > panet-inter-as-psp> > > (timeline) panet-in=3D > > ter-as-psp-timing.html> > > Inter-AS > > Proposal > > - mjsraman-panet-inter-as-psp- > protect > jsraman-panet-inter-as-psp-protect> > > (timeline) panet-in=3D > > ter-as-psp-protect-timing.html> > > Inter-AS > > Proposal > > - mjsraman-panet-pce-power-mcast- > replic > -mjsraman-panet-pce-power-mcast-replic> > > (timeline) panet-pc=3D > > e-power-mcast-replic-timing.html> > > Multicast > > - mjsraman-panet-pim-power mjsraman-pan=3D > > et-pim-power> > > (timeline) panet-pi=3D > > m-power-timing.html> > > Multicast > > - mjsraman-panet-tcam-power- > efficiency > mjsraman-panet-tcam-power-efficiency> > > (timeline) panet-tc=3D > > am-power-efficiency-timing.html> > > TCAM > > related > > - mjsraman-panet-tcam-power- > ratio > man-panet-tcam-power-ratio> > > (timeline panet-tca=3D > > m-power-ratio-timing.html>) > > TCAM related > > - mjsraman-pce-power-replic mjsraman-pc=3D > > e-power-replic> > > (timeline) pce-powe=3D > > r-replic-timing.html> > > Multicast > > - mjsraman-panet-intra-as-psp-te- > leak > jsraman-panet-intra-as-psp-te-leak> > > (timeline) panet-in=3D > > tra-as-psp-te-leak-timing.html> > > Inter-Area > > within an AS > > - mjsraman-panet-ospf-power-topo mjsram=3D > > an-panet-ospf-power-topo> > > (timeline) panet-os=3D > > pf-power-topo-timing.html> >=20 > > Intra-Area > > within an AS > > > > We understand it is a lot of matter to go through. We would much > appreciate > > if some of you could review the inter-AS proposals while others take > up > > multicast and Intra-AS unicast and multicast. > > > > Thanks again for your time on this matter. > > > > thanks and regards, > > balaji venkat >=20 >=20 From lucy.yong@huawei.com Wed Feb 6 12:38:33 2013 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 E7D8A21F861A for ; Wed, 6 Feb 2013 12:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.848 X-Spam-Level: X-Spam-Status: No, score=-6.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIX3bEOcZd7a for ; Wed, 6 Feb 2013 12:38:33 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8C68821F8625 for ; Wed, 6 Feb 2013 12:38:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOF62498; Wed, 06 Feb 2013 20:38:17 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 6 Feb 2013 20:37:21 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 6 Feb 2013 20:38:16 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Wed, 6 Feb 2013 12:38:11 -0800 From: Lucy yong To: "Andrew G. Malis" , Curtis Villamizar Subject: RE: Expiration impending: Thread-Topic: Expiration impending: Thread-Index: AQHOA9qKKBANLA05ikm5ZECusI6COJhty2QA//+AnXA= Date: Wed, 6 Feb 2013 20:38:09 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4488F106@dfweml505-mbx> References: <201302051954.r15Js12Y072536@gateway1.orleans.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.83.20] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4488F106dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: So Ning , RTGWG Working Group 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, 06 Feb 2013 20:38:34 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D4488F106dfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Lucy From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of A= ndrew G. Malis Sent: Wednesday, February 06, 2013 2:14 PM To: Curtis Villamizar Cc: RTGWG Working Group; So Ning Subject: Re: Expiration impending: I agree with Curtis' suggested plan to advance CL Requirements now and cont= inue work on the other two drafts. Cheers, Andy On Tue, Feb 5, 2013 at 2:54 PM, Curtis Villamizar > wrote: In message > Alia Atlas writes: > That sounds good to me. > > I would really like to see the composite link work advance - > preferably by or just after the next IETF. I encourage everyone to > read and comment on it; I will do so as well and send comments > separately. > > Alia Alia, Perhaps we should consider advancing CL Requirements alone. It has been quite stable for a long time. Perhaps repeat last call and advance to the AD review. CL Use Cases has also been stable, but it has received so few comments that it is hard to say there is concensus. It could stand some improvement IMHO, and I'm an author. CL Framework will take some time. Progress may be needed on some of the docs referenced by CL Framework before we can consider advancing it. Referenced docs should at least all be WG docs with a reasonable chance of advancing rather than being abandonned. Curtis _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --_000_2691CE0099834E4A9C5044EEC662BB9D4488F106dfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    +1<= /p>

     <= /p>

    Lucy

     <= /p>

    From: rtgwg-bo= unces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Andrew G. Malis
    Sent: Wednesday, February 06, 2013 2:14 PM
    To: Curtis Villamizar
    Cc: RTGWG Working Group; So Ning
    Subject: Re: Expiration impending: <draft-ietf-rtgwg-cl-requireme= nt-08.txt>

     

    I agree with Curtis' = suggested plan to advance CL Requirements now and continue work on the othe= r two drafts.

    Cheers,
    Andy

     

    On Tue, Feb 5, 2013 at 2:54 PM, Curtis Villamizar &l= t;curtis@occnc.com> wrote:


    In message <CAG4d1rej2s37bt0ESO7NKUm6xjSe1ui=3D    M20V5ye76EW8xZ3CmA@mail.gmail.com><= /o:p>

    Alia Atlas writes:
    > That sounds good to me.
    >
    > I would really like to see the composite link work advance -
    > preferably by or just after the next IETF.  I encourage everyone = to
    > read and comment on it; I will do so as well and send comments
    > separately.
    >
    > Alia

    Alia,

    Perhaps we should consider advancing CL Requirements alone.  It has been quite stable for a long time.  Perhaps repeat last call and
    advance to the AD review.

    CL Use Cases has also been stable, but it has received so few comments
    that it is hard to say there is concensus.  It could stand some
    improvement IMHO, and I'm an author.

    CL Framework will take some time.  Progress may be needed on some of the docs referenced by CL Framework before we can consider advancing
    it.  Referenced docs should at least all be WG docs with a reasonable<= br> chance of advancing rather than being abandonned.


    Curtis
    _______________________________________________
    rtgwg mailing list
    rtgwg@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/rtgwg

     

    --_000_2691CE0099834E4A9C5044EEC662BB9D4488F106dfweml505mbx_-- From balajivenkat299@gmail.com Wed Feb 6 13:06:57 2013 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 5165C21F8619 for ; Wed, 6 Feb 2013 13:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.445 X-Spam-Level: ** X-Spam-Status: No, score=2.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYZRiN4PugGm for ; Wed, 6 Feb 2013 13:06:55 -0800 (PST) Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8507421F8615 for ; Wed, 6 Feb 2013 13:06:55 -0800 (PST) Received: by mail-ia0-f177.google.com with SMTP id h8so2180814iaa.36 for ; Wed, 06 Feb 2013 13:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=3sb6DbCBl5ciK7Te2n+H/+VcfIcjk6PmW5hqQ2b82Vs=; b=o91eUqUOgD8Mlrwj1/ww4AAjoPQRXswLmkRf9fXEV1YOjExIS8AFw1ELUNhwlg2JzK l3zh3KqAvb5ASYHS55Wh2xZv8K9IfWea4tKe1XHFtrIzR9LO65r7MBKHRbtAkkTL++Fj p+Z6FWMCc89l57DH/1sZdrIN98BtHzVvgI2gitOksT5TqagBH/fesUpD6FhS5d8qm5bn 5Z6+hJJysmXtxa/V2uc23QoDsi5jmKRIm90mxNUpNQdHgBQQbQADNpC2DX2tzbKce6Vv kzzERWl1QZPd8UXncwv2fRQwzB43FyI+AZOubHFkFXRNfHoeukZaPqzn5dl6Ucr7Nyyb PRLA== X-Received: by 10.42.58.202 with SMTP id j10mr31164237ich.39.1360184814905; Wed, 06 Feb 2013 13:06:54 -0800 (PST) Received: from [192.168.15.106] ([122.174.5.54]) by mx.google.com with ESMTPS id d1sm3909133paz.17.2013.02.06.13.06.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Feb 2013 13:06:54 -0800 (PST) References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <20ECF67871905846A80F77F8F4A27572100BEE0B@xmb-rcd-x09.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20ECF67871905846A80F77F8F4A27572100BEE0B@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A523) From: Balaji Venkat Subject: Re: Power aware networks : Comments requested from routing community Date: Thu, 7 Feb 2013 02:36:11 +0530 To: "Eric Osborne (eosborne)" Cc: Shankar Raman M J , "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: Wed, 06 Feb 2013 21:06:57 -0000 Dear Eric, Comments inline... Sent from my iPad On 07-Feb-2013, at 1:50 AM, "Eric Osborne (eosborne)" w= rote: > You aim to optimize core networks through traffic engineering such that so= me links can be shut down when not in use, or switched to lower power. Actually the answer is a No. We do not advocate this approach. The main idea= in bgp power path draft has a survey section on previous literature that we= quote for reference and state that such approaches cause expensive equipmen= t to be kept unused. You have quoted the survey section of the paper in the a= bove sentence. >=20 > Have you done studies in core networks with real equipment that show the a= ctual amount of money you could save with this approach? Let's walk through= a quick hypothetical network, you tell me where I got it wrong. >=20 > draft-mjsraman-panet-bgp-power-path says > " Power consumption can be > reduced by trading off performance related measures like latency. For > example, power savings while switching from 1 Gbps to 100 Mbps is > approximately 4 W and from 100 Mbps to 10 Mbps around 0.1 Watts." Again this is a survey section of the paper surveying the existing approache= s. >=20 > but provides no documentation to back these costs up nor itemization of wh= ere the power is consumed (amortized across the router? linecard optics? D= WDM gear?) Our main intent is to allow traffic to follow low power paths through ASs (e= ither through pce like entities or through modifying the bgp path selection a= lgorithm) which consume the least power and possess the required bandwidth. B= y graphing the topology of a set ASs in the immediate neighbourhood using as= -path-info strands typically for a provider manning multiple ASs within the p= roviders own control this mechanism will let large chunks of traffic belongi= ng to a macro FEC traverse such low power ASs through an inter-as te MPLS ls= p computed by a pce like entity and setup by RSVP-te. The use of the metric, the way the pwr metric is arrived at , the computatio= n of the topology of ASs, consequent CSPF and then mapping the traffic to th= e constructed LSP is the main focus if this paper. For dampening fluctuation= s in the metric which are frequent heuristics algorithms are suggested. By no means are we advocating shutting off links. This scheme facilitates ev= en the follow the moon strategy naturally. >=20 > Let's assume that this is true and that it is linear, so that you burn 4W p= er Gb. (side note: I suspect this is inaccurate and that scaling is subline= ar, but let's go with it because if it's sub-linear you have even less of a u= se case. I also think the real world is far more complex, as you have all t= he optical transport gear to worry about. But let's go with it for now.) >=20 > Running a 100Gb link thus draws 400W. >=20 > Let's say you have a backbone with (300) 100Gb links. Total power consump= tion is thus (300*400) =3D=3D 120 kW >=20 > Running all these links for 24 hours thus draws 120*24 =3D=3D 2,880 kWh =3D= =3D 2.8mWh > Power costs are maybe $0.10/kWh in the US. Double that to cover the cost o= f cooling, so $0.20/kWh. > Thus, running the entire backbone costs $0.2 * 2,880 =3D $576/day. $210,0= 00/year. > Let's say your approach can save one third of the power cost, which means a= bout $70,000. >=20 > An operator with 300 100Gb links in a network has hundreds of millions of d= ollars worth of gear and millions or tens of millions in payroll alone. If y= ou cut $70k from their opex they probably wouldn't even notice. That's one o= r two salaries, or 0.002% of what Time Warner spent on advertising in 2006 (= see: http://gaia.adage.com/images/random/FactPack06.pdf). It is a drop in t= he bucket, if that. And your proposal comes with significant work attached t= o it, and significant risk. If your 40 years of experience in the network i= ndustry don't help you understand the risks you're asking an operator to tak= e then you're missing a crucial part of any potential real world solution. I= do not think your work should be presented at the IETF unless it makes a mu= ch stronger argument that its benefits outweigh its costs. Again we are not asking the operator to shut off the equipment. He needs to k= eep it running as long as he has traffic to carry except that the pce makes a= computation every time a large FEC of traffic needs to be carried through h= is ASs through a path that consumes the least power with the links therein h= aving the required bandwidth. The ratio of consumed power to the available b= andwidth is the metric that is used. Consumed power relates to a weighted av= erage of the power consumed within the AS including the edge and core device= s while the available bw relates to the links ingressing into the AS at the A= SBRs that are the inter connectors between the ASes. So in summary, we do not advocate shutting off links at all. In fact we disa= gree with that approach. The scheme we advocate tries to optimise the power c= onsumption using the metric based approach with some heuristics. Hope this helps. Thanks and regards, Balaji venkat >=20 > These sorts of power optimizations all seem to be "here's how you reshape t= he problem so that you can throw a linear problem solver at it". For exampl= e, [ http://www.cs.berkeley.edu/~suchara/publications/GreenNetsBundles.pdf ]= . I've never seen anything which shows how much more work it will be for a n= etwork operator or which quantifies the actual savings. >=20 > If you can demonstrate significant savings in real networks at little or n= o cost to operators, you have an idea worth pursuing. If your idea will cau= se more operational angst (e.g. not knowing whether your unused capacity wil= l be there when you need it because you shut a third of it off all the time,= increased risk of equipment failure from constant power-cycling, operationa= l tools and training and expertise required to manage, deploy and troublesho= ot variable-power links and the centralized NMS required to run them, etc et= c etc) then it will find little traction. Green-TE and power-aware BGP have= been floating around for a while and have seen no real uptake in the WGs as= far as I can see. Is that not to be taken as an indication that there may b= e no real-world interest in them? If not, what would it take to convince yo= u? >=20 >=20 >=20 > eric >=20 >=20 >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of= >> Balaji venkat Venkataswami >> Sent: Wednesday, February 06, 2013 1:53 PM >> To: curtis@occnc.com >> Cc: Shankar Raman M J; rtgwg@ietf.org >> Subject: Re: Power aware networks : Comments requested from routing >> community >>=20 >> Dear Curtis, >>=20 >> As already stated to you in a private email, "We" are a group of people w= ith 40 >> years of collective industry experience in the networking industry. We do= nt >> need to be patronized by anybody since we have independent minds that hav= e >> the capability to digest information not based on somebody else's >> interpretation of how future networks need to be built and how power >> reduction needs to play a part in it. >>=20 >> As you might recall one such research paper on GreenTE by Beichuan Zhang >> rang a lot of bells in the IETF by collecting the ANRP prize. So please d= ont >> misstate facts as you might know them and shove your ideas of how network= s >> are built down our throats. >>=20 >> We think the IETF is a free and fair body that accepts opinions and ideas= from >> all sides. We want to keep this a free and fair organization. So incumben= t >> people like you ought to encourage us and have a fair argument when we >> present such work to you. Dont follow the policy of exclusion to the nth d= egree. >>=20 >> It is but fair to say that you seem to be in a minority on this matter. N= obody >> else responded with unkind misstatements of facts and mis-understanding o= f >> our technical antecedents. >>=20 >> Suffice to say that if we get an opportunity to present this (since IETF i= s OUR >> organization too) you need not sit through it. If you want to give us a f= air >> hearing please follow a policy of kind inclusion and not create a ruckus a= bout us >> research folks trying to make an earnest attempt at some practical resear= ch >> that could well save the planet. >>=20 >> Yours sincerely, >> Thanks and regards, >> balaji venkat and shankar raman >>=20 >> On Thu, Feb 7, 2013 at 12:11 AM, Curtis Villamizar wro= te: >>=20 >>=20 >>=20 >> Balaji, >>=20 >> "We" in the context of your first paragraph seems to be a >> misrepresentation. The authors of all of these drafts seem to be from= >> the same university in India. =46rom prior attempts on your part to g= et >> a draft of this sort into IDR and a brief reading of a few of the >> drafts that you have just submitted, you don't seem to have a good >> understanding of how networks are built and how network equipment >> is >> built from which to begin to attack the problem of reducing the power >> consumption of these networks. >>=20 >> If you want to try to advance a research paper with your theories on >> power reduction, please choose an appropriate venue such as a >> refereed >> technical journal. >>=20 >> Curtis >>=20 >>=20 >> In message >> > com >> > mail.gmail.com> > >>=20 >> Balaji venkat Venkataswami writes: >>=20 >> > Dear all, >> > >> > We are a group of research and industry individuals tied together >> with a >> > common goal towards reducing the energy consumption in the core >> and edge >> > networks. >> > >> > We present a metric-based hierarchical approach to reduce power >> consumption >> > in core and edge networks. The proposal considers both unicast and >> the >>=20 >> > multicast cases. For unicast, the metric considered is *consumed- >> power to >> > available-bandwidth* and for multicast the metric is *consumed- >> power to >> > available-replication-capacity.* >>=20 >> > >> > With unicast, the metric is used to determine a low-power path >> between >> > sources and destinations. With multicast, the metric serves the twin= >> > purpose of finding low-power multicast paths as well as multicast >> > replication points. We evolve multiple techniques at various >> hierarchical >> > levels. One at the Inter-AS level, Inter-Area level within the AS an= d >> > intra-Area within an AS. Additionally, the proposed method can also >> be used >> > to determine disjoint or redundant paths for load balancing or fault= >> > tolerance. Additionally since TCAMs are one of the biggest power >> guzzlers >> > in all the components on a router/switch, we have presented a >> solution for >> > intra-AS purposes to use the TCAM according to the traffic matrix >> passing >> > through the system and shut down those TCAM banks that are >> unused. With >> > this in mind, we have also advocated taking into account a TCAM- >> POWER-Ratio >> > in order to compute the paths from source to destination based on >> this >> > metric. Once low-power paths, in either the unicast or the multicast= >> cases, >> > are identified then currently available traffic engineering techniqu= es >> > could be used to route the data packets. In the case of inter-AS BGP= >> path >> > selection is also modified to arrive at paths which are low-power >> paths. >> > >> > Our main objective is as follows... >> > >> > We now outline four important aspects that any approach for power >> reduction >> > should be capable of addressing. >> > >>=20 >> > *Should cater for both unicast and multicast scenarios* >>=20 >> > >> > Multicast provides an important scenario for the Internet. Today, >> most >> > proposals consider mainly low-power path routing with unicast >> traffic. >> > Multicast traffic has received a lot of attention in wireless networ= ks, >> but >> > not in the wired domain. Any new proposal should be able to address >> both >> > the unicast and the multicast traffic scenarios. Having different >> methods >> > for these two scenarios might lead to unnecessary processing burden >> in the >> > routers, which might hinder its scalability. >> > >>=20 >> > *Should not rely on just switching off unused links* >>=20 >> > >> > Most approaches to optimize energy pursue the following approach: >> measure, >> > monitor and respond to the system energy usage by switching off >> unused or >> > under-utilized links. Such an approach could be effective for reduci= ng >> > power locally. The effect on the network is not clearly understood. >> > Further, the power usage involved in turning on and >> rebooting/reconfiguring >> > the device is often not explicitly considered. We note that Service >> Level >> > Agreement (SLA) requirements may not even permit the links to be >> switched >> > off. Also services provided by ISPs like Virtual Private Networks >> (VPNs) >> > can be affected by such re-routing decisions. >> > >>=20 >> > *Should follow an hierarchical and distributed approach* >>=20 >> > >> > For scalability, it is important that the algorithms proposed for in= ter- >> AS >> > should also be applicable to intra-AS situations. Networks do not wo= rk >> in >> > isolation, so any proposal should be both distributed and hierarchic= al. >> The >> > algorithms should be applicable at every level of the hierarchy. >> > >>=20 >> > *Should provide incentives for ISP for adoption* >>=20 >> > >> > The engineering proposals should be aligned with commercial >> incentives for >> > rapid and widespread adoption. Today, the device manufacturers and >> the ISPs >> > operate independently of each other, and there is no incentive for >> > manufacturers to work towards low-power and high bandwidth >> devices. An >>=20 >> > ISP=3D92s revenue model is based on the consumed bandwidth, which >> in turn lea=3D >> > d >>=20 >> > naturally to more power consumption. If the proposed method >> chooses routers >> > that consume low-power and increase the data flow through them, >> then this >> > indirectly provides encouragement for ISPs to purchase low-power >> and high >> > bandwidth devices. >> > >> > >> > >> > We now present our metric-based proposals in the below mentioned >> drafts >> > which addresses the aforementioned design aspects. >> > >> > We would like the routing community to provide feedback on these >> drafts. We >>=20 >> > also intend to present this work in an abridged format in the >> upcoming IETF=3D >>=20 >> > . >> > >> > The drafts are as follows.... >> > >> > >> > >> > >>=20 >> > - mjsraman-panet-bgp-power-path> mjsrama=3D >> > n-panet-bgp-power-path> >> > (timeline)> panet-bg=3D >> > p-power-path-timing.html> >> > Inter-AS-Proposal >> > - mjsraman-panet-ecmp-redirect-power-repl- >> cap> > /draft-mjsraman-panet-ecmp-redirect-power-repl-cap> >> > (timeline)> panet-ec=3D >> > mp-redirect-power-repl-cap-timing.html> >> > Multicast >> > - mjsraman-panet-inter-as-power- >> source> > mjsraman-panet-inter-as-power-source> >> > (timeline)> panet-in=3D >> > ter-as-power-source-timing.html> >> > Inter-AS >> > Proposal >> > - mjsraman-panet-inter-as-psp> mjsraman-=3D >> > panet-inter-as-psp> >> > (timeline)> panet-in=3D >> > ter-as-psp-timing.html> >> > Inter-AS >> > Proposal >> > - mjsraman-panet-inter-as-psp- >> protect> > jsraman-panet-inter-as-psp-protect> >> > (timeline)> panet-in=3D >> > ter-as-psp-protect-timing.html> >> > Inter-AS >> > Proposal >> > - mjsraman-panet-pce-power-mcast- >> replic> > -mjsraman-panet-pce-power-mcast-replic> >> > (timeline)> panet-pc=3D >> > e-power-mcast-replic-timing.html> >> > Multicast >> > - mjsraman-panet-pim-power> mjsraman-pan=3D >> > et-pim-power> >> > (timeline)> panet-pi=3D >> > m-power-timing.html> >> > Multicast >> > - mjsraman-panet-tcam-power- >> efficiency> > mjsraman-panet-tcam-power-efficiency> >> > (timeline)> panet-tc=3D >> > am-power-efficiency-timing.html> >> > TCAM >> > related >> > - mjsraman-panet-tcam-power- >> ratio> > man-panet-tcam-power-ratio> >> > (timeline> panet-tca=3D >> > m-power-ratio-timing.html>) >> > TCAM related >> > - mjsraman-pce-power-replic> mjsraman-pc=3D >> > e-power-replic> >> > (timeline)> pce-powe=3D >> > r-replic-timing.html> >> > Multicast >> > - mjsraman-panet-intra-as-psp-te- >> leak> > jsraman-panet-intra-as-psp-te-leak> >> > (timeline)> panet-in=3D >> > tra-as-psp-te-leak-timing.html> >> > Inter-Area >> > within an AS >> > - mjsraman-panet-ospf-power-topo> mjsram=3D >> > an-panet-ospf-power-topo> >> > (timeline)> panet-os=3D >> > pf-power-topo-timing.html> >>=20 >> > Intra-Area >> > within an AS >> > >> > We understand it is a lot of matter to go through. We would much >> appreciate >> > if some of you could review the inter-AS proposals while others take= >> up >> > multicast and Intra-AS unicast and multicast. >> > >> > Thanks again for your time on this matter. >> > >> > thanks and regards, >> > balaji venkat >>=20 >>=20 >=20 From balajivenkat299@gmail.com Wed Feb 6 13:20:42 2013 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 6630C21F85A0 for ; Wed, 6 Feb 2013 13:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.287 X-Spam-Level: ** X-Spam-Status: No, score=2.287 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-d-xffsY4ag for ; Wed, 6 Feb 2013 13:20:41 -0800 (PST) Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 07A1621F8599 for ; Wed, 6 Feb 2013 13:20:40 -0800 (PST) Received: by mail-ia0-f181.google.com with SMTP id k25so2137575iah.40 for ; Wed, 06 Feb 2013 13:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=k65Wtrhn2HKHTsFetcbqhzFiWjnuW0a6WO2RfWbg8Jc=; b=Em9i44vdlsaC4iRgLna2snScbs/2hACNRk36FFcQpPJzlzsSMEpVe7STboo39riykW 10XG1NzJAUB6vuLet5h9dUh2XNiFdJSRV3TulMHY4IO/+czICN7WW5+blsf0+/NDDYzL VPak85f9HK6DTroxYxrSNaN5wuqyy0jM45HNncmIIROeR+5rQ7ScR7oSesq4YYme70Vg Pn+TN91VKMKS5iImoRGb0mEYJ10jD3BF4qHdJzpCSWotxYRKBvXG1w24y67URcOAznSd xaO3YRye91+J1lBK2JIIQYvwgy8jJuPb31GfZUEjhrGkgELVldE/nr4C+MbRjYdwb+2f cHkQ== X-Received: by 10.50.5.146 with SMTP id s18mr9123030igs.77.1360185639741; Wed, 06 Feb 2013 13:20:39 -0800 (PST) Received: from [192.168.15.106] ([122.174.5.54]) by mx.google.com with ESMTPS id t6sm40400868paz.11.2013.02.06.13.20.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Feb 2013 13:20:39 -0800 (PST) References: <201302062005.r16K5CQS084848@gateway1.orleans.occnc.com> Mime-Version: 1.0 (1.0) In-Reply-To: <201302062005.r16K5CQS084848@gateway1.orleans.occnc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A523) From: Balaji Venkat Subject: Re: Power aware networks : Comments requested from routing community Date: Thu, 7 Feb 2013 02:49:57 +0530 To: "curtis@occnc.com" Cc: Shankar Raman M J , "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: Wed, 06 Feb 2013 21:20:42 -0000 Dear Curtis, Thank you for your detailed reply. =20 Comments inline... Sent from my iPad On 07-Feb-2013, at 1:35 AM, Curtis Villamizar wrote: >=20 > In message > Balaji venkat Venkataswami writes: >=20 >> As you might recall one such research paper on GreenTE by Beichuan >> Zhang rang a lot of bells in the IETF by collecting the ANRP prize. So >> please dont misstate facts as you might know them and shove your ideas >> of how networks are built down our throats. >=20 > That was a research paper published in IEEE International Conference > on Network Protocols (ICNP). >=20 > Power savings potential (a computation, not a measurement) were as > high as 20-40%. That is good but ... >=20 > Line cards considered were old OC3, OC48, and one port OC192 cards. > The paper ignores the reality that shutting off one port on a > multiport card makes little difference, certainly far less than a > reduction of 1/N. The power consumption of transport was not > included. Impact on fault restoration was not considered. Lots of > other flaws, but still good work and a potential 20-40% is nice, even > if factoring in reality might get only half that or less. >=20 > The point though is that a 1 port OC192 at 174 watts (10 Gb/s) is no > match for a 500 Gb/s card at roughly 650 watts. That is more than > 40%. It is more than a decimal order of magnitude greater. It is not > comparing apples to oranges, one is an IP/MPLS router with full > routing tables and short haul interfaces, the other does OTN switching > drives either short haul or long haul transport interfaces, and could > do IP/MPLS, but with only IGP routes and MPLS LSPs at that power > figure. So maybe the way the network is built needs to change. >=20 > Anyway, if *I* were to continue this discussion, then *I* should get > off the IETF lists and go write an academic paper. [Or better yet, > work for a service provider or equipment vendor and work toward > building better equipment and networks.] >=20 > The point is that efficiency has gone up by orders of magnitude as we > went from OC3 to OC12 to OC48 to OC192 (circa 1995-2000) and then > multiport OC192 and OC768 and 10GbE (circa 2005-2010) to 100GbE and > ODU4 (somewhat recent) to multiport 100GbE and ODU4 (even more > recent). Power per bit drops about one to two decimal order of > magnitude per decade and for any given a specific snapshot in the > technology timeline, there are means to reduce power that get far more > than the 20-40% that GreenTE potentially offers. >=20 > Of course a new generation of equipment means CapEx and GreenTE is > perceived as just routing and therefore free, so therefore the > interest. >=20 > Another point is that no one ever tried this on a real network. With > RSVP-TE no protocol changes would be necessary, just offline > computation, a configured preferred explicit-path, and some interface > shutdowns. I don't know that anyone has even measured the reduction > in power of an idled or administratively shut down interface or line > card. There was nothing in the paper on this. We don't advocate shutting the links down. Instead we intend to maximise Usage of all links with least power utilisation. It's an optimization proble= m=20 With heuristics in graph theory involved. >=20 >>> If you want to try to advance a research paper with your theories on >>> power reduction, please choose an appropriate venue such as a refereed >>> technical journal. >=20 > I repeat my main point. [And hope to be among the reviewers] >=20 > Also IMHO GreenTE as described by Zhang is more likely to be feasible > with MPLS and RSVP-TE than with OSPF or BGP or PIM, etc. But then, > the feasibility and potential benefits of GreenTE using IGP, BGP, and > PIM is what your academic paper can try to defend. Yes sir. In our proposals we intend to deploy most of our solutions with MPL= S te=20 Involved with pce entities and RSVP te as the signalling protocol of choice.= The ospf And Isis protocols need to be used only for carrying the power metric used i= n arriving at a te LSP that is a low power path. This metric is carried in a opaque manner and k= ept in the TED. Thanks and regards, Balaji venkat >=20 > Thank you, >=20 > Curtis From eosborne@cisco.com Wed Feb 6 13:34:13 2013 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 7159E21F854E for ; Wed, 6 Feb 2013 13:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.52 X-Spam-Level: X-Spam-Status: No, score=-10.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCv9VATfW-vO for ; Wed, 6 Feb 2013 13:34:12 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B5E4D21F854A for ; Wed, 6 Feb 2013 13:34:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16095; q=dns/txt; s=iport; t=1360186451; x=1361396051; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=E05/eO7gUO8gHR6YdkSmFfFtWQu7cOJJwzZmWSzItVM=; b=aa6rxSQ0G4OIKYX8gRuc+gD8Coi+g6joBmR3maCK6ttYOA6pCTF0YYc3 9NLT5CRnTdjj8LMvaiuwGPFWaJT9m7/cUarS8KMON6RMJFcOrY72b7W9i CKFcCQ13sJc3Dq9sTudA9UYDyWYS/8ZG8eRHP1PKV0k6qS4zUTrd1c93D Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFADzLElGtJXHA/2dsb2JhbABFFsA6FnOCGAcBAQECAQE6LQQIBgUHBAIBCBEEAQEBCgsJCQcyFAkIAgQOBQgMBwGFLQeCLwMJBgyybA2JVo0REAGBAoJUYQOSLjqEVoolhRCCfoFvNQ X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; d="scan'208";a="171195403" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 06 Feb 2013 21:34:10 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r16LYArF013048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Feb 2013 21:34:10 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 6 Feb 2013 15:34:10 -0600 From: "Eric Osborne (eosborne)" To: Balaji Venkat Subject: RE: Power aware networks : Comments requested from routing community Thread-Topic: Power aware networks : Comments requested from routing community Thread-Index: AQHOBJmILt1Dff9vjkCrdfxQNrUVWphtkbkA//+h48CAAINagP//ojWw Date: Wed, 6 Feb 2013 21:34:10 +0000 Message-ID: <20ECF67871905846A80F77F8F4A27572100BEF6C@xmb-rcd-x09.cisco.com> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <20ECF67871905846A80F77F8F4A27572100BEE0B@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.23.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Shankar Raman M J , "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: Wed, 06 Feb 2013 21:34:13 -0000 ... > Again we are not asking the operator to shut off the equipment. He needs = to > keep it running as long as he has traffic to carry except that the pce ma= kes a > computation every time a large FEC of traffic needs to be carried through= his > ASs through a path that consumes the least power with the links therein h= aving > the required bandwidth. The ratio of consumed power to the available > bandwidth is the metric that is used. Consumed power relates to a weighte= d > average of the power consumed within the AS including the edge and core > devices while the available bw relates to the links ingressing into the A= S at the > ASBRs that are the inter connectors between the ASes. >=20 >=20 > So in summary, we do not advocate shutting off links at all. In fact we d= isagree > with that approach. The scheme we advocate tries to optimise the power > consumption using the metric based approach with some heuristics. You totally skipped over the example I put up. No matter how you save powe= r, you haven't shown you can save enough to make any efforts worth it. Do = you have any case studies, even hypothetical one with real-world architectu= res and load, that demonstrate that your approach saves enough money to mak= e it worth adopting? Can you even get close? eric >=20 > Hope this helps. >=20 > Thanks and regards, > Balaji venkat > > > > These sorts of power optimizations all seem to be "here's how you resha= pe > the problem so that you can throw a linear problem solver at it". For ex= ample, > [ http://www.cs.berkeley.edu/~suchara/publications/GreenNetsBundles.pdf ]= . > I've never seen anything which shows how much more work it will be for a > network operator or which quantifies the actual savings. > > > > If you can demonstrate significant savings in real networks at little o= r no cost > to operators, you have an idea worth pursuing. If your idea will cause m= ore > operational angst (e.g. not knowing whether your unused capacity will be = there > when you need it because you shut a third of it off all the time, increas= ed risk of > equipment failure from constant power-cycling, operational tools and trai= ning > and expertise required to manage, deploy and troubleshoot variable-power > links and the centralized NMS required to run them, etc etc etc) then it = will find > little traction. Green-TE and power-aware BGP have been floating around = for a > while and have seen no real uptake in the WGs as far as I can see. Is th= at not to > be taken as an indication that there may be no real-world interest in the= m? If > not, what would it take to convince you? > > > > > > > > eric > > > > > >> -----Original Message----- > >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On > >> Behalf Of Balaji venkat Venkataswami > >> Sent: Wednesday, February 06, 2013 1:53 PM > >> To: curtis@occnc.com > >> Cc: Shankar Raman M J; rtgwg@ietf.org > >> Subject: Re: Power aware networks : Comments requested from routing > >> community > >> > >> Dear Curtis, > >> > >> As already stated to you in a private email, "We" are a group of > >> people with 40 years of collective industry experience in the > >> networking industry. We dont need to be patronized by anybody since > >> we have independent minds that have the capability to digest > >> information not based on somebody else's interpretation of how future > >> networks need to be built and how power reduction needs to play a part= in > it. > >> > >> As you might recall one such research paper on GreenTE by Beichuan > >> Zhang rang a lot of bells in the IETF by collecting the ANRP prize. > >> So please dont misstate facts as you might know them and shove your > >> ideas of how networks are built down our throats. > >> > >> We think the IETF is a free and fair body that accepts opinions and > >> ideas from all sides. We want to keep this a free and fair > >> organization. So incumbent people like you ought to encourage us and > >> have a fair argument when we present such work to you. Dont follow the > policy of exclusion to the nth degree. > >> > >> It is but fair to say that you seem to be in a minority on this > >> matter. Nobody else responded with unkind misstatements of facts and > >> mis-understanding of our technical antecedents. > >> > >> Suffice to say that if we get an opportunity to present this (since > >> IETF is OUR organization too) you need not sit through it. If you > >> want to give us a fair hearing please follow a policy of kind > >> inclusion and not create a ruckus about us research folks trying to > >> make an earnest attempt at some practical research that could well sav= e > the planet. > >> > >> Yours sincerely, > >> Thanks and regards, > >> balaji venkat and shankar raman > >> > >> On Thu, Feb 7, 2013 at 12:11 AM, Curtis Villamizar > wrote: > >> > >> > >> > >> Balaji, > >> > >> "We" in the context of your first paragraph seems to be a > >> misrepresentation. The authors of all of these drafts seem to be f= rom > >> the same university in India. From prior attempts on your part to = get > >> a draft of this sort into IDR and a brief reading of a few of the > >> drafts that you have just submitted, you don't seem to have a good > >> understanding of how networks are built and how network equipment > >> is > >> built from which to begin to attack the problem of reducing the pow= er > >> consumption of these networks. > >> > >> If you want to try to advance a research paper with your theories o= n > >> power reduction, please choose an appropriate venue such as a > >> refereed > >> technical journal. > >> > >> Curtis > >> > >> > >> In message > >> > >> com > >> > >> mail.gmail.com> > > >> > >> Balaji venkat Venkataswami writes: > >> > >> > Dear all, > >> > > >> > We are a group of research and industry individuals tied > >> together with a > >> > common goal towards reducing the energy consumption in the core > >> and edge > >> > networks. > >> > > >> > We present a metric-based hierarchical approach to reduce power > >> consumption > >> > in core and edge networks. The proposal considers both unicast > >> and the > >> > >> > multicast cases. For unicast, the metric considered is > >> *consumed- power to > >> > available-bandwidth* and for multicast the metric is *consumed- > >> power to > >> > available-replication-capacity.* > >> > >> > > >> > With unicast, the metric is used to determine a low-power path > >> between > >> > sources and destinations. With multicast, the metric serves the t= win > >> > purpose of finding low-power multicast paths as well as multicast > >> > replication points. We evolve multiple techniques at various > >> hierarchical > >> > levels. One at the Inter-AS level, Inter-Area level within the AS= and > >> > intra-Area within an AS. Additionally, the proposed method can > >> also be used > >> > to determine disjoint or redundant paths for load balancing or fa= ult > >> > tolerance. Additionally since TCAMs are one of the biggest power > >> guzzlers > >> > in all the components on a router/switch, we have presented a > >> solution for > >> > intra-AS purposes to use the TCAM according to the traffic > >> matrix passing > >> > through the system and shut down those TCAM banks that are > >> unused. With > >> > this in mind, we have also advocated taking into account a TCAM- > >> POWER-Ratio > >> > in order to compute the paths from source to destination based > >> on this > >> > metric. Once low-power paths, in either the unicast or the > >> multicast cases, > >> > are identified then currently available traffic engineering techn= iques > >> > could be used to route the data packets. In the case of inter-AS > >> BGP path > >> > selection is also modified to arrive at paths which are > >> low-power paths. > >> > > >> > Our main objective is as follows... > >> > > >> > We now outline four important aspects that any approach for > >> power reduction > >> > should be capable of addressing. > >> > > >> > >> > *Should cater for both unicast and multicast scenarios* > >> > >> > > >> > Multicast provides an important scenario for the Internet. > >> Today, most > >> > proposals consider mainly low-power path routing with unicast > >> traffic. > >> > Multicast traffic has received a lot of attention in wireless > >> networks, but > >> > not in the wired domain. Any new proposal should be able to > >> address both > >> > the unicast and the multicast traffic scenarios. Having > >> different methods > >> > for these two scenarios might lead to unnecessary processing > >> burden in the > >> > routers, which might hinder its scalability. > >> > > >> > >> > *Should not rely on just switching off unused links* > >> > >> > > >> > Most approaches to optimize energy pursue the following approach: > >> measure, > >> > monitor and respond to the system energy usage by switching off > >> unused or > >> > under-utilized links. Such an approach could be effective for red= ucing > >> > power locally. The effect on the network is not clearly understoo= d. > >> > Further, the power usage involved in turning on and > >> rebooting/reconfiguring > >> > the device is often not explicitly considered. We note that > >> Service Level > >> > Agreement (SLA) requirements may not even permit the links to be > >> switched > >> > off. Also services provided by ISPs like Virtual Private > >> Networks > >> (VPNs) > >> > can be affected by such re-routing decisions. > >> > > >> > >> > *Should follow an hierarchical and distributed approach* > >> > >> > > >> > For scalability, it is important that the algorithms proposed > >> for inter- AS > >> > should also be applicable to intra-AS situations. Networks do > >> not work in > >> > isolation, so any proposal should be both distributed and hierarc= hical. > >> The > >> > algorithms should be applicable at every level of the hierarchy. > >> > > >> > >> > *Should provide incentives for ISP for adoption* > >> > >> > > >> > The engineering proposals should be aligned with commercial > >> incentives for > >> > rapid and widespread adoption. Today, the device manufacturers > >> and the ISPs > >> > operate independently of each other, and there is no incentive fo= r > >> > manufacturers to work towards low-power and high bandwidth > >> devices. An > >> > >> > ISP=3D92s revenue model is based on the consumed bandwidth, which > >> in turn lea=3D > >> > d > >> > >> > naturally to more power consumption. If the proposed method > >> chooses routers > >> > that consume low-power and increase the data flow through them, > >> then this > >> > indirectly provides encouragement for ISPs to purchase low-power > >> and high > >> > bandwidth devices. > >> > > >> > > >> > > >> > We now present our metric-based proposals in the below mentioned > >> drafts > >> > which addresses the aforementioned design aspects. > >> > > >> > We would like the routing community to provide feedback on these > >> drafts. We > >> > >> > also intend to present this work in an abridged format in the > >> upcoming IETF=3D > >> > >> > . > >> > > >> > The drafts are as follows.... > >> > > >> > > >> > > >> > > >> > >> > - mjsraman-panet-bgp-power-path >> mjsrama=3D > >> > n-panet-bgp-power-path> > >> > (timeline) >> panet-bg=3D > >> > p-power-path-timing.html> > >> > Inter-AS-Proposal > >> > - mjsraman-panet-ecmp-redirect-power-repl- > >> cap >> > /draft-mjsraman-panet-ecmp-redirect-power-repl-cap> > >> > (timeline) >> panet-ec=3D > >> > mp-redirect-power-repl-cap-timing.html> > >> > Multicast > >> > - mjsraman-panet-inter-as-power- > >> source >> > mjsraman-panet-inter-as-power-source> > >> > (timeline) >> panet-in=3D > >> > ter-as-power-source-timing.html> > >> > Inter-AS > >> > Proposal > >> > - mjsraman-panet-inter-as-psp >> mjsraman-=3D > >> > panet-inter-as-psp> > >> > (timeline) >> panet-in=3D > >> > ter-as-psp-timing.html> > >> > Inter-AS > >> > Proposal > >> > - mjsraman-panet-inter-as-psp- > >> protect >> > jsraman-panet-inter-as-psp-protect> > >> > (timeline) >> panet-in=3D > >> > ter-as-psp-protect-timing.html> > >> > Inter-AS > >> > Proposal > >> > - mjsraman-panet-pce-power-mcast- > >> replic >> > -mjsraman-panet-pce-power-mcast-replic> > >> > (timeline) >> panet-pc=3D > >> > e-power-mcast-replic-timing.html> > >> > Multicast > >> > - mjsraman-panet-pim-power >> mjsraman-pan=3D > >> > et-pim-power> > >> > (timeline) >> panet-pi=3D > >> > m-power-timing.html> > >> > Multicast > >> > - mjsraman-panet-tcam-power- > >> efficiency >> > mjsraman-panet-tcam-power-efficiency> > >> > (timeline) >> panet-tc=3D > >> > am-power-efficiency-timing.html> > >> > TCAM > >> > related > >> > - mjsraman-panet-tcam-power- > >> ratio >> > man-panet-tcam-power-ratio> > >> > (timeline >> panet-tca=3D > >> > m-power-ratio-timing.html>) > >> > TCAM related > >> > - mjsraman-pce-power-replic >> mjsraman-pc=3D > >> > e-power-replic> > >> > (timeline) >> pce-powe=3D > >> > r-replic-timing.html> > >> > Multicast > >> > - mjsraman-panet-intra-as-psp-te- > >> leak >> > jsraman-panet-intra-as-psp-te-leak> > >> > (timeline) >> panet-in=3D > >> > tra-as-psp-te-leak-timing.html> > >> > Inter-Area > >> > within an AS > >> > - mjsraman-panet-ospf-power-topo >> mjsram=3D > >> > an-panet-ospf-power-topo> > >> > (timeline) >> panet-os=3D > >> > pf-power-topo-timing.html> > >> > >> > Intra-Area > >> > within an AS > >> > > >> > We understand it is a lot of matter to go through. We would much > >> appreciate > >> > if some of you could review the inter-AS proposals while others > >> take up > >> > multicast and Intra-AS unicast and multicast. > >> > > >> > Thanks again for your time on this matter. > >> > > >> > thanks and regards, > >> > balaji venkat > >> > >> > > From balajivenkat299@gmail.com Wed Feb 6 13:39:20 2013 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 BEFC621F854F for ; Wed, 6 Feb 2013 13:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.209 X-Spam-Level: ** X-Spam-Status: No, score=2.209 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bRWgRlLQlb8 for ; Wed, 6 Feb 2013 13:39:19 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6C79121F847B for ; Wed, 6 Feb 2013 13:39:19 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c10so2622798ieb.3 for ; Wed, 06 Feb 2013 13:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=+cR2e8i0N+ErJYKM4o/Xu9zePxhHr6+XsrHmWVnTlhA=; b=Ud73Va+SMpR65qK8a1kgQdLRvkPB5T9FTWAOf8oaz4KkDwvlkLlDqtJ3ciyxyPLgwN 2WkyLf53jRsk9okSdgzTySJMKVpOvAsZJ4MSbYX71rfOcDMF0o5bYm6K/irUmew9/EOs Gmp0uJhBhssacRhB7matmU0dX48QaLUdkde2hgvBteQbj0oMej5/Gp7sm5TC6nD/O/ZX 4tdnvVYQCx5dKn+pNYLQJDBFZTd40yE6KUu89ZPLjdYNl88nh/dTFeuk4N/PL7ILBB0g t8UWeuGZih0LEuZezkJP4KupY24r3qDJrIpmq2iTsA/kdUw/sQkmQ6OGXmkzZR5bHOm9 nXeg== X-Received: by 10.50.181.136 with SMTP id dw8mr9711745igc.39.1360186758800; Wed, 06 Feb 2013 13:39:18 -0800 (PST) Received: from [192.168.15.106] ([122.174.5.54]) by mx.google.com with ESMTPS id u4sm5561256igw.6.2013.02.06.13.39.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Feb 2013 13:39:18 -0800 (PST) References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <20ECF67871905846A80F77F8F4A27572100BEE0B@xmb-rcd-x09.cisco.com> <20ECF67871905846A80F77F8F4A27572100BEF6C@xmb-rcd-x09.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20ECF67871905846A80F77F8F4A27572100BEF6C@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10A523) From: Balaji Venkat Subject: Re: Power aware networks : Comments requested from routing community Date: Thu, 7 Feb 2013 03:08:36 +0530 To: "Eric Osborne (eosborne)" Cc: Shankar Raman M J , "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: Wed, 06 Feb 2013 21:39:20 -0000 Dear Eric, We have some experimental results=20 Will share it with the you and the alias by tomorrow. Thanks for your kind review and your time, Thanks and regards, Balaji venkat Sent from my iPad On 07-Feb-2013, at 3:04 AM, "Eric Osborne (eosborne)" w= rote: > ... >=20 >> Again we are not asking the operator to shut off the equipment. He needs t= o >> keep it running as long as he has traffic to carry except that the pce ma= kes a >> computation every time a large FEC of traffic needs to be carried through= his >> ASs through a path that consumes the least power with the links therein h= aving >> the required bandwidth. The ratio of consumed power to the available >> bandwidth is the metric that is used. Consumed power relates to a weighte= d >> average of the power consumed within the AS including the edge and core >> devices while the available bw relates to the links ingressing into the A= S at the >> ASBRs that are the inter connectors between the ASes. >>=20 >>=20 >> So in summary, we do not advocate shutting off links at all. In fact we d= isagree >> with that approach. The scheme we advocate tries to optimise the power >> consumption using the metric based approach with some heuristics. >=20 > You totally skipped over the example I put up. No matter how you save pow= er, you haven't shown you can save enough to make any efforts worth it. Do y= ou have any case studies, even hypothetical one with real-world architecture= s and load, that demonstrate that your approach saves enough money to make i= t worth adopting? Can you even get close? >=20 >=20 >=20 >=20 > eric >=20 >=20 >>=20 >> Hope this helps. >>=20 >> Thanks and regards, >> Balaji venkat >>>=20 >>> These sorts of power optimizations all seem to be "here's how you reshap= e >> the problem so that you can throw a linear problem solver at it". For ex= ample, >> [ http://www.cs.berkeley.edu/~suchara/publications/GreenNetsBundles.pdf ]= . >> I've never seen anything which shows how much more work it will be for a >> network operator or which quantifies the actual savings. >>>=20 >>> If you can demonstrate significant savings in real networks at little or= no cost >> to operators, you have an idea worth pursuing. If your idea will cause m= ore >> operational angst (e.g. not knowing whether your unused capacity will be t= here >> when you need it because you shut a third of it off all the time, increas= ed risk of >> equipment failure from constant power-cycling, operational tools and trai= ning >> and expertise required to manage, deploy and troubleshoot variable-power >> links and the centralized NMS required to run them, etc etc etc) then it w= ill find >> little traction. Green-TE and power-aware BGP have been floating around f= or a >> while and have seen no real uptake in the WGs as far as I can see. Is th= at not to >> be taken as an indication that there may be no real-world interest in the= m? If >> not, what would it take to convince you? >>>=20 >>>=20 >>>=20 >>> eric >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On >>>> Behalf Of Balaji venkat Venkataswami >>>> Sent: Wednesday, February 06, 2013 1:53 PM >>>> To: curtis@occnc.com >>>> Cc: Shankar Raman M J; rtgwg@ietf.org >>>> Subject: Re: Power aware networks : Comments requested from routing >>>> community >>>>=20 >>>> Dear Curtis, >>>>=20 >>>> As already stated to you in a private email, "We" are a group of >>>> people with 40 years of collective industry experience in the >>>> networking industry. We dont need to be patronized by anybody since >>>> we have independent minds that have the capability to digest >>>> information not based on somebody else's interpretation of how future >>>> networks need to be built and how power reduction needs to play a part i= n >> it. >>>>=20 >>>> As you might recall one such research paper on GreenTE by Beichuan >>>> Zhang rang a lot of bells in the IETF by collecting the ANRP prize. >>>> So please dont misstate facts as you might know them and shove your >>>> ideas of how networks are built down our throats. >>>>=20 >>>> We think the IETF is a free and fair body that accepts opinions and >>>> ideas from all sides. We want to keep this a free and fair >>>> organization. So incumbent people like you ought to encourage us and >>>> have a fair argument when we present such work to you. Dont follow the >> policy of exclusion to the nth degree. >>>>=20 >>>> It is but fair to say that you seem to be in a minority on this >>>> matter. Nobody else responded with unkind misstatements of facts and >>>> mis-understanding of our technical antecedents. >>>>=20 >>>> Suffice to say that if we get an opportunity to present this (since >>>> IETF is OUR organization too) you need not sit through it. If you >>>> want to give us a fair hearing please follow a policy of kind >>>> inclusion and not create a ruckus about us research folks trying to >>>> make an earnest attempt at some practical research that could well save= >> the planet. >>>>=20 >>>> Yours sincerely, >>>> Thanks and regards, >>>> balaji venkat and shankar raman >>>>=20 >>>> On Thu, Feb 7, 2013 at 12:11 AM, Curtis Villamizar >> wrote: >>>>=20 >>>>=20 >>>>=20 >>>> Balaji, >>>>=20 >>>> "We" in the context of your first paragraph seems to be a >>>> misrepresentation. The authors of all of these drafts seem to be fro= m >>>> the same university in India. =46rom prior attempts on your part to g= et >>>> a draft of this sort into IDR and a brief reading of a few of the >>>> drafts that you have just submitted, you don't seem to have a good >>>> understanding of how networks are built and how network equipment >>>> is >>>> built from which to begin to attack the problem of reducing the power= >>>> consumption of these networks. >>>>=20 >>>> If you want to try to advance a research paper with your theories on >>>> power reduction, please choose an appropriate venue such as a >>>> refereed >>>> technical journal. >>>>=20 >>>> Curtis >>>>=20 >>>>=20 >>>> In message >> >>> com >> >>> mail.gmail.com> > >>>>=20 >>>> Balaji venkat Venkataswami writes: >>>>=20 >>>>> Dear all, >>>>>=20 >>>>> We are a group of research and industry individuals tied >>>> together with a >>>>> common goal towards reducing the energy consumption in the core >>>> and edge >>>>> networks. >>>>>=20 >>>>> We present a metric-based hierarchical approach to reduce power >>>> consumption >>>>> in core and edge networks. The proposal considers both unicast >>>> and the >>>>=20 >>>>> multicast cases. For unicast, the metric considered is >>>> *consumed- power to >>>>> available-bandwidth* and for multicast the metric is *consumed- >>>> power to >>>>> available-replication-capacity.* >>>>=20 >>>>>=20 >>>>> With unicast, the metric is used to determine a low-power path >>>> between >>>>> sources and destinations. With multicast, the metric serves the twin >>>>> purpose of finding low-power multicast paths as well as multicast >>>>> replication points. We evolve multiple techniques at various >>>> hierarchical >>>>> levels. One at the Inter-AS level, Inter-Area level within the AS and >>>>> intra-Area within an AS. Additionally, the proposed method can >>>> also be used >>>>> to determine disjoint or redundant paths for load balancing or fault >>>>> tolerance. Additionally since TCAMs are one of the biggest power >>>> guzzlers >>>>> in all the components on a router/switch, we have presented a >>>> solution for >>>>> intra-AS purposes to use the TCAM according to the traffic >>>> matrix passing >>>>> through the system and shut down those TCAM banks that are >>>> unused. With >>>>> this in mind, we have also advocated taking into account a TCAM- >>>> POWER-Ratio >>>>> in order to compute the paths from source to destination based >>>> on this >>>>> metric. Once low-power paths, in either the unicast or the >>>> multicast cases, >>>>> are identified then currently available traffic engineering techniques= >>>>> could be used to route the data packets. In the case of inter-AS >>>> BGP path >>>>> selection is also modified to arrive at paths which are >>>> low-power paths. >>>>>=20 >>>>> Our main objective is as follows... >>>>>=20 >>>>> We now outline four important aspects that any approach for >>>> power reduction >>>>> should be capable of addressing. >>>>=20 >>>>> *Should cater for both unicast and multicast scenarios* >>>>=20 >>>>>=20 >>>>> Multicast provides an important scenario for the Internet. >>>> Today, most >>>>> proposals consider mainly low-power path routing with unicast >>>> traffic. >>>>> Multicast traffic has received a lot of attention in wireless >>>> networks, but >>>>> not in the wired domain. Any new proposal should be able to >>>> address both >>>>> the unicast and the multicast traffic scenarios. Having >>>> different methods >>>>> for these two scenarios might lead to unnecessary processing >>>> burden in the >>>>> routers, which might hinder its scalability. >>>>=20 >>>>> *Should not rely on just switching off unused links* >>>>=20 >>>>>=20 >>>>> Most approaches to optimize energy pursue the following approach: >>>> measure, >>>>> monitor and respond to the system energy usage by switching off >>>> unused or >>>>> under-utilized links. Such an approach could be effective for reducing= >>>>> power locally. The effect on the network is not clearly understood. >>>>> Further, the power usage involved in turning on and >>>> rebooting/reconfiguring >>>>> the device is often not explicitly considered. We note that >>>> Service Level >>>>> Agreement (SLA) requirements may not even permit the links to be >>>> switched >>>>> off. Also services provided by ISPs like Virtual Private >>>> Networks >>>> (VPNs) >>>>> can be affected by such re-routing decisions. >>>>=20 >>>>> *Should follow an hierarchical and distributed approach* >>>>=20 >>>>>=20 >>>>> For scalability, it is important that the algorithms proposed >>>> for inter- AS >>>>> should also be applicable to intra-AS situations. Networks do >>>> not work in >>>>> isolation, so any proposal should be both distributed and hierarchical= . >>>> The >>>>> algorithms should be applicable at every level of the hierarchy. >>>>=20 >>>>> *Should provide incentives for ISP for adoption* >>>>=20 >>>>>=20 >>>>> The engineering proposals should be aligned with commercial >>>> incentives for >>>>> rapid and widespread adoption. Today, the device manufacturers >>>> and the ISPs >>>>> operate independently of each other, and there is no incentive for >>>>> manufacturers to work towards low-power and high bandwidth >>>> devices. An >>>>=20 >>>>> ISP=3D92s revenue model is based on the consumed bandwidth, which >>>> in turn lea=3D >>>>> d >>>>=20 >>>>> naturally to more power consumption. If the proposed method >>>> chooses routers >>>>> that consume low-power and increase the data flow through them, >>>> then this >>>>> indirectly provides encouragement for ISPs to purchase low-power >>>> and high >>>>> bandwidth devices. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> We now present our metric-based proposals in the below mentioned >>>> drafts >>>>> which addresses the aforementioned design aspects. >>>>>=20 >>>>> We would like the routing community to provide feedback on these >>>> drafts. We >>>>=20 >>>>> also intend to present this work in an abridged format in the >>>> upcoming IETF=3D >>>>=20 >>>>> . >>>>>=20 >>>>> The drafts are as follows.... >>>>=20 >>>>> - mjsraman-panet-bgp-power-path>>> mjsrama=3D >>>>> n-panet-bgp-power-path> >>>>> (timeline)>>> panet-bg=3D >>>>> p-power-path-timing.html> >>>>> Inter-AS-Proposal >>>>> - mjsraman-panet-ecmp-redirect-power-repl- >>>> cap>>>> /draft-mjsraman-panet-ecmp-redirect-power-repl-cap> >>>>> (timeline)>>> panet-ec=3D >>>>> mp-redirect-power-repl-cap-timing.html> >>>>> Multicast >>>>> - mjsraman-panet-inter-as-power- >>>> source>>>> mjsraman-panet-inter-as-power-source> >>>>> (timeline)>>> panet-in=3D >>>>> ter-as-power-source-timing.html> >>>>> Inter-AS >>>>> Proposal >>>>> - mjsraman-panet-inter-as-psp>>> mjsraman-=3D >>>>> panet-inter-as-psp> >>>>> (timeline)>>> panet-in=3D >>>>> ter-as-psp-timing.html> >>>>> Inter-AS >>>>> Proposal >>>>> - mjsraman-panet-inter-as-psp- >>>> protect>>>> jsraman-panet-inter-as-psp-protect> >>>>> (timeline)>>> panet-in=3D >>>>> ter-as-psp-protect-timing.html> >>>>> Inter-AS >>>>> Proposal >>>>> - mjsraman-panet-pce-power-mcast- >>>> replic>>>> -mjsraman-panet-pce-power-mcast-replic> >>>>> (timeline)>>> panet-pc=3D >>>>> e-power-mcast-replic-timing.html> >>>>> Multicast >>>>> - mjsraman-panet-pim-power>>> mjsraman-pan=3D >>>>> et-pim-power> >>>>> (timeline)>>> panet-pi=3D >>>>> m-power-timing.html> >>>>> Multicast >>>>> - mjsraman-panet-tcam-power- >>>> efficiency>>>> mjsraman-panet-tcam-power-efficiency> >>>>> (timeline)>>> panet-tc=3D >>>>> am-power-efficiency-timing.html> >>>>> TCAM >>>>> related >>>>> - mjsraman-panet-tcam-power- >>>> ratio>>>> man-panet-tcam-power-ratio> >>>>> (timeline>>> panet-tca=3D >>>>> m-power-ratio-timing.html>) >>>>> TCAM related >>>>> - mjsraman-pce-power-replic>>> mjsraman-pc=3D >>>>> e-power-replic> >>>>> (timeline)>>> pce-powe=3D >>>>> r-replic-timing.html> >>>>> Multicast >>>>> - mjsraman-panet-intra-as-psp-te- >>>> leak>>>> jsraman-panet-intra-as-psp-te-leak> >>>>> (timeline)>>> panet-in=3D >>>>> tra-as-psp-te-leak-timing.html> >>>>> Inter-Area >>>>> within an AS >>>>> - mjsraman-panet-ospf-power-topo>>> mjsram=3D >>>>> an-panet-ospf-power-topo> >>>>> (timeline)>>> panet-os=3D >>>>> pf-power-topo-timing.html> >>>>=20 >>>>> Intra-Area >>>>> within an AS >>>>>=20 >>>>> We understand it is a lot of matter to go through. We would much >>>> appreciate >>>>> if some of you could review the inter-AS proposals while others >>>> take up >>>>> multicast and Intra-AS unicast and multicast. >>>>>=20 >>>>> Thanks again for your time on this matter. >>>>>=20 >>>>> thanks and regards, >>>>> balaji venkat >>>=20 From jeff.tantsura@ericsson.com Wed Feb 6 14:44:27 2013 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 3BF4321E8041 for ; Wed, 6 Feb 2013 14:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4sboWsBfvy1 for ; Wed, 6 Feb 2013 14:44:26 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBE021F8893 for ; Wed, 6 Feb 2013 14:44:26 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-18-5112dcc8ba50 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id CE.05.03705.8CCD2115; Wed, 6 Feb 2013 23:44:25 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Wed, 6 Feb 2013 17:44:24 -0500 From: Jeff Tantsura To: "Andrew G. Malis" Subject: Re: Expiration impending: Thread-Topic: Expiration impending: Thread-Index: AQHOA9r37uX/Rg5Uo0WfwbAREsEb2phtmRkA///WNf0= Date: Wed, 6 Feb 2013 22:44:22 +0000 Message-ID: <3834FC56-4657-4A85-97DF-A24DF4608AE2@ericsson.com> References: <201302051954.r15Js12Y072536@gateway1.orleans.occnc.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3834FC5646574A8597DFA24DF4608AE2ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyuXRPrO7JO0KBBjMWc1u0b9/FaHH4wHR2 i61nWS0uvPnN7MDisWTJTyaPxV/8PN7MOcPm0fpdNIAlissmJTUnsyy1SN8ugSvj6M1WloIz 6hV/Ph9jaWB8qNjFyMEhIWAi8eYMdxcjJ5ApJnHh3nq2LkYuDiGBI4wSlxo3M0I4yxglzhxt YAKpYhMwkPj/7TgLiC0iYCQx4+89VhCbWaBKYtuyO+wgQ4UFvCVOdftClPhIHJn9mBXCtpLo vrcfzGYRUJE4NP8F2BheAXuJpqnPWCF2XWCUuHvsHQvIHE6BQInj31JBahiBjvt+ag0TxCpx iVtP5jNBHC0gsWTPeWYIW1Ti5eN/UOckS8z+3MgMMV9Q4uTMJywTGEVmIWmfhaRsFpIyiLiO xILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvoqRo7Q4tSw33chwEyMwuo5JsDnuYFzwyfIQozQH i5I4b6jrhQAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjA2vHqQGan16OWNK0xyz1xejbFaE ztz+/kDooq2LvCKmbdX5X5snaeAV8NXdc6nX6btcnt6vfn/I+83xdybrN+f1dTN0lTTDZ/nO LJXamiYg/mnph2M9zgcWJh34uUfO8JTh68x3UptyO/Y1Sp5huS/zRuK8hGwOb4VETY2A/xeW 2hs6KUdsE5RYijMSDbWYi4oTAQckJ8x8AgAA Cc: RTGWG Working Group , So Ning 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, 06 Feb 2013 22:44:27 -0000 --_000_3834FC5646574A8597DFA24DF4608AE2ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Same here Regards, Jeff On Feb 6, 2013, at 3:14 PM, "Andrew G. Malis" > wrote: I agree with Curtis' suggested plan to advance CL Requirements now and cont= inue work on the other two drafts. Cheers, Andy On Tue, Feb 5, 2013 at 2:54 PM, Curtis Villamizar > wrote: In message > Alia Atlas writes: > That sounds good to me. > > I would really like to see the composite link work advance - > preferably by or just after the next IETF. I encourage everyone to > read and comment on it; I will do so as well and send comments > separately. > > Alia Alia, Perhaps we should consider advancing CL Requirements alone. It has been quite stable for a long time. Perhaps repeat last call and advance to the AD review. CL Use Cases has also been stable, but it has received so few comments that it is hard to say there is concensus. It could stand some improvement IMHO, and I'm an author. CL Framework will take some time. Progress may be needed on some of the docs referenced by CL Framework before we can consider advancing it. Referenced docs should at least all be WG docs with a reasonable chance of advancing rather than being abandonned. Curtis _______________________________________________ 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 --_000_3834FC5646574A8597DFA24DF4608AE2ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Same here

    Regards,
    Jeff

    On Feb 6, 2013, at 3:14 PM, "Andrew G. Malis" <andrew.g.malis@verizon.com> wrote:
    I agree with Curtis' suggested plan to advance CL Requirements now and= continue work on the other two drafts.

    Cheers,
    Andy



    On Tue, Feb 5, 2013 at 2:54 PM, Curtis Villamiza= r <curtis@occnc.com<= /a>> wrote:

    In message <CAG4d1rej2s37bt0ESO7NKUm6xjSe1ui=3D    M20V5ye76EW8xZ3CmA@mail.gmail.com>
    Alia Atlas writes:

    > That sounds good to me.
    >
    > I would really like to see the composite link work advance -
    > preferably by or just after the next IETF.  I encourage everyone = to
    > read and comment on it; I will do so as well and send comments
    > separately.
    >
    > Alia


    Alia,

    Perhaps we should consider advancing CL Requirements alone.  It has been quite stable for a long time.  Perhaps repeat last call and
    advance to the AD review.

    CL Use Cases has also been stable, but it has received so few comments
    that it is hard to say there is concensus.  It could stand some
    improvement IMHO, and I'm an author.

    CL Framework will take some time.  Progress may be needed on some of the docs referenced by CL Framework before we can consider advancing
    it.  Referenced docs should at least all be WG docs with a reasonable<= br> chance of advancing rather than being abandonned.

    Curtis
    _______________________________________________
    rtgwg mailing list
    rtgwg@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/rtgwg

    _______________________________________________
    rtgwg mailing list
    rtgwg@ietf.org
    https://www.i= etf.org/mailman/listinfo/rtgwg
    --_000_3834FC5646574A8597DFA24DF4608AE2ericssoncom_-- From akatlas@gmail.com Wed Feb 6 15:19:16 2013 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 F278421E8040 for ; Wed, 6 Feb 2013 15:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfDV4P0iLgfj for ; Wed, 6 Feb 2013 15:19:15 -0800 (PST) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id E2D6721E8034 for ; Wed, 6 Feb 2013 15:19:14 -0800 (PST) Received: by mail-ia0-f178.google.com with SMTP id y26so2277575iab.23 for ; Wed, 06 Feb 2013 15:19:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UKgSSvr5O5kpjfuMOKo9jqKO2eE6zYbPIBCCYJHRuOI=; b=iP8F5lUiPhbcQvPuHLWACbvVAuAksVutHPu6aX+IfWVsepnXcYTOE3k2974IOlFlQv d1hakWG9onJzSbxjCj4XIjaa/CUMjRlHyVHIWdhmmn+cxDWjaol4e3M3OWsoWvPjezR5 XxW5vd/wVK6ycjlZmqATyGfLb17QHYe7PgijcXpF5tG9KKUzOOY5NiJV3ySCaumkO5xh p5R3jRaLB4Wd5rMQKQp17Oz94Yg/WVHgW2LaLitmxydDvm0jCn+IYnKhY8+viTZcUa28 831vadmY2+KebnthQscfu399MSf6MS4/CRTBkr7fElArtt1ewGVKQgYkO18FWekw67ma Kw6g== MIME-Version: 1.0 X-Received: by 10.50.191.164 with SMTP id gz4mr10310426igc.24.1360192754389; Wed, 06 Feb 2013 15:19:14 -0800 (PST) Received: by 10.64.34.203 with HTTP; Wed, 6 Feb 2013 15:19:14 -0800 (PST) In-Reply-To: <3834FC56-4657-4A85-97DF-A24DF4608AE2@ericsson.com> References: <201302051954.r15Js12Y072536@gateway1.orleans.occnc.com> <3834FC56-4657-4A85-97DF-A24DF4608AE2@ericsson.com> Date: Wed, 6 Feb 2013 18:19:14 -0500 Message-ID: Subject: Re: Expiration impending: From: Alia Atlas To: Jeff Tantsura Content-Type: multipart/alternative; boundary=14dae93405c7f3924a04d5168dbd Cc: "Andrew G. Malis" , So Ning , RTGWG Working Group 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, 06 Feb 2013 23:19:16 -0000 --14dae93405c7f3924a04d5168dbd Content-Type: text/plain; charset=ISO-8859-1 K - so can we get any opinions and comments on CL Use-cases? I'll take a read through again and issue a WG Last Call tomorrow. Alia On Wed, Feb 6, 2013 at 5:44 PM, Jeff Tantsura wrote: > Same here > > Regards, > Jeff > > On Feb 6, 2013, at 3:14 PM, "Andrew G. Malis" > wrote: > > I agree with Curtis' suggested plan to advance CL Requirements now and > continue work on the other two drafts. > > Cheers, > Andy > > > > On Tue, Feb 5, 2013 at 2:54 PM, Curtis Villamizar wrote: > >> >> In message > M20V5ye76EW8xZ3CmA@mail.gmail.com> >> Alia Atlas writes: >> >> > That sounds good to me. >> > >> > I would really like to see the composite link work advance - >> > preferably by or just after the next IETF. I encourage everyone to >> > read and comment on it; I will do so as well and send comments >> > separately. >> > >> > Alia >> >> >> Alia, >> >> Perhaps we should consider advancing CL Requirements alone. It has >> been quite stable for a long time. Perhaps repeat last call and >> advance to the AD review. >> >> CL Use Cases has also been stable, but it has received so few comments >> that it is hard to say there is concensus. It could stand some >> improvement IMHO, and I'm an author. >> >> CL Framework will take some time. Progress may be needed on some of >> the docs referenced by CL Framework before we can consider advancing >> it. Referenced docs should at least all be WG docs with a reasonable >> chance of advancing rather than being abandonned. >> >> Curtis >> _______________________________________________ >> 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 > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > --14dae93405c7f3924a04d5168dbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable K - so can we get any opinions and comments on CL Use-cases? =A0I'll ta= ke a read through again and
    issue a WG Last Call tomorrow.
    Alia

    On Wed, Feb 6, 2013 at = 5:44 PM, Jeff Tantsura <jeff.tantsura@ericsson.com>= wrote:
    Same here

    Regards,
    Jeff

    On Feb 6, 2013, at 3:14 PM, "Andrew G. Malis" <andrew.g.malis@verizon.com= > wrote:

    I agree with Curtis' suggested plan to advance CL Requirements now= and continue work on the other two drafts.

    Cheers,
    Andy



    On Tue, Feb 5, 2013 at 2:54 PM, Curtis Villamiza= r <curtis@occnc.com<= /a>> wrote:

    In message <CAG4d1rej2s37bt0ESO7NKUm6xjSe1ui=3D    M20V5ye76EW8xZ3CmA@mail.gmail= .com>
    Alia Atlas writes:

    > That sounds good to me.
    >
    > I would really like to see the composite link work advance -
    > preferably by or just after the next IETF. =A0I encourage everyone to<= br> > read and comment on it; I will do so as well and send comments
    > separately.
    >
    > Alia


    Alia,

    Perhaps we should consider advancing CL Requirements alone. =A0It has
    been quite stable for a long time. =A0Perhaps repeat last call and
    advance to the AD review.

    CL Use Cases has also been stable, but it has received so few comments
    that it is hard to say there is concensus. =A0It could stand some
    improvement IMHO, and I'm an author.

    CL Framework will take some time. =A0Progress may be needed on some of
    the docs referenced by CL Framework before we can consider advancing
    it. =A0Referenced docs should at least all be WG docs with a reasonable
    chance of advancing rather than being abandonned.

    Curtis
    _______________________________________________
    rtgwg mailing list
    rtgwg@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/rtgwg

    _______________________________________________
    rtgwg mailing list
    rtgwg@ietf.org
    https://www.ietf.org/mailman/listinfo/rtgwg

    _______________________________________________
    rtgwg mailing list
    rtgwg@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/rtgwg


    --14dae93405c7f3924a04d5168dbd-- From Ning.So@tatacommunications.com Wed Feb 6 14:57:29 2013 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 F0BBE21F854E for ; Wed, 6 Feb 2013 14:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04UcRC49CnSt for ; Wed, 6 Feb 2013 14:57:29 -0800 (PST) Received: from vmx3.tatacommunications.com (vmx3.tatacommunications.com [66.198.167.208]) by ietfa.amsl.com (Postfix) with ESMTP id DD19121F853D for ; Wed, 6 Feb 2013 14:57:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,618,1355115600"; d="scan'208,217";a="248878536" Received: from unknown (HELO wv1-cas-01.vsnl.co.in) ([64.86.157.137]) by mx3-2.tatacommunications.com with ESMTP; 06 Feb 2013 17:57:24 -0500 Received: from USWV1VCAS01.vsnl.co.in (64.86.157.177) by wv1-cas-01.vsnl.co.in (64.86.157.137) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 6 Feb 2013 17:57:24 -0500 Received: from USWV1VDAG02.vsnl.co.in ([fe80::7c6a:fd71:7022:40b6]) by uswv1vcas01.vsnl.co.in ([fe80::6521:bbe2:f2e4:7b9b%11]) with mapi id 14.02.0309.002; Wed, 6 Feb 2013 17:57:24 -0500 From: Ning So To: Lucy yong , "Andrew G. Malis" , Curtis Villamizar Subject: RE: Expiration impending: Thread-Topic: Expiration impending: Thread-Index: AQHOA9qKmMu0FD6Et0qsu3zVMGCoHphtmRoAgAAGwoD//9MN4A== Date: Wed, 6 Feb 2013 22:57:24 +0000 Message-ID: References: <201302051954.r15Js12Y072536@gateway1.orleans.occnc.com> <2691CE0099834E4A9C5044EEC662BB9D4488F106@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4488F106@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.86.157.8] Content-Type: multipart/alternative; boundary="_000_F03A6CD051CB7946A6E58423E26D99A970F44AD8uswv1vdag02vsnl_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 06 Feb 2013 15:20:41 -0800 Cc: RTGWG Working Group 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, 06 Feb 2013 22:57:30 -0000 --_000_F03A6CD051CB7946A6E58423E26D99A970F44AD8uswv1vdag02vsnl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Best regards, Ning So Head of Network Architecture Mobile Broadband Services Tata Communications (Cell) 972-955-0914 From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Wednesday, February 06, 2013 3:38 PM To: Andrew G. Malis; Curtis Villamizar Cc: RTGWG Working Group; Ning So Subject: RE: Expiration impending: +1 Lucy From: rtgwg-bounces@ietf.org [mailto:rtgwg-b= ounces@ietf.org] On Behalf Of Andrew G. Malis Sent: Wednesday, February 06, 2013 2:14 PM To: Curtis Villamizar Cc: RTGWG Working Group; So Ning Subject: Re: Expiration impending: I agree with Curtis' suggested plan to advance CL Requirements now and cont= inue work on the other two drafts. Cheers, Andy On Tue, Feb 5, 2013 at 2:54 PM, Curtis Villamizar > wrote: In message > Alia Atlas writes: > That sounds good to me. > > I would really like to see the composite link work advance - > preferably by or just after the next IETF. I encourage everyone to > read and comment on it; I will do so as well and send comments > separately. > > Alia Alia, Perhaps we should consider advancing CL Requirements alone. It has been quite stable for a long time. Perhaps repeat last call and advance to the AD review. CL Use Cases has also been stable, but it has received so few comments that it is hard to say there is concensus. It could stand some improvement IMHO, and I'm an author. CL Framework will take some time. Progress may be needed on some of the docs referenced by CL Framework before we can consider advancing it. Referenced docs should at least all be WG docs with a reasonable chance of advancing rather than being abandonned. Curtis _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --_000_F03A6CD051CB7946A6E58423E26D99A970F44AD8uswv1vdag02vsnl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    +1<= /p>

     <= /p>

    Best regar= ds,

     = ;

    Ning So

    Head of Ne= twork Architecture

    Mobile Bro= adband Services

    Tata Commu= nications

    (Cell) 972= -955-0914

     <= /p>

    From: Lucy yon= g [mailto:lucy.yong@huawei.com]
    Sent: Wednesday, February 06, 2013 3:38 PM
    To: Andrew G. Malis; Curtis Villamizar
    Cc: RTGWG Working Group; Ning So
    Subject: RE: Expiration impending: <draft-ietf-rtgwg-cl-requireme= nt-08.txt>

     

    +1<= /p>

     <= /p>

    Lucy

     <= /p>

    From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Andrew G. Malis
    Sent: Wednesday, February 06, 2013 2:14 PM
    To: Curtis Villamizar
    Cc: RTGWG Working Group; So Ning
    Subject: Re: Expiration impending: <draft-ietf-rtgwg-cl-requireme= nt-08.txt>

     

    I agree with Curtis' = suggested plan to advance CL Requirements now and continue work on the othe= r two drafts.

    Cheers,
    Andy

     

    On Tue, Feb 5, 2013 at 2:54 PM, Curtis Villamizar &l= t;curtis@occnc.com> wrote:


    In message <CAG4d1rej2s37bt0ESO7NKUm6xjSe1ui=3D    M20V5ye76EW8xZ3CmA@mail.gmail.com><= /o:p>

    Alia Atlas writes:
    > That sounds good to me.
    >
    > I would really like to see the composite link work advance -
    > preferably by or just after the next IETF.  I encourage everyone = to
    > read and comment on it; I will do so as well and send comments
    > separately.
    >
    > Alia

    Alia,

    Perhaps we should consider advancing CL Requirements alone.  It has been quite stable for a long time.  Perhaps repeat last call and
    advance to the AD review.

    CL Use Cases has also been stable, but it has received so few comments
    that it is hard to say there is concensus.  It could stand some
    improvement IMHO, and I'm an author.

    CL Framework will take some time.  Progress may be needed on some of the docs referenced by CL Framework before we can consider advancing
    it.  Referenced docs should at least all be WG docs with a reasonable<= br> chance of advancing rather than being abandonned.


    Curtis
    _______________________________________________
    rtgwg mailing list
    rtgwg@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/rtgwg

     

    --_000_F03A6CD051CB7946A6E58423E26D99A970F44AD8uswv1vdag02vsnl_-- From curtis@occnc.com Wed Feb 6 18:07:43 2013 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 1A86C21F8464 for ; Wed, 6 Feb 2013 18:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.339 X-Spam-Level: X-Spam-Status: No, score=-0.339 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+mHP9rT1S2a for ; Wed, 6 Feb 2013 18:07:42 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 78F4721F8468 for ; Wed, 6 Feb 2013 18:07:42 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r17256n7091620; Wed, 6 Feb 2013 21:05:06 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302070205.r17256n7091620@gateway1.orleans.occnc.com> To: "Eric Osborne (eosborne)" From: Curtis Villamizar Subject: Re: Power aware networks : Comments requested from routing community In-reply-to: Your message of "Wed, 06 Feb 2013 20:20:29 GMT." <20ECF67871905846A80F77F8F4A27572100BEE0B@xmb-rcd-x09.cisco.com> Date: Wed, 06 Feb 2013 21:05:06 -0500 Cc: Shankar Raman M J , "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, 07 Feb 2013 02:07:43 -0000 In message <20ECF67871905846A80F77F8F4A27572100BEE0B@xmb-rcd-x09.cisco.com> "Eric Osborne (eosborne)" writes: > > draft-mjsraman-panet-bgp-power-path says > " Power consumption can be > reduced by trading off performance related measures like latency. For > example, power savings while switching from 1 Gbps to 100 Mbps is > approximately 4 W and from 100 Mbps to 10 Mbps around 0.1 Watts." Interesting example. I really don't think service providers have core links that small. Even the metro is going to 1GbE and 10GbE. The issue is really how many parallel 10 Gb/s links (older or edge), or 100 Gb/s links (the newest core stuff) are lit and operational and for this topic the issue is whether not using some of them saves power. Not using some ports and concentrating all the traffic on a subset of ports saves very little power. Most cores don't have any lower power higher delay paths. Most cores have some paths with less parallel links and some paths with more parallel links, but generally don't have one link running a partial capacity and one slower link available as an alternate. If all the links are same capacity and its just a matter of how many are running in parallel, shortest hop count is the lowest power path. There has been some discussion of building into high end line cards an ability to go into a reduced power state, but most don't support this yet (none that I am aware of). If so, then the leakage power is saved. There is active power and leakage power in any ASIC. No traffic means almost no active power. Leakage power is generally small compared to active power except in a few type of logic blocks like SRAM. So the savings might not be all that great. Anyone studied this? It would help to know the max power draw and the power draw of an idle high end card, because the idle power draw would be the savings if the card could be put in a standby state. Usually just max power figures are given. Data center is similar, typically built using the fat-tree model. Lots of parallel links. Often there is a jump up in link capacity at levels of aggregation (top of rack, end of rack, building interconnect), but the lowest speed interface would typically be the two (for redundancy) GbE from a blade server to the top of rack. Curtis From curtis@occnc.com Wed Feb 6 19:15:44 2013 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 2F69521E804E for ; Wed, 6 Feb 2013 19:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.347 X-Spam-Level: X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHXaMYnwFrDl for ; Wed, 6 Feb 2013 19:15:43 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2C421E8034 for ; Wed, 6 Feb 2013 19:15:43 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r173DB4f092005; Wed, 6 Feb 2013 22:13:11 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302070313.r173DB4f092005@gateway1.orleans.occnc.com> To: Balaji Venkat From: Curtis Villamizar Subject: Re: Power aware networks : Comments requested from routing community In-reply-to: Your message of "Thu, 07 Feb 2013 02:49:57 +0530." Date: Wed, 06 Feb 2013 22:13:11 -0500 Cc: Shankar Raman M J , "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, 07 Feb 2013 03:15:44 -0000 In message Balaji Venkat writes: > >>> If you want to try to advance a research paper with your theories on > >>> power reduction, please choose an appropriate venue such as a refereed > >>> technical journal. > > > > I repeat my main point. [And hope to be among the reviewers] > > > > Also IMHO GreenTE as described by Zhang is more likely to be feasible > > with MPLS and RSVP-TE than with OSPF or BGP or PIM, etc. But then, > > the feasibility and potential benefits of GreenTE using IGP, BGP, and > > PIM is what your academic paper can try to defend. > > Yes sir. In our proposals we intend to deploy most of our solutions > with MPLS te Involved with pce entities and RSVP te as the signalling > protocol of choice. The ospf And Isis protocols need to be used only > for carrying the power metric used in arriving at a te LSP that is a > low power path. This metric is carried in a opaque manner and kept in > the TED. > > Thanks and regards, > Balaji venkat > > > > > Thank you, > > > > Curtis This is the IETF, not the IRTF, and not an IEEE academic conference or journal. In IETF, standards are supposed to be written for protocols whose underlying mechanism are known to work. The "running code" and "deployment" before standards advancement was largely to prevent standards for unproven theories. IRTF can take on standards (usually experimental, not standards track) for important work that is research in nature but regarded as very promising. That is why I made the comment: If you want to try to advance a research paper with your theories on power reduction, please choose an appropriate venue such as a refereed technical journal. IMO that is where this work belongs, not IETF. You can do studies, like 1) finding out what kinds of interfaces exist in core networks (hint: not 100 MbE or 10 MbE), 2) how much active power each draw per bit (if you want to not put interfaces into standby), and 3) then estimate the potential gains. If the estimates are promising *and* the assumptions are realistic, then it may be something the IRTF or IETF might consider. That is along the lines of what the Zhang paper did. I'm not sure the Zhang assumptions are realistic (who uses an OC3 today?), but as academic papers go ... it may have touched on some new ground. Curtis From tony.li@tony.li Wed Feb 6 19:40:09 2013 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 77DCF21E8042 for ; Wed, 6 Feb 2013 19:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.038 X-Spam-Level: X-Spam-Status: No, score=-100.038 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veRnZLyUKJQV for ; Wed, 6 Feb 2013 19:40:08 -0800 (PST) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 906AA21E8034 for ; Wed, 6 Feb 2013 19:40:08 -0800 (PST) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta12.emeryville.ca.mail.comcast.net with comcast id x0ZS1k0010vp7WLACFg8Nb; Thu, 07 Feb 2013 03:40:08 +0000 Received: from [192.168.2.111] ([98.248.36.188]) by omta05.emeryville.ca.mail.comcast.net with comcast id xFg61k00P43ZcXW8RFg7m2; Thu, 07 Feb 2013 03:40:08 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Power aware networks : Comments requested from routing community From: Tony Li In-Reply-To: <201302070313.r173DB4f092005@gateway1.orleans.occnc.com> Date: Wed, 6 Feb 2013 19:40:06 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <201302070313.r173DB4f092005@gateway1.orleans.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360208408; bh=KXLv9rJmNg8VyTWTivgzZmcmY1bRrTRQyXc8zPLZ2vY=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=WUiAiQYEe4uEUSNa41H5K/6SIHRJw3AG2/ZPoRry9eTj3mG3/ggOIeoceza2tyuQv fvMfr5b/kWhzo5lespwwXDzK3bDDyJKUBNRirzchkxVAQCLTSBm+957k7GEEoVCnVp Pyrf2Y2hXfqc5Uhmnf/o71r5h6lokVxmy3B1XKN3lCixX9nfNmpgj1WBhRZeZRZJQs KtyyQJEMX1AJGYw0N+hzCMh00RSEmlNyiroeZ3dUg91UIT1qUAuKm26UzkMAcBeCSP 3N8c9QWmJAtiSrJ+tzx2kDWIzVwS58i5jnVHpUtub6bbNTqjiejJ8BcVVSTQIFf1gk hi0MvKVpyoSFg== Cc: Shankar Raman M J , "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, 07 Feb 2013 03:40:09 -0000 On Feb 6, 2013, at 7:13 PM, Curtis Villamizar wrote: > IRTF can take on standards (usually experimental, not standards track) > for important work that is research in nature but regarded as very > promising. One correction: The IRTF takes on research. Never standards. Tony From internet-drafts@ietf.org Wed Feb 6 19:42:52 2013 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 0823521E804B; Wed, 6 Feb 2013 19:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlcjvfzFI8jR; Wed, 6 Feb 2013 19:42:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD3221E804C; Wed, 6 Feb 2013 19:42:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-cl-requirement-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130207034250.13877.29325.idtracker@ietfa.amsl.com> Date: Wed, 06 Feb 2013 19:42:50 -0800 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, 07 Feb 2013 03:42:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Requirements for MPLS Over a Composite Link Author(s) : Curtis Villamizar Dave McDysan So Ning Andrew Malis Lucy Yong Filename : draft-ietf-rtgwg-cl-requirement-09.txt Pages : 16 Date : 2013-02-06 Abstract: There is often a need to provide large aggregates of bandwidth that are best provided using parallel links between routers or MPLS LSR. In core networks there is often no alternative since the aggregate capacities of core networks today far exceed the capacity of a single physical link or single packet processing element. The presence of parallel links, with each link potentially comprised of multiple layers has resulted in additional requirements. Certain services may benefit from being restricted to a subset of the component links or a specific component link, where component link characteristics, such as latency, differ. Certain services require that an LSP be treated as atomic and avoid reordering. Other services will continue to require only that reordering not occur within a microflow as is current practice. Current practice related to multipath is described briefly in an appendix. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-requirement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-cl-requirement-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-cl-requirement-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From curtis@occnc.com Wed Feb 6 19:46:10 2013 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 BB84021E8049 for ; Wed, 6 Feb 2013 19:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.355 X-Spam-Level: X-Spam-Status: No, score=-0.355 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EvnX-8jEFa3 for ; Wed, 6 Feb 2013 19:46:10 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 038E421E8034 for ; Wed, 6 Feb 2013 19:46:09 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r173hYqU092132; Wed, 6 Feb 2013 22:43:34 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302070343.r173hYqU092132@gateway1.orleans.occnc.com> To: Alia Atlas From: Curtis Villamizar Subject: Re: Expiration impending: In-reply-to: Your message of "Wed, 06 Feb 2013 18:19:14 EST." Date: Wed, 06 Feb 2013 22:43:34 -0500 Cc: "Andrew G. Malis" , So Ning , RTGWG Working Group 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, 07 Feb 2013 03:46:10 -0000 In message Alia Atlas writes: > > K - so can we get any opinions and comments on CL Use-cases? I'll > take a read through again and issue a WG Last Call tomorrow. > > Alia Alia, IMHO we should: 1. Focus on a repeat of the last call for CL requirements first. 2. Then solicit comments on CL Use Cases. 3. Then last call CL Use Cases if there are still no comments on it. Since time has gone by (a lot) and the document has changed (a little) we do have to repeat WG last call on CL requirements. I don't think we should last call both at the same time. The focus of most people with limited time to dedicate to this would be a thorough read of CL Requirements, possible ignoring CL Use Cases. CL requirements is more important, more thoroughly reviewed, and IMO more ready to go with minimal if any changes. I just uploaded 09 (seconds ago) with the changes suggested earlier in this thread and (so far) agreed to. Curtis ps - draft-ietf-rtgwg-cl-requirement draft-ietf-rtgwg-cl-use-cases - for those looking for these at datatracker.ietf.org From zhangmingui@huawei.com Wed Feb 6 19:53:47 2013 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 307D421E8042 for ; Wed, 6 Feb 2013 19:53:47 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSpczZz0awCY for ; Wed, 6 Feb 2013 19:53:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2180A21E8034 for ; Wed, 6 Feb 2013 19:53:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOF81753; Thu, 07 Feb 2013 03:53:31 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Feb 2013 03:53:25 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 7 Feb 2013 03:53:27 +0000 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.33]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Thu, 7 Feb 2013 11:53:20 +0800 From: Mingui Zhang To: "curtis@occnc.com" , Balaji venkat Venkataswami Subject: RE: Power aware networks : Comments requested from routing community Thread-Topic: Power aware networks : Comments requested from routing community Thread-Index: AQHOBKVFPsIuGU7T7kWvRcj+FvsyIZhtkqrQ Date: Thu, 7 Feb 2013 03:53:19 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E732AFF1A1@nkgeml508-mbx.china.huawei.com> References: Your message of "Thu, 07 Feb 2013 00:22:54 +0530." <201302062005.r16K5CQS084848@gateway1.orleans.occnc.com> In-Reply-To: <201302062005.r16K5CQS084848@gateway1.orleans.occnc.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Shankar Raman M J , "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, 07 Feb 2013 03:53:47 -0000 Hi Curtis, I am very happy that you know GreenTE so well. Very good comments. As the designer of the GreenTE model, I feel obliged to clarify some of the= confusions. Please see in-lines below. Thanks, Mingui Zhang Huawei Technologies >-----Original Message----- >From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of >Curtis Villamizar >Sent: Thursday, February 07, 2013 4:05 AM >To: Balaji venkat Venkataswami >Cc: Shankar Raman M J; rtgwg@ietf.org >Subject: Re: Power aware networks : Comments requested from routing >community > > >In message >mail.com> >Balaji venkat Venkataswami writes: > >> As you might recall one such research paper on GreenTE by Beichuan >> Zhang rang a lot of bells in the IETF by collecting the ANRP prize. So >> please dont misstate facts as you might know them and shove your ideas >> of how networks are built down our throats. > >That was a research paper published in IEEE International Conference >on Network Protocols (ICNP). > >Power savings potential (a computation, not a measurement) were as >high as 20-40%. That is good but ... > >Line cards considered were old OC3, OC48, and one port OC192 cards. >The paper ignores the reality that shutting off one port on a >multiport card makes little difference, certainly far less than a >reduction of 1/N. The power consumption of transport was not >included. Impact on fault restoration was not considered. Lots of >other flaws, but still good work and a potential 20-40% is nice, even >if factoring in reality might get only half that or less. If you read the model, you will find a variable B_m. It indicates the base = power of the line card. This base power is high and can only be saved when = all ports on a multiport card are shutting off. So the model did consider t= he reality that "shutting one port saves far less than a reduction of 1/N".= Having said that, I agree that your reality is based on most current pract= ice. But vendors can purposely provide line cards with single port. Then th= e card can be shut off when the port is shut off. Also, don't forget about = composite links which are powered physically separately. GreenTE is now abl= e to handle composite links. We have a demo website to show this: http://gr= eente.65536.cn/. Let me add another positive reality: when link cards are shutting off in a = chassis, blowers in the same chassis may be shutting off or operate at a lo= w speed. This helps the whole chassis save more power. > >The point though is that a 1 port OC192 at 174 watts (10 Gb/s) is no >match for a 500 Gb/s card at roughly 650 watts. That is more than >40%. It is more than a decimal order of magnitude greater. It is not >comparing apples to oranges, one is an IP/MPLS router with full >routing tables and short haul interfaces, the other does OTN switching >drives either short haul or long haul transport interfaces, and could >do IP/MPLS, but with only IGP routes and MPLS LSPs at that power >figure. So maybe the way the network is built needs to change. > What do you mean about the number "40%"? Anyway, line cards consume a large= percentage of energy of the whole Chassis and this percentage is increasin= g fast. This judgment always holds.=20 GreenTE only cares about line cards. So 20-40% saving actually means 20-40%= of the total power consumed by all line-cards. >Anyway, if *I* were to continue this discussion, then *I* should get >off the IETF lists and go write an academic paper. [Or better yet, >work for a service provider or equipment vendor and work toward >building better equipment and networks.] > >The point is that efficiency has gone up by orders of magnitude as we >went from OC3 to OC12 to OC48 to OC192 (circa 1995-2000) and then >multiport OC192 and OC768 and 10GbE (circa 2005-2010) to 100GbE and >ODU4 (somewhat recent) to multiport 100GbE and ODU4 (even more >recent). Power per bit drops about one to two decimal order of >magnitude per decade and for any given a specific snapshot in the >technology timeline, there are means to reduce power that get far more >than the 20-40% that GreenTE potentially offers. Besides the power saved from the efficiency of the hardware, GreenTE can ad= d another 20-40% saving, right? :)=20 > >Of course a new generation of equipment means CapEx and GreenTE is >perceived as just routing and therefore free, so therefore the >interest. > >Another point is that no one ever tried this on a real network. With >RSVP-TE no protocol changes would be necessary, just offline >computation, a configured preferred explicit-path, and some interface >shutdowns. I don't know that anyone has even measured the reduction >in power of an idled or administratively shut down interface or line >card. There was nothing in the paper on this. > >> > If you want to try to advance a research paper with your theories on >> > power reduction, please choose an appropriate venue such as a refereed >> > technical journal. > >I repeat my main point. [And hope to be among the reviewers] > >Also IMHO GreenTE as described by Zhang is more likely to be feasible >with MPLS and RSVP-TE than with OSPF or BGP or PIM, etc. But then, >the feasibility and potential benefits of GreenTE using IGP, BGP, and >PIM is what your academic paper can try to defend. When a link is shut off, no control messages (e.g., HELLOs) can be delivere= d on it. Link state routing protocols (e.g., ISIS, OSPF), is required to be= aware of this.=20 [end of my clarifications] > >Thank you, > >Curtis >_______________________________________________ >rtgwg mailing list >rtgwg@ietf.org >https://www.ietf.org/mailman/listinfo/rtgwg From balajivenkat299@gmail.com Thu Feb 7 01:57:52 2013 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 C59EF21F845A for ; Thu, 7 Feb 2013 01:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=-0.838, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWHUGE=1.54, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsb1FsGuSQch for ; Thu, 7 Feb 2013 01:57:51 -0800 (PST) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 4187321F842E for ; Thu, 7 Feb 2013 01:57:51 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id o17so2561597oag.20 for ; Thu, 07 Feb 2013 01:57:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=x8YBhqvKT/mqY8BCOzJMV5Wl1BWBafEvVaG1UOhM6rU=; b=kHyvgZ4mDN2mkscWEZpUiKxzxIcuW1Vk1L3RjRHdCWuV/Xu8HBzSST7Gc1mKAnqrHH Ao3MzFhUNBvpdPwDVLQsMBZ8F7s1UMbo9SA++uuNCdr0BYJEGiHidbuTifwi/W9ZS6xQ QZg8PzTr+RMv943REV842an160KG7HUfgqXnBe+jDfxAziV4LKbGIXF0Tj5ajIXynCKL jvD6JdOU2jvEUeWjl4bxXs0qQvrI/En3xmrG3b3iaUAEaKXX5rWoSsdlU+06u9ou3hoL SvAJR6Lm7u1iLXMWRn7Jiv4+I++OzYuVP322EFOXFzLpyFVNTeNYVXKs8NpS9d1whNDU eKUw== MIME-Version: 1.0 X-Received: by 10.182.98.44 with SMTP id ef12mr480960obb.25.1360231069588; Thu, 07 Feb 2013 01:57:49 -0800 (PST) Received: by 10.60.93.8 with HTTP; Thu, 7 Feb 2013 01:57:49 -0800 (PST) In-Reply-To: References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <20ECF67871905846A80F77F8F4A27572100BEE0B@xmb-rcd-x09.cisco.com> <27D3A47E2F60466E8BCB5070170E668D@NCSVAIO> Date: Thu, 7 Feb 2013 15:27:49 +0530 Message-ID: Subject: Fwd: Power aware networks : Comments requested from routing community From: Balaji venkat Venkataswami To: rtgwg@ietf.org Content-Type: multipart/alternative; boundary=14dae93b59b6b71d7504d51f7910 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, 07 Feb 2013 09:57:52 -0000 --14dae93b59b6b71d7504d51f7910 Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: Shankar Raman Date: Thu, Feb 7, 2013 at 1:59 PM Subject: Re: Power aware networks : Comments requested from routing community To: "Eric Osborne (eosborne)" , curtis@occnc.com Cc: Gaurav Raina , Balaji Venkat Venkataswami < balajivenkat299@gmail.com>, mjsraman@csemail.iitm.ac.in Hi Eric/Curtis, Since I am not a part of RTGWG, I have been following only half of these emails. Therefore as an observer of few of these emails, I believe there are some critical point that have been missed, which needs clarification. 1. We are not looking at shutting down links. This is left up to the service provider. Probably some ISP may not be able to shut off links, too. 2. The overall idea we are trying to convey is : the data packets are not routed today based on power information but on other criteria (hops, QoS metric etc.). We simply say that we must consider power as another criteria while taking a routing decision. In this way, overall our traffic pattern will incrementally start using low-power consuming devices and finally will force more installation of low-power devices in the Internet. 3. The approach looks at collaborative reduction in power consumption of entities in the Internet, not just at a device level or at the technology point of view (optical or copper etc.). We agree that the idea looks theoretical at present. At least, from the simulations which we tried on various network topologies, we find that there is huge opportunity in power savings using the protocol based approach, depending on the power distribution of the entities. The questions we answer through the methods are: 1. Even when the devices consume low-power, do we have strategies to route data through those devices? 2. Don't we need a overall coordination between these devices to achieve power reduction? Since you have more experience than us in handling the devices and working with the ISPs, we were working R&D for device manufacturers, you have an idea about the ISP device level issues related to cost and power. Please note that our work does not DENY any of these facts. If needed, we are open to collaboration and see how best we can integrate the device power reduction strategies, along with those facilities offered by the routing protocols today to get the best power reduction possible, which is the goal of our research and which is why we are approaching IETF. If you still believe that protocol level methods have no practical significance in power reduction, then we will have to keep this idea to a journal - (as Curtis has mentioned and has agreed to review). We are positive that his advice will add value to our paper and will definitely seek it. Hope this clarifies any confusion. Thanks Shankar -----Original Message----- From: Balaji Venkat Sent: Thursday, February 07, 2013 2:36 AM To: Eric Osborne (eosborne) Cc: curtis@occnc.com ; Shankar Raman M J ; rtgwg@ietf.org Subject: Re: Power aware networks : Comments requested from routing community Dear Eric, Comments inline... Sent from my iPad On 07-Feb-2013, at 1:50 AM, "Eric Osborne (eosborne)" wrote: You aim to optimize core networks through traffic engineering such that > some links can be shut down when not in use, or switched to lower power. > Actually the answer is a No. We do not advocate this approach. The main idea in bgp power path draft has a survey section on previous literature that we quote for reference and state that such approaches cause expensive equipment to be kept unused. You have quoted the survey section of the paper in the above sentence. > Have you done studies in core networks with real equipment that show the > actual amount of money you could save with this approach? Let's walk > through a quick hypothetical network, you tell me where I got it wrong. > > draft-mjsraman-panet-bgp-**power-path says > " Power consumption can be > reduced by trading off performance related measures like latency. For > example, power savings while switching from 1 Gbps to 100 Mbps is > approximately 4 W and from 100 Mbps to 10 Mbps around 0.1 Watts." > Again this is a survey section of the paper surveying the existing approaches. > but provides no documentation to back these costs up nor itemization of > where the power is consumed (amortized across the router? linecard optics? > DWDM gear?) > Our main intent is to allow traffic to follow low power paths through ASs (either through pce like entities or through modifying the bgp path selection algorithm) which consume the least power and possess the required bandwidth. By graphing the topology of a set ASs in the immediate neighbourhood using as-path-info strands typically for a provider manning multiple ASs within the providers own control this mechanism will let large chunks of traffic belonging to a macro FEC traverse such low power ASs through an inter-as te MPLS lsp computed by a pce like entity and setup by RSVP-te. The use of the metric, the way the pwr metric is arrived at , the computation of the topology of ASs, consequent CSPF and then mapping the traffic to the constructed LSP is the main focus if this paper. For dampening fluctuations in the metric which are frequent heuristics algorithms are suggested. By no means are we advocating shutting off links. This scheme facilitates even the follow the moon strategy naturally. > Let's assume that this is true and that it is linear, so that you burn 4W > per Gb. (side note: I suspect this is inaccurate and that scaling is > sublinear, but let's go with it because if it's sub-linear you have even > less of a use case. I also think the real world is far more complex, as > you have all the optical transport gear to worry about. But let's go with > it for now.) > > Running a 100Gb link thus draws 400W. > > Let's say you have a backbone with (300) 100Gb links. Total power > consumption is thus (300*400) == 120 kW > > Running all these links for 24 hours thus draws 120*24 == 2,880 kWh == > 2.8mWh > Power costs are maybe $0.10/kWh in the US. Double that to cover the cost > of cooling, so $0.20/kWh. > Thus, running the entire backbone costs $0.2 * 2,880 = $576/day. > $210,000/year. > Let's say your approach can save one third of the power cost, which means > about $70,000. > > An operator with 300 100Gb links in a network has hundreds of millions of > dollars worth of gear and millions or tens of millions in payroll alone. If > you cut $70k from their opex they probably wouldn't even notice. That's one > or two salaries, or 0.002% of what Time Warner spent on advertising in 2006 > (see: http://gaia.adage.com/images/**random/FactPack06.pdf). > It is a drop in the bucket, if that. And your proposal comes with > significant work attached to it, and significant risk. If your 40 years of > experience in the network industry don't help you understand the risks > you're asking an operator to take then you're missing a crucial part of any > potential real world solution. I do not think your work should be > presented at the IETF unless it makes a much stronger argument that its > benefits outweigh its costs. > Again we are not asking the operator to shut off the equipment. He needs to keep it running as long as he has traffic to carry except that the pce makes a computation every time a large FEC of traffic needs to be carried through his ASs through a path that consumes the least power with the links therein having the required bandwidth. The ratio of consumed power to the available bandwidth is the metric that is used. Consumed power relates to a weighted average of the power consumed within the AS including the edge and core devices while the available bw relates to the links ingressing into the AS at the ASBRs that are the inter connectors between the ASes. So in summary, we do not advocate shutting off links at all. In fact we disagree with that approach. The scheme we advocate tries to optimise the power consumption using the metric based approach with some heuristics. Hope this helps. Thanks and regards, Balaji venkat > > These sorts of power optimizations all seem to be "here's how you reshape > the problem so that you can throw a linear problem solver at it". For > example, [ http://www.cs.berkeley.edu/~**suchara/publications/** > GreenNetsBundles.pdf]. I've never seen anything which shows how much more work it will be for a > network operator or which quantifies the actual savings. > > If you can demonstrate significant savings in real networks at little or > no cost to operators, you have an idea worth pursuing. If your idea will > cause more operational angst (e.g. not knowing whether your unused capacity > will be there when you need it because you shut a third of it off all the > time, increased risk of equipment failure from constant power-cycling, > operational tools and training and expertise required to manage, deploy and > troubleshoot variable-power links and the centralized NMS required to run > them, etc etc etc) then it will find little traction. Green-TE and > power-aware BGP have been floating around for a while and have seen no real > uptake in the WGs as far as I can see. Is that not to be taken as an > indication that there may be no real-world interest in them? If not, what > would it take to convince you? > > > > eric > > --14dae93b59b6b71d7504d51f7910 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ---------- Forwarded message ----------
    =
    From: Shankar Raman <mjsraman@gmail.com>
    Date: Thu, Feb 7, 2013 at 1:59 PM
    Subject: Re: Power aware networks : Comments requested from routing communi= ty
    To: "Eric Osborne (eosborne)" = <eosborne@cisco.= com>, curtis@o= ccnc.com
    Cc: Gaurav Raina <gaurav@ee.iitm.ac.in>, Balaji Venkat Venkataswami <balajivenkat299@gmail.= com>, mjsraman@csemail.iitm.ac.in


    Hi Eric/Curtis,

    Since I am not a part of RTGWG, I have been following only half of these em= ails. Therefore as an observer of few of these emails, I believe there are = some critical point that have been missed, which needs clarification.

    1. We are not looking at shutting down links. This is left up to the servic= e provider. Probably some ISP may not be able to shut off links, too.

    2. The overall idea we are trying to convey is : =A0the data packets are no= t routed today based on power information but =A0on other criteria (hops, Q= oS metric etc.). We simply say that we must consider power as another crite= ria while taking a routing decision. In this way, overall our traffic patte= rn will incrementally start using low-power consuming devices and finally w= ill force more installation of low-power devices in the Internet.

    3. The approach looks at collaborative reduction in power consumption of en= tities in the Internet, not just at a device level or at the technology poi= nt of view (optical or copper etc.). We agree that the idea looks theoretic= al at present.

    At least, from the simulations which we tried on various network topologies= , we find that there is huge opportunity in power savings using the protoco= l based approach, depending on the power distribution of the entities.

    The questions we answer through the methods =A0are:
    1. Even when the devices consume low-power, do we have strategies to route = data through those devices?
    2. Don't we need a overall coordination between these devices to achiev= e power reduction?

    Since you have more experience than us in handling the devices and working = with the ISPs, we were working R&D for device manufacturers, =A0you hav= e an idea about the ISP device level issues related to cost and power. Plea= se note that our work does not DENY any of these facts.

    If needed, we are open to collaboration and see how best we can integrate t= he device power reduction strategies, along with those facilities offered b= y the routing protocols today to get the best power reduction possible, whi= ch is the goal of our research and which is why we are approaching IETF.
    If you still believe that protocol level methods have no practical signific= ance in power reduction, then we will have to keep this idea to a journal -= (as Curtis has mentioned and has agreed to review). We are positive that h= is advice will add value to our paper =A0and will definitely seek it.

    Hope this clarifies any confusion.

    Thanks
    Shankar

    -----Original Message----- From: Balaji Venkat
    Sent: Thursday, February 07, 2013 2:36 AM
    To: Eric Osborne (eosborne)
    Cc: curtis@occnc.com<= /a> ; Shankar Raman M J ; rtgwg@ietf.org

    Subject: Re: Power aware networks : Comments requested from routing communi= ty

    Dear Eric,

    Comments inline...

    Sent from my iPad

    On 07-Feb-2013, at 1:50 AM, "Eric Osborne (eosborne)" <eosborne@cisco.com>= wrote:

    You aim to optimize core networks through traffic engineering such that som= e links can be shut down when not in use, or switched to lower power.

    Actually the answer is a No. We do not advocate this approach. The main ide= a in bgp power path draft has a survey section on previous literature that = we quote for reference and state that such approaches cause expensive equip= ment to be kept unused. You have quoted the survey section of the paper in = the above sentence.


    Have you done studies in core networks with real equipment that show the ac= tual amount of money you could save with this approach? =A0Let's walk t= hrough a quick hypothetical network, you tell me where I got it wrong.

    draft-mjsraman-panet-bgp-power-path says
    " Power consumption can be
    =A0 reduced by trading off performance related measures like latency. For =A0 example, power savings while switching from 1 Gbps to 100 Mbps is
    =A0 approximately 4 W and from 100 Mbps to 10 Mbps around 0.1 Watts."<= br>

    Again this is a survey section of the paper surveying the existing approach= es.


    but provides no documentation to back these costs up nor itemization of whe= re the power is consumed (amortized across the router? =A0linecard optics? = =A0DWDM gear?)

    Our main intent is to allow traffic to follow low power paths through ASs (= either through pce like entities or through modifying the bgp path selectio= n algorithm) which consume the least power and possess the required bandwid= th. By graphing the topology of a set ASs in the immediate neighbourhood us= ing as-path-info strands typically for a provider manning multiple ASs with= in the providers own control this mechanism will let large chunks of traffi= c belonging to a macro FEC traverse such low power ASs through an inter-as = te MPLS lsp computed by a pce like entity and setup by RSVP-te.

    The use of the metric, the way the pwr metric is arrived at , the computati= on of the topology of ASs, consequent CSPF and then mapping the traffic to = the constructed LSP is the main focus if this paper. For dampening fluctuat= ions in the metric which are frequent heuristics algorithms are suggested.<= br>
    By no means are we advocating shutting off links. This scheme facilitates e= ven the follow the moon strategy naturally.



    Let's assume that this is true and that it is linear, so that you burn = 4W per Gb. =A0(side note: I suspect this is inaccurate and that scaling is = sublinear, but let's go with it because if it's sub-linear you have= even less of a use case. =A0I also think the real world is far more comple= x, as you have all the optical transport gear to worry about. =A0But let= 9;s go with it for now.)

    Running a 100Gb link thus draws 400W.

    Let's say you have a backbone with (300) 100Gb links. =A0Total power co= nsumption is thus (300*400) =3D=3D 120 kW

    Running all these links for 24 hours thus draws 120*24 =3D=3D 2,880 kWh =A0= =3D=3D 2.8mWh
    Power costs are maybe $0.10/kWh in the US. =A0Double that to cover the cost= of cooling, so $0.20/kWh.
    Thus, running the entire backbone costs $0.2 * 2,880 =3D $576/day. $210,000= /year.
    Let's say your approach can save one third of the power cost, which mea= ns about $70,000.

    An operator with 300 100Gb links in a network has hundreds of millions of d= ollars worth of gear and millions or tens of millions in payroll alone. If = you cut $70k from their opex they probably wouldn't even notice. That&#= 39;s one or two salaries, or 0.002% of what Time Warner spent on advertisin= g in 2006 (see: http://gaia.adage.com/images/random/FactPack06= .pdf). =A0It is a drop in the bucket, if that. =A0And your proposal com= es with significant work attached to it, and significant risk. =A0If your 4= 0 years of experience in the network industry don't help you understand= the risks you're asking an operator to take then you're missing a = crucial part of any potential real world solution. =A0I do not think your w= ork should be presented at the IETF unless it makes a much stronger argumen= t that its benefits outweigh its costs.

    Again we are not asking the operator to shut off the equipment. He needs to= keep it running as long as he has traffic to carry except that the pce mak= es a computation every time a large FEC of traffic needs to be carried thro= ugh his ASs through a path that consumes the least power with the links the= rein having the required bandwidth. The ratio of consumed power to the avai= lable bandwidth is the metric that is used. Consumed power relates to a wei= ghted average of the power consumed within the AS including the edge and co= re devices while the available bw relates to the links ingressing into the = AS at the ASBRs that are the inter connectors between the ASes.


    So in summary, we do not advocate shutting off links at all. In fact we dis= agree with that approach. The scheme we advocate tries to optimise the powe= r consumption using the metric based approach with some heuristics.

    Hope this helps.

    Thanks and regards,
    Balaji venkat

    These sorts of power optimizations all seem to be "here's how you = reshape the problem so that you can throw a linear problem solver at it&quo= t;. =A0For example, [ http://www.cs.berkeley.edu/~= suchara/publications/GreenNetsBundles.pdf ]. I've nev= er seen anything which shows how much more work it will be for a network op= erator or which quantifies the actual savings.

    If you can demonstrate significant savings in real networks at little or no= cost to operators, you have an idea worth pursuing. =A0If your idea will c= ause more operational angst (e.g. not knowing whether your unused capacity = will be there when you need it because you shut a third of it off all the t= ime, increased risk of equipment failure from constant power-cycling, opera= tional tools and training and expertise required to manage, deploy and trou= bleshoot variable-power links and the centralized NMS required to run them,= etc etc etc) then it will find little traction. Green-TE and power-aware B= GP have been floating around for a while and have seen no real uptake in th= e WGs as far as I can see. =A0Is that not to be taken as an indication that= there may be no real-world interest in them? =A0If not, what would it take= to convince you?



    eric

    --14dae93b59b6b71d7504d51f7910-- From balajivenkat299@gmail.com Thu Feb 7 04:51:10 2013 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 BC69221F8938 for ; Thu, 7 Feb 2013 04:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWHUGE=1.54, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2xOT2etCIaJ for ; Thu, 7 Feb 2013 04:51:08 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8C421F8561 for ; Thu, 7 Feb 2013 04:51:06 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id h1so2754361oag.31 for ; Thu, 07 Feb 2013 04:51:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=81aN35WGwTsMkZsuNmZPcljBSWza1IlBfnVnsZAhl5I=; b=ajThxb/8XzK/pKg363ryOA7UDAbSDRd6ucGSbj28Y27QQR+zdcMWg5m1eQlIs294TW W7jLttLphi74fcQJkYI1luejhHi+mCLdYuw3F3W/GdEGg1veaa52VTuxD8Pi7hzBwLf+ zDAa0NQOaTI0r7IEqHqoO4oLzLpRiJa74X9AongU35KKM3/rSbVRzpOBLY0ZhKTwU8wg llaG2rajLjH05BkTimOkbKwQ31eFL43O55RIG/TWd/A01skoCoDa2gOoCogVAq+aKZOy xWF/YSQx0DE+LKkRRQSqpBH89NvefvdEFdJu3XmXWFxe17teMgabBZC48PJIuysu3KFZ ezIg== MIME-Version: 1.0 X-Received: by 10.60.32.143 with SMTP id j15mr854147oei.7.1360241466135; Thu, 07 Feb 2013 04:51:06 -0800 (PST) Received: by 10.60.93.8 with HTTP; Thu, 7 Feb 2013 04:51:05 -0800 (PST) In-Reply-To: References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <20ECF67871905846A80F77F8F4A27572100BEE0B@xmb-rcd-x09.cisco.com> <27D3A47E2F60466E8BCB5070170E668D@NCSVAIO> Date: Thu, 7 Feb 2013 18:21:05 +0530 Message-ID: Subject: Fwd: Power aware networks : Comments requested from routing community From: Balaji venkat Venkataswami To: rtgwg@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb1ee6e65d58f04d521e5fd 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, 07 Feb 2013 12:51:10 -0000 --e89a8fb1ee6e65d58f04d521e5fd Content-Type: text/plain; charset=ISO-8859-1 Dear all, Adding the rtgwg alias again since message size was exceeded. thanks and regards, balaji venkat ---------- Forwarded message ---------- From: Shankar Raman Date: Thu, Feb 7, 2013 at 1:59 PM Subject: Re: Power aware networks : Comments requested from routing community To: "Eric Osborne (eosborne)" , curtis@occnc.com Cc: Gaurav Raina , Balaji Venkat Venkataswami < balajivenkat299@gmail.com>, mjsraman@csemail.iitm.ac.in Hi Eric/Curtis, Since I am not a part of RTGWG, I have been following only half of these emails. Therefore as an observer of few of these emails, I believe there are some critical point that have been missed, which needs clarification. 1. We are not looking at shutting down links. This is left up to the service provider. Probably some ISP may not be able to shut off links, too. 2. The overall idea we are trying to convey is : the data packets are not routed today based on power information but on other criteria (hops, QoS metric etc.). We simply say that we must consider power as another criteria while taking a routing decision. In this way, overall our traffic pattern will incrementally start using low-power consuming devices and finally will force more installation of low-power devices in the Internet. 3. The approach looks at collaborative reduction in power consumption of entities in the Internet, not just at a device level or at the technology point of view (optical or copper etc.). We agree that the idea looks theoretical at present. At least, from the simulations which we tried on various network topologies, we find that there is huge opportunity in power savings using the protocol based approach, depending on the power distribution of the entities. The questions we answer through the methods are: 1. Even when the devices consume low-power, do we have strategies to route data through those devices? 2. Don't we need a overall coordination between these devices to achieve power reduction? Since you have more experience than us in handling the devices and working with the ISPs, we were working R&D for device manufacturers, you have an idea about the ISP device level issues related to cost and power. Please note that our work does not DENY any of these facts. If needed, we are open to collaboration and see how best we can integrate the device power reduction strategies, along with those facilities offered by the routing protocols today to get the best power reduction possible, which is the goal of our research and which is why we are approaching IETF. If you still believe that protocol level methods have no practical significance in power reduction, then we will have to keep this idea to a journal - (as Curtis has mentioned and has agreed to review). We are positive that his advice will add value to our paper and will definitely seek it. Hope this clarifies any confusion. Thanks Shankar -----Original Message----- From: Balaji Venkat Sent: Thursday, February 07, 2013 2:36 AM To: Eric Osborne (eosborne) Cc: curtis@occnc.com ; Shankar Raman M J ; rtgwg@ietf.org Subject: Re: Power aware networks : Comments requested from routing community Dear Eric, Comments inline... Sent from my iPad On 07-Feb-2013, at 1:50 AM, "Eric Osborne (eosborne)" wrote: You aim to optimize core networks through traffic engineering such that > some links can be shut down when not in use, or switched to lower power. > Actually the answer is a No. We do not advocate this approach. The main idea in bgp power path draft has a survey section on previous literature that we quote for reference and state that such approaches cause expensive equipment to be kept unused. You have quoted the survey section of the paper in the above sentence. > Have you done studies in core networks with real equipment that show the > actual amount of money you could save with this approach? Let's walk > through a quick hypothetical network, you tell me where I got it wrong. > > draft-mjsraman-panet-bgp-**power-path says > " Power consumption can be > reduced by trading off performance related measures like latency. For > example, power savings while switching from 1 Gbps to 100 Mbps is > approximately 4 W and from 100 Mbps to 10 Mbps around 0.1 Watts." > Again this is a survey section of the paper surveying the existing approaches. > but provides no documentation to back these costs up nor itemization of > where the power is consumed (amortized across the router? linecard optics? > DWDM gear?) > Our main intent is to allow traffic to follow low power paths through ASs (either through pce like entities or through modifying the bgp path selection algorithm) which consume the least power and possess the required bandwidth. By graphing the topology of a set ASs in the immediate neighbourhood using as-path-info strands typically for a provider manning multiple ASs within the providers own control this mechanism will let large chunks of traffic belonging to a macro FEC traverse such low power ASs through an inter-as te MPLS lsp computed by a pce like entity and setup by RSVP-te. The use of the metric, the way the pwr metric is arrived at , the computation of the topology of ASs, consequent CSPF and then mapping the traffic to the constructed LSP is the main focus if this paper. For dampening fluctuations in the metric which are frequent heuristics algorithms are suggested. By no means are we advocating shutting off links. This scheme facilitates even the follow the moon strategy naturally. > Let's assume that this is true and that it is linear, so that you burn 4W > per Gb. (side note: I suspect this is inaccurate and that scaling is > sublinear, but let's go with it because if it's sub-linear you have even > less of a use case. I also think the real world is far more complex, as > you have all the optical transport gear to worry about. But let's go with > it for now.) > > Running a 100Gb link thus draws 400W. > > Let's say you have a backbone with (300) 100Gb links. Total power > consumption is thus (300*400) == 120 kW > > Running all these links for 24 hours thus draws 120*24 == 2,880 kWh == > 2.8mWh > Power costs are maybe $0.10/kWh in the US. Double that to cover the cost > of cooling, so $0.20/kWh. > Thus, running the entire backbone costs $0.2 * 2,880 = $576/day. > $210,000/year. > Let's say your approach can save one third of the power cost, which means > about $70,000. > > An operator with 300 100Gb links in a network has hundreds of millions of > dollars worth of gear and millions or tens of millions in payroll alone. If > you cut $70k from their opex they probably wouldn't even notice. That's one > or two salaries, or 0.002% of what Time Warner spent on advertising in 2006 > (see: http://gaia.adage.com/images/**random/FactPack06.pdf). > It is a drop in the bucket, if that. And your proposal comes with > significant work attached to it, and significant risk. If your 40 years of > experience in the network industry don't help you understand the risks > you're asking an operator to take then you're missing a crucial part of any > potential real world solution. I do not think your work should be > presented at the IETF unless it makes a much stronger argument that its > benefits outweigh its costs. > Again we are not asking the operator to shut off the equipment. He needs to keep it running as long as he has traffic to carry except that the pce makes a computation every time a large FEC of traffic needs to be carried through his ASs through a path that consumes the least power with the links therein having the required bandwidth. The ratio of consumed power to the available bandwidth is the metric that is used. Consumed power relates to a weighted average of the power consumed within the AS including the edge and core devices while the available bw relates to the links ingressing into the AS at the ASBRs that are the inter connectors between the ASes. So in summary, we do not advocate shutting off links at all. In fact we disagree with that approach. The scheme we advocate tries to optimise the power consumption using the metric based approach with some heuristics. Hope this helps. Thanks and regards, Balaji venkat > > These sorts of power optimizations all seem to be "here's how you reshape > the problem so that you can throw a linear problem solver at it". For > example, [ http://www.cs.berkeley.edu/~**suchara/publications/** > GreenNetsBundles.pdf]. I've never seen anything which shows how much more work it will be for a > network operator or which quantifies the actual savings. > > If you can demonstrate significant savings in real networks at little or > no cost to operators, you have an idea worth pursuing. If your idea will > cause more operational angst (e.g. not knowing whether your unused capacity > will be there when you need it because you shut a third of it off all the > time, increased risk of equipment failure from constant power-cycling, > operational tools and training and expertise required to manage, deploy and > troubleshoot variable-power links and the centralized NMS required to run > them, etc etc etc) then it will find little traction. Green-TE and > power-aware BGP have been floating around for a while and have seen no real > uptake in the WGs as far as I can see. Is that not to be taken as an > indication that there may be no real-world interest in them? If not, what > would it take to convince you? > > > > eric > --e89a8fb1ee6e65d58f04d521e5fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,

    Adding the rtgwg alias again since message siz= e was exceeded.

    thanks and regards,
    bala= ji venkat
    ---------- Forwarded message ----------
    From: Shankar Raman <mjsraman@gmail.com>
    Date: Thu, Fe= b 7, 2013 at 1:59 PM
    Subject: Re: Power aware networks : Comments requested from routing communi= ty
    To: "Eric Osborne (eosborne)" = <eosborne@cisco.= com>, curtis@o= ccnc.com
    Cc: Gaurav Raina <gaurav@ee.iitm.ac.in>, Balaji Venkat Venkataswami <balajivenkat299@gmail.= com>, mjsraman@csemail.iitm.ac.in


    Hi Eric/Curtis,
    Since I am not a part of RTGWG, I have been following only half of these em= ails. Therefore as an observer of few of these emails, I believe there are = some critical point that have been missed, which needs clarification.

    1. We are not looking at shutting down links. This is left up to the servic= e provider. Probably some ISP may not be able to shut off links, too.

    2. The overall idea we are trying to convey is : =A0the data packets are no= t routed today based on power information but =A0on other criteria (hops, Q= oS metric etc.). We simply say that we must consider power as another crite= ria while taking a routing decision. In this way, overall our traffic patte= rn will incrementally start using low-power consuming devices and finally w= ill force more installation of low-power devices in the Internet.

    3. The approach looks at collaborative reduction in power consumption of en= tities in the Internet, not just at a device level or at the technology poi= nt of view (optical or copper etc.). We agree that the idea looks theoretic= al at present.

    At least, from the simulations which we tried on various network topologies= , we find that there is huge opportunity in power savings using the protoco= l based approach, depending on the power distribution of the entities.

    The questions we answer through the methods =A0are:
    1. Even when the devices consume low-power, do we have strategies to route = data through those devices?
    2. Don't we need a overall coordination between these devices to achiev= e power reduction?

    Since you have more experience than us in handling the devices and working = with the ISPs, we were working R&D for device manufacturers, =A0you hav= e an idea about the ISP device level issues related to cost and power. Plea= se note that our work does not DENY any of these facts.

    If needed, we are open to collaboration and see how best we can integrate t= he device power reduction strategies, along with those facilities offered b= y the routing protocols today to get the best power reduction possible, whi= ch is the goal of our research and which is why we are approaching IETF.
    If you still believe that protocol level methods have no practical signific= ance in power reduction, then we will have to keep this idea to a journal -= (as Curtis has mentioned and has agreed to review). We are positive that h= is advice will add value to our paper =A0and will definitely seek it.

    Hope this clarifies any confusion.

    Thanks
    Shankar

    -----Original Message----- From: Balaji Venkat
    Sent: Thursday, February 07, 2013 2:36 AM
    To: Eric Osborne (eosborne)
    Cc: curtis@occnc.com<= /a> ; Shankar Raman M J ; rtgwg@ietf.org

    Subject: Re: Power aware networks : Comments requested from routing communi= ty

    Dear Eric,

    Comments inline...

    Sent from my iPad

    On 07-Feb-2013, at 1:50 AM, "Eric Osborne (eosborne)" <eosborne@cisco.com>= wrote:

    You aim to optimize core networks through traffic engineering such that som= e links can be shut down when not in use, or switched to lower power.

    Actually the answer is a No. We do not advocate this approach. The main ide= a in bgp power path draft has a survey section on previous literature that = we quote for reference and state that such approaches cause expensive equip= ment to be kept unused. You have quoted the survey section of the paper in = the above sentence.


    Have you done studies in core networks with real equipment that show the ac= tual amount of money you could save with this approach? =A0Let's walk t= hrough a quick hypothetical network, you tell me where I got it wrong.

    draft-mjsraman-panet-bgp-power-path says
    " Power consumption can be
    =A0 reduced by trading off performance related measures like latency. For =A0 example, power savings while switching from 1 Gbps to 100 Mbps is
    =A0 approximately 4 W and from 100 Mbps to 10 Mbps around 0.1 Watts."<= br>

    Again this is a survey section of the paper surveying the existing approach= es.


    but provides no documentation to back these costs up nor itemization of whe= re the power is consumed (amortized across the router? =A0linecard optics? = =A0DWDM gear?)

    Our main intent is to allow traffic to follow low power paths through ASs (= either through pce like entities or through modifying the bgp path selectio= n algorithm) which consume the least power and possess the required bandwid= th. By graphing the topology of a set ASs in the immediate neighbourhood us= ing as-path-info strands typically for a provider manning multiple ASs with= in the providers own control this mechanism will let large chunks of traffi= c belonging to a macro FEC traverse such low power ASs through an inter-as = te MPLS lsp computed by a pce like entity and setup by RSVP-te.

    The use of the metric, the way the pwr metric is arrived at , the computati= on of the topology of ASs, consequent CSPF and then mapping the traffic to = the constructed LSP is the main focus if this paper. For dampening fluctuat= ions in the metric which are frequent heuristics algorithms are suggested.<= br>
    By no means are we advocating shutting off links. This scheme facilitates e= ven the follow the moon strategy naturally.



    Let's assume that this is true and that it is linear, so that you burn = 4W per Gb. =A0(side note: I suspect this is inaccurate and that scaling is = sublinear, but let's go with it because if it's sub-linear you have= even less of a use case. =A0I also think the real world is far more comple= x, as you have all the optical transport gear to worry about. =A0But let= 9;s go with it for now.)

    Running a 100Gb link thus draws 400W.

    Let's say you have a backbone with (300) 100Gb links. =A0Total power co= nsumption is thus (300*400) =3D=3D 120 kW

    Running all these links for 24 hours thus draws 120*24 =3D=3D 2,880 kWh =A0= =3D=3D 2.8mWh
    Power costs are maybe $0.10/kWh in the US. =A0Double that to cover the cost= of cooling, so $0.20/kWh.
    Thus, running the entire backbone costs $0.2 * 2,880 =3D $576/day. $210,000= /year.
    Let's say your approach can save one third of the power cost, which mea= ns about $70,000.

    An operator with 300 100Gb links in a network has hundreds of millions of d= ollars worth of gear and millions or tens of millions in payroll alone. If = you cut $70k from their opex they probably wouldn't even notice. That&#= 39;s one or two salaries, or 0.002% of what Time Warner spent on advertisin= g in 2006 (see: http://gaia.adage.com/images/random/FactPack06= .pdf). =A0It is a drop in the bucket, if that. =A0And your proposal com= es with significant work attached to it, and significant risk. =A0If your 4= 0 years of experience in the network industry don't help you understand= the risks you're asking an operator to take then you're missing a = crucial part of any potential real world solution. =A0I do not think your w= ork should be presented at the IETF unless it makes a much stronger argumen= t that its benefits outweigh its costs.

    Again we are not asking the operator to shut off the equipment. He needs to= keep it running as long as he has traffic to carry except that the pce mak= es a computation every time a large FEC of traffic needs to be carried thro= ugh his ASs through a path that consumes the least power with the links the= rein having the required bandwidth. The ratio of consumed power to the avai= lable bandwidth is the metric that is used. Consumed power relates to a wei= ghted average of the power consumed within the AS including the edge and co= re devices while the available bw relates to the links ingressing into the = AS at the ASBRs that are the inter connectors between the ASes.


    So in summary, we do not advocate shutting off links at all. In fact we dis= agree with that approach. The scheme we advocate tries to optimise the powe= r consumption using the metric based approach with some heuristics.

    Hope this helps.

    Thanks and regards,
    Balaji venkat

    These sorts of power optimizations all seem to be "here's how you = reshape the problem so that you can throw a linear problem solver at it&quo= t;. =A0For example, [ http://www.cs.berkeley.edu/~= suchara/publications/GreenNetsBundles.pdf ]. I've nev= er seen anything which shows how much more work it will be for a network op= erator or which quantifies the actual savings.

    If you can demonstrate significant savings in real networks at little or no= cost to operators, you have an idea worth pursuing. =A0If your idea will c= ause more operational angst (e.g. not knowing whether your unused capacity = will be there when you need it because you shut a third of it off all the t= ime, increased risk of equipment failure from constant power-cycling, opera= tional tools and training and expertise required to manage, deploy and trou= bleshoot variable-power links and the centralized NMS required to run them,= etc etc etc) then it will find little traction. Green-TE and power-aware B= GP have been floating around for a while and have seen no real uptake in th= e WGs as far as I can see. =A0Is that not to be taken as an indication that= there may be no real-world interest in them? =A0If not, what would it take= to convince you?



    eric
    --e89a8fb1ee6e65d58f04d521e5fd-- From balajivenkat299@gmail.com Thu Feb 7 04:52:33 2013 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 F13EF21F8446 for ; Thu, 7 Feb 2013 04:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.183 X-Spam-Level: X-Spam-Status: No, score=-3.183 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vvw1GdnM4pBB for ; Thu, 7 Feb 2013 04:52:31 -0800 (PST) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by ietfa.amsl.com (Postfix) with ESMTP id 59D4921F846B for ; Thu, 7 Feb 2013 04:52:31 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id ta14so2638675obb.28 for ; Thu, 07 Feb 2013 04:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=shQUNUThZvcJCLKCZS987/lp3pCM2Z+3/mQU2gN3rO4=; b=YcwmYWJQnpp3IxdhcHj5zpKDD1HIk4JtiBKvwcaiTj0++2RXn5VkIdzH8tGjkiLLy4 mD0mk9P0o8Fho9YZimiiSmLtAo1MSegtQboT7CEsT7640Z89XYsOh1+TQlgXNqesq1vp 5Ntu/vvVdWvSM+WxesUxWiBY6oT0yfqlHKu+tJuZO1X8UzvksV6fc6C22PCRE//Wf/bz rSOvlf93hlxyzykxl49Lk10CXI52QXF+PiA2+7gPD+V7aOdOzVDCZqdpXVF3/7X8RMJ3 3f03t8DIi7VjZS/ZZCgzUqveThQWYayOYh+GFl+rYFmTzy/ohB07muyE0vN6U2IK/hke qJQg== MIME-Version: 1.0 X-Received: by 10.60.28.228 with SMTP id e4mr822183oeh.111.1360241550830; Thu, 07 Feb 2013 04:52:30 -0800 (PST) Received: by 10.60.93.8 with HTTP; Thu, 7 Feb 2013 04:52:30 -0800 (PST) In-Reply-To: References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <20ECF67871905846A80F77F8F4A27572100BEE0B@xmb-rcd-x09.cisco.com> <3B74A0857EB0496E8FA8B026A758D788@NCSVAIO> Date: Thu, 7 Feb 2013 18:22:30 +0530 Message-ID: Subject: Fwd: Power aware networks : Comments requested from routing community From: Balaji venkat Venkataswami To: rtgwg@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff1c5b8722d7d04d521eae5 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, 07 Feb 2013 12:52:33 -0000 --e89a8ff1c5b8722d7d04d521eae5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear all, Adding the rtgwg alias again since the message size was exceeded. thanks and regards, balaji venkat ---------- Forwarded message ---------- From: Balaji venkat Venkataswami Date: Thu, Feb 7, 2013 at 3:24 PM Subject: Fwd: Power aware networks : Comments requested from routing community To: rtgwg@ietf.org, "Eric Osborne (eosborne)" , Curtis Villamizar Adding the rtgwg alias since some of us dont have access to sending mails on it. thanks and regards, balaji venkat ---------- Forwarded message ---------- From: Shankar Raman Date: Thu, Feb 7, 2013 at 3:17 PM Subject: Re: Power aware networks : Comments requested from routing community To: Balaji Venkat , "Eric Osborne (eosborne)" < eosborne@cisco.com> Cc: curtis@occnc.com, rtgwg@ietf.org Dear Eric, Looks like we have not been clear in conveying our idea. We abstract the power consumed by every router/switch, use it as the power rating. We then assign it to the link as a metric characteristic to get algorithms like SPF and CSPF to choose the lowest power paths or any metric based routing algorithm. So the link metric is a combination of power consumed including the physical link and router components. In effect the link metric is not just the physical link=92s metric alone (but the cost of the power consumed by t= he router/switch on which it connects to the neighbor). Just like routing protocols consider delay, hops as metric we consider this power consumption as yet another metric. Thanks Shankar -----Original Message----- From: Balaji Venkat Sent: Thursday, February 07, 2013 2:36 AM To: Eric Osborne (eosborne) Cc: curtis@occnc.com ; Shankar Raman M J ; rtgwg@ietf.org Subject: Re: Power aware networks : Comments requested from routing community Dear Eric, Comments inline... Sent from my iPad On 07-Feb-2013, at 1:50 AM, "Eric Osborne (eosborne)" wrote: > You aim to optimize core networks through traffic engineering such that some links can be shut down when not in use, or switched to lower power. Actually the answer is a No. We do not advocate this approach. The main idea in bgp power path draft has a survey section on previous literature that we quote for reference and state that such approaches cause expensive equipment to be kept unused. You have quoted the survey section of the paper in the above sentence. > > Have you done studies in core networks with real equipment that show the actual amount of money you could save with this approach? Let's walk through a quick hypothetical network, you tell me where I got it wrong. > > draft-mjsraman-panet-bgp-power-path says > " Power consumption can be > reduced by trading off performance related measures like latency. For > example, power savings while switching from 1 Gbps to 100 Mbps is > approximately 4 W and from 100 Mbps to 10 Mbps around 0.1 Watts." Again this is a survey section of the paper surveying the existing approaches. > > but provides no documentation to back these costs up nor itemization of where the power is consumed (amortized across the router? linecard optics? DWDM gear?) Our main intent is to allow traffic to follow low power paths through ASs (either through pce like entities or through modifying the bgp path selection algorithm) which consume the least power and possess the required bandwidth. By graphing the topology of a set ASs in the immediate neighbourhood using as-path-info strands typically for a provider manning multiple ASs within the providers own control this mechanism will let large chunks of traffic belonging to a macro FEC traverse such low power ASs through an inter-as te MPLS lsp computed by a pce like entity and setup by RSVP-te. The use of the metric, the way the pwr metric is arrived at , the computation of the topology of ASs, consequent CSPF and then mapping the traffic to the constructed LSP is the main focus if this paper. For dampening fluctuations in the metric which are frequent heuristics algorithms are suggested. By no means are we advocating shutting off links. This scheme facilitates even the follow the moon strategy naturally. > > Let's assume that this is true and that it is linear, so that you burn 4W per Gb. (side note: I suspect this is inaccurate and that scaling is sublinear, but let's go with it because if it's sub-linear you have even less of a use case. I also think the real world is far more complex, as you have all the optical transport gear to worry about. But let's go with it for now.) > > Running a 100Gb link thus draws 400W. > > Let's say you have a backbone with (300) 100Gb links. Total power consumption is thus (300*400) =3D=3D 120 kW > > Running all these links for 24 hours thus draws 120*24 =3D=3D 2,880 kWh = =3D=3D 2.8mWh > Power costs are maybe $0.10/kWh in the US. Double that to cover the cost of cooling, so $0.20/kWh. > Thus, running the entire backbone costs $0.2 * 2,880 =3D $576/day. $210,000/year. > Let's say your approach can save one third of the power cost, which means about $70,000. > > An operator with 300 100Gb links in a network has hundreds of millions of dollars worth of gear and millions or tens of millions in payroll alone. If you cut $70k from their opex they probably wouldn't even notice. That's one or two salaries, or 0.002% of what Time Warner spent on advertising in 2006 (see: http://gaia.adage.com/images/random/FactPack06.pdf). It is a drop in the bucket, if that. And your proposal comes with significant work attached to it, and significant risk. If your 40 years of experience in the network industry don't help you understand the risks you're asking an operator to take then you're missing a crucial part of any potential real world solution. I do not think your work should be presented at the IETF unless it makes a much stronger argument that its benefits outweigh its costs. Again we are not asking the operator to shut off the equipment. He needs to keep it running as long as he has traffic to carry except that the pce makes a computation every time a large FEC of traffic needs to be carried through his ASs through a path that consumes the least power with the links therein having the required bandwidth. The ratio of consumed power to the available bandwidth is the metric that is used. Consumed power relates to a weighted average of the power consumed within the AS including the edge and core devices while the available bw relates to the links ingressing into the AS at the ASBRs that are the inter connectors between the ASes. So in summary, we do not advocate shutting off links at all. In fact we disagree with that approach. The scheme we advocate tries to optimise the power consumption using the metric based approach with some heuristics. Hope this helps. Thanks and regards, Balaji venkat > > These sorts of power optimizations all seem to be "here's how you reshape the problem so that you can throw a linear problem solver at it". For example, [ http://www.cs.berkeley.edu/~suchara/publications/GreenNetsBundles.pdf ]. I've never seen anything which shows how much more work it will be for a network operator or which quantifies the actual savings. > > If you can demonstrate significant savings in real networks at little or no cost to operators, you have an idea worth pursuing. If your idea will cause more operational angst (e.g. not knowing whether your unused capacity will be there when you need it because you shut a third of it off all the time, increased risk of equipment failure from constant power-cycling, operational tools and training and expertise required to manage, deploy and troubleshoot variable-power links and the centralized NMS required to run them, etc etc etc) then it will find little traction. Green-TE and power-aware BGP have been floating around for a while and have seen no real uptake in the WGs as far as I can see. Is that not to be taken as an indication that there may be no real-world interest in them? If not, what would it take to convince you? > > > > eric > --e89a8ff1c5b8722d7d04d521eae5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear all,

    Adding the rtgwg alias again since the message= size was exceeded.

    thanks and regards,
    = balaji venkat

    ---------- Forwarded messag= e ----------
    From: Balaji venkat Venkataswami <balajivenkat299@= gmail.com>
    Date: Thu, Feb 7, 2013 at 3:24 PM
    Subject: F= wd: Power aware networks : Comments requested from routing community
    To: rtgwg@ietf.org, "Eric Osborn= e (eosborne)" <eosborne@cisco= .com>, Curtis Villamizar <cur= tis@occnc.com>


    Adding the rtgwg alias since some of us dont have access to sending= mails on it.

    thanks and regards,
    balaji venka= t

    ---------- Forwarded = message ----------
    From: Shankar Raman <= ;mjsraman@gmail.com= >
    Date: Thu, Feb 7, 2013 at 3:17 PM
    Subject: Re: Power aware networks : Co= mments requested from routing community
    To:= Balaji Venkat <balajivenkat299@gmail.com>, "Eric Osborne (eosborne)&quo= t; <eosborne@cis= co.com>
    Cc: curtis@occnc.com<= /a>, rtgwg@ietf.org=


    Dear Eric,
    Looks like we have not been clear in conveying= our=20 idea.
    =A0
    We abstract the power consumed by every router= /switch,=20 use it as the power rating. We then assign it to the link as a metric=20 characteristic to get algorithms like SPF
    and CSPF to choose the lowest power paths or a= ny metric=20 based routing algorithm.
    =A0
    So the link metric is a combination of power c= onsumed=20 including the physical link and router components. In effect the link metri= c is=20 not just the physical link=92s metric alone (but the cost of the power cons= umed by=20 the router/switch on which it connects to the neighbor).
    =A0
    Just like routing protocols consider delay, ho= ps as=20 metric we consider this power consumption as yet another metric.
    =A0
    Thanks
    Shankar
    =A0
    -----Original Message-----
    From: Balaji Venkat
    Sent: Thursday, February 07, 2013 2:36 AM
    To: Eric Osborne (eosborne)
    Cc: curtis@occnc.com ; Shankar Raman M J ; rtgwg@ietf.org
    Subject: Re: Power aware networks : Comments requested from routing=20 community
    =A0
    Dear Eric,
    =A0
    Comments inline...
    =A0
    Sent from my iPad
    =A0
    On 07-Feb-2013, at 1:50 AM, "Eric Osborne (eosborne)"=20 <eosborne@cisco.= com> wrote:
    =A0
    > You aim to optimize core networks through traffic engineering suc= h=20 that some links can be shut down when not in use, or switched to lower=20 power.
    =A0
    Actually the answer is a No. We do not advocate this approach. The mai= n=20 idea in bgp power path draft has a survey section on previous literature th= at we=20 quote for reference and state that such approaches cause expensive equipmen= t to=20 be kept unused. You have quoted the survey section of the paper in the abov= e=20 sentence.
    =A0
    >
    > Have you done studies in core networks with real equipment that s= how=20 the actual amount of money you could save with this approach?=A0 Let's = walk=20 through a quick hypothetical network, you tell me where I got it wrong.
    >
    > draft-mjsraman-panet-bgp-power-path says
    > " Power consumption can be
    >=A0=A0 reduced by trading off performance related measures like=20 latency. For
    >=A0=A0 example, power savings while switching from 1 Gbps to 100= =20 Mbps is
    >=A0=A0 approximately 4 W and from 100 Mbps to 10 Mbps around 0.1= =20 Watts."
    =A0
    Again this is a survey section of the paper surveying the existing=20 approaches.
    =A0
    >
    > but provides no documentation to back these costs up nor itemizat= ion=20 of where the power is consumed (amortized across the router?=A0 linecard=20 optics?=A0 DWDM gear?)
    =A0
    Our main intent is to allow traffic to follow low power paths through = ASs=20 (either through pce like entities or through modifying the bgp path selecti= on=20 algorithm) which consume the least power and possess the required bandwidth= . By=20 graphing the topology of a set ASs in the immediate neighbourhood using=20 as-path-info strands typically for a provider manning multiple ASs within t= he=20 providers own control this mechanism will let large chunks of traffic belon= ging=20 to a macro FEC traverse such low power ASs through an inter-as te MPLS lsp= =20 computed by a pce like entity and setup by RSVP-te.
    =A0
    The use of the metric, the way the pwr metric is arrived at , the=20 computation of the topology of ASs, consequent CSPF and then mapping the tr= affic=20 to the constructed LSP is the main focus if this paper. For dampening=20 fluctuations in the metric which are frequent heuristics algorithms are=20 suggested.
    =A0
    By no means are we advocating shutting off links. This scheme facilita= tes=20 even the follow the moon strategy naturally.
    =A0
    =A0
    >
    > Let's assume that this is true and that it is linear, so that= you burn=20 4W per Gb.=A0 (side note: I suspect this is inaccurate and that scaling is= =20 sublinear, but let's go with it because if it's sub-linear you have= even less of=20 a use case.=A0 I also think the real world is far more complex, as you have= =20 all the optical transport gear to worry about.=A0 But let's go with it = for=20 now.)
    >
    > Running a 100Gb link thus draws 400W.
    >
    > Let's say you have a backbone with (300) 100Gb links.=A0 Tota= l=20 power consumption is thus (300*400) =3D=3D 120 kW
    >
    > Running all these links for 24 hours thus draws 120*24 =3D=3D 2,8= 80=20 kWh=A0 =3D=3D 2.8mWh
    > Power costs are maybe $0.10/kWh in the US.=A0 Double that to cove= r=20 the cost of cooling, so $0.20/kWh.
    > Thus, running the entire backbone costs $0.2 * 2,880 =3D $576/day= .=A0=20 $210,000/year.
    > Let's say your approach can save one third of the power cost,= which=20 means about $70,000.
    >
    =A0
    =A0
    =A0
    > An operator with 300 100Gb links in a network has hundreds of mil= lions=20 of dollars worth of gear and millions or tens of millions in payroll=20 alone.=A0 If you cut $70k from their opex they probably wouldn't even= =20 notice.=A0 That's one or two salaries, or 0.002% of what Time Warner sp= ent on=20 advertising in 2006 (see:=20 http://gaia.adage.com/images/random/FactPack06.pdf).=A0 It is a d= rop in the=20 bucket, if that.=A0 And your proposal comes with significant work attached = to=20 it, and significant risk.=A0 If your 40 years of experience in the network= =20 industry don't help you understand the risks you're asking an opera= tor to take=20 then you're missing a crucial part of any potential real world solution= .=A0 I=20 do not think your work should be presented at the IETF unless it makes a mu= ch=20 stronger argument that its benefits outweigh its costs.
    =A0
    Again we are not asking the operator to shut off the equipment. He nee= ds to=20 keep it running as long as he has traffic to carry except that the pce make= s a=20 computation every time a large FEC of traffic needs to be carried through h= is=20 ASs through a path that consumes the least power with the links therein hav= ing=20 the required bandwidth. The ratio of consumed power to the available bandwi= dth=20 is the metric that is used. Consumed power relates to a weighted average of= the=20 power consumed within the AS including the edge and core devices while the= =20 available bw relates to the links ingressing into the AS at the ASBRs that = are=20 the inter connectors between the ASes.
    =A0
    =A0
    So in summary, we do not advocate shutting off links at all. In fact w= e=20 disagree with that approach. The scheme we advocate tries to optimise the p= ower=20 consumption using the metric based approach with some heuristics.
    =A0
    Hope this helps.
    =A0
    Thanks and regards,
    Balaji venkat
    >
    > These sorts of power optimizations all seem to be "here'= s how you=20 reshape the problem so that you can throw a linear problem solver at it&quo= t;.=A0=20 For example, [=20 http://www.cs.berkeley.edu/~suchara/publications/G= reenNetsBundles.pdf ].=A0=20 I've never seen anything which shows how much more work it will be for = a network=20 operator or which quantifies the actual savings.
    >
    > If you can demonstrate significant savings in real networks at li= ttle=20 or no cost to operators, you have an idea worth pursuing.=A0 If your idea= =20 will cause more operational angst (e.g. not knowing whether your unused cap= acity=20 will be there when you need it because you shut a third of it off all the t= ime,=20 increased risk of equipment failure from constant power-cycling, operationa= l=20 tools and training and expertise required to manage, deploy and troubleshoo= t=20 variable-power links and the centralized NMS required to run them, etc etc = etc)=20 then it will find little traction.=A0 Green-TE and power-aware BGP have bee= n=20 floating around for a while and have seen no real uptake in the WGs as far = as I=20 can see.=A0 Is that not to be taken as an indication that there may be no= =20 real-world interest in them?=A0 If not, what would it take to convince=20 you?
    >
    >
    >
    > eric
    >

    =
    --e89a8ff1c5b8722d7d04d521eae5-- From hannes@juniper.net Thu Feb 7 05:08:45 2013 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 F3D5621F85CE for ; Thu, 7 Feb 2013 05:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63ewJ-XMffRM for ; Thu, 7 Feb 2013 05:08:43 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 407A521F85F0 for ; Thu, 7 Feb 2013 05:08:43 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUROnW1wAOLBNTL/yKxt+TFrM2wF5sc8T@postini.com; Thu, 07 Feb 2013 05:08:43 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 7 Feb 2013 05:07:54 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 7 Feb 2013 05:07:54 -0800 Received: from CO9EHSOBE010.bigfish.com (207.46.163.27) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 7 Feb 2013 05:09:50 -0800 Received: from mail91-co9-R.bigfish.com (10.236.132.226) by CO9EHSOBE010.bigfish.com (10.236.130.73) with Microsoft SMTP Server id 14.1.225.23; Thu, 7 Feb 2013 13:07:53 +0000 Received: from mail91-co9 (localhost [127.0.0.1]) by mail91-co9-R.bigfish.com (Postfix) with ESMTP id 617B2B002C7 for ; Thu, 7 Feb 2013 13:07:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); (null); H:BLUPRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -20 X-BigFish: PS-20(zz98dI9371I1432I111aI98adlzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahz8dhz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1155h) Received: from mail91-co9 (localhost.localdomain [127.0.0.1]) by mail91-co9 (MessageSwitch) id 1360242470984254_29699; Thu, 7 Feb 2013 13:07:50 +0000 (UTC) Received: from CO9EHSMHS026.bigfish.com (unknown [10.236.132.251]) by mail91-co9.bigfish.com (Postfix) with ESMTP id E1A1E780056; Thu, 7 Feb 2013 13:07:50 +0000 (UTC) Received: from BLUPRD0512HT002.namprd05.prod.outlook.com (132.245.1.149) by CO9EHSMHS026.bigfish.com (10.236.130.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 7 Feb 2013 13:07:48 +0000 Received: from ktom-sslvpn-nc.jnpr.net (66.129.224.36) by pod51010.outlook.com (10.255.215.163) with Microsoft SMTP Server (TLS) id 14.16.263.1; Thu, 7 Feb 2013 13:07:45 +0000 Subject: Re: Power aware networks : Comments requested from routing community MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> Date: Thu, 7 Feb 2013 14:07:38 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: <72B40FF5-6A29-4857-93AA-768490A20903@juniper.net> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> To: Balaji venkat Venkataswami X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%OCCNC.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Shankar Raman M J , 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, 07 Feb 2013 13:08:45 -0000 balaji, may i put your attention to a talk that francois lemarchand gave on future net 2010. https://www.dropbox.com/s/3jb9au2zca4nl3x/10_fn_S29.pdf contains a copy. slide 2 initially shows that the core and edge layer might be appealing due to their per-box power print. however slide 15 discusses the big picture where 99.99% of the power is burned by the home appliances and subscriber line kit. Do you think that optimizing a part of the network which gives only = limited overall savings is a worthwhile goal ? Note that SPs already ask their = vendors about reducing the power footprint of those core devices by improved, = (sometimes less functional) silicon forwarding engines. /hannes On Feb 6, 2013, at 7:41 PM, Curtis Villamizar wrote: >=20 > Balaji, >=20 > "We" in the context of your first paragraph seems to be a > misrepresentation. The authors of all of these drafts seem to be from > the same university in India. =46rom prior attempts on your part to = get > a draft of this sort into IDR and a brief reading of a few of the > drafts that you have just submitted, you don't seem to have a good > understanding of how networks are built and how network equipment is > built from which to begin to attack the problem of reducing the power > consumption of these networks. >=20 > If you want to try to advance a research paper with your theories on > power reduction, please choose an appropriate venue such as a refereed > technical journal. >=20 > Curtis >=20 >=20 > In message = > Balaji venkat Venkataswami writes: >=20 >> Dear all, >>=20 >> We are a group of research and industry individuals tied together = with a >> common goal towards reducing the energy consumption in the core and = edge >> networks. >>=20 >> We present a metric-based hierarchical approach to reduce power = consumption >> in core and edge networks. The proposal considers both unicast and = the >> multicast cases. For unicast, the metric considered is = *consumed-power to >> available-bandwidth* and for multicast the metric is *consumed-power = to >> available-replication-capacity.* >>=20 >> With unicast, the metric is used to determine a low-power path = between >> sources and destinations. With multicast, the metric serves the twin >> purpose of finding low-power multicast paths as well as multicast >> replication points. We evolve multiple techniques at various = hierarchical >> levels. One at the Inter-AS level, Inter-Area level within the AS and >> intra-Area within an AS. Additionally, the proposed method can also = be used >> to determine disjoint or redundant paths for load balancing or fault >> tolerance. Additionally since TCAMs are one of the biggest power = guzzlers >> in all the components on a router/switch, we have presented a = solution for >> intra-AS purposes to use the TCAM according to the traffic matrix = passing >> through the system and shut down those TCAM banks that are unused. = With >> this in mind, we have also advocated taking into account a = TCAM-POWER-Ratio >> in order to compute the paths from source to destination based on = this >> metric. Once low-power paths, in either the unicast or the multicast = cases, >> are identified then currently available traffic engineering = techniques >> could be used to route the data packets. In the case of inter-AS BGP = path >> selection is also modified to arrive at paths which are low-power = paths. >>=20 >> Our main objective is as follows... >>=20 >> We now outline four important aspects that any approach for power = reduction >> should be capable of addressing. >>=20 >> *Should cater for both unicast and multicast scenarios* >>=20 >> Multicast provides an important scenario for the Internet. Today, = most >> proposals consider mainly low-power path routing with unicast = traffic. >> Multicast traffic has received a lot of attention in wireless = networks, but >> not in the wired domain. Any new proposal should be able to address = both >> the unicast and the multicast traffic scenarios. Having different = methods >> for these two scenarios might lead to unnecessary processing burden = in the >> routers, which might hinder its scalability. >>=20 >> *Should not rely on just switching off unused links* >>=20 >> Most approaches to optimize energy pursue the following approach: = measure, >> monitor and respond to the system energy usage by switching off = unused or >> under-utilized links. Such an approach could be effective for = reducing >> power locally. The effect on the network is not clearly understood. >> Further, the power usage involved in turning on and = rebooting/reconfiguring >> the device is often not explicitly considered. We note that Service = Level >> Agreement (SLA) requirements may not even permit the links to be = switched >> off. Also services provided by ISPs like Virtual Private Networks = (VPNs) >> can be affected by such re-routing decisions. >>=20 >> *Should follow an hierarchical and distributed approach* >>=20 >> For scalability, it is important that the algorithms proposed for = inter-AS >> should also be applicable to intra-AS situations. Networks do not = work in >> isolation, so any proposal should be both distributed and = hierarchical. The >> algorithms should be applicable at every level of the hierarchy. >>=20 >> *Should provide incentives for ISP for adoption* >>=20 >> The engineering proposals should be aligned with commercial = incentives for >> rapid and widespread adoption. Today, the device manufacturers and = the ISPs >> operate independently of each other, and there is no incentive for >> manufacturers to work towards low-power and high bandwidth devices. = An >> ISP=3D92s revenue model is based on the consumed bandwidth, which in = turn lea=3D >> d >> naturally to more power consumption. If the proposed method chooses = routers >> that consume low-power and increase the data flow through them, then = this >> indirectly provides encouragement for ISPs to purchase low-power and = high >> bandwidth devices. >>=20 >>=20 >>=20 >> We now present our metric-based proposals in the below mentioned = drafts >> which addresses the aforementioned design aspects. >>=20 >> We would like the routing community to provide feedback on these = drafts. We >> also intend to present this work in an abridged format in the = upcoming IETF=3D >> . >>=20 >> The drafts are as follows.... >>=20 >>=20 >>=20 >>=20 >> - = mjsraman-panet-bgp-power-path> n-panet-bgp-power-path> >> = (timeline)> p-power-path-timing.html> >> Inter-AS-Proposal >> - = mjsraman-panet-ecmp-redirect-power-repl-cap> /draft-mjsraman-panet-ecmp-redirect-power-repl-cap> >> = (timeline)> mp-redirect-power-repl-cap-timing.html> >> Multicast >> - = mjsraman-panet-inter-as-power-source> mjsraman-panet-inter-as-power-source> >> = (timeline)> ter-as-power-source-timing.html> >> Inter-AS >> Proposal >> - = mjsraman-panet-inter-as-psp> panet-inter-as-psp> >> = (timeline)> ter-as-psp-timing.html> >> Inter-AS >> Proposal >> - = mjsraman-panet-inter-as-psp-protect> jsraman-panet-inter-as-psp-protect> >> = (timeline)> ter-as-psp-protect-timing.html> >> Inter-AS >> Proposal >> - = mjsraman-panet-pce-power-mcast-replic> -mjsraman-panet-pce-power-mcast-replic> >> = (timeline)> e-power-mcast-replic-timing.html> >> Multicast >> - = mjsraman-panet-pim-power> et-pim-power> >> = (timeline)> m-power-timing.html> >> Multicast >> - = mjsraman-panet-tcam-power-efficiency> mjsraman-panet-tcam-power-efficiency> >> = (timeline)> am-power-efficiency-timing.html> >> TCAM >> related >> - = mjsraman-panet-tcam-power-ratio> man-panet-tcam-power-ratio> >> = (timeline> m-power-ratio-timing.html>) >> TCAM related >> - = mjsraman-pce-power-replic> e-power-replic> >> = (timeline)> r-replic-timing.html> >> Multicast >> - = mjsraman-panet-intra-as-psp-te-leak> jsraman-panet-intra-as-psp-te-leak> >> = (timeline)> tra-as-psp-te-leak-timing.html> >> Inter-Area >> within an AS >> - = mjsraman-panet-ospf-power-topo> an-panet-ospf-power-topo> >> = (timeline)> pf-power-topo-timing.html> >> Intra-Area >> within an AS >>=20 >> We understand it is a lot of matter to go through. We would much = appreciate >> if some of you could review the inter-AS proposals while others take = up >> multicast and Intra-AS unicast and multicast. >>=20 >> Thanks again for your time on this matter. >>=20 >> thanks and regards, >> balaji venkat > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg >=20 From balajivenkat299@gmail.com Thu Feb 7 05:52:56 2013 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 B59EA21F843E for ; Thu, 7 Feb 2013 05:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnlUFJ4a3WwH for ; Thu, 7 Feb 2013 05:52:48 -0800 (PST) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by ietfa.amsl.com (Postfix) with ESMTP id D305921F843C for ; Thu, 7 Feb 2013 05:52:47 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id 16so2698121obc.19 for ; Thu, 07 Feb 2013 05:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6t7PF6aDXyqhzTiF8toDWi9XxiBdyu7mQIknf/e6+Hk=; b=T2gUwKaaxtXJzReTvuN02+/mRja0FsOenLbSDM6ZWdXBMnd+SfnhRzJHoXyeyb9O69 EqAR5F5m/CyEV7JIaCgdefnBBV+0T4Hv7eO5p4asYDKAPcyqW+ATFY7VNxlGaesKBwVr F6hzWqVbf4GLQOJ1inBUVz0gyWk415XaKWnYSzQAe0EGsCWgoy6ZdvxCciBVOV2IbHUR nU+aaWlGAkvbwhP5GFhr0DwVf+siM250sonbcJFWWMHMRoYIiJNcStK3tr+Sh9uf7Pvh /umKylO/eOmfzhosJsC84BFkzlRWcZONZ6NyFrRVosUdMsygdQI78/GeMXxfdrJ2guHW PfjQ== MIME-Version: 1.0 X-Received: by 10.60.32.50 with SMTP id f18mr1046256oei.8.1360245166552; Thu, 07 Feb 2013 05:52:46 -0800 (PST) Received: by 10.60.93.8 with HTTP; Thu, 7 Feb 2013 05:52:46 -0800 (PST) In-Reply-To: <72B40FF5-6A29-4857-93AA-768490A20903@juniper.net> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <72B40FF5-6A29-4857-93AA-768490A20903@juniper.net> Date: Thu, 7 Feb 2013 19:22:46 +0530 Message-ID: Subject: Re: Power aware networks : Comments requested from routing community From: Balaji venkat Venkataswami To: Hannes Gredler Content-Type: multipart/alternative; boundary=e89a8fb1f820f5b4ff04d522c1f5 Cc: Shankar Raman M J , 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, 07 Feb 2013 13:52:56 -0000 --e89a8fb1f820f5b4ff04d522c1f5 Content-Type: text/plain; charset=ISO-8859-1 Dear Hannes, We are familiar with the presentation that you have referred to. I have 3 questions for you. a) While we agree with the presentation that you have mentioned, can we in the IETF have control over the home appliances and subscriber line kit ? Is there a methodology by which we can optimize the power consumption on these devices ? b) The problem space that the IETF can take up can be only in the edge and core devices in the ISP networks and the Campus/DC/Metro etc...Assume that I have n devices today with the same bandwidth offering but differing power consumption footprint, is there a way today to automatically send traffic through low power paths in the topology of these devices. c) So we can optimize power only on what we can control. What are your views on this ? thanks and regards, balaji venkat On Thu, Feb 7, 2013 at 6:37 PM, Hannes Gredler wrote: > balaji, > > may i put your attention to a talk that francois lemarchand > gave on future net 2010. > https://www.dropbox.com/s/3jb9au2zca4nl3x/10_fn_S29.pdf > contains a copy. > > slide 2 initially shows that the core and edge layer might be appealing > due to their per-box power print. however slide 15 discusses the > big picture where 99.99% of the power is burned by the home > appliances and subscriber line kit. > > Do you think that optimizing a part of the network which gives only limited > overall savings is a worthwhile goal ? Note that SPs already ask their > vendors > about reducing the power footprint of those core devices by improved, > (sometimes > less functional) silicon forwarding engines. > > /hannes > > On Feb 6, 2013, at 7:41 PM, Curtis Villamizar wrote: > > > > > Balaji, > > > > "We" in the context of your first paragraph seems to be a > > misrepresentation. The authors of all of these drafts seem to be from > > the same university in India. From prior attempts on your part to get > > a draft of this sort into IDR and a brief reading of a few of the > > drafts that you have just submitted, you don't seem to have a good > > understanding of how networks are built and how network equipment is > > built from which to begin to attack the problem of reducing the power > > consumption of these networks. > > > > If you want to try to advance a research paper with your theories on > > power reduction, please choose an appropriate venue such as a refereed > > technical journal. > > > > Curtis > > > > > > In message < > CAHF4apO9bEkPk7QwA9fgJq9BNUNHNv+OFon_9_4Oij61e11r9w@mail.gmail.com> > > Balaji venkat Venkataswami writes: > > > >> Dear all, > >> > >> We are a group of research and industry individuals tied together with a > >> common goal towards reducing the energy consumption in the core and edge > >> networks. > >> > >> We present a metric-based hierarchical approach to reduce power > consumption > >> in core and edge networks. The proposal considers both unicast and the > >> multicast cases. For unicast, the metric considered is *consumed-power > to > >> available-bandwidth* and for multicast the metric is *consumed-power to > >> available-replication-capacity.* > >> > >> With unicast, the metric is used to determine a low-power path between > >> sources and destinations. With multicast, the metric serves the twin > >> purpose of finding low-power multicast paths as well as multicast > >> replication points. We evolve multiple techniques at various > hierarchical > >> levels. One at the Inter-AS level, Inter-Area level within the AS and > >> intra-Area within an AS. Additionally, the proposed method can also be > used > >> to determine disjoint or redundant paths for load balancing or fault > >> tolerance. Additionally since TCAMs are one of the biggest power > guzzlers > >> in all the components on a router/switch, we have presented a solution > for > >> intra-AS purposes to use the TCAM according to the traffic matrix > passing > >> through the system and shut down those TCAM banks that are unused. With > >> this in mind, we have also advocated taking into account a > TCAM-POWER-Ratio > >> in order to compute the paths from source to destination based on this > >> metric. Once low-power paths, in either the unicast or the multicast > cases, > >> are identified then currently available traffic engineering techniques > >> could be used to route the data packets. In the case of inter-AS BGP > path > >> selection is also modified to arrive at paths which are low-power paths. > >> > >> Our main objective is as follows... > >> > >> We now outline four important aspects that any approach for power > reduction > >> should be capable of addressing. > >> > >> *Should cater for both unicast and multicast scenarios* > >> > >> Multicast provides an important scenario for the Internet. Today, most > >> proposals consider mainly low-power path routing with unicast traffic. > >> Multicast traffic has received a lot of attention in wireless networks, > but > >> not in the wired domain. Any new proposal should be able to address both > >> the unicast and the multicast traffic scenarios. Having different > methods > >> for these two scenarios might lead to unnecessary processing burden in > the > >> routers, which might hinder its scalability. > >> > >> *Should not rely on just switching off unused links* > >> > >> Most approaches to optimize energy pursue the following approach: > measure, > >> monitor and respond to the system energy usage by switching off unused > or > >> under-utilized links. Such an approach could be effective for reducing > >> power locally. The effect on the network is not clearly understood. > >> Further, the power usage involved in turning on and > rebooting/reconfiguring > >> the device is often not explicitly considered. We note that Service > Level > >> Agreement (SLA) requirements may not even permit the links to be > switched > >> off. Also services provided by ISPs like Virtual Private Networks (VPNs) > >> can be affected by such re-routing decisions. > >> > >> *Should follow an hierarchical and distributed approach* > >> > >> For scalability, it is important that the algorithms proposed for > inter-AS > >> should also be applicable to intra-AS situations. Networks do not work > in > >> isolation, so any proposal should be both distributed and hierarchical. > The > >> algorithms should be applicable at every level of the hierarchy. > >> > >> *Should provide incentives for ISP for adoption* > >> > >> The engineering proposals should be aligned with commercial incentives > for > >> rapid and widespread adoption. Today, the device manufacturers and the > ISPs > >> operate independently of each other, and there is no incentive for > >> manufacturers to work towards low-power and high bandwidth devices. An > >> ISP=92s revenue model is based on the consumed bandwidth, which in turn > lea= > >> d > >> naturally to more power consumption. If the proposed method chooses > routers > >> that consume low-power and increase the data flow through them, then > this > >> indirectly provides encouragement for ISPs to purchase low-power and > high > >> bandwidth devices. > >> > >> > >> > >> We now present our metric-based proposals in the below mentioned drafts > >> which addresses the aforementioned design aspects. > >> > >> We would like the routing community to provide feedback on these > drafts. We > >> also intend to present this work in an abridged format in the upcoming > IETF= > >> . > >> > >> The drafts are as follows.... > >> > >> > >> > >> > >> - mjsraman-panet-bgp-power-path< > http://tools.ietf.org/html/draft-mjsrama= > >> n-panet-bgp-power-path> > >> (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-bg= > >> p-power-path-timing.html> > >> Inter-AS-Proposal > >> - mjsraman-panet-ecmp-redirect-power-repl-cap< > http://tools.ietf.org/html= > >> /draft-mjsraman-panet-ecmp-redirect-power-repl-cap> > >> (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-ec= > >> mp-redirect-power-repl-cap-timing.html> > >> Multicast > >> - mjsraman-panet-inter-as-power-source< > http://tools.ietf.org/html/draft-= > >> mjsraman-panet-inter-as-power-source> > >> (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in= > >> ter-as-power-source-timing.html> > >> Inter-AS > >> Proposal > >> - mjsraman-panet-inter-as-psp< > http://tools.ietf.org/html/draft-mjsraman-= > >> panet-inter-as-psp> > >> (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in= > >> ter-as-psp-timing.html> > >> Inter-AS > >> Proposal > >> - mjsraman-panet-inter-as-psp-protect< > http://tools.ietf.org/html/draft-m= > >> jsraman-panet-inter-as-psp-protect> > >> (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in= > >> ter-as-psp-protect-timing.html> > >> Inter-AS > >> Proposal > >> - mjsraman-panet-pce-power-mcast-replic< > http://tools.ietf.org/html/draft= > >> -mjsraman-panet-pce-power-mcast-replic> > >> (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-pc= > >> e-power-mcast-replic-timing.html> > >> Multicast > >> - mjsraman-panet-pim-power< > http://tools.ietf.org/html/draft-mjsraman-pan= > >> et-pim-power> > >> (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-pi= > >> m-power-timing.html> > >> Multicast > >> - mjsraman-panet-tcam-power-efficiency< > http://tools.ietf.org/html/draft-= > >> mjsraman-panet-tcam-power-efficiency> > >> (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-tc= > >> am-power-efficiency-timing.html> > >> TCAM > >> related > >> - mjsraman-panet-tcam-power-ratio< > http://tools.ietf.org/html/draft-mjsra= > >> man-panet-tcam-power-ratio> > >> (timeline< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-tca= > >> m-power-ratio-timing.html>) > >> TCAM related > >> - mjsraman-pce-power-replic< > http://tools.ietf.org/html/draft-mjsraman-pc= > >> e-power-replic> > >> (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-pce-powe= > >> r-replic-timing.html> > >> Multicast > >> - mjsraman-panet-intra-as-psp-te-leak< > http://tools.ietf.org/html/draft-m= > >> jsraman-panet-intra-as-psp-te-leak> > >> (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in= > >> tra-as-psp-te-leak-timing.html> > >> Inter-Area > >> within an AS > >> - mjsraman-panet-ospf-power-topo< > http://tools.ietf.org/html/draft-mjsram= > >> an-panet-ospf-power-topo> > >> (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-os= > >> pf-power-topo-timing.html> > >> Intra-Area > >> within an AS > >> > >> We understand it is a lot of matter to go through. We would much > appreciate > >> if some of you could review the inter-AS proposals while others take up > >> multicast and Intra-AS unicast and multicast. > >> > >> Thanks again for your time on this matter. > >> > >> thanks and regards, > >> balaji venkat > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > > --e89a8fb1f820f5b4ff04d522c1f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Hannes,

    We are familiar with the presentation that = you have referred to.

    I have 3 questions for you.<= /div>

    a) While we agree with the presentation that you h= ave mentioned, can we in the IETF have control over the home appliances and= subscriber line kit ? Is there a methodology by which we can optimize the = power consumption on these devices ?

    b) The problem space that the IETF can take up can be o= nly in the edge and core devices in the ISP networks and the Campus/DC/Metr= o etc...Assume that I have n devices today with the same bandwidth offering= but differing power consumption
    footprint, is there a way today to automatically send traffic through = low power paths in the topology of these devices.

    = c) So we can optimize power only on what we can control. What are your view= s on this ?

    thanks and regards,
    balaji venkat=A0

    On Thu, Feb 7, 2013 at 6:37 PM, Hannes Gre= dler <hannes@juniper.net> wrote:
    balaji,

    may i put your attention to a talk that =A0francois lemarchand
    gave on future net 2010.
    https://www.dropbox.com/s/3jb9au2zca4nl3x/10_fn_S29.pdf
    contains a copy.

    slide 2 initially shows that the core and edge layer might be appealing
    due to their per-box power print. however slide 15 discusses the
    big picture where 99.99% of the power is burned by the home
    appliances and subscriber line kit.

    Do you think that optimizing a part of the network which gives only limited=
    overall savings is a worthwhile goal ? Note that SPs already ask their vend= ors
    about reducing the power footprint of those core devices by improved, (some= times
    less functional) silicon forwarding engines.

    /hannes

    On Feb 6, 2013, at 7:41 PM, Curtis Villamizar wrote:

    >
    > Balaji,
    >
    > "We" in the context of your first paragraph seems to be a > misrepresentation. =A0The authors of all of these drafts seem to be fr= om
    > the same university in India. =A0From prior attempts on your part to g= et
    > a draft of this sort into IDR and a brief reading of a few of the
    > drafts that you have just submitted, you don't seem to have a good=
    > understanding of how networks are built and how network equipment is > built from which to begin to attack the problem of reducing the power<= br> > consumption of these networks.
    >
    > If you want to try to advance a research paper with your theories on > power reduction, please choose an appropriate venue such as a refereed=
    > technical journal.
    >
    > Curtis
    >
    >
    > In message <CAHF4apO9bEkPk7QwA9fgJq9BNUNHNv+OFon_9_4Oi= j61e11r9w@mail.gmail.com>
    > Balaji venkat Venkataswami writes:
    >
    >> Dear all,
    >>
    >> We are a group of research and industry individuals tied together = with a
    >> common goal towards reducing the energy consumption in the core an= d edge
    >> networks.
    >>
    >> We present a metric-based hierarchical approach to reduce power co= nsumption
    >> in core and edge networks. The proposal considers both unicast and= the
    >> multicast cases. For unicast, the metric considered is *consumed-p= ower to
    >> available-bandwidth* and for multicast the metric is *consumed-pow= er to
    >> available-replication-capacity.*
    >>
    >> With unicast, the metric is used to determine a low-power path bet= ween
    >> sources and destinations. With multicast, the metric serves the tw= in
    >> purpose of finding low-power multicast paths as well as multicast<= br> >> replication points. =A0We evolve multiple techniques at various hi= erarchical
    >> levels. One at the Inter-AS level, Inter-Area level within the AS = and
    >> intra-Area within an AS. Additionally, the proposed method can als= o be used
    >> to determine disjoint or redundant paths for load balancing or fau= lt
    >> tolerance. Additionally since TCAMs are one of the biggest power g= uzzlers
    >> in all the components on a router/switch, we have presented a solu= tion for
    >> intra-AS purposes to use the TCAM according to the traffic matrix = passing
    >> through the system and shut down those TCAM banks that are unused.= With
    >> this in mind, we have also advocated taking into account a TCAM-PO= WER-Ratio
    >> in order to compute the paths from source to destination based on = this
    >> metric. Once low-power paths, in either the unicast or the multica= st cases,
    >> are identified then currently available traffic engineering techni= ques
    >> could be used to route the data packets. In the case of inter-AS B= GP path
    >> selection is also modified to arrive at paths which are low-power = paths.
    >>
    >> Our main objective is as follows...
    >>
    >> We now outline four important aspects that any approach for power = reduction
    >> should be capable of addressing.
    >>
    >> *Should cater for both unicast and multicast scenarios*
    >>
    >> Multicast provides an important scenario for the Internet. Today, = most
    >> proposals consider mainly low-power path routing with unicast traf= fic.
    >> Multicast traffic has received a lot of attention in wireless netw= orks, but
    >> not in the wired domain. Any new proposal should be able to addres= s both
    >> the unicast and the multicast traffic scenarios. Having different = methods
    >> for these two scenarios might lead to unnecessary processing burde= n in the
    >> routers, which might hinder its scalability.
    >>
    >> *Should not rely on just switching off unused links*
    >>
    >> Most approaches to optimize energy pursue the following approach: = measure,
    >> monitor and respond to the system energy usage by switching off un= used or
    >> under-utilized links. Such an approach could be effective for redu= cing
    >> power locally. The effect on the network is not clearly understood= .
    >> Further, the power usage involved in turning on and rebooting/reco= nfiguring
    >> the device is often not explicitly considered. We note that Servic= e Level
    >> Agreement (SLA) requirements may not even permit the links to be s= witched
    >> off. Also services provided by ISPs like Virtual Private Networks = (VPNs)
    >> can be affected by such re-routing decisions.
    >>
    >> *Should follow an hierarchical and distributed approach*
    >>
    >> For scalability, it is important that the algorithms proposed for = inter-AS
    >> should also be applicable to intra-AS situations. Networks do not = work in
    >> isolation, so any proposal should be both distributed and hierarch= ical. The
    >> algorithms should be applicable at every level of the hierarchy. >>
    >> *Should =A0provide incentives for ISP for adoption*
    >>
    >> The engineering proposals should be aligned with commercial incent= ives for
    >> rapid and widespread adoption. Today, the device manufacturers and= the ISPs
    >> operate independently of each other, and there is no incentive for=
    >> manufacturers to work towards low-power and high bandwidth devices= . An
    >> ISP=3D92s revenue model is based on the consumed bandwidth, which = in turn lea=3D
    >> d
    >> naturally to more power consumption. If the proposed method choose= s routers
    >> that consume low-power and increase the data flow through them, th= en this
    >> indirectly provides encouragement for ISPs to purchase low-power a= nd high
    >> bandwidth devices.
    >>
    >>
    >>
    >> We now present our metric-based proposals in the below mentioned d= rafts
    >> which addresses the aforementioned design aspects.
    >>
    >> We would like the routing community to provide feedback on these d= rafts. We
    >> also intend to present this work in an abridged format in the upco= ming IETF=3D
    >> .
    >>
    >> The drafts are as follows....
    >>
    >>
    >>
    >>
    >> =A0 - mjsraman-panet-bgp-power-path<http://tools.ietf.org/html/d= raft-mjsrama=3D
    >> n-panet-bgp-power-path>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-bg=3D
    >> p-power-path-timing.html>
    >> =A0 =A0Inter-AS-Proposal
    >> =A0 - mjsraman-panet-ecmp-redirect-power-repl-cap<http://tools.ietf.org/html= =3D
    >> /draft-mjsraman-panet-ecmp-redirect-power-repl-cap>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-ec=3D
    >> mp-redirect-power-repl-cap-timing.html>
    >> =A0 =A0Multicast
    >> =A0 - mjsraman-panet-inter-as-power-source<http://tools.ietf.org/html/d= raft-=3D
    >> mjsraman-panet-inter-as-power-source>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-in=3D
    >> ter-as-power-source-timing.html>
    >> Inter-AS
    >> =A0 Proposal
    >> =A0 - mjsraman-panet-inter-as-psp<http://tools.ietf.org/html/d= raft-mjsraman-=3D
    >> panet-inter-as-psp>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-in=3D
    >> ter-as-psp-timing.html>
    >> Inter-AS
    >> =A0 Proposal
    >> =A0 - mjsraman-panet-inter-as-psp-protect<http://tools.ietf.org/html/d= raft-m=3D
    >> jsraman-panet-inter-as-psp-protect>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-in=3D
    >> ter-as-psp-protect-timing.html>
    >> Inter-AS
    >> =A0 Proposal
    >> =A0 - mjsraman-panet-pce-power-mcast-replic<http://tools.ietf.org/html/d= raft=3D
    >> -mjsraman-panet-pce-power-mcast-replic>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-pc=3D
    >> e-power-mcast-replic-timing.html>
    >> =A0 =A0Multicast
    >> =A0 - mjsraman-panet-pim-power<http://tools.ietf.org/html/d= raft-mjsraman-pan=3D
    >> et-pim-power>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-pi=3D
    >> m-power-timing.html>
    >> =A0 =A0Multicast
    >> =A0 - mjsraman-panet-tcam-power-efficiency<http://tools.ietf.org/html/d= raft-=3D
    >> mjsraman-panet-tcam-power-efficiency>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-tc=3D
    >> am-power-efficiency-timing.html>
    >> TCAM
    >> =A0 related
    >> =A0 - mjsraman-panet-tcam-power-ratio<http://tools.ietf.org/html/d= raft-mjsra=3D
    >> man-panet-tcam-power-ratio>
    >> =A0 =A0(timeline<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-tca=3D
    >> m-power-ratio-timing.html>)
    >> =A0 TCAM related
    >> =A0 - mjsraman-pce-power-replic<http://tools.ietf.org/html/d= raft-mjsraman-pc=3D
    >> e-power-replic>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-pce-powe=3D
    >> r-replic-timing.html>
    >> =A0 =A0Multicast
    >> =A0 - mjsraman-panet-intra-as-psp-te-leak<http://tools.ietf.org/html/d= raft-m=3D
    >> jsraman-panet-intra-as-psp-te-leak>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-in=3D
    >> tra-as-psp-te-leak-timing.html>
    >> Inter-Area
    >> =A0 within an AS
    >> =A0 - mjsraman-panet-ospf-power-topo<http://tools.ietf.org/html/d= raft-mjsram=3D
    >> an-panet-ospf-power-topo>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-os=3D
    >> pf-power-topo-timing.html>
    >> Intra-Area
    >> =A0 within an AS
    >>
    >> We understand it is a lot of matter to go through. We would much a= ppreciate
    >> if some of you could review the inter-AS proposals while others ta= ke up
    >> multicast and Intra-AS unicast and multicast.
    >>
    >> Thanks again for your time on this matter.
    >>
    >> thanks and regards,
    >> balaji venkat
    > __________________= _____________________________
    > rtgwg mailing list
    > rtgwg@ietf.org
    > https://www.ietf.org/mailman/listinfo/rtgwg
    >



    --e89a8fb1f820f5b4ff04d522c1f5-- From aretana@cisco.com Thu Feb 7 06:12:10 2013 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 A0B7021F86CC for ; Thu, 7 Feb 2013 06:12:10 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLIstCh7QL8G for ; Thu, 7 Feb 2013 06:12:10 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C462B21F855F for ; Thu, 7 Feb 2013 06:12:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1848; q=dns/txt; s=iport; t=1360246330; x=1361455930; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=fn4HMcz9SIx/8zpQ0yGUxxwtAQbz0co8wi0lZBAhMwU=; b=YCwngaJvHP/N5DggKUwB33LwyhV08117fwLpIAhWWEtomfh/kyghv52p Ue8dcqeryZy5fZ5fpIgKhfenEHg2m5Evgwc/RHBmDZQXsGLX99DFADtJt shlasf92HENUEcaXfmbohdHKoBrmnlBLoSHOYfDBpWn6XPr1oWexFDFft Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALm1E1GtJV2Y/2dsb2JhbABFwGYWc4IfAQEBBDo0HQEIIhQFPRQHAQYDAgQTCIgJDJ1LoS2Qe2EDlz6PNYMAgiQ X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; d="scan'208";a="174468771" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 07 Feb 2013 14:12:02 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r17EC2WW004497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 7 Feb 2013 14:12:02 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.174]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 08:12:02 -0600 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: FW: Last Call: (Depth-First Forwarding in Unreliable Networks (DFF)) to Experimental RFC Thread-Topic: Last Call: (Depth-First Forwarding in Unreliable Networks (DFF)) to Experimental RFC Thread-Index: AQHOBT0ZmIN+ktGCFEWAdLHIfIbqJw== Date: Thu, 7 Feb 2013 14:12:01 +0000 Message-ID: In-Reply-To: <20130207132146.18387.62853.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.130.203] Content-Type: text/plain; charset="us-ascii" Content-ID: <9849E02D250B0140B19CF555B175CA52@cisco.com> 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, 07 Feb 2013 14:12:10 -0000 FYI This work was presented in rtgwg a few meetings ago, so it might be interesting. Alvaro. On 2/7/13 8:21 AM, "The IESG" wrote: > >The IESG has received a request from an individual submitter to consider >the following document: >- 'Depth-First Forwarding in Unreliable Networks (DFF)' > as Experimental RFC > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2013-02-24. Exceptionally, comments may be >sent to iesg@ietf.org instead. In either case, please retain the >beginning of the Subject line to allow automated sorting. > >Abstract > > > This document specifies the "Depth-First Forwarding" (DFF) protocol > for IPv6 networks, a data forwarding mechanism that can increase > reliability of data delivery in networks with dynamic topology and/or > lossy links. The protocol operates entirely on the forwarding plane, > but may interact with the routing plane. DFF forwards data packets > using a mechanism similar to a "depth-first search" for the > destination of a packet. The routing plane may be informed of > failures to deliver a packet or loops. This document specifies the > DFF mechanism both for IPv6 networks (as specified in RFC2460) and in > addition also for LoWPAN "mesh-under" networks (as specified in > RFC4944). > > > > >The file can be obtained via >http://datatracker.ietf.org/doc/draft-cardenas-dff/ > >IESG discussion can be tracked via >http://datatracker.ietf.org/doc/draft-cardenas-dff/ballot/ > > >The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/1645/ > http://datatracker.ietf.org/ipr/1646/ > > > From tnadeau@lucidvision.com Thu Feb 7 07:06:16 2013 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 200D621F84F2 for ; Thu, 7 Feb 2013 07:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AY8CoH-PMQw for ; Thu, 7 Feb 2013 07:06:14 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id AC26921F84E6 for ; Thu, 7 Feb 2013 07:06:13 -0800 (PST) Received: from [172.28.133.199] (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 62E8423E8806; Thu, 7 Feb 2013 10:06:07 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3B1AC8E0-60EB-4F70-9328-5613C9E4065F" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Power aware networks : Comments requested from routing community From: Thomas Nadeau In-Reply-To: Date: Thu, 7 Feb 2013 07:06:07 -0800 Message-Id: <540411EE-A351-4AB6-A5B7-10D2D66062D0@lucidvision.com> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <72B40FF5-6A29-4857-93AA-768490A20903@juniper.net> To: Balaji venkat Venkataswami X-Mailer: Apple Mail (2.1499) Cc: Shankar Raman M J , 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, 07 Feb 2013 15:06:16 -0000 --Apple-Mail=_3B1AC8E0-60EB-4F70-9328-5613C9E4065F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 The other problem with this (frankly naive approach which has = been investigated by many) is that yes, while adding in another = constraint to the metric computation, it may result in unexpected = consequences. This is why it is likely to be more suitable as an IRTF = topic of research until those "details" are sorted out.=20 --Tom On Feb 7, 2013:5:52 AM, at 5:52 AM, Balaji venkat Venkataswami = wrote: > Dear Hannes, >=20 > We are familiar with the presentation that you have referred to. >=20 > I have 3 questions for you. >=20 > a) While we agree with the presentation that you have mentioned, can = we in the IETF have control over the home appliances and subscriber line = kit ? Is there a methodology by which we can optimize the power = consumption on these devices ? >=20 > b) The problem space that the IETF can take up can be only in the edge = and core devices in the ISP networks and the Campus/DC/Metro = etc...Assume that I have n devices today with the same bandwidth = offering but differing power consumption > footprint, is there a way today to automatically send traffic through = low power paths in the topology of these devices. >=20 > c) So we can optimize power only on what we can control. What are your = views on this ? >=20 > thanks and regards, > balaji venkat=20 >=20 > On Thu, Feb 7, 2013 at 6:37 PM, Hannes Gredler = wrote: > balaji, >=20 > may i put your attention to a talk that francois lemarchand > gave on future net 2010. > https://www.dropbox.com/s/3jb9au2zca4nl3x/10_fn_S29.pdf > contains a copy. >=20 > slide 2 initially shows that the core and edge layer might be = appealing > due to their per-box power print. however slide 15 discusses the > big picture where 99.99% of the power is burned by the home > appliances and subscriber line kit. >=20 > Do you think that optimizing a part of the network which gives only = limited > overall savings is a worthwhile goal ? Note that SPs already ask their = vendors > about reducing the power footprint of those core devices by improved, = (sometimes > less functional) silicon forwarding engines. >=20 > /hannes >=20 > On Feb 6, 2013, at 7:41 PM, Curtis Villamizar wrote: >=20 > > > > Balaji, > > > > "We" in the context of your first paragraph seems to be a > > misrepresentation. The authors of all of these drafts seem to be = from > > the same university in India. =46rom prior attempts on your part to = get > > a draft of this sort into IDR and a brief reading of a few of the > > drafts that you have just submitted, you don't seem to have a good > > understanding of how networks are built and how network equipment is > > built from which to begin to attack the problem of reducing the = power > > consumption of these networks. > > > > If you want to try to advance a research paper with your theories on > > power reduction, please choose an appropriate venue such as a = refereed > > technical journal. > > > > Curtis > > > > > > In message = > > Balaji venkat Venkataswami writes: > > > >> Dear all, > >> > >> We are a group of research and industry individuals tied together = with a > >> common goal towards reducing the energy consumption in the core and = edge > >> networks. > >> > >> We present a metric-based hierarchical approach to reduce power = consumption > >> in core and edge networks. The proposal considers both unicast and = the > >> multicast cases. For unicast, the metric considered is = *consumed-power to > >> available-bandwidth* and for multicast the metric is = *consumed-power to > >> available-replication-capacity.* > >> > >> With unicast, the metric is used to determine a low-power path = between > >> sources and destinations. With multicast, the metric serves the = twin > >> purpose of finding low-power multicast paths as well as multicast > >> replication points. We evolve multiple techniques at various = hierarchical > >> levels. One at the Inter-AS level, Inter-Area level within the AS = and > >> intra-Area within an AS. Additionally, the proposed method can also = be used > >> to determine disjoint or redundant paths for load balancing or = fault > >> tolerance. Additionally since TCAMs are one of the biggest power = guzzlers > >> in all the components on a router/switch, we have presented a = solution for > >> intra-AS purposes to use the TCAM according to the traffic matrix = passing > >> through the system and shut down those TCAM banks that are unused. = With > >> this in mind, we have also advocated taking into account a = TCAM-POWER-Ratio > >> in order to compute the paths from source to destination based on = this > >> metric. Once low-power paths, in either the unicast or the = multicast cases, > >> are identified then currently available traffic engineering = techniques > >> could be used to route the data packets. In the case of inter-AS = BGP path > >> selection is also modified to arrive at paths which are low-power = paths. > >> > >> Our main objective is as follows... > >> > >> We now outline four important aspects that any approach for power = reduction > >> should be capable of addressing. > >> > >> *Should cater for both unicast and multicast scenarios* > >> > >> Multicast provides an important scenario for the Internet. Today, = most > >> proposals consider mainly low-power path routing with unicast = traffic. > >> Multicast traffic has received a lot of attention in wireless = networks, but > >> not in the wired domain. Any new proposal should be able to address = both > >> the unicast and the multicast traffic scenarios. Having different = methods > >> for these two scenarios might lead to unnecessary processing burden = in the > >> routers, which might hinder its scalability. > >> > >> *Should not rely on just switching off unused links* > >> > >> Most approaches to optimize energy pursue the following approach: = measure, > >> monitor and respond to the system energy usage by switching off = unused or > >> under-utilized links. Such an approach could be effective for = reducing > >> power locally. The effect on the network is not clearly understood. > >> Further, the power usage involved in turning on and = rebooting/reconfiguring > >> the device is often not explicitly considered. We note that Service = Level > >> Agreement (SLA) requirements may not even permit the links to be = switched > >> off. Also services provided by ISPs like Virtual Private Networks = (VPNs) > >> can be affected by such re-routing decisions. > >> > >> *Should follow an hierarchical and distributed approach* > >> > >> For scalability, it is important that the algorithms proposed for = inter-AS > >> should also be applicable to intra-AS situations. Networks do not = work in > >> isolation, so any proposal should be both distributed and = hierarchical. The > >> algorithms should be applicable at every level of the hierarchy. > >> > >> *Should provide incentives for ISP for adoption* > >> > >> The engineering proposals should be aligned with commercial = incentives for > >> rapid and widespread adoption. Today, the device manufacturers and = the ISPs > >> operate independently of each other, and there is no incentive for > >> manufacturers to work towards low-power and high bandwidth devices. = An > >> ISP=3D92s revenue model is based on the consumed bandwidth, which = in turn lea=3D > >> d > >> naturally to more power consumption. If the proposed method chooses = routers > >> that consume low-power and increase the data flow through them, = then this > >> indirectly provides encouragement for ISPs to purchase low-power = and high > >> bandwidth devices. > >> > >> > >> > >> We now present our metric-based proposals in the below mentioned = drafts > >> which addresses the aforementioned design aspects. > >> > >> We would like the routing community to provide feedback on these = drafts. We > >> also intend to present this work in an abridged format in the = upcoming IETF=3D > >> . > >> > >> The drafts are as follows.... > >> > >> > >> > >> > >> - = mjsraman-panet-bgp-power-path >> n-panet-bgp-power-path> > >> = (timeline) >> p-power-path-timing.html> > >> Inter-AS-Proposal > >> - = mjsraman-panet-ecmp-redirect-power-repl-cap >> /draft-mjsraman-panet-ecmp-redirect-power-repl-cap> > >> = (timeline) >> mp-redirect-power-repl-cap-timing.html> > >> Multicast > >> - = mjsraman-panet-inter-as-power-source >> mjsraman-panet-inter-as-power-source> > >> = (timeline) >> ter-as-power-source-timing.html> > >> Inter-AS > >> Proposal > >> - = mjsraman-panet-inter-as-psp >> panet-inter-as-psp> > >> = (timeline) >> ter-as-psp-timing.html> > >> Inter-AS > >> Proposal > >> - = mjsraman-panet-inter-as-psp-protect >> jsraman-panet-inter-as-psp-protect> > >> = (timeline) >> ter-as-psp-protect-timing.html> > >> Inter-AS > >> Proposal > >> - = mjsraman-panet-pce-power-mcast-replic >> -mjsraman-panet-pce-power-mcast-replic> > >> = (timeline) >> e-power-mcast-replic-timing.html> > >> Multicast > >> - = mjsraman-panet-pim-power >> et-pim-power> > >> = (timeline) >> m-power-timing.html> > >> Multicast > >> - = mjsraman-panet-tcam-power-efficiency >> mjsraman-panet-tcam-power-efficiency> > >> = (timeline) >> am-power-efficiency-timing.html> > >> TCAM > >> related > >> - = mjsraman-panet-tcam-power-ratio >> man-panet-tcam-power-ratio> > >> = (timeline >> m-power-ratio-timing.html>) > >> TCAM related > >> - = mjsraman-pce-power-replic >> e-power-replic> > >> = (timeline) >> r-replic-timing.html> > >> Multicast > >> - = mjsraman-panet-intra-as-psp-te-leak >> jsraman-panet-intra-as-psp-te-leak> > >> = (timeline) >> tra-as-psp-te-leak-timing.html> > >> Inter-Area > >> within an AS > >> - = mjsraman-panet-ospf-power-topo >> an-panet-ospf-power-topo> > >> = (timeline) >> pf-power-topo-timing.html> > >> Intra-Area > >> within an AS > >> > >> We understand it is a lot of matter to go through. We would much = appreciate > >> if some of you could review the inter-AS proposals while others = take up > >> multicast and Intra-AS unicast and multicast. > >> > >> Thanks again for your time on this matter. > >> > >> thanks and regards, > >> balaji venkat > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > > >=20 >=20 >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg --Apple-Mail=_3B1AC8E0-60EB-4F70-9328-5613C9E4065F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 = The other problem with this (frankly naive approach which = has been investigated by many) is that yes, while adding in another = constraint to the metric computation, it may result in unexpected = consequences.    This is why it is likely to be more suitable = as an IRTF topic of research until those "details" are sorted = out. 

    = --Tom


    On Feb 7, 2013:5:52 = AM, at 5:52 AM, Balaji venkat Venkataswami <balajivenkat299@gmail.com>= ; wrote:

    Dear Hannes,

    We are familiar with the = presentation that you have referred to.

    I have = 3 questions for you.

    a) While we agree with the = presentation that you have mentioned, can we in the IETF have control = over the home appliances and subscriber line kit ? Is there a = methodology by which we can optimize the power consumption on these = devices ?

    b) The problem space that the IETF can take up can = be only in the edge and core devices in the ISP networks and the = Campus/DC/Metro etc...Assume that I have n devices today with the same = bandwidth offering but differing power consumption
    footprint, is there a way today to automatically send traffic = through low power paths in the topology of these = devices.

    c) So we can optimize power only on = what we can control. What are your views on this ?

    thanks and regards,
    balaji = venkat 

    On Thu, Feb 7, = 2013 at 6:37 PM, Hannes Gredler <hannes@juniper.net> wrote:
    balaji,

    may i put your attention to a talk that  francois lemarchand
    gave on future net 2010.
    https://www.dropbox.com/s/3jb9au2zca4nl3x/10_fn_S29.pdf<= /a>
    contains a copy.

    slide 2 initially shows that the core and edge layer might be = appealing
    due to their per-box power print. however slide 15 discusses the
    big picture where 99.99% of the power is burned by the home
    appliances and subscriber line kit.

    Do you think that optimizing a part of the network which gives only = limited
    overall savings is a worthwhile goal ? Note that SPs already ask their = vendors
    about reducing the power footprint of those core devices by improved, = (sometimes
    less functional) silicon forwarding engines.

    /hannes

    On Feb 6, 2013, at 7:41 PM, Curtis Villamizar wrote:

    >
    > Balaji,
    >
    > "We" in the context of your first paragraph seems to be a
    > misrepresentation.  The authors of all of these drafts seem to = be from
    > the same university in India.  =46rom prior attempts on your = part to get
    > a draft of this sort into IDR and a brief reading of a few of = the
    > drafts that you have just submitted, you don't seem to have a = good
    > understanding of how networks are built and how network equipment = is
    > built from which to begin to attack the problem of reducing the = power
    > consumption of these networks.
    >
    > If you want to try to advance a research paper with your theories = on
    > power reduction, please choose an appropriate venue such as a = refereed
    > technical journal.
    >
    > Curtis
    >
    >
    > In message <    CAHF4apO9bEkPk7QwA9fgJq9BNUNHNv+OFon_9_4Oij61e11r9w@mail.gmail.= com>
    > Balaji venkat Venkataswami writes:
    >
    >> Dear all,
    >>
    >> We are a group of research and industry individuals tied = together with a
    >> common goal towards reducing the energy consumption in the core = and edge
    >> networks.
    >>
    >> We present a metric-based hierarchical approach to reduce power = consumption
    >> in core and edge networks. The proposal considers both unicast = and the
    >> multicast cases. For unicast, the metric considered is = *consumed-power to
    >> available-bandwidth* and for multicast the metric is = *consumed-power to
    >> available-replication-capacity.*
    >>
    >> With unicast, the metric is used to determine a low-power path = between
    >> sources and destinations. With multicast, the metric serves the = twin
    >> purpose of finding low-power multicast paths as well as = multicast
    >> replication points.  We evolve multiple techniques at = various hierarchical
    >> levels. One at the Inter-AS level, Inter-Area level within the = AS and
    >> intra-Area within an AS. Additionally, the proposed method can = also be used
    >> to determine disjoint or redundant paths for load balancing or = fault
    >> tolerance. Additionally since TCAMs are one of the biggest = power guzzlers
    >> in all the components on a router/switch, we have presented a = solution for
    >> intra-AS purposes to use the TCAM according to the traffic = matrix passing
    >> through the system and shut down those TCAM banks that are = unused. With
    >> this in mind, we have also advocated taking into account a = TCAM-POWER-Ratio
    >> in order to compute the paths from source to destination based = on this
    >> metric. Once low-power paths, in either the unicast or the = multicast cases,
    >> are identified then currently available traffic engineering = techniques
    >> could be used to route the data packets. In the case of = inter-AS BGP path
    >> selection is also modified to arrive at paths which are = low-power paths.
    >>
    >> Our main objective is as follows...
    >>
    >> We now outline four important aspects that any approach for = power reduction
    >> should be capable of addressing.
    >>
    >> *Should cater for both unicast and multicast scenarios*
    >>
    >> Multicast provides an important scenario for the Internet. = Today, most
    >> proposals consider mainly low-power path routing with unicast = traffic.
    >> Multicast traffic has received a lot of attention in wireless = networks, but
    >> not in the wired domain. Any new proposal should be able to = address both
    >> the unicast and the multicast traffic scenarios. Having = different methods
    >> for these two scenarios might lead to unnecessary processing = burden in the
    >> routers, which might hinder its scalability.
    >>
    >> *Should not rely on just switching off unused links*
    >>
    >> Most approaches to optimize energy pursue the following = approach: measure,
    >> monitor and respond to the system energy usage by switching off = unused or
    >> under-utilized links. Such an approach could be effective for = reducing
    >> power locally. The effect on the network is not clearly = understood.
    >> Further, the power usage involved in turning on and = rebooting/reconfiguring
    >> the device is often not explicitly considered. We note that = Service Level
    >> Agreement (SLA) requirements may not even permit the links to = be switched
    >> off. Also services provided by ISPs like Virtual Private = Networks (VPNs)
    >> can be affected by such re-routing decisions.
    >>
    >> *Should follow an hierarchical and distributed approach*
    >>
    >> For scalability, it is important that the algorithms proposed = for inter-AS
    >> should also be applicable to intra-AS situations. Networks do = not work in
    >> isolation, so any proposal should be both distributed and = hierarchical. The
    >> algorithms should be applicable at every level of the = hierarchy.
    >>
    >> *Should  provide incentives for ISP for adoption*
    >>
    >> The engineering proposals should be aligned with commercial = incentives for
    >> rapid and widespread adoption. Today, the device manufacturers = and the ISPs
    >> operate independently of each other, and there is no incentive = for
    >> manufacturers to work towards low-power and high bandwidth = devices. An
    >> ISP=3D92s revenue model is based on the consumed bandwidth, = which in turn lea=3D
    >> d
    >> naturally to more power consumption. If the proposed method = chooses routers
    >> that consume low-power and increase the data flow through them, = then this
    >> indirectly provides encouragement for ISPs to purchase = low-power and high
    >> bandwidth devices.
    >>
    >>
    >>
    >> We now present our metric-based proposals in the below = mentioned drafts
    >> which addresses the aforementioned design aspects.
    >>
    >> We would like the routing community to provide feedback on = these drafts. We
    >> also intend to present this work in an abridged format in the = upcoming IETF=3D
    >> .
    >>
    >> The drafts are as follows....
    >>
    >>
    >>
    >>
    >>   - mjsraman-panet-bgp-power-path<http://tools.ietf.org/html/draft-mjsrama=3D
    >> n-panet-bgp-power-path>
    >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-pane= t-bg=3D
    >> p-power-path-timing.html>
    >>    Inter-AS-Proposal
    >>   - mjsraman-panet-ecmp-redirect-power-repl-cap<http://tools.ietf.org/html=3D
    >> /draft-mjsraman-panet-ecmp-redirect-power-repl-cap>
    >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-pane= t-ec=3D
    >> mp-redirect-power-repl-cap-timing.html>
    >>    Multicast
    >>   - mjsraman-panet-inter-as-power-source<http://tools.ietf.org/html/draft-=3D
    >> mjsraman-panet-inter-as-power-source>
    >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-pane= t-in=3D
    >> ter-as-power-source-timing.html>
    >> Inter-AS
    >>   Proposal
    >>   - mjsraman-panet-inter-as-psp<http://tools.ietf.org/html/draft-mjsraman-=3D
    >> panet-inter-as-psp>
    >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-pane= t-in=3D
    >> ter-as-psp-timing.html>
    >> Inter-AS
    >>   Proposal
    >>   - mjsraman-panet-inter-as-psp-protect<http://tools.ietf.org/html/draft-m=3D
    >> jsraman-panet-inter-as-psp-protect>
    >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-pane= t-in=3D
    >> ter-as-psp-protect-timing.html>
    >> Inter-AS
    >>   Proposal
    >>   - mjsraman-panet-pce-power-mcast-replic<http://tools.ietf.org/html/draft=3D
    >> -mjsraman-panet-pce-power-mcast-replic>
    >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-pane= t-pc=3D
    >> e-power-mcast-replic-timing.html>
    >>    Multicast
    >>   - mjsraman-panet-pim-power<http://tools.ietf.org/html/draft-mjsraman-pan=3D
    = >> et-pim-power>
    >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-pane= t-pi=3D
    >> m-power-timing.html>
    >>    Multicast
    >>   - mjsraman-panet-tcam-power-efficiency<http://tools.ietf.org/html/draft-=3D
    >> mjsraman-panet-tcam-power-efficiency>
    >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-pane= t-tc=3D
    >> am-power-efficiency-timing.html>
    >> TCAM
    >>   related
    >>   - mjsraman-panet-tcam-power-ratio<http://tools.ietf.org/html/draft-mjsra=3D
    >> man-panet-tcam-power-ratio>
    >>    (timeline<http://www.arkko.com/tools/lifecycle/draft-mjsraman-pane= t-tca=3D
    >> m-power-ratio-timing.html>)
    >>   TCAM related
    >>   - mjsraman-pce-power-replic<http://tools.ietf.org/html/draft-mjsraman-pc=3D
    >> e-power-replic>
    >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-pce-= powe=3D
    >> r-replic-timing.html>
    >>    Multicast
    >>   - mjsraman-panet-intra-as-psp-te-leak<http://tools.ietf.org/html/draft-m=3D
    >> jsraman-panet-intra-as-psp-te-leak>
    >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-pane= t-in=3D
    >> tra-as-psp-te-leak-timing.html>
    >> Inter-Area
    >>   within an AS
    >>   - mjsraman-panet-ospf-power-topo<http://tools.ietf.org/html/draft-mjsram=3D
    >> an-panet-ospf-power-topo>
    >>    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-pane= t-os=3D
    >> pf-power-topo-timing.html>
    >> Intra-Area
    >>   within an AS
    >>
    >> We understand it is a lot of matter to go through. We would = much appreciate
    >> if some of you could review the inter-AS proposals while others = take up
    >> multicast and Intra-AS unicast and multicast.
    >>
    >> Thanks again for your time on this matter.
    >>
    >> thanks and regards,
    >> balaji venkat
    > = _______________________________________________
    > 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

    = --Apple-Mail=_3B1AC8E0-60EB-4F70-9328-5613C9E4065F-- From tnadeau@lucidvision.com Thu Feb 7 07:14:33 2013 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 171E121F8530 for ; Thu, 7 Feb 2013 07:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUpTquQKI4UI for ; Thu, 7 Feb 2013 07:14:32 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id C85B621F8546 for ; Thu, 7 Feb 2013 07:14:31 -0800 (PST) Received: from [172.28.133.199] (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 280E423E88A8; Thu, 7 Feb 2013 10:14:20 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Power aware networks : Comments requested from routing community From: Thomas Nadeau In-Reply-To: <4552F0907735844E9204A62BBDD325E732AFF1A1@nkgeml508-mbx.china.huawei.com> Date: Thu, 7 Feb 2013 10:14:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <26C6E21E-8E5E-4E6F-83CA-22DA542F6BEF@lucidvision.com> References: Your message of "Thu, 07 Feb 2013 00:22:54 +0530." <201302062005.r16K5CQS084848@gateway1.orleans.occnc.com> <4552F0907735844E9204A62BBDD325E732AFF1A1@nkgeml508-mbx.china.huawei.com> To: Mingui Zhang X-Mailer: Apple Mail (2.1499) Cc: Shankar Raman M J , "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, 07 Feb 2013 15:14:33 -0000 On Feb 6, 2013:10:53 PM, at 10:53 PM, Mingui Zhang = wrote: > Hi Curtis, >=20 > I am very happy that you know GreenTE so well. Very good comments. > As the designer of the GreenTE model, I feel obliged to clarify some = of the confusions. Please see in-lines below. >=20 > Thanks, > Mingui Zhang > Huawei Technologies >=20 >=20 >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On = Behalf Of >> Curtis Villamizar >> Sent: Thursday, February 07, 2013 4:05 AM >> To: Balaji venkat Venkataswami >> Cc: Shankar Raman M J; rtgwg@ietf.org >> Subject: Re: Power aware networks : Comments requested from routing >> community >>=20 >>=20 >> In message >> > mail.com> >> Balaji venkat Venkataswami writes: >>=20 >>> As you might recall one such research paper on GreenTE by Beichuan >>> Zhang rang a lot of bells in the IETF by collecting the ANRP prize. = So >>> please dont misstate facts as you might know them and shove your = ideas >>> of how networks are built down our throats. >>=20 >> That was a research paper published in IEEE International Conference >> on Network Protocols (ICNP). >>=20 >> Power savings potential (a computation, not a measurement) were as >> high as 20-40%. That is good but ... >>=20 >> Line cards considered were old OC3, OC48, and one port OC192 cards. >> The paper ignores the reality that shutting off one port on a >> multiport card makes little difference, certainly far less than a >> reduction of 1/N. The power consumption of transport was not >> included. Impact on fault restoration was not considered. Lots of >> other flaws, but still good work and a potential 20-40% is nice, even >> if factoring in reality might get only half that or less. >=20 > If you read the model, you will find a variable B_m. It indicates the = base power of the line card. This base power is high and can only be = saved when all ports on a multiport card are shutting off. So the model = did consider the reality that "shutting one port saves far less than a = reduction of 1/N". Having said that, I agree that your reality is based = on most current practice. But vendors can purposely provide line cards = with single port. Then the card can be shut off when the port is shut = off. Also, don't forget about composite links which are powered = physically separately. GreenTE is now able to handle composite links. We = have a demo website to show this: http://greente.65536.cn/. >=20 > Let me add another positive reality: when link cards are shutting off = in a chassis, blowers in the same chassis may be shutting off or operate = at a low speed. This helps the whole chassis save more power. The problem with the model is that it makes assumptions that = just do not reflect the reality of much of the equipment that is = deployed today. For instance, while there is a lot of power used in the = line card optics, the idle power supply capacity is another giant waste = of power. This cannot be mitigated without shutting down the entire = device. Further considerations need to be made around the back-up = facility power as well, which while not directly influenced by network = traffic, does influence overall power utilization. =20 >> The point though is that a 1 port OC192 at 174 watts (10 Gb/s) is no >> match for a 500 Gb/s card at roughly 650 watts. That is more than >> 40%. It is more than a decimal order of magnitude greater. It is = not >> comparing apples to oranges, one is an IP/MPLS router with full >> routing tables and short haul interfaces, the other does OTN = switching >> drives either short haul or long haul transport interfaces, and could >> do IP/MPLS, but with only IGP routes and MPLS LSPs at that power >> figure. So maybe the way the network is built needs to change. >>=20 >=20 > What do you mean about the number "40%"? Anyway, line cards consume a = large percentage of energy of the whole Chassis and this percentage is = increasing fast. This judgment always holds.=20 >=20 > GreenTE only cares about line cards. So 20-40% saving actually means = 20-40% of the total power consumed by all line-cards. The point that is being made I believe, is that while overall = power consumption of devices is something we can strive to optimize, the = means of using "green TE" might not be the best one given the reductions = actually possible. >=20 >> Anyway, if *I* were to continue this discussion, then *I* should get >> off the IETF lists and go write an academic paper. [Or better yet, >> work for a service provider or equipment vendor and work toward >> building better equipment and networks.] >>=20 >> The point is that efficiency has gone up by orders of magnitude as we >> went from OC3 to OC12 to OC48 to OC192 (circa 1995-2000) and then >> multiport OC192 and OC768 and 10GbE (circa 2005-2010) to 100GbE and >> ODU4 (somewhat recent) to multiport 100GbE and ODU4 (even more >> recent). Power per bit drops about one to two decimal order of >> magnitude per decade and for any given a specific snapshot in the >> technology timeline, there are means to reduce power that get far = more >> than the 20-40% that GreenTE potentially offers. >=20 > Besides the power saved from the efficiency of the hardware, GreenTE = can add another 20-40% saving, right? :)=20 Yes, but if the equipment is already very power efficient, the = law of diminishing returns (or unexpected consequences) may dominate the = equation. --Tom >> Of course a new generation of equipment means CapEx and GreenTE is >> perceived as just routing and therefore free, so therefore the >> interest. >>=20 >> Another point is that no one ever tried this on a real network. With >> RSVP-TE no protocol changes would be necessary, just offline >> computation, a configured preferred explicit-path, and some interface >> shutdowns. I don't know that anyone has even measured the reduction >> in power of an idled or administratively shut down interface or line >> card. There was nothing in the paper on this. >>=20 >>>> If you want to try to advance a research paper with your theories = on >>>> power reduction, please choose an appropriate venue such as a = refereed >>>> technical journal. >>=20 >> I repeat my main point. [And hope to be among the reviewers] >>=20 >> Also IMHO GreenTE as described by Zhang is more likely to be feasible >> with MPLS and RSVP-TE than with OSPF or BGP or PIM, etc. But then, >> the feasibility and potential benefits of GreenTE using IGP, BGP, and >> PIM is what your academic paper can try to defend. >=20 > When a link is shut off, no control messages (e.g., HELLOs) can be = delivered on it. Link state routing protocols (e.g., ISIS, OSPF), is = required to be aware of this.=20 >=20 > [end of my clarifications] >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >>=20 >> Thank you, >>=20 >> Curtis >> _______________________________________________ >> 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 >=20 From acee.lindem@ericsson.com Thu Feb 7 07:19:25 2013 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 EA14021F85CB for ; Thu, 7 Feb 2013 07:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-IGDiX8bguV for ; Thu, 7 Feb 2013 07:19:24 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id E507F21F855A for ; Thu, 7 Feb 2013 07:19:23 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-6b-5113c5fa13e6 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 5E.08.31450.AF5C3115; Thu, 7 Feb 2013 16:19:23 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 10:19:22 -0500 From: Acee Lindem To: Thomas Nadeau Subject: Re: Power aware networks : Comments requested from routing community Thread-Topic: Power aware networks : Comments requested from routing community Thread-Index: AQHOBUS2KDJkO1M7IEeLafcJ3BRJWphu1kkA Date: Thu, 7 Feb 2013 15:19:21 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470BDFDD@eusaamb101.ericsson.se> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <72B40FF5-6A29-4857-93AA-768490A20903@juniper.net> <540411EE-A351-4AB6-A5B7-10D2D66062D0@lucidvision.com> In-Reply-To: <540411EE-A351-4AB6-A5B7-10D2D66062D0@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE470BDFDDeusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonRPf3UeFAg3utzBbTz6xhszjV/I7d 4sKb38wWDydfYndg8dg56y67x5IlP5k8tj5Zwh7AHMVlk5Kak1mWWqRvl8CVcXFTN0vBjE+M Ff8+7WdpYFx+gbGLkZNDQsBE4tzu91C2mMSFe+vZuhi5OIQEjjBKrJ28DspZxihxYNcWsCo2 AR2J54/+MYPYIgLaEhP7WplBipgFOhklHl/dApYQFvCV2LJ7JwtEUYDE9Z7bUA1GEn8a7wLZ HBwsAioSHz44g4R5Bbwl7j3qZYZY9pNR4tyrHUwgCU4BZ4nlk7eDzWEEOu/7qTVgcWYBcYlb T+YzQZwtILFkz3lmCFtU4uXjf6wQtrLEkif7WSDq8yXWbvvOCrFMUOLkzCcsExhFZyEZNQtJ 2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceAzUywFkW0s0r6tCVrKAkWMVI0dpcWpZbrqRwSZG YEQek2DT3cG456XlIUZpDhYlcd4g1wsBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhh7v/2/ pDtxR/SllQ6bmy+LOzxVXNvwzbnvWu/uzUqbFE9H2Z1sfvSm1YbhffyXN/+dyjRcbJcYHWe9 u/Dr0h3Pl6964/nH7E1FJ/vSKTOe5kiuOhB5ZTWTRVmLs53aOuMpAl+7bjMc2CuWt1G5tLci Omd/5J5nsZtUyqYcP1ndcPPbTpUPqWGGSizFGYmGWsxFxYkAllobY5YCAAA= Cc: Shankar Raman M J , "" 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, 07 Feb 2013 15:19:26 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE470BDFDDeusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Acee On Feb 7, 2013, at 10:06 AM, Thomas Nadeau wrote: The other problem with this (frankly naive approach which has been investig= ated by many) is that yes, while adding in another constraint to the metric= computation, it may result in unexpected consequences. This is why it i= s likely to be more suitable as an IRTF topic of research until those "deta= ils" are sorted out. --Tom On Feb 7, 2013:5:52 AM, at 5:52 AM, Balaji venkat Venkataswami > wrote: Dear Hannes, We are familiar with the presentation that you have referred to. I have 3 questions for you. a) While we agree with the presentation that you have mentioned, can we in = the IETF have control over the home appliances and subscriber line kit ? Is= there a methodology by which we can optimize the power consumption on thes= e devices ? b) The problem space that the IETF can take up can be only in the edge and = core devices in the ISP networks and the Campus/DC/Metro etc...Assume that = I have n devices today with the same bandwidth offering but differing power= consumption footprint, is there a way today to automatically send traffic through low p= ower paths in the topology of these devices. c) So we can optimize power only on what we can control. What are your view= s on this ? thanks and regards, balaji venkat On Thu, Feb 7, 2013 at 6:37 PM, Hannes Gredler > wrote: balaji, may i put your attention to a talk that francois lemarchand gave on future net 2010. https://www.dropbox.com/s/3jb9au2zca4nl3x/10_fn_S29.pdf contains a copy. slide 2 initially shows that the core and edge layer might be appealing due to their per-box power print. however slide 15 discusses the big picture where 99.99% of the power is burned by the home appliances and subscriber line kit. Do you think that optimizing a part of the network which gives only limited overall savings is a worthwhile goal ? Note that SPs already ask their vend= ors about reducing the power footprint of those core devices by improved, (some= times less functional) silicon forwarding engines. /hannes On Feb 6, 2013, at 7:41 PM, Curtis Villamizar wrote: > > Balaji, > > "We" in the context of your first paragraph seems to be a > misrepresentation. The authors of all of these drafts seem to be from > the same university in India. From prior attempts on your part to get > a draft of this sort into IDR and a brief reading of a few of the > drafts that you have just submitted, you don't seem to have a good > understanding of how networks are built and how network equipment is > built from which to begin to attack the problem of reducing the power > consumption of these networks. > > If you want to try to advance a research paper with your theories on > power reduction, please choose an appropriate venue such as a refereed > technical journal. > > Curtis > > > In message > > Balaji venkat Venkataswami writes: > >> Dear all, >> >> We are a group of research and industry individuals tied together with a >> common goal towards reducing the energy consumption in the core and edge >> networks. >> >> We present a metric-based hierarchical approach to reduce power consumpt= ion >> in core and edge networks. The proposal considers both unicast and the >> multicast cases. For unicast, the metric considered is *consumed-power t= o >> available-bandwidth* and for multicast the metric is *consumed-power to >> available-replication-capacity.* >> >> With unicast, the metric is used to determine a low-power path between >> sources and destinations. With multicast, the metric serves the twin >> purpose of finding low-power multicast paths as well as multicast >> replication points. We evolve multiple techniques at various hierarchic= al >> levels. One at the Inter-AS level, Inter-Area level within the AS and >> intra-Area within an AS. Additionally, the proposed method can also be u= sed >> to determine disjoint or redundant paths for load balancing or fault >> tolerance. Additionally since TCAMs are one of the biggest power guzzler= s >> in all the components on a router/switch, we have presented a solution f= or >> intra-AS purposes to use the TCAM according to the traffic matrix passin= g >> through the system and shut down those TCAM banks that are unused. With >> this in mind, we have also advocated taking into account a TCAM-POWER-Ra= tio >> in order to compute the paths from source to destination based on this >> metric. Once low-power paths, in either the unicast or the multicast cas= es, >> are identified then currently available traffic engineering techniques >> could be used to route the data packets. In the case of inter-AS BGP pat= h >> selection is also modified to arrive at paths which are low-power paths. >> >> Our main objective is as follows... >> >> We now outline four important aspects that any approach for power reduct= ion >> should be capable of addressing. >> >> *Should cater for both unicast and multicast scenarios* >> >> Multicast provides an important scenario for the Internet. Today, most >> proposals consider mainly low-power path routing with unicast traffic. >> Multicast traffic has received a lot of attention in wireless networks, = but >> not in the wired domain. Any new proposal should be able to address both >> the unicast and the multicast traffic scenarios. Having different method= s >> for these two scenarios might lead to unnecessary processing burden in t= he >> routers, which might hinder its scalability. >> >> *Should not rely on just switching off unused links* >> >> Most approaches to optimize energy pursue the following approach: measur= e, >> monitor and respond to the system energy usage by switching off unused o= r >> under-utilized links. Such an approach could be effective for reducing >> power locally. The effect on the network is not clearly understood. >> Further, the power usage involved in turning on and rebooting/reconfigur= ing >> the device is often not explicitly considered. We note that Service Leve= l >> Agreement (SLA) requirements may not even permit the links to be switche= d >> off. Also services provided by ISPs like Virtual Private Networks (VPNs) >> can be affected by such re-routing decisions. >> >> *Should follow an hierarchical and distributed approach* >> >> For scalability, it is important that the algorithms proposed for inter-= AS >> should also be applicable to intra-AS situations. Networks do not work i= n >> isolation, so any proposal should be both distributed and hierarchical. = The >> algorithms should be applicable at every level of the hierarchy. >> >> *Should provide incentives for ISP for adoption* >> >> The engineering proposals should be aligned with commercial incentives f= or >> rapid and widespread adoption. Today, the device manufacturers and the I= SPs >> operate independently of each other, and there is no incentive for >> manufacturers to work towards low-power and high bandwidth devices. An >> ISP=3D92s revenue model is based on the consumed bandwidth, which in tur= n lea=3D >> d >> naturally to more power consumption. If the proposed method chooses rout= ers >> that consume low-power and increase the data flow through them, then thi= s >> indirectly provides encouragement for ISPs to purchase low-power and hig= h >> bandwidth devices. >> >> >> >> We now present our metric-based proposals in the below mentioned drafts >> which addresses the aforementioned design aspects. >> >> We would like the routing community to provide feedback on these drafts.= We >> also intend to present this work in an abridged format in the upcoming I= ETF=3D >> . >> >> The drafts are as follows.... >> >> >> >> >> - mjsraman-panet-bgp-power-path> n-panet-bgp-power-path> >> (timeline)> p-power-path-timing.html> >> Inter-AS-Proposal >> - mjsraman-panet-ecmp-redirect-power-repl-cap> /draft-mjsraman-panet-ecmp-redirect-power-repl-cap> >> (timeline)> mp-redirect-power-repl-cap-timing.html> >> Multicast >> - mjsraman-panet-inter-as-power-source> mjsraman-panet-inter-as-power-source> >> (timeline)> ter-as-power-source-timing.html> >> Inter-AS >> Proposal >> - mjsraman-panet-inter-as-psp> panet-inter-as-psp> >> (timeline)> ter-as-psp-timing.html> >> Inter-AS >> Proposal >> - mjsraman-panet-inter-as-psp-protect> jsraman-panet-inter-as-psp-protect> >> (timeline)> ter-as-psp-protect-timing.html> >> Inter-AS >> Proposal >> - mjsraman-panet-pce-power-mcast-replic> -mjsraman-panet-pce-power-mcast-replic> >> (timeline)> e-power-mcast-replic-timing.html> >> Multicast >> - mjsraman-panet-pim-power> et-pim-power> >> (timeline)> m-power-timing.html> >> Multicast >> - mjsraman-panet-tcam-power-efficiency> mjsraman-panet-tcam-power-efficiency> >> (timeline)> am-power-efficiency-timing.html> >> TCAM >> related >> - mjsraman-panet-tcam-power-ratio> man-panet-tcam-power-ratio> >> (timeline> m-power-ratio-timing.html>) >> TCAM related >> - mjsraman-pce-power-replic> e-power-replic> >> (timeline)> r-replic-timing.html> >> Multicast >> - mjsraman-panet-intra-as-psp-te-leak> jsraman-panet-intra-as-psp-te-leak> >> (timeline)> tra-as-psp-te-leak-timing.html> >> Inter-Area >> within an AS >> - mjsraman-panet-ospf-power-topo> an-panet-ospf-power-topo> >> (timeline)> pf-power-topo-timing.html> >> Intra-Area >> within an AS >> >> We understand it is a lot of matter to go through. We would much appreci= ate >> if some of you could review the inter-AS proposals while others take up >> multicast and Intra-AS unicast and multicast. >> >> Thanks again for your time on this matter. >> >> thanks and regards, >> balaji venkat > _______________________________________________ > 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 _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --_000_94A203EA12AECE4BA92D42DBFFE0AE470BDFDDeusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable +1 
    Acee 
    On Feb 7, 2013, at 10:06 AM, Thomas Nadeau wrote:


    The other p= roblem with this (frankly naive approach which has been investigated by man= y) is that yes, while adding in another constraint to the metric computatio= n, it may result in unexpected consequences.    This is why it is likely to be more suitable as an IRTF topic= of research until those "details" are sorted out. 

    --Tom<= /div>


    On Feb 7, 2013:5:52 AM, at 5:52 AM, Balaji venkat Venkataswami <balajivenkat299@gmail.com>= wrote:

    Dear Hannes,

    We are familiar with the presentation that you have referred to.

    I have 3 questions for you.

    a) While we agree with the presentation that you have mentioned, can w= e in the IETF have control over the home appliances and subscriber line kit= ? Is there a methodology by which we can optimize the power consumption on= these devices ?

    b) The problem space that the IETF can take up can be only in the edge= and core devices in the ISP networks and the Campus/DC/Metro etc...Assume = that I have n devices today with the same bandwidth offering but differing = power consumption
    footprint, is there a way today to automatically send traffic through = low power paths in the topology of these devices.

    c) So we can optimize power only on what we can control. What are your= views on this ?

    thanks and regards,
    balaji venkat 

    On Thu, Feb 7, 2013 at 6:37 PM, Hannes Gredler <= span dir=3D"ltr"> <hannes@juniper.= net> wrote:
    balaji,

    may i put your attention to a talk that  francois lemarchand
    gave on future net 2010.
    https://www.dropbox.com/s/3jb9au2zca4nl3x/10_fn_S29.pdf
    contains a copy.

    slide 2 initially shows that the core and edge layer might be appealing
    due to their per-box power print. however slide 15 discusses the
    big picture where 99.99% of the power is burned by the home
    appliances and subscriber line kit.

    Do you think that optimizing a part of the network which gives only limited=
    overall savings is a worthwhile goal ? Note that SPs already ask their vend= ors
    about reducing the power footprint of those core devices by improved, (some= times
    less functional) silicon forwarding engines.

    /hannes

    On Feb 6, 2013, at 7:41 PM, Curtis Villamizar wrote:

    >
    > Balaji,
    >
    > "We" in the context of your first paragraph seems to be a > misrepresentation.  The authors of all of these drafts seem to be= from
    > the same university in India.  From prior attempts on your part t= o get
    > a draft of this sort into IDR and a brief reading of a few of the
    > drafts that you have just submitted, you don't seem to have a good
    > understanding of how networks are built and how network equipment is > built from which to begin to attack the problem of reducing the power<= br> > consumption of these networks.
    >
    > If you want to try to advance a research paper with your theories on > power reduction, please choose an appropriate venue such as a refereed=
    > technical journal.
    >
    > Curtis
    >
    >
    > In message <CAHF4apO9bEkPk7QwA9fgJq9BNUNHNv+OFon_9= _4Oij61e11r9w@mail.gmail.com>
    > Balaji venkat Venkataswami writes:
    >
    >> Dear all,
    >>
    >> We are a group of research and industry individuals tied together = with a
    >> common goal towards reducing the energy consumption in the core an= d edge
    >> networks.
    >>
    >> We present a metric-based hierarchical approach to reduce power co= nsumption
    >> in core and edge networks. The proposal considers both unicast and= the
    >> multicast cases. For unicast, the metric considered is *consumed-p= ower to
    >> available-bandwidth* and for multicast the metric is *consumed-pow= er to
    >> available-replication-capacity.*
    >>
    >> With unicast, the metric is used to determine a low-power path bet= ween
    >> sources and destinations. With multicast, the metric serves the tw= in
    >> purpose of finding low-power multicast paths as well as multicast<= br> >> replication points.  We evolve multiple techniques at various= hierarchical
    >> levels. One at the Inter-AS level, Inter-Area level within the AS = and
    >> intra-Area within an AS. Additionally, the proposed method can als= o be used
    >> to determine disjoint or redundant paths for load balancing or fau= lt
    >> tolerance. Additionally since TCAMs are one of the biggest power g= uzzlers
    >> in all the components on a router/switch, we have presented a solu= tion for
    >> intra-AS purposes to use the TCAM according to the traffic matrix = passing
    >> through the system and shut down those TCAM banks that are unused.= With
    >> this in mind, we have also advocated taking into account a TCAM-PO= WER-Ratio
    >> in order to compute the paths from source to destination based on = this
    >> metric. Once low-power paths, in either the unicast or the multica= st cases,
    >> are identified then currently available traffic engineering techni= ques
    >> could be used to route the data packets. In the case of inter-AS B= GP path
    >> selection is also modified to arrive at paths which are low-power = paths.
    >>
    >> Our main objective is as follows...
    >>
    >> We now outline four important aspects that any approach for power = reduction
    >> should be capable of addressing.
    >>
    >> *Should cater for both unicast and multicast scenarios*
    >>
    >> Multicast provides an important scenario for the Internet. Today, = most
    >> proposals consider mainly low-power path routing with unicast traf= fic.
    >> Multicast traffic has received a lot of attention in wireless netw= orks, but
    >> not in the wired domain. Any new proposal should be able to addres= s both
    >> the unicast and the multicast traffic scenarios. Having different = methods
    >> for these two scenarios might lead to unnecessary processing burde= n in the
    >> routers, which might hinder its scalability.
    >>
    >> *Should not rely on just switching off unused links*
    >>
    >> Most approaches to optimize energy pursue the following approach: = measure,
    >> monitor and respond to the system energy usage by switching off un= used or
    >> under-utilized links. Such an approach could be effective for redu= cing
    >> power locally. The effect on the network is not clearly understood= .
    >> Further, the power usage involved in turning on and rebooting/reco= nfiguring
    >> the device is often not explicitly considered. We note that Servic= e Level
    >> Agreement (SLA) requirements may not even permit the links to be s= witched
    >> off. Also services provided by ISPs like Virtual Private Networks = (VPNs)
    >> can be affected by such re-routing decisions.
    >>
    >> *Should follow an hierarchical and distributed approach*
    >>
    >> For scalability, it is important that the algorithms proposed for = inter-AS
    >> should also be applicable to intra-AS situations. Networks do not = work in
    >> isolation, so any proposal should be both distributed and hierarch= ical. The
    >> algorithms should be applicable at every level of the hierarchy. >>
    >> *Should  provide incentives for ISP for adoption*
    >>
    >> The engineering proposals should be aligned with commercial incent= ives for
    >> rapid and widespread adoption. Today, the device manufacturers and= the ISPs
    >> operate independently of each other, and there is no incentive for=
    >> manufacturers to work towards low-power and high bandwidth devices= . An
    >> ISP=3D92s revenue model is based on the consumed bandwidth, which = in turn lea=3D
    >> d
    >> naturally to more power consumption. If the proposed method choose= s routers
    >> that consume low-power and increase the data flow through them, th= en this
    >> indirectly provides encouragement for ISPs to purchase low-power a= nd high
    >> bandwidth devices.
    >>
    >>
    >>
    >> We now present our metric-based proposals in the below mentioned d= rafts
    >> which addresses the aforementioned design aspects.
    >>
    >> We would like the routing community to provide feedback on these d= rafts. We
    >> also intend to present this work in an abridged format in the upco= ming IETF=3D
    >> .
    >>
    >> The drafts are as follows....
    >>
    >>
    >>
    >>
    >>   - mjsraman-panet-bgp-power-path<http://tools.ietf.org/htm= l/draft-mjsrama=3D
    >> n-panet-bgp-power-path>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-bg=3D
    >> p-power-path-timing.html>
    >>    Inter-AS-Proposal
    >>   - mjsraman-panet-ecmp-redirect-power-repl-cap<http://tools.ietf.org/htm= l=3D
    >> /draft-mjsraman-panet-ecmp-redirect-power-repl-cap>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-ec=3D
    >> mp-redirect-power-repl-cap-timing.html>
    >>    Multicast
    >>   - mjsraman-panet-inter-as-power-source<http://tools.ietf.org/htm= l/draft-=3D
    >> mjsraman-panet-inter-as-power-source>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-in=3D
    >> ter-as-power-source-timing.html>
    >> Inter-AS
    >>   Proposal
    >>   - mjsraman-panet-inter-as-psp<http://tools.ietf.org/htm= l/draft-mjsraman-=3D
    >> panet-inter-as-psp>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-in=3D
    >> ter-as-psp-timing.html>
    >> Inter-AS
    >>   Proposal
    >>   - mjsraman-panet-inter-as-psp-protect<http://tools.ietf.org/htm= l/draft-m=3D
    >> jsraman-panet-inter-as-psp-protect>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-in=3D
    >> ter-as-psp-protect-timing.html>
    >> Inter-AS
    >>   Proposal
    >>   - mjsraman-panet-pce-power-mcast-replic<http://tools.ietf.org/htm= l/draft=3D
    >> -mjsraman-panet-pce-power-mcast-replic>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-pc=3D
    >> e-power-mcast-replic-timing.html>
    >>    Multicast
    >>   - mjsraman-panet-pim-power<http://tools.ietf.org/htm= l/draft-mjsraman-pan=3D
    >> et-pim-power>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-pi=3D
    >> m-power-timing.html>
    >>    Multicast
    >>   - mjsraman-panet-tcam-power-efficiency<http://tools.ietf.org/htm= l/draft-=3D
    >> mjsraman-panet-tcam-power-efficiency>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-tc=3D
    >> am-power-efficiency-timing.html>
    >> TCAM
    >>   related
    >>   - mjsraman-panet-tcam-power-ratio<http://tools.ietf.org/htm= l/draft-mjsra=3D
    >> man-panet-tcam-power-ratio>
    >>    (timeline<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-tca=3D
    >> m-power-ratio-timing.html>)
    >>   TCAM related
    >>   - mjsraman-pce-power-replic<http://tools.ietf.org/htm= l/draft-mjsraman-pc=3D
    >> e-power-replic>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-pce-powe=3D
    >> r-replic-timing.html>
    >>    Multicast
    >>   - mjsraman-panet-intra-as-psp-te-leak<http://tools.ietf.org/htm= l/draft-m=3D
    >> jsraman-panet-intra-as-psp-te-leak>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-in=3D
    >> tra-as-psp-te-leak-timing.html>
    >> Inter-Area
    >>   within an AS
    >>   - mjsraman-panet-ospf-power-topo<http://tools.ietf.org/htm= l/draft-mjsram=3D
    >> an-panet-ospf-power-topo>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-os=3D
    >> pf-power-topo-timing.html>
    >> Intra-Area
    >>   within an AS
    >>
    >> We understand it is a lot of matter to go through. We would much a= ppreciate
    >> if some of you could review the inter-AS proposals while others ta= ke up
    >> multicast and Intra-AS unicast and multicast.
    >>
    >> Thanks again for your time on this matter.
    >>
    >> thanks and regards,
    >> balaji venkat
    > _______________________________________________
    > rtgwg mailing list
    > rtgwg@ietf.org
    > https://www.ietf.org/mailman/listinfo/rtgwg
    >



    _______________________________________________
    rtgwg mailing list
    rtgwg@ietf.org
    https://www.ietf.or= g/mailman/listinfo/rtgwg

    _______________________________________________
    rtgwg mailing list
    rtgwg@ietf.org
    https://www.ietf.org/mailman/listinfo/rtgwg

    --_000_94A203EA12AECE4BA92D42DBFFE0AE470BDFDDeusaamb101ericsso_-- From balajivenkat299@gmail.com Thu Feb 7 07:31:42 2013 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 6D2AD21F86EF for ; Thu, 7 Feb 2013 07:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.37 X-Spam-Level: X-Spam-Status: No, score=-3.37 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKxpMA5GDYlT for ; Thu, 7 Feb 2013 07:31:40 -0800 (PST) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by ietfa.amsl.com (Postfix) with ESMTP id 436DB21F862A for ; Thu, 7 Feb 2013 07:31:40 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id v19so2809651obq.21 for ; Thu, 07 Feb 2013 07:31:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FwQSHc0rty20EQfDCmE/zmHpy52KO2T/cA8KteQ+mOc=; b=mlA0ynQGizCuJLQ/2A7GR7Su4ez9A42JIld9KlMF84/9HR7eBLNEIVxiubFnGn1Q6o T7jkD7/Wbmkc1cQfMP/jS2UtP+RuA20YGPj+tzyBAxDQpvmtJKlDDJWwroyKzHP9r0jA YwW9Qgq94BwTOGdQYN+AVcZwu/FpFeAWPF/iHVLTm3eGQaYn+bDq6OT0xZVHuiMMhwhO jflch0VIMQowNGP3/Dw7IuW31VtLRpFOtDBShFjw5XMkCGXfdhcl2xRUbVagvcjyi1zE 2TxwTbiL7eq8soPWu3yakG/d9nBp9FvBn5Rf0nwINYsRTVbfY1nmkLKWvVujUc8BYhM6 vycA== MIME-Version: 1.0 X-Received: by 10.182.217.10 with SMTP id ou10mr1345828obc.30.1360251099792; Thu, 07 Feb 2013 07:31:39 -0800 (PST) Received: by 10.60.93.8 with HTTP; Thu, 7 Feb 2013 07:31:39 -0800 (PST) In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470BDFDD@eusaamb101.ericsson.se> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <72B40FF5-6A29-4857-93AA-768490A20903@juniper.net> <540411EE-A351-4AB6-A5B7-10D2D66062D0@lucidvision.com> <94A203EA12AECE4BA92D42DBFFE0AE470BDFDD@eusaamb101.ericsson.se> Date: Thu, 7 Feb 2013 21:01:39 +0530 Message-ID: Subject: Re: Power aware networks : Comments requested from routing community From: Balaji venkat Venkataswami To: Acee Lindem Content-Type: multipart/alternative; boundary=f46d0444709d9bc5df04d5242388 Cc: Shankar Raman M J , "" 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, 07 Feb 2013 15:31:42 -0000 --f46d0444709d9bc5df04d5242388 Content-Type: text/plain; charset=ISO-8859-1 Dear Tom, Acee, Thank you for your comments. We are currently approaching IRTF for this very purpose. Additionally we would like to state that there are existing mechanisms for aspects like delay (QoS) being additional metrics for the computation of paths inter-AS and intra-AS. We feel that this additional power metric can be handled in a way similar to how say aspects like delay are handled today. Since you have said that this approach has already been tried out, we would request you to give us some of the citations which will be of help to us. We have already searched literature available in the web today. In case we have missed out anything your citations would help us. Thanks and regards, balaji venkat On Thu, Feb 7, 2013 at 8:49 PM, Acee Lindem wrote: > +1 > Acee > > On Feb 7, 2013, at 10:06 AM, Thomas Nadeau wrote: > > > The other problem with this (frankly naive approach which has been > investigated by many) is that yes, while adding in another constraint to > the metric computation, it may result in unexpected consequences. This > is why it is likely to be more suitable as an IRTF topic of research until > those "details" are sorted out. > > --Tom > > > On Feb 7, 2013:5:52 AM, at 5:52 AM, Balaji venkat Venkataswami < > balajivenkat299@gmail.com> wrote: > > Dear Hannes, > > We are familiar with the presentation that you have referred to. > > I have 3 questions for you. > > a) While we agree with the presentation that you have mentioned, can we > in the IETF have control over the home appliances and subscriber line kit ? > Is there a methodology by which we can optimize the power consumption on > these devices ? > > b) The problem space that the IETF can take up can be only in the edge > and core devices in the ISP networks and the Campus/DC/Metro etc...Assume > that I have n devices today with the same bandwidth offering but differing > power consumption > footprint, is there a way today to automatically send traffic through low > power paths in the topology of these devices. > > c) So we can optimize power only on what we can control. What are your > views on this ? > > thanks and regards, > balaji venkat > > On Thu, Feb 7, 2013 at 6:37 PM, Hannes Gredler wrote: > >> balaji, >> >> may i put your attention to a talk that francois lemarchand >> gave on future net 2010. >> https://www.dropbox.com/s/3jb9au2zca4nl3x/10_fn_S29.pdf >> contains a copy. >> >> slide 2 initially shows that the core and edge layer might be appealing >> due to their per-box power print. however slide 15 discusses the >> big picture where 99.99% of the power is burned by the home >> appliances and subscriber line kit. >> >> Do you think that optimizing a part of the network which gives only >> limited >> overall savings is a worthwhile goal ? Note that SPs already ask their >> vendors >> about reducing the power footprint of those core devices by improved, >> (sometimes >> less functional) silicon forwarding engines. >> >> /hannes >> >> On Feb 6, 2013, at 7:41 PM, Curtis Villamizar wrote: >> >> > >> > Balaji, >> > >> > "We" in the context of your first paragraph seems to be a >> > misrepresentation. The authors of all of these drafts seem to be from >> > the same university in India. From prior attempts on your part to get >> > a draft of this sort into IDR and a brief reading of a few of the >> > drafts that you have just submitted, you don't seem to have a good >> > understanding of how networks are built and how network equipment is >> > built from which to begin to attack the problem of reducing the power >> > consumption of these networks. >> > >> > If you want to try to advance a research paper with your theories on >> > power reduction, please choose an appropriate venue such as a refereed >> > technical journal. >> > >> > Curtis >> > >> > >> > In message < >> CAHF4apO9bEkPk7QwA9fgJq9BNUNHNv+OFon_9_4Oij61e11r9w@mail.gmail.com> >> > Balaji venkat Venkataswami writes: >> > >> >> Dear all, >> >> >> >> We are a group of research and industry individuals tied together with >> a >> >> common goal towards reducing the energy consumption in the core and >> edge >> >> networks. >> >> >> >> We present a metric-based hierarchical approach to reduce power >> consumption >> >> in core and edge networks. The proposal considers both unicast and the >> >> multicast cases. For unicast, the metric considered is *consumed-power >> to >> >> available-bandwidth* and for multicast the metric is *consumed-power to >> >> available-replication-capacity.* >> >> >> >> With unicast, the metric is used to determine a low-power path between >> >> sources and destinations. With multicast, the metric serves the twin >> >> purpose of finding low-power multicast paths as well as multicast >> >> replication points. We evolve multiple techniques at various >> hierarchical >> >> levels. One at the Inter-AS level, Inter-Area level within the AS and >> >> intra-Area within an AS. Additionally, the proposed method can also be >> used >> >> to determine disjoint or redundant paths for load balancing or fault >> >> tolerance. Additionally since TCAMs are one of the biggest power >> guzzlers >> >> in all the components on a router/switch, we have presented a solution >> for >> >> intra-AS purposes to use the TCAM according to the traffic matrix >> passing >> >> through the system and shut down those TCAM banks that are unused. With >> >> this in mind, we have also advocated taking into account a >> TCAM-POWER-Ratio >> >> in order to compute the paths from source to destination based on this >> >> metric. Once low-power paths, in either the unicast or the multicast >> cases, >> >> are identified then currently available traffic engineering techniques >> >> could be used to route the data packets. In the case of inter-AS BGP >> path >> >> selection is also modified to arrive at paths which are low-power >> paths. >> >> >> >> Our main objective is as follows... >> >> >> >> We now outline four important aspects that any approach for power >> reduction >> >> should be capable of addressing. >> >> >> >> *Should cater for both unicast and multicast scenarios* >> >> >> >> Multicast provides an important scenario for the Internet. Today, most >> >> proposals consider mainly low-power path routing with unicast traffic. >> >> Multicast traffic has received a lot of attention in wireless >> networks, but >> >> not in the wired domain. Any new proposal should be able to address >> both >> >> the unicast and the multicast traffic scenarios. Having different >> methods >> >> for these two scenarios might lead to unnecessary processing burden in >> the >> >> routers, which might hinder its scalability. >> >> >> >> *Should not rely on just switching off unused links* >> >> >> >> Most approaches to optimize energy pursue the following approach: >> measure, >> >> monitor and respond to the system energy usage by switching off unused >> or >> >> under-utilized links. Such an approach could be effective for reducing >> >> power locally. The effect on the network is not clearly understood. >> >> Further, the power usage involved in turning on and >> rebooting/reconfiguring >> >> the device is often not explicitly considered. We note that Service >> Level >> >> Agreement (SLA) requirements may not even permit the links to be >> switched >> >> off. Also services provided by ISPs like Virtual Private Networks >> (VPNs) >> >> can be affected by such re-routing decisions. >> >> >> >> *Should follow an hierarchical and distributed approach* >> >> >> >> For scalability, it is important that the algorithms proposed for >> inter-AS >> >> should also be applicable to intra-AS situations. Networks do not work >> in >> >> isolation, so any proposal should be both distributed and >> hierarchical. The >> >> algorithms should be applicable at every level of the hierarchy. >> >> >> >> *Should provide incentives for ISP for adoption* >> >> >> >> The engineering proposals should be aligned with commercial incentives >> for >> >> rapid and widespread adoption. Today, the device manufacturers and the >> ISPs >> >> operate independently of each other, and there is no incentive for >> >> manufacturers to work towards low-power and high bandwidth devices. An >> >> ISP=92s revenue model is based on the consumed bandwidth, which in >> turn lea= >> >> d >> >> naturally to more power consumption. If the proposed method chooses >> routers >> >> that consume low-power and increase the data flow through them, then >> this >> >> indirectly provides encouragement for ISPs to purchase low-power and >> high >> >> bandwidth devices. >> >> >> >> >> >> >> >> We now present our metric-based proposals in the below mentioned drafts >> >> which addresses the aforementioned design aspects. >> >> >> >> We would like the routing community to provide feedback on these >> drafts. We >> >> also intend to present this work in an abridged format in the upcoming >> IETF= >> >> . >> >> >> >> The drafts are as follows.... >> >> >> >> >> >> >> >> >> >> - mjsraman-panet-bgp-power-path< >> http://tools.ietf.org/html/draft-mjsrama= >> >> n-panet-bgp-power-path> >> >> (timeline)< >> http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-bg= >> >> p-power-path-timing.html> >> >> Inter-AS-Proposal >> >> - mjsraman-panet-ecmp-redirect-power-repl-cap< >> http://tools.ietf.org/html= >> >> /draft-mjsraman-panet-ecmp-redirect-power-repl-cap> >> >> (timeline)< >> http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-ec= >> >> mp-redirect-power-repl-cap-timing.html> >> >> Multicast >> >> - mjsraman-panet-inter-as-power-source< >> http://tools.ietf.org/html/draft-= >> >> mjsraman-panet-inter-as-power-source> >> >> (timeline)< >> http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in= >> >> ter-as-power-source-timing.html> >> >> Inter-AS >> >> Proposal >> >> - mjsraman-panet-inter-as-psp< >> http://tools.ietf.org/html/draft-mjsraman-= >> >> panet-inter-as-psp> >> >> (timeline)< >> http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in= >> >> ter-as-psp-timing.html> >> >> Inter-AS >> >> Proposal >> >> - mjsraman-panet-inter-as-psp-protect< >> http://tools.ietf.org/html/draft-m= >> >> jsraman-panet-inter-as-psp-protect> >> >> (timeline)< >> http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in= >> >> ter-as-psp-protect-timing.html> >> >> Inter-AS >> >> Proposal >> >> - mjsraman-panet-pce-power-mcast-replic< >> http://tools.ietf.org/html/draft= >> >> -mjsraman-panet-pce-power-mcast-replic> >> >> (timeline)< >> http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-pc= >> >> e-power-mcast-replic-timing.html> >> >> Multicast >> >> - mjsraman-panet-pim-power< >> http://tools.ietf.org/html/draft-mjsraman-pan= >> >> et-pim-power> >> >> (timeline)< >> http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-pi= >> >> m-power-timing.html> >> >> Multicast >> >> - mjsraman-panet-tcam-power-efficiency< >> http://tools.ietf.org/html/draft-= >> >> mjsraman-panet-tcam-power-efficiency> >> >> (timeline)< >> http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-tc= >> >> am-power-efficiency-timing.html> >> >> TCAM >> >> related >> >> - mjsraman-panet-tcam-power-ratio< >> http://tools.ietf.org/html/draft-mjsra= >> >> man-panet-tcam-power-ratio> >> >> (timeline< >> http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-tca= >> >> m-power-ratio-timing.html>) >> >> TCAM related >> >> - mjsraman-pce-power-replic< >> http://tools.ietf.org/html/draft-mjsraman-pc= >> >> e-power-replic> >> >> (timeline)< >> http://www.arkko.com/tools/lifecycle/draft-mjsraman-pce-powe= >> >> r-replic-timing.html> >> >> Multicast >> >> - mjsraman-panet-intra-as-psp-te-leak< >> http://tools.ietf.org/html/draft-m= >> >> jsraman-panet-intra-as-psp-te-leak> >> >> (timeline)< >> http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in= >> >> tra-as-psp-te-leak-timing.html> >> >> Inter-Area >> >> within an AS >> >> - mjsraman-panet-ospf-power-topo< >> http://tools.ietf.org/html/draft-mjsram= >> >> an-panet-ospf-power-topo> >> >> (timeline)< >> http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-os= >> >> pf-power-topo-timing.html> >> >> Intra-Area >> >> within an AS >> >> >> >> We understand it is a lot of matter to go through. We would much >> appreciate >> >> if some of you could review the inter-AS proposals while others take up >> >> multicast and Intra-AS unicast and multicast. >> >> >> >> Thanks again for your time on this matter. >> >> >> >> thanks and regards, >> >> balaji venkat >> > _______________________________________________ >> > 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 > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > > --f46d0444709d9bc5df04d5242388 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Tom, Acee,

    Thank you for your comments.
    <= br>
    We are currently approaching IRTF for this very purpose.

    Additionally we would like to state that there are exi= sting mechanisms for aspects like delay (QoS) being additional metrics for = the computation of paths inter-AS and intra-AS. We feel that this additiona= l power metric can be handled in a way similar to how say aspects like dela= y are handled today.

    Since you have said that this approach has already been= tried out, we would request you to give us some of the citations which wil= l be of help to us. We have already searched literature available in the we= b today. In case we have missed out anything your citations would help us.<= /div>

    Thanks and regards,
    balaji venkat
    <= br>
    =A0

    On Thu, Feb 7, 2013 at = 8:49 PM, Acee Lindem <acee.lindem@ericsson.com> wrote= :
    +1=A0
    Acee=A0

    On Feb 7, 2013, at 10:06 AM, Thomas Nadeau wrote:


    The other problem with this (fr= ankly naive approach which has been investigated by many) is that yes, whil= e adding in another constraint to the metric computation, it may result in = unexpected consequences. =A0 =A0This is why it is likely to be more suitable as an IRTF topic of re= search until those "details" are sorted out.=A0

    --Tom


    On Feb 7, 2013:5:52 AM, at 5:52 AM, Balaji venkat Venkataswami <balajivenkat299= @gmail.com> wrote:

    Dear Hannes,

    We are familiar with the presentation that you have referred to.

    I have 3 questions for you.

    a) While we agree with the presentation that you have mentioned, can w= e in the IETF have control over the home appliances and subscriber line kit= ? Is there a methodology by which we can optimize the power consumption on= these devices ?

    b) The problem space that the IETF can take up can be only in the edge= and core devices in the ISP networks and the Campus/DC/Metro etc...Assume = that I have n devices today with the same bandwidth offering but differing = power consumption
    footprint, is there a way today to automatically send traffic through = low power paths in the topology of these devices.

    c) So we can optimize power only on what we can control. What are your= views on this ?

    thanks and regards,
    balaji venkat=A0

    On Thu, Feb 7, 2013 at 6:37 PM, Hannes Gredler <= span dir=3D"ltr"> <hannes@juniper.= net> wrote:
    balaji,

    may i put your attention to a talk that =A0francois lemarchand
    gave on future net 2010.
    https://www.dropbox.com/s/3jb9au2zca4nl3x/10_fn_S29.pdf
    contains a copy.

    slide 2 initially shows that the core and edge layer might be appealing
    due to their per-box power print. however slide 15 discusses the
    big picture where 99.99% of the power is burned by the home
    appliances and subscriber line kit.

    Do you think that optimizing a part of the network which gives only limited=
    overall savings is a worthwhile goal ? Note that SPs already ask their vend= ors
    about reducing the power footprint of those core devices by improved, (some= times
    less functional) silicon forwarding engines.

    /hannes

    On Feb 6, 2013, at 7:41 PM, Curtis Villamizar wrote:

    >
    > Balaji,
    >
    > "We" in the context of your first paragraph seems to be a > misrepresentation. =A0The authors of all of these drafts seem to be fr= om
    > the same university in India. =A0From prior attempts on your part to g= et
    > a draft of this sort into IDR and a brief reading of a few of the
    > drafts that you have just submitted, you don't seem to have a good=
    > understanding of how networks are built and how network equipment is > built from which to begin to attack the problem of reducing the power<= br> > consumption of these networks.
    >
    > If you want to try to advance a research paper with your theories on > power reduction, please choose an appropriate venue such as a refereed=
    > technical journal.
    >
    > Curtis
    >
    >
    > In message <CAHF4apO9bEkPk7QwA9fgJq9= BNUNHNv+OFon_9_4Oij61e11r9w@mail.gmail.com>
    > Balaji venkat Venkataswami writes:
    >
    >> Dear all,
    >>
    >> We are a group of research and industry individuals tied together = with a
    >> common goal towards reducing the energy consumption in the core an= d edge
    >> networks.
    >>
    >> We present a metric-based hierarchical approach to reduce power co= nsumption
    >> in core and edge networks. The proposal considers both unicast and= the
    >> multicast cases. For unicast, the metric considered is *consumed-p= ower to
    >> available-bandwidth* and for multicast the metric is *consumed-pow= er to
    >> available-replication-capacity.*
    >>
    >> With unicast, the metric is used to determine a low-power path bet= ween
    >> sources and destinations. With multicast, the metric serves the tw= in
    >> purpose of finding low-power multicast paths as well as multicast<= br> >> replication points. =A0We evolve multiple techniques at various hi= erarchical
    >> levels. One at the Inter-AS level, Inter-Area level within the AS = and
    >> intra-Area within an AS. Additionally, the proposed method can als= o be used
    >> to determine disjoint or redundant paths for load balancing or fau= lt
    >> tolerance. Additionally since TCAMs are one of the biggest power g= uzzlers
    >> in all the components on a router/switch, we have presented a solu= tion for
    >> intra-AS purposes to use the TCAM according to the traffic matrix = passing
    >> through the system and shut down those TCAM banks that are unused.= With
    >> this in mind, we have also advocated taking into account a TCAM-PO= WER-Ratio
    >> in order to compute the paths from source to destination based on = this
    >> metric. Once low-power paths, in either the unicast or the multica= st cases,
    >> are identified then currently available traffic engineering techni= ques
    >> could be used to route the data packets. In the case of inter-AS B= GP path
    >> selection is also modified to arrive at paths which are low-power = paths.
    >>
    >> Our main objective is as follows...
    >>
    >> We now outline four important aspects that any approach for power = reduction
    >> should be capable of addressing.
    >>
    >> *Should cater for both unicast and multicast scenarios*
    >>
    >> Multicast provides an important scenario for the Internet. Today, = most
    >> proposals consider mainly low-power path routing with unicast traf= fic.
    >> Multicast traffic has received a lot of attention in wireless netw= orks, but
    >> not in the wired domain. Any new proposal should be able to addres= s both
    >> the unicast and the multicast traffic scenarios. Having different = methods
    >> for these two scenarios might lead to unnecessary processing burde= n in the
    >> routers, which might hinder its scalability.
    >>
    >> *Should not rely on just switching off unused links*
    >>
    >> Most approaches to optimize energy pursue the following approach: = measure,
    >> monitor and respond to the system energy usage by switching off un= used or
    >> under-utilized links. Such an approach could be effective for redu= cing
    >> power locally. The effect on the network is not clearly understood= .
    >> Further, the power usage involved in turning on and rebooting/reco= nfiguring
    >> the device is often not explicitly considered. We note that Servic= e Level
    >> Agreement (SLA) requirements may not even permit the links to be s= witched
    >> off. Also services provided by ISPs like Virtual Private Networks = (VPNs)
    >> can be affected by such re-routing decisions.
    >>
    >> *Should follow an hierarchical and distributed approach*
    >>
    >> For scalability, it is important that the algorithms proposed for = inter-AS
    >> should also be applicable to intra-AS situations. Networks do not = work in
    >> isolation, so any proposal should be both distributed and hierarch= ical. The
    >> algorithms should be applicable at every level of the hierarchy. >>
    >> *Should =A0provide incentives for ISP for adoption*
    >>
    >> The engineering proposals should be aligned with commercial incent= ives for
    >> rapid and widespread adoption. Today, the device manufacturers and= the ISPs
    >> operate independently of each other, and there is no incentive for=
    >> manufacturers to work towards low-power and high bandwidth devices= . An
    >> ISP=3D92s revenue model is based on the consumed bandwidth, which = in turn lea=3D
    >> d
    >> naturally to more power consumption. If the proposed method choose= s routers
    >> that consume low-power and increase the data flow through them, th= en this
    >> indirectly provides encouragement for ISPs to purchase low-power a= nd high
    >> bandwidth devices.
    >>
    >>
    >>
    >> We now present our metric-based proposals in the below mentioned d= rafts
    >> which addresses the aforementioned design aspects.
    >>
    >> We would like the routing community to provide feedback on these d= rafts. We
    >> also intend to present this work in an abridged format in the upco= ming IETF=3D
    >> .
    >>
    >> The drafts are as follows....
    >>
    >>
    >>
    >>
    >> =A0 - mjsraman-panet-bgp-power-path<http://tools.ietf.org/html/d= raft-mjsrama=3D
    >> n-panet-bgp-power-path>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-bg=3D
    >> p-power-path-timing.html>
    >> =A0 =A0Inter-AS-Proposal
    >> =A0 - mjsraman-panet-ecmp-redirect-power-repl-cap<http://tools.ietf.org/html= =3D
    >> /draft-mjsraman-panet-ecmp-redirect-power-repl-cap>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-ec=3D
    >> mp-redirect-power-repl-cap-timing.html>
    >> =A0 =A0Multicast
    >> =A0 - mjsraman-panet-inter-as-power-source<http://tools.ietf.org/html/d= raft-=3D
    >> mjsraman-panet-inter-as-power-source>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-in=3D
    >> ter-as-power-source-timing.html>
    >> Inter-AS
    >> =A0 Proposal
    >> =A0 - mjsraman-panet-inter-as-psp<http://tools.ietf.org/html/d= raft-mjsraman-=3D
    >> panet-inter-as-psp>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-in=3D
    >> ter-as-psp-timing.html>
    >> Inter-AS
    >> =A0 Proposal
    >> =A0 - mjsraman-panet-inter-as-psp-protect<http://tools.ietf.org/html/d= raft-m=3D
    >> jsraman-panet-inter-as-psp-protect>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-in=3D
    >> ter-as-psp-protect-timing.html>
    >> Inter-AS
    >> =A0 Proposal
    >> =A0 - mjsraman-panet-pce-power-mcast-replic<http://tools.ietf.org/html/d= raft=3D
    >> -mjsraman-panet-pce-power-mcast-replic>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-pc=3D
    >> e-power-mcast-replic-timing.html>
    >> =A0 =A0Multicast
    >> =A0 - mjsraman-panet-pim-power<http://tools.ietf.org/html/d= raft-mjsraman-pan=3D
    >> et-pim-power>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-pi=3D
    >> m-power-timing.html>
    >> =A0 =A0Multicast
    >> =A0 - mjsraman-panet-tcam-power-efficiency<http://tools.ietf.org/html/d= raft-=3D
    >> mjsraman-panet-tcam-power-efficiency>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-tc=3D
    >> am-power-efficiency-timing.html>
    >> TCAM
    >> =A0 related
    >> =A0 - mjsraman-panet-tcam-power-ratio<http://tools.ietf.org/html/d= raft-mjsra=3D
    >> man-panet-tcam-power-ratio>
    >> =A0 =A0(timeline<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-tca=3D
    >> m-power-ratio-timing.html>)
    >> =A0 TCAM related
    >> =A0 - mjsraman-pce-power-replic<http://tools.ietf.org/html/d= raft-mjsraman-pc=3D
    >> e-power-replic>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-pce-powe=3D
    >> r-replic-timing.html>
    >> =A0 =A0Multicast
    >> =A0 - mjsraman-panet-intra-as-psp-te-leak<http://tools.ietf.org/html/d= raft-m=3D
    >> jsraman-panet-intra-as-psp-te-leak>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-in=3D
    >> tra-as-psp-te-leak-timing.html>
    >> Inter-Area
    >> =A0 within an AS
    >> =A0 - mjsraman-panet-ospf-power-topo<http://tools.ietf.org/html/d= raft-mjsram=3D
    >> an-panet-ospf-power-topo>
    >> =A0 =A0(timeline)<http://www.arkko.com/tools= /lifecycle/draft-mjsraman-panet-os=3D
    >> pf-power-topo-timing.html>
    >> Intra-Area
    >> =A0 within an AS
    >>
    >> We understand it is a lot of matter to go through. We would much a= ppreciate
    >> if some of you could review the inter-AS proposals while others ta= ke up
    >> multicast and Intra-AS unicast and multicast.
    >>
    >> Thanks again for your time on this matter.
    >>
    >> thanks and regards,
    >> balaji venkat
    > _______________________________________________
    > rtgwg mailing list
    > rtgwg@ietf.org=
    > https://www.ietf.org/mailman/listinfo/rtgwg
    >



    _______________________________________________
    rtgwg mailing list
    rtgwg@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/rtgwg

    _______________________________________________
    rtgwg mailing list
    rtgwg@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/rtgwg


    --f46d0444709d9bc5df04d5242388-- From eosborne@cisco.com Thu Feb 7 07:49:04 2013 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 BB41821F84E4 for ; Thu, 7 Feb 2013 07:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.284 X-Spam-Level: X-Spam-Status: No, score=-10.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRGfturgNH0e for ; Thu, 7 Feb 2013 07:49:01 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BF03921F84D1 for ; Thu, 7 Feb 2013 07:49:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30064; q=dns/txt; s=iport; t=1360252140; x=1361461740; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=k9GU6wtAxKD3X1JONc1OfCiKyEUr50F1UI6TF45W/2U=; b=LyHvVcj1COGPhKGnKKJcpBApjVx1bZrBQdIgkuegxjUoqLznWopR1pHi SjSwccbegmWV4lQyQbXsGjNLT1GoZFyfllQLKkDWHMIXeaHeS0RHhDenC C1T2jmvP8qW6HXd5mR/neegHwEoq5nE0z/e6GeTigTVKCOi5tWv/aUB6c k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAPzLE1GtJV2b/2dsb2JhbABFFoYzuSd3FnOCGAcBAQECAhgCCREzAwEIBgwEAgEIDgMEAQEBAgIGCxIDAgICHxEUAQgIAgQBDQUIDAcBBIUpB4IvAw8MrDuIdg2JVoEjinN9ARABgQKCIjJhA5IuOoFhgnWKIgOFEIMAgW81 X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; d="scan'208";a="174549651" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 07 Feb 2013 15:48:59 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r17FmxBh020517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Feb 2013 15:48:59 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 09:48:59 -0600 From: "Eric Osborne (eosborne)" To: Shankar Raman , Balaji Venkat Subject: RE: Power aware networks : Comments requested from routing community Thread-Topic: Power aware networks : Comments requested from routing community Thread-Index: AQHOBJmILt1Dff9vjkCrdfxQNrUVWphtkbkA//+h48CAAPPu4IAAY5NA Date: Thu, 7 Feb 2013 15:48:58 +0000 Message-ID: <20ECF67871905846A80F77F8F4A27572100BF86F@xmb-rcd-x09.cisco.com> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <20ECF67871905846A80F77F8F4A27572100BEE0B@xmb-rcd-x09.cisco.com> <3B74A0857EB0496E8FA8B026A758D788@NCSVAIO> In-Reply-To: <3B74A0857EB0496E8FA8B026A758D788@NCSVAIO> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.23.84] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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, 07 Feb 2013 15:49:04 -0000 VGhlIHJvb3Qgb2YgeW91ciBwb3NpdGlvbiBzZWVtcyB0byBiZSB0aGF0IGlmIHlvdSBkb24ndCB1 c2UgYSBsaW5rLCB5b3UgY29uc3VtZSBsZXNzIHBvd2VyLCBhbmQgdGh1cyBhdm9pZGluZyBjZXJ0 YWluIGxpbmtzIG1lYW5zIGNvbnN1bWluZyBsZXNzIHBvd2VyIG1lYW5zIHNhdmluZyBtb25leS4N Cg0KSSBzZWUgdHdvIHByb2JsZW1zIHdpdGggdGhpczoNCg0KMSkgSSdtIG5vdCBzdXJlIHRoYXQn cyBhY3R1YWxseSB0cnVlLiAgU09ORVQsIGZvciBvbmUsIHNlbmRzIGVtcHR5IGZyYW1lcyB3aGVu IHRoZXJlJ3Mgbm8gZGF0YSwgc28gdGhlIGxhc2VyIGlzIGFsd2F5cyBmaXJpbmcuDQoNCjIpIGV2 ZW4gaWYgaXQgd2FzIHRydWUsIG9yIGlmIHlvdSBoYWQgc29tZSBhbmFsb2d1ZSB0byA4MDIuM2F6 IHRoYXQgeW91IGNvdWxkIHVzZSBpbiBiYWNrYm9uZXMsIEkgZG9uJ3QgYmVsaWV2ZSB5b3UnZCBz YXZlIGFueXdoZXJlIG5lYXIgZW5vdWdoIG1vbmV5IHRvIG1ha2UgaXQgd29ydGggaXQuICANCg0K Rm9yICMxLCBwbGVhc2UgZXhwbGFpbiB0aGUgY2lyY3Vtc3RhbmNlcyB1bmRlciB3aGljaCBsZWF2 aW5nIGEgbGluayBpZGxlIHNhdmVzIHBvd2VyLCBhbmQgZXhwbGFpbiBob3cgbXVjaCBwb3dlciBh bmQgd2hhdCBkcml2ZXMgdGhhdCBwb3dlciBkcmF3Lg0KDQpGb3IgIzIsIHBsZWFzZSBzZWUgbXkg ZXhhbXBsZSBpbiBteSBvcmlnaW5hbCBlbWFpbC4NCg0KDQoNCg0KZXJpYw0KDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2hhbmthciBSYW1hbiBbbWFpbHRvOm1qc3Jh bWFuQGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA3LCAyMDEzIDQ6NDgg QU0NCj4gVG86IEJhbGFqaSBWZW5rYXQ7IEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpDQo+IENjOiBj dXJ0aXNAb2NjbmMuY29tOyBydGd3Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogUG93ZXIgYXdh cmUgbmV0d29ya3MgOiBDb21tZW50cyByZXF1ZXN0ZWQgZnJvbSByb3V0aW5nDQo+IGNvbW11bml0 eQ0KPiANCj4gRGVhciBFcmljLA0KPiBMb29rcyBsaWtlIHdlIGhhdmUgbm90IGJlZW4gY2xlYXIg aW4gY29udmV5aW5nIG91ciBpZGVhLg0KPiANCj4gV2UgYWJzdHJhY3QgdGhlIHBvd2VyIGNvbnN1 bWVkIGJ5IGV2ZXJ5IHJvdXRlci9zd2l0Y2gsIHVzZSBpdCBhcyB0aGUgcG93ZXINCj4gcmF0aW5n LiBXZSB0aGVuIGFzc2lnbiBpdCB0byB0aGUgbGluayBhcyBhIG1ldHJpYyBjaGFyYWN0ZXJpc3Rp YyB0byBnZXQgYWxnb3JpdGhtcw0KPiBsaWtlIFNQRiBhbmQgQ1NQRiB0byBjaG9vc2UgdGhlIGxv d2VzdCBwb3dlciBwYXRocyBvciBhbnkgbWV0cmljIGJhc2VkIHJvdXRpbmcNCj4gYWxnb3JpdGht Lg0KPiANCj4gU28gdGhlIGxpbmsgbWV0cmljIGlzIGEgY29tYmluYXRpb24gb2YgcG93ZXIgY29u c3VtZWQgaW5jbHVkaW5nIHRoZSBwaHlzaWNhbA0KPiBsaW5rIGFuZCByb3V0ZXIgY29tcG9uZW50 cy4gSW4gZWZmZWN0IHRoZSBsaW5rIG1ldHJpYyBpcyBub3QganVzdCB0aGUgcGh5c2ljYWwNCj4g bGlua+KAmXMgbWV0cmljIGFsb25lIChidXQgdGhlIGNvc3Qgb2YgdGhlIHBvd2VyIGNvbnN1bWVk IGJ5IHRoZSByb3V0ZXIvc3dpdGNoIG9uDQo+IHdoaWNoIGl0IGNvbm5lY3RzIHRvIHRoZSBuZWln aGJvcikuDQo+IA0KPiBKdXN0IGxpa2Ugcm91dGluZyBwcm90b2NvbHMgY29uc2lkZXIgZGVsYXks IGhvcHMgYXMgbWV0cmljIHdlIGNvbnNpZGVyIHRoaXMNCj4gcG93ZXIgY29uc3VtcHRpb24gYXMg eWV0IGFub3RoZXIgbWV0cmljLg0KPiANCj4gVGhhbmtzDQo+IFNoYW5rYXINCj4gDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJhbGFqaSBWZW5rYXQNCj4gU2VudDogVGh1 cnNkYXksIEZlYnJ1YXJ5IDA3LCAyMDEzIDI6MzYgQU0NCj4gVG86IEVyaWMgT3Nib3JuZSAoZW9z Ym9ybmUpDQo+IENjOiBjdXJ0aXNAb2NjbmMuY29tIDsgU2hhbmthciBSYW1hbiBNIEogOyBydGd3 Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogUG93ZXIgYXdhcmUgbmV0d29ya3MgOiBDb21tZW50 cyByZXF1ZXN0ZWQgZnJvbSByb3V0aW5nDQo+IGNvbW11bml0eQ0KPiANCj4gRGVhciBFcmljLA0K PiANCj4gQ29tbWVudHMgaW5saW5lLi4uDQo+IA0KPiBTZW50IGZyb20gbXkgaVBhZA0KPiANCj4g T24gMDctRmViLTIwMTMsIGF0IDE6NTAgQU0sICJFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSINCj4g PGVvc2Jvcm5lQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiA+IFlvdSBhaW0gdG8gb3B0aW1pemUg Y29yZSBuZXR3b3JrcyB0aHJvdWdoIHRyYWZmaWMgZW5naW5lZXJpbmcgc3VjaCB0aGF0DQo+IHNv bWUgbGlua3MgY2FuIGJlIHNodXQgZG93biB3aGVuIG5vdCBpbiB1c2UsIG9yIHN3aXRjaGVkIHRv IGxvd2VyIHBvd2VyLg0KPiANCj4gQWN0dWFsbHkgdGhlIGFuc3dlciBpcyBhIE5vLiBXZSBkbyBu b3QgYWR2b2NhdGUgdGhpcyBhcHByb2FjaC4gVGhlIG1haW4gaWRlYQ0KPiBpbiBiZ3AgcG93ZXIg cGF0aCBkcmFmdCBoYXMgYSBzdXJ2ZXkgc2VjdGlvbiBvbiBwcmV2aW91cyBsaXRlcmF0dXJlIHRo YXQgd2UNCj4gcXVvdGUgZm9yIHJlZmVyZW5jZSBhbmQgc3RhdGUgdGhhdCBzdWNoIGFwcHJvYWNo ZXMgY2F1c2UgZXhwZW5zaXZlIGVxdWlwbWVudA0KPiB0byBiZSBrZXB0IHVudXNlZC4gWW91IGhh dmUgcXVvdGVkIHRoZSBzdXJ2ZXkgc2VjdGlvbiBvZiB0aGUgcGFwZXIgaW4gdGhlDQo+IGFib3Zl IHNlbnRlbmNlLg0KPiANCj4gPg0KPiA+IEhhdmUgeW91IGRvbmUgc3R1ZGllcyBpbiBjb3JlIG5l dHdvcmtzIHdpdGggcmVhbCBlcXVpcG1lbnQgdGhhdCBzaG93IHRoZQ0KPiBhY3R1YWwgYW1vdW50 IG9mIG1vbmV5IHlvdSBjb3VsZCBzYXZlIHdpdGggdGhpcyBhcHByb2FjaD8gIExldCdzIHdhbGsg dGhyb3VnaA0KPiBhIHF1aWNrIGh5cG90aGV0aWNhbCBuZXR3b3JrLCB5b3UgdGVsbCBtZSB3aGVy ZSBJIGdvdCBpdCB3cm9uZy4NCj4gPg0KPiA+IGRyYWZ0LW1qc3JhbWFuLXBhbmV0LWJncC1wb3dl ci1wYXRoIHNheXMgIiBQb3dlciBjb25zdW1wdGlvbiBjYW4gYmUNCj4gPiAgIHJlZHVjZWQgYnkg dHJhZGluZyBvZmYgcGVyZm9ybWFuY2UgcmVsYXRlZCBtZWFzdXJlcyBsaWtlIGxhdGVuY3kuIEZv cg0KPiA+ICAgZXhhbXBsZSwgcG93ZXIgc2F2aW5ncyB3aGlsZSBzd2l0Y2hpbmcgZnJvbSAxIEdi cHMgdG8gMTAwIE1icHMgaXMNCj4gPiAgIGFwcHJveGltYXRlbHkgNCBXIGFuZCBmcm9tIDEwMCBN YnBzIHRvIDEwIE1icHMgYXJvdW5kIDAuMSBXYXR0cy4iDQo+IA0KPiBBZ2FpbiB0aGlzIGlzIGEg c3VydmV5IHNlY3Rpb24gb2YgdGhlIHBhcGVyIHN1cnZleWluZyB0aGUgZXhpc3RpbmcgYXBwcm9h Y2hlcy4NCj4gDQo+ID4NCj4gPiBidXQgcHJvdmlkZXMgbm8gZG9jdW1lbnRhdGlvbiB0byBiYWNr IHRoZXNlIGNvc3RzIHVwIG5vciBpdGVtaXphdGlvbg0KPiA+IG9mIHdoZXJlIHRoZSBwb3dlciBp cyBjb25zdW1lZCAoYW1vcnRpemVkIGFjcm9zcyB0aGUgcm91dGVyPyAgbGluZWNhcmQNCj4gPiBv cHRpY3M/ICBEV0RNIGdlYXI/KQ0KPiANCj4gT3VyIG1haW4gaW50ZW50IGlzIHRvIGFsbG93IHRy YWZmaWMgdG8gZm9sbG93IGxvdyBwb3dlciBwYXRocyB0aHJvdWdoIEFTcyAoZWl0aGVyDQo+IHRo cm91Z2ggcGNlIGxpa2UgZW50aXRpZXMgb3IgdGhyb3VnaCBtb2RpZnlpbmcgdGhlIGJncCBwYXRo IHNlbGVjdGlvbg0KPiBhbGdvcml0aG0pIHdoaWNoIGNvbnN1bWUgdGhlIGxlYXN0IHBvd2VyIGFu ZCBwb3NzZXNzIHRoZSByZXF1aXJlZCBiYW5kd2lkdGguDQo+IEJ5IGdyYXBoaW5nIHRoZSB0b3Bv bG9neSBvZiBhIHNldCBBU3MgaW4gdGhlIGltbWVkaWF0ZSBuZWlnaGJvdXJob29kIHVzaW5nDQo+ IGFzLXBhdGgtaW5mbyBzdHJhbmRzIHR5cGljYWxseSBmb3IgYSBwcm92aWRlciBtYW5uaW5nIG11 bHRpcGxlIEFTcyB3aXRoaW4gdGhlDQo+IHByb3ZpZGVycyBvd24gY29udHJvbCB0aGlzIG1lY2hh bmlzbSB3aWxsIGxldCBsYXJnZSBjaHVua3Mgb2YgdHJhZmZpYyBiZWxvbmdpbmcNCj4gdG8gYSBt YWNybyBGRUMgdHJhdmVyc2Ugc3VjaCBsb3cgcG93ZXIgQVNzIHRocm91Z2ggYW4gaW50ZXItYXMg dGUgTVBMUyBsc3ANCj4gY29tcHV0ZWQgYnkgYSBwY2UgbGlrZSBlbnRpdHkgYW5kIHNldHVwIGJ5 IFJTVlAtdGUuDQo+IA0KPiBUaGUgdXNlIG9mIHRoZSBtZXRyaWMsIHRoZSB3YXkgdGhlIHB3ciBt ZXRyaWMgaXMgYXJyaXZlZCBhdCAsIHRoZSBjb21wdXRhdGlvbiBvZg0KPiB0aGUgdG9wb2xvZ3kg b2YgQVNzLCBjb25zZXF1ZW50IENTUEYgYW5kIHRoZW4gbWFwcGluZyB0aGUgdHJhZmZpYyB0byB0 aGUNCj4gY29uc3RydWN0ZWQgTFNQIGlzIHRoZSBtYWluIGZvY3VzIGlmIHRoaXMgcGFwZXIuIEZv ciBkYW1wZW5pbmcgZmx1Y3R1YXRpb25zIGluDQo+IHRoZSBtZXRyaWMgd2hpY2ggYXJlIGZyZXF1 ZW50IGhldXJpc3RpY3MgYWxnb3JpdGhtcyBhcmUgc3VnZ2VzdGVkLg0KPiANCj4gQnkgbm8gbWVh bnMgYXJlIHdlIGFkdm9jYXRpbmcgc2h1dHRpbmcgb2ZmIGxpbmtzLiBUaGlzIHNjaGVtZSBmYWNp bGl0YXRlcyBldmVuDQo+IHRoZSBmb2xsb3cgdGhlIG1vb24gc3RyYXRlZ3kgbmF0dXJhbGx5Lg0K PiANCj4gDQo+ID4NCj4gPiBMZXQncyBhc3N1bWUgdGhhdCB0aGlzIGlzIHRydWUgYW5kIHRoYXQg aXQgaXMgbGluZWFyLCBzbyB0aGF0IHlvdSBidXJuDQo+ID4gNFcgcGVyIEdiLiAgKHNpZGUgbm90 ZTogSSBzdXNwZWN0IHRoaXMgaXMgaW5hY2N1cmF0ZSBhbmQgdGhhdCBzY2FsaW5nDQo+ID4gaXMg c3VibGluZWFyLCBidXQgbGV0J3MgZ28gd2l0aCBpdCBiZWNhdXNlIGlmIGl0J3Mgc3ViLWxpbmVh ciB5b3UgaGF2ZQ0KPiA+IGV2ZW4gbGVzcyBvZiBhIHVzZSBjYXNlLiAgSSBhbHNvIHRoaW5rIHRo ZSByZWFsIHdvcmxkIGlzIGZhciBtb3JlDQo+ID4gY29tcGxleCwgYXMgeW91IGhhdmUgYWxsIHRo ZSBvcHRpY2FsIHRyYW5zcG9ydCBnZWFyIHRvIHdvcnJ5IGFib3V0Lg0KPiA+IEJ1dCBsZXQncyBn byB3aXRoIGl0IGZvciBub3cuKQ0KPiA+DQo+ID4gUnVubmluZyBhIDEwMEdiIGxpbmsgdGh1cyBk cmF3cyA0MDBXLg0KPiA+DQo+ID4gTGV0J3Mgc2F5IHlvdSBoYXZlIGEgYmFja2JvbmUgd2l0aCAo MzAwKSAxMDBHYiBsaW5rcy4gIFRvdGFsIHBvd2VyDQo+ID4gY29uc3VtcHRpb24gaXMgdGh1cyAo MzAwKjQwMCkgPT0gMTIwIGtXDQo+ID4NCj4gPiBSdW5uaW5nIGFsbCB0aGVzZSBsaW5rcyBmb3Ig MjQgaG91cnMgdGh1cyBkcmF3cyAxMjAqMjQgPT0gMiw4ODAga1doDQo+ID4gPT0gMi44bVdoIFBv d2VyIGNvc3RzIGFyZSBtYXliZSAkMC4xMC9rV2ggaW4gdGhlIFVTLiAgRG91YmxlIHRoYXQgdG8N Cj4gY292ZXIgdGhlIGNvc3Qgb2YgY29vbGluZywgc28gJDAuMjAva1doLg0KPiA+IFRodXMsIHJ1 bm5pbmcgdGhlIGVudGlyZSBiYWNrYm9uZSBjb3N0cyAkMC4yICogMiw4ODAgPSAkNTc2L2RheS4N Cj4gJDIxMCwwMDAveWVhci4NCj4gPiBMZXQncyBzYXkgeW91ciBhcHByb2FjaCBjYW4gc2F2ZSBv bmUgdGhpcmQgb2YgdGhlIHBvd2VyIGNvc3QsIHdoaWNoIG1lYW5zDQo+IGFib3V0ICQ3MCwwMDAu DQo+ID4NCj4gDQo+IA0KPiANCj4gPiBBbiBvcGVyYXRvciB3aXRoIDMwMCAxMDBHYiBsaW5rcyBp biBhIG5ldHdvcmsgaGFzIGh1bmRyZWRzIG9mIG1pbGxpb25zIG9mDQo+IGRvbGxhcnMgd29ydGgg b2YgZ2VhciBhbmQgbWlsbGlvbnMgb3IgdGVucyBvZiBtaWxsaW9ucyBpbiBwYXlyb2xsIGFsb25l LiAgSWYgeW91IGN1dA0KPiAkNzBrIGZyb20gdGhlaXIgb3BleCB0aGV5IHByb2JhYmx5IHdvdWxk bid0IGV2ZW4gbm90aWNlLiAgVGhhdCdzIG9uZSBvciB0d28NCj4gc2FsYXJpZXMsIG9yIDAuMDAy JSBvZiB3aGF0IFRpbWUgV2FybmVyIHNwZW50IG9uIGFkdmVydGlzaW5nIGluIDIwMDYgKHNlZToN Cj4gaHR0cDovL2dhaWEuYWRhZ2UuY29tL2ltYWdlcy9yYW5kb20vRmFjdFBhY2swNi5wZGYpLiAg SXQgaXMgYSBkcm9wIGluIHRoZQ0KPiBidWNrZXQsIGlmIHRoYXQuICBBbmQgeW91ciBwcm9wb3Nh bCBjb21lcyB3aXRoIHNpZ25pZmljYW50IHdvcmsgYXR0YWNoZWQgdG8gaXQsDQo+IGFuZCBzaWdu aWZpY2FudCByaXNrLiAgSWYgeW91ciA0MCB5ZWFycyBvZiBleHBlcmllbmNlIGluIHRoZSBuZXR3 b3JrIGluZHVzdHJ5IGRvbid0DQo+IGhlbHAgeW91IHVuZGVyc3RhbmQgdGhlIHJpc2tzIHlvdSdy ZSBhc2tpbmcgYW4gb3BlcmF0b3IgdG8gdGFrZSB0aGVuIHlvdSdyZQ0KPiBtaXNzaW5nIGEgY3J1 Y2lhbCBwYXJ0IG9mIGFueSBwb3RlbnRpYWwgcmVhbCB3b3JsZCBzb2x1dGlvbi4gIEkgZG8gbm90 IHRoaW5rIHlvdXINCj4gd29yayBzaG91bGQgYmUgcHJlc2VudGVkIGF0IHRoZSBJRVRGIHVubGVz cyBpdCBtYWtlcyBhIG11Y2ggc3Ryb25nZXINCj4gYXJndW1lbnQgdGhhdCBpdHMgYmVuZWZpdHMg b3V0d2VpZ2ggaXRzIGNvc3RzLg0KPiANCj4gQWdhaW4gd2UgYXJlIG5vdCBhc2tpbmcgdGhlIG9w ZXJhdG9yIHRvIHNodXQgb2ZmIHRoZSBlcXVpcG1lbnQuIEhlIG5lZWRzIHRvDQo+IGtlZXAgaXQg cnVubmluZyBhcyBsb25nIGFzIGhlIGhhcyB0cmFmZmljIHRvIGNhcnJ5IGV4Y2VwdCB0aGF0IHRo ZSBwY2UgbWFrZXMgYQ0KPiBjb21wdXRhdGlvbiBldmVyeSB0aW1lIGEgbGFyZ2UgRkVDIG9mIHRy YWZmaWMgbmVlZHMgdG8gYmUgY2FycmllZCB0aHJvdWdoIGhpcw0KPiBBU3MgdGhyb3VnaCBhIHBh dGggdGhhdCBjb25zdW1lcyB0aGUgbGVhc3QgcG93ZXIgd2l0aCB0aGUgbGlua3MgdGhlcmVpbiBo YXZpbmcNCj4gdGhlIHJlcXVpcmVkIGJhbmR3aWR0aC4gVGhlIHJhdGlvIG9mIGNvbnN1bWVkIHBv d2VyIHRvIHRoZSBhdmFpbGFibGUNCj4gYmFuZHdpZHRoIGlzIHRoZSBtZXRyaWMgdGhhdCBpcyB1 c2VkLiBDb25zdW1lZCBwb3dlciByZWxhdGVzIHRvIGEgd2VpZ2h0ZWQNCj4gYXZlcmFnZSBvZiB0 aGUgcG93ZXIgY29uc3VtZWQgd2l0aGluIHRoZSBBUyBpbmNsdWRpbmcgdGhlIGVkZ2UgYW5kIGNv cmUNCj4gZGV2aWNlcyB3aGlsZSB0aGUgYXZhaWxhYmxlIGJ3IHJlbGF0ZXMgdG8gdGhlIGxpbmtz IGluZ3Jlc3NpbmcgaW50byB0aGUgQVMgYXQgdGhlDQo+IEFTQlJzIHRoYXQgYXJlIHRoZSBpbnRl ciBjb25uZWN0b3JzIGJldHdlZW4gdGhlIEFTZXMuDQo+IA0KPiANCj4gU28gaW4gc3VtbWFyeSwg d2UgZG8gbm90IGFkdm9jYXRlIHNodXR0aW5nIG9mZiBsaW5rcyBhdCBhbGwuIEluIGZhY3Qgd2Ug ZGlzYWdyZWUNCj4gd2l0aCB0aGF0IGFwcHJvYWNoLiBUaGUgc2NoZW1lIHdlIGFkdm9jYXRlIHRy aWVzIHRvIG9wdGltaXNlIHRoZSBwb3dlcg0KPiBjb25zdW1wdGlvbiB1c2luZyB0aGUgbWV0cmlj IGJhc2VkIGFwcHJvYWNoIHdpdGggc29tZSBoZXVyaXN0aWNzLg0KPiANCj4gSG9wZSB0aGlzIGhl bHBzLg0KPiANCj4gVGhhbmtzIGFuZCByZWdhcmRzLA0KPiBCYWxhamkgdmVua2F0DQo+ID4NCj4g PiBUaGVzZSBzb3J0cyBvZiBwb3dlciBvcHRpbWl6YXRpb25zIGFsbCBzZWVtIHRvIGJlICJoZXJl J3MgaG93IHlvdSByZXNoYXBlDQo+IHRoZSBwcm9ibGVtIHNvIHRoYXQgeW91IGNhbiB0aHJvdyBh IGxpbmVhciBwcm9ibGVtIHNvbHZlciBhdCBpdCIuICBGb3IgZXhhbXBsZSwNCj4gWyBodHRwOi8v d3d3LmNzLmJlcmtlbGV5LmVkdS9+c3VjaGFyYS9wdWJsaWNhdGlvbnMvR3JlZW5OZXRzQnVuZGxl cy5wZGYgXS4NCj4gSSd2ZSBuZXZlciBzZWVuIGFueXRoaW5nIHdoaWNoIHNob3dzIGhvdyBtdWNo IG1vcmUgd29yayBpdCB3aWxsIGJlIGZvciBhDQo+IG5ldHdvcmsgb3BlcmF0b3Igb3Igd2hpY2gg cXVhbnRpZmllcyB0aGUgYWN0dWFsIHNhdmluZ3MuDQo+ID4NCj4gPiBJZiB5b3UgY2FuIGRlbW9u c3RyYXRlIHNpZ25pZmljYW50IHNhdmluZ3MgaW4gcmVhbCBuZXR3b3JrcyBhdCBsaXR0bGUgb3Ig bm8gY29zdA0KPiB0byBvcGVyYXRvcnMsIHlvdSBoYXZlIGFuIGlkZWEgd29ydGggcHVyc3Vpbmcu ICBJZiB5b3VyIGlkZWEgd2lsbCBjYXVzZSBtb3JlDQo+IG9wZXJhdGlvbmFsIGFuZ3N0IChlLmcu IG5vdCBrbm93aW5nIHdoZXRoZXIgeW91ciB1bnVzZWQgY2FwYWNpdHkgd2lsbCBiZSB0aGVyZQ0K PiB3aGVuIHlvdSBuZWVkIGl0IGJlY2F1c2UgeW91IHNodXQgYSB0aGlyZCBvZiBpdCBvZmYgYWxs IHRoZSB0aW1lLCBpbmNyZWFzZWQgcmlzayBvZg0KPiBlcXVpcG1lbnQgZmFpbHVyZSBmcm9tIGNv bnN0YW50IHBvd2VyLWN5Y2xpbmcsIG9wZXJhdGlvbmFsIHRvb2xzIGFuZCB0cmFpbmluZw0KPiBh bmQgZXhwZXJ0aXNlIHJlcXVpcmVkIHRvIG1hbmFnZSwgZGVwbG95IGFuZCB0cm91Ymxlc2hvb3Qg dmFyaWFibGUtcG93ZXINCj4gbGlua3MgYW5kIHRoZSBjZW50cmFsaXplZCBOTVMgcmVxdWlyZWQg dG8gcnVuIHRoZW0sIGV0YyBldGMgZXRjKSB0aGVuIGl0IHdpbGwgZmluZA0KPiBsaXR0bGUgdHJh Y3Rpb24uICBHcmVlbi1URSBhbmQgcG93ZXItYXdhcmUgQkdQIGhhdmUgYmVlbiBmbG9hdGluZyBh cm91bmQgZm9yIGENCj4gd2hpbGUgYW5kIGhhdmUgc2VlbiBubyByZWFsIHVwdGFrZSBpbiB0aGUg V0dzIGFzIGZhciBhcyBJIGNhbiBzZWUuICBJcyB0aGF0IG5vdCB0bw0KPiBiZSB0YWtlbiBhcyBh biBpbmRpY2F0aW9uIHRoYXQgdGhlcmUgbWF5IGJlIG5vIHJlYWwtd29ybGQgaW50ZXJlc3QgaW4g dGhlbT8gIElmDQo+IG5vdCwgd2hhdCB3b3VsZCBpdCB0YWtlIHRvIGNvbnZpbmNlIHlvdT8NCj4g Pg0KPiA+DQo+ID4NCj4gPiBlcmljDQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+PiBGcm9tOiBydGd3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRnd2ct Ym91bmNlc0BpZXRmLm9yZ10gT24NCj4gPj4gQmVoYWxmIE9mIEJhbGFqaSB2ZW5rYXQgVmVua2F0 YXN3YW1pDQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDYsIDIwMTMgMTo1MyBQTQ0K PiA+PiBUbzogY3VydGlzQG9jY25jLmNvbQ0KPiA+PiBDYzogU2hhbmthciBSYW1hbiBNIEo7IHJ0 Z3dnQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBQb3dlciBhd2FyZSBuZXR3b3JrcyA6IENv bW1lbnRzIHJlcXVlc3RlZCBmcm9tIHJvdXRpbmcNCj4gPj4gY29tbXVuaXR5DQo+ID4+DQo+ID4+ IERlYXIgQ3VydGlzLA0KPiA+Pg0KPiA+PiBBcyBhbHJlYWR5IHN0YXRlZCB0byB5b3UgaW4gYSBw cml2YXRlIGVtYWlsLCAiV2UiIGFyZSBhIGdyb3VwIG9mDQo+ID4+IHBlb3BsZSB3aXRoIDQwIHll YXJzIG9mIGNvbGxlY3RpdmUgaW5kdXN0cnkgZXhwZXJpZW5jZSBpbiB0aGUNCj4gPj4gbmV0d29y a2luZyBpbmR1c3RyeS4gV2UgZG9udCBuZWVkIHRvIGJlIHBhdHJvbml6ZWQgYnkgYW55Ym9keSBz aW5jZQ0KPiA+PiB3ZSBoYXZlIGluZGVwZW5kZW50IG1pbmRzIHRoYXQgaGF2ZSB0aGUgY2FwYWJp bGl0eSB0byBkaWdlc3QNCj4gPj4gaW5mb3JtYXRpb24gbm90IGJhc2VkIG9uIHNvbWVib2R5IGVs c2UncyBpbnRlcnByZXRhdGlvbiBvZiBob3cgZnV0dXJlDQo+ID4+IG5ldHdvcmtzIG5lZWQgdG8g YmUgYnVpbHQgYW5kIGhvdyBwb3dlciByZWR1Y3Rpb24gbmVlZHMgdG8gcGxheSBhIHBhcnQgaW4N Cj4gaXQuDQo+ID4+DQo+ID4+IEFzIHlvdSBtaWdodCByZWNhbGwgb25lIHN1Y2ggcmVzZWFyY2gg cGFwZXIgb24gR3JlZW5URSBieSBCZWljaHVhbg0KPiA+PiBaaGFuZyByYW5nIGEgbG90IG9mIGJl bGxzIGluIHRoZSBJRVRGIGJ5IGNvbGxlY3RpbmcgdGhlIEFOUlAgcHJpemUuDQo+ID4+IFNvIHBs ZWFzZSBkb250IG1pc3N0YXRlIGZhY3RzIGFzIHlvdSBtaWdodCBrbm93IHRoZW0gYW5kIHNob3Zl IHlvdXINCj4gPj4gaWRlYXMgb2YgaG93IG5ldHdvcmtzIGFyZSBidWlsdCBkb3duIG91ciB0aHJv YXRzLg0KPiA+Pg0KPiA+PiBXZSB0aGluayB0aGUgSUVURiBpcyBhIGZyZWUgYW5kIGZhaXIgYm9k eSB0aGF0IGFjY2VwdHMgb3BpbmlvbnMgYW5kDQo+ID4+IGlkZWFzIGZyb20gYWxsIHNpZGVzLiBX ZSB3YW50IHRvIGtlZXAgdGhpcyBhIGZyZWUgYW5kIGZhaXINCj4gPj4gb3JnYW5pemF0aW9uLiBT byBpbmN1bWJlbnQgcGVvcGxlIGxpa2UgeW91IG91Z2h0IHRvIGVuY291cmFnZSB1cyBhbmQNCj4g Pj4gaGF2ZSBhIGZhaXIgYXJndW1lbnQgd2hlbiB3ZSBwcmVzZW50IHN1Y2ggd29yayB0byB5b3Uu IERvbnQgZm9sbG93IHRoZQ0KPiBwb2xpY3kgb2YgZXhjbHVzaW9uIHRvIHRoZSBudGggZGVncmVl Lg0KPiA+Pg0KPiA+PiBJdCBpcyBidXQgZmFpciB0byBzYXkgdGhhdCB5b3Ugc2VlbSB0byBiZSBp biBhIG1pbm9yaXR5IG9uIHRoaXMNCj4gPj4gbWF0dGVyLiBOb2JvZHkgZWxzZSByZXNwb25kZWQg d2l0aCB1bmtpbmQgbWlzc3RhdGVtZW50cyBvZiBmYWN0cyBhbmQNCj4gPj4gbWlzLXVuZGVyc3Rh bmRpbmcgb2Ygb3VyIHRlY2huaWNhbCBhbnRlY2VkZW50cy4NCj4gPj4NCj4gPj4gU3VmZmljZSB0 byBzYXkgdGhhdCBpZiB3ZSBnZXQgYW4gb3Bwb3J0dW5pdHkgdG8gcHJlc2VudCB0aGlzIChzaW5j ZQ0KPiA+PiBJRVRGIGlzIE9VUiBvcmdhbml6YXRpb24gdG9vKSB5b3UgbmVlZCBub3Qgc2l0IHRo cm91Z2ggaXQuIElmIHlvdQ0KPiA+PiB3YW50IHRvIGdpdmUgdXMgYSBmYWlyIGhlYXJpbmcgcGxl YXNlIGZvbGxvdyBhIHBvbGljeSBvZiBraW5kDQo+ID4+IGluY2x1c2lvbiBhbmQgbm90IGNyZWF0 ZSBhIHJ1Y2t1cyBhYm91dCB1cyByZXNlYXJjaCBmb2xrcyB0cnlpbmcgdG8NCj4gPj4gbWFrZSBh biBlYXJuZXN0IGF0dGVtcHQgYXQgc29tZSBwcmFjdGljYWwgcmVzZWFyY2ggdGhhdCBjb3VsZCB3 ZWxsIHNhdmUNCj4gdGhlIHBsYW5ldC4NCj4gPj4NCj4gPj4gWW91cnMgc2luY2VyZWx5LA0KPiA+ PiBUaGFua3MgYW5kIHJlZ2FyZHMsDQo+ID4+IGJhbGFqaSB2ZW5rYXQgYW5kIHNoYW5rYXIgcmFt YW4NCj4gPj4NCj4gPj4gT24gVGh1LCBGZWIgNywgMjAxMyBhdCAxMjoxMSBBTSwgQ3VydGlzIFZp bGxhbWl6YXIgPGN1cnRpc0BvY2NuYy5jb20+DQo+IHdyb3RlOg0KPiA+Pg0KPiA+Pg0KPiA+Pg0K PiA+PiAgICBCYWxhamksDQo+ID4+DQo+ID4+ICAgICJXZSIgaW4gdGhlIGNvbnRleHQgb2YgeW91 ciBmaXJzdCBwYXJhZ3JhcGggc2VlbXMgdG8gYmUgYQ0KPiA+PiAgICBtaXNyZXByZXNlbnRhdGlv bi4gIFRoZSBhdXRob3JzIG9mIGFsbCBvZiB0aGVzZSBkcmFmdHMgc2VlbSB0byBiZSBmcm9tDQo+ ID4+ICAgIHRoZSBzYW1lIHVuaXZlcnNpdHkgaW4gSW5kaWEuICBGcm9tIHByaW9yIGF0dGVtcHRz IG9uIHlvdXIgcGFydCB0byBnZXQNCj4gPj4gICAgYSBkcmFmdCBvZiB0aGlzIHNvcnQgaW50byBJ RFIgYW5kIGEgYnJpZWYgcmVhZGluZyBvZiBhIGZldyBvZiB0aGUNCj4gPj4gICAgZHJhZnRzIHRo YXQgeW91IGhhdmUganVzdCBzdWJtaXR0ZWQsIHlvdSBkb24ndCBzZWVtIHRvIGhhdmUgYSBnb29k DQo+ID4+ICAgIHVuZGVyc3RhbmRpbmcgb2YgaG93IG5ldHdvcmtzIGFyZSBidWlsdCBhbmQgaG93 IG5ldHdvcmsgZXF1aXBtZW50DQo+ID4+IGlzDQo+ID4+ICAgIGJ1aWx0IGZyb20gd2hpY2ggdG8g YmVnaW4gdG8gYXR0YWNrIHRoZSBwcm9ibGVtIG9mIHJlZHVjaW5nIHRoZSBwb3dlcg0KPiA+PiAg ICBjb25zdW1wdGlvbiBvZiB0aGVzZSBuZXR3b3Jrcy4NCj4gPj4NCj4gPj4gICAgSWYgeW91IHdh bnQgdG8gdHJ5IHRvIGFkdmFuY2UgYSByZXNlYXJjaCBwYXBlciB3aXRoIHlvdXIgdGhlb3JpZXMg b24NCj4gPj4gICAgcG93ZXIgcmVkdWN0aW9uLCBwbGVhc2UgY2hvb3NlIGFuIGFwcHJvcHJpYXRl IHZlbnVlIHN1Y2ggYXMgYQ0KPiA+PiByZWZlcmVlZA0KPiA+PiAgICB0ZWNobmljYWwgam91cm5h bC4NCj4gPj4NCj4gPj4gICAgQ3VydGlzDQo+ID4+DQo+ID4+DQo+ID4+ICAgIEluIG1lc3NhZ2UN Cj4gPj4NCj4gPENBSEY0YXBPOWJFa1BrN1F3QTlmZ0pxOUJOVU5ITnYrT0Zvbl85XzRPaWo2MWUx MXI5d0BtYWlsLmdtYWlsLg0KPiA+PiBjb20NCj4gPj4NCj4gPG1haWx0bzpDQUhGNGFwTzliRWtQ azdRd0E5ZmdKcTlCTlVOSE52JTJCT0Zvbl85XzRPaWo2MWUxMXI5d0ANCj4gPj4gbWFpbC5nbWFp bC5jb20+ID4NCj4gPj4NCj4gPj4gICAgQmFsYWppIHZlbmthdCBWZW5rYXRhc3dhbWkgd3JpdGVz Og0KPiA+Pg0KPiA+PiAgICA+IERlYXIgYWxsLA0KPiA+PiAgICA+DQo+ID4+ICAgID4gV2UgYXJl IGEgZ3JvdXAgb2YgcmVzZWFyY2ggYW5kIGluZHVzdHJ5IGluZGl2aWR1YWxzIHRpZWQNCj4gPj4g dG9nZXRoZXIgd2l0aCBhDQo+ID4+ICAgID4gY29tbW9uIGdvYWwgdG93YXJkcyByZWR1Y2luZyB0 aGUgZW5lcmd5IGNvbnN1bXB0aW9uIGluIHRoZSBjb3JlDQo+ID4+IGFuZCBlZGdlDQo+ID4+ICAg ID4gbmV0d29ya3MuDQo+ID4+ICAgID4NCj4gPj4gICAgPiBXZSBwcmVzZW50IGEgbWV0cmljLWJh c2VkIGhpZXJhcmNoaWNhbCBhcHByb2FjaCB0byByZWR1Y2UgcG93ZXINCj4gPj4gY29uc3VtcHRp b24NCj4gPj4gICAgPiBpbiBjb3JlIGFuZCBlZGdlIG5ldHdvcmtzLiBUaGUgcHJvcG9zYWwgY29u c2lkZXJzIGJvdGggdW5pY2FzdA0KPiA+PiBhbmQgdGhlDQo+ID4+DQo+ID4+ICAgID4gbXVsdGlj YXN0IGNhc2VzLiBGb3IgdW5pY2FzdCwgdGhlIG1ldHJpYyBjb25zaWRlcmVkIGlzDQo+ID4+ICpj b25zdW1lZC0gcG93ZXIgdG8NCj4gPj4gICAgPiBhdmFpbGFibGUtYmFuZHdpZHRoKiBhbmQgZm9y IG11bHRpY2FzdCB0aGUgbWV0cmljIGlzICpjb25zdW1lZC0NCj4gPj4gcG93ZXIgdG8NCj4gPj4g ICAgPiBhdmFpbGFibGUtcmVwbGljYXRpb24tY2FwYWNpdHkuKg0KPiA+Pg0KPiA+PiAgICA+DQo+ ID4+ICAgID4gIFdpdGggdW5pY2FzdCwgdGhlIG1ldHJpYyBpcyB1c2VkIHRvIGRldGVybWluZSBh IGxvdy1wb3dlciBwYXRoDQo+ID4+IGJldHdlZW4NCj4gPj4gICAgPiBzb3VyY2VzIGFuZCBkZXN0 aW5hdGlvbnMuIFdpdGggbXVsdGljYXN0LCB0aGUgbWV0cmljIHNlcnZlcyB0aGUgdHdpbg0KPiA+ PiAgICA+IHB1cnBvc2Ugb2YgZmluZGluZyBsb3ctcG93ZXIgbXVsdGljYXN0IHBhdGhzIGFzIHdl bGwgYXMgbXVsdGljYXN0DQo+ID4+ICAgID4gcmVwbGljYXRpb24gcG9pbnRzLiAgV2UgZXZvbHZl IG11bHRpcGxlIHRlY2huaXF1ZXMgYXQgdmFyaW91cw0KPiA+PiBoaWVyYXJjaGljYWwNCj4gPj4g ICAgPiBsZXZlbHMuIE9uZSBhdCB0aGUgSW50ZXItQVMgbGV2ZWwsIEludGVyLUFyZWEgbGV2ZWwg d2l0aGluIHRoZSBBUyBhbmQNCj4gPj4gICAgPiBpbnRyYS1BcmVhIHdpdGhpbiBhbiBBUy4gQWRk aXRpb25hbGx5LCB0aGUgcHJvcG9zZWQgbWV0aG9kIGNhbg0KPiA+PiBhbHNvIGJlIHVzZWQNCj4g Pj4gICAgPiB0byBkZXRlcm1pbmUgZGlzam9pbnQgb3IgcmVkdW5kYW50IHBhdGhzIGZvciBsb2Fk IGJhbGFuY2luZyBvciBmYXVsdA0KPiA+PiAgICA+IHRvbGVyYW5jZS4gQWRkaXRpb25hbGx5IHNp bmNlIFRDQU1zIGFyZSBvbmUgb2YgdGhlIGJpZ2dlc3QgcG93ZXINCj4gPj4gZ3V6emxlcnMNCj4g Pj4gICAgPiBpbiBhbGwgdGhlIGNvbXBvbmVudHMgb24gYSByb3V0ZXIvc3dpdGNoLCB3ZSBoYXZl IHByZXNlbnRlZCBhDQo+ID4+IHNvbHV0aW9uIGZvcg0KPiA+PiAgICA+IGludHJhLUFTIHB1cnBv c2VzIHRvIHVzZSB0aGUgVENBTSBhY2NvcmRpbmcgdG8gdGhlIHRyYWZmaWMNCj4gPj4gbWF0cml4 IHBhc3NpbmcNCj4gPj4gICAgPiB0aHJvdWdoIHRoZSBzeXN0ZW0gYW5kIHNodXQgZG93biB0aG9z ZSBUQ0FNIGJhbmtzIHRoYXQgYXJlDQo+ID4+IHVudXNlZC4gV2l0aA0KPiA+PiAgICA+IHRoaXMg aW4gbWluZCwgd2UgaGF2ZSBhbHNvIGFkdm9jYXRlZCB0YWtpbmcgaW50byBhY2NvdW50IGEgVENB TS0NCj4gPj4gUE9XRVItUmF0aW8NCj4gPj4gICAgPiBpbiBvcmRlciB0byBjb21wdXRlIHRoZSBw YXRocyBmcm9tIHNvdXJjZSB0byBkZXN0aW5hdGlvbiBiYXNlZA0KPiA+PiBvbiB0aGlzDQo+ID4+ ICAgID4gbWV0cmljLiBPbmNlIGxvdy1wb3dlciBwYXRocywgaW4gZWl0aGVyIHRoZSB1bmljYXN0 IG9yIHRoZQ0KPiA+PiBtdWx0aWNhc3QgY2FzZXMsDQo+ID4+ICAgID4gYXJlIGlkZW50aWZpZWQg dGhlbiBjdXJyZW50bHkgYXZhaWxhYmxlIHRyYWZmaWMgZW5naW5lZXJpbmcgdGVjaG5pcXVlcw0K PiA+PiAgICA+IGNvdWxkIGJlIHVzZWQgdG8gcm91dGUgdGhlIGRhdGEgcGFja2V0cy4gSW4gdGhl IGNhc2Ugb2YgaW50ZXItQVMNCj4gPj4gQkdQIHBhdGgNCj4gPj4gICAgPiBzZWxlY3Rpb24gaXMg YWxzbyBtb2RpZmllZCB0byBhcnJpdmUgYXQgcGF0aHMgd2hpY2ggYXJlDQo+ID4+IGxvdy1wb3dl ciBwYXRocy4NCj4gPj4gICAgPg0KPiA+PiAgICA+ICBPdXIgbWFpbiBvYmplY3RpdmUgaXMgYXMg Zm9sbG93cy4uLg0KPiA+PiAgICA+DQo+ID4+ICAgID4gV2Ugbm93IG91dGxpbmUgZm91ciBpbXBv cnRhbnQgYXNwZWN0cyB0aGF0IGFueSBhcHByb2FjaCBmb3INCj4gPj4gcG93ZXIgcmVkdWN0aW9u DQo+ID4+ICAgID4gc2hvdWxkIGJlIGNhcGFibGUgb2YgYWRkcmVzc2luZy4NCj4gPj4gICAgPg0K PiA+Pg0KPiA+PiAgICA+ICAqU2hvdWxkIGNhdGVyIGZvciBib3RoIHVuaWNhc3QgYW5kIG11bHRp Y2FzdCBzY2VuYXJpb3MqDQo+ID4+DQo+ID4+ICAgID4NCj4gPj4gICAgPiBNdWx0aWNhc3QgcHJv dmlkZXMgYW4gaW1wb3J0YW50IHNjZW5hcmlvIGZvciB0aGUgSW50ZXJuZXQuDQo+ID4+IFRvZGF5 LCBtb3N0DQo+ID4+ICAgID4gcHJvcG9zYWxzIGNvbnNpZGVyIG1haW5seSBsb3ctcG93ZXIgcGF0 aCByb3V0aW5nIHdpdGggdW5pY2FzdA0KPiA+PiB0cmFmZmljLg0KPiA+PiAgICA+IE11bHRpY2Fz dCB0cmFmZmljIGhhcyByZWNlaXZlZCBhIGxvdCBvZiBhdHRlbnRpb24gaW4gd2lyZWxlc3MNCj4g Pj4gbmV0d29ya3MsIGJ1dA0KPiA+PiAgICA+IG5vdCBpbiB0aGUgd2lyZWQgZG9tYWluLiBBbnkg bmV3IHByb3Bvc2FsIHNob3VsZCBiZSBhYmxlIHRvDQo+ID4+IGFkZHJlc3MgYm90aA0KPiA+PiAg ICA+IHRoZSB1bmljYXN0IGFuZCB0aGUgbXVsdGljYXN0IHRyYWZmaWMgc2NlbmFyaW9zLiBIYXZp bmcNCj4gPj4gZGlmZmVyZW50IG1ldGhvZHMNCj4gPj4gICAgPiBmb3IgdGhlc2UgdHdvIHNjZW5h cmlvcyBtaWdodCBsZWFkIHRvIHVubmVjZXNzYXJ5IHByb2Nlc3NpbmcNCj4gPj4gYnVyZGVuIGlu IHRoZQ0KPiA+PiAgICA+IHJvdXRlcnMsIHdoaWNoIG1pZ2h0IGhpbmRlciBpdHMgc2NhbGFiaWxp dHkuDQo+ID4+ICAgID4NCj4gPj4NCj4gPj4gICAgPiAgKlNob3VsZCBub3QgcmVseSBvbiBqdXN0 IHN3aXRjaGluZyBvZmYgdW51c2VkIGxpbmtzKg0KPiA+Pg0KPiA+PiAgICA+DQo+ID4+ICAgID4g TW9zdCBhcHByb2FjaGVzIHRvIG9wdGltaXplIGVuZXJneSBwdXJzdWUgdGhlIGZvbGxvd2luZyBh cHByb2FjaDoNCj4gPj4gbWVhc3VyZSwNCj4gPj4gICAgPiBtb25pdG9yIGFuZCByZXNwb25kIHRv IHRoZSBzeXN0ZW0gZW5lcmd5IHVzYWdlIGJ5IHN3aXRjaGluZyBvZmYNCj4gPj4gdW51c2VkIG9y DQo+ID4+ICAgID4gdW5kZXItdXRpbGl6ZWQgbGlua3MuIFN1Y2ggYW4gYXBwcm9hY2ggY291bGQg YmUgZWZmZWN0aXZlIGZvciByZWR1Y2luZw0KPiA+PiAgICA+IHBvd2VyIGxvY2FsbHkuIFRoZSBl ZmZlY3Qgb24gdGhlIG5ldHdvcmsgaXMgbm90IGNsZWFybHkgdW5kZXJzdG9vZC4NCj4gPj4gICAg PiBGdXJ0aGVyLCB0aGUgcG93ZXIgdXNhZ2UgaW52b2x2ZWQgaW4gdHVybmluZyBvbiBhbmQNCj4g Pj4gcmVib290aW5nL3JlY29uZmlndXJpbmcNCj4gPj4gICAgPiB0aGUgZGV2aWNlIGlzIG9mdGVu IG5vdCBleHBsaWNpdGx5IGNvbnNpZGVyZWQuIFdlIG5vdGUgdGhhdA0KPiA+PiBTZXJ2aWNlIExl dmVsDQo+ID4+ICAgID4gQWdyZWVtZW50IChTTEEpIHJlcXVpcmVtZW50cyBtYXkgbm90IGV2ZW4g cGVybWl0IHRoZSBsaW5rcyB0byBiZQ0KPiA+PiBzd2l0Y2hlZA0KPiA+PiAgICA+IG9mZi4gQWxz byBzZXJ2aWNlcyBwcm92aWRlZCBieSBJU1BzIGxpa2UgVmlydHVhbCBQcml2YXRlDQo+ID4+IE5l dHdvcmtzDQo+ID4+IChWUE5zKQ0KPiA+PiAgICA+IGNhbiBiZSBhZmZlY3RlZCBieSBzdWNoIHJl LXJvdXRpbmcgZGVjaXNpb25zLg0KPiA+PiAgICA+DQo+ID4+DQo+ID4+ICAgID4gICpTaG91bGQg Zm9sbG93IGFuIGhpZXJhcmNoaWNhbCBhbmQgZGlzdHJpYnV0ZWQgYXBwcm9hY2gqDQo+ID4+DQo+ ID4+ICAgID4NCj4gPj4gICAgPiBGb3Igc2NhbGFiaWxpdHksIGl0IGlzIGltcG9ydGFudCB0aGF0 IHRoZSBhbGdvcml0aG1zIHByb3Bvc2VkDQo+ID4+IGZvciBpbnRlci0gQVMNCj4gPj4gICAgPiBz aG91bGQgYWxzbyBiZSBhcHBsaWNhYmxlIHRvIGludHJhLUFTIHNpdHVhdGlvbnMuIE5ldHdvcmtz IGRvDQo+ID4+IG5vdCB3b3JrIGluDQo+ID4+ICAgID4gaXNvbGF0aW9uLCBzbyBhbnkgcHJvcG9z YWwgc2hvdWxkIGJlIGJvdGggZGlzdHJpYnV0ZWQgYW5kIGhpZXJhcmNoaWNhbC4NCj4gPj4gVGhl DQo+ID4+ICAgID4gYWxnb3JpdGhtcyBzaG91bGQgYmUgYXBwbGljYWJsZSBhdCBldmVyeSBsZXZl bCBvZiB0aGUgaGllcmFyY2h5Lg0KPiA+PiAgICA+DQo+ID4+DQo+ID4+ICAgID4gICpTaG91bGQg IHByb3ZpZGUgaW5jZW50aXZlcyBmb3IgSVNQIGZvciBhZG9wdGlvbioNCj4gPj4NCj4gPj4gICAg Pg0KPiA+PiAgICA+IFRoZSBlbmdpbmVlcmluZyBwcm9wb3NhbHMgc2hvdWxkIGJlIGFsaWduZWQg d2l0aCBjb21tZXJjaWFsDQo+ID4+IGluY2VudGl2ZXMgZm9yDQo+ID4+ICAgID4gcmFwaWQgYW5k IHdpZGVzcHJlYWQgYWRvcHRpb24uIFRvZGF5LCB0aGUgZGV2aWNlIG1hbnVmYWN0dXJlcnMNCj4g Pj4gYW5kIHRoZSBJU1BzDQo+ID4+ICAgID4gb3BlcmF0ZSBpbmRlcGVuZGVudGx5IG9mIGVhY2gg b3RoZXIsIGFuZCB0aGVyZSBpcyBubyBpbmNlbnRpdmUgZm9yDQo+ID4+ICAgID4gbWFudWZhY3R1 cmVycyB0byB3b3JrIHRvd2FyZHMgbG93LXBvd2VyIGFuZCBoaWdoIGJhbmR3aWR0aA0KPiA+PiBk ZXZpY2VzLiBBbg0KPiA+Pg0KPiA+PiAgICA+IElTUD05MnMgcmV2ZW51ZSBtb2RlbCBpcyBiYXNl ZCBvbiB0aGUgY29uc3VtZWQgYmFuZHdpZHRoLCB3aGljaA0KPiA+PiBpbiB0dXJuIGxlYT0NCj4g Pj4gICAgPiBkDQo+ID4+DQo+ID4+ICAgID4gbmF0dXJhbGx5IHRvIG1vcmUgcG93ZXIgY29uc3Vt cHRpb24uIElmIHRoZSBwcm9wb3NlZCBtZXRob2QNCj4gPj4gY2hvb3NlcyByb3V0ZXJzDQo+ID4+ ICAgID4gdGhhdCBjb25zdW1lIGxvdy1wb3dlciBhbmQgaW5jcmVhc2UgdGhlIGRhdGEgZmxvdyB0 aHJvdWdoIHRoZW0sDQo+ID4+IHRoZW4gdGhpcw0KPiA+PiAgICA+IGluZGlyZWN0bHkgcHJvdmlk ZXMgZW5jb3VyYWdlbWVudCBmb3IgSVNQcyB0byBwdXJjaGFzZSBsb3ctcG93ZXINCj4gPj4gYW5k IGhpZ2gNCj4gPj4gICAgPiBiYW5kd2lkdGggZGV2aWNlcy4NCj4gPj4gICAgPg0KPiA+PiAgICA+ DQo+ID4+ICAgID4NCj4gPj4gICAgPiBXZSBub3cgcHJlc2VudCBvdXIgbWV0cmljLWJhc2VkIHBy b3Bvc2FscyBpbiB0aGUgYmVsb3cgbWVudGlvbmVkDQo+ID4+IGRyYWZ0cw0KPiA+PiAgICA+IHdo aWNoIGFkZHJlc3NlcyB0aGUgYWZvcmVtZW50aW9uZWQgZGVzaWduIGFzcGVjdHMuDQo+ID4+ICAg ID4NCj4gPj4gICAgPiBXZSB3b3VsZCBsaWtlIHRoZSByb3V0aW5nIGNvbW11bml0eSB0byBwcm92 aWRlIGZlZWRiYWNrIG9uIHRoZXNlDQo+ID4+IGRyYWZ0cy4gV2UNCj4gPj4NCj4gPj4gICAgPiBh bHNvIGludGVuZCB0byBwcmVzZW50IHRoaXMgd29yayBpbiBhbiBhYnJpZGdlZCBmb3JtYXQgaW4g dGhlDQo+ID4+IHVwY29taW5nIElFVEY9DQo+ID4+DQo+ID4+ICAgID4gLg0KPiA+PiAgICA+DQo+ ID4+ICAgID4gIFRoZSBkcmFmdHMgYXJlIGFzIGZvbGxvd3MuLi4uDQo+ID4+ICAgID4NCj4gPj4g ICAgPg0KPiA+PiAgICA+DQo+ID4+ICAgID4NCj4gPj4NCj4gPj4gICAgPiAgICAtIG1qc3JhbWFu LXBhbmV0LWJncC1wb3dlci1wYXRoPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LQ0K PiA+PiBtanNyYW1hPQ0KPiA+PiAgICA+IG4tcGFuZXQtYmdwLXBvd2VyLXBhdGg+DQo+ID4+ICAg ID4gICAgICh0aW1lbGluZSk8aHR0cDovL3d3dy5hcmtrby5jb20vdG9vbHMvbGlmZWN5Y2xlL2Ry YWZ0LW1qc3JhbWFuLQ0KPiA+PiBwYW5ldC1iZz0NCj4gPj4gICAgPiBwLXBvd2VyLXBhdGgtdGlt aW5nLmh0bWw+DQo+ID4+ICAgID4gICAgIEludGVyLUFTLVByb3Bvc2FsDQo+ID4+ICAgID4gICAg LSBtanNyYW1hbi1wYW5ldC1lY21wLXJlZGlyZWN0LXBvd2VyLXJlcGwtDQo+ID4+IGNhcDxodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbD0NCj4gPj4gICAgPiAvZHJhZnQtbWpzcmFtYW4tcGFuZXQt ZWNtcC1yZWRpcmVjdC1wb3dlci1yZXBsLWNhcD4NCj4gPj4gICAgPiAgICAgKHRpbWVsaW5lKTxo dHRwOi8vd3d3LmFya2tvLmNvbS90b29scy9saWZlY3ljbGUvZHJhZnQtbWpzcmFtYW4tDQo+ID4+ IHBhbmV0LWVjPQ0KPiA+PiAgICA+IG1wLXJlZGlyZWN0LXBvd2VyLXJlcGwtY2FwLXRpbWluZy5o dG1sPg0KPiA+PiAgICA+ICAgICBNdWx0aWNhc3QNCj4gPj4gICAgPiAgICAtIG1qc3JhbWFuLXBh bmV0LWludGVyLWFzLXBvd2VyLQ0KPiA+PiBzb3VyY2U8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtPQ0KPiA+PiAgICA+IG1qc3JhbWFuLXBhbmV0LWludGVyLWFzLXBvd2VyLXNvdXJj ZT4NCj4gPj4gICAgPiAgICAgKHRpbWVsaW5lKTxodHRwOi8vd3d3LmFya2tvLmNvbS90b29scy9s aWZlY3ljbGUvZHJhZnQtbWpzcmFtYW4tDQo+ID4+IHBhbmV0LWluPQ0KPiA+PiAgICA+IHRlci1h cy1wb3dlci1zb3VyY2UtdGltaW5nLmh0bWw+DQo+ID4+ICAgID4gSW50ZXItQVMNCj4gPj4gICAg PiAgICBQcm9wb3NhbA0KPiA+PiAgICA+ICAgIC0gbWpzcmFtYW4tcGFuZXQtaW50ZXItYXMtcHNw PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LQ0KPiA+PiBtanNyYW1hbi09DQo+ID4+ ICAgID4gcGFuZXQtaW50ZXItYXMtcHNwPg0KPiA+PiAgICA+ICAgICAodGltZWxpbmUpPGh0dHA6 Ly93d3cuYXJra28uY29tL3Rvb2xzL2xpZmVjeWNsZS9kcmFmdC1tanNyYW1hbi0NCj4gPj4gcGFu ZXQtaW49DQo+ID4+ICAgID4gdGVyLWFzLXBzcC10aW1pbmcuaHRtbD4NCj4gPj4gICAgPiBJbnRl ci1BUw0KPiA+PiAgICA+ICAgIFByb3Bvc2FsDQo+ID4+ICAgID4gICAgLSBtanNyYW1hbi1wYW5l dC1pbnRlci1hcy1wc3AtDQo+ID4+IHByb3RlY3Q8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtbT0NCj4gPj4gICAgPiBqc3JhbWFuLXBhbmV0LWludGVyLWFzLXBzcC1wcm90ZWN0Pg0K PiA+PiAgICA+ICAgICAodGltZWxpbmUpPGh0dHA6Ly93d3cuYXJra28uY29tL3Rvb2xzL2xpZmVj eWNsZS9kcmFmdC1tanNyYW1hbi0NCj4gPj4gcGFuZXQtaW49DQo+ID4+ICAgID4gdGVyLWFzLXBz cC1wcm90ZWN0LXRpbWluZy5odG1sPg0KPiA+PiAgICA+IEludGVyLUFTDQo+ID4+ICAgID4gICAg UHJvcG9zYWwNCj4gPj4gICAgPiAgICAtIG1qc3JhbWFuLXBhbmV0LXBjZS1wb3dlci1tY2FzdC0N Cj4gPj4gcmVwbGljPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0PQ0KPiA+PiAgICA+ IC1tanNyYW1hbi1wYW5ldC1wY2UtcG93ZXItbWNhc3QtcmVwbGljPg0KPiA+PiAgICA+ICAgICAo dGltZWxpbmUpPGh0dHA6Ly93d3cuYXJra28uY29tL3Rvb2xzL2xpZmVjeWNsZS9kcmFmdC1tanNy YW1hbi0NCj4gPj4gcGFuZXQtcGM9DQo+ID4+ICAgID4gZS1wb3dlci1tY2FzdC1yZXBsaWMtdGlt aW5nLmh0bWw+DQo+ID4+ICAgID4gICAgIE11bHRpY2FzdA0KPiA+PiAgICA+ICAgIC0gbWpzcmFt YW4tcGFuZXQtcGltLXBvd2VyPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LQ0KPiA+ PiBtanNyYW1hbi1wYW49DQo+ID4+ICAgID4gZXQtcGltLXBvd2VyPg0KPiA+PiAgICA+ICAgICAo dGltZWxpbmUpPGh0dHA6Ly93d3cuYXJra28uY29tL3Rvb2xzL2xpZmVjeWNsZS9kcmFmdC1tanNy YW1hbi0NCj4gPj4gcGFuZXQtcGk9DQo+ID4+ICAgID4gbS1wb3dlci10aW1pbmcuaHRtbD4NCj4g Pj4gICAgPiAgICAgTXVsdGljYXN0DQo+ID4+ICAgID4gICAgLSBtanNyYW1hbi1wYW5ldC10Y2Ft LXBvd2VyLQ0KPiA+PiBlZmZpY2llbmN5PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LT0NCj4gPj4gICAgPiBtanNyYW1hbi1wYW5ldC10Y2FtLXBvd2VyLWVmZmljaWVuY3k+DQo+ID4+ ICAgID4gICAgICh0aW1lbGluZSk8aHR0cDovL3d3dy5hcmtrby5jb20vdG9vbHMvbGlmZWN5Y2xl L2RyYWZ0LW1qc3JhbWFuLQ0KPiA+PiBwYW5ldC10Yz0NCj4gPj4gICAgPiBhbS1wb3dlci1lZmZp Y2llbmN5LXRpbWluZy5odG1sPg0KPiA+PiAgICA+IFRDQU0NCj4gPj4gICAgPiAgICByZWxhdGVk DQo+ID4+ICAgID4gICAgLSBtanNyYW1hbi1wYW5ldC10Y2FtLXBvd2VyLQ0KPiA+PiByYXRpbzxo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tanNyYT0NCj4gPj4gICAgPiBtYW4tcGFu ZXQtdGNhbS1wb3dlci1yYXRpbz4NCj4gPj4gICAgPiAgICAgKHRpbWVsaW5lPGh0dHA6Ly93d3cu YXJra28uY29tL3Rvb2xzL2xpZmVjeWNsZS9kcmFmdC1tanNyYW1hbi0NCj4gPj4gcGFuZXQtdGNh PQ0KPiA+PiAgICA+IG0tcG93ZXItcmF0aW8tdGltaW5nLmh0bWw+KQ0KPiA+PiAgICA+ICAgIFRD QU0gcmVsYXRlZA0KPiA+PiAgICA+ICAgIC0gbWpzcmFtYW4tcGNlLXBvd2VyLXJlcGxpYzxodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC0NCj4gPj4gbWpzcmFtYW4tcGM9DQo+ID4+ICAg ID4gZS1wb3dlci1yZXBsaWM+DQo+ID4+ICAgID4gICAgICh0aW1lbGluZSk8aHR0cDovL3d3dy5h cmtrby5jb20vdG9vbHMvbGlmZWN5Y2xlL2RyYWZ0LW1qc3JhbWFuLQ0KPiA+PiBwY2UtcG93ZT0N Cj4gPj4gICAgPiByLXJlcGxpYy10aW1pbmcuaHRtbD4NCj4gPj4gICAgPiAgICAgTXVsdGljYXN0 DQo+ID4+ICAgID4gICAgLSBtanNyYW1hbi1wYW5ldC1pbnRyYS1hcy1wc3AtdGUtDQo+ID4+IGxl YWs8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbT0NCj4gPj4gICAgPiBqc3JhbWFu LXBhbmV0LWludHJhLWFzLXBzcC10ZS1sZWFrPg0KPiA+PiAgICA+ICAgICAodGltZWxpbmUpPGh0 dHA6Ly93d3cuYXJra28uY29tL3Rvb2xzL2xpZmVjeWNsZS9kcmFmdC1tanNyYW1hbi0NCj4gPj4g cGFuZXQtaW49DQo+ID4+ICAgID4gdHJhLWFzLXBzcC10ZS1sZWFrLXRpbWluZy5odG1sPg0KPiA+ PiAgICA+IEludGVyLUFyZWENCj4gPj4gICAgPiAgICB3aXRoaW4gYW4gQVMNCj4gPj4gICAgPiAg ICAtIG1qc3JhbWFuLXBhbmV0LW9zcGYtcG93ZXItdG9wbzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC0NCj4gPj4gbWpzcmFtPQ0KPiA+PiAgICA+IGFuLXBhbmV0LW9zcGYtcG93ZXIt dG9wbz4NCj4gPj4gICAgPiAgICAgKHRpbWVsaW5lKTxodHRwOi8vd3d3LmFya2tvLmNvbS90b29s cy9saWZlY3ljbGUvZHJhZnQtbWpzcmFtYW4tDQo+ID4+IHBhbmV0LW9zPQ0KPiA+PiAgICA+IHBm LXBvd2VyLXRvcG8tdGltaW5nLmh0bWw+DQo+ID4+DQo+ID4+ICAgID4gSW50cmEtQXJlYQ0KPiA+ PiAgICA+ICAgIHdpdGhpbiBhbiBBUw0KPiA+PiAgICA+DQo+ID4+ICAgID4gV2UgdW5kZXJzdGFu ZCBpdCBpcyBhIGxvdCBvZiBtYXR0ZXIgdG8gZ28gdGhyb3VnaC4gV2Ugd291bGQgbXVjaA0KPiA+ PiBhcHByZWNpYXRlDQo+ID4+ICAgID4gaWYgc29tZSBvZiB5b3UgY291bGQgcmV2aWV3IHRoZSBp bnRlci1BUyBwcm9wb3NhbHMgd2hpbGUgb3RoZXJzDQo+ID4+IHRha2UgdXANCj4gPj4gICAgPiBt dWx0aWNhc3QgYW5kIEludHJhLUFTIHVuaWNhc3QgYW5kIG11bHRpY2FzdC4NCj4gPj4gICAgPg0K PiA+PiAgICA+IFRoYW5rcyBhZ2FpbiBmb3IgeW91ciB0aW1lIG9uIHRoaXMgbWF0dGVyLg0KPiA+ PiAgICA+DQo+ID4+ICAgID4gdGhhbmtzIGFuZCByZWdhcmRzLA0KPiA+PiAgICA+IGJhbGFqaSB2 ZW5rYXQNCj4gPj4NCj4gPj4NCj4gPg0K From mjsraman@gmail.com Thu Feb 7 01:48:57 2013 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 23FDE21F8578 for ; Thu, 7 Feb 2013 01:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.283 X-Spam-Level: X-Spam-Status: No, score=-3.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yn0DLBl+7d5w for ; Thu, 7 Feb 2013 01:48:54 -0800 (PST) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA3F21F854C for ; Thu, 7 Feb 2013 01:48:54 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id bj3so1329318pad.34 for ; Thu, 07 Feb 2013 01:48:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:cc:references:in-reply-to:subject :date:mime-version:content-type:x-priority:x-msmail-priority :importance:x-mailer:x-mimeole; bh=PFlkImHdTiBepqQ2ILJ298CMmR5wYLkH+w2tDtnXHAY=; b=FVHQLB8qk7fTKXD04359HEvaLG7sNHh2hX4Dfl4cqBvj+slHB1aPEdAq3Fm6YO1YxV TBE1DUxhOE6GLi+WIn3r64umEIPi/NmTNOssTQUeraGJ/hI2aJsBlrqwrf+AShsBNaXQ xbbI+XmL/ofmfP0V+rlrLz7CJsVjd4mODETtJeQrNX3eV4h7uOTI/xEvarGMDxdyf8L5 7/htVqZ1AeGtbRrc+mgVuy6jibMnwy2Gp/tfNeN3oJC5wT6PbrWlX2dtUhc8NJwxYMAH 36TTmseuEcinBEaeAxmDvFANliFsX5Sor9h0xdgTwEgmZ6hd76j3w43pHdnc9Jn+K0Gx hF0Q== X-Received: by 10.66.72.233 with SMTP id g9mr4208311pav.29.1360230533738; Thu, 07 Feb 2013 01:48:53 -0800 (PST) Received: from NCSVAIO ([203.199.213.3]) by mx.google.com with ESMTPS id bi2sm44655978pab.18.2013.02.07.01.48.49 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 Feb 2013 01:48:52 -0800 (PST) Message-ID: <3B74A0857EB0496E8FA8B026A758D788@NCSVAIO> From: "Shankar Raman" To: "Balaji Venkat" , "Eric Osborne \(eosborne\)" References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <20ECF67871905846A80F77F8F4A27572100BEE0B@xmb-rcd-x09.cisco.com> In-Reply-To: Subject: Re: Power aware networks : Comments requested from routing community Date: Thu, 7 Feb 2013 15:17:36 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FC_01CE0546.4305DB70" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3508.1109 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109 X-Mailman-Approved-At: Thu, 07 Feb 2013 08:00:05 -0800 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, 07 Feb 2013 09:48:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01FC_01CE0546.4305DB70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Eric, Looks like we have not been clear in conveying our idea.=20 We abstract the power consumed by every router/switch, use it as the = power rating. We then assign it to the link as a metric characteristic = to get algorithms like SPF and CSPF to choose the lowest power paths or any metric based routing = algorithm.=20 So the link metric is a combination of power consumed including the = physical link and router components. In effect the link metric is not = just the physical link=E2=80=99s metric alone (but the cost of the power = consumed by the router/switch on which it connects to the neighbor).=20 Just like routing protocols consider delay, hops as metric we consider = this power consumption as yet another metric.=20 Thanks Shankar -----Original Message-----=20 From: Balaji Venkat=20 Sent: Thursday, February 07, 2013 2:36 AM=20 To: Eric Osborne (eosborne)=20 Cc: curtis@occnc.com ; Shankar Raman M J ; rtgwg@ietf.org=20 Subject: Re: Power aware networks : Comments requested from routing = community=20 Dear Eric, Comments inline... Sent from my iPad On 07-Feb-2013, at 1:50 AM, "Eric Osborne (eosborne)" = wrote: > You aim to optimize core networks through traffic engineering such = that some links can be shut down when not in use, or switched to lower = power. Actually the answer is a No. We do not advocate this approach. The main = idea in bgp power path draft has a survey section on previous literature = that we quote for reference and state that such approaches cause = expensive equipment to be kept unused. You have quoted the survey = section of the paper in the above sentence. >=20 > Have you done studies in core networks with real equipment that show = the actual amount of money you could save with this approach? Let's = walk through a quick hypothetical network, you tell me where I got it = wrong. >=20 > draft-mjsraman-panet-bgp-power-path says > " Power consumption can be > reduced by trading off performance related measures like latency. = For > example, power savings while switching from 1 Gbps to 100 Mbps is > approximately 4 W and from 100 Mbps to 10 Mbps around 0.1 Watts." Again this is a survey section of the paper surveying the existing = approaches. >=20 > but provides no documentation to back these costs up nor itemization = of where the power is consumed (amortized across the router? linecard = optics? DWDM gear?) Our main intent is to allow traffic to follow low power paths through = ASs (either through pce like entities or through modifying the bgp path = selection algorithm) which consume the least power and possess the = required bandwidth. By graphing the topology of a set ASs in the = immediate neighbourhood using as-path-info strands typically for a = provider manning multiple ASs within the providers own control this = mechanism will let large chunks of traffic belonging to a macro FEC = traverse such low power ASs through an inter-as te MPLS lsp computed by = a pce like entity and setup by RSVP-te. The use of the metric, the way the pwr metric is arrived at , the = computation of the topology of ASs, consequent CSPF and then mapping the = traffic to the constructed LSP is the main focus if this paper. For = dampening fluctuations in the metric which are frequent heuristics = algorithms are suggested. By no means are we advocating shutting off links. This scheme = facilitates even the follow the moon strategy naturally. >=20 > Let's assume that this is true and that it is linear, so that you burn = 4W per Gb. (side note: I suspect this is inaccurate and that scaling is = sublinear, but let's go with it because if it's sub-linear you have even = less of a use case. I also think the real world is far more complex, as = you have all the optical transport gear to worry about. But let's go = with it for now.) >=20 > Running a 100Gb link thus draws 400W. >=20 > Let's say you have a backbone with (300) 100Gb links. Total power = consumption is thus (300*400) =3D=3D 120 kW >=20 > Running all these links for 24 hours thus draws 120*24 =3D=3D 2,880 = kWh =3D=3D 2.8mWh > Power costs are maybe $0.10/kWh in the US. Double that to cover the = cost of cooling, so $0.20/kWh. > Thus, running the entire backbone costs $0.2 * 2,880 =3D $576/day. = $210,000/year. > Let's say your approach can save one third of the power cost, which = means about $70,000. > > An operator with 300 100Gb links in a network has hundreds of millions = of dollars worth of gear and millions or tens of millions in payroll = alone. If you cut $70k from their opex they probably wouldn't even = notice. That's one or two salaries, or 0.002% of what Time Warner spent = on advertising in 2006 (see: = http://gaia.adage.com/images/random/FactPack06.pdf). It is a drop in = the bucket, if that. And your proposal comes with significant work = attached to it, and significant risk. If your 40 years of experience in = the network industry don't help you understand the risks you're asking = an operator to take then you're missing a crucial part of any potential = real world solution. I do not think your work should be presented at = the IETF unless it makes a much stronger argument that its benefits = outweigh its costs. Again we are not asking the operator to shut off the equipment. He needs = to keep it running as long as he has traffic to carry except that the = pce makes a computation every time a large FEC of traffic needs to be = carried through his ASs through a path that consumes the least power = with the links therein having the required bandwidth. The ratio of = consumed power to the available bandwidth is the metric that is used. = Consumed power relates to a weighted average of the power consumed = within the AS including the edge and core devices while the available bw = relates to the links ingressing into the AS at the ASBRs that are the = inter connectors between the ASes. So in summary, we do not advocate shutting off links at all. In fact we = disagree with that approach. The scheme we advocate tries to optimise = the power consumption using the metric based approach with some = heuristics. Hope this helps. Thanks and regards, Balaji venkat >=20 > These sorts of power optimizations all seem to be "here's how you = reshape the problem so that you can throw a linear problem solver at = it". For example, [ = http://www.cs.berkeley.edu/~suchara/publications/GreenNetsBundles.pdf ]. = I've never seen anything which shows how much more work it will be for = a network operator or which quantifies the actual savings. >=20 > If you can demonstrate significant savings in real networks at little = or no cost to operators, you have an idea worth pursuing. If your idea = will cause more operational angst (e.g. not knowing whether your unused = capacity will be there when you need it because you shut a third of it = off all the time, increased risk of equipment failure from constant = power-cycling, operational tools and training and expertise required to = manage, deploy and troubleshoot variable-power links and the centralized = NMS required to run them, etc etc etc) then it will find little = traction. Green-TE and power-aware BGP have been floating around for a = while and have seen no real uptake in the WGs as far as I can see. Is = that not to be taken as an indication that there may be no real-world = interest in them? If not, what would it take to convince you? >=20 >=20 >=20 > eric >=20 >=20 >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On = Behalf Of >> Balaji venkat Venkataswami >> Sent: Wednesday, February 06, 2013 1:53 PM >> To: curtis@occnc.com >> Cc: Shankar Raman M J; rtgwg@ietf.org >> Subject: Re: Power aware networks : Comments requested from routing >> community >>=20 >> Dear Curtis, >>=20 >> As already stated to you in a private email, "We" are a group of = people with 40 >> years of collective industry experience in the networking industry. = We dont >> need to be patronized by anybody since we have independent minds that = have >> the capability to digest information not based on somebody else's >> interpretation of how future networks need to be built and how power >> reduction needs to play a part in it. >>=20 >> As you might recall one such research paper on GreenTE by Beichuan = Zhang >> rang a lot of bells in the IETF by collecting the ANRP prize. So = please dont >> misstate facts as you might know them and shove your ideas of how = networks >> are built down our throats. >>=20 >> We think the IETF is a free and fair body that accepts opinions and = ideas from >> all sides. We want to keep this a free and fair organization. So = incumbent >> people like you ought to encourage us and have a fair argument when = we >> present such work to you. Dont follow the policy of exclusion to the = nth degree. >>=20 >> It is but fair to say that you seem to be in a minority on this = matter. Nobody >> else responded with unkind misstatements of facts and = mis-understanding of >> our technical antecedents. >>=20 >> Suffice to say that if we get an opportunity to present this (since = IETF is OUR >> organization too) you need not sit through it. If you want to give us = a fair >> hearing please follow a policy of kind inclusion and not create a = ruckus about us >> research folks trying to make an earnest attempt at some practical = research >> that could well save the planet. >>=20 >> Yours sincerely, >> Thanks and regards, >> balaji venkat and shankar raman >>=20 >> On Thu, Feb 7, 2013 at 12:11 AM, Curtis Villamizar = wrote: >>=20 >>=20 >>=20 >> Balaji, >>=20 >> "We" in the context of your first paragraph seems to be a >> misrepresentation. The authors of all of these drafts seem to be = from >> the same university in India. From prior attempts on your part to = get >> a draft of this sort into IDR and a brief reading of a few of the >> drafts that you have just submitted, you don't seem to have a good >> understanding of how networks are built and how network equipment >> is >> built from which to begin to attack the problem of reducing the = power >> consumption of these networks. >>=20 >> If you want to try to advance a research paper with your theories = on >> power reduction, please choose an appropriate venue such as a >> refereed >> technical journal. >>=20 >> Curtis >>=20 >>=20 >> In message >> > com >> > mail.gmail.com> > >>=20 >> Balaji venkat Venkataswami writes: >>=20 >> > Dear all, >> > >> > We are a group of research and industry individuals tied = together >> with a >> > common goal towards reducing the energy consumption in the core >> and edge >> > networks. >> > >> > We present a metric-based hierarchical approach to reduce power >> consumption >> > in core and edge networks. The proposal considers both unicast = and >> the >>=20 >> > multicast cases. For unicast, the metric considered is = *consumed- >> power to >> > available-bandwidth* and for multicast the metric is *consumed- >> power to >> > available-replication-capacity.* >>=20 >> > >> > With unicast, the metric is used to determine a low-power path >> between >> > sources and destinations. With multicast, the metric serves the = twin >> > purpose of finding low-power multicast paths as well as = multicast >> > replication points. We evolve multiple techniques at various >> hierarchical >> > levels. One at the Inter-AS level, Inter-Area level within the = AS and >> > intra-Area within an AS. Additionally, the proposed method can = also >> be used >> > to determine disjoint or redundant paths for load balancing or = fault >> > tolerance. Additionally since TCAMs are one of the biggest power >> guzzlers >> > in all the components on a router/switch, we have presented a >> solution for >> > intra-AS purposes to use the TCAM according to the traffic = matrix >> passing >> > through the system and shut down those TCAM banks that are >> unused. With >> > this in mind, we have also advocated taking into account a TCAM- >> POWER-Ratio >> > in order to compute the paths from source to destination based = on >> this >> > metric. Once low-power paths, in either the unicast or the = multicast >> cases, >> > are identified then currently available traffic engineering = techniques >> > could be used to route the data packets. In the case of inter-AS = BGP >> path >> > selection is also modified to arrive at paths which are = low-power >> paths. >> > >> > Our main objective is as follows... >> > >> > We now outline four important aspects that any approach for = power >> reduction >> > should be capable of addressing. >> > >>=20 >> > *Should cater for both unicast and multicast scenarios* >>=20 >> > >> > Multicast provides an important scenario for the Internet. = Today, >> most >> > proposals consider mainly low-power path routing with unicast >> traffic. >> > Multicast traffic has received a lot of attention in wireless = networks, >> but >> > not in the wired domain. Any new proposal should be able to = address >> both >> > the unicast and the multicast traffic scenarios. Having = different >> methods >> > for these two scenarios might lead to unnecessary processing = burden >> in the >> > routers, which might hinder its scalability. >> > >>=20 >> > *Should not rely on just switching off unused links* >>=20 >> > >> > Most approaches to optimize energy pursue the following = approach: >> measure, >> > monitor and respond to the system energy usage by switching off >> unused or >> > under-utilized links. Such an approach could be effective for = reducing >> > power locally. The effect on the network is not clearly = understood. >> > Further, the power usage involved in turning on and >> rebooting/reconfiguring >> > the device is often not explicitly considered. We note that = Service >> Level >> > Agreement (SLA) requirements may not even permit the links to be >> switched >> > off. Also services provided by ISPs like Virtual Private = Networks >> (VPNs) >> > can be affected by such re-routing decisions. >> > >>=20 >> > *Should follow an hierarchical and distributed approach* >>=20 >> > >> > For scalability, it is important that the algorithms proposed = for inter- >> AS >> > should also be applicable to intra-AS situations. Networks do = not work >> in >> > isolation, so any proposal should be both distributed and = hierarchical. >> The >> > algorithms should be applicable at every level of the hierarchy. >> > >>=20 >> > *Should provide incentives for ISP for adoption* >>=20 >> > >> > The engineering proposals should be aligned with commercial >> incentives for >> > rapid and widespread adoption. Today, the device manufacturers = and >> the ISPs >> > operate independently of each other, and there is no incentive = for >> > manufacturers to work towards low-power and high bandwidth >> devices. An >>=20 >> > ISP=3D92s revenue model is based on the consumed bandwidth, = which >> in turn lea=3D >> > d >>=20 >> > naturally to more power consumption. If the proposed method >> chooses routers >> > that consume low-power and increase the data flow through them, >> then this >> > indirectly provides encouragement for ISPs to purchase low-power >> and high >> > bandwidth devices. >> > >> > >> > >> > We now present our metric-based proposals in the below mentioned >> drafts >> > which addresses the aforementioned design aspects. >> > >> > We would like the routing community to provide feedback on these >> drafts. We >>=20 >> > also intend to present this work in an abridged format in the >> upcoming IETF=3D >>=20 >> > . >> > >> > The drafts are as follows.... >> > >> > >> > >> > >>=20 >> > - = mjsraman-panet-bgp-power-path> mjsrama=3D >> > n-panet-bgp-power-path> >> > = (timeline)> panet-bg=3D >> > p-power-path-timing.html> >> > Inter-AS-Proposal >> > - mjsraman-panet-ecmp-redirect-power-repl- >> cap> > /draft-mjsraman-panet-ecmp-redirect-power-repl-cap> >> > = (timeline)> panet-ec=3D >> > mp-redirect-power-repl-cap-timing.html> >> > Multicast >> > - mjsraman-panet-inter-as-power- >> source> > mjsraman-panet-inter-as-power-source> >> > = (timeline)> panet-in=3D >> > ter-as-power-source-timing.html> >> > Inter-AS >> > Proposal >> > - = mjsraman-panet-inter-as-psp> mjsraman-=3D >> > panet-inter-as-psp> >> > = (timeline)> panet-in=3D >> > ter-as-psp-timing.html> >> > Inter-AS >> > Proposal >> > - mjsraman-panet-inter-as-psp- >> protect> > jsraman-panet-inter-as-psp-protect> >> > = (timeline)> panet-in=3D >> > ter-as-psp-protect-timing.html> >> > Inter-AS >> > Proposal >> > - mjsraman-panet-pce-power-mcast- >> replic> > -mjsraman-panet-pce-power-mcast-replic> >> > = (timeline)> panet-pc=3D >> > e-power-mcast-replic-timing.html> >> > Multicast >> > - mjsraman-panet-pim-power> mjsraman-pan=3D >> > et-pim-power> >> > = (timeline)> panet-pi=3D >> > m-power-timing.html> >> > Multicast >> > - mjsraman-panet-tcam-power- >> efficiency> > mjsraman-panet-tcam-power-efficiency> >> > = (timeline)> panet-tc=3D >> > am-power-efficiency-timing.html> >> > TCAM >> > related >> > - mjsraman-panet-tcam-power- >> ratio> > man-panet-tcam-power-ratio> >> > = (timeline> panet-tca=3D >> > m-power-ratio-timing.html>) >> > TCAM related >> > - mjsraman-pce-power-replic> mjsraman-pc=3D >> > e-power-replic> >> > = (timeline)> pce-powe=3D >> > r-replic-timing.html> >> > Multicast >> > - mjsraman-panet-intra-as-psp-te- >> leak> > jsraman-panet-intra-as-psp-te-leak> >> > = (timeline)> panet-in=3D >> > tra-as-psp-te-leak-timing.html> >> > Inter-Area >> > within an AS >> > - = mjsraman-panet-ospf-power-topo> mjsram=3D >> > an-panet-ospf-power-topo> >> > = (timeline)> panet-os=3D >> > pf-power-topo-timing.html> >>=20 >> > Intra-Area >> > within an AS >> > >> > We understand it is a lot of matter to go through. We would much >> appreciate >> > if some of you could review the inter-AS proposals while others = take >> up >> > multicast and Intra-AS unicast and multicast. >> > >> > Thanks again for your time on this matter. >> > >> > thanks and regards, >> > balaji venkat >>=20 >>=20 > ------=_NextPart_000_01FC_01CE0546.4305DB70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dear Eric,
    Looks like we have not been clear in = conveying our=20 idea.
     
    We abstract the power consumed by every = router/switch,=20 use it as the power rating. We then assign it to the link as a metric=20 characteristic to get algorithms like SPF
    and CSPF to choose the lowest power paths or = any metric=20 based routing algorithm.
     
    So the link metric is a combination of power = consumed=20 including the physical link and router components. In effect the link = metric is=20 not just the physical link=E2=80=99s metric alone (but the cost of the = power consumed by=20 the router/switch on which it connects to the neighbor).
     
    Just like routing protocols consider delay, = hops as=20 metric we consider this power consumption as yet another metric. =
     
    Thanks
    Shankar
     
    -----Original Message-----
    From: Balaji Venkat
    Sent: Thursday, February 07, 2013 2:36 AM
    To: Eric Osborne (eosborne)
    Cc: curtis@occnc.com ; Shankar Raman M J ; rtgwg@ietf.org
    Subject: Re: Power aware networks : Comments requested from routing = community
     
    Dear Eric,
     
    Comments inline...
     
    Sent from my iPad
     
    On 07-Feb-2013, at 1:50 AM, "Eric Osborne (eosborne)"=20 <eosborne@cisco.com> wrote:
     
    > You aim to optimize core networks through traffic engineering = such=20 that some links can be shut down when not in use, or switched to lower=20 power.
     
    Actually the answer is a No. We do not advocate this approach. The = main=20 idea in bgp power path draft has a survey section on previous literature = that we=20 quote for reference and state that such approaches cause expensive = equipment to=20 be kept unused. You have quoted the survey section of the paper in the = above=20 sentence.
     
    >
    > Have you done studies in core networks with real equipment = that show=20 the actual amount of money you could save with this approach?  = Let's walk=20 through a quick hypothetical network, you tell me where I got it = wrong.
    >
    > draft-mjsraman-panet-bgp-power-path says
    > " Power consumption can be
    >   reduced by trading off performance related = measures like=20 latency. For
    >   example, power savings while switching from 1 Gbps = to 100=20 Mbps is
    >   approximately 4 W and from 100 Mbps to 10 Mbps = around 0.1=20 Watts."
     
    Again this is a survey section of the paper surveying the existing=20 approaches.
     
    >
    > but provides no documentation to back these costs up nor = itemization=20 of where the power is consumed (amortized across the router?  = linecard=20 optics?  DWDM gear?)
     
    Our main intent is to allow traffic to follow low power paths = through ASs=20 (either through pce like entities or through modifying the bgp path = selection=20 algorithm) which consume the least power and possess the required = bandwidth. By=20 graphing the topology of a set ASs in the immediate neighbourhood using=20 as-path-info strands typically for a provider manning multiple ASs = within the=20 providers own control this mechanism will let large chunks of traffic = belonging=20 to a macro FEC traverse such low power ASs through an inter-as te MPLS = lsp=20 computed by a pce like entity and setup by RSVP-te.
     
    The use of the metric, the way the pwr metric is arrived at , the=20 computation of the topology of ASs, consequent CSPF and then mapping the = traffic=20 to the constructed LSP is the main focus if this paper. For dampening=20 fluctuations in the metric which are frequent heuristics algorithms are=20 suggested.
     
    By no means are we advocating shutting off links. This scheme = facilitates=20 even the follow the moon strategy naturally.
     
     
    >
    > Let's assume that this is true and that it is linear, so that = you burn=20 4W per Gb.  (side note: I suspect this is inaccurate and that = scaling is=20 sublinear, but let's go with it because if it's sub-linear you have even = less of=20 a use case.  I also think the real world is far more complex, as = you have=20 all the optical transport gear to worry about.  But let's go with = it for=20 now.)
    >
    > Running a 100Gb link thus draws 400W.
    >
    > Let's say you have a backbone with (300) 100Gb links.  = Total=20 power consumption is thus (300*400) =3D=3D 120 kW
    >
    > Running all these links for 24 hours thus draws 120*24 =3D=3D = 2,880=20 kWh  =3D=3D 2.8mWh
    > Power costs are maybe $0.10/kWh in the US.  Double that = to cover=20 the cost of cooling, so $0.20/kWh.
    > Thus, running the entire backbone costs $0.2 * 2,880 =3D = $576/day. =20 $210,000/year.
    > Let's say your approach can save one third of the power cost, = which=20 means about $70,000.
    >
     
     
     
    > An operator with 300 100Gb links in a network has hundreds of = millions=20 of dollars worth of gear and millions or tens of millions in payroll=20 alone.  If you cut $70k from their opex they probably wouldn't even = notice.  That's one or two salaries, or 0.002% of what Time Warner = spent on=20 advertising in 2006 (see:=20 http://gaia.adage.com/images/random/FactPack06.pdf).  It is a drop = in the=20 bucket, if that.  And your proposal comes with significant work = attached to=20 it, and significant risk.  If your 40 years of experience in the = network=20 industry don't help you understand the risks you're asking an operator = to take=20 then you're missing a crucial part of any potential real world = solution.  I=20 do not think your work should be presented at the IETF unless it makes a = much=20 stronger argument that its benefits outweigh its costs.
     
    Again we are not asking the operator to shut off the equipment. He = needs to=20 keep it running as long as he has traffic to carry except that the pce = makes a=20 computation every time a large FEC of traffic needs to be carried = through his=20 ASs through a path that consumes the least power with the links therein = having=20 the required bandwidth. The ratio of consumed power to the available = bandwidth=20 is the metric that is used. Consumed power relates to a weighted average = of the=20 power consumed within the AS including the edge and core devices while = the=20 available bw relates to the links ingressing into the AS at the ASBRs = that are=20 the inter connectors between the ASes.
     
     
    So in summary, we do not advocate shutting off links at all. In = fact we=20 disagree with that approach. The scheme we advocate tries to optimise = the power=20 consumption using the metric based approach with some heuristics.
     
    Hope this helps.
     
    Thanks and regards,
    Balaji venkat
    >
    > These sorts of power optimizations all seem to be "here's how = you=20 reshape the problem so that you can throw a linear problem solver at = it". =20 For example, [=20 http://www.cs.berkeley.edu/~suchara/publications/GreenNetsBundles.pdf = ]. =20 I've never seen anything which shows how much more work it will be for a = network=20 operator or which quantifies the actual savings.
    >
    > If you can demonstrate significant savings in real networks at = little=20 or no cost to operators, you have an idea worth pursuing.  If your = idea=20 will cause more operational angst (e.g. not knowing whether your unused = capacity=20 will be there when you need it because you shut a third of it off all = the time,=20 increased risk of equipment failure from constant power-cycling, = operational=20 tools and training and expertise required to manage, deploy and = troubleshoot=20 variable-power links and the centralized NMS required to run them, etc = etc etc)=20 then it will find little traction.  Green-TE and power-aware BGP = have been=20 floating around for a while and have seen no real uptake in the WGs as = far as I=20 can see.  Is that not to be taken as an indication that there may = be no=20 real-world interest in them?  If not, what would it take to = convince=20 you?
    >
    >
    >
    > eric
    >
    >
    >> -----Original Message-----
    >> From: rtgwg-bounces@ietf.org = [mailto:rtgwg-bounces@ietf.org] On=20 Behalf Of
    >> Balaji venkat Venkataswami
    >> Sent: Wednesday, February 06, 2013 1:53 PM
    >> To: curtis@occnc.com
    >> Cc: Shankar Raman M J; rtgwg@ietf.org
    >> Subject: Re: Power aware networks : Comments requested = from=20 routing
    >> community
    >>
    >> Dear Curtis,
    >>
    >> As already stated to you in a private email, "We" are a = group of=20 people with 40
    >> years of collective industry experience in the networking=20 industry. We dont
    >> need to be patronized by anybody since we have independent = minds=20 that have
    >> the capability to digest information not based on somebody = else's
    >> interpretation of how future networks need to be built and = how=20 power
    >> reduction needs to play a part in it.
    >>
    >> As you might recall one such research paper on GreenTE by = Beichuan=20 Zhang
    >> rang a lot of bells in the IETF by collecting the ANRP = prize. So=20 please dont
    >> misstate facts as you might know them and shove your ideas = of how=20 networks
    >> are built down our throats.
    >>
    >> We think the IETF is a free and fair body that accepts = opinions=20 and ideas from
    >> all sides. We want to keep this a free and fair = organization. So=20 incumbent
    >> people like you ought to encourage us and have a fair = argument=20 when we
    >> present such work to you. Dont follow the policy of = exclusion to=20 the nth degree.
    >>
    >> It is but fair to say that you seem to be in a minority on = this=20 matter. Nobody
    >> else responded with unkind misstatements of facts and=20 mis-understanding of
    >> our technical antecedents.
    >>
    >> Suffice to say that if we get an opportunity to present = this=20 (since IETF is OUR
    >> organization too) you need not sit through it. If you want = to give=20 us a fair
    >> hearing please follow a policy of kind inclusion and not = create a=20 ruckus about us
    >> research folks trying to make an earnest attempt at some = practical=20 research
    >> that could well save the planet.
    >>
    >> Yours sincerely,
    >> Thanks and regards,
    >> balaji venkat and shankar raman
    >>
    >> On Thu, Feb 7, 2013 at 12:11 AM, Curtis Villamizar=20 <curtis@occnc.com> wrote:
    >>
    >>
    >>
    >>    Balaji,
    >>
    >>    "We" in the context of your first = paragraph=20 seems to be a
    >>    misrepresentation.  The authors of = all of=20 these drafts seem to be from
    >>    the same university in India.  From = prior=20 attempts on your part to get
    >>    a draft of this sort into IDR and a = brief=20 reading of a few of the
    >>    drafts that you have just submitted, you = don't=20 seem to have a good
    >>    understanding of how networks are built = and how=20 network equipment
    >> is
    >>    built from which to begin to attack the = problem=20 of reducing the power
    >>    consumption of these networks.
    >>
    >>    If you want to try to advance a research = paper=20 with your theories on
    >>    power reduction, please choose an = appropriate=20 venue such as a
    >> refereed
    >>    technical journal.
    >>
    >>    Curtis
    >>
    >>
    >>    In message
    >>=20 <CAHF4apO9bEkPk7QwA9fgJq9BNUNHNv+OFon_9_4Oij61e11r9w@mail.gmail.
    =
    >> com
    >>=20 <mailto:CAHF4apO9bEkPk7QwA9fgJq9BNUNHNv%2BOFon_9_4Oij61e11r9w@
    >> mail.gmail.com> >
    >>
    >>    Balaji venkat Venkataswami writes:
    >>
    >>    > Dear all,
    >>    >
    >>    > We are a group of research and = industry=20 individuals tied together
    >> with a
    >>    > common goal towards reducing the = energy=20 consumption in the core
    >> and edge
    >>    > networks.
    >>    >
    >>    > We present a metric-based = hierarchical=20 approach to reduce power
    >> consumption
    >>    > in core and edge networks. The = proposal=20 considers both unicast and
    >> the
    >>
    >>    > multicast cases. For unicast, the = metric=20 considered is *consumed-
    >> power to
    >>    > available-bandwidth* and for = multicast the=20 metric is *consumed-
    >> power to
    >>    > = available-replication-capacity.*
    >>
    >>    >
    >>    >  With unicast, the metric is = used to=20 determine a low-power path
    >> between
    >>    > sources and destinations. With = multicast,=20 the metric serves the twin
    >>    > purpose of finding low-power = multicast=20 paths as well as multicast
    >>    > replication points.  We evolve = multiple techniques at various
    >> hierarchical
    >>    > levels. One at the Inter-AS level,=20 Inter-Area level within the AS and
    >>    > intra-Area within an AS. = Additionally, the=20 proposed method can also
    >> be used
    >>    > to determine disjoint or redundant = paths=20 for load balancing or fault
    >>    > tolerance. Additionally since TCAMs = are one=20 of the biggest power
    >> guzzlers
    >>    > in all the components on a = router/switch,=20 we have presented a
    >> solution for
    >>    > intra-AS purposes to use the TCAM = according=20 to the traffic matrix
    >> passing
    >>    > through the system and shut down = those TCAM=20 banks that are
    >> unused. With
    >>    > this in mind, we have also = advocated taking=20 into account a TCAM-
    >> POWER-Ratio
    >>    > in order to compute the paths from = source=20 to destination based on
    >> this
    >>    > metric. Once low-power paths, in = either the=20 unicast or the multicast
    >> cases,
    >>    > are identified then currently = available=20 traffic engineering techniques
    >>    > could be used to route the data = packets. In=20 the case of inter-AS BGP
    >> path
    >>    > selection is also modified to = arrive at=20 paths which are low-power
    >> paths.
    >>    >
    >>    >  Our main objective is as=20 follows...
    >>    >
    >>    > We now outline four important = aspects that=20 any approach for power
    >> reduction
    >>    > should be capable of = addressing.
    >>    >
    >>
    >>    >  *Should cater for both = unicast and=20 multicast scenarios*
    >>
    >>    >
    >>    > Multicast provides an important = scenario=20 for the Internet. Today,
    >> most
    >>    > proposals consider mainly low-power = path=20 routing with unicast
    >> traffic.
    >>    > Multicast traffic has received a = lot of=20 attention in wireless networks,
    >> but
    >>    > not in the wired domain. Any new = proposal=20 should be able to address
    >> both
    >>    > the unicast and the multicast = traffic=20 scenarios. Having different
    >> methods
    >>    > for these two scenarios might lead = to=20 unnecessary processing burden
    >> in the
    >>    > routers, which might hinder its=20 scalability.
    >>    >
    >>
    >>    >  *Should not rely on just = switching=20 off unused links*
    >>
    >>    >
    >>    > Most approaches to optimize energy = pursue=20 the following approach:
    >> measure,
    >>    > monitor and respond to the system = energy=20 usage by switching off
    >> unused or
    >>    > under-utilized links. Such an = approach=20 could be effective for reducing
    >>    > power locally. The effect on the = network is=20 not clearly understood.
    >>    > Further, the power usage involved = in=20 turning on and
    >> rebooting/reconfiguring
    >>    > the device is often not explicitly=20 considered. We note that Service
    >> Level
    >>    > Agreement (SLA) requirements may = not even=20 permit the links to be
    >> switched
    >>    > off. Also services provided by ISPs = like=20 Virtual Private Networks
    >> (VPNs)
    >>    > can be affected by such re-routing=20 decisions.
    >>    >
    >>
    >>    >  *Should follow an = hierarchical and=20 distributed approach*
    >>
    >>    >
    >>    > For scalability, it is important = that the=20 algorithms proposed for inter-
    >> AS
    >>    > should also be applicable to = intra-AS=20 situations. Networks do not work
    >> in
    >>    > isolation, so any proposal should = be both=20 distributed and hierarchical.
    >> The
    >>    > algorithms should be applicable at = every=20 level of the hierarchy.
    >>    >
    >>
    >>    >  *Should  provide = incentives for=20 ISP for adoption*
    >>
    >>    >
    >>    > The engineering proposals should be = aligned=20 with commercial
    >> incentives for
    >>    > rapid and widespread adoption. = Today, the=20 device manufacturers and
    >> the ISPs
    >>    > operate independently of each = other, and=20 there is no incentive for
    >>    > manufacturers to work towards = low-power and=20 high bandwidth
    >> devices. An
    >>
    >>    > ISP=3D92s revenue model is based on = the=20 consumed bandwidth, which
    >> in turn lea=3D
    >>    > d
    >>
    >>    > naturally to more power = consumption. If the=20 proposed method
    >> chooses routers
    >>    > that consume low-power and increase = the=20 data flow through them,
    >> then this
    >>    > indirectly provides encouragement = for ISPs=20 to purchase low-power
    >> and high
    >>    > bandwidth devices.
    >>    >
    >>    >
    >>    >
    >>    > We now present our metric-based = proposals=20 in the below mentioned
    >> drafts
    >>    > which addresses the aforementioned = design=20 aspects.
    >>    >
    >>    > We would like the routing community = to=20 provide feedback on these
    >> drafts. We
    >>
    >>    > also intend to present this work in = an=20 abridged format in the
    >> upcoming IETF=3D
    >>
    >>    > .
    >>    >
    >>    >  The drafts are as = follows....
    >>    >
    >>    >
    >>    >
    >>    >
    >>
    >>    >    -=20 mjsraman-panet-bgp-power-path<http://tools.ietf.org/html/draft-
    >> mjsrama=3D
    >>    > n-panet-bgp-power-path>
    >>    >    =20 (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-
    >> panet-bg=3D
    >>    > p-power-path-timing.html>
    >>    >    =20 Inter-AS-Proposal
    >>    >    -=20 mjsraman-panet-ecmp-redirect-power-repl-
    >> cap<http://tools.ietf.org/html=3D
    >>    >=20 /draft-mjsraman-panet-ecmp-redirect-power-repl-cap>
    >>    >    =20 (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-
    >> panet-ec=3D
    >>    >=20 mp-redirect-power-repl-cap-timing.html>
    >>    >     = Multicast
    >>    >    -=20 mjsraman-panet-inter-as-power-
    >> source<http://tools.ietf.org/html/draft-=3D
    >>    >=20 mjsraman-panet-inter-as-power-source>
    >>    >    =20 (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-
    >> panet-in=3D
    >>    > = ter-as-power-source-timing.html>
    >>    > Inter-AS
    >>    >    Proposal
    >>    >    -=20 mjsraman-panet-inter-as-psp<http://tools.ietf.org/html/draft-
    >> mjsraman-=3D
    >>    > panet-inter-as-psp>
    >>    >    =20 (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-
    >> panet-in=3D
    >>    > ter-as-psp-timing.html>
    >>    > Inter-AS
    >>    >    Proposal
    >>    >    -=20 mjsraman-panet-inter-as-psp-
    >> protect<http://tools.ietf.org/html/draft-m=3D
    >>    >=20 jsraman-panet-inter-as-psp-protect>
    >>    >    =20 (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-
    >> panet-in=3D
    >>    > = ter-as-psp-protect-timing.html>
    >>    > Inter-AS
    >>    >    Proposal
    >>    >    -=20 mjsraman-panet-pce-power-mcast-
    >> replic<http://tools.ietf.org/html/draft=3D
    >>    >=20 -mjsraman-panet-pce-power-mcast-replic>
    >>    >    =20 (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-
    >> panet-pc=3D
    >>    > = e-power-mcast-replic-timing.html>
    >>    >     = Multicast
    >>    >    -=20 mjsraman-panet-pim-power<http://tools.ietf.org/html/draft-
    >> mjsraman-pan=3D
    >>    > et-pim-power>
    >>    >    =20 (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-
    >> panet-pi=3D
    >>    > m-power-timing.html>
    >>    >     = Multicast
    >>    >    -=20 mjsraman-panet-tcam-power-
    >> efficiency<http://tools.ietf.org/html/draft-=3D
    >>    >=20 mjsraman-panet-tcam-power-efficiency>
    >>    >    =20 (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-
    >> panet-tc=3D
    >>    > = am-power-efficiency-timing.html>
    >>    > TCAM
    >>    >    related
    >>    >    -=20 mjsraman-panet-tcam-power-
    >> ratio<http://tools.ietf.org/html/draft-mjsra=3D
    >>    > = man-panet-tcam-power-ratio>
    >>    >    =20 (timeline<http://www.arkko.com/tools/lifecycle/draft-mjsraman-
    >> panet-tca=3D
    >>    > = m-power-ratio-timing.html>)
    >>    >    TCAM = related
    >>    >    -=20 mjsraman-pce-power-replic<http://tools.ietf.org/html/draft-
    >> mjsraman-pc=3D
    >>    > e-power-replic>
    >>    >    =20 (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-
    >> pce-powe=3D
    >>    > r-replic-timing.html>
    >>    >     = Multicast
    >>    >    -=20 mjsraman-panet-intra-as-psp-te-
    >> leak<http://tools.ietf.org/html/draft-m=3D
    >>    >=20 jsraman-panet-intra-as-psp-te-leak>
    >>    >    =20 (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-
    >> panet-in=3D
    >>    > = tra-as-psp-te-leak-timing.html>
    >>    > Inter-Area
    >>    >    within an = AS
    >>    >    -=20 mjsraman-panet-ospf-power-topo<http://tools.ietf.org/html/draft-
    =
    >> mjsram=3D
    >>    > an-panet-ospf-power-topo>
    >>    >    =20 (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-
    >> panet-os=3D
    >>    > pf-power-topo-timing.html>
    >>
    >>    > Intra-Area
    >>    >    within an = AS
    >>    >
    >>    > We understand it is a lot of matter = to go=20 through. We would much
    >> appreciate
    >>    > if some of you could review the = inter-AS=20 proposals while others take
    >> up
    >>    > multicast and Intra-AS unicast and=20 multicast.
    >>    >
    >>    > Thanks again for your time on this=20 matter.
    >>    >
    >>    > thanks and regards,
    >>    > balaji venkat
    >>
    >>
    >
    ------=_NextPart_000_01FC_01CE0546.4305DB70-- From balajivenkat299@gmail.com Thu Feb 7 08:01:01 2013 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 41E0B21F853D for ; Thu, 7 Feb 2013 08:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.234 X-Spam-Level: X-Spam-Status: No, score=-3.234 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izf84t9i+C-d for ; Thu, 7 Feb 2013 08:00:59 -0800 (PST) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by ietfa.amsl.com (Postfix) with ESMTP id 4D17821F841C for ; Thu, 7 Feb 2013 08:00:59 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id ta14so2846723obb.28 for ; Thu, 07 Feb 2013 08:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bfDNVQg0gebC+O7LAWWMq6JXzW2Q7AhEcptbVctV02o=; b=Ofy00PiAydNo07J5na1bRpGDYVlT7SWZruEo2HYEwtTu4LvETt0h+dLV0jxC5W6/oA 70xjjlMk9FL/5QwXxQ8oAZyEHYZBVzEHNkO2do9wuFVY6WYyvhUtasaf/d8K62oCBpbs IFJWtGAgsPvKSp5QgRNj7cLZ5D3Qxhxr5L9HjXPUESlHRq1yismyxt+mxkIgiCG6bz2K Y4q1Qw02jnql5i7kZrSYCtci2/muriX0GMEUKyFVo9Cq/K1jeoQsSq86/USQF6cVXK9c nsbea9gqOLe6YxfkSv/d5KJ9DySwGrKrwS8A8MLhvyuAh0JAYAv0O9xH7+oY7RyYpJcB zAyw== MIME-Version: 1.0 X-Received: by 10.60.32.143 with SMTP id j15mr1454157oei.7.1360252857388; Thu, 07 Feb 2013 08:00:57 -0800 (PST) Received: by 10.60.93.8 with HTTP; Thu, 7 Feb 2013 08:00:57 -0800 (PST) In-Reply-To: References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <20ECF67871905846A80F77F8F4A27572100BEE0B@xmb-rcd-x09.cisco.com> <3B74A0857EB0496E8FA8B026A758D788@NCSVAIO> <20ECF67871905846A80F77F8F4A27572100BF86F@xmb-rcd-x09.cisco.com> Date: Thu, 7 Feb 2013 21:30:57 +0530 Message-ID: Subject: Re: Power aware networks : Comments requested from routing community From: Balaji venkat Venkataswami To: "Eric Osborne (eosborne)" Content-Type: multipart/alternative; boundary=e89a8fb1ee6e5e903204d5248c9c Cc: Shankar Raman , "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, 07 Feb 2013 16:01:01 -0000 --e89a8fb1ee6e5e903204d5248c9c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable CCing the alias as message went out of bounds in size. On Thu, Feb 7, 2013 at 9:28 PM, Balaji venkat Venkataswami < balajivenkat299@gmail.com> wrote: > Dear Eric, > > We seem to be discussing at cross purposes. > > The root of our position is not what you have stated. We do not say if yo= u > dont use a link you consume less power. We are not for avoiding links but > we are for avoiding nodes/routers/switches which have a large power > footprint. The essence of using link metrics is to avoid nodes with large= r > power footprints. That is how SPF or CSPF works. When it computes a low > power path it avoids nodes and also links that lead to that node which ha= s > a larger power footprint. So the premise that we are just avoiding links = is > WRONG. > > For #1 question, we dont even talk about the power the link draws. We tal= k > about the power footprint of the node that it is connected to. > > For #2 question, again we state that your premise of avoiding links in > your example is a non-starter for us. > > thanks and regards, > balaji venkat > > > On Thu, Feb 7, 2013 at 9:18 PM, Eric Osborne (eosborne) < > eosborne@cisco.com> wrote: > >> The root of your position seems to be that if you don't use a link, you >> consume less power, and thus avoiding certain links means consuming less >> power means saving money. >> >> I see two problems with this: >> >> 1) I'm not sure that's actually true. SONET, for one, sends empty frame= s >> when there's no data, so the laser is always firing. >> >> 2) even if it was true, or if you had some analogue to 802.3az that you >> could use in backbones, I don't believe you'd save anywhere near enough >> money to make it worth it. >> >> For #1, please explain the circumstances under which leaving a link idle >> saves power, and explain how much power and what drives that power draw. >> >> For #2, please see my example in my original email. >> >> >> >> >> eric >> >> >> > -----Original Message----- >> > From: Shankar Raman [mailto:mjsraman@gmail.com] >> > Sent: Thursday, February 07, 2013 4:48 AM >> > To: Balaji Venkat; Eric Osborne (eosborne) >> > Cc: curtis@occnc.com; rtgwg@ietf.org >> > Subject: Re: Power aware networks : Comments requested from routing >> > community >> > >> > Dear Eric, >> > Looks like we have not been clear in conveying our idea. >> > >> > We abstract the power consumed by every router/switch, use it as the >> power >> > rating. We then assign it to the link as a metric characteristic to ge= t >> algorithms >> > like SPF and CSPF to choose the lowest power paths or any metric based >> routing >> > algorithm. >> > >> > So the link metric is a combination of power consumed including the >> physical >> > link and router components. In effect the link metric is not just the >> physical >> > link=92s metric alone (but the cost of the power consumed by the >> router/switch on >> > which it connects to the neighbor). >> > >> > Just like routing protocols consider delay, hops as metric we consider >> this >> > power consumption as yet another metric. >> > >> > Thanks >> > Shankar >> > >> > -----Original Message----- >> > From: Balaji Venkat >> > Sent: Thursday, February 07, 2013 2:36 AM >> > To: Eric Osborne (eosborne) >> > Cc: curtis@occnc.com ; Shankar Raman M J ; rtgwg@ietf.org >> > Subject: Re: Power aware networks : Comments requested from routing >> > community >> > >> > Dear Eric, >> > >> > Comments inline... >> > >> > Sent from my iPad >> > >> > On 07-Feb-2013, at 1:50 AM, "Eric Osborne (eosborne)" >> > wrote: >> > >> > > You aim to optimize core networks through traffic engineering such >> that >> > some links can be shut down when not in use, or switched to lower powe= r. >> > >> > Actually the answer is a No. We do not advocate this approach. The mai= n >> idea >> > in bgp power path draft has a survey section on previous literature >> that we >> > quote for reference and state that such approaches cause expensive >> equipment >> > to be kept unused. You have quoted the survey section of the paper in >> the >> > above sentence. >> > >> > > >> > > Have you done studies in core networks with real equipment that show >> the >> > actual amount of money you could save with this approach? Let's walk >> through >> > a quick hypothetical network, you tell me where I got it wrong. >> > > >> > > draft-mjsraman-panet-bgp-power-path says " Power consumption can be >> > > reduced by trading off performance related measures like latency. >> For >> > > example, power savings while switching from 1 Gbps to 100 Mbps is >> > > approximately 4 W and from 100 Mbps to 10 Mbps around 0.1 Watts." >> > >> > Again this is a survey section of the paper surveying the existing >> approaches. >> > >> > > >> > > but provides no documentation to back these costs up nor itemization >> > > of where the power is consumed (amortized across the router? lineca= rd >> > > optics? DWDM gear?) >> > >> > Our main intent is to allow traffic to follow low power paths through >> ASs (either >> > through pce like entities or through modifying the bgp path selection >> > algorithm) which consume the least power and possess the required >> bandwidth. >> > By graphing the topology of a set ASs in the immediate neighbourhood >> using >> > as-path-info strands typically for a provider manning multiple ASs >> within the >> > providers own control this mechanism will let large chunks of traffic >> belonging >> > to a macro FEC traverse such low power ASs through an inter-as te MPLS >> lsp >> > computed by a pce like entity and setup by RSVP-te. >> > >> > The use of the metric, the way the pwr metric is arrived at , the >> computation of >> > the topology of ASs, consequent CSPF and then mapping the traffic to t= he >> > constructed LSP is the main focus if this paper. For dampening >> fluctuations in >> > the metric which are frequent heuristics algorithms are suggested. >> > >> > By no means are we advocating shutting off links. This scheme >> facilitates even >> > the follow the moon strategy naturally. >> > >> > >> > > >> > > Let's assume that this is true and that it is linear, so that you bu= rn >> > > 4W per Gb. (side note: I suspect this is inaccurate and that scalin= g >> > > is sublinear, but let's go with it because if it's sub-linear you ha= ve >> > > even less of a use case. I also think the real world is far more >> > > complex, as you have all the optical transport gear to worry about. >> > > But let's go with it for now.) >> > > >> > > Running a 100Gb link thus draws 400W. >> > > >> > > Let's say you have a backbone with (300) 100Gb links. Total power >> > > consumption is thus (300*400) =3D=3D 120 kW >> > > >> > > Running all these links for 24 hours thus draws 120*24 =3D=3D 2,880 = kWh >> > > =3D=3D 2.8mWh Power costs are maybe $0.10/kWh in the US. Double tha= t to >> > cover the cost of cooling, so $0.20/kWh. >> > > Thus, running the entire backbone costs $0.2 * 2,880 =3D $576/day. >> > $210,000/year. >> > > Let's say your approach can save one third of the power cost, which >> means >> > about $70,000. >> > > >> > >> > >> > >> > > An operator with 300 100Gb links in a network has hundreds of >> millions of >> > dollars worth of gear and millions or tens of millions in payroll >> alone. If you cut >> > $70k from their opex they probably wouldn't even notice. That's one o= r >> two >> > salaries, or 0.002% of what Time Warner spent on advertising in 2006 >> (see: >> > http://gaia.adage.com/images/random/FactPack06.pdf). It is a drop in >> the >> > bucket, if that. And your proposal comes with significant work >> attached to it, >> > and significant risk. If your 40 years of experience in the network >> industry don't >> > help you understand the risks you're asking an operator to take then >> you're >> > missing a crucial part of any potential real world solution. I do not >> think your >> > work should be presented at the IETF unless it makes a much stronger >> > argument that its benefits outweigh its costs. >> > >> > Again we are not asking the operator to shut off the equipment. He >> needs to >> > keep it running as long as he has traffic to carry except that the pce >> makes a >> > computation every time a large FEC of traffic needs to be carried >> through his >> > ASs through a path that consumes the least power with the links therei= n >> having >> > the required bandwidth. The ratio of consumed power to the available >> > bandwidth is the metric that is used. Consumed power relates to a >> weighted >> > average of the power consumed within the AS including the edge and cor= e >> > devices while the available bw relates to the links ingressing into th= e >> AS at the >> > ASBRs that are the inter connectors between the ASes. >> > >> > >> > So in summary, we do not advocate shutting off links at all. In fact w= e >> disagree >> > with that approach. The scheme we advocate tries to optimise the power >> > consumption using the metric based approach with some heuristics. >> > >> > Hope this helps. >> > >> > Thanks and regards, >> > Balaji venkat >> > > >> > > These sorts of power optimizations all seem to be "here's how you >> reshape >> > the problem so that you can throw a linear problem solver at it". For >> example, >> > [ http://www.cs.berkeley.edu/~suchara/publications/GreenNetsBundles.pd= f]. >> > I've never seen anything which shows how much more work it will be for= a >> > network operator or which quantifies the actual savings. >> > > >> > > If you can demonstrate significant savings in real networks at littl= e >> or no cost >> > to operators, you have an idea worth pursuing. If your idea will caus= e >> more >> > operational angst (e.g. not knowing whether your unused capacity will >> be there >> > when you need it because you shut a third of it off all the time, >> increased risk of >> > equipment failure from constant power-cycling, operational tools and >> training >> > and expertise required to manage, deploy and troubleshoot variable-pow= er >> > links and the centralized NMS required to run them, etc etc etc) then >> it will find >> > little traction. Green-TE and power-aware BGP have been floating >> around for a >> > while and have seen no real uptake in the WGs as far as I can see. Is >> that not to >> > be taken as an indication that there may be no real-world interest in >> them? If >> > not, what would it take to convince you? >> > > >> > > >> > > >> > > eric >> > --e89a8fb1ee6e5e903204d5248c9c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable CCing the alias as message went out of bounds in size.

    On Thu, Feb 7, 2013 at 9:28 PM, Balaji venkat Venkataswami <balajivenkat299@gmail.com> wrote:
    Dear Eric,

    We seem to be = discussing at cross purposes.

    The root of our posi= tion is not what you have stated. We do not say if you dont use a link you = consume less power. We are not for avoiding links but we are for avoiding n= odes/routers/switches which have a large power footprint. The essence of us= ing link metrics is to avoid nodes with larger power footprints. That is ho= w SPF or CSPF works. When it computes a low power path it avoids nodes and = also links that lead to that node which has a larger power footprint. So th= e premise that we are just avoiding links is WRONG.=A0

    For #1 question, we dont even talk about the power the = link draws. We talk about the power footprint of the node that it is connec= ted to.

    For #2 question, again we state that your = premise of avoiding links in your example is a non-starter for us.

    thanks and regards,
    balaji venkat


    On Thu, Feb 7, 2013 at 9:18 P= M, Eric Osborne (eosborne) <eosborne@cisco.com> wrote:
    The root of your position seems to be that i= f you don't use a link, you consume less power, and thus avoiding certa= in links means consuming less power means saving money.

    I see two problems with this:

    1) I'm not sure that's actually true. =A0SONET, for one, sends empt= y frames when there's no data, so the laser is always firing.

    2) even if it was true, or if you had some analogue to 802.3az that you cou= ld use in backbones, I don't believe you'd save anywhere near enoug= h money to make it worth it.

    For #1, please explain the circumstances under which leaving a link idle sa= ves power, and explain how much power and what drives that power draw.

    For #2, please see my example in my original email.




    eric


    > -----Original Message-----
    > From: Shankar Raman [mailto:mjsraman@gmail.com]
    > Sent: Thursday, February 07, 2013 4:48 AM
    > To: Balaji Venkat; Eric Osborne (eosborne)
    > Cc: curtis@occnc= .com; rtgwg@ietf.or= g
    > Subject: Re: Power aware networks : Comments requested from routing > community
    >
    > Dear Eric,
    > Looks like we have not been clear in conveying our idea.
    >
    > We abstract the power consumed by every router/switch, use it as the p= ower
    > rating. We then assign it to the link as a metric characteristic to ge= t algorithms
    > like SPF and CSPF to choose the lowest power paths or any metric based= routing
    > algorithm.
    >
    > So the link metric is a combination of power consumed including the ph= ysical
    > link and router components. In effect the link metric is not just the = physical
    > link=92s metric alone (but the cost of the power consumed by the route= r/switch on
    > which it connects to the neighbor).
    >
    > Just like routing protocols consider delay, hops as metric we consider= this
    > power consumption as yet another metric.
    >
    > Thanks
    > Shankar
    >
    > -----Original Message-----
    > From: Balaji Venkat
    > Sent: Thursday, February 07, 2013 2:36 AM
    > To: Eric Osborne (eosborne)
    > Cc: curtis@occnc= .com ; Shankar Raman M J ; rtgwg@ietf.org
    > Subject: Re: Power aware networks : Comments requested from routing > community
    >
    > Dear Eric,
    >
    > Comments inline...
    >
    > Sent from my iPad
    >
    > On 07-Feb-2013, at 1:50 AM, "Eric Osborne (eosborne)"
    > <eosborne@c= isco.com> wrote:
    >
    > > You aim to optimize core networks through traffic engineering suc= h that
    > some links can be shut down when not in use, or switched to lower powe= r.
    >
    > Actually the answer is a No. We do not advocate this approach. The mai= n idea
    > in bgp power path draft has a survey section on previous literature th= at we
    > quote for reference and state that such approaches cause expensive equ= ipment
    > to be kept unused. You have quoted the survey section of the paper in = the
    > above sentence.
    >
    > >
    > > Have you done studies in core networks with real equipment that s= how the
    > actual amount of money you could save with this approach? =A0Let's= walk through
    > a quick hypothetical network, you tell me where I got it wrong.
    > >
    > > draft-mjsraman-panet-bgp-power-path says " Power consumption= can be
    > > =A0 reduced by trading off performance related measures like late= ncy. For
    > > =A0 example, power savings while switching from 1 Gbps to 100 Mbp= s is
    > > =A0 approximately 4 W and from 100 Mbps to 10 Mbps around 0.1 Wat= ts."
    >
    > Again this is a survey section of the paper surveying the existing app= roaches.
    >
    > >
    > > but provides no documentation to back these costs up nor itemizat= ion
    > > of where the power is consumed (amortized across the router? =A0l= inecard
    > > optics? =A0DWDM gear?)
    >
    > Our main intent is to allow traffic to follow low power paths through = ASs (either
    > through pce like entities or through modifying the bgp path selection<= br> > algorithm) which consume the least power and possess the required band= width.
    > By graphing the topology of a set ASs in the immediate neighbourhood u= sing
    > as-path-info strands typically for a provider manning multiple ASs wit= hin the
    > providers own control this mechanism will let large chunks of traffic = belonging
    > to a macro FEC traverse such low power ASs through an inter-as te MPLS= lsp
    > computed by a pce like entity and setup by RSVP-te.
    >
    > The use of the metric, the way the pwr metric is arrived at , the comp= utation of
    > the topology of ASs, consequent CSPF and then mapping the traffic to t= he
    > constructed LSP is the main focus if this paper. For dampening fluctua= tions in
    > the metric which are frequent heuristics algorithms are suggested.
    >
    > By no means are we advocating shutting off links. This scheme facilita= tes even
    > the follow the moon strategy naturally.
    >
    >
    > >
    > > Let's assume that this is true and that it is linear, so that= you burn
    > > 4W per Gb. =A0(side note: I suspect this is inaccurate and that s= caling
    > > is sublinear, but let's go with it because if it's sub-li= near you have
    > > even less of a use case. =A0I also think the real world is far mo= re
    > > complex, as you have all the optical transport gear to worry abou= t.
    > > But let's go with it for now.)
    > >
    > > Running a 100Gb link thus draws 400W.
    > >
    > > Let's say you have a backbone with (300) 100Gb links. =A0Tota= l power
    > > consumption is thus (300*400) =3D=3D 120 kW
    > >
    > > Running all these links for 24 hours thus draws 120*24 =3D=3D 2,8= 80 kWh
    > > =3D=3D 2.8mWh Power costs are maybe $0.10/kWh in the US. =A0Doubl= e that to
    > cover the cost of cooling, so $0.20/kWh.
    > > Thus, running the entire backbone costs $0.2 * 2,880 =3D $576/day= .
    > $210,000/year.
    > > Let's say your approach can save one third of the power cost,= which means
    > about $70,000.
    > >
    >
    >
    >
    > > An operator with 300 100Gb links in a network has hundreds of mil= lions of
    > dollars worth of gear and millions or tens of millions in payroll alon= e. =A0If you cut
    > $70k from their opex they probably wouldn't even notice. =A0That&#= 39;s one or two
    > salaries, or 0.002% of what Time Warner spent on advertising in 2006 (= see:
    > http://gaia.adage.com/images/random/FactPack06.pdf). =A0It = is a drop in the
    > bucket, if that. =A0And your proposal comes with significant work atta= ched to it,
    > and significant risk. =A0If your 40 years of experience in the network= industry don't
    > help you understand the risks you're asking an operator to take th= en you're
    > missing a crucial part of any potential real world solution. =A0I do n= ot think your
    > work should be presented at the IETF unless it makes a much stronger > argument that its benefits outweigh its costs.
    >
    > Again we are not asking the operator to shut off the equipment. He nee= ds to
    > keep it running as long as he has traffic to carry except that the pce= makes a
    > computation every time a large FEC of traffic needs to be carried thro= ugh his
    > ASs through a path that consumes the least power with the links therei= n having
    > the required bandwidth. The ratio of consumed power to the available > bandwidth is the metric that is used. Consumed power relates to a weig= hted
    > average of the power consumed within the AS including the edge and cor= e
    > devices while the available bw relates to the links ingressing into th= e AS at the
    > ASBRs that are the inter connectors between the ASes.
    >
    >
    > So in summary, we do not advocate shutting off links at all. In fact w= e disagree
    > with that approach. The scheme we advocate tries to optimise the power=
    > consumption using the metric based approach with some heuristics.
    >
    > Hope this helps.
    >
    > Thanks and regards,
    > Balaji venkat
    > >
    > > These sorts of power optimizations all seem to be "here'= s how you reshape
    > the problem so that you can throw a linear problem solver at it".= =A0For example,
    > [ http://www.cs.berkeley.edu/~suchara/publica= tions/GreenNetsBundles.pdf ].
    > I've never seen anything which shows how much more work it will be= for a
    > network operator or which quantifies the actual savings.
    > >
    > > If you can demonstrate significant savings in real networks at li= ttle or no cost
    > to operators, you have an idea worth pursuing. =A0If your idea will ca= use more
    > operational angst (e.g. not knowing whether your unused capacity will = be there
    > when you need it because you shut a third of it off all the time, incr= eased risk of
    > equipment failure from constant power-cycling, operational tools and t= raining
    > and expertise required to manage, deploy and troubleshoot variable-pow= er
    > links and the centralized NMS required to run them, etc etc etc) then = it will find
    > little traction. =A0Green-TE and power-aware BGP have been floating ar= ound for a
    > while and have seen no real uptake in the WGs as far as I can see. =A0= Is that not to
    > be taken as an indication that there may be no real-world interest in = them? =A0If
    > not, what would it take to convince you?
    > >
    > >
    > >
    > > eric
    --e89a8fb1ee6e5e903204d5248c9c-- From eosborne@cisco.com Thu Feb 7 08:09:05 2013 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 960F021F86DC for ; Thu, 7 Feb 2013 08:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.546 X-Spam-Level: X-Spam-Status: No, score=-10.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82NvoiiIMbxO for ; Thu, 7 Feb 2013 08:09:04 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id CBC0621F86EF for ; Thu, 7 Feb 2013 08:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1832; q=dns/txt; s=iport; t=1360253344; x=1361462944; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=e8dkpAgTP0juT6a26d33B6e1hI/8m2oWg3OZdNqkv3g=; b=MM2PNlhaH0UPBs8Q0f7wXGbhTZ9fV8n6fWdTwzfz0CTgstF9a+3pj/0s HDuPWnArdgOf5ZxGQ6n0SNAMY9M5RIAS8gnmyO9SiHvbrRyBadeATiJvy DEkBhXdUcD2OVNMpZ95VRoa78zoacEjhVNHKPH5HJ1VBSha8fe8mnWvGN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGXRE1GtJV2a/2dsb2JhbABFwGcWc4IfAQEBBCcTPwwEAgEIEQQBAQsUCQchERQJCAIEDgUIDIdrAw+1PQ2JVowWfRKDVmEDlEmNF4UTgwCCJA X-IronPort-AV: E=Sophos;i="4.84,622,1355097600"; d="scan'208";a="174517972" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 07 Feb 2013 16:08:56 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r17G8uJ3014557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Feb 2013 16:08:56 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 10:08:45 -0600 From: "Eric Osborne (eosborne)" To: Balaji venkat Venkataswami Subject: RE: Power aware networks : Comments requested from routing community Thread-Topic: Power aware networks : Comments requested from routing community Thread-Index: AQHOBJmILt1Dff9vjkCrdfxQNrUVWphtkbkA//+h48CAAPPu4IAAY5NAgABoWYD//5u3MA== Date: Thu, 7 Feb 2013 16:08:44 +0000 Message-ID: <20ECF67871905846A80F77F8F4A27572100BF9BD@xmb-rcd-x09.cisco.com> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <20ECF67871905846A80F77F8F4A27572100BEE0B@xmb-rcd-x09.cisco.com> <3B74A0857EB0496E8FA8B026A758D788@NCSVAIO> <20ECF67871905846A80F77F8F4A27572100BF86F@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.23.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Shankar Raman , "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, 07 Feb 2013 16:09:05 -0000 [size trimmed] OK, so you want to avoid nodes which draw more power. Are you assuming that minimizing the traffic across a node also minimizes t= he power that node draws? If yes: - please provide concrete examples of how this actually works. In my expe= rience the power draw by a router or switch is pretty constant, more driven= by the *existence* of links (because links -> linecards -> power draw) tha= n by the *traffic* on those links. If not, what do you hope to accomplish by avoiding higher-power nodes? eric > -----Original Message----- > From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com] > Sent: Thursday, February 07, 2013 10:59 AM > To: Eric Osborne (eosborne) > Cc: Shankar Raman; curtis@occnc.com; rtgwg@ietf.org > Subject: Re: Power aware networks : Comments requested from routing > community >=20 > Dear Eric, >=20 > We seem to be discussing at cross purposes. >=20 > The root of our position is not what you have stated. We do not say if yo= u dont > use a link you consume less power. We are not for avoiding links but we a= re for > avoiding nodes/routers/switches which have a large power footprint. The > essence of using link metrics is to avoid nodes with larger power footpri= nts. > That is how SPF or CSPF works. When it computes a low power path it avoid= s > nodes and also links that lead to that node which has a larger power foot= print. > So the premise that we are just avoiding links is WRONG. >=20 > For #1 question, we dont even talk about the power the link draws. We tal= k > about the power footprint of the node that it is connected to. >=20 > For #2 question, again we state that your premise of avoiding links in yo= ur > example is a non-starter for us. >=20 > thanks and regards, > balaji venkat >=20 From tony.li@tony.li Thu Feb 7 08:09:09 2013 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 113B021F86EF for ; Thu, 7 Feb 2013 08:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.237 X-Spam-Level: X-Spam-Status: No, score=-100.237 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgVIvbMAv9Qb for ; Thu, 7 Feb 2013 08:09:08 -0800 (PST) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:56]) by ietfa.amsl.com (Postfix) with ESMTP id 2F04421F87A3 for ; Thu, 7 Feb 2013 08:09:08 -0800 (PST) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta06.emeryville.ca.mail.comcast.net with comcast id xSFH1k0010QkzPwA6U97aC; Thu, 07 Feb 2013 16:09:07 +0000 Received: from [192.168.2.111] ([98.248.36.188]) by omta02.emeryville.ca.mail.comcast.net with comcast id xU961k00W43ZcXW8NU97mq; Thu, 07 Feb 2013 16:09:07 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Power aware networks : Comments requested from routing community From: Tony Li In-Reply-To: <72B40FF5-6A29-4857-93AA-768490A20903@juniper.net> Date: Thu, 7 Feb 2013 08:09:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <021A2E07-50AF-443C-AC4A-E61A28D57F6F@tony.li> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <72B40FF5-6A29-4857-93AA-768490A20903@juniper.net> To: Hannes Gredler X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360253347; bh=vQHhHsSldF1fpZ5gKXslK5gc30ZkL91sugQsP/GXuDc=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=bXkzoYTvSbR8y06b0YYiizr7VBdKlmCkc9WFJ/0g4oi0bRN8o9lsjt26U5cKoBayj 9Hpd4GHKtqIbPc4+4ZqePsABuI+pU/BlNooK9rhSDgTa8w89Ce3fYJJc8ajngW7tvg aqxJJCFtGZ0J49G2LJCYbHI6hLWCVcV2Qqbz/wuFtDQ2JT9UuYa4/7V5zFGg8UjPRo jKlVHqN8l/1h6tF3CX0A8km93dsyjT3H/zcvRBoSyxI82fposAZRxjrgcZaUyv3+qB /Qacn2A1orbtZIoT0SD2w7gDj8Ik4WM62H8+kwMxHiNPU5p5UKEyafJWWwTIyS4UnJ X1t5Gh3Yt9NRg== Cc: Shankar Raman M J , 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, 07 Feb 2013 16:09:09 -0000 On Feb 7, 2013, at 5:07 AM, Hannes Gredler wrote: > Do you think that optimizing a part of the network which gives only = limited > overall savings is a worthwhile goal ?=20 Hannes,=20 I'll just point out that this argument that you and Eric are espousing = is skirting dangerously close to the quagmire of business. And we know = from long experience that the IETF does not do business models. I'd like to strongly suggest that we simply restrict ourselves to the = goal of saving power. I think that we can agree, in general, that = saving power is a worthwhile goal. As to whether or not it is = significant or makes economic sense is very much an issue that should be = left to the operator community to decide. Limited overall savings may = be worthwhile in one context and pointless in another. I know of one country where they are purportedly mandating power = reductions. In such situations, saving that last watt is the difference = between a fine and not. On the other hand, in a situation where power = is very cheap, it's obviously silly. Let's not argue about the marginal value of energy. That's a business = model issue. Let's talk about how technology can actually save power. Regards, Tony From balajivenkat299@gmail.com Thu Feb 7 08:22:13 2013 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 2DC9D21F86F4 for ; Thu, 7 Feb 2013 08:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.395 X-Spam-Level: X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nx8Zp4VyMrXC for ; Thu, 7 Feb 2013 08:22:05 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E0F2F21F86D8 for ; Thu, 7 Feb 2013 08:22:01 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id tb18so2907491obb.31 for ; Thu, 07 Feb 2013 08:22:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kigaJ/AFOmK0SP6BjpOtYt+vsDKhEmctrySJlol3DxE=; b=kwGTJzivCPL5EZqNlEXMLLB3AqYjoBro/A7IxfpeHXmFMFEwwOTEGOV+CiizfClvZc 2p8og6dBgjg/F+93LVq3eqyv4UNN7JyPHeI8PtfkITwRwe2hI6A9TaEZ+7KYpIN6guds dtsW3RVSNhP5Ctb2dGSXkdbsFL9pWjUfg6/lgp7s+El0IH/mhJ0QGhvfR3+EMcVEJMbE S8OZk0rdU0RQe+hT3Gvm7mhPyjpe6b5fgISjIGXfiv67vN+/PDLQj7xTd21P3Ed2QyR1 xd9KLOFVJveUWtfoovfKnd03LL6ictw5JkKkzL2oxLCLK4Kfy0R9DMVbADeiWDNnFexP oAQw== MIME-Version: 1.0 X-Received: by 10.60.32.143 with SMTP id j15mr1534009oei.7.1360254121334; Thu, 07 Feb 2013 08:22:01 -0800 (PST) Received: by 10.60.93.8 with HTTP; Thu, 7 Feb 2013 08:22:01 -0800 (PST) In-Reply-To: <20ECF67871905846A80F77F8F4A27572100BF9BD@xmb-rcd-x09.cisco.com> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <20ECF67871905846A80F77F8F4A27572100BEE0B@xmb-rcd-x09.cisco.com> <3B74A0857EB0496E8FA8B026A758D788@NCSVAIO> <20ECF67871905846A80F77F8F4A27572100BF86F@xmb-rcd-x09.cisco.com> <20ECF67871905846A80F77F8F4A27572100BF9BD@xmb-rcd-x09.cisco.com> Date: Thu, 7 Feb 2013 21:52:01 +0530 Message-ID: Subject: Re: Power aware networks : Comments requested from routing community From: Balaji venkat Venkataswami To: "Eric Osborne (eosborne)" Content-Type: multipart/alternative; boundary=e89a8fb1ee6eb4d74404d524d714 Cc: Shankar Raman , "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, 07 Feb 2013 16:22:13 -0000 --e89a8fb1ee6eb4d74404d524d714 Content-Type: text/plain; charset=ISO-8859-1 Dear Eric, Please take a look at the tcam-efficiency draft that we have published. The URL to the draft is http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-efficiency-00 A follow up draft that defines TCAM efficiency in terms of a metric is also outlined in... http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-ratio-02 With the help of the above schemes and additional work that is in progress we intend to reduce the power footprint of a device/router/switch/chassis such that important power guzzling components of the router are optimized. In summary, the above 2 drafts coupled with the protocol schemes will we feel result in better power saving than what we have today. So essentially optimizing the power consumed within a device coupled with using protocol schemes between devices will result in saving power. Hope this helps. thanks and regards, balaji venkat On Thu, Feb 7, 2013 at 9:38 PM, Eric Osborne (eosborne) wrote: > [size trimmed] > > OK, so you want to avoid nodes which draw more power. > Are you assuming that minimizing the traffic across a node also minimizes > the power that node draws? > > If yes: > - please provide concrete examples of how this actually works. In my > experience the power draw by a router or switch is pretty constant, more > driven by the *existence* of links (because links -> linecards -> power > draw) than by the *traffic* on those links. > > If not, what do you hope to accomplish by avoiding higher-power nodes? > > > > > eric > > > -----Original Message----- > > From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com] > > Sent: Thursday, February 07, 2013 10:59 AM > > To: Eric Osborne (eosborne) > > Cc: Shankar Raman; curtis@occnc.com; rtgwg@ietf.org > > Subject: Re: Power aware networks : Comments requested from routing > > community > > > > Dear Eric, > > > > We seem to be discussing at cross purposes. > > > > The root of our position is not what you have stated. We do not say if > you dont > > use a link you consume less power. We are not for avoiding links but we > are for > > avoiding nodes/routers/switches which have a large power footprint. The > > essence of using link metrics is to avoid nodes with larger power > footprints. > > That is how SPF or CSPF works. When it computes a low power path it > avoids > > nodes and also links that lead to that node which has a larger power > footprint. > > So the premise that we are just avoiding links is WRONG. > > > > For #1 question, we dont even talk about the power the link draws. We > talk > > about the power footprint of the node that it is connected to. > > > > For #2 question, again we state that your premise of avoiding links in > your > > example is a non-starter for us. > > > > thanks and regards, > > balaji venkat > > > > --e89a8fb1ee6eb4d74404d524d714 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Eric,

    Please take a look at the tcam-efficiency draft that we = have published.


    A follow up draft that defines TCAM efficiency in terms= of a metric is also outlined in...


    With the help of the above schemes and additional work = that is in progress we intend to reduce the
    power footprint of a = device/router/switch/chassis such that important power guzzling components = of
    the router are optimized.=A0

    In summary, the = above 2 drafts coupled with the protocol schemes will we feel result in bet= ter power
    saving than what we have today. So essentially optimizi= ng the power consumed within a device=A0
    coupled with using protocol schemes between devices will result in sav= ing power.

    Hope this helps.

    thanks and regards,
    balaji venkat

    On Thu, Feb 7, 2013 at 9:38 PM, Eric Osborne (eosborne) &= lt;eosborne@cisco.c= om> wrote:
    [size trimmed]

    OK, so you want to avoid nodes which draw more power.
    Are you assuming that minimizing the traffic across a node also minimizes t= he power that node draws?

    If yes:
    =A0- please provide concrete examples of how this actually works. =A0In my = experience the power draw by a router or switch is pretty constant, more dr= iven by the *existence* of links (because links -> linecards -> power= draw) than by the *traffic* on those links.

    If not, what do you hope to accomplish by avoiding higher-power nodes?




    eric

    > -----Original Message-----
    > From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com]
    > Sent: Thursday, February 07, 2013 10:59 AM
    > To: Eric Osborne (eosborne)
    > Cc: Shankar Raman; curtis@occnc.com; rtg= wg@ietf.org
    > Subject: Re: Power aware networks : Comments requested from routing > community
    >
    > Dear Eric,
    >
    > We seem to be discussing= at cross purposes.
    >
    > The root of our position is not what you have stated. We do not say if= you dont
    > use a link you consume less power. We are not for avoiding links but w= e are for
    > avoiding nodes/routers/switches which have a large power footprint. Th= e
    > essence of using link metrics is to avoid nodes with larger power foot= prints.
    > That is how SPF or CSPF works. When it computes a low power path it av= oids
    > nodes and also links that lead to that node which has a larger power f= ootprint.
    > So the premise that we are just avoiding links is WRONG.
    >
    > For #1 question, we dont even talk about the power the link draws. We = talk
    > about the power footprint of the node that it is connected to.
    >
    > For #2 question, again we state that your premise of avoiding links in= your
    > example is a non-starter for us.
    >
    > thanks and regards,
    > balaji venkat
    >


    --e89a8fb1ee6eb4d74404d524d714-- From akatlas@gmail.com Thu Feb 7 08:22:27 2013 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 4174921F86FB for ; Thu, 7 Feb 2013 08:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSpVPbGGDV3u for ; Thu, 7 Feb 2013 08:22:17 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A810121F86D8 for ; Thu, 7 Feb 2013 08:22:16 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id c11so3758091ieb.15 for ; Thu, 07 Feb 2013 08:22:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+1kTqLBYtBl2wP96nBoshDlJxKtWOrWRxnQ6493LAK8=; b=tAxltYW6sKyqD4NKlhDEmjXBTRGnkRAZ2UeVbF3Nd47z448k8sXS0gL/jGC3V/uU1s NqBqQzFsC1GqWYW9uJfOV8Jdx7mCuOk+bBC0f9MC/lDKVTRE+sbRVgxHHRMw3wUZuO22 5Sw4uXAUXLOPwrEmYqnUsVX5mKoVVzDK607nayDXhkeAbkeShsbAUuTJdrIEGIDMukL4 RPsAdBjDHbpVQmUPatC6MD1n4euwYVGsIx+6pvSSePGJToYkjBTAfVwOilBP05k0WMbl FzeamXswoPBHymg+72r6eRkJIG1LGwmE96qaQZ+G5Rs8+gxoVtG7efAM9y+PmxsXUhbo O8rw== MIME-Version: 1.0 X-Received: by 10.50.153.198 with SMTP id vi6mr15680635igb.112.1360254135699; Thu, 07 Feb 2013 08:22:15 -0800 (PST) Received: by 10.64.34.203 with HTTP; Thu, 7 Feb 2013 08:22:15 -0800 (PST) In-Reply-To: <021A2E07-50AF-443C-AC4A-E61A28D57F6F@tony.li> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <72B40FF5-6A29-4857-93AA-768490A20903@juniper.net> <021A2E07-50AF-443C-AC4A-E61A28D57F6F@tony.li> Date: Thu, 7 Feb 2013 11:22:15 -0500 Message-ID: Subject: Re: Power aware networks : Comments requested from routing community From: Alia Atlas To: Tony Li Content-Type: multipart/alternative; boundary=e89a8f22c68190087f04d524d86a Cc: Shankar Raman M J , 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, 07 Feb 2013 16:22:27 -0000 --e89a8f22c68190087f04d524d86a Content-Type: text/plain; charset=ISO-8859-1 There are two different aspects to power-aware routing that I think are of interest. The first is developing a framework and method for evaluating different possible solutions. We had a discussion of draft-retana-rtgwg-eacp-00 in RTGWG in July 2012. The second is examining and considering control plane and routing solutions in that context. That seems to me to be more likely something for the IRTF, rather than the IETF. The former, however, is where I think that the IETF's operational knowledge and experience could be useful in framing what would be a useful solution. Would it be possible to discuss this work that Balaji is presenting in that context? In other words, if the goal of the solution is X,Y, and Z, then this mechanism seems useful/ not useful, has stability concerns, etc. And then there are the questions about assumptions and goals... All of this is great to discuss in RTGWG - there's been significant interest, but what is mature enough for the IETF vs. the IRTF and whether there are sufficient people to work in the area is not clear. Alia On Thu, Feb 7, 2013 at 11:09 AM, Tony Li wrote: > > On Feb 7, 2013, at 5:07 AM, Hannes Gredler wrote: > > > Do you think that optimizing a part of the network which gives only > limited > > overall savings is a worthwhile goal ? > > > Hannes, > > I'll just point out that this argument that you and Eric are espousing is > skirting dangerously close to the quagmire of business. And we know from > long experience that the IETF does not do business models. > > I'd like to strongly suggest that we simply restrict ourselves to the goal > of saving power. I think that we can agree, in general, that saving power > is a worthwhile goal. As to whether or not it is significant or makes > economic sense is very much an issue that should be left to the operator > community to decide. Limited overall savings may be worthwhile in one > context and pointless in another. > > I know of one country where they are purportedly mandating power > reductions. In such situations, saving that last watt is the difference > between a fine and not. On the other hand, in a situation where power is > very cheap, it's obviously silly. > > Let's not argue about the marginal value of energy. That's a business > model issue. Let's talk about how technology can actually save power. > > Regards, > Tony > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --e89a8f22c68190087f04d524d86a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There are two different aspects to power-aware routing that I think are of = interest.
    The first is developing a framework and method for evaluating= different possible solutions.
    We had a discussion of=A0draft-ret= ana-rtgwg-eacp-00 in RTGWG in July 2012.

    The second is examining and considering control plane a= nd routing solutions in that context.
    That seems to me to be more= likely something for the IRTF, rather than the IETF.

    The former, however, is where I think that the IETF's operational = knowledge and experience
    could be useful in framing what would be= a useful solution.

    Would it be possible to discus= s this work that Balaji is presenting in that context?
    In other words, if the goal of the solution is X,Y, and Z, then this m= echanism seems useful/
    not useful, has stability concerns, etc.

    And then there are the questions about assumptions = and goals... =A0All of this is great to
    discuss in RTGWG - there's been significant interest, but what is = mature enough for the=A0
    IETF vs. the IRTF and whether there are = sufficient people to work in the area is not clear.

    Alia

    On Thu, Feb 7, 2013 at 11:09 AM, Ton= y Li <tony.li@tony.li> wrote:

    On Feb 7, 2013, at 5:07 AM, Hannes Gredler <hannes@juniper.net> wrote:

    > Do you think that optimizing a part of the network which gives only li= mited
    > overall savings is a worthwhile goal ?


    Hannes,

    I'll just point out that this argument that you and Eric are espousing = is skirting dangerously close to the quagmire of business. =A0And we know f= rom long experience that the IETF does not do business models.

    I'd like to strongly suggest that we simply restrict ourselves to the g= oal of saving power. =A0I think that we can agree, in general, that saving = power is a worthwhile goal. =A0As to whether or not it is significant or ma= kes economic sense is very much an issue that should be left to the operato= r community to decide. =A0Limited overall savings may be worthwhile in one = context and pointless in another.

    I know of one country where they are purportedly mandating power reductions= . =A0In such situations, saving that last watt is the difference between a = fine and not. =A0On the other hand, in a situation where power is very chea= p, it's obviously silly.

    Let's not argue about the marginal value of energy. =A0That's a bus= iness model issue. =A0Let's talk about how technology can actually save= power.

    Regards,
    Tony

    _______________________________________________
    rtgwg mailing list
    rtgwg@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/rtgwg

    --e89a8f22c68190087f04d524d86a-- From balajivenkat299@gmail.com Thu Feb 7 08:34:08 2013 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 B813F21F8546 for ; Thu, 7 Feb 2013 08:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eo-zZ2YvokmK for ; Thu, 7 Feb 2013 08:34:07 -0800 (PST) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by ietfa.amsl.com (Postfix) with ESMTP id C350421F851F for ; Thu, 7 Feb 2013 08:34:07 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id wd20so2850325obb.23 for ; Thu, 07 Feb 2013 08:34:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fpSRbHv1YUh+KgbXZq1r74HqxzaxiPUbEBM2FzKROjY=; b=A6JQuM2Orrya8+JKUsyVfJXdSrk8O+a2szmyWk8Xl1crN0ULy8cv0epM9CYh40sW4z owr+v17SN3wgSPPS1EesinUH32YTz0KvFqfm1N7DcsRXTUUR//xE/qtS8ikOCQIyKIlJ hho2wZpHq/loPpttw/reEZGF71qgsA6Cnwj32hYR5IwWQhcbSBLUQPM0vUHl8g4jx9sB +DMAseEnmiDxzpQBAtBqTG/pMiDc8iKTkWEXfzX+TRWQixs6GFDfDRkYK9iX6KmnWq8Y 4CbOFwMUmlw6I5Ex+p4dhBEieTXtoucMagru2dBYFNdSYN+me7Zns/pDVUP6rnOCOjQ5 NYwQ== MIME-Version: 1.0 X-Received: by 10.60.8.199 with SMTP id t7mr1534852oea.26.1360254847291; Thu, 07 Feb 2013 08:34:07 -0800 (PST) Received: by 10.60.93.8 with HTTP; Thu, 7 Feb 2013 08:34:07 -0800 (PST) In-Reply-To: References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <20ECF67871905846A80F77F8F4A27572100BEE0B@xmb-rcd-x09.cisco.com> <3B74A0857EB0496E8FA8B026A758D788@NCSVAIO> <20ECF67871905846A80F77F8F4A27572100BF86F@xmb-rcd-x09.cisco.com> <20ECF67871905846A80F77F8F4A27572100BF9BD@xmb-rcd-x09.cisco.com> Date: Thu, 7 Feb 2013 22:04:07 +0530 Message-ID: Subject: Re: Power aware networks : Comments requested from routing community From: Balaji venkat Venkataswami To: "Eric Osborne (eosborne)" Content-Type: multipart/alternative; boundary=e89a8ff1ce46fa126704d52502a4 Cc: Shankar Raman , "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, 07 Feb 2013 16:34:08 -0000 --e89a8ff1ce46fa126704d52502a4 Content-Type: text/plain; charset=ISO-8859-1 Dear Eric, You had written... If yes... - please provide concrete examples of how this actually works. In my experience the power draw by a router or switch is pretty constant, more driven by the *existence* of links (because links -> linecards -> power draw) than by the *traffic* on those links. If not, what do you hope to accomplish by avoiding higher-power nodes? Our answer to the above question is this. We are rephrasing the question as "Can you send more traffic through low power consuming nodes ?". Therefore If yes does not come into the picture. The end objective slowly the traffic will migrate to the low power nodes and the high power consuming nodes can be dismantled. The other mail for TCAM that I had sent will deal with answer to your problem. thanks and regards, balaji venkat On Thu, Feb 7, 2013 at 9:52 PM, Balaji venkat Venkataswami < balajivenkat299@gmail.com> wrote: > Dear Eric, > > Please take a look at the tcam-efficiency draft that we have published. > > The URL to the draft is > http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-efficiency-00 > > A follow up draft that defines TCAM efficiency in terms of a metric is > also outlined in... > > http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-ratio-02 > > With the help of the above schemes and additional work that is in progress > we intend to reduce the > power footprint of a device/router/switch/chassis such that important > power guzzling components of > the router are optimized. > > In summary, the above 2 drafts coupled with the protocol schemes will we > feel result in better power > saving than what we have today. So essentially optimizing the power > consumed within a device > coupled with using protocol schemes between devices will result in saving > power. > > Hope this helps. > > thanks and regards, > balaji venkat > > On Thu, Feb 7, 2013 at 9:38 PM, Eric Osborne (eosborne) < > eosborne@cisco.com> wrote: > >> [size trimmed] >> >> OK, so you want to avoid nodes which draw more power. >> Are you assuming that minimizing the traffic across a node also minimizes >> the power that node draws? >> >> If yes: >> - please provide concrete examples of how this actually works. In my >> experience the power draw by a router or switch is pretty constant, more >> driven by the *existence* of links (because links -> linecards -> power >> draw) than by the *traffic* on those links. >> >> If not, what do you hope to accomplish by avoiding higher-power nodes? >> >> >> >> >> eric >> >> > -----Original Message----- >> > From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com] >> > Sent: Thursday, February 07, 2013 10:59 AM >> > To: Eric Osborne (eosborne) >> > Cc: Shankar Raman; curtis@occnc.com; rtgwg@ietf.org >> > Subject: Re: Power aware networks : Comments requested from routing >> > community >> > >> > Dear Eric, >> > >> > We seem to be discussing at cross purposes. >> > >> > The root of our position is not what you have stated. We do not say if >> you dont >> > use a link you consume less power. We are not for avoiding links but we >> are for >> > avoiding nodes/routers/switches which have a large power footprint. The >> > essence of using link metrics is to avoid nodes with larger power >> footprints. >> > That is how SPF or CSPF works. When it computes a low power path it >> avoids >> > nodes and also links that lead to that node which has a larger power >> footprint. >> > So the premise that we are just avoiding links is WRONG. >> > >> > For #1 question, we dont even talk about the power the link draws. We >> talk >> > about the power footprint of the node that it is connected to. >> > >> > For #2 question, again we state that your premise of avoiding links in >> your >> > example is a non-starter for us. >> > >> > thanks and regards, >> > balaji venkat >> > >> >> > --e89a8ff1ce46fa126704d52502a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Eric,

    You had written...

    I= f yes...
    =A0- please provide concrete examples of how this actually work= s. =A0In my experience the power draw by a router or switch is pretty const= ant, more driven by the *existence* of links (because links -> linecards= -> power draw) than by the *traffic* on those links.

    If not, what do you hope to accomplish by avoiding higher-power nodes?<= br>

    <balajivenkat> Our answer to the above q= uestion is this. We are rephrasing the question as "Can you send more = traffic through low power consuming nodes ?". Therefore If yes does no= t come into the picture.

    The end objective slowly the traffic will migrate to th= e low power nodes and the high power consuming nodes can be dismantled.

    The other mail for TCAM that I had sent will deal wit= h answer to your problem.


    thanks and regards,
    balaji ven= kat=A0

    On Thu, Feb 7, 2013 at 9:52 PM, Ba= laji venkat Venkataswami <balajivenkat299@gmail.com>= wrote:
    Dear Eric,

    Please take a look at the= tcam-efficiency draft that we have published.


    A follow up draft that defines TCAM efficiency in terms= of a metric is also outlined in...


    With the help of the above schemes and additional work = that is in progress we intend to reduce the
    power footprint of a = device/router/switch/chassis such that important power guzzling components = of
    the router are optimized.=A0

    In summary, the = above 2 drafts coupled with the protocol schemes will we feel result in bet= ter power
    saving than what we have today. So essentially optimizi= ng the power consumed within a device=A0
    coupled with using protocol schemes between devices will result in sav= ing power.

    Hope this helps.

    thanks and regards,
    balaji venkat

    On Thu, Feb 7, 2013 at 9:38 PM, Eric Osborne (eosborne) &= lt;eosborne@cisco.c= om> wrote:
    [size trimmed]

    OK, so you want to avoid nodes which draw more power.
    Are you assuming that minimizing the traffic across a node also minimizes t= he power that node draws?

    If yes:
    =A0- please provide concrete examples of how this actually works. =A0In my = experience the power draw by a router or switch is pretty constant, more dr= iven by the *existence* of links (because links -> linecards -> power= draw) than by the *traffic* on those links.

    If not, what do you hope to accomplish by avoiding higher-power nodes?




    eric

    > -----Original Message-----
    > From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com]
    > Sent: Thursday, February 07, 2013 10:59 AM
    > To: Eric Osborne (eosborne)
    > Cc: Shankar Raman; curtis@occnc.com; rtgwg@ietf.org
    > Subject: Re: Power aware networks : Comments requested from routing > community
    >
    > Dear Eric,
    >
    > We seem to be discussing at cross purposes.
    >
    > The root of our position is not what you have stated. We do not say if= you dont
    > use a link you consume less power. We are not for avoiding links but w= e are for
    > avoiding nodes/routers/switches which have a large power footprint. Th= e
    > essence of using link metrics is to avoid nodes with larger power foot= prints.
    > That is how SPF or CSPF works. When it computes a low power path it av= oids
    > nodes and also links that lead to that node which has a larger power f= ootprint.
    > So the premise that we are just avoiding links is WRONG.
    >
    > For #1 question, we dont even talk about the power the link draws. We = talk
    > about the power footprint of the node that it is connected to.
    >
    > For #2 question, again we state that your premise of avoiding links in= your
    > example is a non-starter for us.
    >
    > thanks and regards,
    > balaji venkat
    >



    --e89a8ff1ce46fa126704d52502a4-- From curtis@occnc.com Thu Feb 7 12:21:10 2013 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 942AF21F88D8 for ; Thu, 7 Feb 2013 12:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYlazwNX1DrC for ; Thu, 7 Feb 2013 12:21:08 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 855AD21F87DC for ; Thu, 7 Feb 2013 12:21:06 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r17KIPnO001596; Thu, 7 Feb 2013 15:18:26 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302072018.r17KIPnO001596@gateway1.orleans.occnc.com> To: Mingui Zhang From: Curtis Villamizar Subject: Re: Power aware networks : Comments requested from routing community In-reply-to: Your message of "Thu, 07 Feb 2013 03:53:19 GMT." <4552F0907735844E9204A62BBDD325E732AFF1A1@nkgeml508-mbx.china.huawei.com> Date: Thu, 07 Feb 2013 15:18:25 -0500 Cc: Shankar Raman M J , "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, 07 Feb 2013 20:21:10 -0000 In message <4552F0907735844E9204A62BBDD325E732AFF1A1@nkgeml508-mbx.china.huawei.com> Mingui Zhang writes: > Hi Curtis, > > I am very happy that you know GreenTE so well. Very good comments. As > the designer of the GreenTE model, I feel obliged to clarify some of > the confusions. Please see in-lines below. > > Thanks, > Mingui Zhang > Huawei Technologies Mingui, Thank you for the clarifications. A few comments are inline. Curtis > >-----Original Message----- > >From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > >Curtis Villamizar > >Sent: Thursday, February 07, 2013 4:05 AM > >To: Balaji venkat Venkataswami > >Cc: Shankar Raman M J; rtgwg@ietf.org > >Subject: Re: Power aware networks : Comments requested from routing > >community > > > > > >In message > > >mail.com> > >Balaji venkat Venkataswami writes: > > > >> As you might recall one such research paper on GreenTE by Beichuan > >> Zhang rang a lot of bells in the IETF by collecting the ANRP prize. So > >> please dont misstate facts as you might know them and shove your ideas > >> of how networks are built down our throats. > > > >That was a research paper published in IEEE International Conference > >on Network Protocols (ICNP). > > > >Power savings potential (a computation, not a measurement) were as > >high as 20-40%. That is good but ... > > > >Line cards considered were old OC3, OC48, and one port OC192 cards. > >The paper ignores the reality that shutting off one port on a > >multiport card makes little difference, certainly far less than a > >reduction of 1/N. The power consumption of transport was not > >included. Impact on fault restoration was not considered. Lots of > >other flaws, but still good work and a potential 20-40% is nice, even > >if factoring in reality might get only half that or less. > > If you read the model, you will find a variable B_m. It indicates the > base power of the line card. This base power is high and can only be > saved when all ports on a multiport card are shutting off. So the > model did consider the reality that "shutting one port saves far less > than a reduction of 1/N". Having said that, I agree that your reality > is based on most current practice. But vendors can purposely provide > line cards with single port. Then the card can be shut off when the > port is shut off. Also, don't forget about composite links which are > powered physically separately. GreenTE is now able to handle composite > links. We have a demo website to show this: http://greente.65536.cn/. You are correct. B_m does consider baseline power. Line cards with single ports are impractical. The fastest interfaces are 100 Gb/s. Packet processors ranging up to 500 Gb/s (line side plus fabric side, so max 2x 100G) exist today (though they are few and very recent) and 100G chips exist today (100G line side, plus > 100G fabric side). Some chassis today make use of a 500+ Gb/s card slot. Composite Link or any other means of shutting down specific ports may help. Shutting down ULH transport capacity on a DWDM is more problematic than shutting down a VSR Ethernet. Even so, when the forwarding chip supports more than one port, as is common, only the MSA can be shut off. In such a case, shutting down the receive side saves nothing, so either side could initiate a bring up. For lower speed interfaces, today's forwarding chips support on the order of 12-24 x 10 GbE and much larger numbers of GbE. > Let me add another positive reality: when link cards are shutting off > in a chassis, blowers in the same chassis may be shutting off or > operate at a low speed. This helps the whole chassis save more power. Yes. Even running an average packet size of larger than minimum packet size should reduce power draw (less PPS) unless the vendor is cheating a bit in the max power draw figure. The fan speed will not be at max except with fully utilized cards in all slots and AC fail. > >The point though is that a 1 port OC192 at 174 watts (10 Gb/s) is no > >match for a 500 Gb/s card at roughly 650 watts. That is more than > >40%. It is more than a decimal order of magnitude greater. It is not > >comparing apples to oranges, one is an IP/MPLS router with full > >routing tables and short haul interfaces, the other does OTN switching > >drives either short haul or long haul transport interfaces, and could > >do IP/MPLS, but with only IGP routes and MPLS LSPs at that power > >figure. So maybe the way the network is built needs to change. > > > > What do you mean about the number "40%"? Anyway, line cards consume a > large percentage of energy of the whole Chassis and this percentage is > increasing fast. This judgment always holds. > > GreenTE only cares about line cards. So 20-40% saving actually means > 20-40% of the total power consumed by all line-cards. I think the range of potential savings in the figures indicates a maximum of 20-40% saving network wide. > >Anyway, if *I* were to continue this discussion, then *I* should get > >off the IETF lists and go write an academic paper. [Or better yet, > >work for a service provider or equipment vendor and work toward > >building better equipment and networks.] > > > >The point is that efficiency has gone up by orders of magnitude as we > >went from OC3 to OC12 to OC48 to OC192 (circa 1995-2000) and then > >multiport OC192 and OC768 and 10GbE (circa 2005-2010) to 100GbE and > >ODU4 (somewhat recent) to multiport 100GbE and ODU4 (even more > >recent). Power per bit drops about one to two decimal order of > >magnitude per decade and for any given a specific snapshot in the > >technology timeline, there are means to reduce power that get far more > >than the 20-40% that GreenTE potentially offers. > > Besides the power saved from the efficiency of the hardware, GreenTE > can add another 20-40% saving, right? :) Yes. I am not arguing against continued work on GreenTE. I am saying that it is still in the research stage and there are bigger gains elsewhere. > >Of course a new generation of equipment means CapEx and GreenTE is > >perceived as just routing and therefore free, so therefore the > >interest. > > > >Another point is that no one ever tried this on a real network. With > >RSVP-TE no protocol changes would be necessary, just offline > >computation, a configured preferred explicit-path, and some interface > >shutdowns. I don't know that anyone has even measured the reduction > >in power of an idled or administratively shut down interface or line > >card. There was nothing in the paper on this. > > > >> > If you want to try to advance a research paper with your theories on > >> > power reduction, please choose an appropriate venue such as a refereed > >> > technical journal. > > > >I repeat my main point. [And hope to be among the reviewers] > > > >Also IMHO GreenTE as described by Zhang is more likely to be feasible > >with MPLS and RSVP-TE than with OSPF or BGP or PIM, etc. But then, > >the feasibility and potential benefits of GreenTE using IGP, BGP, and > >PIM is what your academic paper can try to defend. > > When a link is shut off, no control messages (e.g., HELLOs) can be > delivered on it. Link state routing protocols (e.g., ISIS, OSPF), is > required to be aware of this. The network should never be partitioned. If partitioned due to network fault, leaving the recieve side up with minimal logic enabled allows either side to enable reactivation. Detection of a partition could also trigger bringing up idled capacity. > [end of my clarifications] Thanks again for the clarifications. GreenTE is a worthwhile research topic to pursue. My primary point is that it still remain a topic of research and attempts at IETF standardization are premature. From curtis@occnc.com Thu Feb 7 13:26:16 2013 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 4D26821F88CC for ; Thu, 7 Feb 2013 13:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.368 X-Spam-Level: X-Spam-Status: No, score=-0.368 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8M-vMBAurRSc for ; Thu, 7 Feb 2013 13:26:15 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECA021F86AA for ; Thu, 7 Feb 2013 13:26:14 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r17LNee0001986; Thu, 7 Feb 2013 16:23:40 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302072123.r17LNee0001986@gateway1.orleans.occnc.com> To: Balaji venkat Venkataswami From: Curtis Villamizar Subject: Re: Power aware networks : Comments requested from routing community In-reply-to: Your message of "Thu, 07 Feb 2013 19:22:46 +0530." Date: Thu, 07 Feb 2013 16:23:39 -0500 Cc: Shankar Raman M J , 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, 07 Feb 2013 21:26:16 -0000 Balaji, This response was directed to Hannes, but I'll point out that we do have a homenet WG within IETF. See inline. Curtis In message Balaji venkat Venkataswami writes: > > Dear Hannes, > > We are familiar with the presentation that you have referred to. > > I have 3 questions for you. > > a) While we agree with the presentation that you have mentioned, can > we in the IETF have control over the home appliances and subscriber > line kit ? Is there a methodology by which we can optimize the > power consumption on these devices ? Perhaps homenet WG could take on work in this area. > b) The problem space that the IETF can take up can be only in the edge > and core devices in the ISP networks and the Campus/DC/Metro > etc...Assume that I have n devices today with the same bandwidth > offering but differing power consumption footprint, is there a way > today to automatically send traffic through low power paths in the > topology of these devices. There is no routing based solution but there are ways to put home devices into standby or otherwise save significant amounts of power. > c) So we can optimize power only on what we can control. What are your > views on this ? If "we" is IETF, IETF can do work in home networking and historically has done lots of work in the applications area and now has a homenet WG which could recharter but may feel that power expertise in home networking devices lies elsewhere. Curtis > thanks and regards, > balaji venkat > > On Thu, Feb 7, 2013 at 6:37 PM, Hannes Gredler wrote: > > > balaji, > > > > may i put your attention to a talk that francois lemarchand > > gave on future net 2010. > > https://www.dropbox.com/s/3jb9au2zca4nl3x/10_fn_S29.pdf > > contains a copy. > > > > slide 2 initially shows that the core and edge layer might be appealing > > due to their per-box power print. however slide 15 discusses the > > big picture where 99.99% of the power is burned by the home > > appliances and subscriber line kit. > > > > Do you think that optimizing a part of the network which gives only limited > > overall savings is a worthwhile goal ? Note that SPs already ask their > > vendors > > about reducing the power footprint of those core devices by improved, > > (sometimes > > less functional) silicon forwarding engines. > > > > /hannes > > > > On Feb 6, 2013, at 7:41 PM, Curtis Villamizar wrote: > > > > > > > > Balaji, > > > > > > "We" in the context of your first paragraph seems to be a > > > misrepresentation. The authors of all of these drafts seem to be from > > > the same university in India. From prior attempts on your part to get > > > a draft of this sort into IDR and a brief reading of a few of the > > > drafts that you have just submitted, you don't seem to have a good > > > understanding of how networks are built and how network equipment is > > > built from which to begin to attack the problem of reducing the power > > > consumption of these networks. > > > > > > If you want to try to advance a research paper with your theories on > > > power reduction, please choose an appropriate venue such as a refereed > > > technical journal. > > > > > > Curtis > > > > > > > > > In message < > > CAHF4apO9bEkPk7QwA9fgJq9BNUNHNv+OFon_9_4Oij61e11r9w@mail.gmail.com> > > > Balaji venkat Venkataswami writes: > > > > > >> Dear all, > > >> > > >> We are a group of research and industry individuals tied together with a > > >> common goal towards reducing the energy consumption in the core and edge > > >> networks. > > >> > > >> We present a metric-based hierarchical approach to reduce power > > consumption > > >> in core and edge networks. The proposal considers both unicast and the > > >> multicast cases. For unicast, the metric considered is *consumed-power > > to > > >> available-bandwidth* and for multicast the metric is *consumed-power to > > >> available-replication-capacity.* > > >> > > >> With unicast, the metric is used to determine a low-power path between > > >> sources and destinations. With multicast, the metric serves the twin > > >> purpose of finding low-power multicast paths as well as multicast > > >> replication points. We evolve multiple techniques at various > > hierarchical > > >> levels. One at the Inter-AS level, Inter-Area level within the AS and > > >> intra-Area within an AS. Additionally, the proposed method can also be > > used > > >> to determine disjoint or redundant paths for load balancing or fault > > >> tolerance. Additionally since TCAMs are one of the biggest power > > guzzlers > > >> in all the components on a router/switch, we have presented a solution > > for > > >> intra-AS purposes to use the TCAM according to the traffic matrix > > passing > > >> through the system and shut down those TCAM banks that are unused. With > > >> this in mind, we have also advocated taking into account a > > TCAM-POWER-Ratio > > >> in order to compute the paths from source to destination based on this > > >> metric. Once low-power paths, in either the unicast or the multicast > > cases, > > >> are identified then currently available traffic engineering techniques > > >> could be used to route the data packets. In the case of inter-AS BGP > > path > > >> selection is also modified to arrive at paths which are low-power paths. > > >> > > >> Our main objective is as follows... > > >> > > >> We now outline four important aspects that any approach for power > > reduction > > >> should be capable of addressing. > > >> > > >> *Should cater for both unicast and multicast scenarios* > > >> > > >> Multicast provides an important scenario for the Internet. Today, most > > >> proposals consider mainly low-power path routing with unicast traffic. > > >> Multicast traffic has received a lot of attention in wireless networks, > > but > > >> not in the wired domain. Any new proposal should be able to address both > > >> the unicast and the multicast traffic scenarios. Having different > > methods > > >> for these two scenarios might lead to unnecessary processing burden in > > the > > >> routers, which might hinder its scalability. > > >> > > >> *Should not rely on just switching off unused links* > > >> > > >> Most approaches to optimize energy pursue the following approach: > > measure, > > >> monitor and respond to the system energy usage by switching off unused > > or > > >> under-utilized links. Such an approach could be effective for reducing > > >> power locally. The effect on the network is not clearly understood. > > >> Further, the power usage involved in turning on and > > rebooting/reconfiguring > > >> the device is often not explicitly considered. We note that Service > > Level > > >> Agreement (SLA) requirements may not even permit the links to be > > switched > > >> off. Also services provided by ISPs like Virtual Private Networks (VPNs) > > >> can be affected by such re-routing decisions. > > >> > > >> *Should follow an hierarchical and distributed approach* > > >> > > >> For scalability, it is important that the algorithms proposed for > > inter-AS > > >> should also be applicable to intra-AS situations. Networks do not work > > in > > >> isolation, so any proposal should be both distributed and hierarchical. > > The > > >> algorithms should be applicable at every level of the hierarchy. > > >> > > >> *Should provide incentives for ISP for adoption* > > >> > > >> The engineering proposals should be aligned with commercial incentives > > for > > >> rapid and widespread adoption. Today, the device manufacturers and the > > ISPs > > >> operate independently of each other, and there is no incentive for > > >> manufacturers to work towards low-power and high bandwidth devices. An > > >> ISP=92s revenue model is based on the consumed bandwidth, which in turn > > lea= > > >> d > > >> naturally to more power consumption. If the proposed method chooses > > routers > > >> that consume low-power and increase the data flow through them, then > > this > > >> indirectly provides encouragement for ISPs to purchase low-power and > > high > > >> bandwidth devices. > > >> > > >> > > >> > > >> We now present our metric-based proposals in the below mentioned drafts > > >> which addresses the aforementioned design aspects. > > >> > > >> We would like the routing community to provide feedback on these > > drafts. We > > >> also intend to present this work in an abridged format in the upcoming > > IETF= > > >> . > > >> > > >> The drafts are as follows.... From curtis@occnc.com Thu Feb 7 14:00:35 2013 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 87D7121F8A69 for ; Thu, 7 Feb 2013 14:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.374 X-Spam-Level: X-Spam-Status: No, score=-0.374 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDIAuqjSCYPp for ; Thu, 7 Feb 2013 14:00:35 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id C93E621F8481 for ; Thu, 7 Feb 2013 14:00:34 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r17LvxFl002170; Thu, 7 Feb 2013 16:57:59 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302072157.r17LvxFl002170@gateway1.orleans.occnc.com> To: Balaji venkat Venkataswami From: Curtis Villamizar Subject: Re: Power aware networks : Comments requested from routing community In-reply-to: Your message of "Thu, 07 Feb 2013 21:52:01 +0530." Date: Thu, 07 Feb 2013 16:57:59 -0500 Cc: Shankar Raman , "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, 07 Feb 2013 22:00:35 -0000 In message Balaji venkat Venkataswami writes: > Dear Eric, > > Please take a look at the tcam-efficiency draft that we have published. > > The URL to the draft is > http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-efficiency-00 > > A follow up draft that defines TCAM efficiency in terms of a metric is > also outlined in... > > http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-ratio-02 > > With the help of the above schemes and additional work that is in > progress we intend to reduce the power footprint of a > device/router/switch/chassis such that important power guzzling > components of the router are optimized. > > In summary, the above 2 drafts coupled with the protocol schemes will > we feel result in better power saving than what we have today. So > essentially optimizing the power consumed within a device coupled with > using protocol schemes between devices will result in saving power. > > Hope this helps. > > thanks and regards, > balaji venkat balaji, This is in the realm of router design. You are suggesting a TCAM in which banks can be shut off by reducing the number of destination addresses in the FIB. A better solution to reduce the power consumed by TCAM is don't use a TCAM. It is fast, but a radix trie based approach or other tree approach consumes less power and pipelining makes such an approach feasible if the lookup memory can be kept on-chip. MPLS lookup can be easily done in on chip SRAM rather than TCAM consuming mush less power than an on-chip TCAM and a fraction of the power of off chip TCAM due to the SERDES power needed to go off chip. This pair of drafts in particular should be dropped. Curtis > On Thu, Feb 7, 2013 at 9:38 PM, Eric Osborne (eosborne) > wrote: > > > [size trimmed] > > > > OK, so you want to avoid nodes which draw more power. > > Are you assuming that minimizing the traffic across a node also minimizes > > the power that node draws? > > > > If yes: > > - please provide concrete examples of how this actually works. In my > > experience the power draw by a router or switch is pretty constant, more > > driven by the *existence* of links (because links -> linecards -> power > > draw) than by the *traffic* on those links. > > > > If not, what do you hope to accomplish by avoiding higher-power nodes? > > > > > > > > > > eric > > > > > -----Original Message----- > > > From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com] > > > Sent: Thursday, February 07, 2013 10:59 AM > > > To: Eric Osborne (eosborne) > > > Cc: Shankar Raman; curtis@occnc.com; rtgwg@ietf.org > > > Subject: Re: Power aware networks : Comments requested from routing > > > community > > > > > > Dear Eric, > > > > > > We seem to be discussing at cross purposes. > > > > > > The root of our position is not what you have stated. We do not say if > > you dont > > > use a link you consume less power. We are not for avoiding links but we > > are for > > > avoiding nodes/routers/switches which have a large power footprint. The > > > essence of using link metrics is to avoid nodes with larger power > > footprints. > > > That is how SPF or CSPF works. When it computes a low power path it > > avoids > > > nodes and also links that lead to that node which has a larger power > > footprint. > > > So the premise that we are just avoiding links is WRONG. > > > > > > For #1 question, we dont even talk about the power the link draws. We > > talk > > > about the power footprint of the node that it is connected to. > > > > > > For #2 question, again we state that your premise of avoiding links in > > your > > > example is a non-starter for us. > > > > > > thanks and regards, > > > balaji venkat From curtis@occnc.com Thu Feb 7 14:02:44 2013 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 1640B21F8A06 for ; Thu, 7 Feb 2013 14:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.379 X-Spam-Level: X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WsN1N2UvTAd for ; Thu, 7 Feb 2013 14:02:43 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE5B21F8B5E for ; Thu, 7 Feb 2013 14:02:43 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r17M0AWf002223; Thu, 7 Feb 2013 17:00:10 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302072200.r17M0AWf002223@gateway1.orleans.occnc.com> To: Balaji venkat Venkataswami From: Curtis Villamizar Subject: Re: Power aware networks : Comments requested from routing community In-reply-to: Your message of "Thu, 07 Feb 2013 22:04:07 +0530." Date: Thu, 07 Feb 2013 17:00:10 -0500 Cc: Shankar Raman , "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, 07 Feb 2013 22:02:44 -0000 Balaji, If TCAM is your best example, you are not making a convincing argument. See the prior response. Curtis In message Balaji venkat Venkataswami writes: > Dear Eric, > > You had written... > > If yes... > - please provide concrete examples of how this actually works. In my > experience the power draw by a router or switch is pretty constant, more > driven by the *existence* of links (because links -> linecards -> power > draw) than by the *traffic* on those links. > > If not, what do you hope to accomplish by avoiding higher-power nodes? > > Our answer to the above question is this. We are rephrasing > the question as "Can you send more traffic through low power consuming > nodes ?". Therefore If yes does not come into the picture. > > The end objective slowly the traffic will migrate to the low power nodes > and the high power consuming nodes can be dismantled. > > The other mail for TCAM that I had sent will deal with answer to your > problem. > > > thanks and regards, > balaji venkat > > On Thu, Feb 7, 2013 at 9:52 PM, Balaji venkat Venkataswami < > balajivenkat299@gmail.com> wrote: > > > Dear Eric, > > > > Please take a look at the tcam-efficiency draft that we have published. > > > > The URL to the draft is > > http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-efficiency-00 > > > > A follow up draft that defines TCAM efficiency in terms of a metric is > > also outlined in... > > > > http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-ratio-02 > > > > With the help of the above schemes and additional work that is in progress > > we intend to reduce the > > power footprint of a device/router/switch/chassis such that important > > power guzzling components of > > the router are optimized. > > > > In summary, the above 2 drafts coupled with the protocol schemes will we > > feel result in better power > > saving than what we have today. So essentially optimizing the power > > consumed within a device > > coupled with using protocol schemes between devices will result in saving > > power. > > > > Hope this helps. > > > > thanks and regards, > > balaji venkat > > > > On Thu, Feb 7, 2013 at 9:38 PM, Eric Osborne (eosborne) < > > eosborne@cisco.com> wrote: > > > >> [size trimmed] > >> > >> OK, so you want to avoid nodes which draw more power. > >> Are you assuming that minimizing the traffic across a node also minimizes > >> the power that node draws? > >> > >> If yes: > >> - please provide concrete examples of how this actually works. In my > >> experience the power draw by a router or switch is pretty constant, more > >> driven by the *existence* of links (because links -> linecards -> power > >> draw) than by the *traffic* on those links. > >> > >> If not, what do you hope to accomplish by avoiding higher-power nodes? > >> > >> > >> > >> > >> eric > >> > >> > -----Original Message----- > >> > From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com] > >> > Sent: Thursday, February 07, 2013 10:59 AM > >> > To: Eric Osborne (eosborne) > >> > Cc: Shankar Raman; curtis@occnc.com; rtgwg@ietf.org > >> > Subject: Re: Power aware networks : Comments requested from routing > >> > community > >> > > >> > Dear Eric, > >> > > >> > We seem to be discussing at cross purposes. > >> > > >> > The root of our position is not what you have stated. We do not say if > >> you dont > >> > use a link you consume less power. We are not for avoiding links but we > >> are for > >> > avoiding nodes/routers/switches which have a large power footprint. The > >> > essence of using link metrics is to avoid nodes with larger power > >> footprints. > >> > That is how SPF or CSPF works. When it computes a low power path it > >> avoids > >> > nodes and also links that lead to that node which has a larger power > >> footprint. > >> > So the premise that we are just avoiding links is WRONG. > >> > > >> > For #1 question, we dont even talk about the power the link draws. We > >> talk > >> > about the power footprint of the node that it is connected to. > >> > > >> > For #2 question, again we state that your premise of avoiding links in > >> your > >> > example is a non-starter for us. > >> > > >> > thanks and regards, > >> > balaji venkat From curtis@occnc.com Thu Feb 7 14:46:36 2013 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 E23571F0D04 for ; Thu, 7 Feb 2013 14:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 621+0MghTITx for ; Thu, 7 Feb 2013 14:46:35 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id BC3991F0CFF for ; Thu, 7 Feb 2013 14:46:35 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r17Mi3Og002450; Thu, 7 Feb 2013 17:44:03 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302072244.r17Mi3Og002450@gateway1.orleans.occnc.com> To: Alia Atlas From: Curtis Villamizar Subject: Re: Power aware networks : Comments requested from routing community In-reply-to: Your message of "Thu, 07 Feb 2013 11:22:15 EST." Date: Thu, 07 Feb 2013 17:44:03 -0500 Cc: Shankar Raman M J , 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, 07 Feb 2013 22:46:37 -0000 In message Alia Atlas writes: > > There are two different aspects to power-aware routing that I think > are of interest. The first is developing a framework and method for > evaluating different possible solutions. We had a discussion of > draft-retana-rtgwg-eacp-00 in RTGWG in July 2012. Can you point to any message on the RTGWG mailing list? I searched locally for draft-retana-rtgwg-eacp and found none except a few related to meeting agenda scheduling. draft-retana-rtgwg-eacp is a 00 individual draft that has expired. I just looked at this for the first time and I'm not at all convinced that it is useful. IMO this is not a useful framework and also proposes techniques that are unlikely to have much if any impact (such as Section 5.4. Introducing Jitter Through Microsleeps and Section 5.4.1. An Example of Microsleeps to Reduce Energy Usage. > The second is examining and considering control plane and routing > solutions in that context. That seems to me to be more likely > something for the IRTF, rather than the IETF. > > The former, however, is where I think that the IETF's operational > knowledge and experience could be useful in framing what would be a > useful solution. > > Would it be possible to discuss this work that Balaji is presenting in > that context? In other words, if the goal of the solution is X,Y, and > Z, then this mechanism seems useful/ not useful, has stability > concerns, etc. > > And then there are the questions about assumptions and goals... All > of this is great to discuss in RTGWG - there's been significant > interest, but what is mature enough for the IETF vs. the IRTF and > whether there are sufficient people to work in the area is not clear. > > Alia If we did have a useful requirements or framework, then it might be useful to evaluate some new approach against it, but IMO we don't. I don't think this is even material ready for IRTF consideration, but that is up to Tony and IRTF to decide. Curtis > On Thu, Feb 7, 2013 at 11:09 AM, Tony Li wrote: > > > > > On Feb 7, 2013, at 5:07 AM, Hannes Gredler wrote: > > > > > Do you think that optimizing a part of the network which gives only > > limited > > > overall savings is a worthwhile goal ? > > > > > > Hannes, > > > > I'll just point out that this argument that you and Eric are espousing is > > skirting dangerously close to the quagmire of business. And we know from > > long experience that the IETF does not do business models. > > > > I'd like to strongly suggest that we simply restrict ourselves to the goal > > of saving power. I think that we can agree, in general, that saving power > > is a worthwhile goal. As to whether or not it is significant or makes > > economic sense is very much an issue that should be left to the operator > > community to decide. Limited overall savings may be worthwhile in one > > context and pointless in another. > > > > I know of one country where they are purportedly mandating power > > reductions. In such situations, saving that last watt is the difference > > between a fine and not. On the other hand, in a situation where power is > > very cheap, it's obviously silly. > > > > Let's not argue about the marginal value of energy. That's a business > > model issue. Let's talk about how technology can actually save power. > > > > Regards, > > Tony > > > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg From tony.li@tony.li Thu Feb 7 15:04:23 2013 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 9C22411E80A2 for ; Thu, 7 Feb 2013 15:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhAsROfPWwYE for ; Thu, 7 Feb 2013 15:04:23 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 27A8311E809C for ; Thu, 7 Feb 2013 15:04:23 -0800 (PST) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta03.emeryville.ca.mail.comcast.net with comcast id xS8s1k0060x6nqcA3b4PN6; Thu, 07 Feb 2013 23:04:23 +0000 Received: from [10.66.230.195] ([64.236.139.254]) by omta12.emeryville.ca.mail.comcast.net with comcast id xb281k00F5VXD0o8Yb2Bpc; Thu, 07 Feb 2013 23:02:21 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Power aware networks : Comments requested from routing community From: Tony Li In-Reply-To: <201302072244.r17Mi3Og002450@gateway1.orleans.occnc.com> Date: Thu, 7 Feb 2013 15:02:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6B5386C5-F507-417F-94E8-0E4B6446FFA8@tony.li> References: <201302072244.r17Mi3Og002450@gateway1.orleans.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360278263; bh=8nrNbGl63+xps8YE14BpGywNDumjlul5Rl4M+oGuSxw=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=mwfytReXkYD0/B0gUBYomVNRc4bUHFaMFu2gHwhO8qGwHaIJWoWOrgEL3uGzxq1V6 s7+9mGUhTaaRBeoIY042/KlBblXHq5WUwTjXAEEq/d8KF0khuODRe7hxhO3nIDtJ6h ZtUSLGRMH3jmPBL+D4BLbCF8xo5lVCtZPIeT8VoXolB9+ZjwPZbKOeIbMruu8hGfcR ZbWE9rbYOBa/6u/RIsGt7vHPEf+L0FnLegFU9Wcq6itxShVuZ9gz5ou6kstD2CIPCV 0BaZwDLanosD5LDYMasbRxmnXoDT3vOb5sXjnbXF+XSbrxSw8GHuhuLRlvYhcwZDGJ zUKzFie9BJJwQ== Cc: Shankar Raman M J , 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, 07 Feb 2013 23:04:23 -0000 On Feb 7, 2013, at 2:44 PM, Curtis Villamizar wrote: > I don't think this is even material ready for IRTF consideration, but > that is up to Tony and IRTF to decide. As always, the IRTF does not require well-formed ideas as a = pre-requisite for starting work. Instead, there needs to be a clear = problem statement (i.e., a charter) and a sufficient group of serious = researchers who are committed to following through in a committed = manner. Note that it is, by definition, research. It is expected to have a = non-trivial likelihood of failure. Regards, Tony From zhangmingui@huawei.com Thu Feb 7 23:10:06 2013 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 0927121F89FC for ; Thu, 7 Feb 2013 23:10:06 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acNPYa2wY3PH for ; Thu, 7 Feb 2013 23:10:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DBE4421F89E5 for ; Thu, 7 Feb 2013 23:10:04 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APN66317; Fri, 08 Feb 2013 07:09:51 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 8 Feb 2013 07:08:51 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 8 Feb 2013 07:09:49 +0000 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.33]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Fri, 8 Feb 2013 15:09:38 +0800 From: Mingui Zhang To: Tony Li , "curtis@occnc.com" Subject: PANET side-meeting Thread-Topic: PANET side-meeting Thread-Index: AQHOBctBKuTqdHe8Bkmtrak3KqQ1Bw== Date: Fri, 8 Feb 2013 07:09:38 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E732AFF460@nkgeml508-mbx.china.huawei.com> References: <201302072244.r17Mi3Og002450@gateway1.orleans.occnc.com> <6B5386C5-F507-417F-94E8-0E4B6446FFA8@tony.li> In-Reply-To: <6B5386C5-F507-417F-94E8-0E4B6446FFA8@tony.li> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Susan Hares , "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: Fri, 08 Feb 2013 07:10:06 -0000 Hi Tony and Curtis, Let me retrospect some history to clear up the chaos floating around.=20 On Feb 4th, I organized a conference call among a dozen of guys (from opera= tors, vendors and Universities) who are interested in PANET, in order to pr= epare for a side meeting in IETF. There was a rough consensus that a side-m= eeting is a good way to call for interest, coordination and contribution to= PANET. However, requests was _prematurely_ sent out afterwards, without in= cluding all the effort from the conference attendees. I hope this email can= get us back on track. So I change its title. I believe the most efficient way for us is to play the game according to th= e rule of IETF/IRTF. Therefore, we are trying to find a place to accommodat= e the side-meeting. We should not delve into discussion of specific solutio= ns before we make clear the problem scope. A charter should be published, w= hich will help us figure out what is the problem we are trying to solve. Be= fore that, let me add some pointers of drafts from my side. I believe these= drafts can also help people to figure out the scope of PANET.=20 Power-Aware Networks (PANET): Problem Statement, https://datatracker.ietf.o= rg/doc/draft-zhang-panet-problem-statement/ Use Cases for Power-Aware Networks, https://datatracker.ietf.org/doc/draft-= zhang-panet-use-cases/ Requirements for Power Aware Network, https://datatracker.ietf.org/doc/draf= t-dong-panet-requirement/ On the 84th IETF rtgwg f2f meeting, there were two presentations relevant t= o greening. I also list them as follows FYI.=20 A Framework and Requirements for Energy Aware Control Planes, http://tools.= ietf.org/html/draft-retana-rtgwg-eacp-00, [slides] http://www.ietf.org/proc= eedings/84/slides/slides-84-rtgwg-3.pptx Power-aware Routing and Traffic Engineering: Requirements, Approaches, and = Issues, https://datatracker.ietf.org/doc/draft-zhang-greennet/, [slides] ht= tp://www.ietf.org/proceedings/84/slides/slides-84-rtgwg-4.pptx Thanks, Mingui Zhang Huawei Technologies >-----Original Message----- >From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of >Tony Li >Sent: Friday, February 08, 2013 7:02 AM >To: curtis@occnc.com >Cc: Shankar Raman M J; rtgwg@ietf.org >Subject: Re: Power aware networks : Comments requested from routing >community > > >On Feb 7, 2013, at 2:44 PM, Curtis Villamizar wrote: > >> I don't think this is even material ready for IRTF consideration, but >> that is up to Tony and IRTF to decide. > > >As always, the IRTF does not require well-formed ideas as a pre-requisite = for >starting work. Instead, there needs to be a clear problem statement (i.e.= , a >charter) and a sufficient group of serious researchers who are committed t= o >following through in a committed manner. > >Note that it is, by definition, research. It is expected to have a non-tr= ivial >likelihood of failure. > >Regards, >Tony > >_______________________________________________ >rtgwg mailing list >rtgwg@ietf.org >https://www.ietf.org/mailman/listinfo/rtgwg From zhangmingui@huawei.com Fri Feb 8 00:17:21 2013 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 DB72F21F88DB for ; Fri, 8 Feb 2013 00:17:21 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1raL8MqGipAi for ; Fri, 8 Feb 2013 00:17:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DF99821F87EE for ; Fri, 8 Feb 2013 00:17:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOG83267; Fri, 08 Feb 2013 08:17:08 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 8 Feb 2013 08:16:06 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 8 Feb 2013 08:17:05 +0000 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.33]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Fri, 8 Feb 2013 16:17:02 +0800 From: Mingui Zhang To: Thomas Nadeau Subject: GreenTE discussion Thread-Topic: GreenTE discussion Thread-Index: AQHOBdSrwqzZVgvQnUCRL7trd5Tp/g== Date: Fri, 8 Feb 2013 08:17:00 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E732AFF48D@nkgeml508-mbx.china.huawei.com> References: Your message of "Thu, 07 Feb 2013 00:22:54 +0530." <201302062005.r16K5CQS084848@gateway1.orleans.occnc.com> <4552F0907735844E9204A62BBDD325E732AFF1A1@nkgeml508-mbx.china.huawei.com> <26C6E21E-8E5E-4E6F-83CA-22DA542F6BEF@lucidvision.com> In-Reply-To: <26C6E21E-8E5E-4E6F-83CA-22DA542F6BEF@lucidvision.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Bmlx CF4y CG0G CrND HQz0 J7A8 Kv5Y LPck PImA Qvpk TWnF aCir dBdQ d0Hd iW7S kySs; 3; YwB1AHIAdABpAHMAQABvAGMAYwBuAGMALgBjAG8AbQA7AHIAdABnAHcAZwBAAGkAZQB0AGYALgBvAHIAZwA7AHQAbgBhAGQAZQBhAHUAQABsAHUAYwBpAGQAdgBpAHMAaQBvAG4ALgBjAG8AbQA=; Sosha1_v1; 7; {31E60ADD-B508-4B8C-8CDC-EEC011A02665}; egBoAGEAbgBnAG0AaQBuAGcAdQBpAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Fri, 08 Feb 2013 08:16:51 GMT; RwByAGUAZQBuAFQARQAgAGQAaQBzAGMAdQBzAHMAaQBvAG4A x-cr-puzzleid: {31E60ADD-B508-4B8C-8CDC-EEC011A02665} x-originating-ip: [10.111.102.175] 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: Fri, 08 Feb 2013 08:17:22 -0000 Hi Thomas, > The problem with the model is that it makes assumptions that just do not >reflect the reality of much of the equipment that is deployed today. For i= nstance, >while there is a lot of power used in the line card optics, the idle power= supply >capacity is another giant waste of power. This cannot be mitigated without >shutting down the entire device. Further considerations need to be made >around the back-up facility power as well, which while not directly influe= nced by >network traffic, does influence overall power utilization. Yes, network traffic does not directly influence the power consumption of s= ome facilities such as air conditioners. Then energy conservation for these= facilities is clearly out the scope of GreenTE (or PANET). It may as well = be out of the scope of IETF. We focus on how to coordinate network devices through the control/managemen= t plane _protocols_ to achieve energy conservation. That's the problem scop= e. > Yes, but if the equipment is already very power efficient, the law of >diminishing returns (or unexpected consequences) may dominate the equation= . I know, they are most power efficient when packets get through at their pea= k rate. But, when they are idle (i.e., no packets are being forwarded), the= power efficient is awkwardly very low. Line-cards can consume 80% of the M= AX power even when they do not forward any packet. So, power efficient of a single device does not lead to power efficient of = whole network, right? Thanks, Mingui Zhang Huawei Technologies From hannes@juniper.net Fri Feb 8 00:30:03 2013 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 B03AA21F859C for ; Fri, 8 Feb 2013 00:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulN1wMA7mKev for ; Fri, 8 Feb 2013 00:30:03 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBFA21F8460 for ; Fri, 8 Feb 2013 00:30:03 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKURS3ijCE4YI35cE3xhl6vfvL88QUtJXl@postini.com; Fri, 08 Feb 2013 00:30:03 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 8 Feb 2013 00:25:27 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 8 Feb 2013 00:25:26 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 8 Feb 2013 00:34:14 -0800 Received: from mail199-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Feb 2013 08:25:25 +0000 Received: from mail199-ch1 (localhost [127.0.0.1]) by mail199-ch1-R.bigfish.com (Postfix) with ESMTP id 564DD34040E for ; Fri, 8 Feb 2013 08:25:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); (null); H:BLUPRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -4 X-BigFish: PS-4(zz98dI9371I1432I1418Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275chz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1155h) Received: from mail199-ch1 (localhost.localdomain [127.0.0.1]) by mail199-ch1 (MessageSwitch) id 1360311923529467_4041; Fri, 8 Feb 2013 08:25:23 +0000 (UTC) Received: from CH1EHSMHS031.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail199-ch1.bigfish.com (Postfix) with ESMTP id 75114460055; Fri, 8 Feb 2013 08:25:23 +0000 (UTC) Received: from BLUPRD0512HT001.namprd05.prod.outlook.com (132.245.1.149) by CH1EHSMHS031.bigfish.com (10.43.70.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Feb 2013 08:25:22 +0000 Received: from [172.23.7.85] (66.129.224.36) by pod51010.outlook.com (10.255.215.162) with Microsoft SMTP Server (TLS) id 14.16.263.1; Fri, 8 Feb 2013 08:25:22 +0000 Subject: Re: Power aware networks : Comments requested from routing community MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: <021A2E07-50AF-443C-AC4A-E61A28D57F6F@tony.li> Date: Fri, 8 Feb 2013 09:25:14 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: <534A746F-66FE-49F2-86FA-20CCED1487CE@juniper.net> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <72B40FF5-6A29-4857-93AA-768490A20903@juniper.net> <021A2E07-50AF-443C-AC4A-E61A28D57F6F@tony.li> To: Tony Li X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TONY.LI$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Shankar Raman M J , 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: Fri, 08 Feb 2013 08:30:03 -0000 tony, agree that saving power is a worthwhile goal; in fact existing hardware technology is making that happen today by e.g. automatically shutting down unused lookup engines, CPU cores, = memory banks etc. when there is low processing demand. the part where i am not yet convinced is that additional off-peak = "optimization" of infrastructure links by e.g. computing a routing mesh which only uses 70% of the nominal links does actually give much power savings. note that line cards which are running at 70% have already throttled = down their power consumption - so what is the point emptying the link and loading = another ? appears to me a zero sum game. my concern about the core (and SP edge) is not about business or = technology - it is more about if we try to optimize an already optimized (and solved) = problem. /hannes On Feb 7, 2013, at 5:09 PM, Tony Li wrote: >=20 > On Feb 7, 2013, at 5:07 AM, Hannes Gredler wrote: >=20 >> Do you think that optimizing a part of the network which gives only = limited >> overall savings is a worthwhile goal ?=20 >=20 >=20 > Hannes,=20 >=20 > I'll just point out that this argument that you and Eric are espousing = is skirting dangerously close to the quagmire of business. And we know = from long experience that the IETF does not do business models. >=20 > I'd like to strongly suggest that we simply restrict ourselves to the = goal of saving power. I think that we can agree, in general, that = saving power is a worthwhile goal. As to whether or not it is = significant or makes economic sense is very much an issue that should be = left to the operator community to decide. Limited overall savings may = be worthwhile in one context and pointless in another. >=20 > I know of one country where they are purportedly mandating power = reductions. In such situations, saving that last watt is the difference = between a fine and not. On the other hand, in a situation where power = is very cheap, it's obviously silly. >=20 > Let's not argue about the marginal value of energy. That's a business = model issue. Let's talk about how technology can actually save power. >=20 > Regards, > Tony >=20 >=20 From tony.li@tony.li Fri Feb 8 00:48:05 2013 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 7D19021F84D5 for ; Fri, 8 Feb 2013 00:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.304 X-Spam-Level: X-Spam-Status: No, score=-100.304 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoyGg0n9OS+e for ; Fri, 8 Feb 2013 00:48:04 -0800 (PST) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEA821F84C6 for ; Fri, 8 Feb 2013 00:48:04 -0800 (PST) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta07.emeryville.ca.mail.comcast.net with comcast id xko41k00117UAYkA7ko4Ro; Fri, 08 Feb 2013 08:48:04 +0000 Received: from [192.168.2.111] ([98.248.36.188]) by omta13.emeryville.ca.mail.comcast.net with comcast id xko21k00B43ZcXW8Zko3bP; Fri, 08 Feb 2013 08:48:03 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Power aware networks : Comments requested from routing community From: Tony Li In-Reply-To: <534A746F-66FE-49F2-86FA-20CCED1487CE@juniper.net> Date: Fri, 8 Feb 2013 00:48:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8F1F25B1-F519-4D13-82CA-583597F7AE7B@tony.li> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <72B40FF5-6A29-4857-93AA-768490A20903@juniper.net> <021A2E07-50AF-443C-AC4A-E61A28D57F6F@tony.li> <534A746F-66FE-49F2-86FA-20CCED1487CE@juniper.net> To: Hannes Gredler X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360313284; bh=HCMPSqHjL/Frn7RqgcdqxSFTJ8JIdvF9A4YVa2Kmqbs=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=EEGbg60d7dE72nkDwRlUJqGHXdLM/GzPA619DJhvHa+plXEOYM1FBgZDmHBGtwRZZ a8+b4/mHSg5bkONEa7U/fjiHECmStlrIheTE8C6gT2T35CVJ7KfOaYUYvKOBCqmfQj n+29sYpUv+WlnMuki7ZwLjnPbFR7KR5gMsUJfTcwBdePuzypUatgbeS9GqmJO+3ehs naJVjmxS2BgOt7KqjTS/nrabwdU1DRbYdjWuW3EJAZlJjg87IPzUEdtADg5QoZtjC/ y0UMdUtyQPTruiD2iu3vqqyta9KkTPN+NaXSJ24qfbzwMcOa7FPjLM9N6y5HYmAMA5 gSJTMc0wEjJKw== Cc: Shankar Raman M J , 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: Fri, 08 Feb 2013 08:48:05 -0000 On Feb 8, 2013, at 12:25 AM, Hannes Gredler wrote: > tony, >=20 > agree that saving power is a worthwhile goal; >=20 > in fact existing hardware technology is making that happen today by > e.g. automatically shutting down unused lookup engines, CPU cores, = memory banks etc. > when there is low processing demand. >=20 > the part where i am not yet convinced is that additional off-peak = "optimization" of > infrastructure links by e.g. computing a routing mesh which only uses > 70% of the nominal links does actually give much power savings. >=20 > note that line cards which are running at 70% have already throttled = down their > power consumption - so what is the point emptying the link and loading = another ? > appears to me a zero sum game. >=20 > my concern about the core (and SP edge) is not about business or = technology - > it is more about if we try to optimize an already optimized (and = solved) problem. If there are no more optimizations to be had, then talking about it = isn't going to hurt anything. =20 The point of emptying links is the ability to turn off NPUs (50-100W = ea.), turn off edge optics (2-20W ea.) and most importantly turn off = long-haul optics (100-400W ea.). Yes, I realize that the latter part is = really problematic because DWDM systems are balanced with all lambdas = active, and that disabling any one of them can cause issues with other = lambdas. =20 Still, it would be nice to understand what CAN be done, if only to feel = like we've truly explored every corner in the solution space and = exhausted every option. Tony From zhangmingui@huawei.com Fri Feb 8 00:53:46 2013 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 B127721F8765 for ; Fri, 8 Feb 2013 00:53:46 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id komZXqITCghf for ; Fri, 8 Feb 2013 00:53:45 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 18F5021F874F for ; Fri, 8 Feb 2013 00:53:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APN73713; Fri, 08 Feb 2013 08:53:44 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 8 Feb 2013 08:52:41 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 8 Feb 2013 08:53:41 +0000 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.33]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Fri, 8 Feb 2013 16:53:33 +0800 From: Mingui Zhang To: Hannes Gredler , Tony Li Subject: RE: Power aware networks : Comments requested from routing community Thread-Topic: Power aware networks : Comments requested from routing community Thread-Index: AQHOBJmIPsIuGU7T7kWvRcj+FvsyIZht2OUAgAAytACAARC6AIAAiq1w Date: Fri, 8 Feb 2013 08:53:32 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E732AFF5B1@nkgeml508-mbx.china.huawei.com> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <72B40FF5-6A29-4857-93AA-768490A20903@juniper.net> <021A2E07-50AF-443C-AC4A-E61A28D57F6F@tony.li> <534A746F-66FE-49F2-86FA-20CCED1487CE@juniper.net> In-Reply-To: <534A746F-66FE-49F2-86FA-20CCED1487CE@juniper.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Shankar Raman M J , "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: Fri, 08 Feb 2013 08:53:46 -0000 Hi Hannes, "Optimization" tries to empty all links on one line-card with priority, the= n this line card can be shut off to save the high baseline power. Thanks, Mingui Zhang Huawei Technologies >-----Original Message----- >From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of >Hannes Gredler >Sent: Friday, February 08, 2013 4:25 PM >To: Tony Li >Cc: Shankar Raman M J; rtgwg@ietf.org >Subject: Re: Power aware networks : Comments requested from routing >community > >tony, > >agree that saving power is a worthwhile goal; > >in fact existing hardware technology is making that happen today by >e.g. automatically shutting down unused lookup engines, CPU cores, memory >banks etc. >when there is low processing demand. > >the part where i am not yet convinced is that additional off-peak "optimiz= ation" >of >infrastructure links by e.g. computing a routing mesh which only uses >70% of the nominal links does actually give much power savings. > >note that line cards which are running at 70% have already throttled down = their >power consumption - so what is the point emptying the link and loading >another ? >appears to me a zero sum game. > >my concern about the core (and SP edge) is not about business or technolog= y - >it is more about if we try to optimize an already optimized (and solved) p= roblem. > >/hannes > >On Feb 7, 2013, at 5:09 PM, Tony Li wrote: > >> >> On Feb 7, 2013, at 5:07 AM, Hannes Gredler wrote: >> >>> Do you think that optimizing a part of the network which gives only lim= ited >>> overall savings is a worthwhile goal ? >> >> >> Hannes, >> >> I'll just point out that this argument that you and Eric are espousing i= s skirting >dangerously close to the quagmire of business. And we know from long >experience that the IETF does not do business models. >> >> I'd like to strongly suggest that we simply restrict ourselves to the go= al of >saving power. I think that we can agree, in general, that saving power is= a >worthwhile goal. As to whether or not it is significant or makes economic >sense is very much an issue that should be left to the operator community = to >decide. Limited overall savings may be worthwhile in one context and poin= tless >in another. >> >> I know of one country where they are purportedly mandating power reducti= ons. >In such situations, saving that last watt is the difference between a fine= and not. >On the other hand, in a situation where power is very cheap, it's obviousl= y silly. >> >> Let's not argue about the marginal value of energy. That's a business m= odel >issue. Let's talk about how technology can actually save power. >> >> Regards, >> Tony >> >> > > >_______________________________________________ >rtgwg mailing list >rtgwg@ietf.org >https://www.ietf.org/mailman/listinfo/rtgwg From hannes@juniper.net Fri Feb 8 01:21:55 2013 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 B9B7E21F8765 for ; Fri, 8 Feb 2013 01:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLkcYl-9nd+v for ; Fri, 8 Feb 2013 01:21:52 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 63F8F21F86F7 for ; Fri, 8 Feb 2013 01:21:50 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKURTDrZbjaIFm8qhpZ2i+6VOcUOSJLkMK@postini.com; Fri, 08 Feb 2013 01:21:52 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 8 Feb 2013 01:17:30 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 8 Feb 2013 01:17:29 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.16) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 8 Feb 2013 01:19:24 -0800 Received: from mail255-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Feb 2013 09:17:28 +0000 Received: from mail255-va3 (localhost [127.0.0.1]) by mail255-va3-R.bigfish.com (Postfix) with ESMTP id AE63C190043A for ; Fri, 8 Feb 2013 09:17:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); (null); H:BL2PRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -26 X-BigFish: PS-26(zz98dI9371I542I1432I1418I4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL8275dhz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1155h) Received: from mail255-va3 (localhost.localdomain [127.0.0.1]) by mail255-va3 (MessageSwitch) id 1360315044404587_16570; Fri, 8 Feb 2013 09:17:24 +0000 (UTC) Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.238]) by mail255-va3.bigfish.com (Postfix) with ESMTP id 5FBD2198004C; Fri, 8 Feb 2013 09:17:24 +0000 (UTC) Received: from BL2PRD0512HT002.namprd05.prod.outlook.com (157.56.242.197) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Feb 2013 09:17:23 +0000 Received: from [172.23.7.85] (66.129.224.54) by pod51010.outlook.com (10.255.233.35) with Microsoft SMTP Server (TLS) id 14.16.263.1; Fri, 8 Feb 2013 09:17:22 +0000 Subject: Re: Power aware networks : Comments requested from routing community MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: <4552F0907735844E9204A62BBDD325E732AFF5B1@nkgeml508-mbx.china.huawei.com> Date: Fri, 8 Feb 2013 10:17:16 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: <2ACD61D8-783A-404D-BB60-02E83FABDE3B@juniper.net> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <72B40FF5-6A29-4857-93AA-768490A20903@juniper.net> <021A2E07-50AF-443C-AC4A-E61A28D57F6F@tony.li> <534A746F-66FE-49F2-86FA-20CCED1487CE@juniper.net> <4552F0907735844E9204A62BBDD325E732AFF5B1@nkgeml508-mbx.china.huawei.com> To: Mingui Zhang X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.54] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TONY.LI$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Shankar Raman M J , "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: Fri, 08 Feb 2013 09:21:55 -0000 mingui, wouldn't designing the hardware architecture such that there is no high baseline rather than a more demand based power draw curve be the better alternative then ? only box local changes needed, immediate returns, no need to bother the network with the fact that the local box cannot do the power housekeeping well ? /hannes On Feb 8, 2013, at 9:53 AM, Mingui Zhang wrote: > Hi Hannes, >=20 > "Optimization" tries to empty all links on one line-card with = priority, then this line card can be shut off to save the high baseline = power. >=20 > Thanks, > Mingui Zhang > Huawei Technologies >=20 >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On = Behalf Of >> Hannes Gredler >> Sent: Friday, February 08, 2013 4:25 PM >> To: Tony Li >> Cc: Shankar Raman M J; rtgwg@ietf.org >> Subject: Re: Power aware networks : Comments requested from routing >> community >>=20 >> tony, >>=20 >> agree that saving power is a worthwhile goal; >>=20 >> in fact existing hardware technology is making that happen today by >> e.g. automatically shutting down unused lookup engines, CPU cores, = memory >> banks etc. >> when there is low processing demand. >>=20 >> the part where i am not yet convinced is that additional off-peak = "optimization" >> of >> infrastructure links by e.g. computing a routing mesh which only uses >> 70% of the nominal links does actually give much power savings. >>=20 >> note that line cards which are running at 70% have already throttled = down their >> power consumption - so what is the point emptying the link and = loading >> another ? >> appears to me a zero sum game. >>=20 >> my concern about the core (and SP edge) is not about business or = technology - >> it is more about if we try to optimize an already optimized (and = solved) problem. >>=20 >> /hannes >>=20 >> On Feb 7, 2013, at 5:09 PM, Tony Li wrote: >>=20 >>>=20 >>> On Feb 7, 2013, at 5:07 AM, Hannes Gredler = wrote: >>>=20 >>>> Do you think that optimizing a part of the network which gives only = limited >>>> overall savings is a worthwhile goal ? >>>=20 >>>=20 >>> Hannes, >>>=20 >>> I'll just point out that this argument that you and Eric are = espousing is skirting >> dangerously close to the quagmire of business. And we know from long >> experience that the IETF does not do business models. >>>=20 >>> I'd like to strongly suggest that we simply restrict ourselves to = the goal of >> saving power. I think that we can agree, in general, that saving = power is a >> worthwhile goal. As to whether or not it is significant or makes = economic >> sense is very much an issue that should be left to the operator = community to >> decide. Limited overall savings may be worthwhile in one context and = pointless >> in another. >>>=20 >>> I know of one country where they are purportedly mandating power = reductions. >> In such situations, saving that last watt is the difference between a = fine and not. >> On the other hand, in a situation where power is very cheap, it's = obviously silly. >>>=20 >>> Let's not argue about the marginal value of energy. That's a = business model >> issue. Let's talk about how technology can actually save power. >>>=20 >>> Regards, >>> Tony >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg >=20 From zhangmingui@huawei.com Fri Feb 8 01:33:21 2013 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 77DAD21F84D5 for ; Fri, 8 Feb 2013 01:33:21 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLqpgrjQoEDG for ; Fri, 8 Feb 2013 01:33:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 357B821F84C6 for ; Fri, 8 Feb 2013 01:33:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOG89679; Fri, 08 Feb 2013 09:33:19 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 8 Feb 2013 09:33:13 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 8 Feb 2013 17:33:18 +0800 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.33]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Fri, 8 Feb 2013 17:33:14 +0800 From: Mingui Zhang To: Hannes Gredler Subject: RE: Power aware networks : Comments requested from routing community Thread-Topic: Power aware networks : Comments requested from routing community Thread-Index: AQHOBJmIPsIuGU7T7kWvRcj+FvsyIZht2OUAgAAytACAARC6AIAAiq1w//+D3QCAAIf0EA== Date: Fri, 8 Feb 2013 09:33:13 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E732AFF5D5@nkgeml508-mbx.china.huawei.com> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <72B40FF5-6A29-4857-93AA-768490A20903@juniper.net> <021A2E07-50AF-443C-AC4A-E61A28D57F6F@tony.li> <534A746F-66FE-49F2-86FA-20CCED1487CE@juniper.net> <4552F0907735844E9204A62BBDD325E732AFF5B1@nkgeml508-mbx.china.huawei.com> <2ACD61D8-783A-404D-BB60-02E83FABDE3B@juniper.net> In-Reply-To: <2ACD61D8-783A-404D-BB60-02E83FABDE3B@juniper.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Shankar Raman M J , "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: Fri, 08 Feb 2013 09:33:21 -0000 Hannes, That's the dream of line-card hardware manufactures. If the hardware is 100= % power proportional, then PANET will become useless. However, the practice is that only 10%-15% power proportional is possible, = which means a high 85%-90% of baseline power is being wasted when there is = few traffic. Thanks, Mingui >-----Original Message----- >From: Hannes Gredler [mailto:hannes@juniper.net] >Sent: Friday, February 08, 2013 5:17 PM >To: Mingui Zhang >Cc: Tony Li; Shankar Raman M J; rtgwg@ietf.org >Subject: Re: Power aware networks : Comments requested from routing >community > >mingui, > >wouldn't designing the hardware architecture such that there is >no high baseline rather than a more demand based >power draw curve be the better alternative then ? > >only box local changes needed, immediate returns, >no need to bother the network with the fact that the local >box cannot do the power housekeeping well ? > >/hannes > >On Feb 8, 2013, at 9:53 AM, Mingui Zhang wrote: > >> Hi Hannes, >> >> "Optimization" tries to empty all links on one line-card with priority, = then this >line card can be shut off to save the high baseline power. >> >> Thanks, >> Mingui Zhang >> Huawei Technologies >> >>> -----Original Message----- >>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf >Of >>> Hannes Gredler >>> Sent: Friday, February 08, 2013 4:25 PM >>> To: Tony Li >>> Cc: Shankar Raman M J; rtgwg@ietf.org >>> Subject: Re: Power aware networks : Comments requested from routing >>> community >>> >>> tony, >>> >>> agree that saving power is a worthwhile goal; >>> >>> in fact existing hardware technology is making that happen today by >>> e.g. automatically shutting down unused lookup engines, CPU cores, memo= ry >>> banks etc. >>> when there is low processing demand. >>> >>> the part where i am not yet convinced is that additional off-peak >"optimization" >>> of >>> infrastructure links by e.g. computing a routing mesh which only uses >>> 70% of the nominal links does actually give much power savings. >>> >>> note that line cards which are running at 70% have already throttled do= wn >their >>> power consumption - so what is the point emptying the link and loading >>> another ? >>> appears to me a zero sum game. >>> >>> my concern about the core (and SP edge) is not about business or techno= logy >- >>> it is more about if we try to optimize an already optimized (and solved= ) >problem. >>> >>> /hannes >>> >>> On Feb 7, 2013, at 5:09 PM, Tony Li wrote: >>> >>>> >>>> On Feb 7, 2013, at 5:07 AM, Hannes Gredler wrote: >>>> >>>>> Do you think that optimizing a part of the network which gives only l= imited >>>>> overall savings is a worthwhile goal ? >>>> >>>> >>>> Hannes, >>>> >>>> I'll just point out that this argument that you and Eric are espousing= is >skirting >>> dangerously close to the quagmire of business. And we know from long >>> experience that the IETF does not do business models. >>>> >>>> I'd like to strongly suggest that we simply restrict ourselves to the = goal of >>> saving power. I think that we can agree, in general, that saving power= is a >>> worthwhile goal. As to whether or not it is significant or makes econo= mic >>> sense is very much an issue that should be left to the operator communi= ty to >>> decide. Limited overall savings may be worthwhile in one context and >pointless >>> in another. >>>> >>>> I know of one country where they are purportedly mandating power >reductions. >>> In such situations, saving that last watt is the difference between a f= ine and >not. >>> On the other hand, in a situation where power is very cheap, it's obvio= usly >silly. >>>> >>>> Let's not argue about the marginal value of energy. That's a business >model >>> issue. Let's talk about how technology can actually save power. >>>> >>>> Regards, >>>> Tony >>>> >>>> >>> >>> >>> _______________________________________________ >>> rtgwg mailing list >>> rtgwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtgwg >> > From balajivenkat299@gmail.com Fri Feb 8 03:56:12 2013 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 9B0C821F8814 for ; Fri, 8 Feb 2013 03:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DVyW5uCcQGH for ; Fri, 8 Feb 2013 03:56:11 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id 82E5E21F86C3 for ; Fri, 8 Feb 2013 03:56:11 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id va7so3813597obc.13 for ; Fri, 08 Feb 2013 03:56:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Ds2DbLxSZL7aXHwewS1bT+VAeIRhuhQvNQr1j8WC0Ns=; b=IjbTcx1kON6Vk1sb6Bdvk1pLeaZDXvi/H3XoU/Syas40GAmFR+dbX4Rqt1jceezNp6 3NRamPN5aiVXZrI6zUxOZUfOJi9XKFJn2exqry6YtpYLM4SIUgAA05KMeAgfBI4o3oB4 jS+PrB6pT+cyfTr+ED1cXLpjhm5sjuvYhvlEgBPFfDN3UNPl3WCAOhCfGPXCATKqqhde tRu9+QkgdZl2vHUWFW5u8IwOtEswp5+p5fw78SCBRYyk2dL2B6PUHnOH3N5L75qaGo1Q aCVsbeZLQk4hcsus+6ufcjoZVg+Fe8o5MmWZH15ytzENAyeGmBo9VECU5saPUcuHDbYH hJZw== MIME-Version: 1.0 X-Received: by 10.60.8.199 with SMTP id t7mr3754823oea.26.1360324570920; Fri, 08 Feb 2013 03:56:10 -0800 (PST) Received: by 10.60.93.8 with HTTP; Fri, 8 Feb 2013 03:56:10 -0800 (PST) In-Reply-To: <201302072157.r17LvxFl002170@gateway1.orleans.occnc.com> References: <201302072157.r17LvxFl002170@gateway1.orleans.occnc.com> Date: Fri, 8 Feb 2013 17:26:10 +0530 Message-ID: Subject: Re: Power aware networks : Comments requested from routing community From: Balaji venkat Venkataswami To: curtis@occnc.com Content-Type: multipart/alternative; boundary=e89a8ff1ce46d436bb04d5353e17 Cc: Shankar Raman , "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: Fri, 08 Feb 2013 11:56:12 -0000 --e89a8ff1ce46d436bb04d5353e17 Content-Type: text/plain; charset=ISO-8859-1 Dear Curtis, Comments inline.... On Fri, Feb 8, 2013 at 3:27 AM, Curtis Villamizar wrote: > > In message < > CAHF4apOGL40a3owkjznvOafN7u6cL06vt0rU8vRuNiWPUH9v2A@mail.gmail.com> > Balaji venkat Venkataswami writes: > > > Dear Eric, > > > > Please take a look at the tcam-efficiency draft that we have published. > > > > The URL to the draft is > > http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-efficiency-00 > > > > A follow up draft that defines TCAM efficiency in terms of a metric is > > also outlined in... > > > > http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-ratio-02 > > > > With the help of the above schemes and additional work that is in > > progress we intend to reduce the power footprint of a > > device/router/switch/chassis such that important power guzzling > > components of the router are optimized. > > > > In summary, the above 2 drafts coupled with the protocol schemes will > > we feel result in better power saving than what we have today. So > > essentially optimizing the power consumed within a device coupled with > > using protocol schemes between devices will result in saving power. > > > > Hope this helps. > > > > thanks and regards, > > balaji venkat > > > balaji, > > This is in the realm of router design. > Most modern commercial chipsets provide the capability of switching off TCAM banks. TCAMs nowadays come in the form factor of multiple banks that can be switched off and switched on with register operations. I wouldnt say that this is uncommon. This algorithm we suggest falls within the realm of software design where the software is responsible for managing multiple TCAM banks of suitable granularity. Its because such chips are available that these algorithms are feasible today. > > You are suggesting a TCAM in which banks can be shut off by reducing > the number of destination addresses in the FIB. > > A better solution to reduce the power consumed by TCAM is don't use a > TCAM. It is fast, but a radix trie based approach or other tree > Most vendors and commercial chipsets manufactured use TCAMs for the Longest prefix match lookup. Fast is good so TCAMs are in widespread use. Radix trees too could be used. But then again we could optimize the SRAM they use by applying similar approaches to reducing the radix tree to hold only routes that are in use. So it is the general philosophy that is of importance and does not hinge on usage of TCAMs in routers. > approach consumes less power and pipelining makes such an approach > feasible if the lookup memory can be kept on-chip. MPLS lookup can be > easily done in on chip SRAM rather than TCAM consuming mush less power > than an on-chip TCAM and a fraction of the power of off chip TCAM due > to the SERDES power needed to go off chip. > > This pair of drafts in particular should be dropped. > Hence we think this work is of importance in the current context. This is currently work in progress. thanks and regards, balaji venkat > > Curtis > > > > On Thu, Feb 7, 2013 at 9:38 PM, Eric Osborne (eosborne) > > wrote: > > > > > [size trimmed] > > > > > > OK, so you want to avoid nodes which draw more power. > > > Are you assuming that minimizing the traffic across a node also > minimizes > > > the power that node draws? > > > > > > If yes: > > > - please provide concrete examples of how this actually works. In my > > > experience the power draw by a router or switch is pretty constant, > more > > > driven by the *existence* of links (because links -> linecards -> power > > > draw) than by the *traffic* on those links. > > > > > > If not, what do you hope to accomplish by avoiding higher-power nodes? > > > > > > > > > > > > > > > eric > > > > > > > -----Original Message----- > > > > From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com] > > > > Sent: Thursday, February 07, 2013 10:59 AM > > > > To: Eric Osborne (eosborne) > > > > Cc: Shankar Raman; curtis@occnc.com; rtgwg@ietf.org > > > > Subject: Re: Power aware networks : Comments requested from routing > > > > community > > > > > > > > Dear Eric, > > > > > > > > We seem to be discussing at cross purposes. > > > > > > > > The root of our position is not what you have stated. We do not say > if > > > you dont > > > > use a link you consume less power. We are not for avoiding links but > we > > > are for > > > > avoiding nodes/routers/switches which have a large power footprint. > The > > > > essence of using link metrics is to avoid nodes with larger power > > > footprints. > > > > That is how SPF or CSPF works. When it computes a low power path it > > > avoids > > > > nodes and also links that lead to that node which has a larger power > > > footprint. > > > > So the premise that we are just avoiding links is WRONG. > > > > > > > > For #1 question, we dont even talk about the power the link draws. We > > > talk > > > > about the power footprint of the node that it is connected to. > > > > > > > > For #2 question, again we state that your premise of avoiding links > in > > > your > > > > example is a non-starter for us. > > > > > > > > thanks and regards, > > > > balaji venkat > --e89a8ff1ce46d436bb04d5353e17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Curtis,

    Comments inline.... <balajivenkat>
    On Fri, Feb 8, 2013 at 3:27 AM, Curtis Vill= amizar <curtis@occnc.com> wrote:

    In message <CAHF4apOGL40a3owkjznvOafN7u6cL06vt0rU8vRuNiWPUH9v= 2A@mail.gmail.com>
    Balaji venkat Venkataswami writes:

    > Dear Eric,
    >
    > Please take a look at the tcam-efficiency draft that we have published= .
    >
    > The URL to the draft is
    > http://tools.ietf.org/html/draft-mjsraman-= panet-tcam-power-efficiency-00
    >
    > A follow up draft that defines TCAM efficiency in terms of a metric is=
    > also outlined in...
    >
    > http://tools.ietf.org/html/draft-mjsraman-panet= -tcam-power-ratio-02
    >
    > With the help of the above schemes and additional work that is in
    > progress we intend to reduce the power footprint of a
    > device/router/switch/chassis such that important power guzzling
    > components of the router are optimized.
    >
    > In summary, the above 2 drafts coupled with the protocol schemes will<= br> > we feel result in better power saving than what we have today. So
    > essentially optimizing the power consumed within a device coupled with=
    > using protocol schemes between devices will result in saving power. >
    > Hope this helps.
    >
    > thanks and regards,
    > balaji venkat


    balaji,

    This is in the realm of router design.

    = <balajivenkat> Most modern commercial chipsets provide the capability= of switching off TCAM banks.
    TCAMs nowadays come in the form fac= tor of multiple banks that can be switched off and switched on
    with register operations. I wouldnt say that this is uncommon. This al= gorithm we suggest falls within
    the realm of software design wher= e the software is responsible for managing multiple TCAM banks of
    suitable granularity. Its because such chips are available that these = algorithms are feasible today.
    =A0

    You are suggesting a TCAM in which banks can be shut off by reducing
    the number of destination addresses in the FIB.

    A better solution to reduce the power consumed by TCAM is don't use a TCAM. =A0It is fast, but a radix trie based approach or other tree

    <balajivenkat>
    Most vendors and= commercial chipsets manufactured use TCAMs for the Longest prefix match lo= okup.
    Fast is good so TCAMs are in widespread use.=A0

    Radix trees too could be used. But then again we could optimize the SRAM= they use by applying=A0
    similar approaches to reducing the radix= tree to hold only routes that are in use. So it is the
    general philosophy that is of importance and does not hinge on usage o= f TCAMs in routers.
    =A0=A0
    approach consumes less power and pipelining makes such an approach
    feasible if the lookup memory can be kept on-chip. =A0MPLS lookup can be easily done in on chip SRAM rather than TCAM consuming mush less power
    than an on-chip TCAM and a fraction of the power of off chip TCAM due
    to the SERDES power needed to go off chip.

    This pair of drafts in particular should be dropped.
    <= br>
    Hence we think this work is of importance in the current cont= ext.
    This is currently work in progress.

    thanks and regards,
    balaji venkat=A0

    Curtis


    > On Thu, Feb 7, 2013 at 9:38 PM, Eric Osborne (eosborne)
    > <eosborne@cisco.com>wr= ote:
    >
    > > [size trimmed]
    > >
    > > OK, so you want to avoid nodes which draw more power.
    > > Are you assuming that minimizing the traffic across a node also m= inimizes
    > > the power that node draws?
    > >
    > > If yes:
    > > =A0- please provide concrete examples of how this actually works.= =A0In my
    > > experience the power draw by a router or switch is pretty constan= t, more
    > > driven by the *existence* of links (because links -> linecards= -> power
    > > draw) than by the *traffic* on those links.
    > >
    > > If not, what do you hope to accomplish by avoiding higher-power n= odes?
    > >
    > >
    > >
    > >
    > > eric
    > >
    > > > -----Original Message-----
    > > > From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com]
    > > > Sent: Thursday, February 07, 2013 10:59 AM
    > > > To: Eric Osborne (eosborne)
    > > > Cc: Shankar Raman; curti= s@occnc.com; rtgwg@ietf.org
    > > > Subject: Re: Power aware networks : Comments requested from = routing
    > > > community
    > > >
    > > > Dear Eric,
    > > >
    > > > We seem to be discussing at cross purposes.
    > > >
    > > > The root of our position is not what you have stated. We do = not say if
    > > you dont
    > > > use a link you consume less power. We are not for avoiding l= inks but we
    > > are for
    > > > avoiding nodes/routers/switches which have a large power foo= tprint. The
    > > > essence of using link metrics is to avoid nodes with larger = power
    > > footprints.
    > > > That is how SPF or CSPF works. When it computes a low power = path it
    > > avoids
    > > > nodes and also links that lead to that node which has a larg= er power
    > > footprint.
    > > > So the premise that we are just avoiding links is WRONG.
    > > >
    > > > For #1 question, we dont even talk about the power the link = draws. We
    > > talk
    > > > about the power footprint of the node that it is connected t= o.
    > > >
    > > > For #2 question, again we state that your premise of avoidin= g links in
    > > your
    > > > example is a non-starter for us.
    > > >
    > > > thanks and regards,
    > > > balaji venkat

    --e89a8ff1ce46d436bb04d5353e17-- From jdrake@juniper.net Fri Feb 8 05:30:54 2013 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 3C11D21F8806 for ; Fri, 8 Feb 2013 05:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.983 X-Spam-Level: X-Spam-Status: No, score=-2.983 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQ+oysc8YMnj for ; Fri, 8 Feb 2013 05:30:53 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id C118321F87FA for ; Fri, 8 Feb 2013 05:30:52 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKURT+DNOruOa0po7FYf+JUhz4VnrkhZdM@postini.com; Fri, 08 Feb 2013 05:30:52 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 8 Feb 2013 05:26:56 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 8 Feb 2013 05:26:56 -0800 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.15) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 8 Feb 2013 05:35:44 -0800 Received: from mail62-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Feb 2013 13:26:55 +0000 Received: from mail62-tx2 (localhost [127.0.0.1]) by mail62-tx2-R.bigfish.com (Postfix) with ESMTP id 7BC172E0294 for ; Fri, 8 Feb 2013 13:26:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -32 X-BigFish: PS-32(zz98dI9371Ic85fh542I1432I328cMzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah30d1K8275bh8275dh18c673hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received: from mail62-tx2 (localhost.localdomain [127.0.0.1]) by mail62-tx2 (MessageSwitch) id 1360330011845137_28651; Fri, 8 Feb 2013 13:26:51 +0000 (UTC) Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.248]) by mail62-tx2.bigfish.com (Postfix) with ESMTP id C746C26006D; Fri, 8 Feb 2013 13:26:51 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Feb 2013 13:26:43 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.189]) by BL2PRD0510HT004.namprd05.prod.outlook.com ([10.255.100.39]) with mapi id 14.16.0263.000; Fri, 8 Feb 2013 13:26:42 +0000 From: John E Drake To: Balaji venkat Venkataswami , "Eric Osborne (eosborne)" Subject: RE: Power aware networks : Comments requested from routing community Thread-Topic: Power aware networks : Comments requested from routing community Thread-Index: AQHOBJmI9fL6dxa9R06j94m+9aozuZhtkbkA//+h48CAAPPu4IAAY5NAgABoWYD//5u3MIAABiSAgAFhENA= Date: Fri, 8 Feb 2013 13:26:42 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E1451519F@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <20ECF67871905846A80F77F8F4A27572100BEE0B@xmb-rcd-x09.cisco.com> <3B74A0857EB0496E8FA8B026A758D788@NCSVAIO> <20ECF67871905846A80F77F8F4A27572100BF86F@xmb-rcd-x09.cisco.com> <20ECF67871905846A80F77F8F4A27572100BF9BD@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: multipart/alternative; boundary="_000_0182DEA5604B3A44A2EE61F3EE3ED69E1451519FBL2PRD0510MB349_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Shankar Raman , "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: Fri, 08 Feb 2013 13:30:54 -0000 --_000_0182DEA5604B3A44A2EE61F3EE3ED69E1451519FBL2PRD0510MB349_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://patft.uspto.gov/netacgi/nph-Parser?Sect1=3DPTO1&Sect2=3DHITOFF&d=3DP= ALL&p=3D1&u=3D%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=3D1&f=3DG&l=3D50&s1=3D71625= 72.PN.&OS=3DPN/7162572&RS=3DPN/7162572 Irrespectively Yours, John From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of B= alaji venkat Venkataswami Sent: Thursday, February 07, 2013 8:22 AM To: Eric Osborne (eosborne) Cc: Shankar Raman; rtgwg@ietf.org Subject: Re: Power aware networks : Comments requested from routing communi= ty Dear Eric, Please take a look at the tcam-efficiency draft that we have published. The URL to the draft is http://tools.ietf.org/html/draft-mjsraman-panet-tca= m-power-efficiency-00 A follow up draft that defines TCAM efficiency in terms of a metric is also= outlined in... http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-ratio-02 With the help of the above schemes and additional work that is in progress = we intend to reduce the power footprint of a device/router/switch/chassis such that important power= guzzling components of the router are optimized. In summary, the above 2 drafts coupled with the protocol schemes will we fe= el result in better power saving than what we have today. So essentially optimizing the power consume= d within a device coupled with using protocol schemes between devices will result in saving p= ower. Hope this helps. thanks and regards, balaji venkat On Thu, Feb 7, 2013 at 9:38 PM, Eric Osborne (eosborne) > wrote: [size trimmed] OK, so you want to avoid nodes which draw more power. Are you assuming that minimizing the traffic across a node also minimizes t= he power that node draws? If yes: - please provide concrete examples of how this actually works. In my expe= rience the power draw by a router or switch is pretty constant, more driven= by the *existence* of links (because links -> linecards -> power draw) tha= n by the *traffic* on those links. If not, what do you hope to accomplish by avoiding higher-power nodes? eric > -----Original Message----- > From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com] > Sent: Thursday, February 07, 2013 10:59 AM > To: Eric Osborne (eosborne) > Cc: Shankar Raman; curtis@occnc.com; rtgwg@ietf.= org > Subject: Re: Power aware networks : Comments requested from routing > community > > Dear Eric, > > We seem to be discussing at cross purposes. > > The root of our position is not what you have stated. We do not say if yo= u dont > use a link you consume less power. We are not for avoiding links but we a= re for > avoiding nodes/routers/switches which have a large power footprint. The > essence of using link metrics is to avoid nodes with larger power footpri= nts. > That is how SPF or CSPF works. When it computes a low power path it avoid= s > nodes and also links that lead to that node which has a larger power foot= print. > So the premise that we are just avoiding links is WRONG. > > For #1 question, we dont even talk about the power the link draws. We tal= k > about the power footprint of the node that it is connected to. > > For #2 question, again we state that your premise of avoiding links in yo= ur > example is a non-starter for us. > > thanks and regards, > balaji venkat > --_000_0182DEA5604B3A44A2EE61F3EE3ED69E1451519FBL2PRD0510MB349_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    http://= patft.uspto.gov/netacgi/nph-Parser?Sect1=3DPTO1&Sect2=3DHITOFF&d=3D= PALL&p=3D1&u=3D%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=3D1&f=3DG&= amp;l=3D50&s1=3D7162572.PN.&OS=3DPN/7162572&RS=3DPN/7162572=

     <= /p>

    Irrespectively Yours,

     <= /p>

    John

     <= /p>

    From: rtgwg-bo= unces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Balaji venkat Venkataswami
    Sent: Thursday, February 07, 2013 8:22 AM
    To: Eric Osborne (eosborne)
    Cc: Shankar Raman; rtgwg@ietf.org
    Subject: Re: Power aware networks : Comments requested from routing = community

     

    Dear Eric,


    Please take a look at the tcam-efficiency draft that we have published.

     

     

    A follow up draft that defines TCAM efficiency in te= rms of a metric is also outlined in...

     

     

    With the help of the above schemes and additional wo= rk that is in progress we intend to reduce the

    power footprint of a device/router/switch/chassis su= ch that important power guzzling components of

    the router are optimized. 

     

    In summary, the above 2 drafts coupled with the prot= ocol schemes will we feel result in better power

    saving than what we have today. So essentially optim= izing the power consumed within a device 

    coupled with using protocol schemes between devices = will result in saving power.

     

    Hope this helps.

     

    thanks and regards,

    balaji venkat

     

    On Thu, Feb 7, 2013 at 9:38 PM, Eric Osborne (eosbor= ne) <eosborne@ci= sco.com> wrote:

    [size trimmed]

    OK, so you want to avoid nodes which draw more power.
    Are you assuming that minimizing the traffic across a node also minimizes t= he power that node draws?

    If yes:
     - please provide concrete examples of how this actually works.  = In my experience the power draw by a router or switch is pretty constant, m= ore driven by the *existence* of links (because links -> linecards ->= power draw) than by the *traffic* on those links.

    If not, what do you hope to accomplish by avoiding higher-power nodes?




    eric


    > -----Original Message-----
    > From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com]
    > Sent: Thursday, February 07, 2013 10:59 AM
    > To: Eric Osborne (eosborne)

    > Cc: Shankar Raman; curtis@occnc.com; rtgwg@ietf.org
    > Subject: Re: Power aware networks : Comments requested from routing > community
    >
    > Dear Eric,
    >

    > We seem to be di= scussing at cross purposes.
    >
    > The root of our position is not what you have stated. We do not say if= you dont
    > use a link you consume less power. We are not for avoiding links but w= e are for
    > avoiding nodes/routers/switches which have a large power footprint. Th= e
    > essence of using link metrics is to avoid nodes with larger power foot= prints.
    > That is how SPF or CSPF works. When it computes a low power path it av= oids
    > nodes and also links that lead to that node which has a larger power f= ootprint.
    > So the premise that we are just avoiding links is WRONG.
    >
    > For #1 question, we dont even talk about the power the link draws. We = talk
    > about the power footprint of the node that it is connected to.
    >
    > For #2 question, again we state that your premise of avoiding links in= your
    > example is a non-starter for us.
    >
    > thanks and regards,
    > balaji venkat
    >

     

    --_000_0182DEA5604B3A44A2EE61F3EE3ED69E1451519FBL2PRD0510MB349_-- From eosborne@cisco.com Fri Feb 8 06:53:30 2013 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 97FC921F8A4F for ; Fri, 8 Feb 2013 06:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.945 X-Spam-Level: X-Spam-Status: No, score=-8.945 tagged_above=-999 required=5 tests=[AWL=1.654, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLQJEHGUt7cR for ; Fri, 8 Feb 2013 06:53:26 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 38E5F21F87F6 for ; Fri, 8 Feb 2013 06:53:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3853; q=dns/txt; s=iport; t=1360335206; x=1361544806; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8UujEIz4J5YEQXV+Bnh3ANXmoEmdgPmwzD1KBzu5wSQ=; b=bJ9panRbEEMt5C7b/DMTxp4Cq+ByGbc4JTu0sLUUyo/ChUvtqalorNNv BeiU6xIaftzhvxh/e1F+wo4Q+GQR82eHx2mxMxqgiIJ9axV/IM3tvnx1B TBNCfRh5Y+ntlhvj4IxwHAHYAI8kbXJFSRjh8x+MbrXEuM3gbHiy+zQz1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAL8QFVGtJV2a/2dsb2JhbABFwRIWc4IfAQEBBAEBARodLgYLDAQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCAELB4d2DMBijRQRg1ZhA5JqhFePNYMAgW81 X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; d="scan'208";a="174931397" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 08 Feb 2013 14:53:25 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r18ErPBq029078 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Feb 2013 14:53:25 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 08:53:25 -0600 From: "Eric Osborne (eosborne)" To: Mingui Zhang , Tony Li , "curtis@occnc.com" Subject: RE: PANET side-meeting Thread-Topic: PANET side-meeting Thread-Index: AQHOBctWUr8UpBPq1UixHTNAwDsanphwDFcg Date: Fri, 8 Feb 2013 14:53:24 +0000 Message-ID: <20ECF67871905846A80F77F8F4A27572100C0A1C@xmb-rcd-x09.cisco.com> References: <201302072244.r17Mi3Og002450@gateway1.orleans.occnc.com> <6B5386C5-F507-417F-94E8-0E4B6446FFA8@tony.li> <4552F0907735844E9204A62BBDD325E732AFF460@nkgeml508-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E732AFF460@nkgeml508-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.23.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Susan Hares , "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: Fri, 08 Feb 2013 14:53:30 -0000 Will this side meeting be in Orlando? I'm sceptical of some of the current= approaches but am very interested in where they might go. eric > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Mingui Zhang > Sent: Friday, February 08, 2013 2:10 AM > To: Tony Li; curtis@occnc.com > Cc: Susan Hares; rtgwg@ietf.org > Subject: PANET side-meeting >=20 > Hi Tony and Curtis, >=20 > Let me retrospect some history to clear up the chaos floating around. >=20 > On Feb 4th, I organized a conference call among a dozen of guys (from > operators, vendors and Universities) who are interested in PANET, in orde= r to > prepare for a side meeting in IETF. There was a rough consensus that a si= de- > meeting is a good way to call for interest, coordination and contribution= to > PANET. However, requests was _prematurely_ sent out afterwards, without > including all the effort from the conference attendees. I hope this email= can get > us back on track. So I change its title. >=20 > I believe the most efficient way for us is to play the game according to = the rule > of IETF/IRTF. Therefore, we are trying to find a place to accommodate the= side- > meeting. We should not delve into discussion of specific solutions before= we > make clear the problem scope. A charter should be published, which will h= elp > us figure out what is the problem we are trying to solve. Before that, le= t me > add some pointers of drafts from my side. I believe these drafts can also= help > people to figure out the scope of PANET. > Power-Aware Networks (PANET): Problem Statement, > https://datatracker.ietf.org/doc/draft-zhang-panet-problem-statement/ > Use Cases for Power-Aware Networks, https://datatracker.ietf.org/doc/draf= t- > zhang-panet-use-cases/ > Requirements for Power Aware Network, > https://datatracker.ietf.org/doc/draft-dong-panet-requirement/ >=20 > On the 84th IETF rtgwg f2f meeting, there were two presentations relevant= to > greening. I also list them as follows FYI. > A Framework and Requirements for Energy Aware Control Planes, > http://tools.ietf.org/html/draft-retana-rtgwg-eacp-00, [slides] > http://www.ietf.org/proceedings/84/slides/slides-84-rtgwg-3.pptx > Power-aware Routing and Traffic Engineering: Requirements, Approaches, an= d > Issues, https://datatracker.ietf.org/doc/draft-zhang-greennet/, [slides] > http://www.ietf.org/proceedings/84/slides/slides-84-rtgwg-4.pptx >=20 > Thanks, > Mingui Zhang > Huawei Technologies >=20 >=20 > >-----Original Message----- > >From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > >Of Tony Li > >Sent: Friday, February 08, 2013 7:02 AM > >To: curtis@occnc.com > >Cc: Shankar Raman M J; rtgwg@ietf.org > >Subject: Re: Power aware networks : Comments requested from routing > >community > > > > > >On Feb 7, 2013, at 2:44 PM, Curtis Villamizar wrote: > > > >> I don't think this is even material ready for IRTF consideration, but > >> that is up to Tony and IRTF to decide. > > > > > >As always, the IRTF does not require well-formed ideas as a > >pre-requisite for starting work. Instead, there needs to be a clear > >problem statement (i.e., a > >charter) and a sufficient group of serious researchers who are > >committed to following through in a committed manner. > > > >Note that it is, by definition, research. It is expected to have a > >non-trivial likelihood of failure. > > > >Regards, > >Tony > > > >_______________________________________________ > >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 From aretana@cisco.com Fri Feb 8 07:41:41 2013 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 251CA21F8A99 for ; Fri, 8 Feb 2013 07:41:41 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QGfY6uwocip for ; Fri, 8 Feb 2013 07:41:40 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 04A8921F8A80 for ; Fri, 8 Feb 2013 07:41:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4497; q=dns/txt; s=iport; t=1360338100; x=1361547700; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Eh6qebAWVR2FxaAtMWvA5E2QpXJ2JZb/Sn6zseF0aOE=; b=e7AYWmuHyXUGeAdNQZpd41kbDkVi5l1/6pYQKMsU3x1UBKHQ0/tjZZQK LC63rJWvpjY6L73XH9AAU9aKrcaxWSIZHzSNNfHL3aJPFEEx4a+Kc3HRO dg2aHbIx/OVs6eQUJBGWos1It2Oi18j6Rm2g/resXTKNq4jDttGAFj2KE o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAH0bFVGtJV2c/2dsb2JhbABFwRIWc4IfAQEBAwEBAQEaHS4GCwUHBAIBCBEEAQEBHgkHJwsUCQgCBA4FCQsHh3AGDMAcjRQRg1ZhA5JqgzqBHY81gwCBbw X-IronPort-AV: E=Sophos;i="4.84,630,1355097600"; d="scan'208";a="174997660" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 08 Feb 2013 15:41:39 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r18FfdqK007434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Feb 2013 15:41:39 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.174]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 09:41:39 -0600 From: "Alvaro Retana (aretana)" To: "Eric Osborne (eosborne)" Subject: Re: PANET side-meeting Thread-Topic: PANET side-meeting Thread-Index: AQHOBctWqBu9VUeRrkmt2fY4/yliWZhwcRUA//+o5fM= Date: Fri, 8 Feb 2013 15:41:38 +0000 Message-ID: References: <201302072244.r17Mi3Og002450@gateway1.orleans.occnc.com> <6B5386C5-F507-417F-94E8-0E4B6446FFA8@tony.li> <4552F0907735844E9204A62BBDD325E732AFF460@nkgeml508-mbx.china.huawei.com>, <20ECF67871905846A80F77F8F4A27572100C0A1C@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A27572100C0A1C@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg@ietf.org" , Susan Hares 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: Fri, 08 Feb 2013 15:41:41 -0000 No, there won't be a side meeting in Orlando. However, we secured more time (than the regular 90 min) for rtgwg so that w= e can have a discussion there. Alia and I will send out more details (objectives, ground rules, etc.) soon= . Thanks! Alvaro. Sent from my iPhone On Feb 8, 2013, at 9:53 AM, "Eric Osborne (eosborne)" = wrote: > Will this side meeting be in Orlando? I'm sceptical of some of the curre= nt approaches but am very interested in where they might go. >=20 >=20 >=20 >=20 >=20 > eric >=20 >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf O= f >> Mingui Zhang >> Sent: Friday, February 08, 2013 2:10 AM >> To: Tony Li; curtis@occnc.com >> Cc: Susan Hares; rtgwg@ietf.org >> Subject: PANET side-meeting >>=20 >> Hi Tony and Curtis, >>=20 >> Let me retrospect some history to clear up the chaos floating around. >>=20 >> On Feb 4th, I organized a conference call among a dozen of guys (from >> operators, vendors and Universities) who are interested in PANET, in ord= er to >> prepare for a side meeting in IETF. There was a rough consensus that a s= ide- >> meeting is a good way to call for interest, coordination and contributio= n to >> PANET. However, requests was _prematurely_ sent out afterwards, without >> including all the effort from the conference attendees. I hope this emai= l can get >> us back on track. So I change its title. >>=20 >> I believe the most efficient way for us is to play the game according to= the rule >> of IETF/IRTF. Therefore, we are trying to find a place to accommodate th= e side- >> meeting. We should not delve into discussion of specific solutions befor= e we >> make clear the problem scope. A charter should be published, which will = help >> us figure out what is the problem we are trying to solve. Before that, l= et me >> add some pointers of drafts from my side. I believe these drafts can als= o help >> people to figure out the scope of PANET. >> Power-Aware Networks (PANET): Problem Statement, >> https://datatracker.ietf.org/doc/draft-zhang-panet-problem-statement/ >> Use Cases for Power-Aware Networks, https://datatracker.ietf.org/doc/dra= ft- >> zhang-panet-use-cases/ >> Requirements for Power Aware Network, >> https://datatracker.ietf.org/doc/draft-dong-panet-requirement/ >>=20 >> On the 84th IETF rtgwg f2f meeting, there were two presentations relevan= t to >> greening. I also list them as follows FYI. >> A Framework and Requirements for Energy Aware Control Planes, >> http://tools.ietf.org/html/draft-retana-rtgwg-eacp-00, [slides] >> http://www.ietf.org/proceedings/84/slides/slides-84-rtgwg-3.pptx >> Power-aware Routing and Traffic Engineering: Requirements, Approaches, a= nd >> Issues, https://datatracker.ietf.org/doc/draft-zhang-greennet/, [slides] >> http://www.ietf.org/proceedings/84/slides/slides-84-rtgwg-4.pptx >>=20 >> Thanks, >> Mingui Zhang >> Huawei Technologies >>=20 >>=20 >>> -----Original Message----- >>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf >>> Of Tony Li >>> Sent: Friday, February 08, 2013 7:02 AM >>> To: curtis@occnc.com >>> Cc: Shankar Raman M J; rtgwg@ietf.org >>> Subject: Re: Power aware networks : Comments requested from routing >>> community >>>=20 >>>=20 >>> On Feb 7, 2013, at 2:44 PM, Curtis Villamizar wrote: >>>=20 >>>> I don't think this is even material ready for IRTF consideration, but >>>> that is up to Tony and IRTF to decide. >>>=20 >>>=20 >>> As always, the IRTF does not require well-formed ideas as a >>> pre-requisite for starting work. Instead, there needs to be a clear >>> problem statement (i.e., a >>> charter) and a sufficient group of serious researchers who are >>> committed to following through in a committed manner. >>>=20 >>> Note that it is, by definition, research. It is expected to have a >>> non-trivial likelihood of failure. >>>=20 >>> Regards, >>> Tony >>>=20 >>> _______________________________________________ >>> 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 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From donald.fedyk@alcatel-lucent.com Fri Feb 8 08:22:26 2013 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 8F55F21F84D5 for ; Fri, 8 Feb 2013 08:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X52Me9q8+-tH for ; Fri, 8 Feb 2013 08:22:25 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 53B3621F8AA3 for ; Fri, 8 Feb 2013 08:22:24 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r18GMJJp015989 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 8 Feb 2013 17:22:19 +0100 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 8 Feb 2013 17:22:19 +0100 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.135]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Fri, 8 Feb 2013 11:22:17 -0500 From: "Fedyk, Donald (Don)" To: Mingui Zhang , Hannes Gredler Subject: RE: Power aware networks : Comments requested from routing community Thread-Topic: Power aware networks : Comments requested from routing community Thread-Index: AQHOBJmIop87Llgb7UmS6eAqj25uYphustMAgAAyswCAARC7AIAAB+gAgAAGogCAAAR0gIAACyyg Date: Fri, 8 Feb 2013 16:22:16 +0000 Message-ID: <59E40B2663705C47B8C0A107CBFBA98807D6BE@US70TWXCHMBA09.zam.alcatel-lucent.com> References: <201302061841.r16IfBn5084352@gateway1.orleans.occnc.com> <72B40FF5-6A29-4857-93AA-768490A20903@juniper.net> <021A2E07-50AF-443C-AC4A-E61A28D57F6F@tony.li> <534A746F-66FE-49F2-86FA-20CCED1487CE@juniper.net> <4552F0907735844E9204A62BBDD325E732AFF5B1@nkgeml508-mbx.china.huawei.com> <2ACD61D8-783A-404D-BB60-02E83FABDE3B@juniper.net> <4552F0907735844E9204A62BBDD325E732AFF5D5@nkgeml508-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E732AFF5D5@nkgeml508-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: Shankar Raman M J , "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: Fri, 08 Feb 2013 16:22:26 -0000 I too think this is a research area. =20 I will comment on the metric though. Path computation on multiple metrics i= s hard so we usually minimize one metric subject to a set of constraints. = Is a power metric a primary minimization metric? I would bet if you asked p= roviders the answer is no. So it would be compute a minimum path based on B= andwidth or delay subject to a set of equipment that qualifies as "green". = Or prefer green links if possible.=20 How do you determine Green links? The PWR metric proposed has two items: Power per XGIG and Available Utiliza= tion (draft-mjsraman-panet-ospf-power-topo-00) I'd argue that Power per XGIG has to be measured and verified on an equal s= cale across vendors (so it is unlikely to be populated by vendors in any ea= sily agreed manner ;-) ) and it is related to utilization (Higher utilizati= on =3D more power/bit). So if you divide by available utilization, the goal of the metric seems to = be to produce an average power per XGIG.=20 So the metric is roughly a constant per port. Comparing all the link metrics in the network some set would qualify as gre= en, others perhaps yellow or red.=20 So an easy way to get 90% of the value of this is Measure your equipment. C= olor the best ports Green (using some threshold), and have a path computati= on that prefers green links all other things being equal.=20 This puts the onus on Operators to measure power and color links (administr= ative group (color) exists) and requires a path computation that can prefer= green. A requirement that is softer than must be green. Just saying.. Don=20 -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of M= ingui Zhang Sent: Friday, February 08, 2013 4:33 AM To: Hannes Gredler Cc: Shankar Raman M J; rtgwg@ietf.org Subject: RE: Power aware networks : Comments requested from routing communi= ty Hannes, That's the dream of line-card hardware manufactures. If the hardware is 100= % power proportional, then PANET will become useless. However, the practice is that only 10%-15% power proportional is possible, = which means a high 85%-90% of baseline power is being wasted when there is = few traffic. Thanks, Mingui >-----Original Message----- >From: Hannes Gredler [mailto:hannes@juniper.net] >Sent: Friday, February 08, 2013 5:17 PM >To: Mingui Zhang >Cc: Tony Li; Shankar Raman M J; rtgwg@ietf.org >Subject: Re: Power aware networks : Comments requested from routing=20 >community > >mingui, > >wouldn't designing the hardware architecture such that there is no high=20 >baseline rather than a more demand based power draw curve be the better=20 >alternative then ? > >only box local changes needed, immediate returns, no need to bother the=20 >network with the fact that the local box cannot do the power=20 >housekeeping well ? > >/hannes > >On Feb 8, 2013, at 9:53 AM, Mingui Zhang wrote: > >> Hi Hannes, >> >> "Optimization" tries to empty all links on one line-card with=20 >> priority, then this >line card can be shut off to save the high baseline power. >> >> Thanks, >> Mingui Zhang >> Huawei Technologies >> >>> -----Original Message----- >>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On=20 >>> Behalf >Of >>> Hannes Gredler >>> Sent: Friday, February 08, 2013 4:25 PM >>> To: Tony Li >>> Cc: Shankar Raman M J; rtgwg@ietf.org >>> Subject: Re: Power aware networks : Comments requested from routing=20 >>> community >>> >>> tony, >>> >>> agree that saving power is a worthwhile goal; >>> >>> in fact existing hardware technology is making that happen today by=20 >>> e.g. automatically shutting down unused lookup engines, CPU cores,=20 >>> memory banks etc. >>> when there is low processing demand. >>> >>> the part where i am not yet convinced is that additional off-peak >"optimization" >>> of >>> infrastructure links by e.g. computing a routing mesh which only=20 >>> uses 70% of the nominal links does actually give much power savings. >>> >>> note that line cards which are running at 70% have already throttled=20 >>> down >their >>> power consumption - so what is the point emptying the link and=20 >>> loading another ? >>> appears to me a zero sum game. >>> >>> my concern about the core (and SP edge) is not about business or=20 >>> technology >- >>> it is more about if we try to optimize an already optimized (and=20 >>> solved) >problem. >>> >>> /hannes >>> >>> On Feb 7, 2013, at 5:09 PM, Tony Li wrote: >>> >>>> >>>> On Feb 7, 2013, at 5:07 AM, Hannes Gredler wrote: >>>> >>>>> Do you think that optimizing a part of the network which gives=20 >>>>> only limited overall savings is a worthwhile goal ? >>>> >>>> >>>> Hannes, >>>> >>>> I'll just point out that this argument that you and Eric are=20 >>>> espousing is >skirting >>> dangerously close to the quagmire of business. And we know from=20 >>> long experience that the IETF does not do business models. >>>> >>>> I'd like to strongly suggest that we simply restrict ourselves to=20 >>>> the goal of >>> saving power. I think that we can agree, in general, that saving=20 >>> power is a worthwhile goal. As to whether or not it is significant=20 >>> or makes economic sense is very much an issue that should be left to=20 >>> the operator community to decide. Limited overall savings may be=20 >>> worthwhile in one context and >pointless >>> in another. >>>> >>>> I know of one country where they are purportedly mandating power >reductions. >>> In such situations, saving that last watt is the difference between=20 >>> a fine and >not. >>> On the other hand, in a situation where power is very cheap, it's=20 >>> obviously >silly. >>>> >>>> Let's not argue about the marginal value of energy. That's a=20 >>>> business >model >>> issue. Let's talk about how technology can actually save power. >>>> >>>> Regards, >>>> Tony >>>> >>>> >>> >>> >>> _______________________________________________ >>> 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 From curtis@occnc.com Fri Feb 8 09:27:14 2013 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 0FEE421F89AA for ; Fri, 8 Feb 2013 09:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUbc-NCF4u7I for ; Fri, 8 Feb 2013 09:27:13 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 32C3721F8A5F for ; Fri, 8 Feb 2013 09:27:13 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r18HPpt3010162; Fri, 8 Feb 2013 12:25:51 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302081725.r18HPpt3010162@gateway1.orleans.occnc.com> To: Mingui Zhang From: Curtis Villamizar Subject: Re: PANET side-meeting In-reply-to: Your message of "Fri, 08 Feb 2013 07:09:38 GMT." <4552F0907735844E9204A62BBDD325E732AFF460@nkgeml508-mbx.china.huawei.com> Date: Fri, 08 Feb 2013 12:25:51 -0500 Cc: "rtgwg@ietf.org" , Susan Hares 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: Fri, 08 Feb 2013 17:27:14 -0000 In message <4552F0907735844E9204A62BBDD325E732AFF460@nkgeml508-mbx.china.huawei.com> Mingui Zhang writes: > Hi Tony and Curtis, > > Let me retrospect some history to clear up the chaos floating around. > > On Feb 4th, I organized a conference call among a dozen of guys (from > operators, vendors and Universities) who are interested in PANET, in > order to prepare for a side meeting in IETF. There was a rough > consensus that a side-meeting is a good way to call for interest, > coordination and contribution to PANET. However, requests was > _prematurely_ sent out afterwards, without including all the effort > from the conference attendees. I hope this email can get us back on > track. So I change its title. I could find no record of this in a google search. Nothing that seemed relevant for "PANET meeting", "PANET conference call", or "Power Aware Networking" other than IETF chatter and the already discussed academic papers. Is there any reference to this meeting? An closed ad-hoc conference call does not justify a new WG, even an IRTF WG. Would you care to say who attended the conference call and whether anyone took notes that could be shared? Was this just among the authors of the docs sent to RTGWG? [If so, it would seem more like a Huawei internal meeting with a few guests.] > I believe the most efficient way for us is to play the game according > to the rule of IETF/IRTF. Therefore, we are trying to find a place to > accommodate the side-meeting. We should not delve into discussion of > specific solutions before we make clear the problem scope. A charter > should be published, which will help us figure out what is the problem > we are trying to solve. Before that, let me add some pointers of > drafts from my side. I believe these drafts can also help people to > figure out the scope of PANET. Power-Aware Networks (PANET): Problem > Statement, > https://datatracker.ietf.org/doc/draft-zhang-panet-problem-statement/ > Use Cases for Power-Aware Networks, > https://datatracker.ietf.org/doc/draft-zhang-panet-use-cases/ > Requirements for Power Aware Network, > https://datatracker.ietf.org/doc/draft-dong-panet-requirement/ The usual way to do this formally in IETF is to request a BOF. Informally you can ask for a room or just get together at the bar (the venue of choice for an informal ad hoc BOF a decade or more ago). > On the 84th IETF rtgwg f2f meeting, there were two presentations > relevant to greening. I also list them as follows FYI. A Framework > and Requirements for Energy Aware Control Planes, > http://tools.ietf.org/html/draft-retana-rtgwg-eacp-00, [slides] > http://www.ietf.org/proceedings/84/slides/slides-84-rtgwg-3.pptx > Power-aware Routing and Traffic Engineering: Requirements, Approaches, > and Issues, https://datatracker.ietf.org/doc/draft-zhang-greennet/, > [slides] > http://www.ietf.org/proceedings/84/slides/slides-84-rtgwg-4.pptx > > Thanks, > Mingui Zhang > Huawei Technologies At IETF, no activity at all on the WG mailing list usually means not enough interest and therefore no advancement. I mentioned earlier on the prior thread that I had just quickly read draft-retana-rtgwg-eacp-00 and did not think this work was worth the IETF (or IRTF, if I can speak up in advance) in its current form. The topic might be worth considering, but the work seems to take a naive approach. Whether treating interfaces and links as a black box and using routing provides any appreciable gain in real networks remains to be proven. These documents are trying to write requirements, build a framework, and specify protocols, all based on unproven assertions. If the work goes to IRTF, the first order of business must be to provide compelling proof or at least compelling argument that a specific approach will have benefit in *real* networks, not hypothetic networks, and not real topologies with a hypothetic network architecture (ie: choice of type of equipment and build out). Curtis > > -----Original Message----- > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > > Tony Li > > Sent: Friday, February 08, 2013 7:02 AM > > To: curtis@occnc.com > > Cc: Shankar Raman M J; rtgwg@ietf.org > > Subject: Re: Power aware networks : Comments requested from routing > > community > > > > > > On Feb 7, 2013, at 2:44 PM, Curtis Villamizar wrote: > > > > > I don't think this is even material ready for IRTF consideration, but > > > that is up to Tony and IRTF to decide. > > > > > > As always, the IRTF does not require well-formed ideas as a > > pre-requisite for starting work. Instead, there needs to be a clear > > problem statement (i.e., a charter) and a sufficient group of serious > > researchers who are committed to following through in a committed > > manner. > > > > Note that it is, by definition, research. It is expected to have a > > non-trivial likelihood of failure. > > > > Regards, > > Tony From tony.li@tony.li Fri Feb 8 09:41:33 2013 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 6974821F8AE5 for ; Fri, 8 Feb 2013 09:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.337 X-Spam-Level: X-Spam-Status: No, score=-100.337 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l569k8Jvtae2 for ; Fri, 8 Feb 2013 09:41:32 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5FB21F8AE3 for ; Fri, 8 Feb 2013 09:41:32 -0800 (PST) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta03.emeryville.ca.mail.comcast.net with comcast id xosi1k0021smiN4A3thYGX; Fri, 08 Feb 2013 17:41:32 +0000 Received: from [192.168.2.111] ([98.248.36.188]) by omta20.emeryville.ca.mail.comcast.net with comcast id xthV1k01E43ZcXW8gthXmA; Fri, 08 Feb 2013 17:41:31 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: PANET side-meeting From: Tony Li In-Reply-To: <201302081725.r18HPpt3010162@gateway1.orleans.occnc.com> Date: Fri, 8 Feb 2013 09:41:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6C1049B1-622A-4D59-810F-D4309F5B813D@tony.li> References: <201302081725.r18HPpt3010162@gateway1.orleans.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360345292; bh=UObsBKeuCc5kmdvnWunHK9QMEnhjtNx2RloFbQuQ2Wg=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=FMEfZnnI4TSvhi5rTQZDY+03mHrn84iQIwzmzAnCx8cBYnYVlAxvxt1O/Fs+d0Ftd 4FAB/3a0gchDvGdsX89tr1CtH1B2kzRGk8y/bSgdNC9GPkCd7YDQzGdpIrFgzIwC7s VJ71IdIxkPILTZptEPL0lgP0zDn+XyCsHD7q7aAqLF1SbjC/B8+PAjuuV3gGutiqeM 8FgbyWf3nIOKwkSz4NSMGQnL+4C7BPr2hObMjtgusLmo8xXShyeoFUgXkOFc3hMwX2 Cq+XXa3W64+SYajs/+s0HLDEYj+Tw5jV1SV9PRtb2GSUdiODybI9C3v6DBwdbeKu26 MZu30mnKDQVLw== Cc: Susan Hares , "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: Fri, 08 Feb 2013 17:41:33 -0000 On Feb 8, 2013, at 9:25 AM, Curtis Villamizar wrote: > If the work goes to IRTF, the first order of business must be to > provide compelling proof or at least compelling argument that a > specific approach will have benefit in *real* networks, not hypothetic > networks, and not real topologies with a hypothetic network > architecture (ie: choice of type of equipment and build out). I think that this sets the bar just a bit too high. Again, the first thing to tackle is a clear problem statement and = demonstrating that there is a community willing to take this on and see = it through. As Curtis is suggesting, showing that a solution is possible would be a = very good thing. Spending time arguing and finding that we are = inherently fighting the laws of physics is simply not productive. However, in showing that a solution exists, we not be constrained to = existing, deployed and off-the-shelf constraints. Again, the IRTF does = research and must be open-minded enough to consider alternate = possibilities, above and beyond what already exists today. If it = implies new router architectures, new network architectures, or new = optimization techniques, then that should be on the table. To be sure, = they must be feasible and practical, but they need not be instantiated = today. =20 Yours in research, Tony From curtis@occnc.com Fri Feb 8 09:46:48 2013 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 1F8DD21F8B2F for ; Fri, 8 Feb 2013 09:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.393 X-Spam-Level: X-Spam-Status: No, score=-0.393 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaSOFKyptmJH for ; Fri, 8 Feb 2013 09:46:47 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 1F64621F8B29 for ; Fri, 8 Feb 2013 09:46:47 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r18HiDDE010266; Fri, 8 Feb 2013 12:44:13 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302081744.r18HiDDE010266@gateway1.orleans.occnc.com> To: Balaji venkat Venkataswami From: Curtis Villamizar Subject: Re: Power aware networks : Comments requested from routing community In-reply-to: Your message of "Fri, 08 Feb 2013 17:26:10 +0530." Date: Fri, 08 Feb 2013 12:44:13 -0500 Cc: Shankar Raman , "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: Fri, 08 Feb 2013 17:46:48 -0000 In message Balaji venkat Venkataswami writes: > Dear Curtis, > > Comments inline.... > > On Fri, Feb 8, 2013 at 3:27 AM, Curtis Villamizar wrote: > > > > > In message < > > CAHF4apOGL40a3owkjznvOafN7u6cL06vt0rU8vRuNiWPUH9v2A@mail.gmail.com> > > Balaji venkat Venkataswami writes: > > > > > Dear Eric, > > > > > > Please take a look at the tcam-efficiency draft that we have published. > > > > > > The URL to the draft is > > > http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-efficiency-00 > > > > > > A follow up draft that defines TCAM efficiency in terms of a metric is > > > also outlined in... > > > > > > http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-ratio-02 > > > > > > With the help of the above schemes and additional work that is in > > > progress we intend to reduce the power footprint of a > > > device/router/switch/chassis such that important power guzzling > > > components of the router are optimized. > > > > > > In summary, the above 2 drafts coupled with the protocol schemes will > > > we feel result in better power saving than what we have today. So > > > essentially optimizing the power consumed within a device coupled with > > > using protocol schemes between devices will result in saving power. > > > > > > Hope this helps. > > > > > > thanks and regards, > > > balaji venkat > > > > > > balaji, > > > > This is in the realm of router design. > > > > Most modern commercial chipsets provide the capability > of switching off TCAM banks. TCAMs nowadays come in the form factor > of multiple banks that can be switched off and switched on with > register operations. I wouldnt say that this is uncommon. This > algorithm we suggest falls within the realm of software design where > the software is responsible for managing multiple TCAM banks of > suitable granularity. Its because such chips are available that these > algorithms are feasible today. You seemed to have missed the point. TCAMs are power hungry. External TCAMs use power in the logic that runs in parallel, and in the SERDES to go off-chip on both sides. Getting rid of the external TCAM reduces SERDES power to zero. Using an alternate to TCAM eliminates that power hungry peice of logic. > > You are suggesting a TCAM in which banks can be shut off by reducing > > the number of destination addresses in the FIB. > > > > A better solution to reduce the power consumed by TCAM is don't use a > > TCAM. It is fast, but a radix trie based approach or other tree > > > > Most vendors and commercial chipsets manufactured use > TCAMs for the Longest prefix match lookup. Fast is good so TCAMs are > in widespread use. Quick fix, but power hungry. That is why some designs are now revisiting the idea of external TCAM. > Radix trees too could be used. But then again we could optimize the > SRAM they use by applying similar approaches to reducing the radix > tree to hold only routes that are in use. So it is the general > philosophy that is of importance and does not hinge on usage of TCAMs > in routers. The active power of a large SRAM is a small fraction of the active power of a large TCAM. For a large SRAM, the active power is so low that the leakage power becomes more significant. That leakage power is constant whether the SRAM is active or not. If the SRAM is being used for route lookup. the small active power comes into play. External TCAM was an easier solution back in the 130nm days and probably up to about the 65nm or 40nm days because, at least back in the 130 nm days, putting the forwarding lookup on chip was unthinkable. There has been a lot of work in higher radix lookups to reduce the number of pipeline stages, or the amount of parallelism needed, and these simply use a small number of low active power SRAM lookups rather than one power hungry TCAM lookup. If only IGP routes and MPLS LSP are present, then the small IGP lookup on a small subset of traffic (however it is done), and the MPLS ILM lookup (a single SRAM lookup) would yield lower power. Even keeping the power hungry external TCAM but providing a separate SRAM for ILM would be a means to lower the power needed for route lookup. > > approach consumes less power and pipelining makes such an approach > > feasible if the lookup memory can be kept on-chip. MPLS lookup can be > > easily done in on chip SRAM rather than TCAM consuming mush less power > > than an on-chip TCAM and a fraction of the power of off chip TCAM due > > to the SERDES power needed to go off chip. > > > > This pair of drafts in particular should be dropped. > > > > Hence we think this work is of importance in the current context. > This is currently work in progress. I disagree for reasons cited above. You are free to continue to design your routers with TCAM if you prefer. Even if this work had merit, which I do not think it does, IETF has never written standards covering ASIC design techniques and forwarding hardware design and there is currently no plans to do so. > thanks and regards, > balaji venkat Curtis > > Curtis > > > > > > > On Thu, Feb 7, 2013 at 9:38 PM, Eric Osborne (eosborne) > > > wrote: > > > > > > > [size trimmed] > > > > > > > > OK, so you want to avoid nodes which draw more power. > > > > Are you assuming that minimizing the traffic across a node also > > minimizes > > > > the power that node draws? > > > > > > > > If yes: > > > > - please provide concrete examples of how this actually works. In my > > > > experience the power draw by a router or switch is pretty constant, > > more > > > > driven by the *existence* of links (because links -> linecards -> power > > > > draw) than by the *traffic* on those links. > > > > > > > > If not, what do you hope to accomplish by avoiding higher-power nodes? > > > > > > > > > > > > > > > > > > > > eric > > > > > > > > > -----Original Message----- > > > > > From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com] > > > > > Sent: Thursday, February 07, 2013 10:59 AM > > > > > To: Eric Osborne (eosborne) > > > > > Cc: Shankar Raman; curtis@occnc.com; rtgwg@ietf.org > > > > > Subject: Re: Power aware networks : Comments requested from routing > > > > > community > > > > > > > > > > Dear Eric, > > > > > > > > > > We seem to be discussing at cross purposes. > > > > > > > > > > The root of our position is not what you have stated. We do not say > > if > > > > you dont > > > > > use a link you consume less power. We are not for avoiding links but > > we > > > > are for > > > > > avoiding nodes/routers/switches which have a large power footprint. > > The > > > > > essence of using link metrics is to avoid nodes with larger power > > > > footprints. > > > > > That is how SPF or CSPF works. When it computes a low power path it > > > > avoids > > > > > nodes and also links that lead to that node which has a larger power > > > > footprint. > > > > > So the premise that we are just avoiding links is WRONG. > > > > > > > > > > For #1 question, we dont even talk about the power the link draws. We > > > > talk > > > > > about the power footprint of the node that it is connected to. > > > > > > > > > > For #2 question, again we state that your premise of avoiding links > > in > > > > your > > > > > example is a non-starter for us. > > > > > > > > > > thanks and regards, > > > > > balaji venkat From akatlas@gmail.com Fri Feb 8 11:19:35 2013 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 AB82421F8B3B for ; Fri, 8 Feb 2013 11:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuqKxVRb6MU7 for ; Fri, 8 Feb 2013 11:19:35 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EE3DA21F8B29 for ; Fri, 8 Feb 2013 11:19:34 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c10so5398358ieb.17 for ; Fri, 08 Feb 2013 11:19:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=0ULfeUBN8PlqKMseQQMrFMIy+Go8Bu+XEQTVUxxT/CY=; b=pAm6OaSNLwJLSgTHOVJIk0m5I4zRoquBdX43ABqP8JAaaRXQatCnkgRlmJr33KwDhs NCsgHpIbD9fypXZxLNye0LHtrJKIxp3ScGGzJ2OYTF4voqsJ6NUW2GjFcmoHbEUIk0uT +CgcXwZLvEQEDZ4G3hFkRIIm5536Ze/dOe5rTMod7kpmYwsMq52yLCly2VyxV7WOvUtj KrA54lVyZ+Zhwzp4Qt3shKFubSWDni5B437l99WCArDq9IHLe1g88PJuKFCqSOV0xy9W WqiOiHUJobnZwFOZUBxNwqcYdd/7ozF+ZtrX4go1Ly0dODE9sBmcuXuyh0QL1R+jG081 /0Dw== MIME-Version: 1.0 X-Received: by 10.50.222.201 with SMTP id qo9mr4539997igc.111.1360351174528; Fri, 08 Feb 2013 11:19:34 -0800 (PST) Received: by 10.64.34.203 with HTTP; Fri, 8 Feb 2013 11:19:34 -0800 (PST) Date: Fri, 8 Feb 2013 14:19:34 -0500 Message-ID: Subject: comments on draft-li-rtgwg-igp-ext-mrt-frr-00 From: Alia Atlas To: rtgwg@ietf.org, draft-li-rtgwg-igp-ext-mrt-frr@tools.ietf.org Content-Type: multipart/alternative; boundary=14dae934112d87101004d53b7050 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: Fri, 08 Feb 2013 19:19:36 -0000 --14dae934112d87101004d53b7050 Content-Type: text/plain; charset=ISO-8859-1 I have read through this draft and have a number of comments. First, to simplify the signaling needed and reduce on-the-fly checking and computation of an MRT island, it would be preferable to have "well-known profiles" represented by particular flags. A profile that would be useful is something like: Blue MRT MT-ID: X Red MRT MT-ID: Y Supported Algorithm: lowpoint inheritance GADAG selection: highest router ID encapsulation: IP in LDP fast-reroute supported for: IPv4, IPv6, and LDP That would be a good profile for unicast - and minimize the options and determination for an MRT island. We'll need something similar for multicast fast-reroute and multicast live-live. Having a detailed sub-TLV that gives the detailed options may be useful in the future, if there is disagreement on what are appropriate profiles. I can see having a bit indicating that the details supported are given in the sub-TLV for the future. The Algorithm ID should be a value and not a bit-flag. If there are multiple bits set, then clear rules need to be given as to which algorithm would be picked and why. In general, if multiple profiles are specified or multiple options, the draft needs to give a clear algorithm for what and how an MRT island is created. Certainly, MRT needs ISIS and OSPF extensions to define the signaling, but I find this draft a bit naive in simply taking what is in the draft-ietf-rtgwg-mrt-frr-architecture and turning it into the protocol parts without fully thinking through the implications and rules to be used. Alia --14dae934112d87101004d53b7050 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have read through this draft and have a number of comments.

    First, to simplify the signaling needed and reduce on-the-fly checkin= g and computation of an MRT island,
    it would be preferable to hav= e "well-known profiles" represented by particular flags. =A0A pro= file that would be
    useful is something like:
    =A0 =A0 =A0 Blue MRT MT-ID: =A0X
    =A0 =A0 =A0 Red MRT MT-ID: =A0 Y
    =A0 =A0 =A0 Supported A= lgorithm: =A0lowpoint inheritance
    =A0 =A0 =A0 GADAG selection: = =A0highest router ID
    =A0 =A0 =A0 encapsulation: =A0IP in LDP
    =A0 =A0 =A0 fast-reroute = supported for: =A0IPv4, IPv6, and LDP

    That would b= e a good profile for unicast - and minimize the options and determination f= or an MRT island.
    We'll need something similar for multicast fast-reroute and multic= ast live-live.

    Having a detailed sub-TLV that give= s the detailed options may be useful in the future, if there is disagreemen= t=A0
    on what are appropriate profiles. =A0I can see having a bit indicating= that the details supported are given in the
    sub-TLV for the futu= re.

    The Algorithm ID should be a value and not a b= it-flag. =A0If there are multiple bits set, then clear rules need to be
    given as to which algorithm would be picked and why. =A0
    In general, if multiple profiles are specified or multiple opti= ons, the draft needs to give a clear algorithm for
    what and how a= n MRT island is created.

    Certainly, MRT needs ISIS and OSPF extensions to define= the signaling, but I find this draft a bit naive in
    simply takin= g what is in the=A0draft-ietf-rtgwg-mrt-frr-architecture=A0an= d turning it into the protocol parts without
    fully thinking through the implications and rules to be used.

    Alia
    --14dae934112d87101004d53b7050-- From akatlas@gmail.com Fri Feb 8 12:14:48 2013 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 9CED521F8886 for ; Fri, 8 Feb 2013 12:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.678 X-Spam-Level: X-Spam-Status: No, score=-2.678 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygLvnhlN-thQ for ; Fri, 8 Feb 2013 12:14:47 -0800 (PST) Received: from mail-ia0-x22b.google.com (ia-in-x022b.1e100.net [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1C10B21F8794 for ; Fri, 8 Feb 2013 12:14:47 -0800 (PST) Received: by mail-ia0-f171.google.com with SMTP id z13so4687757iaz.30 for ; Fri, 08 Feb 2013 12:14:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=jr0iMJ/P/Fz2OZNDEvrOqOeh1wAB1cY8x1bkg5vCAxk=; b=ignvMdbvuLBQIzUGjhH9JwU1zm+KZ4IoSXY5WWqisB2mFMpyr2+Xld8d+ohwL+DYhX FfHcI0VT5m3fLSoGa43f8RsKof0MhQsTJNm5kQzH83mqW3o+PaymBCX6evkVgTX+0hHt C2kAXmzfFqsJbY73xI6850mSKWLX5SiAM/vuoNMRnmZTx5ZHvOKZ/u6kGOGIno4Fi1h4 Ic0zSP7cGNn9bZD1TZzqT6kI7nifrNoHbBB0OCDCGhapmIPXtFoA1fytHv/j5y9AD6nJ Q96ogoBc2twPeV4UFSTEUVriVb5g6n1iaKC37u0q2Gw1TiXPSmXIyDyO0N6RJIyuTx3W +n5w== MIME-Version: 1.0 X-Received: by 10.50.56.141 with SMTP id a13mr5163940igq.24.1360354486576; Fri, 08 Feb 2013 12:14:46 -0800 (PST) Received: by 10.64.34.203 with HTTP; Fri, 8 Feb 2013 12:14:46 -0800 (PST) Date: Fri, 8 Feb 2013 15:14:46 -0500 Message-ID: Subject: comments on draft-li-rtgwg-ldp-mt-mrt-frr From: Alia Atlas To: draft-li-rtgwg-ldp-mt-mrt-frr@tools.ietf.org, rtgwg@ietf.org Content-Type: multipart/alternative; boundary=f46d0401f53df0e81f04d53c35a3 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: Fri, 08 Feb 2013 20:14:48 -0000 --f46d0401f53df0e81f04d53c35a3 Content-Type: text/plain; charset=ISO-8859-1 I've done a read through on this draft and have the following comments: In Sec 3.1: "If there is no secondary route of LFA, the blue topology is preferred since it can be protected again by the red topology." This is incorrect. Please read the more recent draft-ietf-rtgwg-mrt-frr-architecture and draft-enyedi-rtgwg-mrt-frr-algorithm ; the method for computing which of the blue and red MRT to use as the alternate is clearly specified. The idea of failing from the blue topology to the red was only in the very initial work - since then Gabor figured out (and I've verified in an analysis tool) how to precompute whether the blue or red provides protection. Similarly, in Sec 3.3: "For the blue topology, the secondary label forwarding entry is created according to the secondary route in the red topology." Again, the blue topology routes do not have alternates. Neither do the red topology. Only the primary SPF topology has alternates. In Sec 3.4, the reason to delay installing new MRT routes is NOT because of slowing down the SPF topology reconvergence, but rather because the MRT topologies are carrying traffic and shouldn't be disrupted until the new SPF routes are installed everywhere so that traffic is moved off of the MRT topologies. In Sec 3.5, do you anticipate that LDP will be running in other than Downstream Unsolicited Liberal Label Retention mode? In that mode, the necessary labels should already be learned. In Sec 3.6 "IGP MT and LDP MT", I'm not sure what point you are trying to make. Is it that in OSPF, different link topologies are used for IPv4 and IPv6 and therefore different MT-IDs should be used as well -i.e. a Blue IPv6 MT-ID and a Blue IPv4 MT-ID? In as much as MT-IDs are used by the IGP, they would be associated just with loopback addresses - which could clearly be either IPv4 or IPv6 to disambiguate. For LDP, both types of FECs can use the same MT-ID. Do you see other issues here? Using well-known and reserved MT-IDs for MRT makes the most sense to me - ones that are the same for the IGP and LDP. Rather than discussing the issues, I'd specify the desired solution and reasoning for why it works well. In Sec 3.7 "Multiple IGP", I do know that running multiple IGPs is not uncommon. I don't see a reason why this causes a problem with MRT. If one assumes there are consistent rules for which IGP provides a route across the network, those same rules can be used to populate the MRT topologies. Can you clarify a scenario where this would not apply or be sufficient? In Sec 3.8 "Label Space", certainly MRT requires additional LDP labels - but how many depends on whether per-prefix FECs are advertised and on whether LDP traffic as well as IP traffic needs to be protected. In Sec 3.9 "Proxy Egress", it says: "In several scenarios where MRT FRR is deployed, proxy egress LSPs have to be setup by LDP. The proxy egress LSP maybe not end-to-end to bear VPN service in the network." I am unclear on what you are talking about here. In the computation, there are proxy nodes to represent FECs outside the local area/level; in the actual usage, there are no additional LDP labels needed. Instead, the appropriate Blue or RED label for the actual node transited to reach the proxy egress node should be used. In other words, if a proxy egress is connected to ABR-1 and ABR-2 and the Blue MRT goes through ABR-1 and the Red MRT goes through ABR-2 to reach the proxy egress, the Blue MRT label advertised by ABR-1 for that FEC would be used. In Sec 3.11, it's good to see thought about LDP DoD mode - but the required labels for the blue and red MRT topologies would have to be requested in advance of the failure to provide useful protection. I'm unclear on what you mean by "The difference from LDP DU is that there is no label distributed for the secondary route calculated in the default topology. The label forwarding entry in the blue topology or the red topology will be used as the secondary one directly." In Sec 4.1, I'm not sure which algorithm you used to compute or what the GADAG was. Rather than making assumptions about link costs, it'd be much better to just show the ones used. Also, it says: "From the above calculation example, we can see that how the tie- breaking rule has to be applied when choose the nexthop in a specific topology and the topology which is used for the secondary route. For the reason of simplicity, there is no LFA calculation for the secondary route. If exists, it should be preferred." If there are multiple options for the Blue MRT next-hops, then it's just like ECMP - the router can pick all of them or any one without causing difficulty. I've already talked about the rule for picking the correct topology for the alternate. In Sec 4.1, I personally find the example with the labels and the associated LFIB to be quite hard to follow. Perhaps using actual label values would help? What is interesting/special for MRT is handling label distribution at area/level boundaries. In Sec 4.4, it says "In order to optimize the second mechanism,when the penultimate router receive a packet with MRT label, it can swap the label to corresponding FEC's default topology label instead of penultimate hop pop." That is exactly what is said in Sec 8 of draft-ietf-rtgwg-mrt-frr-architecture-01 "The penultimate router can determine that the ABR/LBR will forward the packet out of area/level and, in that case, the penultimate router can remove the MRT marking but still forward the packet along the MRT next-hop to reach the ABR." However, the first mechanism where the ABR/LBR provides different LDP labels to the different areas/levels is STRONGLY preferred. It avoids the need for all neighboring routers to understand and recompute what area/level the ABR/LBR has selected - and all the associated interoperability problems that could come from that. In Sec 4.4, it talks about label distribution to/from a proxy node! This makes no sense to me. The proxy node is there for the MRT graph algorithm to run - it isn't instantiated by one of the routers. I'm sure you're trying to make a point here, but I do not understand it. In Sec 4.5, again there's the idea that the proxy node has to have labels advertised to and from it. I believe that the border routers of the MRT island can properly install the next-hop to outside the MRT island as computed based on whether the packet is received with the Blue label or the Red label. Can you clarify what you are concerned about in Sec 4.6? Nodes that don't support LDP and are hidden from the IGP topology by TE links don't need to support MRT at all... In general, what I see lacking in this draft is anything specifying the extensions, algorithms or methods needed to support MRT using LDP?? I can see the usefulness of something that references the LDP multi-topology draft and defines the necessary behavior for MRT support. I can see the need to potentially advertise capabilities... I do see that this draft is intended for Informational, but I'm not personally seeing what areas you feel it is significantly amplifying from what is in draft-ietf-rtgwg-mrt-frr-architecture. Regards, Alia --f46d0401f53df0e81f04d53c35a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've done a read through on this draft and have the following comments:=

    In Sec 3.1: "= If there is no secondary route of LFA, the blue topology is preferred since it can be protected again by t= he red topology."
    This is incorrect. Please read t= he more recent draft-ietf-rtgwg-mrt-frr-architecture= =A0and=A0draft-enyedi-rtgwg-mrt-frr-algorithm;
    the method for computing which of the blue and red MRT to use as the a= lternate is clearly specified. =A0The idea of failing from the blue
    topology to the red was only in the very initial work - since then Gabor= figured out (and I've verified in an analysis tool) how to precompute<= /div>
    whether the blue or red provides protection.

    = Similarly, in Sec 3.3: "For the blue topology, the secondary lab= el forwarding entry is created = according to the secondary route in the red topology."
    Again, the blue topology routes d= o not have alternates. Neither do the red topology. Only the primary SPF = topology has alternates.

    In Sec 3.4, the reas= on to delay installing new MRT routes is NOT because of slowing down the SP= F topology reconvergence, but rather because
    the MRT topologies are carrying traffic and shoul= dn't be disrupted until the new SPF routes are installed everywhere so = that traffic is moved off of
    the MRT topologies.
    <= div>
    In Sec 3.5, do you anticipate that LDP will be ru= nning in other than Downstream Unsolicited Liberal Label Retention mode? I= n that mode, the necessary labels should already be learned.

    In Sec 3.6 "IGP MT and LDP MT", I'm= not sure what point you are trying to make. Is it that in OSPF, different= link topologies are used for IPv4 and IPv6 and therefore different MT-IDs = should be used as well -i.e. a Blue IPv6 MT-ID and a Blue IPv4 MT-ID? In a= s much as MT-IDs are used by the IGP, they would be associated just with lo= opback addresses - which could clearly be either IPv4 or IPv6 to disambigua= te. For LDP, both types of FECs can use the same MT-ID. Do you see othe= r issues here? Using well-known and reserved MT-IDs for MRT makes the most= sense to me - ones that are the same for the IGP and LDP. Rather than dis= cussing the issues, I'd specify the desired solution and reasoning for = why it works well.

    In Sec 3.7 "Multiple IGP", I do know that running multiple IGPs is not= uncommon. I don't see a reason why this causes a problem with MRT. I= f one assumes there are consistent rules for which IGP provides a route acr= oss the network, those same rules can be used to populate the MRT topologie= s. Can you clarify a scenario where this would not apply or be sufficient?=

    In Sec 3.8 "Label Space", certainly MRT requires additional LDP labels= - but how many depends on whether per-prefix FECs are advertised and on wh= ether LDP traffic as well as IP traffic needs to be protected.

    In Sec 3.9 "Proxy Egress",= it says: "In several scen= arios where MRT FRR is deployed, proxy egress LSPs have to be setup by LDP. The proxy egress LSP maybe no= t end-to-end to bear VPN servic= e in the network." I am unclear on what you are talking about here. = In the computation, there are proxy nodes to represent FECs outside the loc= al area/level; in the actual usage, there are no additional LDP labels need= ed. Instead, the appropriate Blue or RED label for the actual node transit= ed to reach the proxy egress node should be used. In other words, if a pro= xy egress is connected to ABR-1 and ABR-2 and the Blue MRT goes through ABR= -1 and the Red MRT goes through ABR-2 to reach the proxy egress, the Blue M= RT label advertised by ABR-1 for that FEC would be used.

    In Sec 3.11, it's good to see thought about L= DP DoD mode - but the required labels for the blue and red MRT topologies w= ould have to be requested in advance of the failure to provide useful prote= ction. I'm unclear on what you mean by "The difference from LDP DU is that there is no label distributed for the secondary rout= e calculated in the default top= ology. The label forwarding entry in the blue topology or the red topology will be used as the secondary = one directly."

    In Sec 4.1, I'm not sure which algorithm you = used to compute or what the GADAG was. Rather than making assumptions abou= t link costs, it'd be much better to just show the ones used. Also, it= says: "From the above cal= culation example, we can see that how the tie- breaking rule has to be applied when choose the nexthop in = a specific topology and the top= ology which is used for the secondary route. For the reason of simplicity, there is no LFA calculation fo= r the secondary route. If exis= ts, it should be preferred." If there are multiple options for the Bl= ue MRT next-hops, then it's just like ECMP - the router can pick all of= them or any one without causing difficulty. I've already talked about= the rule for picking the correct topology for the alternate.

    In Sec 4.1, I personally find the example with th= e labels and the associated LFIB to be quite hard to follow. Perhaps using= actual label values would help? What is interesting/special for MRT is ha= ndling label distribution at area/level boundaries.

    In Sec 4.4, it says "In order to optimize the second mechanism,when the penultimate router receive a packe= t with MRT label, it can swap t= he label to corresponding FEC's default topology label instead <= span style=3D"white-space:pre-wrap">of penultimate hop pop." That is = exactly what is said in Sec 8 of draft-ietf-rtgwg-mrt-frr-architecture-01 &= quot;The penultimate router=A0<= span style=3D"font-size:1em">can determine that the ABR/LBR will forward th= e packet out of area/level and, in tha= t case, the penultimate router can remove the MRT=A0marking but still forward the packet along the MRT next-hop t= o reach=A0the ABR." However, the first mechanism where the ABR/= LBR provides different LDP labels to the different areas/levels is STRONGLY= preferred. It avoids the need for all neighboring routers to understand a= nd recompute what area/level the ABR/LBR has selected - and all the associa= ted interoperability problems that could come from that.

    In Sec 4.4, it talks about label distribution to/= from a proxy node! This makes no sense to me. The proxy node is there for= the MRT graph algorithm to run - it isn't instantiated by one of the r= outers. I'm sure you're trying to make a point here, but I do not = understand it.

    In Sec 4.5, again there's the idea that the p= roxy node has to have labels advertised to and from it. I believe that the= border routers of the MRT island can properly install the next-hop to outs= ide the MRT island as computed based on whether the packet is received with= the Blue label or the Red label.

    Can you clarify what you are concerned about in S= ec 4.6? Nodes that don't support LDP and are hidden from the IGP topol= ogy by TE links don't need to support MRT at all...

    In general, what I see lacking in this draft is a= nything specifying the extensions, algorithms or methods needed to support = MRT using LDP?? I can see the usefulness of something that references the = LDP multi-topology draft and defines the necessary behavior for MRT support= . I can see the need to potentially advertise capabilities... I do see t= hat this draft is intended for Informational, but I'm not personally se= eing what areas you feel it is significantly amplifying from what is in=A0<= /span>draft-ietf-rtgwg-mrt-frr-archite= cture.

    Regards,
    Alia
    --f46d0401f53df0e81f04d53c35a3-- From curtis@occnc.com Fri Feb 8 12:15:58 2013 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 CC30A21F8886 for ; Fri, 8 Feb 2013 12:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.397 X-Spam-Level: X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbJaD-VwDwN6 for ; Fri, 8 Feb 2013 12:15:57 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 7E31021F8B9B for ; Fri, 8 Feb 2013 12:15:57 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r18KDKah043185; Fri, 8 Feb 2013 15:13:23 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302082013.r18KDKah043185@gateway1.orleans.occnc.com> To: Tony Li From: Curtis Villamizar Subject: Re: Power aware networks : Comments requested from routing community In-reply-to: Your message of "Fri, 08 Feb 2013 00:48:02 PST." <8F1F25B1-F519-4D13-82CA-583597F7AE7B@tony.li> Date: Fri, 08 Feb 2013 15:13:20 -0500 Cc: Shankar Raman M J , 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: Fri, 08 Feb 2013 20:15:59 -0000 In message <8F1F25B1-F519-4D13-82CA-583597F7AE7B@tony.li> Tony Li writes: > > On Feb 8, 2013, at 12:25 AM, Hannes Gredler wrote: > > > tony, > > > > agree that saving power is a worthwhile goal; > > > > in fact existing hardware technology is making that happen today by > > e.g. automatically shutting down unused lookup engines, CPU cores, memory banks etc. > > when there is low processing demand. > > > > the part where i am not yet convinced is that additional off-peak "optimization" of > > infrastructure links by e.g. computing a routing mesh which only uses > > 70% of the nominal links does actually give much power savings. > > > > note that line cards which are running at 70% have already throttled down their > > power consumption - so what is the point emptying the link and loading another ? > > appears to me a zero sum game. > > > > my concern about the core (and SP edge) is not about business or technology - > > it is more about if we try to optimize an already optimized (and solved) problem. > > > If there are no more optimizations to be had, then talking about it > isn't going to hurt anything. > > The point of emptying links is the ability to turn off NPUs (50-100W > ea.), turn off edge optics (2-20W ea.) and most importantly turn off > long-haul optics (100-400W ea.). Yes, I realize that the latter part > is really problematic because DWDM systems are balanced with all > lambdas active, and that disabling any one of them can cause issues > with other lambdas. > > Still, it would be nice to understand what CAN be done, if only to > feel like we've truly explored every corner in the solution space and > exhausted every option. > > Tony Tony, It may be that the industry is already doing what they can but for a completely different reason that CO2 emissions. The reason is getting more capacity in not much more space and power. Network capacity grows exponentially, about a decimal order of magnitude in 5-8 years is a reasonable estimate (circa 2000 up to 10G IP core links, circa 2012 approaching 1T IP core links, transport capacities of 3.2T to 8T per fiber). Each generation of equipment replaces a row of racks with a rack or less of the same capacity at far less power per bit. As each generation ages, the row of racks fills again and the cycle repeats. The older stuff used to be redeployed further out from the core in edge, but I'm not sure if that occurs as much anymore (the older stuff may simply be retired now). This is true of IP/MPLS and transport. Given the goal of replacing existing space and power footprint with 5-10 times the capacity, it is space density and peak power density that has been the focus. The key question after "do we need to look at leasing more space or relocating the facility" has been "are the power feeds and the AC going to need to be upgraded and is that feasible". Operating power has been a secondary concern. Operating power is a secondary concern, but it dictates the power bill, and therefore is a big part of the OpEx equation. Secondary doesn't mean ignored, and given both big power bills and potential political presure due to having multiple facilities requiring 100s of KW the problem is not being ignored. OTOH - the datacenters of content providers and the Internet exchanges, requiring many MW of power have even more incentive to think about operating power. A useful question is, if equipment vendors and providers placed a greater focus on operating power, how much could be gained and what are the best means of doing so. The question is really not whether in theory a routing or TE based approach can make gains in a hypothetic network, it is whether it is worthwhile approach given how networks are actually built and where the power actually goes. This is assuming a solution before understanding the problem, and IMHO it is starting off with a poor solution. Anyone who thinks the industry does not look at this problem, can look to past NANOG presentations. Most have focused on data centers and IXP. At least one specifically on core routers, but appealing to relax NEBS temperatures and sustained PPS rates to reduce power http://www.nanog.org/meetings/nanog54/presentations/Wednesday/Wobker.pdf This has good info on slides 11 and 12. An interesting point is on slide 10 "cooling 1 slot ~= cooling ALL slots" (reason is airflow past cooling fins has to be maintained at a given rate per ambient temp). Curtis From curtis@occnc.com Fri Feb 8 13:13:13 2013 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 9105B21F8AE6 for ; Fri, 8 Feb 2013 13:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pb-9QWMAZKM for ; Fri, 8 Feb 2013 13:13:13 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id D6AEC21F8AB1 for ; Fri, 8 Feb 2013 13:13:12 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r18LAa53057615; Fri, 8 Feb 2013 16:10:37 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302082110.r18LAa53057615@gateway1.orleans.occnc.com> To: Mingui Zhang From: Curtis Villamizar Subject: Re: Power aware networks : Comments requested from routing community In-reply-to: Your message of "Fri, 08 Feb 2013 09:33:13 GMT." <4552F0907735844E9204A62BBDD325E732AFF5D5@nkgeml508-mbx.china.huawei.com> Date: Fri, 08 Feb 2013 16:10:36 -0500 Cc: Shankar Raman M J , "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: Fri, 08 Feb 2013 21:13:13 -0000 In message <4552F0907735844E9204A62BBDD325E732AFF5D5@nkgeml508-mbx.china.huawei.com> Mingui Zhang writes: > Hannes, > > That's the dream of line-card hardware manufactures. If the hardware > is 100% power proportional, then PANET will become useless. > > However, the practice is that only 10%-15% power proportional is > possible, which means a high 85%-90% of baseline power is being wasted > when there is few traffic. > > Thanks, > Mingui Is this a measured value, and if so, measured on what type of equipment? That seems to me to indicate very high leakage power in an NPU or ASIC if the NPU and ASIC is 50% or more of board power. Did you mean to say that an idle card runs at 85-90% of the power that it would run at with a full packet load? AFAIK only certain types of logic blocks like SRAM have high ratio of leakage to active power. Plain old logic gates have a high active to leakage ratio and for a given logic block you need to know what percentage of the gates tend to be in an active state at any given time. TCAM, when in use, has a very high active power because almost all the gates, except those in disabled banks, go active when doing a TCAM lookup. I'm not an ASIC designer, far from it, but I've reviewed the results of ASIC designers going through this power estimation exercise. If I remember correctly, active power was higher than leakage overall for NPU and other ASIC used in routers and transport. Active power is important enough that chips draw more power and run hotter when testing with small packet loads that with a larger average packet size (the so called Intenet mix or IMIX testing). I remember having a conversation with a chip vendor about the likelyhood of anyone doing a continuous 40 byte packet test at max NEBS temps and whether the intersection of those two requirements was needed. Curtis From curtis@occnc.com Fri Feb 8 13:44:38 2013 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 4E35721F8B61 for ; Fri, 8 Feb 2013 13:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjTovy6-T1rD for ; Fri, 8 Feb 2013 13:44:37 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id EA75E21F8B6E for ; Fri, 8 Feb 2013 13:44:36 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r18Lg0ei060320; Fri, 8 Feb 2013 16:42:00 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302082142.r18Lg0ei060320@gateway1.orleans.occnc.com> To: John E Drake From: Curtis Villamizar Subject: Re: Power aware networks : Comments requested from routing community In-reply-to: Your message of "Fri, 08 Feb 2013 13:26:42 GMT." <0182DEA5604B3A44A2EE61F3EE3ED69E1451519F@BL2PRD0510MB349.namprd05.prod.outlook.com> Date: Fri, 08 Feb 2013 16:42:00 -0500 Cc: Shankar Raman , "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: Fri, 08 Feb 2013 21:44:38 -0000 In message <0182DEA5604B3A44A2EE61F3EE3ED69E1451519F@BL2PRD0510MB349.namprd05.prod.outlook.com> John E Drake writes: > > http://patft.uspto.gov/netacgi/nph-Parser?Sect1=3DPTO1&Sect2=3DHITOFF&d=3DP= > ALL&p=3D1&u=3D%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=3D1&f=3DG&l=3D50&s1=3D71625= > 72.PN.&OS=3DPN/7162572&RS=3DPN/7162572 > > Irrespectively Yours, > > John John, Thanks. A better TCAM. If anything the bashing of conventional TCAM in the background reinforces what I said about TCAM being power pigs. There are many disadvantages with the conventional ternary CAM structure, however. Since each cell contains two memory cells, and a mask-and-compare circuit, implementation of a table of size w.times.2.sup.n requires w.times.2.sup.n+1 memory elements, and w.times.2.sup.n mask-and-compare circuits. Since every lookup in the table requires the activation of all the cells, power consumption is proportional to w.times.2.sup.n. For large values of n, the cost is considerable, and the power consumption is prohibitive. I'm quite sure radix trie is still more power efficient. A 4 bit radix trie (16 entry tables doing four binary radix trie operations at once) requires a maximum of 8 SRAM lookups, seldom more than 6, and often 4 or less. This can be pipelined using separate SRAM blocks per radix trie stage. Other highly creative lookup techniques exist. Curtis From jdrake@juniper.net Fri Feb 8 13:52:15 2013 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 0283521F8C2A for ; Fri, 8 Feb 2013 13:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.053 X-Spam-Level: X-Spam-Status: No, score=-3.053 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znvYUxrSymtU for ; Fri, 8 Feb 2013 13:52:14 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED7221F8BD4 for ; Fri, 8 Feb 2013 13:52:14 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKURVzjU+fcBT/oz19cK/NAdxSvs7WgFGl@postini.com; Fri, 08 Feb 2013 13:52:14 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 8 Feb 2013 13:50:59 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 8 Feb 2013 13:50:58 -0800 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.139) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 8 Feb 2013 13:52:51 -0800 Received: from mail35-db3-R.bigfish.com (10.3.81.233) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Feb 2013 21:50:56 +0000 Received: from mail35-db3 (localhost [127.0.0.1]) by mail35-db3-R.bigfish.com (Postfix) with ESMTP id 9EFA12E02D5 for ; Fri, 8 Feb 2013 21:50:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -21 X-BigFish: PS-21(zz9371I542I1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dh74efjz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received: from mail35-db3 (localhost.localdomain [127.0.0.1]) by mail35-db3 (MessageSwitch) id 1360360254979519_25801; Fri, 8 Feb 2013 21:50:54 +0000 (UTC) Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.248]) by mail35-db3.bigfish.com (Postfix) with ESMTP id EC39622005B; Fri, 8 Feb 2013 21:50:54 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Feb 2013 21:50:54 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.189]) by BL2PRD0510HT003.namprd05.prod.outlook.com ([10.255.100.38]) with mapi id 14.16.0263.000; Fri, 8 Feb 2013 21:50:52 +0000 From: John E Drake To: "curtis@occnc.com" Subject: RE: Power aware networks : Comments requested from routing community Thread-Topic: Power aware networks : Comments requested from routing community Thread-Index: AQHOBkUg9fL6dxa9R06j94m+9aozuZhwf0xQ Date: Fri, 8 Feb 2013 21:50:51 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E14515F52@BL2PRD0510MB349.namprd05.prod.outlook.com> References: Your message of "Fri, 08 Feb 2013 13:26:42 GMT." <0182DEA5604B3A44A2EE61F3EE3ED69E1451519F@BL2PRD0510MB349.namprd05.prod.outlook.com> <201302082142.r18Lg0ei060320@gateway1.orleans.occnc.com> In-Reply-To: <201302082142.r18Lg0ei060320@gateway1.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%OCCNC.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Shankar Raman , "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: Fri, 08 Feb 2013 21:52:15 -0000 Curtis, What I heard before joining Juniper was that they were quite happy that Cis= co made this acquisition because they don't use TCAM and they thought Cisco= wasted a lot of money on a suboptimal technology.=20 Irrespectively Yours, John > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@occnc.com] > Sent: Friday, February 08, 2013 1:42 PM > To: John E Drake > Cc: Balaji venkat Venkataswami; Eric Osborne (eosborne); Shankar Raman; > rtgwg@ietf.org > Subject: Re: Power aware networks : Comments requested from routing > community >=20 >=20 > In message > <0182DEA5604B3A44A2EE61F3EE3ED69E1451519F@BL2PRD0510MB349.namprd05.prod > .outlook.com> > John E Drake writes: > > > > http://patft.uspto.gov/netacgi/nph- > Parser?Sect1=3D3DPTO1&Sect2=3D3DHITOFF& > > d=3D3DP=3D > > > ALL&p=3D3D1&u=3D3D%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=3D3D1&f=3D3DG&l=3D3D5= 0&s1=3D3D > > 71625=3D > > 72.PN.&OS=3D3DPN/7162572&RS=3D3DPN/7162572 > > > > Irrespectively Yours, > > > > John >=20 >=20 > John, >=20 > Thanks. A better TCAM. If anything the bashing of conventional TCAM > in the background reinforces what I said about TCAM being power pigs. >=20 > There are many disadvantages with the conventional ternary CAM > structure, however. Since each cell contains two memory cells, and a > mask-and-compare circuit, implementation of a table of size > w.times.2.sup.n requires w.times.2.sup.n+1 memory elements, and > w.times.2.sup.n mask-and-compare circuits. Since every lookup in the > table requires the activation of all the cells, power consumption is > proportional to w.times.2.sup.n. For large values of n, the cost is > considerable, and the power consumption is prohibitive. >=20 > I'm quite sure radix trie is still more power efficient. >=20 > A 4 bit radix trie (16 entry tables doing four binary radix trie > operations at once) requires a maximum of 8 SRAM lookups, seldom more > than 6, and often 4 or less. This can be pipelined using separate SRAM > blocks per radix trie stage. Other highly creative lookup techniques > exist. >=20 > Curtis From jdrake@juniper.net Fri Feb 8 13:56:03 2013 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 F19AD21F8BB7 for ; Fri, 8 Feb 2013 13:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.104 X-Spam-Level: X-Spam-Status: No, score=-3.104 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkc+GMqhjArj for ; Fri, 8 Feb 2013 13:56:03 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 279C521F89FC for ; Fri, 8 Feb 2013 13:56:03 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKURV0bSt5HzdQNKlzc7s7Kip0VDIPnl7W@postini.com; Fri, 08 Feb 2013 13:56:03 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 8 Feb 2013 13:54:14 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 8 Feb 2013 13:54:13 -0800 Received: from TX2EHSOBE010.bigfish.com (65.55.88.13) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 8 Feb 2013 14:03:01 -0800 Received: from mail66-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Feb 2013 21:54:13 +0000 Received: from mail66-tx2 (localhost [127.0.0.1]) by mail66-tx2-R.bigfish.com (Postfix) with ESMTP id 211CD340154 for ; Fri, 8 Feb 2013 21:54:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -21 X-BigFish: PS-21(zz9371I542I1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dh74efjz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received: from mail66-tx2 (localhost.localdomain [127.0.0.1]) by mail66-tx2 (MessageSwitch) id 1360360451627790_27197; Fri, 8 Feb 2013 21:54:11 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.249]) by mail66-tx2.bigfish.com (Postfix) with ESMTP id 94F774A0082; Fri, 8 Feb 2013 21:54:11 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Feb 2013 21:54:09 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.189]) by BL2PRD0510HT003.namprd05.prod.outlook.com ([10.255.100.38]) with mapi id 14.16.0263.000; Fri, 8 Feb 2013 21:54:08 +0000 From: John E Drake To: John E Drake , "curtis@occnc.com" Subject: RE: Power aware networks : Comments requested from routing community Thread-Topic: Power aware networks : Comments requested from routing community Thread-Index: AQHOBkUg9fL6dxa9R06j94m+9aozuZhwf0xQgAABmrA= Date: Fri, 8 Feb 2013 21:54:07 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E14515F7F@BL2PRD0510MB349.namprd05.prod.outlook.com> References: Your message of "Fri, 08 Feb 2013 13:26:42 GMT." <0182DEA5604B3A44A2EE61F3EE3ED69E1451519F@BL2PRD0510MB349.namprd05.prod.outlook.com> <201302082142.r18Lg0ei060320@gateway1.orleans.occnc.com> <0182DEA5604B3A44A2EE61F3EE3ED69E14515F52@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E14515F52@BL2PRD0510MB349.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%OCCNC.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Shankar Raman , "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: Fri, 08 Feb 2013 21:56:04 -0000 Hi, My apologies. Please excuse what I meant to be a private comment. Irrespectively Yours, John > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > Of John E Drake > Sent: Friday, February 08, 2013 1:51 PM > To: curtis@occnc.com > Cc: Shankar Raman; rtgwg@ietf.org > Subject: RE: Power aware networks : Comments requested from routing > community >=20 > Curtis, >=20 > What I heard before joining Juniper was that they were quite happy that > Cisco made this acquisition because they don't use TCAM and they > thought Cisco wasted a lot of money on a suboptimal technology. >=20 > Irrespectively Yours, >=20 > John >=20 >=20 > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@occnc.com] > > Sent: Friday, February 08, 2013 1:42 PM > > To: John E Drake > > Cc: Balaji venkat Venkataswami; Eric Osborne (eosborne); Shankar > > Raman; rtgwg@ietf.org > > Subject: Re: Power aware networks : Comments requested from routing > > community > > > > > > In message > > > <0182DEA5604B3A44A2EE61F3EE3ED69E1451519F@BL2PRD0510MB349.namprd05.pro > > d > > .outlook.com> > > John E Drake writes: > > > > > > http://patft.uspto.gov/netacgi/nph- > > Parser?Sect1=3D3DPTO1&Sect2=3D3DHITOFF& > > > d=3D3DP=3D > > > > > > ALL&p=3D3D1&u=3D3D%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=3D3D1&f=3D3DG&l=3D3D5= 0&s1=3D3D > > > 71625=3D > > > 72.PN.&OS=3D3DPN/7162572&RS=3D3DPN/7162572 > > > > > > Irrespectively Yours, > > > > > > John > > > > > > John, > > > > Thanks. A better TCAM. If anything the bashing of conventional TCAM > > in the background reinforces what I said about TCAM being power pigs. > > > > There are many disadvantages with the conventional ternary CAM > > structure, however. Since each cell contains two memory cells, and > a > > mask-and-compare circuit, implementation of a table of size > > w.times.2.sup.n requires w.times.2.sup.n+1 memory elements, and > > w.times.2.sup.n mask-and-compare circuits. Since every lookup in > the > > table requires the activation of all the cells, power consumption > is > > proportional to w.times.2.sup.n. For large values of n, the cost is > > considerable, and the power consumption is prohibitive. > > > > I'm quite sure radix trie is still more power efficient. > > > > A 4 bit radix trie (16 entry tables doing four binary radix trie > > operations at once) requires a maximum of 8 SRAM lookups, seldom more > > than 6, and often 4 or less. This can be pipelined using separate > > SRAM blocks per radix trie stage. Other highly creative lookup > > techniques exist. > > > > Curtis >=20 >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From tony.li@tony.li Fri Feb 8 14:45:15 2013 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 0C23021F8B64 for ; Fri, 8 Feb 2013 14:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdPmaZ02fCtf for ; Fri, 8 Feb 2013 14:45:14 -0800 (PST) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA6221F8B48 for ; Fri, 8 Feb 2013 14:45:14 -0800 (PST) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta02.emeryville.ca.mail.comcast.net with comcast id xpY51k0080QkzPwA2ylE1z; Fri, 08 Feb 2013 22:45:14 +0000 Received: from [10.66.230.52] ([64.236.139.254]) by omta02.emeryville.ca.mail.comcast.net with comcast id xyiz1k0035VXD0o8Nyj1ZZ; Fri, 08 Feb 2013 22:43:12 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Power aware networks : Comments requested from routing community From: Tony Li In-Reply-To: <201302082013.r18KDKah043185@gateway1.orleans.occnc.com> Date: Fri, 8 Feb 2013 14:42:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <25E93247-2547-4E95-8A47-828F30A4D03C@tony.li> References: <201302082013.r18KDKah043185@gateway1.orleans.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360363514; bh=8fsA7aRT/4I1zV3t4IO4hcR6+of1GcBwLNN5SqxNElA=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=GrVg3BppdbU8AGqq34hg30inYQOh3cWppWe3qBxXPFu8+TEw6hae5L1Ngs6fVjbzd IAOAWLivlkNX3fwhwtmn30JUdWAdhwk0Vencum+p/DYuX3X0Ybk4voyEdSglX1xYrh 5Hqco9zg4p/PseQB4ZHluFATTBDTogXVDdm3F2KLXNNW2C726GnxJeSea015A7nrEB tYbUsckomTI8ovJ4+iIop4kmMiJ0LN0jGQsMfapGDXJH+ccqVwbBSaP9SYM+LgyeLx WmVfLrjGoJbAuKuTy5CYYMJXuhAxLsZO6R5UMRIm2EwedUKH6ABZXWw7Olxb14AhGU 2p0KVpuK0N0Fg== Cc: Shankar Raman M J , 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: Fri, 08 Feb 2013 22:45:15 -0000 On Feb 8, 2013, at 12:13 PM, Curtis Villamizar wrote: > The question is really not whether in theory a routing or TE based > approach can make gains in a hypothetic network, it is whether it is > worthwhile approach given how networks are actually built and where > the power actually goes. This is assuming a solution before > understanding the problem, and IMHO it is starting off with a poor > solution. Curtis, As you and I both know, there is a huge diurnal cycle to traffic, plus = macro cycles at the weekly period. Even with local power optimization = in place, our experience with traffic engineering alone suggests that = there are further, global optimizations that are possible. Again, I think that constraining our thinking to what is 'worthwhile' = today, at current power rates is shortsighted. We need to understand = what can be done, what the returns are, and only then, let various = operators judge as to whether it is of commercial interest to them or = not. Tony =20= From curtis@occnc.com Fri Feb 8 17:26:07 2013 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 97D8721F8C56 for ; Fri, 8 Feb 2013 17:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1gEHWsWTU0v for ; Fri, 8 Feb 2013 17:26:07 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 063E021F8C50 for ; Fri, 8 Feb 2013 17:26:06 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r191NWut061588; Fri, 8 Feb 2013 20:23:32 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302090123.r191NWut061588@gateway1.orleans.occnc.com> To: Tony Li From: Curtis Villamizar Subject: Re: Power aware networks : Comments requested from routing community In-reply-to: Your message of "Fri, 08 Feb 2013 14:42:58 PST." <25E93247-2547-4E95-8A47-828F30A4D03C@tony.li> Date: Fri, 08 Feb 2013 20:23:32 -0500 Cc: Shankar Raman M J , 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: Sat, 09 Feb 2013 01:26:07 -0000 In message <25E93247-2547-4E95-8A47-828F30A4D03C@tony.li> Tony Li writes: > > On Feb 8, 2013, at 12:13 PM, Curtis Villamizar wrote: > > > The question is really not whether in theory a routing or TE based > > approach can make gains in a hypothetic network, it is whether it is > > worthwhile approach given how networks are actually built and where > > the power actually goes. This is assuming a solution before > > understanding the problem, and IMHO it is starting off with a poor > > solution. > > > Curtis, > > As you and I both know, there is a huge diurnal cycle to traffic, plus > macro cycles at the weekly period. Even with local power optimization > in place, our experience with traffic engineering alone suggests that > there are further, global optimizations that are possible. > > Again, I think that constraining our thinking to what is 'worthwhile' > today, at current power rates is shortsighted. We need to understand > what can be done, what the returns are, and only then, let various > operators judge as to whether it is of commercial interest to them or > not. > > Tony Tony, I agree with that you said. What I was trying to get at was: 1. The discussion should be based on realistic assumptions. Discussions not based on realistic assumptions often turn out to be a waste of time. 2. The solution space should be within the range of deployable options. Discussions on many topics in the research world too often fails to adhere to these. The IRTF Routing Requirements WG is a good example, with the occasional proposals to completely replace routing with pet ideas and inability to stick to the deployable solution space. Curtis From tony.li@tony.li Fri Feb 8 17:33:51 2013 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 EB4A321F8C38 for ; Fri, 8 Feb 2013 17:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnZSIsUQ3Rqy for ; Fri, 8 Feb 2013 17:33:51 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 92F9A21F8BF6 for ; Fri, 8 Feb 2013 17:33:51 -0800 (PST) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta03.emeryville.ca.mail.comcast.net with comcast id xpi81k0070QkzPwA31ZrWA; Sat, 09 Feb 2013 01:33:51 +0000 Received: from [10.66.230.52] ([64.236.139.254]) by omta02.emeryville.ca.mail.comcast.net with comcast id y1Xc1k00h5VXD0o8N1XfV5; Sat, 09 Feb 2013 01:31:49 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Power aware networks : Comments requested from routing community From: Tony Li In-Reply-To: <201302090123.r191NWut061588@gateway1.orleans.occnc.com> Date: Fri, 8 Feb 2013 17:31:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201302090123.r191NWut061588@gateway1.orleans.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360373631; bh=O3r4UiEMUuYpOCaEEx1CuitFwbW61ROnWbw9bV52ftM=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=lJImweM5BbiFIuIDfOCCsEx5kAMTvD6LOgOqvd+Rs9rWgKscSDQd/TD6dQoZYRm/T C/TGUzUVZ5HGK2ko2AJ5xcW5HKUxSbcQyHh6cUshVHA/euMGfXcNftphUMx5+YCndI aw8M628HuSco3jEnb6CUdWsZUTTbcrFHvuGVQM4MPf5Vz5Ps+gms657d8PDvFBpa/I JVpj69TJmLsN1ITUj2X5R9x7WiZbF0JefiLzcKQ6gRZMdzasE9T75i7EFTaLmGtQRr URcCwQNz504VPxeOL2NKQIGn207v56flLUSOerDunYVF5N3RCrzqqcyE9swmju+vB4 2HH93ehwBHD9w== Cc: Shankar Raman M J , 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: Sat, 09 Feb 2013 01:33:52 -0000 > 1. The discussion should be based on realistic assumptions. > Discussions not based on realistic assumptions often turn out to > be a waste of time. >=20 > 2. The solution space should be within the range of deployable > options. >=20 > Discussions on many topics in the research world too often fails to > adhere to these. The IRTF Routing Requirements WG is a good example, > with the occasional proposals to completely replace routing with pet > ideas and inability to stick to the deployable solution space. Curtis, You're correct, we're generally in agreement except that we have = completely different expectations of what the words 'realistic' and = 'deployable' mean in a research context vs. an engineering context. I propose that we agree to disagree. Regards, Tony From zhangmingui@huawei.com Sun Feb 10 05:30:48 2013 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 6E67021F883C for ; Sun, 10 Feb 2013 05:30:48 -0800 (PST) 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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMYKFbSBrdOA for ; Sun, 10 Feb 2013 05:30:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 27B1821F883F for ; Sun, 10 Feb 2013 05:30:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOI18531; Sun, 10 Feb 2013 13:28:59 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 10 Feb 2013 13:28:14 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 10 Feb 2013 13:28:26 +0000 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.33]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Sun, 10 Feb 2013 21:28:14 +0800 From: Mingui Zhang To: "curtis@occnc.com" Subject: RE: PANET side-meeting Thread-Topic: PANET side-meeting Thread-Index: AQHOBiFXKuTqdHe8Bkmtrak3KqQ1B5hw9q4c Date: Sun, 10 Feb 2013 13:28:14 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E732AFF6E9@nkgeml508-mbx.china.huawei.com> References: Your message of "Fri, 08 Feb 2013 07:09:38 GMT." <4552F0907735844E9204A62BBDD325E732AFF460@nkgeml508-mbx.china.huawei.com>, <201302081725.r18HPpt3010162@gateway1.orleans.occnc.com> In-Reply-To: <201302081725.r18HPpt3010162@gateway1.orleans.occnc.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.99.192.164] Content-Type: multipart/alternative; boundary="_000_4552F0907735844E9204A62BBDD325E732AFF6E9nkgeml508mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Susan Hares , "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: Sun, 10 Feb 2013 13:30:48 -0000 --_000_4552F0907735844E9204A62BBDD325E732AFF6E9nkgeml508mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Curtis, Comments in-line below. Thanks, Mingui ________________________________________ From: Curtis Villamizar [curtis@occnc.com] Sent: Saturday, February 09, 2013 1:25 To: Mingui Zhang Cc: Tony Li; curtis@occnc.com; rtgwg@ietf.org; Susan Hares Subject: Re: PANET side-meeting In message <4552F0907735844E9204A62BBDD325E732AFF460@nkgeml508-mbx.china.hu= awei.com> Mingui Zhang writes: > Hi Tony and Curtis, > > Let me retrospect some history to clear up the chaos floating around. > > On Feb 4th, I organized a conference call among a dozen of guys (from > operators, vendors and Universities) who are interested in PANET, in > order to prepare for a side meeting in IETF. There was a rough > consensus that a side-meeting is a good way to call for interest, > coordination and contribution to PANET. However, requests was > _prematurely_ sent out afterwards, without including all the effort > from the conference attendees. I hope this email can get us back on > track. So I change its title. I could find no record of this in a google search. Nothing that seemed relevant for "PANET meeting", "PANET conference call", or "Power Aware Networking" other than IETF chatter and the already discussed academic papers. Is there any reference to this meeting? An closed ad-hoc conference call does not justify a new WG, even an IRTF WG. [zmg] We never argue this is a conference call justifies anything. No commi= tment is promised either. Would you care to say who attended the conference call and whether anyone took notes that could be shared? [zmg] I did record the conference (web and audio). However, the recording i= s currently shared only among guys who are interested in pushing PANET _for= ward_. As I said, they are from more than one communities. I will talk with= other attendees whether they feel it is proper to announce their names. An= yway, you can come to attend the side-meeting to grasp what was going on. Was this just among the authors of the docs sent to RTGWG? [If so, it would seem more like a Huawei internal meeting with a few guests.] [zmg] The situation was totally different as what you speculated. > I believe the most efficient way for us is to play the game according > to the rule of IETF/IRTF. Therefore, we are trying to find a place to > accommodate the side-meeting. We should not delve into discussion of > specific solutions before we make clear the problem scope. A charter > should be published, which will help us figure out what is the problem > we are trying to solve. Before that, let me add some pointers of > drafts from my side. I believe these drafts can also help people to > figure out the scope of PANET. Power-Aware Networks (PANET): Problem > Statement, > https://datatracker.ietf.org/doc/draft-zhang-panet-problem-statement/ > Use Cases for Power-Aware Networks, > https://datatracker.ietf.org/doc/draft-zhang-panet-use-cases/ > Requirements for Power Aware Network, > https://datatracker.ietf.org/doc/draft-dong-panet-requirement/ The usual way to do this formally in IETF is to request a BOF. Informally you can ask for a room or just get together at the bar (the venue of choice for an informal ad hoc BOF a decade or more ago). [zmg] Yes, you are right. Our target was a side-meeting (bar-BoF) and we ar= e trying to request a room. > On the 84th IETF rtgwg f2f meeting, there were two presentations > relevant to greening. I also list them as follows FYI. A Framework > and Requirements for Energy Aware Control Planes, > http://tools.ietf.org/html/draft-retana-rtgwg-eacp-00, [slides] > http://www.ietf.org/proceedings/84/slides/slides-84-rtgwg-3.pptx > Power-aware Routing and Traffic Engineering: Requirements, Approaches, > and Issues, https://datatracker.ietf.org/doc/draft-zhang-greennet/, > [slides] > http://www.ietf.org/proceedings/84/slides/slides-84-rtgwg-4.pptx > > Thanks, > Mingui Zhang > Huawei Technologies At IETF, no activity at all on the WG mailing list usually means not enough interest and therefore no advancement. I mentioned earlier on the prior thread that I had just quickly read draft-retana-rtgwg-eacp-00 and did not think this work was worth the IETF (or IRTF, if I can speak up in advance) in its current form. The topic might be worth considering, but the work seems to take a naive approach. Whether treating interfaces and links as a black box and using routing provides any appreciable gain in real networks remains to be proven. [zmg] I'd like to hear your _specific_ feedbacks on other drafts. [end of comments] These documents are trying to write requirements, build a framework, and specify protocols, all based on unproven assertions. If the work goes to IRTF, the first order of business must be to provide compelling proof or at least compelling argument that a specific approach will have benefit in *real* networks, not hypothetic networks, and not real topologies with a hypothetic network architecture (ie: choice of type of equipment and build out). Curtis > > -----Original Message----- > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf = Of > > Tony Li > > Sent: Friday, February 08, 2013 7:02 AM > > To: curtis@occnc.com > > Cc: Shankar Raman M J; rtgwg@ietf.org > > Subject: Re: Power aware networks : Comments requested from routing > > community > > > > > > On Feb 7, 2013, at 2:44 PM, Curtis Villamizar wrote: > > > > > I don't think this is even material ready for IRTF consideration, but > > > that is up to Tony and IRTF to decide. > > > > > > As always, the IRTF does not require well-formed ideas as a > > pre-requisite for starting work. Instead, there needs to be a clear > > problem statement (i.e., a charter) and a sufficient group of serious > > researchers who are committed to following through in a committed > > manner. > > > > Note that it is, by definition, research. It is expected to have a > > non-trivial likelihood of failure. > > > > Regards, > > Tony --_000_4552F0907735844E9204A62BBDD325E732AFF6E9nkgeml508mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Hi Curtis,

    Comments in-line below.

    Thanks,

    Mingui

    ________________________________________
    From: Curtis Villamizar [curtis@occnc.com]
    Sent: Saturday, February 09, 2013 1:25
    To: Mingui Zhang
    Cc: Tony Li; curtis@occnc.com; rtgwg@ietf.org; Susan Hares
    Subject: Re: PANET side-meeting

    In message <4552F0907735844E9204A62BBDD325E732AFF460@nkgeml508-mbx.china= .huawei.com>
    Mingui Zhang writes:

    > Hi Tony and Curtis,
    >
    > Let me retrospect some history to clear up the chaos floating around.<= br> >
    > On Feb 4th, I organized a conference call among a dozen of guys (from<= br> > operators, vendors and Universities) who are interested in PANET, in > order to prepare for a side meeting in IETF. There was a rough
    > consensus that a side-meeting is a good way to call for interest,
    > coordination and contribution to PANET. However, requests was
    > _prematurely_ sent out afterwards, without including all the effort > from the conference attendees. I hope this email can get us back on > track. So I change its title.

    I could find no record of this in a google search.  Nothing that
    seemed relevant for "PANET meeting", "PANET conference call&= quot;, or
    "Power Aware Networking" other than IETF chatter and the already<= br> discussed academic papers.  Is there any reference to this meeting?


    An closed ad-hoc conference call does not justify a new WG, even an
    IRTF WG.

    [zmg] We never argue this is a conference call justifies anything. No co= mmitment is promised either.

    Would you care to say who attended the conference call and whether
    anyone took notes that could be shared?

    [zmg] I did record the conference (web and audio). However, the recordin= g is currently shared only among guys who are interested in pushing PANET _= forward_. As I said, they are from more than one communities. I will t= alk with other attendees whether they feel it is proper to announce their names. Anyway, you can come to at= tend the side-meeting to grasp what was going on.

    Was this just among the authors of the docs sent to RTGWG?  [If so,= it
    would seem more like a Huawei internal meeting with a few guests.]

     

    [zmg] The situation was totally different as what you specul= ated.


    > I believe the most efficient way for us is to play the game according<= br> > to the rule of IETF/IRTF. Therefore, we are trying to find a place to<= br> > accommodate the side-meeting. We should not delve into discussion of > specific solutions before we make clear the problem scope. A charter > should be published, which will help us figure out what is the problem=
    > we are trying to solve. Before that, let me add some pointers of
    > drafts from my side. I believe these drafts can also help people to > figure out the scope of PANET.  Power-Aware Networks (PANET): Pro= blem
    > Statement,
    > https://datatracker.ietf.org/doc/draft-zhang-panet-problem-statement/<= br> > Use Cases for Power-Aware Networks,
    > https://datatracker.ietf.org/doc/draft-zhang-panet-use-cases/
    > Requirements for Power Aware Network,
    > https://datatracker.ietf.org/doc/draft-dong-panet-requirement/

    The usual way to do this formally in IETF is to request a BOF.
    Informally you can ask for a room or just get together at the bar (the
    venue of choice for an informal ad hoc BOF a decade or more ago).

    [zmg] Yes, you are right. Our target was a side-meeting (bar-BoF) and we= are trying to request a room.


    > On the 84th IETF rtgwg f2f meeting, there were two presentations
    > relevant to greening. I also list them as follows FYI.  A Framewo= rk
    > and Requirements for Energy Aware Control Planes,
    > http://tools.ietf.org/html/draft-retana-rtgwg-eacp-00, [slides]
    > http://www.ietf.org/proceedings/84/slides/slides-84-rtgwg-3.pptx
    > Power-aware Routing and Traffic Engineering: Requirements, Approaches,=
    > and Issues, https://datatracker.ietf.org/doc/draft-zhang-greennet/, > [slides]
    > http://www.ietf.org/proceedings/84/slides/slides-84-rtgwg-4.pptx
    >
    > Thanks,
    > Mingui Zhang
    > Huawei Technologies

    At IETF, no activity at all on the WG mailing list usually means not
    enough interest and therefore no advancement.

    I mentioned earlier on the prior thread that I had just quickly read
    draft-retana-rtgwg-eacp-00 and did not think this work was worth the
    IETF (or IRTF, if I can speak up in advance) in its current form.  The=
    topic might be worth considering, but the work seems to take a naive
    approach.  Whether treating interfaces and links as a black box and using routing provides any appreciable gain in real networks remains
    to be proven.

    [zmg] I'd like to hear your _specific_ feedbacks on other drafts.

    [end of comments]

     

     

     

     


    These documents are trying to write requirements, build a framework,
    and specify protocols, all based on unproven assertions.

    If the work goes to IRTF, the first order of business must be to
    provide compelling proof or at least compelling argument that a
    specific approach will have benefit in *real* networks, not hypothetic
    networks, and not real topologies with a hypothetic network
    architecture (ie: choice of type of equipment and build out).

    Curtis


    > > -----Original Message-----
    > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On B= ehalf Of
    > > Tony Li
    > > Sent: Friday, February 08, 2013 7:02 AM
    > > To: curtis@occnc.com
    > > Cc: Shankar Raman M J; rtgwg@ietf.org
    > > Subject: Re: Power aware networks : Comments requested from routi= ng
    > > community
    > >
    > >
    > > On Feb 7, 2013, at 2:44 PM, Curtis Villamizar <curtis@occnc.co= m> wrote:
    > >
    > > > I don't think this is even material ready for IRTF considera= tion, but
    > > > that is up to Tony and IRTF to decide.
    > >
    > >
    > > As always, the IRTF does not require well-formed ideas as a
    > > pre-requisite for starting work.  Instead, there needs to be= a clear
    > > problem statement (i.e., a charter) and a sufficient group of ser= ious
    > > researchers who are committed to following through in a committed=
    > > manner.
    > >
    > > Note that it is, by definition, research.  It is expected to= have a
    > > non-trivial likelihood of failure.
    > >
    > > Regards,
    > > Tony

    --_000_4552F0907735844E9204A62BBDD325E732AFF6E9nkgeml508mbxchi_-- From curtis@occnc.com Mon Feb 11 08:20:34 2013 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 A681121F8B1C for ; Mon, 11 Feb 2013 08:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ETDnJnxmCxY for ; Mon, 11 Feb 2013 08:20:34 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 04EE921F8B13 for ; Mon, 11 Feb 2013 08:20:33 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r1BGJCTH031475; Mon, 11 Feb 2013 11:19:12 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302111619.r1BGJCTH031475@gateway1.orleans.occnc.com> To: Mingui Zhang From: Curtis Villamizar Subject: Re: PANET side-meeting In-reply-to: Your message of "Sun, 10 Feb 2013 13:28:14 GMT." <4552F0907735844E9204A62BBDD325E732AFF6E9@nkgeml508-mbx.china.huawei.com> Date: Mon, 11 Feb 2013 11:18:32 -0500 Cc: "rtgwg@ietf.org" , Susan Hares 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: Mon, 11 Feb 2013 16:20:34 -0000 In message <4552F0907735844E9204A62BBDD325E732AFF6E9@nkgeml508-mbx.china.huawei.com> Mingui Zhang writes: > I mentioned earlier on the prior thread that I had just quickly read > draft-retana-rtgwg-eacp-00 and did not think this work was worth the > IETF (or IRTF, if I can speak up in advance) in its current form. The > topic might be worth considering, but the work seems to take a naive > approach. Whether treating interfaces and links as a black box and > using routing provides any appreciable gain in real networks remains > to be proven. > > [zmg] I'd like to hear your _specific_ feedbacks on other drafts. I have better things to do with my time than provide detailed review of drafts that are ill conceived and so do most of the people on the mailing list. Below is the list of drafts with comments on whether they are relevant. draft-mjsraman-panet-bgp-power-path draft-mjsraman-panet-ecmp-redirect-power-repl-cap draft-mjsraman-panet-inter-as-power-source draft-mjsraman-panet-inter-as-psp draft-mjsraman-panet-inter-as-psp-protect draft-mjsraman-panet-pce-power-mcast-replic draft-mjsraman-panet-pim-power draft-mjsraman-pce-power-replic draft-mjsraman-panet-intra-as-psp-te-leak draft-mjsraman-panet-ospf-power-topo These are all founded on the premise that there are significant gains that can result from routing that is aware of power disipation differences in hardware related to the traffic load placed on the hardware. The topic of the relevance of these drafts to RTGWG has just been discussed and the concensus seems to me to be that these are not relevant to RTGWG. The discussion so far has been to move all of this work to IRTF if IRTF wants to pursue this topic. draft-mjsraman-panet-tcam-power-efficiency draft-mjsraman-panet-tcam-power-ratio Alreadty discussed on list. Theee TCAM drafts are ill conceived and technically flawed. They should be dropped completely. There may be merit to doing work in this area but you are going about it entirely the wrong way. IMO you need to start with a BOF proposal with a brief problem statement and a charter to address the problem. No solution should be mentioned in the initial charter, with a detailed problem statement draft, requirements draft and framework draft. The outcome of this initial exercise would dictate what sort of solutions, if any, to pursue. For example, if any work is done, it may be best to start with IGP and inter-domain MPLS since they can be deployed in a single AS. Multicast right now contributes a much smaller percentage of load than unicast, so it makes sense to do IGP first. For BGP you can always use DFA (just declared historic, my point being that overloading global BGP with new inter-AS metrics is going to be a "hard sell"). > [end of comments] > > > These documents are trying to write requirements, build a framework, > and specify protocols, all based on unproven assertions. > > If the work goes to IRTF, the first order of business must be to > provide compelling proof or at least compelling argument that a > specific approach will have benefit in *real* networks, not hypothetic > networks, and not real topologies with a hypothetic network > architecture (ie: choice of type of equipment and build out). > > Curtis My main point stands. IMO You are out of line to submit nearly a dozen drafts to RTGWG on topics for which research is needed to determine if there is any merit to the approach. Curtis From donald.fedyk@alcatel-lucent.com Mon Feb 11 08:51:41 2013 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 228CC21F8A89 for ; Mon, 11 Feb 2013 08:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CpOndeA5xVR for ; Mon, 11 Feb 2013 08:51:40 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 21DC021F8A8B for ; Mon, 11 Feb 2013 08:51:39 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1BGpWeP015658 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Feb 2013 17:51:34 +0100 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Feb 2013 17:51:32 +0100 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.135]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 11 Feb 2013 11:51:16 -0500 From: "Fedyk, Donald (Don)" To: "curtis@occnc.com" , Mingui Zhang Subject: RE: PANET side-meeting Thread-Topic: PANET side-meeting Thread-Index: AQHOCHNvulhFFgPdp0O+uWgwO9U+yZh0266w Date: Mon, 11 Feb 2013 16:51:15 +0000 Message-ID: <59E40B2663705C47B8C0A107CBFBA98807F4F7@US70TWXCHMBA09.zam.alcatel-lucent.com> References: Your message of "Sun, 10 Feb 2013 13:28:14 GMT." <4552F0907735844E9204A62BBDD325E732AFF6E9@nkgeml508-mbx.china.huawei.com> <201302111619.r1BGJCTH031475@gateway1.orleans.occnc.com> In-Reply-To: <201302111619.r1BGJCTH031475@gateway1.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: Susan Hares , "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: Mon, 11 Feb 2013 16:51:41 -0000 I agree with Curtis on this. As I said in another thread. It is not clear = to me even if operators wanted to do Power aware routing why we would need = the extensions proposed in some of these documents. As a vendor I'm not lik= ely to keep dynamic power levels per port.=20 Don =20 -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of C= urtis Villamizar Sent: Monday, February 11, 2013 11:19 AM To: Mingui Zhang Cc: rtgwg@ietf.org; Susan Hares Subject: Re: PANET side-meeting In message <4552F0907735844E9204A62BBDD325E732AFF6E9@nkgeml508-mbx.china.hu= awei.com> Mingui Zhang writes: =20 > I mentioned earlier on the prior thread that I had just quickly read > draft-retana-rtgwg-eacp-00 and did not think this work was worth the=20 > IETF (or IRTF, if I can speak up in advance) in its current form. The=20 > topic might be worth considering, but the work seems to take a naive=20 > approach. Whether treating interfaces and links as a black box and=20 > using routing provides any appreciable gain in real networks remains=20 > to be proven. > =20 > [zmg] I'd like to hear your _specific_ feedbacks on other drafts. I have better things to do with my time than provide detailed review of dra= fts that are ill conceived and so do most of the people on the mailing list= . Below is the list of drafts with comments on whether they are relevant. draft-mjsraman-panet-bgp-power-path draft-mjsraman-panet-ecmp-redirect-power-repl-cap draft-mjsraman-panet-inter-as-power-source draft-mjsraman-panet-inter-as-psp draft-mjsraman-panet-inter-as-psp-protect draft-mjsraman-panet-pce-power-mcast-replic draft-mjsraman-panet-pim-power draft-mjsraman-pce-power-replic draft-mjsraman-panet-intra-as-psp-te-leak draft-mjsraman-panet-ospf-power-topo These are all founded on the premise that there are significant gains that can result from routing that is aware of power disipation differences in hardware related to the traffic load placed on the hardware. The topic of the relevance of these drafts to RTGWG has just been discussed and the concensus seems to me to be that these are not relevant to RTGWG. The discussion so far has been to move all of this work to IRTF if IRTF wants to pursue this topic. draft-mjsraman-panet-tcam-power-efficiency draft-mjsraman-panet-tcam-power-ratio Alreadty discussed on list. Theee TCAM drafts are ill conceived and technically flawed. They should be dropped completely. There may be merit to doing work in this area but you are going about it en= tirely the wrong way. IMO you need to start with a BOF proposal with a bri= ef problem statement and a charter to address the problem. No solution should be mentioned in the initial charter, with a detailed pro= blem statement draft, requirements draft and framework draft. The outcome = of this initial exercise would dictate what sort of solutions, if any, to p= ursue. For example, if any work is done, it may be best to start with IGP = and inter-domain MPLS since they can be deployed in a single AS. Multicast right now contributes a much smaller percentage of load than unic= ast, so it makes sense to do IGP first. For BGP you can always use DFA (ju= st declared historic, my point being that overloading global BGP with new i= nter-AS metrics is going to be a "hard sell"). > [end of comments] > =20 > =20 > These documents are trying to write requirements, build a framework,=20 > and specify protocols, all based on unproven assertions. > =20 > If the work goes to IRTF, the first order of business must be to=20 > provide compelling proof or at least compelling argument that a=20 > specific approach will have benefit in *real* networks, not hypothetic=20 > networks, and not real topologies with a hypothetic network=20 > architecture (ie: choice of type of equipment and build out). > =20 > Curtis My main point stands. IMO You are out of line to submit nearly a dozen dra= fts to RTGWG on topics for which research is needed to determine if there i= s any merit to the approach. Curtis _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From tnadeau@juniper.net Mon Feb 11 11:34:59 2013 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 F20BA21F8849 for ; Mon, 11 Feb 2013 11:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hcdFEpB9Xnq for ; Mon, 11 Feb 2013 11:34:57 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id B7C6921F88FD for ; Mon, 11 Feb 2013 11:34:56 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKURlH4KVxC/Zi8A9x94rGKyyZFq2nO9gj@postini.com; Mon, 11 Feb 2013 11:34:56 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Feb 2013 11:29:55 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 11 Feb 2013 11:29:54 -0800 Received: from CO9EHSOBE042.bigfish.com (207.46.163.27) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 11 Feb 2013 11:38:39 -0800 Received: from mail71-co9-R.bigfish.com (10.236.132.251) by CO9EHSOBE042.bigfish.com (10.236.130.105) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Feb 2013 19:29:53 +0000 Received: from mail71-co9 (localhost [127.0.0.1]) by mail71-co9-R.bigfish.com (Postfix) with ESMTP id 6792AA00F6 for ; Mon, 11 Feb 2013 19:29:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -20 X-BigFish: PS-20(zz98dI9371Ic85fh1432I111aI98adlzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh18c673hz2dh2a8h668h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1155h) Received: from mail71-co9 (localhost.localdomain [127.0.0.1]) by mail71-co9 (MessageSwitch) id 1360610990890433_32386; Mon, 11 Feb 2013 19:29:50 +0000 (UTC) Received: from CO9EHSMHS024.bigfish.com (unknown [10.236.132.227]) by mail71-co9.bigfish.com (Postfix) with ESMTP id D5F6E2E0101; Mon, 11 Feb 2013 19:29:50 +0000 (UTC) Received: from CH1PRD0511HT001.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS024.bigfish.com (10.236.130.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 11 Feb 2013 19:29:50 +0000 Received: from CH1PRD0511MB420.namprd05.prod.outlook.com ([169.254.9.59]) by CH1PRD0511HT001.namprd05.prod.outlook.com ([10.255.159.36]) with mapi id 14.16.0263.000; Mon, 11 Feb 2013 19:29:49 +0000 From: Thomas Nadeau To: Balaji venkat Venkataswami , Hannes Gredler Subject: Re: Power aware networks : Comments requested from routing community Thread-Topic: Power aware networks : Comments requested from routing community Thread-Index: AQHOBJn2ZCPhmd4MdEGFU2pLnHfERphuXwAAgAAMnQCABlOpAA== Date: Mon, 11 Feb 2013 19:29:49 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.255.159.4] Content-Type: multipart/alternative; boundary="_000_CD392F2918B73tnadeaujunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Shankar Raman M J , "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: Mon, 11 Feb 2013 19:34:59 -0000 --_000_CD392F2918B73tnadeaujunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Balaji venkat Venkataswami > Date: Thursday, February 7, 2013 8:52 AM To: Hannes Gredler > Cc: Shankar Raman M J >, "rtg= wg@ietf.org" > Subject: Re: Power aware networks : Comments requested from routing communi= ty Dear Hannes, We are familiar with the presentation that you have referred to. I have 3 questions for you. a) While we agree with the presentation that you have mentioned, can we in = the IETF have control over the home appliances and subscriber line kit ? Is= there a methodology by which we can optimize the power consumption on thes= e devices ? The last thing that many people want is for service providers to be able to= control the equipment that is inside their homes, which includes the CPE d= evice which they may in fact own. However, if you want to go down that r= oute, you might want to check out the HomeNet WG. b) The problem space that the IETF can take up can be only in the edge and = core devices in the ISP networks and the Campus/DC/Metro etc...Assume that = I have n devices today with the same bandwidth offering but differing power= consumption footprint, is there a way today to automatically send traffic = through low power paths in the topology of these devices. Again, checkout HomeNet. --Tom c) So we can optimize power only on what we can control. What are your view= s on this ? thanks and regards, balaji venkat On Thu, Feb 7, 2013 at 6:37 PM, Hannes Gredler > wrote: balaji, may i put your attention to a talk that francois lemarchand gave on future net 2010. https://www.dropbox.com/s/3jb9au2zca4nl3x/10_fn_S29.pdf contains a copy. slide 2 initially shows that the core and edge layer might be appealing due to their per-box power print. however slide 15 discusses the big picture where 99.99% of the power is burned by the home appliances and subscriber line kit. Do you think that optimizing a part of the network which gives only limited overall savings is a worthwhile goal ? Note that SPs already ask their vend= ors about reducing the power footprint of those core devices by improved, (some= times less functional) silicon forwarding engines. /hannes On Feb 6, 2013, at 7:41 PM, Curtis Villamizar wrote: > > Balaji, > > "We" in the context of your first paragraph seems to be a > misrepresentation. The authors of all of these drafts seem to be from > the same university in India. From prior attempts on your part to get > a draft of this sort into IDR and a brief reading of a few of the > drafts that you have just submitted, you don't seem to have a good > understanding of how networks are built and how network equipment is > built from which to begin to attack the problem of reducing the power > consumption of these networks. > > If you want to try to advance a research paper with your theories on > power reduction, please choose an appropriate venue such as a refereed > technical journal. > > Curtis > > > In message > > Balaji venkat Venkataswami writes: > >> Dear all, >> >> We are a group of research and industry individuals tied together with a >> common goal towards reducing the energy consumption in the core and edge >> networks. >> >> We present a metric-based hierarchical approach to reduce power consumpt= ion >> in core and edge networks. The proposal considers both unicast and the >> multicast cases. For unicast, the metric considered is *consumed-power t= o >> available-bandwidth* and for multicast the metric is *consumed-power to >> available-replication-capacity.* >> >> With unicast, the metric is used to determine a low-power path between >> sources and destinations. With multicast, the metric serves the twin >> purpose of finding low-power multicast paths as well as multicast >> replication points. We evolve multiple techniques at various hierarchic= al >> levels. One at the Inter-AS level, Inter-Area level within the AS and >> intra-Area within an AS. Additionally, the proposed method can also be u= sed >> to determine disjoint or redundant paths for load balancing or fault >> tolerance. Additionally since TCAMs are one of the biggest power guzzler= s >> in all the components on a router/switch, we have presented a solution f= or >> intra-AS purposes to use the TCAM according to the traffic matrix passin= g >> through the system and shut down those TCAM banks that are unused. With >> this in mind, we have also advocated taking into account a TCAM-POWER-Ra= tio >> in order to compute the paths from source to destination based on this >> metric. Once low-power paths, in either the unicast or the multicast cas= es, >> are identified then currently available traffic engineering techniques >> could be used to route the data packets. In the case of inter-AS BGP pat= h >> selection is also modified to arrive at paths which are low-power paths. >> >> Our main objective is as follows... >> >> We now outline four important aspects that any approach for power reduct= ion >> should be capable of addressing. >> >> *Should cater for both unicast and multicast scenarios* >> >> Multicast provides an important scenario for the Internet. Today, most >> proposals consider mainly low-power path routing with unicast traffic. >> Multicast traffic has received a lot of attention in wireless networks, = but >> not in the wired domain. Any new proposal should be able to address both >> the unicast and the multicast traffic scenarios. Having different method= s >> for these two scenarios might lead to unnecessary processing burden in t= he >> routers, which might hinder its scalability. >> >> *Should not rely on just switching off unused links* >> >> Most approaches to optimize energy pursue the following approach: measur= e, >> monitor and respond to the system energy usage by switching off unused o= r >> under-utilized links. Such an approach could be effective for reducing >> power locally. The effect on the network is not clearly understood. >> Further, the power usage involved in turning on and rebooting/reconfigur= ing >> the device is often not explicitly considered. We note that Service Leve= l >> Agreement (SLA) requirements may not even permit the links to be switche= d >> off. Also services provided by ISPs like Virtual Private Networks (VPNs) >> can be affected by such re-routing decisions. >> >> *Should follow an hierarchical and distributed approach* >> >> For scalability, it is important that the algorithms proposed for inter-= AS >> should also be applicable to intra-AS situations. Networks do not work i= n >> isolation, so any proposal should be both distributed and hierarchical. = The >> algorithms should be applicable at every level of the hierarchy. >> >> *Should provide incentives for ISP for adoption* >> >> The engineering proposals should be aligned with commercial incentives f= or >> rapid and widespread adoption. Today, the device manufacturers and the I= SPs >> operate independently of each other, and there is no incentive for >> manufacturers to work towards low-power and high bandwidth devices. An >> ISP=3D92s revenue model is based on the consumed bandwidth, which in tur= n lea=3D >> d >> naturally to more power consumption. If the proposed method chooses rout= ers >> that consume low-power and increase the data flow through them, then thi= s >> indirectly provides encouragement for ISPs to purchase low-power and hig= h >> bandwidth devices. >> >> >> >> We now present our metric-based proposals in the below mentioned drafts >> which addresses the aforementioned design aspects. >> >> We would like the routing community to provide feedback on these drafts.= We >> also intend to present this work in an abridged format in the upcoming I= ETF=3D >> . >> >> The drafts are as follows.... >> >> >> >> >> - mjsraman-panet-bgp-power-path> n-panet-bgp-power-path> >> (timeline)> p-power-path-timing.html> >> Inter-AS-Proposal >> - mjsraman-panet-ecmp-redirect-power-repl-cap> /draft-mjsraman-panet-ecmp-redirect-power-repl-cap> >> (timeline)> mp-redirect-power-repl-cap-timing.html> >> Multicast >> - mjsraman-panet-inter-as-power-source> mjsraman-panet-inter-as-power-source> >> (timeline)> ter-as-power-source-timing.html> >> Inter-AS >> Proposal >> - mjsraman-panet-inter-as-psp> panet-inter-as-psp> >> (timeline)> ter-as-psp-timing.html> >> Inter-AS >> Proposal >> - mjsraman-panet-inter-as-psp-protect> jsraman-panet-inter-as-psp-protect> >> (timeline)> ter-as-psp-protect-timing.html> >> Inter-AS >> Proposal >> - mjsraman-panet-pce-power-mcast-replic> -mjsraman-panet-pce-power-mcast-replic> >> (timeline)> e-power-mcast-replic-timing.html> >> Multicast >> - mjsraman-panet-pim-power> et-pim-power> >> (timeline)> m-power-timing.html> >> Multicast >> - mjsraman-panet-tcam-power-efficiency> mjsraman-panet-tcam-power-efficiency> >> (timeline)> am-power-efficiency-timing.html> >> TCAM >> related >> - mjsraman-panet-tcam-power-ratio> man-panet-tcam-power-ratio> >> (timeline> m-power-ratio-timing.html>) >> TCAM related >> - mjsraman-pce-power-replic> e-power-replic> >> (timeline)> r-replic-timing.html> >> Multicast >> - mjsraman-panet-intra-as-psp-te-leak> jsraman-panet-intra-as-psp-te-leak> >> (timeline)> tra-as-psp-te-leak-timing.html> >> Inter-Area >> within an AS >> - mjsraman-panet-ospf-power-topo> an-panet-ospf-power-topo> >> (timeline)> pf-power-topo-timing.html> >> Intra-Area >> within an AS >> >> We understand it is a lot of matter to go through. We would much appreci= ate >> if some of you could review the inter-AS proposals while others take up >> multicast and Intra-AS unicast and multicast. >> >> Thanks again for your time on this matter. >> >> thanks and regards, >> balaji venkat > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --_000_CD392F2918B73tnadeaujunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable


    From: Balaji venkat Venkataswami &l= t;balajivenkat299@gmail.com>
    Date: Thursday, February 7, 2013 8:= 52 AM
    To: Hannes Gredler <    hannes@juniper.net>
    Cc: Shankar Raman M J <mjsraman@gmail.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>
    Subject: Re: Power aware networks := Comments requested from routing community

    Dear Hannes,

    We are familiar with the presentation that you have referred to.

    I have 3 questions for you.

    a) While we agree with the presentation that you have mentioned, can w= e in the IETF have control over the home appliances and subscriber line kit= ? Is there a methodology by which we can optimize the power consumption on= these devices ?

    The la= st thing that many people want is for service providers to be able to contr= ol the equipment that is inside their homes, which includes the CPE device = which they may in fact own.    However, if you want to go down that route, you might want to check out the HomeNet= WG.

    b) The problem space that the IETF can take up can be only in the edge= and core devices in the ISP networks and the Campus/DC/Metro etc...Assume = that I have n devices today with the same bandwidth offering but differing = power consumption footprint, is there a way today to automatically send traffic through low power paths in= the topology of these devices.

    Again,= checkout HomeNet.

    --Tom<= /div>



    c) So we can optimize power only on what we can control. What are your= views on this ?

    thanks and regards,
    balaji venkat 

    On Thu, Feb 7, 2013 at 6:37 PM, Hannes Gredler <= span dir=3D"ltr"> <hannes@juniper.= net> wrote:
    balaji,

    may i put your attention to a talk that  francois lemarchand
    gave on future net 2010.
    https://www.dropbox.com/s/3jb9au2zca4nl3x/10_fn_S29.pdf
    contains a copy.

    slide 2 initially shows that the core and edge layer might be appealing
    due to their per-box power print. however slide 15 discusses the
    big picture where 99.99% of the power is burned by the home
    appliances and subscriber line kit.

    Do you think that optimizing a part of the network which gives only limited=
    overall savings is a worthwhile goal ? Note that SPs already ask their vend= ors
    about reducing the power footprint of those core devices by improved, (some= times
    less functional) silicon forwarding engines.

    /hannes

    On Feb 6, 2013, at 7:41 PM, Curtis Villamizar wrote:

    >
    > Balaji,
    >
    > "We" in the context of your first paragraph seems to be a > misrepresentation.  The authors of all of these drafts seem to be= from
    > the same university in India.  From prior attempts on your part t= o get
    > a draft of this sort into IDR and a brief reading of a few of the
    > drafts that you have just submitted, you don't seem to have a good
    > understanding of how networks are built and how network equipment is > built from which to begin to attack the problem of reducing the power<= br> > consumption of these networks.
    >
    > If you want to try to advance a research paper with your theories on > power reduction, please choose an appropriate venue such as a refereed=
    > technical journal.
    >
    > Curtis
    >
    >
    > In message <CAHF4apO9bEkPk7QwA9fgJq9BNUNHNv+OFon_9= _4Oij61e11r9w@mail.gmail.com>
    > Balaji venkat Venkataswami writes:
    >
    >> Dear all,
    >>
    >> We are a group of research and industry individuals tied together = with a
    >> common goal towards reducing the energy consumption in the core an= d edge
    >> networks.
    >>
    >> We present a metric-based hierarchical approach to reduce power co= nsumption
    >> in core and edge networks. The proposal considers both unicast and= the
    >> multicast cases. For unicast, the metric considered is *consumed-p= ower to
    >> available-bandwidth* and for multicast the metric is *consumed-pow= er to
    >> available-replication-capacity.*
    >>
    >> With unicast, the metric is used to determine a low-power path bet= ween
    >> sources and destinations. With multicast, the metric serves the tw= in
    >> purpose of finding low-power multicast paths as well as multicast<= br> >> replication points.  We evolve multiple techniques at various= hierarchical
    >> levels. One at the Inter-AS level, Inter-Area level within the AS = and
    >> intra-Area within an AS. Additionally, the proposed method can als= o be used
    >> to determine disjoint or redundant paths for load balancing or fau= lt
    >> tolerance. Additionally since TCAMs are one of the biggest power g= uzzlers
    >> in all the components on a router/switch, we have presented a solu= tion for
    >> intra-AS purposes to use the TCAM according to the traffic matrix = passing
    >> through the system and shut down those TCAM banks that are unused.= With
    >> this in mind, we have also advocated taking into account a TCAM-PO= WER-Ratio
    >> in order to compute the paths from source to destination based on = this
    >> metric. Once low-power paths, in either the unicast or the multica= st cases,
    >> are identified then currently available traffic engineering techni= ques
    >> could be used to route the data packets. In the case of inter-AS B= GP path
    >> selection is also modified to arrive at paths which are low-power = paths.
    >>
    >> Our main objective is as follows...
    >>
    >> We now outline four important aspects that any approach for power = reduction
    >> should be capable of addressing.
    >>
    >> *Should cater for both unicast and multicast scenarios*
    >>
    >> Multicast provides an important scenario for the Internet. Today, = most
    >> proposals consider mainly low-power path routing with unicast traf= fic.
    >> Multicast traffic has received a lot of attention in wireless netw= orks, but
    >> not in the wired domain. Any new proposal should be able to addres= s both
    >> the unicast and the multicast traffic scenarios. Having different = methods
    >> for these two scenarios might lead to unnecessary processing burde= n in the
    >> routers, which might hinder its scalability.
    >>
    >> *Should not rely on just switching off unused links*
    >>
    >> Most approaches to optimize energy pursue the following approach: = measure,
    >> monitor and respond to the system energy usage by switching off un= used or
    >> under-utilized links. Such an approach could be effective for redu= cing
    >> power locally. The effect on the network is not clearly understood= .
    >> Further, the power usage involved in turning on and rebooting/reco= nfiguring
    >> the device is often not explicitly considered. We note that Servic= e Level
    >> Agreement (SLA) requirements may not even permit the links to be s= witched
    >> off. Also services provided by ISPs like Virtual Private Networks = (VPNs)
    >> can be affected by such re-routing decisions.
    >>
    >> *Should follow an hierarchical and distributed approach*
    >>
    >> For scalability, it is important that the algorithms proposed for = inter-AS
    >> should also be applicable to intra-AS situations. Networks do not = work in
    >> isolation, so any proposal should be both distributed and hierarch= ical. The
    >> algorithms should be applicable at every level of the hierarchy. >>
    >> *Should  provide incentives for ISP for adoption*
    >>
    >> The engineering proposals should be aligned with commercial incent= ives for
    >> rapid and widespread adoption. Today, the device manufacturers and= the ISPs
    >> operate independently of each other, and there is no incentive for=
    >> manufacturers to work towards low-power and high bandwidth devices= . An
    >> ISP=3D92s revenue model is based on the consumed bandwidth, which = in turn lea=3D
    >> d
    >> naturally to more power consumption. If the proposed method choose= s routers
    >> that consume low-power and increase the data flow through them, th= en this
    >> indirectly provides encouragement for ISPs to purchase low-power a= nd high
    >> bandwidth devices.
    >>
    >>
    >>
    >> We now present our metric-based proposals in the below mentioned d= rafts
    >> which addresses the aforementioned design aspects.
    >>
    >> We would like the routing community to provide feedback on these d= rafts. We
    >> also intend to present this work in an abridged format in the upco= ming IETF=3D
    >> .
    >>
    >> The drafts are as follows....
    >>
    >>
    >>
    >>
    >>   - mjsraman-panet-bgp-power-path<http://tools.ietf.org/htm= l/draft-mjsrama=3D
    >> n-panet-bgp-power-path>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-bg=3D
    >> p-power-path-timing.html>
    >>    Inter-AS-Proposal
    >>   - mjsraman-panet-ecmp-redirect-power-repl-cap<http://tools.ietf.org/htm= l=3D
    >> /draft-mjsraman-panet-ecmp-redirect-power-repl-cap>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-ec=3D
    >> mp-redirect-power-repl-cap-timing.html>
    >>    Multicast
    >>   - mjsraman-panet-inter-as-power-source<http://tools.ietf.org/htm= l/draft-=3D
    >> mjsraman-panet-inter-as-power-source>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-in=3D
    >> ter-as-power-source-timing.html>
    >> Inter-AS
    >>   Proposal
    >>   - mjsraman-panet-inter-as-psp<http://tools.ietf.org/htm= l/draft-mjsraman-=3D
    >> panet-inter-as-psp>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-in=3D
    >> ter-as-psp-timing.html>
    >> Inter-AS
    >>   Proposal
    >>   - mjsraman-panet-inter-as-psp-protect<http://tools.ietf.org/htm= l/draft-m=3D
    >> jsraman-panet-inter-as-psp-protect>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-in=3D
    >> ter-as-psp-protect-timing.html>
    >> Inter-AS
    >>   Proposal
    >>   - mjsraman-panet-pce-power-mcast-replic<http://tools.ietf.org/htm= l/draft=3D
    >> -mjsraman-panet-pce-power-mcast-replic>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-pc=3D
    >> e-power-mcast-replic-timing.html>
    >>    Multicast
    >>   - mjsraman-panet-pim-power<http://tools.ietf.org/htm= l/draft-mjsraman-pan=3D
    >> et-pim-power>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-pi=3D
    >> m-power-timing.html>
    >>    Multicast
    >>   - mjsraman-panet-tcam-power-efficiency<http://tools.ietf.org/htm= l/draft-=3D
    >> mjsraman-panet-tcam-power-efficiency>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-tc=3D
    >> am-power-efficiency-timing.html>
    >> TCAM
    >>   related
    >>   - mjsraman-panet-tcam-power-ratio<http://tools.ietf.org/htm= l/draft-mjsra=3D
    >> man-panet-tcam-power-ratio>
    >>    (timeline<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-tca=3D
    >> m-power-ratio-timing.html>)
    >>   TCAM related
    >>   - mjsraman-pce-power-replic<http://tools.ietf.org/htm= l/draft-mjsraman-pc=3D
    >> e-power-replic>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-pce-powe=3D
    >> r-replic-timing.html>
    >>    Multicast
    >>   - mjsraman-panet-intra-as-psp-te-leak<http://tools.ietf.org/htm= l/draft-m=3D
    >> jsraman-panet-intra-as-psp-te-leak>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-in=3D
    >> tra-as-psp-te-leak-timing.html>
    >> Inter-Area
    >>   within an AS
    >>   - mjsraman-panet-ospf-power-topo<http://tools.ietf.org/htm= l/draft-mjsram=3D
    >> an-panet-ospf-power-topo>
    >>    (timeline)<http://www.arkko.com= /tools/lifecycle/draft-mjsraman-panet-os=3D
    >> pf-power-topo-timing.html>
    >> Intra-Area
    >>   within an AS
    >>
    >> We understand it is a lot of matter to go through. We would much a= ppreciate
    >> if some of you could review the inter-AS proposals while others ta= ke up
    >> multicast and Intra-AS unicast and multicast.
    >>
    >> Thanks again for your time on this matter.
    >>
    >> thanks and regards,
    >> balaji venkat
    > _______________________________________________
    > rtgwg mailing list
    > rtgwg@ietf.org
    > https://www.ietf.org/mailman/listinfo/rtgwg
    >



     --_000_CD392F2918B73tnadeaujunipernet_-- From zhangmingui@huawei.com Mon Feb 11 22:07:10 2013 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 A1DF321F8C3E for ; Mon, 11 Feb 2013 22:07:10 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0ITxgLtBrtL for ; Mon, 11 Feb 2013 22:07:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DCDF221F8C48 for ; Mon, 11 Feb 2013 22:07:04 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APQ33138; Tue, 12 Feb 2013 06:06:50 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 12 Feb 2013 06:06:29 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 12 Feb 2013 06:06:46 +0000 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.33]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Tue, 12 Feb 2013 14:06:36 +0800 From: Mingui Zhang To: "curtis@occnc.com" Subject: RE: PANET side-meeting Thread-Topic: PANET side-meeting Thread-Index: AQHOCHNvKuTqdHe8Bkmtrak3KqQ1B5h1uvPn Date: Tue, 12 Feb 2013 06:06:36 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E732AFF828@nkgeml508-mbx.china.huawei.com> References: Your message of "Sun, 10 Feb 2013 13:28:14 GMT." <4552F0907735844E9204A62BBDD325E732AFF6E9@nkgeml508-mbx.china.huawei.com>, <201302111619.r1BGJCTH031475@gateway1.orleans.occnc.com> In-Reply-To: <201302111619.r1BGJCTH031475@gateway1.orleans.occnc.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.99.198.98] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Susan Hares , "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: Tue, 12 Feb 2013 06:07:10 -0000 Hi Curtis, One clarification: when I said the "other drafts", I actually meant the fol= lowing drafts.=20 Power-Aware Networks (PANET): Problem Statement, https://datatracker.ietf.o= rg/doc/draft-zhang-panet-problem-statement/ Use Cases for Power-Aware Networks, https://datatracker.ietf.org/doc/draft-= zhang-panet-use-cases/ Requirements for Power Aware Network, https://datatracker.ietf.org/doc/draf= t-dong-panet-requirement Thanks, Mingui ________________________________________ From: Curtis Villamizar [curtis@occnc.com] Sent: Tuesday, February 12, 2013 0:18 To: Mingui Zhang Cc: curtis@occnc.com; Tony Li; rtgwg@ietf.org; Susan Hares Subject: Re: PANET side-meeting In message <4552F0907735844E9204A62BBDD325E732AFF6E9@nkgeml508-mbx.china.hu= awei.com> Mingui Zhang writes: > I mentioned earlier on the prior thread that I had just quickly read > draft-retana-rtgwg-eacp-00 and did not think this work was worth the > IETF (or IRTF, if I can speak up in advance) in its current form. The > topic might be worth considering, but the work seems to take a naive > approach. Whether treating interfaces and links as a black box and > using routing provides any appreciable gain in real networks remains > to be proven. > > [zmg] I'd like to hear your _specific_ feedbacks on other drafts. I have better things to do with my time than provide detailed review of drafts that are ill conceived and so do most of the people on the mailing list. Below is the list of drafts with comments on whether they are relevant. draft-mjsraman-panet-bgp-power-path draft-mjsraman-panet-ecmp-redirect-power-repl-cap draft-mjsraman-panet-inter-as-power-source draft-mjsraman-panet-inter-as-psp draft-mjsraman-panet-inter-as-psp-protect draft-mjsraman-panet-pce-power-mcast-replic draft-mjsraman-panet-pim-power draft-mjsraman-pce-power-replic draft-mjsraman-panet-intra-as-psp-te-leak draft-mjsraman-panet-ospf-power-topo These are all founded on the premise that there are significant gains that can result from routing that is aware of power disipation differences in hardware related to the traffic load placed on the hardware. The topic of the relevance of these drafts to RTGWG has just been discussed and the concensus seems to me to be that these are not relevant to RTGWG. The discussion so far has been to move all of this work to IRTF if IRTF wants to pursue this topic. draft-mjsraman-panet-tcam-power-efficiency draft-mjsraman-panet-tcam-power-ratio Alreadty discussed on list. Theee TCAM drafts are ill conceived and technically flawed. They should be dropped completely. There may be merit to doing work in this area but you are going about it entirely the wrong way. IMO you need to start with a BOF proposal with a brief problem statement and a charter to address the problem. No solution should be mentioned in the initial charter, with a detailed problem statement draft, requirements draft and framework draft. The outcome of this initial exercise would dictate what sort of solutions, if any, to pursue. For example, if any work is done, it may be best to start with IGP and inter-domain MPLS since they can be deployed in a single AS. Multicast right now contributes a much smaller percentage of load than unicast, so it makes sense to do IGP first. For BGP you can always use DFA (just declared historic, my point being that overloading global BGP with new inter-AS metrics is going to be a "hard sell"). > [end of comments] > > > These documents are trying to write requirements, build a framework, > and specify protocols, all based on unproven assertions. > > If the work goes to IRTF, the first order of business must be to > provide compelling proof or at least compelling argument that a > specific approach will have benefit in *real* networks, not hypothetic > networks, and not real topologies with a hypothetic network > architecture (ie: choice of type of equipment and build out). > > Curtis My main point stands. IMO You are out of line to submit nearly a dozen drafts to RTGWG on topics for which research is needed to determine if there is any merit to the approach. Curtis= From curtis@occnc.com Tue Feb 12 08:52:30 2013 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 E1B1C21F8F7E for ; Tue, 12 Feb 2013 08:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.412 X-Spam-Level: X-Spam-Status: No, score=-0.412 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8A-F5FMF4vNb for ; Tue, 12 Feb 2013 08:52:30 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 28D0021F8F52 for ; Tue, 12 Feb 2013 08:52:30 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r1CGoZQI043900; Tue, 12 Feb 2013 11:50:35 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302121650.r1CGoZQI043900@gateway1.orleans.occnc.com> To: Mingui Zhang From: Curtis Villamizar Subject: PANET drafts (was Re: PANET side-meeting) In-reply-to: Your message of "Tue, 12 Feb 2013 06:06:36 GMT." <4552F0907735844E9204A62BBDD325E732AFF828@nkgeml508-mbx.china.huawei.com> Date: Tue, 12 Feb 2013 11:49:55 -0500 Cc: "rtgwg@ietf.org" , Susan Hares 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: Tue, 12 Feb 2013 16:52:31 -0000 In message <4552F0907735844E9204A62BBDD325E732AFF828@nkgeml508-mbx.china.huawei.com> Mingui Zhang writes: > Hi Curtis, > > One clarification: when I said the "other drafts", I actually meant > the following drafts. > > Power-Aware Networks (PANET): Problem Statement, > https://datatracker.ietf.org/doc/draft-zhang-panet-problem-statement/ > > Use Cases for Power-Aware Networks, > https://datatracker.ietf.org/doc/draft-zhang-panet-use-cases/ > > Requirements for Power Aware Network, > https://datatracker.ietf.org/doc/draft-dong-panet-requirement > > Thanks, > Mingui Mingui, OK. Comments below. Do to other obligations, I have to go through these quickly but they are so far off the mark that it is OK to go through them quickly. The underlying flaw in all of this is that you have not done the fundamental research into where power goes and where gains can be made. That exercise needs to be done for each of the type of domain within scope: core, edge, aggregation, access, enterprise, data center. The problem statement should have a clear statement of which of these are within scope and an analysis of where power goes for each within scope, and where gains can be made for each within scope. You can't have a good requirements document and framework until you have a good problem statement, so don't bother to write them until you have done the underlying research and have a good problem statement. Curtis Power-Aware Networks (PANET): Problem Statement draft-zhang-panet-problem-statement Intro could be shorter. We all know that power is an issue for numerous resasons. Money is an issue and that CO2 is an issue. In the past fitting higher capacity into the same space and power has been the dominant issue. A problem statement should not have solution approaches. This narrows the solution space unnecessarily too early in the process. The choice of solution approaches is poor and ignores the many types of equipment drawing power. There is no mention of the scope of the work. Is it core networsk, edge, aggregation (metro), access, enterprise, data center, or all of the above. Different solutions will apply to difference situations. For example, does putting a router link into sleep mode affect the 400W laser in the transport equipment? If transport lasers are turned off, how long do they need to restabilize (hint: minimum for ULH is usually minutes to get power levels right, stabilize temperatures within the actively cooled lasers, etc. Can take tens of minutes before fully stabilized during which time periods of errors may occur). A good engineering approach is to start by figuring out where most of the power goes, and focus on where large gains can be made. That is what *should* go into a problem statement. Problem Areas for IETF outlines what should be in this document. You could take the bullet list and try to make that into a WG BOF rather than offer this as a problems statement. If you are going to write a problem statement draft, address the questions under Motivation and Problem Scope. The bullets in the Technical Development and Operation Practice belong in requirements and framework documents, filled in, not unanswered. A proper "problem statement" in IETF is a clear and concise statement of a well defined problem to be solved. You don't have that. Use Cases for Power-Aware Networks https://datatracker.ietf.org/doc/draft-zhang-panet-use-cases/ This document is useless as a use cases document. It mostly reiterates the solution set proposed in the problem statement. Instead of anecdotal examples a good analysis of where power goes in core, edge, aggregation (metro), access, enterprise, data center and where power could be potentially reduced would make for a better use case document if that wasn't in the problem statement. Requirements for Power Aware Network https://datatracker.ietf.org/doc/draft-dong-panet-requirement The requirements makes the assumption that a solution involving changes in the control plane will be found necessary. Since we don't have the research to support that, this document is premature and should be ignored for now. It is entirely possible that some 90% of the gains could come from local power optimizations alone and the remaining 10% requires enough complexity that it is not worth it. We don't know that until the underlying research into where the power goes and where we can make gains is done. From aretana@cisco.com Tue Feb 12 09:18:06 2013 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 4910621F8EDF for ; Tue, 12 Feb 2013 09:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPn5xsfkFLec for ; Tue, 12 Feb 2013 09:18:05 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9706721F8EBE for ; Tue, 12 Feb 2013 09:18:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4470; q=dns/txt; s=iport; t=1360689485; x=1361899085; h=from:to:subject:date:message-id:mime-version; bh=I/Nc9Pv7DXrMbCcF/Um4iWGYNez461ur6fHzJPfBS2w=; b=bTJeMq9VFPZnM+Cc/U7/aix4ODhCFLLSGC+bMaoAmuwpUdcevXWeZTxL o6mQNngM5uFLwQ7X+o23mA6aa8VlQ9Jz4W1Je9a1YQWwat1u/gLTlNEm1 CqLn0yLAPd5LMSh823vwMVrWmZFoH0iZgbXG0wyai13TCV1nJ3dPQtQ0L U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0FADF4GlGtJV2Y/2dsb2JhbABEgkmFH7lUFnOCIQEEgQsBDB5WJwQbiAoMnhGRFZAVBI1Kg1phA6Z3gwaCJw X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; d="scan'208,217";a="176257549" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 12 Feb 2013 17:18:05 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1CHI5f1031690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 12 Feb 2013 17:18:05 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.213]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 12 Feb 2013 11:18:04 -0600 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: rtgwg Meeting @ IETF 86 (Orlando) Thread-Topic: rtgwg Meeting @ IETF 86 (Orlando) Thread-Index: AQHOCUTrg22HRkZN+U+afl5ih1P/Yg== Date: Tue, 12 Feb 2013 17:18:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.233.18] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94ED47B25xmbalnx15ciscocom_" 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: Tue, 12 Feb 2013 17:18:06 -0000 --_000_BBD66FD99311804F80324E8139B3C94ED47B25xmbalnx15ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have been given a 2-hour slot for rtgwg on Wednesday (Mar/13) afternoon. https://datatracker.ietf.org/meeting/86/agenda.txt Given the interest in recent months on power-aware/energy-efficient network= ing, we will dedicate the second hour of the meeting to that topic. Accord= ing to the WG's charter, rtgwg is the appropriate place to discuss topics t= hat are not ready for their own WG/BOF and that are related to routing. Pl= ease be clear that this section of the meeting should not be considered a B= OF or side-meeting or any other such construct targeted at potentially crea= ting a WG. The goal is to discuss the technology and potential work items,= if any, that the WG may take on. Ideally we would reach agreement (pendin= g discussion on the list, of course) on what the topic covers, what may bel= ong in the IETF at this time, and whether there is interest in doing any wo= rk. The first hour will be dedicated to "business as usual". Please send us an= y requests for presentations. For the second hour, the agenda will give people a chance to clarify the wo= rk they think needs to be done, and have time for discussion. We think we k= now who should be addressing the meeting, but if you think you have a draft= or a specific topic to add, please let us know. We will be asking all the presenters to start a discussion on the list abou= t their drafts, pointing out the parts they would like the most feedback on= . The intention is to both have an idea of the initial interest and for th= e content to not be completely new at the in-person meeting, hopefully resu= lting in better discussions. Thanks! Alia and Alvaro. --_000_BBD66FD99311804F80324E8139B3C94ED47B25xmbalnx15ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
    We have been given a 2-hour slot for rtgwg on Wednesday (Mar/13) after= noon.


    Given the interest in recent months on power-aware/energy-efficient ne= tworking, we will dedicate the second hour of the meeting to that topic. &n= bsp;According to the WG's charter, rtgwg is the appropriate place to discus= s topics that are not ready for their own WG/BOF and that are related to routing.  Please be clear that thi= s section of the meeting should not be considered a BOF or side-meeting or = any other such construct targeted at potentially creating a WG.  The g= oal is to discuss the technology and potential work items, if any, that the WG may take on.  Ideally we would reach = agreement (pending discussion on the list, of course) on what the topic cov= ers, what may belong in the IETF at this time, and whether there is interes= t in doing any work.

    The first hour will be dedicated to "business as usual". &nb= sp;Please send us any requests for presentations.

    For the second hour, the agenda will give people a chance to clarify t= he work they think needs to be done, and have time for discussion. We think= we know who should be addressing the meeting, but if you think you have a = draft or a specific topic to add, please let us know.
     
    We will be asking all the presenters to start a discussion on the= list about their drafts, pointing out the parts they would like the most f= eedback on.  The intention is to both have an idea of the initial inte= rest and for the content to not be completely new at the in-person meeting, hopefully resulting in better discussions. &= nbsp;

    Thanks!

    Alia and Alvaro.
    --_000_BBD66FD99311804F80324E8139B3C94ED47B25xmbalnx15ciscocom_-- From aretana@cisco.com Wed Feb 13 07:53:04 2013 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 9A47021F8788 for ; Wed, 13 Feb 2013 07:53:03 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIOfkbGxydm5 for ; Wed, 13 Feb 2013 07:52:57 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1E73121F8783 for ; Wed, 13 Feb 2013 07:52:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4537; q=dns/txt; s=iport; t=1360770777; x=1361980377; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=HUZFWPFefD6/Jbka7Cpox6JzrA8ODdj5N4prP/xtUXw=; b=hV0/xDACn7Q3Ya0C5yQQPQhXvShAey5EPewCxHlQ8eGh/kfUVs8UsQJb fn4RL+vns0qR0xyr0cCVaue6wv7YY+DvRjxTSkCrLVQ+IDGRTkGYGkWzJ DPKa+jttXk1LpxezCS0Aj+XhhR3OOE2Ync3W02xdk+v6yKrFWhq/2tF3w 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAOWzG1GtJXG//2dsb2JhbABEg3m8cRZzgh8BAQEEAQEBCywrCR0BCCIUNwsbAQYDAgQTCAESh3cHBZ1poQCNSoNYYQOXQYomhRCDBoIn X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; d="scan'208";a="176700419" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 13 Feb 2013 15:52:53 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1DFqrUE030978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 13 Feb 2013 15:52:53 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.213]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 09:52:53 -0600 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: FW: I-D Action: draft-retana-rtgwg-eacp-01.txt Thread-Topic: I-D Action: draft-retana-rtgwg-eacp-01.txt Thread-Index: AQHOCf1km8R/urP4qkG8rBFAxgvU4Zh4ASIA Date: Wed, 13 Feb 2013 15:52:52 +0000 Message-ID: In-Reply-To: <20130213151819.12024.15592.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.232.118] Content-Type: text/plain; charset="us-ascii" Content-ID: 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: Wed, 13 Feb 2013 15:53:06 -0000 [Chair hat off.] Hi! We just published an update (a refresh really) of the draft below. The draft is NOT a set of requirements to be solved in the realm of power aware/energy efficient networking. We are not trying to define requirements on how to save energy, how much energy should be saved, how, when or where. Nor are we recommending any specific solution. So, what is it? ;-) The intent of the draft is to "provide the tools and knowledge necessary for protocol designers to modify network protocols to best balance efficiency against performance, and to provide the background information network operators will need to intelligently deploy and use protocol modifications to network protocols." In other words.. We recognize that saving energy may be in many people's minds, but we also recognize that networks have been designed/deployed with a set of business (availability, ability to satisfy customer SLAs, for example) and application (min bw, jitter/delay budgets, for instance) requirements in mind, which need to still be satisfied even while saving energy. The draft goes on to evaluate considerations derived from the business/application requirements that may be affected by applying common methods of reducing energy (reducing the topology or reducing the link speed, for example): bw reduction, stretch, fast recovery, introducing jitter and other operational aspects. As an example, we mention (section 5.1) that eliminating links from the topology (shutting them down or putting them in a "low power state") should result in lower energy utilization..but that it will also affect the total available bw in the network. The requirement then comes in in the form of "Modifications to control plane protocols to achieve network energy efficiency SHOULD provide the ability to set the minimal bandwidth, jitter, and delay through the network". I'll leave you to read some of the other examples/considerations and requirements. The end result of the draft is the definition of a framework against which we can evaluate "the tradeoffs between modifications made to network protocols to conserve energy and network performance metrics and requirements". Thanks! Alvaro. On 2/13/13 10:18 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : A Framework and Requirements for Energy Aware Control >Planes > Author(s) : Alvaro Retana > Russ White > Manuel Paul > Filename : draft-retana-rtgwg-eacp-01.txt > Pages : 16 > Date : 2013-02-13 > >Abstract: > There has been, for several years, a rising concern over the energy > usage of large scale networks. This concern is strongly focused on > campus, data center, and other highly concentrated deployments of > network infrastructure. Given the steadily increasing demand for > higher network speeds, always-on service models, and ubiquitous > network coverage, it is also of growing importance for > telecommunication networks both local and wide area in scope. One of > the issues in moving forward to reduce energy usage is to ensure that > the network can still meet the performance specifications required to > support the applications running over it. > > This document provides an overview of the various areas of concern in > the interaction between network performance and efforts at energy > aware control planes, as a guide for those working on modifying > current control planes or designing new control planes to improve the > energy efficiency of high density, highly complex, network > deployments. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-retana-rtgwg-eacp > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-retana-rtgwg-eacp-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-retana-rtgwg-eacp-01 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From susan.hares@huawei.com Wed Feb 13 08:36:51 2013 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 B841C21F8A74 for ; Wed, 13 Feb 2013 08:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+iv56gJ+2Ch for ; Wed, 13 Feb 2013 08:36:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 971E821F8940 for ; Wed, 13 Feb 2013 08:36:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOK78673; Wed, 13 Feb 2013 16:36:36 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 13 Feb 2013 16:36:13 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 13 Feb 2013 16:36:35 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.139]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Wed, 13 Feb 2013 08:36:25 -0800 From: Susan Hares To: "Eric Osborne (eosborne)" , Mingui Zhang , Tony Li , "curtis@occnc.com" Subject: RE: PANET side-meeting Thread-Topic: PANET side-meeting Thread-Index: AQHOBctBKuTqdHe8Bkmtrak3KqQ1B5hwkpwAgAdyRxA= Date: Wed, 13 Feb 2013 16:36:24 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B146237EDC28@dfweml509-mbx.china.huawei.com> References: <201302072244.r17Mi3Og002450@gateway1.orleans.occnc.com> <6B5386C5-F507-417F-94E8-0E4B6446FFA8@tony.li> <4552F0907735844E9204A62BBDD325E732AFF460@nkgeml508-mbx.china.huawei.com> <20ECF67871905846A80F77F8F4A27572100C0A1C@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A27572100C0A1C@xmb-rcd-x09.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 13 Feb 2013 08:39:24 -0800 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: Wed, 13 Feb 2013 16:36:51 -0000 Eric, Minqui and Curtis: +1 on interest. Whether we get a IETF room or not - I'd like to really cha= t about this topic. Sue=20 -----Original Message----- From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]=20 Sent: Friday, February 08, 2013 6:53 AM To: Mingui Zhang; Tony Li; curtis@occnc.com Cc: Susan Hares; rtgwg@ietf.org Subject: RE: PANET side-meeting Will this side meeting be in Orlando? I'm sceptical of some of the current= approaches but am very interested in where they might go. eric > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Mingui Zhang > Sent: Friday, February 08, 2013 2:10 AM > To: Tony Li; curtis@occnc.com > Cc: Susan Hares; rtgwg@ietf.org > Subject: PANET side-meeting >=20 > Hi Tony and Curtis, >=20 > Let me retrospect some history to clear up the chaos floating around. >=20 > On Feb 4th, I organized a conference call among a dozen of guys (from > operators, vendors and Universities) who are interested in PANET, in orde= r to > prepare for a side meeting in IETF. There was a rough consensus that a si= de- > meeting is a good way to call for interest, coordination and contribution= to > PANET. However, requests was _prematurely_ sent out afterwards, without > including all the effort from the conference attendees. I hope this email= can get > us back on track. So I change its title. >=20 > I believe the most efficient way for us is to play the game according to = the rule > of IETF/IRTF. Therefore, we are trying to find a place to accommodate the= side- > meeting. We should not delve into discussion of specific solutions before= we > make clear the problem scope. A charter should be published, which will h= elp > us figure out what is the problem we are trying to solve. Before that, le= t me > add some pointers of drafts from my side. I believe these drafts can also= help > people to figure out the scope of PANET. > Power-Aware Networks (PANET): Problem Statement, > https://datatracker.ietf.org/doc/draft-zhang-panet-problem-statement/ > Use Cases for Power-Aware Networks, https://datatracker.ietf.org/doc/draf= t- > zhang-panet-use-cases/ > Requirements for Power Aware Network, > https://datatracker.ietf.org/doc/draft-dong-panet-requirement/ >=20 > On the 84th IETF rtgwg f2f meeting, there were two presentations relevant= to > greening. I also list them as follows FYI. > A Framework and Requirements for Energy Aware Control Planes, > http://tools.ietf.org/html/draft-retana-rtgwg-eacp-00, [slides] > http://www.ietf.org/proceedings/84/slides/slides-84-rtgwg-3.pptx > Power-aware Routing and Traffic Engineering: Requirements, Approaches, an= d > Issues, https://datatracker.ietf.org/doc/draft-zhang-greennet/, [slides] > http://www.ietf.org/proceedings/84/slides/slides-84-rtgwg-4.pptx >=20 > Thanks, > Mingui Zhang > Huawei Technologies >=20 >=20 > >-----Original Message----- > >From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > >Of Tony Li > >Sent: Friday, February 08, 2013 7:02 AM > >To: curtis@occnc.com > >Cc: Shankar Raman M J; rtgwg@ietf.org > >Subject: Re: Power aware networks : Comments requested from routing > >community > > > > > >On Feb 7, 2013, at 2:44 PM, Curtis Villamizar wrote: > > > >> I don't think this is even material ready for IRTF consideration, but > >> that is up to Tony and IRTF to decide. > > > > > >As always, the IRTF does not require well-formed ideas as a > >pre-requisite for starting work. Instead, there needs to be a clear > >problem statement (i.e., a > >charter) and a sufficient group of serious researchers who are > >committed to following through in a committed manner. > > > >Note that it is, by definition, research. It is expected to have a > >non-trivial likelihood of failure. > > > >Regards, > >Tony > > > >_______________________________________________ > >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 From stephane.litkowski@orange.com Mon Feb 18 04:31:14 2013 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 7504C21F8771 for ; Mon, 18 Feb 2013 04:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.722 X-Spam-Level: X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[AWL=1.526, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2yyda2BK1K4 for ; Mon, 18 Feb 2013 04:31:14 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id ACDD221F8763 for ; Mon, 18 Feb 2013 04:31:13 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 6C90432429F for ; Mon, 18 Feb 2013 13:31:12 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 4F65E35C045 for ; Mon, 18 Feb 2013 13:31:12 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.53]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 18 Feb 2013 13:31:12 +0100 From: To: "rtgwg@ietf.org" Date: Mon, 18 Feb 2013 13:31:11 +0100 Subject: TR: I-D Action: draft-litkowski-rtgwg-lfa-manageability-01.txt Thread-Topic: I-D Action: draft-litkowski-rtgwg-lfa-manageability-01.txt Thread-Index: Ac4N0j6E/7A4EUSYSlmIAvqz48euWQAABAjg Message-ID: <18471_1361190672_51221F10_18471_6729_1_EEE55384044474429A926C625D0FCC81063D5E7C42@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.18.120328 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: Mon, 18 Feb 2013 12:31:14 -0000 Hi all, We just posted the new version of LFA manageability draft including all the= comments we gathered. Feel free to raise any new suggestion/comment on the content. Best Regards, Stephane =20 -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : lundi 18 f=E9vrier 2013 13:20 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-litkowski-rtgwg-lfa-manageability-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Operational management of Loop Free Alternates Author(s) : Stephane Litkowski Bruno Decraene Clarence Filsfils Kamran Raza Filename : draft-litkowski-rtgwg-lfa-manageability-01.txt Pages : 17 Date : 2013-02-18 Abstract: Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic (and MPLS LDP traffic by extension). Following first deployment experiences, this document provides operational feedback on LFA, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications. This proposal is also applicable to remote LFA solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-litkowski-rtgwg-lfa-manageability There's also a htmlized version available at: http://tools.ietf.org/html/draft-litkowski-rtgwg-lfa-manageability-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-litkowski-rtgwg-lfa-manageability-= 01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt ___________________________________________________________________________= ______________________________________________ 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 Mon Feb 18 04:31:14 2013 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 AAB3C21F8763 for ; Mon, 18 Feb 2013 04:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.485 X-Spam-Level: X-Spam-Status: No, score=-1.485 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lh-69Dn4Hv4b for ; Mon, 18 Feb 2013 04:31:14 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E07AB21F8765 for ; Mon, 18 Feb 2013 04:31:13 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 7638E3B4067 for ; Mon, 18 Feb 2013 13:31:12 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 568BD23805C for ; Mon, 18 Feb 2013 13:31:12 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.53]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Mon, 18 Feb 2013 13:31:12 +0100 From: To: "rtgwg@ietf.org" Date: Mon, 18 Feb 2013 13:29:04 +0100 Subject: TR: I-D Action: draft-litkowski-rtgwg-uloop-delay-00.txt Thread-Topic: I-D Action: draft-litkowski-rtgwg-uloop-delay-00.txt Thread-Index: Ac4Li1LgZmXCtg+jR4OO1QqGrfLPNQCR2Jmw Message-ID: <31088_1361190672_51221F10_31088_7335_1_EEE55384044474429A926C625D0FCC81063D5E7C43@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.18.120328 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: Mon, 18 Feb 2013 12:31:14 -0000 Hi, We posted a "new" proposal for preventing a subset of transient forwarding = loops in IP networks. The subject and solution are not really new but as we can see, no solution = are available today in routers even if discussions are existing for years ! Transient forwarding loops are a real problem for IP networks and we (servi= ce providers) need working and implementable solutions in this area. Thanks to provide a feedback on this proposal. Best Regards, Stephane -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : vendredi 15 f=E9vrier 2013 15:46 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-litkowski-rtgwg-uloop-delay-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Microloop prevention by introducting a local convergence= delay Author(s) : Stephane Litkowski Bruno Decraene Pierre Francois Filename : draft-litkowski-rtgwg-uloop-delay-00.txt Pages : 11 Date : 2013-02-15 Abstract: This document describes a mechanism for link-state routing protocols to prevent a subset of transient loops during topology changes. It introduces a two-step convergence by introducing a delay between the network wide convergence and the node advertising the failure. As the network wide convergence is delayed in case of down events, this mechanism can be used for planned maintenance or for unplanned outage provided a fast reroute mechanism is used in conjunction to convert a failure into a less urgent topology change. Simulation using real network topologies and costs, with pathological convergence behaviour, have been performed. While the proposed mechanism does not provide a complete solution, it is simple and it solves an interesting fraction of the transient loops in the analyzed SP topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-litkowski-rtgwg-uloop-delay There's also a htmlized version available at: http://tools.ietf.org/html/draft-litkowski-rtgwg-uloop-delay-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt ___________________________________________________________________________= ______________________________________________ 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 Mon Feb 18 05:07:59 2013 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 DD8D121F8810 for ; Mon, 18 Feb 2013 05:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDZLj--qTgYm for ; Mon, 18 Feb 2013 05:07:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1270221F87A5 for ; Mon, 18 Feb 2013 05:07:59 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 70F1118C863 for ; Mon, 18 Feb 2013 14:07:58 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 58D4223804B for ; Mon, 18 Feb 2013 14:07:58 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.53]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 18 Feb 2013 14:07:58 +0100 From: To: "rtgwg@ietf.org" Date: Mon, 18 Feb 2013 14:07:58 +0100 Subject: TR: I-D Action: draft-litkowski-rtgwg-lfa-rsvpte-cooperation-01.txt Thread-Topic: I-D Action: draft-litkowski-rtgwg-lfa-rsvpte-cooperation-01.txt Thread-Index: Ac4NxFathbiasWZTQFig9CBmDBlksgAE/6/Q Message-ID: <7351_1361192878_512227AE_7351_751_1_EEE55384044474429A926C625D0FCC81063D5E7CA2@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" 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.10.24.110314 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: Mon, 18 Feb 2013 13:08:00 -0000 Hi all, We would like to receive feedback on the new version of lfa-rsvpte-cooperat= ion draft. This version should be easier to read and understand. The document provides guidelines on how LFA and RSVP-TE could be used toget= her within a network. This guidelines are really important as we can observ= e today that implementations are today working differently and we cannot en= sure a consistent behavior/design in a multivendor network. We tried to keep both mechanism as more independent as possible to limit in= terprocess communication within routers while we tried also to keep the fle= xibility to use them together on a single node/interface. Thanks to provide your feedback and concerns regarding the content. Best Regards, Stephane -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : lundi 18 f=E9vrier 2013 11:40 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-litkowski-rtgwg-lfa-rsvpte-cooperation-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Interactions between LFA and RSVP-TE Author(s) : Stephane Litkowski Bruno Decraene Clarence FilsFils Kamran Raza Filename : draft-litkowski-rtgwg-lfa-rsvpte-cooperation-01.txt Pages : 12 Date : 2013-02-18 Abstract: This document defines the behavior of a node supporting Loopfree Alternates (LFA) when the node has established RSVP TE tunnels. It first describes the decisions to be made by the LFA mechanism with respect to the use of TE tunnels as LFA candidates. Second, it discusses the use of RSVP TE tunnels as a way to complement the LFA coverage, illustrating how these technologies can benefit from each other. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-litkowski-rtgwg-lfa-rsvpte-cooperati= on There's also a htmlized version available at: http://tools.ietf.org/html/draft-litkowski-rtgwg-lfa-rsvpte-cooperation-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-litkowski-rtgwg-lfa-rsvpte-coopera= tion-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt ___________________________________________________________________________= ______________________________________________ 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 akatlas@gmail.com Tue Feb 19 20:21:04 2013 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 13F5D21F8855 for ; Tue, 19 Feb 2013 20:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+XAF6Rlb00b for ; Tue, 19 Feb 2013 20:21:03 -0800 (PST) Received: from mail-ie0-x231.google.com (ie-in-x0231.1e100.net [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 76EFD21F887F for ; Tue, 19 Feb 2013 20:21:03 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id 16so9444712iea.22 for ; Tue, 19 Feb 2013 20:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Z1uu5DUI0Iwh1cLKrW5vqxOs4gOa2ihETPftWNA0NtQ=; b=mB5iG98RZGerIl+n8Z+n9GT8GwSp4d/oKqqpVl0u04sFyok4K4n1ZkV7OgYbUsph4h TkcKEHUrYd57aZ0DGpoSNlljOwuMD7SIXCmmi3xvqulsmMud2sBm2LwMlhFIkseDGcaI HGuekHvMJ+iacOOBo9yIYXz7Qgmo43e187+KcFGV9EKe6qP4o9z3e9CsySnsidJbbfx+ oW0B4AuFjW2aBqddSzDPwKhO177bZUAiRfjBtPZkv/lmMo6HZXQzmK9M5g4rAb65njIV N4OA3uj3JTyQ74QOiYEKu+ZST527eRWRvy7RwzwdqaGr4JFAN43eiS8oHF4HkTSgy8+u n3QQ== MIME-Version: 1.0 X-Received: by 10.50.17.131 with SMTP id o3mr9897110igd.112.1361334063058; Tue, 19 Feb 2013 20:21:03 -0800 (PST) Received: by 10.64.34.203 with HTTP; Tue, 19 Feb 2013 20:21:02 -0800 (PST) Date: Tue, 19 Feb 2013 23:21:02 -0500 Message-ID: Subject: seeking anonymized network topologies for MRT & fast-reroute analysis From: Alia Atlas To: rtgwg@ietf.org Content-Type: multipart/alternative; boundary=14dae934049f3fceaf04d62049cf 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, 20 Feb 2013 04:21:04 -0000 --14dae934049f3fceaf04d62049cf Content-Type: text/plain; charset=ISO-8859-1 (WG-chair hat firmly off) I am working on getting an analysis of the various fast-reroute technologies (MRT, not-via, optimal, Remote LFA) on different networks. Specifically, I want to update draft-enyedi-rtgwg-mrt-frr-algorithm with the method and results of analysis so that we can draw some conclusions about which MRT algorithm to select for unicast fast-reroute and how much difference the selection of the GADAG root makes. To do this, I could use as many real network topologies as possible. While it's interesting to analyze arbitrary topologies, what is really meaningful is looking at the topologies that are used. For a network topology, I need a list of routers (router-name, IP-addresses) and a list of one-way links (local-router-name, local-interface-name, remote-route-name, remote-interface-name, IGP metric). The IP-addresses and router-names just have to be unique; what they are doesn't matter (IP addresses slightly for tie-breaking, but very minorly). I can also automatically translate the output of 'show isis database detail' and such, via Cariden. If you have such a model and would not be adverse to privately sharing it, with the understanding that no identifying information would be included or shared in the summarized analysis, I'd greatly appreciate it. Obviously, I have some networks that I'm looking at already, but the more the better the results. I'm also happy to discuss the methods that I'm using the compare the algorithms and their results. Thanks, Alia --14dae934049f3fceaf04d62049cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (WG-chair hat firmly off)

    I am working on getting an ana= lysis of the various fast-reroute technologies (MRT, not-via, optimal, Remo= te LFA) on different networks. =A0Specifically, I want to update draft-enye= di-rtgwg-mrt-frr-algorithm with the method and results of analysis so that = we can draw some conclusions about which MRT algorithm to select for unicas= t fast-reroute and how much difference the selection of =A0the GADAG root m= akes.

    To do this, I could use as many real network topologies= as possible. =A0While it's interesting to analyze arbitrary topologies= , what is really meaningful is looking at the topologies that are used.

    For a network topology, I need a list of routers (route= r-name, IP-addresses) and a list of one-way links (local-router-name, local= -interface-name, remote-route-name, remote-interface-name, IGP metric). =A0= The IP-addresses and router-names just have to be unique; what they are doe= sn't matter (IP addresses slightly for tie-breaking, but very minorly).= =A0I can also automatically translate the output of 'show isis databas= e detail' and such, via Cariden.

    If you have such a model and would not be adverse to pr= ivately sharing it, with the understanding that no identifying information = would be included or shared in the summarized analysis, I'd greatly app= reciate it.

    Obviously, I have some networks that I'm looking at= already, but the more the better the results.

    I&#= 39;m also happy to discuss the methods that I'm using the compare the a= lgorithms and their results.

    Thanks,
    Alia
    --14dae934049f3fceaf04d62049cf-- From akatlas@gmail.com Thu Feb 21 11:41:37 2013 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 2D94121F8F30 for ; Thu, 21 Feb 2013 11:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sWhLltwYaDT for ; Thu, 21 Feb 2013 11:41:36 -0800 (PST) Received: from mail-ie0-x22d.google.com (ie-in-x022d.1e100.net [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C284521F8F1E for ; Thu, 21 Feb 2013 11:41:36 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id 9so11797221iec.4 for ; Thu, 21 Feb 2013 11:41:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=VMH8szha8J3EgxP5K0sHZCb3RukjStdLhaki5oGwD/U=; b=tUh1v1IiOWGwDzByLvl95F7TPcjX3K6Uztnz0xzWbRtbgSpzecnx8tJoi0rQV8Us2j 5P/7brVza0ipmr3sUNMOVyyskqUu9SAeBtaJcbRaeZ6QPzXfRS6noqgxxNrK3UUEF35Z 25caGfcLVsmpk3kAka6RkOJtg8XkMUll2GVi97mLtSfiw/UKlfnpx7fDueTL/ZrZYf5T /IPwdsBm71XPEiDErIbwjOSQUKkzymQqafSI+i3B2OH5Ns05n9GMUWnKGRWd+rqoaH82 MfiXJ9YzU/G9wDzRBTfjUl2uibUeUNOzkWb1uVgmAEFlNV8sj4Iv7V6KZWeyud6uCr8b P0Cw== MIME-Version: 1.0 X-Received: by 10.50.178.105 with SMTP id cx9mr34432igc.111.1361475696241; Thu, 21 Feb 2013 11:41:36 -0800 (PST) Received: by 10.64.34.203 with HTTP; Thu, 21 Feb 2013 11:41:36 -0800 (PST) Date: Thu, 21 Feb 2013 14:41:36 -0500 Message-ID: Subject: WGLC on draft-ietf-rtgwg-cl-requirements-09 From: Alia Atlas To: rtgwg@ietf.org Content-Type: multipart/alternative; boundary=e89a8f8388853eac4a04d6414305 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, 21 Feb 2013 19:41:37 -0000 --e89a8f8388853eac4a04d6414305 Content-Type: text/plain; charset=ISO-8859-1 This is to start a working group last call on draft-ietf-rtgwg-cl-requirements-09. The WGLC will conclude on March 15; extra time is given to include the IETF meeting. Please read and send comments. Thanks, Alia & Alvaro --e89a8f8388853eac4a04d6414305 Content-Type: text/html; charset=ISO-8859-1 This is to start a working group last call on draft-ietf-rtgwg-cl-requirements-09.
    The WGLC will conclude on March 15; extra time is given to include the IETF meeting.

    Please read and send comments.

    Thanks,
    Alia & Alvaro
    --e89a8f8388853eac4a04d6414305-- From akatlas@gmail.com Thu Feb 21 11:48:03 2013 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 08F9521F8F65 for ; Thu, 21 Feb 2013 11:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVVTo2h5CDIa for ; Thu, 21 Feb 2013 11:48:02 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6A86421F8F5F for ; Thu, 21 Feb 2013 11:48:02 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id k14so11697462iea.41 for ; Thu, 21 Feb 2013 11:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=8NSdYHkVk3bnr0FKJcmzd1EOU1/vIHSSv4t6yG1Ilsw=; b=nkDvJTI3B9aKiLHbaosuuvnbu8zHE8snEQr7BVB6viwa7SHOfKm+y5Vz6T+clKJrQY gKjv6F7LFwFLtQUwWHztJYHTJvBcQYN1xM0b7stqdtFjM/I2Y3Kv5++g69dlp0pipsj5 noT/ohh3qH+9IJnLob5AN5+1UwXwoMJwsXlB7Pn2r5p5lBV3V7hyJSmnSnxBMiVyVYw8 GyiWp/I61FxLZYH2BLn4COXTn+auGsyDAv08Qe0PUO/FEQeGomgzygo2R1zRiHBviPxG 9JT+mSI6J2xqDFnbzJNKEeLBnagCGm/Y5I5fhDtj1jMqaWuNnY3S+gAjEvRsQhKZVmIq 3plw== MIME-Version: 1.0 X-Received: by 10.50.153.198 with SMTP id vi6mr13862451igb.112.1361476081289; Thu, 21 Feb 2013 11:48:01 -0800 (PST) Received: by 10.64.34.203 with HTTP; Thu, 21 Feb 2013 11:48:01 -0800 (PST) Date: Thu, 21 Feb 2013 14:48:01 -0500 Message-ID: Subject: comments on: draft-ietf-rtgwg-cl-requirement-09 From: Alia Atlas To: rtgwg@ietf.org Content-Type: multipart/alternative; boundary=e89a8f22c681320c4a04d6415a9f 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, 21 Feb 2013 19:48:03 -0000 --e89a8f22c681320c4a04d6415a9f Content-Type: text/plain; charset=ISO-8859-1 Just one quick comment - the last paragraph in the abstract "Current practice related to multipath is described briefly in an appendix." is incorrect. The abstract is something different (definitions); I think this dates from an earlier version and should be removed. Alia --e89a8f22c681320c4a04d6415a9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just one quick comment - the last paragraph in the abstract
    "Current practice related to multipath is described= briefly in an=A0appendix." is in= correct.
    The abstract is something different (def= initions); I think this dates from an earlier version and should
    be removed.

    Alia
    --e89a8f22c681320c4a04d6415a9f-- From curtis@occnc.com Thu Feb 21 22:03:55 2013 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 C8D1421F8578 for ; Thu, 21 Feb 2013 22:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.372 X-Spam-Level: X-Spam-Status: No, score=-0.372 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+Vu+v3yk87Q for ; Thu, 21 Feb 2013 22:03:55 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 073E221F8558 for ; Thu, 21 Feb 2013 22:03:54 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r1M61NKe003394; Fri, 22 Feb 2013 01:01:23 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201302220601.r1M61NKe003394@gateway1.orleans.occnc.com> To: Alia Atlas From: Curtis Villamizar Subject: Re: comments on: draft-ietf-rtgwg-cl-requirement-09 In-reply-to: Your message of "Thu, 21 Feb 2013 14:48:01 EST." Date: Fri, 22 Feb 2013 01:01:23 -0500 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: Fri, 22 Feb 2013 06:03:55 -0000 In message Alia Atlas writes: > Just one quick comment - the last paragraph in the abstract "Current > practice related to multipath is described briefly in an appendix." > is incorrect. The abstract is something different (definitions); I > think this dates from an earlier version and should be removed. > > Alia Thanks you. Will change this. Curtis From akatlas@gmail.com Fri Feb 22 09:39:26 2013 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 5C93E21F8E7A for ; Fri, 22 Feb 2013 09:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dsm9VCQKl41C for ; Fri, 22 Feb 2013 09:39:25 -0800 (PST) Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id CA47621F8E71 for ; Fri, 22 Feb 2013 09:39:25 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id k38so755070iah.13 for ; Fri, 22 Feb 2013 09:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=f94z36KilFD2GJiuJko+uLxgwYE3bSyE8YoL3/nnRHw=; b=0OnCgsojJ3ZThiAbhpnUR90RfIFPdCY/XBHuy77a4hSlr4TY0G7MQuAywENqMxBOa2 L5UDddMDvkx4xGLtb6ozk5/ypFgee6rNwI6PYVZHqTPfGElgR0G39TWnxylCK/n5dJPI GsTCuMFQX9y9wwjlfkfXtUxsQ2PMY3Xxyai3yMLh4nOQkg/YId2k6mLNdSOBcEsJGs9/ Mr2eIzGU94bS1IiDe3hcoSYJzjuc8PBjslQVZ5VNoWpgbcYSTn620qrSd/anCvUpruUz yzcCx4dBj91YK44TApEZAS4M/PT0AizanQDdRAMPOm7S5wk0x29+8GOFZ/OInFqUKjke rOuw== MIME-Version: 1.0 X-Received: by 10.50.56.141 with SMTP id a13mr32446igq.24.1361554765459; Fri, 22 Feb 2013 09:39:25 -0800 (PST) Received: by 10.64.34.203 with HTTP; Fri, 22 Feb 2013 09:39:25 -0800 (PST) In-Reply-To: <20130222161824.23195.40206.idtracker@ietfa.amsl.com> References: <20130222161824.23195.40206.idtracker@ietfa.amsl.com> Date: Fri, 22 Feb 2013 12:39:25 -0500 Message-ID: Subject: Fwd: Internet Draft Final Submission Cut-Off Monday, February 25 From: Alia Atlas To: rtgwg@ietf.org Content-Type: multipart/alternative; boundary=f46d0401f53d233cf504d653aca9 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: Fri, 22 Feb 2013 17:39:26 -0000 --f46d0401f53d233cf504d653aca9 Content-Type: text/plain; charset=ISO-8859-1 friendly reminder ---------- Forwarded message ---------- From: Internet-Drafts Administrator Date: Fri, Feb 22, 2013 at 11:18 AM Subject: Internet Draft Final Submission Cut-Off Monday, February 25 To: IETF Announcement List Cc: ietf@ietf.org This is a reminder that the Internet Draft Final Submission (version -01 and up) cut-off is Monday, February 25, 2013. All Final Version (-01 and up) submissions are due by UTC 24:00 Monday, February 25. All drafts can be uploaded using the ID submission tool located here: https://datatracker.ietf.org/submit/ The Internet-Draft cutoff dates as well as other significant dates for IETF 86 can be found at: https://www.ietf.org/meeting/cutoff-dates-2013.html#IETF86 Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. --f46d0401f53d233cf504d653aca9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable friendly reminder

    ---------- Forwarded me= ssage ----------
    From: Internet-Drafts Adm= inistrator <internet-drafts@ietf.org>
    Date: Fri, Feb 22, 2013 at 11:18 AM
    Subject: Internet Draft Final Submis= sion Cut-Off Monday, February 25
    To: IETF Announcement List <ietf-announce@ietf.org>
    Cc: ietf@ietf.org


    This is a reminder that the Internet Draft Final Submission (versio= n -01
    and up) cut-off is Monday, February 25, 2013.

    All Final Version (-01 and up) submissions are due by UTC 24:00 Monday, Feb= ruary 25.

    All drafts can be uploaded using the ID submission tool located here:
    https://= datatracker.ietf.org/submit/

    The Internet-Draft cutoff dates as well as other significant dates for IETF= 86 can be found at:
    https://www.ietf.org/meeting/cutoff-dates-2013.html#IETF86

    Thank you for your understanding and cooperation. If you have any =A0questi= ons or concerns, then please send a message to     internet-drafts@ietf.org.

    --f46d0401f53d233cf504d653aca9-- From internet-drafts@ietf.org Mon Feb 25 10:30:05 2013 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 63B3621E8089; Mon, 25 Feb 2013 10:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnwvWSzJRzNA; Mon, 25 Feb 2013 10:30:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E0E21F91DD; Mon, 25 Feb 2013 10:30:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-mrt-frr-architecture-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225183004.10156.29783.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 10:30:04 -0800 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: Mon, 25 Feb 2013 18:30:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : An Architecture for IP/LDP Fast-Reroute Using Maximally = Redundant Trees Author(s) : Alia Atlas Robert Kebler Gabor Sandor Enyedi Andras Csaszar Jeff Tantsura Maciek Konstantynowicz Russ White Mike Shand Filename : draft-ietf-rtgwg-mrt-frr-architecture-02.txt Pages : 27 Date : 2013-02-25 Abstract: As IP and LDP Fast-Reroute are increasingly deployed, the coverage limitations of Loop-Free Alternates are seen as a problem that requires a straightforward and consistent solution for IP and LDP, for unicast and multicast. This draft describes an architecture based on redundant backup trees where a single failure can cut a point-of-local-repair from the destination only on one of the pair of redundant trees. One innovative algorithm to compute such topologies is maximally disjoint backup trees. Each router can compute its next-hops for each pair of maximally disjoint trees rooted at each node in the IGP area with computational complexity similar to that required by Dijkstra. The additional state, address and computation requirements are believed to be significantly less than the Not-Via architecture requires. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-architecture There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-mrt-frr-architecture-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-mrt-frr-architecture-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From aretana@cisco.com Tue Feb 26 09:12:27 2013 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 564F121F8A08 for ; Tue, 26 Feb 2013 09:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1gPd7cAfZMJ for ; Tue, 26 Feb 2013 09:12:26 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 70D4021F89EE for ; Tue, 26 Feb 2013 09:12:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4541; q=dns/txt; s=iport; t=1361898746; x=1363108346; h=from:to:subject:date:message-id:mime-version; bh=GY2ZdxKnWS8IauOlj7kiutPQ7AuIx64vPWZJYNJYi0g=; b=S26WB347O4iWBBV57xuUP4zzEUyEkTZZO7hfMgAUvLv1YmtQf/KiTaxX GWInEw5akkk/Tf5RHIdbq3+bCFVQMmKZ2ALaflBsfy9KJmuzey3CikO+I mscZyN3SiYRhUaxICQCj1aCH45MYkiDmTyWl0P80kohzGXJ37X48UR35R A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoLAK7sLFGtJXG9/2dsb2JhbABFgkOFJrl/fxZzgiEBBIELAQweC0snBBsBiAoMnmeRFZAEjVSBD0KCVWEDkn+UKYMIgic X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208,217";a="181168819" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 26 Feb 2013 17:12:26 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1QHCPNO027231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 Feb 2013 17:12:25 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.213]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 11:12:25 -0600 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: rtgwg Agenda Posted (IETF 86) Thread-Topic: rtgwg Agenda Posted (IETF 86) Thread-Index: AQHOFERydNLhMqCDIkWR4pQqWXWpCw== Date: Tue, 26 Feb 2013 17:12:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.223.130] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94ED8970Bxmbalnx15ciscocom_" 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: Tue, 26 Feb 2013 17:12:27 -0000 --_000_BBD66FD99311804F80324E8139B3C94ED8970Bxmbalnx15ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/proceedings/86/agenda/agenda-86-rtgwg As you can see, we have received a significant number of presentation reque= sts and are out of time. We will dedicate the second hour of the meeting to power-aware/energy-effic= ient networking. According to the WG's charter, rtgwg is the appropriate p= lace to discuss topics that are not ready for their own WG/BOF and that are= related to routing. Please be clear that this section of the meeting shou= ld not be considered a BOF or side-meeting or any other such construct targ= eted at potentially creating a WG. The goal is to discuss the technology a= nd potential work items, if any, that the WG may take on. Ideally we would= reach agreement (pending discussion on the list, of course) on what the to= pic covers, what may belong in the IETF at this time, and whether there is = interest in doing any work. We have asked all the presenters to start a discussion on the list about th= eir drafts, pointing out the parts they would like the most feedback on. T= he intention is to both have an idea of the initial interest and for the co= ntent to not be completely new at the in-person meeting, hopefully resultin= g in better discussions. Please take a look and make comments on line. Note to presenters: The time on the agenda includes presentation and discu= ssion, so please plan accordingly. Given that the WG meeting is scheduled = for Wednesday, and taking other commitments into account, we MUST receive a= ll presentations by the end of the day on Monday Mar/11 (pick your favorite= timezone). The chairs MAY change the order of the presentations based on = slide availability. Thanks! Alvaro. --_000_BBD66FD99311804F80324E8139B3C94ED8970Bxmbalnx15ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4F9CA4B45D532D45899697C4EA7C21EE@cisco.com> Content-Transfer-Encoding: quoted-printable


    As you can see, we have received a significant number of presentation = requests and are out of time. 

    We will dedicate the second hour of the meeting to power-aware/energy-= efficient networking.  According to the WG's charter, rtgwg is the app= ropriate place to discuss topics that are not ready for their own WG/BOF an= d that are related to routing.  Please be clear that this section of the meeting should not be considered a BOF o= r side-meeting or any other such construct targeted at potentially creating= a WG.  The goal is to discuss the technology and potential work items= , if any, that the WG may take on.  Ideally we would reach agreement (pending discussion on the list, of course) on wh= at the topic covers, what may belong in the IETF at this time, and whether = there is interest in doing any work.

    We have asked all the presenters to start a discussion on the list abo= ut their drafts, pointing out the parts they would like the most feedback o= n.  The intention is to both have an idea of the initial interest and = for the content to not be completely new at the in-person meeting, hopefully resulting in better discussions. &= nbsp;Please take a look and make comments on line.

    Note to presenters:  The time on the agenda includes presentation= and discussion, so please plan accordingly.  Given that the WG meetin= g is scheduled for Wednesday, and taking other commitments into account, we= MUST receive all presentations by the end of the day on Monday Mar/11 (pick your favorite timezone).  The chair= s MAY change the order of the presentations based on slide availability.

    Thanks!

    Alvaro.
    --_000_BBD66FD99311804F80324E8139B3C94ED8970Bxmbalnx15ciscocom_-- From akatlas@gmail.com Wed Feb 27 09:57:43 2013 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 6218321F8873 for ; Wed, 27 Feb 2013 09:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJr49yli2vY0 for ; Wed, 27 Feb 2013 09:57:35 -0800 (PST) Received: from mail-ia0-x22c.google.com (mail-ia0-x22c.google.com [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8C12D21F8611 for ; Wed, 27 Feb 2013 09:57:32 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id l29so722173iag.31 for ; Wed, 27 Feb 2013 09:57:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=YQMS2HmVd1GVtXTY9nJDkkgMAs2Sy8FXa/nufIwBGRc=; b=xofK0slf+9fQYwG3qVebhYjoEQX7cJGxVvdp+f6bEgoBg0xrugiDb3AmDVb9uFffHh 1D7NAsgWUUfXiMvanPCa/VKnbJzUyu8i3EXdjXNI5wr4DA6gCqkF+C/EGsECNlaFpVKs 5CRWeghBSiNdXWdAQ/la+akpAYbvLMbAYaOJ2IhOY1DPWc0VZUUUlzGe9gon6ryVgBVM LbsLg/WumMH6Nx/PDIVdY1a41J2l1TtTu+JVnt9Xcrn+QNKsgQCmD12kf6eucDacxmc5 08NBEOBckEjGbN/p48tIUwux7SD7s995NDRaJrbO2jx3TWri7fj7honiwl2rJj5ALqGn NHmQ== MIME-Version: 1.0 X-Received: by 10.50.178.105 with SMTP id cx9mr7789898igc.111.1361987852123; Wed, 27 Feb 2013 09:57:32 -0800 (PST) Received: by 10.64.34.203 with HTTP; Wed, 27 Feb 2013 09:57:32 -0800 (PST) Date: Wed, 27 Feb 2013 09:57:32 -0800 Message-ID: Subject: remote participation 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, 27 Feb 2013 17:57:43 -0000 Is anyone planning on attending the WG meeting remotely? We can sign up for a meetecho session if that would be useful, but must do it soon. Please let me know. Also, volunteers for jabber scribes and minute-takers would be greatly welcome ahead of time. Regards, Alia From stbryant@cisco.com Thu Feb 28 07:03:53 2013 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 46F8D21F8BE0 for ; Thu, 28 Feb 2013 07:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.587 X-Spam-Level: X-Spam-Status: No, score=-110.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcDOgxnXCJZ2 for ; Thu, 28 Feb 2013 07:03:52 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 539C821F8BDE for ; Thu, 28 Feb 2013 07:03:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5365; q=dns/txt; s=iport; t=1362063831; x=1363273431; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=YOw1+QxRZPyTiyrgz08rTPabwDcFZH7DlsupJrBgwt0=; b=HrYF5EvPK653899euWf9mREWQYKqCLYA+sROkzJZmPKpF1UVqzYr14AW +6Fz74R1gSf9YVQkSdbIjivyJqATnhjMnEQ+zh6OVx/Q5Bh3r2gyku7SS LID8CSVxgtupLCS28CagctudxarCk7hJzKZwsDper/+g3Xsl6+bg0vAmK g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAIJxL1GQ/khL/2dsb2JhbABFwix6FnOCHwEBAQQBAQE1LwcKAQwECxEEAQEBCRYIBwkDAgECARUfCQgTAQUCAQGIDwzBWY04G4EfFwYFBwaDOgOWQYEej0yDCIFy X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="12135437" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 28 Feb 2013 15:03:36 +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 r1SF3a1p024438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 15:03:36 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r1SF3avF017612; Thu, 28 Feb 2013 15:03:36 GMT Message-ID: <512F71C8.4050300@cisco.com> Date: Thu, 28 Feb 2013 15:03:36 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: rtgwg@ietf.org Subject: Re: A query on RIPv2 References: <35347FBF2796F94E936EE76C0E6047ED2B643823@BLRKECMBX13.ad.infosys.com>, <1C717044A9DD904E83DBD133393FD8D00843EFAD@szxeml525-mbs.china.huawei.com> <35347FBF2796F94E936EE76C0E6047ED2D11A681@BLRKECMBX12.ad.infosys.com> In-Reply-To: <35347FBF2796F94E936EE76C0E6047ED2D11A681@BLRKECMBX12.ad.infosys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Farrel 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, 28 Feb 2013 15:03:53 -0000 The confusion seems to be whether the AH, which gets carried as a special type of RIP entry, is an RTE or not. I can see arguments both ways, although the fact that this has taken 25 years to surface suggests that most implementers have subscribed to a common view that the an AH is not an RTE, and therefore the RFC is correct. I propose that we close this as an errata to be fixed in next version with the statement: "Some readers have been confused as to whether an AH is considered to be an RTE. The consensus view it that that it is not. If this RFC is revised, some clarifying text should be added." Is that a reasonable way forward? Stewart On 02/01/2013 06:08, Bharat Joshi wrote: > Dear Gopakumar, > > I understand what you are saying. In fact, I tested some vendor's behaviour to understand how other people have implemented it. > > When authentication is enabled, there should be 2 route entries for things to work but I still feel that the RFC is not clear enough on this. In fact, in my search, I found that Quagga has issues with this. > > Regards, > Bharat > ________________________________________ > From: Gopakumar C [gopakumar.c@huawei.com] > Sent: Wednesday, January 02, 2013 11:05 AM > To: Bharat Joshi; rtgwg@ietf.org > Subject: RE: A query on RIPv2 > > Dear Bharat, > > In the scenario that you mentioned RIP packet will have two RTEs after the RIP header, first one will be authentication RTE and second one will be FULL table request RTE with address family identifier as 0. This may be followed by authentication trailer depending on the authentication scheme selected. > > RFC section 3.9.1 first states the general format of RIP Version 2 request message. Even though authentication is present, there is only one RTE (full table RTE) other than authentication as authentication RTE doesn't convey routing information. > > Hope this helps. > > Note: I think this is not correct forum to discuss this issue. I am not sure where you can post it as RIP mailing list is not active anymore. > > Regards, > -Gopakumar > > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Bharat Joshi > Sent: Tuesday, December 25, 2012 4:02 PM > To: rtgwg@ietf.org > Cc: Bharat Joshi > Subject: A query on RIPv2 > > Hi All, > > I came across some text in RFC 2453 (RIPv2) which has confused me. It would be great if someone can clarify this for me. I searched the net and looked through the errata but could not find any reference to this. > > In section 3.9.1 of RFC 2453 (http://tools.ietf.org/html/rfc2453#section-3.9.1), in second para, following text is available: > > > > There is one special case. If there is exactly > one entry in the request, and it has an address family identifier of > zero and a metric of infinity (i.e., 16), then this is a request to > send the entire routing table. > > > > In section 4.1 of same RFC (http://tools.ietf.org/html/rfc2453#section-4.1), in first para, following text is available: > > > > If the Address Family Identifier of the first (and > only the first) entry in the message is 0xFFFF, then the remainder of > the entry contains the authentication. > > > > Now what has confused me is that if a router is configured to use authentication, how should its 'request' message for full routing table look? Should it go without authentication information or with authentication information? > > If it goes with authentication information then it is not conforming to the statement of 3.9.1. If it goes without authentication information then it is not conforming to the user configuration and also there may be security issues. > > Regards, > Bharat > > PS: I am currently not subscribed to RTG working group mailing list, so please reply all so that I can get your reply. > > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely > for the use of the addressee(s). If you are not the intended recipient, please > notify the sender by e-mail and delete the original message. Further, you are not > to copy, disclose, or distribute this e-mail or its contents to any other person and > any such actions are unlawful. This e-mail may contain viruses. Infosys has taken > every reasonable precaution to minimize this risk, but is not liable for any damage > you may sustain as a result of any virus in this e-mail. You should carry out your > own virus checks before opening the e-mail or attachment. Infosys reserves the > right to monitor and review the content of all messages sent to or from this e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > _______________________________________________ > 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 > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From acee.lindem@ericsson.com Thu Feb 28 07:44:27 2013 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 211FF21F87AC for ; Thu, 28 Feb 2013 07:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDyJ0wz5105O for ; Thu, 28 Feb 2013 07:44:26 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id EE33721F8793 for ; Thu, 28 Feb 2013 07:44:25 -0800 (PST) X-AuditID: c6180641-b7faf6d00000096b-55-512f7b50930a Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 10.9C.02411.05B7F215; Thu, 28 Feb 2013 16:44:16 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0318.004; Thu, 28 Feb 2013 10:44:15 -0500 From: Acee Lindem To: "" Subject: Re: A query on RIPv2 Thread-Topic: A query on RIPv2 Thread-Index: AQHOFcTYxV7Qrfx2T0u9GRksERvMJpiPvTGA Date: Thu, 28 Feb 2013 15:44:14 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470EB3F9@eusaamb101.ericsson.se> References: <35347FBF2796F94E936EE76C0E6047ED2B643823@BLRKECMBX13.ad.infosys.com>, <1C717044A9DD904E83DBD133393FD8D00843EFAD@szxeml525-mbs.china.huawei.com> <35347FBF2796F94E936EE76C0E6047ED2D11A681@BLRKECMBX12.ad.infosys.com> <512F71C8.4050300@cisco.com> In-Reply-To: <512F71C8.4050300@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <9F2A3672654AD544A8A13D6FA6EC7AA3@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXSPt25AtX6gwfKLehY/em4wW1x485vZ 4tzTOYwOzB5Tfm9k9Viy5CeTx4rNKxkDmKO4bFJSczLLUov07RK4MuZ8u8dUcMWgYvtplwbG DvUuRk4OCQETiT83epkhbDGJC/fWs3UxcnEICRxhlPh9+iojhLOcUWLpkdWsIFVsAjoSzx/9 A+sQEdCXOPJhJ5jNLOAjsWnONzBbWEBWYmXLU6gaOYnnfxcxQthGEieaN4PZLAKqEnsvHGAB sXkFvCVudh4HiwsJtDJJ7J0q2sXIwcEpoClx5A5YCSPQcd9PrWGCWCUucevJfCaIowUkluw5 D/WAqMTLx/9YIWxlie9zHrFA1OtILNj9iQ1kJLOAtcTD1VoQYW2JZQtfM0NcIChxcuYTlgmM 4rOQbJiFpHsWQvcsJN2zkHQvYGRdxchRWpxalptuZLiJERhjxyTYHHcwLvhkeYhRmoNFSZw3 1PVCgJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGC+60BfsTrup0TmLgnZ+wd/mf3byMWcL7 V+0x5hL8cER44r0DL8wfc7jKvbdpesTTypv101RWRk/jt8pK9nsBUzVOs78IrdnMs+77lOp/ SjfynlXof1zy/s9rhnuvMuJs/JRvcDF0TZw3y1H5S/+W0/mzPm+sbBTyrAk/sOOjtPGdnZ5L S3XvKLEUZyQaajEXFScCAOyqrnR/AgAA Cc: Adrian Farrel , "" 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, 28 Feb 2013 15:44:27 -0000 Hi Stewart,=20 To retain compatibility with RIPv1, the RIPv2 WG kept the packets formatted= as a variable number of 20 byte entries. The one containing the authentica= tion is, well, the authentication and, by definition, is not a route. I'm d= on't think this needs any clarification.=20 Thanks,=20 Acee=20 On Feb 28, 2013, at 10:03 AM, Stewart Bryant wrote: > The confusion seems to be whether the AH, which gets carried as > a special type of RIP entry, is an RTE or not. >=20 > I can see arguments both ways, although the fact that this has taken > 25 years to surface suggests that most implementers have > subscribed to a common view that the an AH is not an RTE, > and therefore the RFC is correct. >=20 > I propose that we close this as an errata to be fixed in next version > with the statement: >=20 > "Some readers have been confused as to whether an AH is considered > to be an RTE. The consensus view it that that it is not. If this > RFC is revised, some clarifying text should be added." >=20 > Is that a reasonable way forward? >=20 > Stewart >=20 >=20 >=20 >=20 > On 02/01/2013 06:08, Bharat Joshi wrote: >> Dear Gopakumar, >>=20 >> I understand what you are saying. In fact, I tested some vendor's= behaviour to understand how other people have implemented it. >>=20 >> When authentication is enabled, there should be 2 route entries f= or things to work but I still feel that the RFC is not clear enough on this= . In fact, in my search, I found that Quagga has issues with this. >>=20 >> Regards, >> Bharat >> ________________________________________ >> From: Gopakumar C [gopakumar.c@huawei.com] >> Sent: Wednesday, January 02, 2013 11:05 AM >> To: Bharat Joshi; rtgwg@ietf.org >> Subject: RE: A query on RIPv2 >>=20 >> Dear Bharat, >>=20 >> In the scenario that you mentioned RIP packet will have two RTEs after t= he RIP header, first one will be authentication RTE and second one will be = FULL table request RTE with address family identifier as 0. This may be fol= lowed by authentication trailer depending on the authentication scheme sele= cted. >>=20 >> RFC section 3.9.1 first states the general format of RIP Version 2 reque= st message. Even though authentication is present, there is only one RTE (f= ull table RTE) other than authentication as authentication RTE doesn't conv= ey routing information. >>=20 >> Hope this helps. >>=20 >> Note: I think this is not correct forum to discuss this issue. I am not = sure where you can post it as RIP mailing list is not active anymore. >>=20 >> Regards, >> -Gopakumar >>=20 >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf O= f Bharat Joshi >> Sent: Tuesday, December 25, 2012 4:02 PM >> To: rtgwg@ietf.org >> Cc: Bharat Joshi >> Subject: A query on RIPv2 >>=20 >> Hi All, >>=20 >> I came across some text in RFC 2453 (RIPv2) which has confused me. = It would be great if someone can clarify this for me. I searched the net an= d looked through the errata but could not find any reference to this. >>=20 >> In section 3.9.1 of RFC 2453 (http://tools.ietf.org/html/rfc2453#section= -3.9.1), in second para, following text is available: >>=20 >> >>=20 >> There is one special case. If there is exactly >> one entry in the request, and it has an address family identifier of >> zero and a metric of infinity (i.e., 16), then this is a request to >> send the entire routing table. >>=20 >> >>=20 >> In section 4.1 of same RFC (http://tools.ietf.org/html/rfc2453#section-4= .1), in first para, following text is available: >>=20 >> >>=20 >> If the Address Family Identifier of the first (and >> only the first) entry in the message is 0xFFFF, then the remainder of >> the entry contains the authentication. >>=20 >> >>=20 >> Now what has confused me is that if a router is configured to use au= thentication, how should its 'request' message for full routing table look?= Should it go without authentication information or with authentication inf= ormation? >>=20 >> If it goes with authentication information then it is not conforming= to the statement of 3.9.1. If it goes without authentication information t= hen it is not conforming to the user configuration and also there may be se= curity issues. >>=20 >> Regards, >> Bharat >>=20 >> PS: I am currently not subscribed to RTG working group mailing list, so = please reply all so that I can get your reply. >>=20 >>=20 >> **************** CAUTION - Disclaimer ***************** >> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended so= lely >> for the use of the addressee(s). If you are not the intended recipient, = please >> notify the sender by e-mail and delete the original message. Further, yo= u are not >> to copy, disclose, or distribute this e-mail or its contents to any othe= r person and >> any such actions are unlawful. This e-mail may contain viruses. Infosys = has taken >> every reasonable precaution to minimize this risk, but is not liable for= any damage >> you may sustain as a result of any virus in this e-mail. You should carr= y out your >> own virus checks before opening the e-mail or attachment. Infosys reserv= es the >> right to monitor and review the content of all messages sent to or from = this e-mail >> address. Messages sent to or from this e-mail address may be stored on t= he >> Infosys e-mail system. >> ***INFOSYS******** End of Disclaimer ********INFOSYS*** >> _______________________________________________ >> 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 >> . >>=20 >=20 >=20 > --=20 > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From stbryant@cisco.com Thu Feb 28 08:19:53 2013 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 237B021F8574 for ; Thu, 28 Feb 2013 08:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.587 X-Spam-Level: X-Spam-Status: No, score=-110.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImStTr3j1up4 for ; Thu, 28 Feb 2013 08:19:51 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3217521F856F for ; Thu, 28 Feb 2013 08:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6846; q=dns/txt; s=iport; t=1362068391; x=1363277991; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0JiBxZPlpVRC7M/nfBOxtN4PfVL2/hr+ShEYj/leVDg=; b=FyYSfTWlt/k1h80OVEFNpeCNLEXHJf9nXuIuN0v8OU+kS6lR/4ZmqRq/ mt8Khci+fD5fQND2m/5WDWNMw6MWKMFL/rQQh/Etn4KO3n5MDYFA4I9UL BAZOWZ3B5cKeVGnmLTLOJqVGJxnHCQWti2hc2FWwhENWvm6vWm/NRulr5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFACyDL1GQ/khL/2dsb2JhbABFwix6FnOCHwEBAQQBAQE1LwcKAQwECxEEAQEBCRYIBwkDAgECARUfCQgGDQEFAgEBiA8MwUaNOBuBHxcGBQcGgzoDlkGBHo9MgwiBcg X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="151034003" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 28 Feb 2013 16:19:50 +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 r1SGJnM2005667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 16:19:49 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r1SGJmVY023131; Thu, 28 Feb 2013 16:19:49 GMT Message-ID: <512F83A4.7010203@cisco.com> Date: Thu, 28 Feb 2013 16:19:48 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Acee Lindem Subject: Re: A query on RIPv2 References: <35347FBF2796F94E936EE76C0E6047ED2B643823@BLRKECMBX13.ad.infosys.com>, <1C717044A9DD904E83DBD133393FD8D00843EFAD@szxeml525-mbs.china.huawei.com> <35347FBF2796F94E936EE76C0E6047ED2D11A681@BLRKECMBX12.ad.infosys.com> <512F71C8.4050300@cisco.com> <94A203EA12AECE4BA92D42DBFFE0AE470EB3F9@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470EB3F9@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Farrel , "" 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, 28 Feb 2013 16:19:53 -0000 That is a valid response and I agree that the text is strictly correct. However there also appears to be an existence proof that more than one reader was confused (the reference to Quagga). It would be at least charitable to has some text somewhere that unconfused such a reader and the only way I can see to do this is either to add an accepted errata or a fixed in next version saying something like. In section 3.9.1 "Note that an authentication header is not considered to be an RTE". Yes/No/Other proposals? - Stewart On 28/02/2013 15:44, Acee Lindem wrote: > Hi Stewart, > To retain compatibility with RIPv1, the RIPv2 WG kept the packets formatted as a variable number of 20 byte entries. The one containing the authentication is, well, the authentication and, by definition, is not a route. I'm don't think this needs any clarification. > Thanks, > Acee > > On Feb 28, 2013, at 10:03 AM, Stewart Bryant wrote: > >> The confusion seems to be whether the AH, which gets carried as >> a special type of RIP entry, is an RTE or not. >> >> I can see arguments both ways, although the fact that this has taken >> 25 years to surface suggests that most implementers have >> subscribed to a common view that the an AH is not an RTE, >> and therefore the RFC is correct. >> >> I propose that we close this as an errata to be fixed in next version >> with the statement: >> >> "Some readers have been confused as to whether an AH is considered >> to be an RTE. The consensus view it that that it is not. If this >> RFC is revised, some clarifying text should be added." >> >> Is that a reasonable way forward? >> >> Stewart >> >> >> >> >> On 02/01/2013 06:08, Bharat Joshi wrote: >>> Dear Gopakumar, >>> >>> I understand what you are saying. In fact, I tested some vendor's behaviour to understand how other people have implemented it. >>> >>> When authentication is enabled, there should be 2 route entries for things to work but I still feel that the RFC is not clear enough on this. In fact, in my search, I found that Quagga has issues with this. >>> >>> Regards, >>> Bharat >>> ________________________________________ >>> From: Gopakumar C [gopakumar.c@huawei.com] >>> Sent: Wednesday, January 02, 2013 11:05 AM >>> To: Bharat Joshi; rtgwg@ietf.org >>> Subject: RE: A query on RIPv2 >>> >>> Dear Bharat, >>> >>> In the scenario that you mentioned RIP packet will have two RTEs after the RIP header, first one will be authentication RTE and second one will be FULL table request RTE with address family identifier as 0. This may be followed by authentication trailer depending on the authentication scheme selected. >>> >>> RFC section 3.9.1 first states the general format of RIP Version 2 request message. Even though authentication is present, there is only one RTE (full table RTE) other than authentication as authentication RTE doesn't convey routing information. >>> >>> Hope this helps. >>> >>> Note: I think this is not correct forum to discuss this issue. I am not sure where you can post it as RIP mailing list is not active anymore. >>> >>> Regards, >>> -Gopakumar >>> >>> -----Original Message----- >>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Bharat Joshi >>> Sent: Tuesday, December 25, 2012 4:02 PM >>> To: rtgwg@ietf.org >>> Cc: Bharat Joshi >>> Subject: A query on RIPv2 >>> >>> Hi All, >>> >>> I came across some text in RFC 2453 (RIPv2) which has confused me. It would be great if someone can clarify this for me. I searched the net and looked through the errata but could not find any reference to this. >>> >>> In section 3.9.1 of RFC 2453 (http://tools.ietf.org/html/rfc2453#section-3.9.1), in second para, following text is available: >>> >>> >>> >>> There is one special case. If there is exactly >>> one entry in the request, and it has an address family identifier of >>> zero and a metric of infinity (i.e., 16), then this is a request to >>> send the entire routing table. >>> >>> >>> >>> In section 4.1 of same RFC (http://tools.ietf.org/html/rfc2453#section-4.1), in first para, following text is available: >>> >>> >>> >>> If the Address Family Identifier of the first (and >>> only the first) entry in the message is 0xFFFF, then the remainder of >>> the entry contains the authentication. >>> >>> >>> >>> Now what has confused me is that if a router is configured to use authentication, how should its 'request' message for full routing table look? Should it go without authentication information or with authentication information? >>> >>> If it goes with authentication information then it is not conforming to the statement of 3.9.1. If it goes without authentication information then it is not conforming to the user configuration and also there may be security issues. >>> >>> Regards, >>> Bharat >>> >>> PS: I am currently not subscribed to RTG working group mailing list, so please reply all so that I can get your reply. >>> >>> >>> **************** CAUTION - Disclaimer ***************** >>> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely >>> for the use of the addressee(s). If you are not the intended recipient, please >>> notify the sender by e-mail and delete the original message. Further, you are not >>> to copy, disclose, or distribute this e-mail or its contents to any other person and >>> any such actions are unlawful. This e-mail may contain viruses. Infosys has taken >>> every reasonable precaution to minimize this risk, but is not liable for any damage >>> you may sustain as a result of any virus in this e-mail. You should carry out your >>> own virus checks before opening the e-mail or attachment. Infosys reserves the >>> right to monitor and review the content of all messages sent to or from this e-mail >>> address. Messages sent to or from this e-mail address may be stored on the >>> Infosys e-mail system. >>> ***INFOSYS******** End of Disclaimer ********INFOSYS*** >>> _______________________________________________ >>> 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 >>> . >>> >> >> -- >> For corporate legal information go to: >> >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From jmh@joelhalpern.com Thu Feb 28 09:06:10 2013 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 2B41D21F8B0A for ; Thu, 28 Feb 2013 09:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkqoWtOb45JN for ; Thu, 28 Feb 2013 09:06:09 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD5921F89EE for ; Thu, 28 Feb 2013 09:06:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id DAC171BDFAE9; Thu, 28 Feb 2013 09:06:07 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-134.clppva.east.verizon.net [70.106.134.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 755401BDFA7D; Thu, 28 Feb 2013 09:05:54 -0800 (PST) Message-ID: <512F8E5E.4070004@joelhalpern.com> Date: Thu, 28 Feb 2013 12:05:34 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: stbryant@cisco.com Subject: Re: A query on RIPv2 References: <35347FBF2796F94E936EE76C0E6047ED2B643823@BLRKECMBX13.ad.infosys.com>, <1C717044A9DD904E83DBD133393FD8D00843EFAD@szxeml525-mbs.china.huawei.com> <35347FBF2796F94E936EE76C0E6047ED2D11A681@BLRKECMBX12.ad.infosys.com> <512F71C8.4050300@cisco.com> <94A203EA12AECE4BA92D42DBFFE0AE470EB3F9@eusaamb101.ericsson.se> <512F83A4.7010203@cisco.com> In-Reply-To: <512F83A4.7010203@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Farrel , "" 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, 28 Feb 2013 17:06:10 -0000 That works for me. Yours, Joel On 2/28/2013 11:19 AM, Stewart Bryant wrote: > That is a valid response and I agree that the text is strictly > correct. However there also appears to be an existence > proof that more than one reader was confused (the > reference to Quagga). > > It would be at least charitable to has some text somewhere > that unconfused such a reader and the only way I can see > to do this is either to add an accepted errata or a fixed in > next version saying something like. > > In section 3.9.1 "Note that an authentication header is > not considered to be an RTE". > > Yes/No/Other proposals? > > - Stewart > > > On 28/02/2013 15:44, Acee Lindem wrote: >> Hi Stewart, >> To retain compatibility with RIPv1, the RIPv2 WG kept the packets >> formatted as a variable number of 20 byte entries. The one containing >> the authentication is, well, the authentication and, by definition, is >> not a route. I'm don't think this needs any clarification. >> Thanks, >> Acee >> >> On Feb 28, 2013, at 10:03 AM, Stewart Bryant wrote: >> >>> The confusion seems to be whether the AH, which gets carried as >>> a special type of RIP entry, is an RTE or not. >>> >>> I can see arguments both ways, although the fact that this has taken >>> 25 years to surface suggests that most implementers have >>> subscribed to a common view that the an AH is not an RTE, >>> and therefore the RFC is correct. >>> >>> I propose that we close this as an errata to be fixed in next version >>> with the statement: >>> >>> "Some readers have been confused as to whether an AH is considered >>> to be an RTE. The consensus view it that that it is not. If this >>> RFC is revised, some clarifying text should be added." >>> >>> Is that a reasonable way forward? >>> >>> Stewart >>> >>> >>> >>> >>> On 02/01/2013 06:08, Bharat Joshi wrote: >>>> Dear Gopakumar, >>>> >>>> I understand what you are saying. In fact, I tested some >>>> vendor's behaviour to understand how other people have implemented it. >>>> >>>> When authentication is enabled, there should be 2 route >>>> entries for things to work but I still feel that the RFC is not >>>> clear enough on this. In fact, in my search, I found that Quagga has >>>> issues with this. >>>> >>>> Regards, >>>> Bharat >>>> ________________________________________ >>>> From: Gopakumar C [gopakumar.c@huawei.com] >>>> Sent: Wednesday, January 02, 2013 11:05 AM >>>> To: Bharat Joshi; rtgwg@ietf.org >>>> Subject: RE: A query on RIPv2 >>>> >>>> Dear Bharat, >>>> >>>> In the scenario that you mentioned RIP packet will have two RTEs >>>> after the RIP header, first one will be authentication RTE and >>>> second one will be FULL table request RTE with address family >>>> identifier as 0. This may be followed by authentication trailer >>>> depending on the authentication scheme selected. >>>> >>>> RFC section 3.9.1 first states the general format of RIP Version 2 >>>> request message. Even though authentication is present, there is >>>> only one RTE (full table RTE) other than authentication as >>>> authentication RTE doesn't convey routing information. >>>> >>>> Hope this helps. >>>> >>>> Note: I think this is not correct forum to discuss this issue. I am >>>> not sure where you can post it as RIP mailing list is not active >>>> anymore. >>>> >>>> Regards, >>>> -Gopakumar >>>> >>>> -----Original Message----- >>>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On >>>> Behalf Of Bharat Joshi >>>> Sent: Tuesday, December 25, 2012 4:02 PM >>>> To: rtgwg@ietf.org >>>> Cc: Bharat Joshi >>>> Subject: A query on RIPv2 >>>> >>>> Hi All, >>>> >>>> I came across some text in RFC 2453 (RIPv2) which has confused >>>> me. It would be great if someone can clarify this for me. I searched >>>> the net and looked through the errata but could not find any >>>> reference to this. >>>> >>>> In section 3.9.1 of RFC 2453 >>>> (http://tools.ietf.org/html/rfc2453#section-3.9.1), in second para, >>>> following text is available: >>>> >>>> >>>> >>>> There is one special case. If there is exactly >>>> one entry in the request, and it has an address family >>>> identifier of >>>> zero and a metric of infinity (i.e., 16), then this is a request to >>>> send the entire routing table. >>>> >>>> >>>> >>>> In section 4.1 of same RFC >>>> (http://tools.ietf.org/html/rfc2453#section-4.1), in first para, >>>> following text is available: >>>> >>>> >>>> >>>> If the Address Family Identifier of the first (and >>>> only the first) entry in the message is 0xFFFF, then the >>>> remainder of >>>> the entry contains the authentication. >>>> >>>> >>>> >>>> Now what has confused me is that if a router is configured to >>>> use authentication, how should its 'request' message for full >>>> routing table look? Should it go without authentication information >>>> or with authentication information? >>>> >>>> If it goes with authentication information then it is not >>>> conforming to the statement of 3.9.1. If it goes without >>>> authentication information then it is not conforming to the user >>>> configuration and also there may be security issues. >>>> >>>> Regards, >>>> Bharat >>>> >>>> PS: I am currently not subscribed to RTG working group mailing list, >>>> so please reply all so that I can get your reply. >>>> >>>> >>>> **************** CAUTION - Disclaimer ***************** >>>> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION >>>> intended solely >>>> for the use of the addressee(s). If you are not the intended >>>> recipient, please >>>> notify the sender by e-mail and delete the original message. >>>> Further, you are not >>>> to copy, disclose, or distribute this e-mail or its contents to any >>>> other person and >>>> any such actions are unlawful. This e-mail may contain viruses. >>>> Infosys has taken >>>> every reasonable precaution to minimize this risk, but is not liable >>>> for any damage >>>> you may sustain as a result of any virus in this e-mail. You should >>>> carry out your >>>> own virus checks before opening the e-mail or attachment. Infosys >>>> reserves the >>>> right to monitor and review the content of all messages sent to or >>>> from this e-mail >>>> address. Messages sent to or from this e-mail address may be stored >>>> on the >>>> Infosys e-mail system. >>>> ***INFOSYS******** End of Disclaimer ********INFOSYS*** >>>> _______________________________________________ >>>> 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 >>>> . >>>> >>> >>> -- >>> For corporate legal information go to: >>> >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>> >>> _______________________________________________ >>> rtgwg mailing list >>> rtgwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtgwg >> . >> > >