From aretana@cisco.com Thu Sep 6 05:55:49 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7543D21F85AE for ; Thu, 6 Sep 2012 05:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTeqtvqS3IwE for ; Thu, 6 Sep 2012 05:55:48 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AFDB321F8594 for ; Thu, 6 Sep 2012 05:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4355; q=dns/txt; s=iport; t=1346936148; x=1348145748; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=6keod7YFVT4J5gFPzqck7rIu6FXOFLpPR93rwwH34Is=; b=JELcy1TDgYpRIXiDRqhY0T7yGkxZZcnYCxUE9pP+twmZT1tA4XWpvx5u HIgt4qsyrWbTOw/yu9AQZflMnRAFEfY2+OCrPheQ25YoST0z2cuUseIyv XVfFzTav8+uGhNVvBl6Xo+zK9nGWsMiNN0m2+TOYEf7E01tubrBkSnRrh g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJKcSFCtJV2a/2dsb2JhbABFux2BB4IgAQIEEgEKHVEBCC0JQhsBBgMCBBMUDodrC5ksgSigHosRgx2DKAOVWYEUjR+BZ4JjgWE X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="118885102" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 06 Sep 2012 12:55:48 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q86CtmD5030526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 6 Sep 2012 12:55:48 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.236]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Thu, 6 Sep 2012 07:55:47 -0500 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: FW: NomCom 2012-2013: Call for Nomination and Feedback Thread-Topic: NomCom 2012-2013: Call for Nomination and Feedback Thread-Index: AQHNi8O09dHbbZoq+EGx1Y01GhpoqZd9VxYA Date: Thu, 6 Sep 2012 12:55:47 +0000 Message-ID: In-Reply-To: <20120906000758.12304.41648.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.245.155] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19166.005 x-tm-as-result: No--46.621700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <943E5D7092C712429575FBA4D3D610A9@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, 06 Sep 2012 12:55:49 -0000 FYI On 9/5/12 8:07 PM, "NomCom Chair" wrote: >This is a reminder that the 2012-2013 Nominating Committee (NomCom) >is seeking nominations from now until September 24, 2012 . > >Additionally, this is an announcement that the NomCom is seeking >feedback on individuals who have accepted nominations for IETF >leadership positions. As we are following the advice of RFC 5680, the list >of individuals who have agreed to be considered for various positions can >be found on the NomCom Community Feedback Tool: > >https://www.ietf.org/group/nomcom/2012/input > >Within the coming weeks, we will be updating the list of individuals we >are considering for each position as more individuals accept nominations. >All feedback provided to the NomCom about these individuals is kept >strictly confidential (as per RFC 3777). Your honest >feedback is very important to the NomCom process. > >The open positions being considered by this year's NomCom can be found >at the end of this email or on the NomCom 2012-2013 website: > >https://www.ietf.org/group/nomcom/2012/ > >Nominations may be made by selecting the Nominate link at the top of >the NomCom 2012-2013 website or by visiting the following URL: > >https://www.ietf.org/group/nomcom/2012/nominate > >Note that nominations made using the web tool require an ietf.org (i.e., >datatracker) account. You can create an ietf.org account by visiting the >following URL: > >https://datatracker.ietf.org/accounts/create/ > >Nominations may also be made by email to nomcom12@ietf.org. >If you do so, please include the word "Nominate" in the Subject and >indicate in the email who is being nominated, their email address (to >confirm acceptance of the nomination), and the position for which you >are making the nomination. If you wish to nominate someone via email >for more than one position, please use separate emails to do so. > >Self nomination is welcome. > >NomCom 2012-2013 will follow the policy for "Open Disclosure of Willing >Nominees" described in RFC 5680. As stated in RFC 5680: "The list of >nominees willing to be considered for positions under review in the >current NomCom cycle is not confidential". Willing Nominees for each >position will be publicly listed. > >With the exception of publicly listing willing nominees, the >confidentiality requirements of RFC 3777 remain in effect. All >feedback and NomCom deliberations will remain confidential and >will not be disclosed. > >In order to ensure time to collect sufficient community feedback about >each of the willing nominees, nominations must be received by the >NomCom on or before September 24, 2012. > >The NomCom appoints individuals to fill the open slots on the >IAOC, the IAB, and the IESG. This year, the NomCom willing be filling the >positions currently held by the following individuals, whose terms expire >in March 2013: > >IAOC: >-------- >Dave Crocker > >IAB: >-------- >Alissa Cooper >Joel Halpern >David Kessens >Danny McPherson >Jon Peterson >Dave Thaler > >IESG: >-------- >Russ Housley (IETF Chair) >Pete Resnick (Applications Area) >Ralph Droms (Internet Area) >Ronald Bonica (Operations and Management Area) >Robert Sparks (Real-Time Applications and Infrastructure Area) >Adrian Farrel (Routing Area) >Stephen Farrell (Security Area) >Wesley Eddy (Transport Area) > >In addition to nominations, the Nominating Committee is actively >seeking community input on the jobs that need to be filled. We have >received the job descriptions from the IAB, IESG, and IAOC and they can >be found at: > >https://www.ietf.org/group/nomcom/2012/iaoc-requirements >https://www.ietf.org/group/nomcom/2012/iab-requirements >https://www.ietf.org/group/nomcom/2012/chair-requirements >https://www.ietf.org/group/nomcom/2012/iesg-requirements > >However, we also need the community's views and input on the jobs >within each organization. If you have ideas on job responsibilities >(more, less, different), please let us know. Please send suggestions >and feedback to nomcom12@ietf.org. > >Thank you for your help in identifying qualified nominees, and in >providing=20 >feedback about individuals we are considering for IETF leadership >positions. > >Matt Lepinski >nomcom-chair@ietf.org From internet-drafts@ietf.org Fri Sep 7 10:40:58 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2B921E804C; Fri, 7 Sep 2012 10:40:58 -0700 (PDT) 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=[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 us-8mhDJk3ON; Fri, 7 Sep 2012 10:40:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D8921F8668; Fri, 7 Sep 2012 10:40:57 -0700 (PDT) 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-ordered-fib-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120907174057.6594.46348.idtracker@ietfa.amsl.com> Date: Fri, 07 Sep 2012 10:40:57 -0700 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, 07 Sep 2012 17:40:58 -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 : Loop-free convergence using oFIB Author(s) : Mike Shand Stewart Bryant Stefano Previdi Clarence Filsfils Pierre Francois Olivier Bonaventure Filename : draft-ietf-rtgwg-ordered-fib-07.txt Pages : 25 Date : 2012-09-07 Abstract: This document describes a mechanism for use in conjunction with link state routing protocols which prevents the transient loops which would otherwise occur during topology changes. It does this by correctly sequencing the forwarding information base (FIB) updates on the routers. This mechanism can be used in the case of non-urgent link or node shutdowns and restarts or link metric changes. It can also be used in conjunction with a fast re-route mechanism which converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations. After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described. The technology described in this document has been subject to extensive simulation using real network topologies and costs, and pathological convergence behaviour. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ordered-fib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-ordered-fib-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-ordered-fib-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From saku@ytti.fi Sat Sep 8 01:35:29 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A80321F8680 for ; Sat, 8 Sep 2012 01:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 EPNchJw3Xl0W for ; Sat, 8 Sep 2012 01:35:29 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE1B21F8671 for ; Sat, 8 Sep 2012 01:35:28 -0700 (PDT) Received: by iabz21 with SMTP id z21so317801iab.31 for ; Sat, 08 Sep 2012 01:35:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=A0kn2yjIMzTVlsUAhPFULbDAx6oe0ceHPRWJUc0KNIk=; b=HTv64Tlo65TPB6ATiydOu9zBHkZu14xxmJuEhFQZXwK2eSqjg4VJDOqExW0FQXUjur 6Yjrgn4J2FAlUGBcDhS5wLNW/vYraUfyHP6Cpp22xeCBxqexU0CVkdDnlQdQMNrPnRzF pGQSfiTwglvZV4J2Vo5W36Wp4+/VsZqHfQ6L/M7oShPcp4zmcKY6osTm8+UPPDEQ33EA JOu5L+d8X+YaI302/RgQnVZ1XDHF3Q3p6a8RDwpuSQ58sgN9XjtuGL0ioNY7uK0R83sZ MlUvWt5oh7O4V4DOZa4wHRljsSooAGdYcxgOGjMUlvDAp3B03KYV2b93NIYkPI8m/IJd sH2g== MIME-Version: 1.0 Received: by 10.50.94.195 with SMTP id de3mr1568483igb.68.1347093328001; Sat, 08 Sep 2012 01:35:28 -0700 (PDT) Received: by 10.64.81.138 with HTTP; Sat, 8 Sep 2012 01:35:27 -0700 (PDT) In-Reply-To: <20120907174057.6594.46348.idtracker@ietfa.amsl.com> References: <20120907174057.6594.46348.idtracker@ietfa.amsl.com> Date: Sat, 8 Sep 2012 11:35:27 +0300 Message-ID: Subject: Re: I-D Action: draft-ietf-rtgwg-ordered-fib-07.txt From: Saku Ytti To: rtgwg@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmrHjfQTGivWRkM8I3mN0VqUxZIQTtEVjVMD05I3K+u3ikhosTbXXOfvpCdAWkoLyH9ZL3c 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, 08 Sep 2012 08:35:29 -0000 I'm confused. '2. Introduction' says this: --- The mechanisms that are used in the failure case are exactly the same as those used for managed changes. For simplicity this document makes no further distinction between managed and unplanned changes. --- Does this imply, this is as useful in failure cases as it is in managed changes? I understand why it would be useful in managed changes such as metric changes or artificially delayed interface shut. But I don't understand how this can do any good in unmanaged change. Domestically my network is 5ms long, it takes me 10ms on fastest available modern route engine to calculate SPF change. I flood LSP immediately before calculating SFP. So before I've finished calculating SPF on local-to-fault router, furthest domestic node has already been busy calculating it it for 5ms and is 5ms from finishing it? Non-domestic routers would not cause loop,, regardless or not if they've changed FIB. Wouldn't I double my delay, in the best scenario? As I'm waiting for permission to update my FIB and I'm bound by network delay not only to propagate LSP from up->down but to propagate permissions from down->up? So essentially I'm trading short transient loop to significantly longer packet loss (remember, using the old topology will cause packet loss, as link is already down). I'm probably not understanding this right. If this feature should also provide help in failure cases, would it be possible to have step by step description for both cases normal and oFIB? In terms of what happens millisecond to millisecond? (In same topology, where each link has described millisecond, each router described time to calculate SPF and each router described time to update FIB after SPF). Thanks, On 7 September 2012 20:40, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Area Working Group Working Group of the IETF. > > Title : Loop-free convergence using oFIB > Author(s) : Mike Shand > Stewart Bryant > Stefano Previdi > Clarence Filsfils > Pierre Francois > Olivier Bonaventure > Filename : draft-ietf-rtgwg-ordered-fib-07.txt > Pages : 25 > Date : 2012-09-07 > > Abstract: > This document describes a mechanism for use in conjunction with link > state routing protocols which prevents the transient loops which > would otherwise occur during topology changes. It does this by > correctly sequencing the forwarding information base (FIB) updates on > the routers. > > This mechanism can be used in the case of non-urgent link or node > shutdowns and restarts or link metric changes. It can also be used > in conjunction with a fast re-route mechanism which converts a sudden > link or node failure into a non-urgent topology change. This is > possible where a complete repair path is provided for all affected > destinations. > > After a non-urgent topology change, each router computes a rank that > defines the time at which it can safely update its FIB. A method for > accelerating this loop-free convergence process by the use of > completion messages is also described. > > The technology described in this document has been subject to > extensive simulation using real network topologies and costs, and > pathological convergence behaviour. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ordered-fib > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtgwg-ordered-fib-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-ordered-fib-07 > > > 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 -- ++ytti From balajivenkat299@gmail.com Sat Sep 8 01:50:09 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B2521F8691 for ; Sat, 8 Sep 2012 01:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 XnsmKIZZPQ7m for ; Sat, 8 Sep 2012 01:50:08 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFA721F8686 for ; Sat, 8 Sep 2012 01:50:08 -0700 (PDT) Received: by dadf8 with SMTP id f8so266562dad.31 for ; Sat, 08 Sep 2012 01:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-type; bh=hDI57xfsOvqF18h8lBDx7MZSn9Epp6q8KEXHuPdx9Vo=; b=nB7z+8FtYunKyHX1FRN8seDUKY/Wpe72hXVxmNyJoBaGcjQzQBdervN6Jw0A+VUgM5 FQWpWwU1PiPjPHXTnmBySxVOntoDR0OPYzYkKUgjmvGOjmiesvUlVr3Lniexwzzxgd4O 3dBaB+Ys1cvDmfyWCEZA+h8q/t1C5odgkcc16Y5Boxxxce3Hx3T89gYaBFmC4G0jQwEx oQEeFnFu88zH/kwjj2bweoDaRqY14aIF/h951Og0Rww2RMPhhXuvD3GMnGneIEVQZni2 cGB4qzDZcRM3vZDAgiUCd7eMMz0NQM21s2j2wa+iGrGMztjwGz9X1KEl3FkI2TD2tfYW TI7g== Received: by 10.66.77.168 with SMTP id t8mr12753224paw.28.1347094207858; Sat, 08 Sep 2012 01:50:07 -0700 (PDT) Received: from [192.168.15.105] ([122.174.23.47]) by mx.google.com with ESMTPS id pn4sm4836294pbb.50.2012.09.08.01.50.03 (version=SSLv3 cipher=OTHER); Sat, 08 Sep 2012 01:50:06 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sat, 08 Sep 2012 14:19:58 +0530 Subject: Power consumption reduction in edge and core routers in the internet From: balaji venkat Venkataswami To: Message-ID: Thread-Topic: Power consumption reduction in edge and core routers in the internet Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3429958804_297388" Cc: Shankar Raman 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, 08 Sep 2012 08:50:09 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3429958804_297388 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, After due consultation with the chairs and IRTF folks we have been instructed to ask for discussion on the following drafts that deal with power consumption reduction in edge and core devices in the internet. We deal with the problem in a hierarchical approach. One within an Autonomous System and the other between Autonomous Systems and hence for the whole internet. We duly submit to you this work that we have done for your kind review and consideration. We deal with solutions for unicast and multicast at the AS level and the intra-AS level. Multicast solutions mostly in the intra-AS level. We submit this work and request you to comment on it. Multicast intra-AS level * mjsraman-pce-power-replic (timeline) * mjsraman-pim-ecmp-redirect-power-replic-cap (timeline) Unicast AS level * mjsraman-rtgwg-bgp-power-path (timeline) * mjsraman-rtgwg-inter-as-psp (timeline) * mjsraman-rtgwg-inter-as-psp (timeline) * mjsraman-rtgwg-inter-as-psp-protect (timeline) Unicast intra-AS level * mjsraman-rtgwg-intra-as-psp-te-leak (timeline) * mjsraman-rtgwg-ospf-power-topo (timeline) Multicast intra-AS level * mjsraman-rtgwg-pim-power (timeline) Thanks again to the WG and IETF chairs for letting us share our work with this group. Thanks and regards Shankar and team --B_3429958804_297388 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Dear all,

After due consultation with the chairs and IRTF fo= lks we have been instructed to ask for discussion on the following drafts th= at deal with power consumption reduction in edge and core devices in the int= ernet.

We deal with the problem in a hier= archical approach. One within an Autonomous System and the other between Aut= onomous Systems and hence for the whole internet.

<= div style=3D"color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-= serif; ">We duly submit to you this work that we have done for your kind rev= iew and consideration.

We deal with solut= ions for unicast and multicast at the AS level and the intra-AS level. Multi= cast solutions mostly in the intra-AS level.

We submit this work and request you to comment on it.
Multicast intra-AS level
Unicast AS l= evel
Unicast intra-AS level
Multicast intra-AS level
  • <= a href=3D"http://tools.ietf.org/html/draft-mjsraman-rtgwg-pim-power" style=3D"co= lor: rgb(68, 0, 136); border-bottom-width: 0px; ">mjsraman-rtgwg-pim-power (timeline)

Thanks again to the WG and = IETF chairs for letting us share our work with this group.

Thanks and regards
= Shankar and team
--B_3429958804_297388-- From curtis@occnc.com Sat Sep 8 13:02:44 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E9C21F8468 for ; Sat, 8 Sep 2012 13:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, 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 Lkn8uq35Qq4e for ; Sat, 8 Sep 2012 13:02:43 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 4A92E21F8466 for ; Sat, 8 Sep 2012 13:02:41 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q88K2YgM021133; Sat, 8 Sep 2012 16:02:34 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209082002.q88K2YgM021133@gateway1.orleans.occnc.com> To: balaji venkat Venkataswami From: Curtis Villamizar Subject: Re: Power consumption reduction in edge and core routers in the internet In-reply-to: Your message of "Sat, 08 Sep 2012 14:19:58 +0530." Date: Sat, 08 Sep 2012 16:02:34 -0400 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: Sat, 08 Sep 2012 20:02:44 -0000 In message balaji venkat Venkataswami writes: > Dear all, > > After due consultation with the chairs and IRTF folks we have been > instructed to ask for discussion on the following drafts that deal with > power consumption reduction in edge and core devices in the internet. > > We deal with the problem in a hierarchical approach. One within an > Autonomous System and the other between Autonomous Systems and hence for the > whole internet. > > We duly submit to you this work that we have done for your kind review and > consideration. > > We deal with solutions for unicast and multicast at the AS level and the > intra-AS level. Multicast solutions mostly in the intra-AS level. > > We submit this work and request you to comment on it. > > Multicast intra-AS level > * mjsraman-pce-power-replic > (timeline) > .html> > * mjsraman-pim-ecmp-redirect-power-replic-cap > p> (timeline) > -replic-cap-timing.html> > Unicast AS level > * mjsraman-rtgwg-bgp-power-path > (timeline) > ming.html> > * mjsraman-rtgwg-inter-as-psp > (timeline) > ng.html> > * mjsraman-rtgwg-inter-as-psp > (timeline) > ng.html> > * mjsraman-rtgwg-inter-as-psp-protect > > (timeline) > ect-timing.html> > Unicast intra-AS level > * mjsraman-rtgwg-intra-as-psp-te-leak > > (timeline) > eak-timing.html> > * mjsraman-rtgwg-ospf-power-topo > > (timeline) > iming.html> > Multicast intra-AS level > * mjsraman-rtgwg-pim-power > (timeline) > html> > > Thanks again to the WG and IETF chairs for letting us share our work with > this group. > > Thanks and regards > Shankar and team My first reaction was that this was just a really bad idea from some students who didn't understand very much about how provider networks were built. But looking at some of the citations I'm wondering if this whole thing is just a joke. draft-mjsraman-rtgwg-ospf-power-topo-01 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 1 2003. [RFC5513] Farrel, A., "IANA Considerations for Three Letter Acronyms", RFC 5513, April 1 2009. [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 2009. I'm really hoping the whole thing is a joke, but unfortunately I do think that you are seriously proposing this. Just confirming first. Curtis From balajivenkat299@gmail.com Sat Sep 8 13:45:35 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F8321F8495 for ; Sat, 8 Sep 2012 13:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396, RCVD_ILLEGAL_IP=1.908, 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 YMcDrQsx39pW for ; Sat, 8 Sep 2012 13:45:34 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AED2721F8493 for ; Sat, 8 Sep 2012 13:45:34 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1112330pbb.31 for ; Sat, 08 Sep 2012 13:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=AkFK8GB3sM6cCJvte39Rv2cPv4FsKSm93DwGFFPlo28=; b=Yca8uMbhvtNJ8mQQNZc46V+STfZi+6tg2fwyNXttae581ZfwBce+h+bZ5brXMBs8HT dTCIIEFT8IrVvXVD8YM+z94+wsLznn9YcfKZ/s/PSut1w7ngsrc1N03HwND3G9RMMzoP oXBKDvsSAJBDU5wIro20OQ1TpGwD+6nvTyrWRwSGVMe1MuQYtnjLRhnUdCtb/8pyFk4G 7kKVOdXfXED0IXs1a7gDi3t+RoHjow5E7qBojJOrn1HzU0RMGnCmRWkeQsg4Boa5JHrL bgfZ41uZwtU4KCPgXrAwlTQTu8GVZ/qn6hvrZLkwJ+5lt72OtD91v+Y9Az6qsXasTBHu ipvQ== Received: by 10.66.74.196 with SMTP id w4mr15200480pav.32.1347137134242; Sat, 08 Sep 2012 13:45:34 -0700 (PDT) Received: from [223.231.150.91] ([223.231.150.91]) by mx.google.com with ESMTPS id rz10sm5901521pbc.32.2012.09.08.13.45.29 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 08 Sep 2012 13:45:32 -0700 (PDT) References: <201209082002.q88K2YgM021133@gateway1.orleans.occnc.com> In-Reply-To: <201209082002.q88K2YgM021133@gateway1.orleans.occnc.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Balaji Venkat Subject: Re: Power consumption reduction in edge and core routers in the internet Date: Sun, 9 Sep 2012 02:15:27 +0530 To: "curtis@occnc.com" 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: Sat, 08 Sep 2012 20:45:35 -0000 Dear Curtis, We used nroffedit for preparing these drafts and forgot to delete the defaul= t references that got stuck in there.=20 We intended these to be serious material. If you could comment on the specifics of why you disagree with our proposals= it would be most beneficial. Regards Balaji Sent from my iPad On 09-Sep-2012, at 1:32 AM, Curtis Villamizar wrote: >=20 > In message > balaji venkat Venkataswami writes: >=20 >> Dear all, >>=20 >> After due consultation with the chairs and IRTF folks we have been >> instructed to ask for discussion on the following drafts that deal with >> power consumption reduction in edge and core devices in the internet. >>=20 >> We deal with the problem in a hierarchical approach. One within an >> Autonomous System and the other between Autonomous Systems and hence for t= he >> whole internet. >>=20 >> We duly submit to you this work that we have done for your kind review an= d >> consideration. >>=20 >> We deal with solutions for unicast and multicast at the AS level and the >> intra-AS level. Multicast solutions mostly in the intra-AS level. >>=20 >> We submit this work and request you to comment on it. >>=20 >> Multicast intra-AS level >> * mjsraman-pce-power-replic >> (timeline) >> > .html>=20 >> * mjsraman-pim-ecmp-redirect-power-replic-cap >> > p> (timeline)=20 >> > -replic-cap-timing.html> >> Unicast AS level >> * mjsraman-rtgwg-bgp-power-path >> (timeli= ne) >> > ming.html>=20 >> * mjsraman-rtgwg-inter-as-psp >> (timeline= ) >> > ng.html>=20 >> * mjsraman-rtgwg-inter-as-psp >> (timeline= ) >> > ng.html>=20 >> * mjsraman-rtgwg-inter-as-psp-protect >> >> (timeline)=20 >> > ect-timing.html>=20 >> Unicast intra-AS level >> * mjsraman-rtgwg-intra-as-psp-te-leak >> >> (timeline)=20 >> > eak-timing.html>=20 >> * mjsraman-rtgwg-ospf-power-topo >> >> (timeline)=20 >> > iming.html>=20 >> Multicast intra-AS level >> * mjsraman-rtgwg-pim-power >> (timeline) >> > html>=20 >>=20 >> Thanks again to the WG and IETF chairs for letting us share our work with= >> this group. >>=20 >> Thanks and regards >> Shankar and team >=20 >=20 > My first reaction was that this was just a really bad idea from some > students who didn't understand very much about how provider networks > were built. >=20 > But looking at some of the citations I'm wondering if this whole thing > is just a joke. >=20 > draft-mjsraman-rtgwg-ospf-power-topo-01 >=20 > [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", > RFC 3514, April 1 2003. >=20 > [RFC5513] Farrel, A., "IANA Considerations for Three Letter > Acronyms", RFC 5513, April 1 2009. >=20 > [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April > 1 2009. >=20 > I'm really hoping the whole thing is a joke, but unfortunately I do > think that you are seriously proposing this. Just confirming first. >=20 > Curtis From curtis@occnc.com Sat Sep 8 15:57:06 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D730E21F84E1 for ; Sat, 8 Sep 2012 15:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, 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 nWYcO7rqpsI6 for ; Sat, 8 Sep 2012 15:57:05 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 911E721F84DE for ; Sat, 8 Sep 2012 15:57:05 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q88Mv1Hn022065; Sat, 8 Sep 2012 18:57:01 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209082257.q88Mv1Hn022065@gateway1.orleans.occnc.com> To: Balaji Venkat From: Curtis Villamizar Subject: Re: Power consumption reduction in edge and core routers in the internet In-reply-to: Your message of "Sun, 09 Sep 2012 02:15:27 +0530." Date: Sat, 08 Sep 2012 18:57:00 -0400 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: Sat, 08 Sep 2012 22:57:07 -0000 In message Balaji Venkat writes: > Dear Curtis, > > We used nroffedit for preparing these drafts and forgot to delete the > default references that got stuck in there. > > We intended these to be serious material. > > If you could comment on the specifics of why you disagree with our > proposals it would be most beneficial. > > Regards > Balaji Without too lengthy a response I have to say that I don't think your approach is going to yield much if any benefit. First reducing power in core and edge are very different problems. There are a few things in the core. For example: 1. Constraining the number of forwarding entries to get the existing external TCAM back into the forwarding chip and doing the forwarding with a less power greedy method than TCAM. 2. If possible eliminating the very large buffer on one side of a switching fabric, making it small enough to use on chip RAM and putting the bulk of the buffering on one side. Some think putting enough overspeed in the fabric and putting large buffer on the output side may be a solution. Others favor a VOQ approach. The extreme memory bandwidth needed to go to external DRAM is the culprit. As on chip SRAM sizes increase over time this may be possible. Putting external DRAM on both sides of a fabric is a big power drain. The first above is supported by using MPLS with a BGP free core (no IP forwarding except for the small number of prefixes needed for control traffic and then just a set of MPLS labels to traverse the topology. Comments on LDP vs RSVP-TE to /dev/null please (not important here). Comments on IPFRR are also not relevant as IPFRR doesn't address this. For edge, forwarding speeds are much lower (about 3 decimal orders of magnitude give or take one) and buffering requirements are smaller. On chip buffering of one side is clearly feasible but needs to be done right. At the very low end, on chip buffering on both ends might be feasible. Access is further out than edge and on chip buffer should be sufficient. With IP, if global routing is needed, then an external TCAM is generally used, though some chips will use external DRAM (realizing that multiple accesses would be needed for a trie approach). I'm far less familiar with where state-of-the-art is for edge and access. For large networks the parallel links provide a further potential for power reduction. Generally some traffic must be run for monitoring even if the link is unused. However in principle on-chip power islands could be used to eliminate the leakage current that unused power forwarding engines would draw, while keeping the minimal circuitry needed for an OAM or link layer equivalent active. I don't know any chip that does this. Generally that would be taking component links out of a parallel set of links (for example a wide LAG of 100Gb/s links). Powering down the laser is very problematic in long haul (LH). The LH optical systems monitor and balance power levels on the optical fiber. Lighting up additional wavelengths on a WDM can take minutes before power levels are adjusted right and transmit and receive sides and all the optical amplifiers along the way are sufficiently in sync to bring bit error rates down. LH optics and modulation is a black art, particularly ultra LH (ULH) and subsea (no OEO for up to 6000km) and right now shutting lasers down can be disruptive. The optical amplifier pump lasers have to be powered at about the same levels regardless of how many optical channels are carried. This does not apply to edge and access. Between edge and access, the physical topology is often a set of logical rings over WDM with ROADM add/drop. Taking down one side of each ring would not be viable. If there is parallel links or other redundancy, then shutting down lasers in short haul (less than 40 or less than 100 km) is feasible. Moving "high touch" functions such as deep packet inspection and filtering to edge helps. For core where a provider peering might require filtering, keeping the rule set very small can keep it on chip. Adding still more TCAM or DRAM for filtering drive power up. If a card must be all things, then it would help to allow those components to be powered down if not needed and the forwarding chip SERDES facing them to be powered down if not needed (internal to core for example, rather than peering). So I really think that you haven't started by stating a valid problem other than recognizing that reducing power would be a good thing. Maybe you should start over with one draft stating the problem. Identify where the power goes in a provider core network or content provider data center (or other extremely large data center) or in a service provider edge and access. Is it forwarding logic? Is it chip externals such as forwarding TCAM or DRAM, buffer SERDES/DRAM, filter TCAM or DRAM, switching fabric, etc. What is the contribution of optical components driving the line? (hint: don't look here). Then once you know where the power goes, try to fix it. IMHO you'll end up with a very different approach. Well - I suppose that wasn't as concise as it could be. Curtis > On 09-Sep-2012, at 1:32 AM, Curtis Villamizar wrote: > > > > > In message > > balaji venkat Venkataswami writes: > > > >> Dear all, > >> > >> After due consultation with the chairs and IRTF folks we have been > >> instructed to ask for discussion on the following drafts that deal with > >> power consumption reduction in edge and core devices in the internet. > >> > >> We deal with the problem in a hierarchical approach. One within an > >> Autonomous System and the other between Autonomous Systems and hence for the > >> whole internet. > >> > >> We duly submit to you this work that we have done for your kind review and > >> consideration. > >> > >> We deal with solutions for unicast and multicast at the AS level and the > >> intra-AS level. Multicast solutions mostly in the intra-AS level. > >> > >> We submit this work and request you to comment on it. > >> > >> Multicast intra-AS level > >> * mjsraman-pce-power-replic > >> (timeline) > >> >> .html> > >> * mjsraman-pim-ecmp-redirect-power-replic-cap > >> >> p> (timeline) > >> >> -replic-cap-timing.html> > >> Unicast AS level > >> * mjsraman-rtgwg-bgp-power-path > >> (timeline) > >> >> ming.html> > >> * mjsraman-rtgwg-inter-as-psp > >> (timeline) > >> >> ng.html> > >> * mjsraman-rtgwg-inter-as-psp > >> (timeline) > >> >> ng.html> > >> * mjsraman-rtgwg-inter-as-psp-protect > >> > >> (timeline) > >> >> ect-timing.html> > >> Unicast intra-AS level > >> * mjsraman-rtgwg-intra-as-psp-te-leak > >> > >> (timeline) > >> >> eak-timing.html> > >> * mjsraman-rtgwg-ospf-power-topo > >> > >> (timeline) > >> >> iming.html> > >> Multicast intra-AS level > >> * mjsraman-rtgwg-pim-power > >> (timeline) > >> >> html> > >> > >> Thanks again to the WG and IETF chairs for letting us share our work with > >> this group. > >> > >> Thanks and regards > >> Shankar and team > > > > > > My first reaction was that this was just a really bad idea from some > > students who didn't understand very much about how provider networks > > were built. > > > > But looking at some of the citations I'm wondering if this whole thing > > is just a joke. > > > > draft-mjsraman-rtgwg-ospf-power-topo-01 > > > > [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", > > RFC 3514, April 1 2003. > > > > [RFC5513] Farrel, A., "IANA Considerations for Three Letter > > Acronyms", RFC 5513, April 1 2009. > > > > [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April > > 1 2009. > > > > I'm really hoping the whole thing is a joke, but unfortunately I do > > think that you are seriously proposing this. Just confirming first. > > > > Curtis From balajivenkat299@gmail.com Sun Sep 9 05:04:42 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C8321F84D5 for ; Sun, 9 Sep 2012 05:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=1.389, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 GJtI6eorYz7W for ; Sun, 9 Sep 2012 05:04:41 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id D02B421F84A1 for ; Sun, 9 Sep 2012 05:04:40 -0700 (PDT) Received: by ieak13 with SMTP id k13so1655423iea.31 for ; Sun, 09 Sep 2012 05:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=GaapFHuVCMUqA53uztGL0RcJ800CiEs532pTXBF77/0=; b=Tnl+x9LQU7ncn/Is3fnchVelU1P9dC5CA9z6rGtPRu3VuO1N6/5RIBYKRiCD7kEfWJ N9T74fPf+ybIbAeRSWA15/7JkPs5vnLLjSOrFwWYcfChlUwZlHTkHD2B2f6QaIIZlJB8 WTHrIJJMIyiqS8IyHPXPLTY2LLoQ5ed8aXi4UzfwwjZN2igMpCm3e4F/JQLymS/Qe168 ICHs3zQ/F5f3vXkLE33wNBoduaMOOIsUC39SBpr2aDZ3HWujANi6/gbvcRq9jESEtwL6 QmV6UiQoHX8sYI1LDfQI8VeDMSncye5ziwVpylwpiUSUnKi/J+n34OLYT3QgXswq4ZSD 5GKA== Received: by 10.50.186.169 with SMTP id fl9mr7173971igc.9.1347192280457; Sun, 09 Sep 2012 05:04:40 -0700 (PDT) Received: from [192.168.15.105] ([122.174.12.155]) by mx.google.com with ESMTPS id ff4sm12954319igc.5.2012.09.09.05.04.35 (version=SSLv3 cipher=OTHER); Sun, 09 Sep 2012 05:04:39 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sun, 09 Sep 2012 17:34:30 +0530 Subject: Re: Power consumption reduction in edge and core routers in the internet From: balaji venkat Venkataswami To: Message-ID: Thread-Topic: Power consumption reduction in edge and core routers in the internet In-Reply-To: <201209082257.q88Mv1Hn022065@gateway1.orleans.occnc.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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: Sun, 09 Sep 2012 12:04:42 -0000 Dear Curtis, Thank you for your detailed reply on this matter. Agreed. We should definitely try optimising at the device level. What you have suggested all of them fall at the device level. Once you have reduced power to the extent possible at the device level there needs to be a protocol based approach to ascertain and discover which devices consume the least power in the topology (in a system of devices and interconnecting links). After all the system level of looking at a collection of such devices and links matters too. Our approach in these documents refers to the method of discovering such low power consuming devices in a topology of such devices and routing the traffic through them. We leave it to others to concentrate on the device level while we apply algorithms and protocols at the intra-AS and inter-AS level. Every one of our ideas in these drafts concentrates at a system level where such a system consists of more than ONE device and not just a device in isolation. After all there is bound to be differences in power consumption at the device level between two or more devices in a topology of nodes and links. This difference we exploit to direct traffic through those nodes and links that are efficient in power consumption and hence we reward the devices in an intra-AS scenario and Ases in an inter-AS scenario with more traffic. The greater the load they can take on without consequent linear or more than linear power consumption the better the internet is with regard to system / Internet level power consumption. Hope this helps. Thanks and regards, Shankar and team On 09/09/12 4:27 AM, "Curtis Villamizar" wrote: > >In message >Balaji Venkat writes: > >> Dear Curtis, >> >> We used nroffedit for preparing these drafts and forgot to delete the >> default references that got stuck in there. >> >> We intended these to be serious material. >> >> If you could comment on the specifics of why you disagree with our >> proposals it would be most beneficial. >> >> Regards >> Balaji > > >Without too lengthy a response I have to say that I don't think your >approach is going to yield much if any benefit. > >First reducing power in core and edge are very different problems. > >There are a few things in the core. For example: > > 1. Constraining the number of forwarding entries to get the > existing external TCAM back into the forwarding chip and doing > the forwarding with a less power greedy method than TCAM. > > 2. If possible eliminating the very large buffer on one side of a > switching fabric, making it small enough to use on chip RAM and > putting the bulk of the buffering on one side. Some think > putting enough overspeed in the fabric and putting large buffer > on the output side may be a solution. Others favor a VOQ > approach. The extreme memory bandwidth needed to go to external > DRAM is the culprit. As on chip SRAM sizes increase over time > this may be possible. Putting external DRAM on both sides of a > fabric is a big power drain. > >The first above is supported by using MPLS with a BGP free core (no IP >forwarding except for the small number of prefixes needed for control >traffic and then just a set of MPLS labels to traverse the topology. >Comments on LDP vs RSVP-TE to /dev/null please (not important here). >Comments on IPFRR are also not relevant as IPFRR doesn't address this. > >For edge, forwarding speeds are much lower (about 3 decimal orders of >magnitude give or take one) and buffering requirements are smaller. >On chip buffering of one side is clearly feasible but needs to be done >right. At the very low end, on chip buffering on both ends might be >feasible. Access is further out than edge and on chip buffer should >be sufficient. With IP, if global routing is needed, then an external >TCAM is generally used, though some chips will use external DRAM >(realizing that multiple accesses would be needed for a trie >approach). I'm far less familiar with where state-of-the-art is for >edge and access. > >For large networks the parallel links provide a further potential for >power reduction. Generally some traffic must be run for monitoring >even if the link is unused. However in principle on-chip power >islands could be used to eliminate the leakage current that unused >power forwarding engines would draw, while keeping the minimal >circuitry needed for an OAM or link layer equivalent active. I don't >know any chip that does this. Generally that would be taking >component links out of a parallel set of links (for example a wide LAG >of 100Gb/s links). > >Powering down the laser is very problematic in long haul (LH). The LH >optical systems monitor and balance power levels on the optical fiber. >Lighting up additional wavelengths on a WDM can take minutes before >power levels are adjusted right and transmit and receive sides and all >the optical amplifiers along the way are sufficiently in sync to bring >bit error rates down. LH optics and modulation is a black art, >particularly ultra LH (ULH) and subsea (no OEO for up to 6000km) and >right now shutting lasers down can be disruptive. The optical >amplifier pump lasers have to be powered at about the same levels >regardless of how many optical channels are carried. > >This does not apply to edge and access. Between edge and access, the >physical topology is often a set of logical rings over WDM with ROADM >add/drop. Taking down one side of each ring would not be viable. If >there is parallel links or other redundancy, then shutting down lasers >in short haul (less than 40 or less than 100 km) is feasible. > >Moving "high touch" functions such as deep packet inspection and >filtering to edge helps. For core where a provider peering might >require filtering, keeping the rule set very small can keep it on >chip. Adding still more TCAM or DRAM for filtering drive power up. >If a card must be all things, then it would help to allow those >components to be powered down if not needed and the forwarding chip >SERDES facing them to be powered down if not needed (internal to core >for example, rather than peering). > >So I really think that you haven't started by stating a valid problem >other than recognizing that reducing power would be a good thing. > >Maybe you should start over with one draft stating the problem. >Identify where the power goes in a provider core network or content >provider data center (or other extremely large data center) or in a >service provider edge and access. Is it forwarding logic? Is it chip >externals such as forwarding TCAM or DRAM, buffer SERDES/DRAM, filter >TCAM or DRAM, switching fabric, etc. What is the contribution of >optical components driving the line? (hint: don't look here). > >Then once you know where the power goes, try to fix it. IMHO you'll >end up with a very different approach. > >Well - I suppose that wasn't as concise as it could be. > >Curtis > > >> On 09-Sep-2012, at 1:32 AM, Curtis Villamizar wrote: >> >> > >> > In message >> > balaji venkat Venkataswami writes: >> > >> >> Dear all, >> >> >> >> After due consultation with the chairs and IRTF folks we have been >> >> instructed to ask for discussion on the following drafts that deal >>with >> >> power consumption reduction in edge and core devices in the internet. >> >> >> >> We deal with the problem in a hierarchical approach. One within an >> >> Autonomous System and the other between Autonomous Systems and hence >>for the >> >> whole internet. >> >> >> >> We duly submit to you this work that we have done for your kind >>review and >> >> consideration. >> >> >> >> We deal with solutions for unicast and multicast at the AS level and >>the >> >> intra-AS level. Multicast solutions mostly in the intra-AS level. >> >> >> >> We submit this work and request you to comment on it. >> >> >> >> Multicast intra-AS level >> >> * mjsraman-pce-power-replic >> >> >>(timeline) >> >> >>>ing >> >> .html> >> >> * mjsraman-pim-ecmp-redirect-power-replic-cap >> >> >>>-ca >> >> p> (timeline) >> >> >>>wer >> >> -replic-cap-timing.html> >> >> Unicast AS level >> >> * mjsraman-rtgwg-bgp-power-path >> >> >>(timeline) >> >> >>>-ti >> >> ming.html> >> >> * mjsraman-rtgwg-inter-as-psp >> >> >>(timeline) >> >> >>>imi >> >> ng.html> >> >> * mjsraman-rtgwg-inter-as-psp >> >> >>(timeline) >> >> >>>imi >> >> ng.html> >> >> * mjsraman-rtgwg-inter-as-psp-protect >> >> >> >> >> (timeline) >> >> >>>rot >> >> ect-timing.html> >> >> Unicast intra-AS level >> >> * mjsraman-rtgwg-intra-as-psp-te-leak >> >> >> >> >> (timeline) >> >> >>>e-l >> >> eak-timing.html> >> >> * mjsraman-rtgwg-ospf-power-topo >> >> >> >> (timeline) >> >> >>>o-t >> >> iming.html> >> >> Multicast intra-AS level >> >> * mjsraman-rtgwg-pim-power >> >> >>(timeline) >> >> >>>ng. >> >> html> >> >> >> >> Thanks again to the WG and IETF chairs for letting us share our work >>with >> >> this group. >> >> >> >> Thanks and regards >> >> Shankar and team >> > >> > >> > My first reaction was that this was just a really bad idea from some >> > students who didn't understand very much about how provider networks >> > were built. >> > >> > But looking at some of the citations I'm wondering if this whole thing >> > is just a joke. >> > >> > draft-mjsraman-rtgwg-ospf-power-topo-01 >> > >> > [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", >> > RFC 3514, April 1 2003. >> > >> > [RFC5513] Farrel, A., "IANA Considerations for Three Letter >> > Acronyms", RFC 5513, April 1 2009. >> > >> > [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April >> > 1 2009. >> > >> > I'm really hoping the whole thing is a joke, but unfortunately I do >> > think that you are seriously proposing this. Just confirming first. >> > >> > Curtis > From mickseaman@sbcglobal.net Sun Sep 9 10:58:06 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742CE21F852B for ; Sun, 9 Sep 2012 10:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 NqTN9Zg-3EfE for ; Sun, 9 Sep 2012 10:58:04 -0700 (PDT) Received: from nm30.access.bullet.mail.mud.yahoo.com (nm30.access.bullet.mail.mud.yahoo.com [66.94.237.95]) by ietfa.amsl.com (Postfix) with SMTP id 7B1F321F8523 for ; Sun, 9 Sep 2012 10:58:04 -0700 (PDT) Received: from [66.94.237.127] by nm30.access.bullet.mail.mud.yahoo.com with NNFMP; 09 Sep 2012 17:58:04 -0000 Received: from [98.139.221.53] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 09 Sep 2012 17:58:03 -0000 Received: from [127.0.0.1] by smtp106.sbc.mail.bf1.yahoo.com with NNFMP; 09 Sep 2012 17:58:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1347213483; bh=QySkS5uXM00Zgdp6X8pIjN0ZRkrGg3CMx0UeSSvL4dc=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=QszY7qkVblF6h20f3SwGDMwaTotwPZoUuTfbiFNZQbhcLTr36bKxeq4HFrcHfo5ngooCAJqYet7u56FKEdEkeDi/exCrgUujN9MEEpnJC8W+9GZBPy/3RPNr59HdR+l7F62CWWZsU1l0UTgnKv2xD9GGtSl/ip8PCD4upINWbto= X-Yahoo-Newman-Id: 737764.65617.bm@smtp106.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 5UNA.MYVM1n7hB.gMVenC5FUh1Prj.3e3isbqrUC8KrBdsx uumwuF.fl.zadOSKWxE5cHyU9JPk9CEgXx8YJ5VEP3tqnHDf2om4b7BFPcPw TC.CnoZWxCHuSamNs25GtAjwbL2VjhHOvQzOuASu62U0EcTkaaPX3Cgyl3lA z5NYzZdAGO0PjJz5JCZRTcKtnN7WnLZL_AnEPjtCDP0f5mP2pY2mZ1aprt7W EFFcOgt47u7faX4keVi6E8.XZPgsceaZ57M._Xs18PuI010owyCd72YYWesx Wlp.ArqSpvt9V0.EDNIh6QrnWtbOK7J2_Npl4adYyMMVdcRRojY90eFRv6Vg 92r3NjoaBpk9ZI3AwdEe2GFGKZ5xHUUU9rIHauFSswSAwEW3yX7U952txC73 2p6IocWDHCtfyYevc4g..Mkyc3tib6tlOV.hCmb5OcgsU3N3WMMFodQgLYc2 ZoYP5HwgINDHB0R2sZrji8mtDW17rCq.9uixVDdXLy9asvdY5_4shJX0mDhI 5jJ9km6QsVz2JhaNoWphs5412WeLKUfWn_IVSM1rZBqQjEFD3fprzU9tvo8N OSqUOHPd7yzT4vzW4e3OLvZGkUirT3XQAVzBvkhuut915gpkV2_GsM7dQzdg 9UayTSayXt5OVrQ_0AXA- X-Yahoo-SMTP: AR5_vwuswBBBxttajAdmA6MrHv2fOmL0PL2m9ko1TKipiHmVNQ-- Received: from [192.168.0.113] (mickseaman@75.35.78.140 with plain) by smtp106.sbc.mail.bf1.yahoo.com with SMTP; 09 Sep 2012 10:58:03 -0700 PDT Message-ID: <504CD8A9.5030704@sbcglobal.net> Date: Sun, 09 Sep 2012 10:58:01 -0700 From: Mick Seaman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: balaji venkat Venkataswami Subject: Re: Power consumption reduction in edge and core routers in the internet References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 17:58:06 -0000 Balaji, You say below "Once ... there needs to be a *protocol based* approach to ascertain and discover which devices ..." Frankly I doubt it. If the network administrators/operators are truly interested (which I don't doubt) they will know the power/load characteristics of their devices and can feed that data into the necessary computation. Having a protocol run around and auto discover such input information seems to be just one additional source of uncertainty/instability. The possibility of such a protocol mediating between two connected administrators/operators as to who should bear the power load is far fetched. Moreover, in the absence of a prior study as to what the power load characteristics of the devices of interest actually are, this seems too theoretical for words. The usable characteristics are likely to be (so far as they are really predictable) device/interface on (draws power) or off (does not) with some interfaces capable of operating in a lower power/much reduced data rate mode. An operator can assess the network load using some offline tool and then decide what devices to switch on/off/into low power mode - with a clear and obvious feed through into link availability/routing metric. This is of course already being done today. Mick On 9/9/2012 5:04 AM, balaji venkat Venkataswami wrote: > Dear Curtis, > > Thank you for your detailed reply on this matter. > Agreed. We should definitely try optimising at the device level. > What you have suggested all of them fall at the device level. > > Once you have reduced power to the extent possible at the device level > there needs to be a protocol based approach to ascertain and discover > which devices consume the least power in the topology (in a system of > devices and interconnecting links). After all the system level of looking > at a collection of such devices and links matters too. > > Our approach in these documents refers to the method of discovering such > low power consuming devices in a topology of such devices and routing the > traffic through them. We leave it to others to concentrate on the device > level while we apply algorithms and protocols at the intra-AS and inter-AS > level. > > Every one of our ideas in these drafts concentrates at a system level > where such a system consists of more than ONE device and not just a device > in isolation. After all there is bound to be differences in power > consumption at the device level between two or more devices in a topology > of nodes and links. This difference we exploit to direct traffic through > those nodes and links that are efficient in power consumption and hence we > reward the devices in an intra-AS scenario and Ases in an inter-AS > scenario with more traffic. The greater the load they can take on without > consequent linear or more than linear power consumption the better the > internet is with regard to system / Internet level power consumption. > > Hope this helps. > > Thanks and regards, > Shankar and team > > On 09/09/12 4:27 AM, "Curtis Villamizar" wrote: > >> In message >> Balaji Venkat writes: >> >>> Dear Curtis, >>> >>> We used nroffedit for preparing these drafts and forgot to delete the >>> default references that got stuck in there. >>> >>> We intended these to be serious material. >>> >>> If you could comment on the specifics of why you disagree with our >>> proposals it would be most beneficial. >>> >>> Regards >>> Balaji >> >> Without too lengthy a response I have to say that I don't think your >> approach is going to yield much if any benefit. >> >> First reducing power in core and edge are very different problems. >> >> There are a few things in the core. For example: >> >> 1. Constraining the number of forwarding entries to get the >> existing external TCAM back into the forwarding chip and doing >> the forwarding with a less power greedy method than TCAM. >> >> 2. If possible eliminating the very large buffer on one side of a >> switching fabric, making it small enough to use on chip RAM and >> putting the bulk of the buffering on one side. Some think >> putting enough overspeed in the fabric and putting large buffer >> on the output side may be a solution. Others favor a VOQ >> approach. The extreme memory bandwidth needed to go to external >> DRAM is the culprit. As on chip SRAM sizes increase over time >> this may be possible. Putting external DRAM on both sides of a >> fabric is a big power drain. >> >> The first above is supported by using MPLS with a BGP free core (no IP >> forwarding except for the small number of prefixes needed for control >> traffic and then just a set of MPLS labels to traverse the topology. >> Comments on LDP vs RSVP-TE to /dev/null please (not important here). >> Comments on IPFRR are also not relevant as IPFRR doesn't address this. >> >> For edge, forwarding speeds are much lower (about 3 decimal orders of >> magnitude give or take one) and buffering requirements are smaller. >> On chip buffering of one side is clearly feasible but needs to be done >> right. At the very low end, on chip buffering on both ends might be >> feasible. Access is further out than edge and on chip buffer should >> be sufficient. With IP, if global routing is needed, then an external >> TCAM is generally used, though some chips will use external DRAM >> (realizing that multiple accesses would be needed for a trie >> approach). I'm far less familiar with where state-of-the-art is for >> edge and access. >> >> For large networks the parallel links provide a further potential for >> power reduction. Generally some traffic must be run for monitoring >> even if the link is unused. However in principle on-chip power >> islands could be used to eliminate the leakage current that unused >> power forwarding engines would draw, while keeping the minimal >> circuitry needed for an OAM or link layer equivalent active. I don't >> know any chip that does this. Generally that would be taking >> component links out of a parallel set of links (for example a wide LAG >> of 100Gb/s links). >> >> Powering down the laser is very problematic in long haul (LH). The LH >> optical systems monitor and balance power levels on the optical fiber. >> Lighting up additional wavelengths on a WDM can take minutes before >> power levels are adjusted right and transmit and receive sides and all >> the optical amplifiers along the way are sufficiently in sync to bring >> bit error rates down. LH optics and modulation is a black art, >> particularly ultra LH (ULH) and subsea (no OEO for up to 6000km) and >> right now shutting lasers down can be disruptive. The optical >> amplifier pump lasers have to be powered at about the same levels >> regardless of how many optical channels are carried. >> >> This does not apply to edge and access. Between edge and access, the >> physical topology is often a set of logical rings over WDM with ROADM >> add/drop. Taking down one side of each ring would not be viable. If >> there is parallel links or other redundancy, then shutting down lasers >> in short haul (less than 40 or less than 100 km) is feasible. >> >> Moving "high touch" functions such as deep packet inspection and >> filtering to edge helps. For core where a provider peering might >> require filtering, keeping the rule set very small can keep it on >> chip. Adding still more TCAM or DRAM for filtering drive power up. >> If a card must be all things, then it would help to allow those >> components to be powered down if not needed and the forwarding chip >> SERDES facing them to be powered down if not needed (internal to core >> for example, rather than peering). >> >> So I really think that you haven't started by stating a valid problem >> other than recognizing that reducing power would be a good thing. >> >> Maybe you should start over with one draft stating the problem. >> Identify where the power goes in a provider core network or content >> provider data center (or other extremely large data center) or in a >> service provider edge and access. Is it forwarding logic? Is it chip >> externals such as forwarding TCAM or DRAM, buffer SERDES/DRAM, filter >> TCAM or DRAM, switching fabric, etc. What is the contribution of >> optical components driving the line? (hint: don't look here). >> >> Then once you know where the power goes, try to fix it. IMHO you'll >> end up with a very different approach. >> >> Well - I suppose that wasn't as concise as it could be. >> >> Curtis >> >> >>> On 09-Sep-2012, at 1:32 AM, Curtis Villamizar wrote: >>> >>>> In message >>>> balaji venkat Venkataswami writes: >>>> >>>>> Dear all, >>>>> >>>>> After due consultation with the chairs and IRTF folks we have been >>>>> instructed to ask for discussion on the following drafts that deal >>> with >>>>> power consumption reduction in edge and core devices in the internet. >>>>> >>>>> We deal with the problem in a hierarchical approach. One within an >>>>> Autonomous System and the other between Autonomous Systems and hence >>> for the >>>>> whole internet. >>>>> >>>>> We duly submit to you this work that we have done for your kind >>> review and >>>>> consideration. >>>>> >>>>> We deal with solutions for unicast and multicast at the AS level and >>> the >>>>> intra-AS level. Multicast solutions mostly in the intra-AS level. >>>>> >>>>> We submit this work and request you to comment on it. >>>>> >>>>> Multicast intra-AS level >>>>> * mjsraman-pce-power-replic >>>>> >>> (timeline) >>> >> ing >>>>> .html> >>>>> * mjsraman-pim-ecmp-redirect-power-replic-cap >>>>> >>> >> -ca >>>>> p> (timeline) >>>>> >>> >> wer >>>>> -replic-cap-timing.html> >>>>> Unicast AS level >>>>> * mjsraman-rtgwg-bgp-power-path >>>>> >>> (timeline) >>> >> -ti >>>>> ming.html> >>>>> * mjsraman-rtgwg-inter-as-psp >>>>> >>> (timeline) >>> >> imi >>>>> ng.html> >>>>> * mjsraman-rtgwg-inter-as-psp >>>>> >>> (timeline) >>> >> imi >>>>> ng.html> >>>>> * mjsraman-rtgwg-inter-as-psp-protect >>>>> >>> >>>>> (timeline) >>>>> >>> >> rot >>>>> ect-timing.html> >>>>> Unicast intra-AS level >>>>> * mjsraman-rtgwg-intra-as-psp-te-leak >>>>> >>> >>>>> (timeline) >>>>> >>> >> e-l >>>>> eak-timing.html> >>>>> * mjsraman-rtgwg-ospf-power-topo >>>>> >>>>> (timeline) >>>>> >>> >> o-t >>>>> iming.html> >>>>> Multicast intra-AS level >>>>> * mjsraman-rtgwg-pim-power >>>>> >>> (timeline) >>> >> ng. >>>>> html> >>>>> >>>>> Thanks again to the WG and IETF chairs for letting us share our work >>> with >>>>> this group. >>>>> >>>>> Thanks and regards >>>>> Shankar and team >>>> >>>> My first reaction was that this was just a really bad idea from some >>>> students who didn't understand very much about how provider networks >>>> were built. >>>> >>>> But looking at some of the citations I'm wondering if this whole thing >>>> is just a joke. >>>> >>>> draft-mjsraman-rtgwg-ospf-power-topo-01 >>>> >>>> [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", >>>> RFC 3514, April 1 2003. >>>> >>>> [RFC5513] Farrel, A., "IANA Considerations for Three Letter >>>> Acronyms", RFC 5513, April 1 2009. >>>> >>>> [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April >>>> 1 2009. >>>> >>>> I'm really hoping the whole thing is a joke, but unfortunately I do >>>> think that you are seriously proposing this. Just confirming first. >>>> >>>> Curtis > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > From stbryant@cisco.com Sun Sep 9 12:45:30 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383B621F8540 for ; Sun, 9 Sep 2012 12:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 Da0J9TgcZcAb for ; Sun, 9 Sep 2012 12:45:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7B921F8534 for ; Sun, 9 Sep 2012 12:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5188; q=dns/txt; s=iport; t=1347219928; x=1348429528; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ztLI2xKwUGdvGMvrf9k6rvyDLF8uZ13r83X3K2vr/YU=; b=ITw0nqgWW/aAvv6j7amK6fK1Y1Y0nYy20Ap+d0NrAFxuT3GQSadk0vSe F92QCCx3xYaTCmRX9fFaD5dnmrrgBMk06ikYCmdPON24zjbhXjUlzHu9u 9Jj2YRokNgHwzXBijPYjI3RX2WBjde5sqLmIgQ/oZZ7CVW2+RvXDYx5Gq I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACbxTFCQ/khR/2dsb2JhbABFu1KBB4IgAQEBBAEBAQ8BAhIRNgoBEAsYCRYPCQMCAQIBFTAGDQEFAgEBBRmHbguaeoNIEJsuixOGNgOVXYEUigSDHoEEY4Jn X-IronPort-AV: E=Sophos;i="4.80,126,1344211200"; d="scan'208";a="143557401" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 09 Sep 2012 19:45:26 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q89JjPkR024137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Sep 2012 19:45:25 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q89JjN5p013028; Sun, 9 Sep 2012 20:45:24 +0100 (BST) Message-ID: <504CF1D3.3030009@cisco.com> Date: Sun, 09 Sep 2012 20:45:23 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Saku Ytti Subject: Re: I-D Action: draft-ietf-rtgwg-ordered-fib-07.txt References: <20120907174057.6594.46348.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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: Sun, 09 Sep 2012 19:45:30 -0000 Saku The expected use of this technology in the failure case is in conjunction with IPFRR where following a protected failure, and in the absence of a convergence control technology, microloops may form and/or the repair may be staved. Note not only do you need to learn of the failure and compute the new SPF, you also need to update the FIB. The FIB update time can be the dominant factor in re-convergence. - Stewart On 08/09/2012 09:35, Saku Ytti wrote: > I'm confused. > > '2. Introduction' says this: > --- > The mechanisms that are used in the > failure case are exactly the same as those used for managed changes. > For simplicity this document makes no further distinction between > managed and unplanned changes. > --- > > Does this imply, this is as useful in failure cases as it is in > managed changes? > > > I understand why it would be useful in managed changes such as metric > changes or artificially delayed interface shut. But I don't understand > how this can do any good in unmanaged change. > > Domestically my network is 5ms long, it takes me 10ms on fastest > available modern route engine to calculate SPF change. I flood LSP > immediately before calculating SFP. So before I've finished > calculating SPF on local-to-fault router, furthest domestic node has > already been busy calculating it it for 5ms and is 5ms from finishing > it? > Non-domestic routers would not cause loop,, regardless or not if > they've changed FIB. > > Wouldn't I double my delay, in the best scenario? As I'm waiting for > permission to update my FIB and I'm bound by network delay not only to > propagate LSP from up->down but to propagate permissions from > down->up? > So essentially I'm trading short transient loop to significantly > longer packet loss (remember, using the old topology will cause packet > loss, as link is already down). > > I'm probably not understanding this right. If this feature should also > provide help in failure cases, would it be possible to have step by > step description for both cases normal and oFIB? In terms of what > happens millisecond to millisecond? (In same topology, where each link > has described millisecond, each router described time to calculate SPF > and each router described time to update FIB after SPF). > > Thanks, > On 7 September 2012 20:40, wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Routing Area Working Group Working Group of the IETF. >> >> Title : Loop-free convergence using oFIB >> Author(s) : Mike Shand >> Stewart Bryant >> Stefano Previdi >> Clarence Filsfils >> Pierre Francois >> Olivier Bonaventure >> Filename : draft-ietf-rtgwg-ordered-fib-07.txt >> Pages : 25 >> Date : 2012-09-07 >> >> Abstract: >> This document describes a mechanism for use in conjunction with link >> state routing protocols which prevents the transient loops which >> would otherwise occur during topology changes. It does this by >> correctly sequencing the forwarding information base (FIB) updates on >> the routers. >> >> This mechanism can be used in the case of non-urgent link or node >> shutdowns and restarts or link metric changes. It can also be used >> in conjunction with a fast re-route mechanism which converts a sudden >> link or node failure into a non-urgent topology change. This is >> possible where a complete repair path is provided for all affected >> destinations. >> >> After a non-urgent topology change, each router computes a rank that >> defines the time at which it can safely update its FIB. A method for >> accelerating this loop-free convergence process by the use of >> completion messages is also described. >> >> The technology described in this document has been subject to >> extensive simulation using real network topologies and costs, and >> pathological convergence behaviour. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ordered-fib >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-rtgwg-ordered-fib-07 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-ordered-fib-07 >> >> >> 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 > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From curtis@occnc.com Sun Sep 9 14:48:55 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CEA21F856D for ; Sun, 9 Sep 2012 14:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 ztR+cRnJcUS7 for ; Sun, 9 Sep 2012 14:48:54 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id CFEF721F8564 for ; Sun, 9 Sep 2012 14:48:53 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q89LmnOc003787; Sun, 9 Sep 2012 17:48:49 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201209092148.q89LmnOc003787@gateway1.orleans.occnc.com> To: balaji venkat Venkataswami From: Curtis Villamizar Subject: Re: Power consumption reduction in edge and core routers in the internet In-reply-to: Your message of "Sun, 09 Sep 2012 17:34:30 +0530." Date: Sun, 09 Sep 2012 17:48:49 -0400 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: Sun, 09 Sep 2012 21:48:55 -0000 Banji, Sorry if I have to get a bit harsh in my wording, but your persistance forces it. In message balaji venkat Venkataswami writes: > Dear Curtis, > > Thank you for your detailed reply on this matter. > Agreed. We should definitely try optimising at the device level. > What you have suggested all of them fall at the device level. You have no basis for the statement "What you have suggested all of them fall at the device level". I just spent a good part of my time for the last few year working at an transport equipment vendor and working with a small number of chip vendors who make high end packet forwarding chips and have a good understanding of where the power goes in some of today's high end routers and have a good relationship with number of service providers who would like to reduce their power draw. Prior to that I was at a high end router vendor. Prior to that in Internet operations and routing software work for the NSFNET. I suspect that you've never even seen a high end router such as a CRS-1 or CRS-3 or T-1600 and have no idea what the power feeds look like, let along where in those big 10+ KW chassis the power goes. If you did have any idea where the power goes, you would not make a statement like "What you have suggested all of them fall at the device level". > Once you have reduced power to the extent possible at the device level > there needs to be a protocol based approach to ascertain and discover > which devices consume the least power in the topology (in a system of > devices and interconnecting links). After all the system level of looking > at a collection of such devices and links matters too. You have no basis for the assertion "there needs to be a protocol based approach to ascertain and discover which devices consume the least power in the topology". If you talk to someone at a service provider you won't hear this. Mick just expressed his doubt. > Our approach in these documents refers to the method of discovering such > low power consuming devices in a topology of such devices and routing the > traffic through them. We leave it to others to concentrate on the device > level while we apply algorithms and protocols at the intra-AS and inter-AS > level. > > Every one of our ideas in these drafts concentrates at a system level > where such a system consists of more than ONE device and not just a device > in isolation. After all there is bound to be differences in power > consumption at the device level between two or more devices in a topology > of nodes and links. This difference we exploit to direct traffic through > those nodes and links that are efficient in power consumption and hence we > reward the devices in an intra-AS scenario and Ases in an inter-AS > scenario with more traffic. The greater the load they can take on without > consequent linear or more than linear power consumption the better the > internet is with regard to system / Internet level power consumption. I'm amused by "where such a system consists of more than ONE device and not just a device in isolation". Did you think anyone here thought a core router had only one chip in it? Do you have any clue what the "fabric" I mentioned was? I think it is time for you to stop making uniformed assertions and go do your homework and find out what service provider topologies look like, what type of equipment they deploy, where the power goes within those types of equipment and therefore the topology as a whole, and then think about how to reduce it. > Hope this helps. > > Thanks and regards, > Shankar and team The question for the WG is whether this work is of any interest to the IETF. My opinion is a *NO*, there is no interest in this work. At this point we need to hear other opinions, but so far I hear no support. Curtis > On 09/09/12 4:27 AM, "Curtis Villamizar" wrote: > > > > >In message > >Balaji Venkat writes: > > > >> Dear Curtis, > >> > >> We used nroffedit for preparing these drafts and forgot to delete the > >> default references that got stuck in there. > >> > >> We intended these to be serious material. > >> > >> If you could comment on the specifics of why you disagree with our > >> proposals it would be most beneficial. > >> > >> Regards > >> Balaji > > > > > >Without too lengthy a response I have to say that I don't think your > >approach is going to yield much if any benefit. > > > >First reducing power in core and edge are very different problems. > > > >There are a few things in the core. For example: > > > > 1. Constraining the number of forwarding entries to get the > > existing external TCAM back into the forwarding chip and doing > > the forwarding with a less power greedy method than TCAM. > > > > 2. If possible eliminating the very large buffer on one side of a > > switching fabric, making it small enough to use on chip RAM and > > putting the bulk of the buffering on one side. Some think > > putting enough overspeed in the fabric and putting large buffer > > on the output side may be a solution. Others favor a VOQ > > approach. The extreme memory bandwidth needed to go to external > > DRAM is the culprit. As on chip SRAM sizes increase over time > > this may be possible. Putting external DRAM on both sides of a > > fabric is a big power drain. > > > >The first above is supported by using MPLS with a BGP free core (no IP > >forwarding except for the small number of prefixes needed for control > >traffic and then just a set of MPLS labels to traverse the topology. > >Comments on LDP vs RSVP-TE to /dev/null please (not important here). > >Comments on IPFRR are also not relevant as IPFRR doesn't address this. > > > >For edge, forwarding speeds are much lower (about 3 decimal orders of > >magnitude give or take one) and buffering requirements are smaller. > >On chip buffering of one side is clearly feasible but needs to be done > >right. At the very low end, on chip buffering on both ends might be > >feasible. Access is further out than edge and on chip buffer should > >be sufficient. With IP, if global routing is needed, then an external > >TCAM is generally used, though some chips will use external DRAM > >(realizing that multiple accesses would be needed for a trie > >approach). I'm far less familiar with where state-of-the-art is for > >edge and access. > > > >For large networks the parallel links provide a further potential for > >power reduction. Generally some traffic must be run for monitoring > >even if the link is unused. However in principle on-chip power > >islands could be used to eliminate the leakage current that unused > >power forwarding engines would draw, while keeping the minimal > >circuitry needed for an OAM or link layer equivalent active. I don't > >know any chip that does this. Generally that would be taking > >component links out of a parallel set of links (for example a wide LAG > >of 100Gb/s links). > > > >Powering down the laser is very problematic in long haul (LH). The LH > >optical systems monitor and balance power levels on the optical fiber. > >Lighting up additional wavelengths on a WDM can take minutes before > >power levels are adjusted right and transmit and receive sides and all > >the optical amplifiers along the way are sufficiently in sync to bring > >bit error rates down. LH optics and modulation is a black art, > >particularly ultra LH (ULH) and subsea (no OEO for up to 6000km) and > >right now shutting lasers down can be disruptive. The optical > >amplifier pump lasers have to be powered at about the same levels > >regardless of how many optical channels are carried. > > > >This does not apply to edge and access. Between edge and access, the > >physical topology is often a set of logical rings over WDM with ROADM > >add/drop. Taking down one side of each ring would not be viable. If > >there is parallel links or other redundancy, then shutting down lasers > >in short haul (less than 40 or less than 100 km) is feasible. > > > >Moving "high touch" functions such as deep packet inspection and > >filtering to edge helps. For core where a provider peering might > >require filtering, keeping the rule set very small can keep it on > >chip. Adding still more TCAM or DRAM for filtering drive power up. > >If a card must be all things, then it would help to allow those > >components to be powered down if not needed and the forwarding chip > >SERDES facing them to be powered down if not needed (internal to core > >for example, rather than peering). > > > >So I really think that you haven't started by stating a valid problem > >other than recognizing that reducing power would be a good thing. > > > >Maybe you should start over with one draft stating the problem. > >Identify where the power goes in a provider core network or content > >provider data center (or other extremely large data center) or in a > >service provider edge and access. Is it forwarding logic? Is it chip > >externals such as forwarding TCAM or DRAM, buffer SERDES/DRAM, filter > >TCAM or DRAM, switching fabric, etc. What is the contribution of > >optical components driving the line? (hint: don't look here). > > > >Then once you know where the power goes, try to fix it. IMHO you'll > >end up with a very different approach. > > > >Well - I suppose that wasn't as concise as it could be. > > > >Curtis > > > > > >> On 09-Sep-2012, at 1:32 AM, Curtis Villamizar wrote: > >> > >> > > >> > In message > >> > balaji venkat Venkataswami writes: > >> > > >> >> Dear all, > >> >> > >> >> After due consultation with the chairs and IRTF folks we have been > >> >> instructed to ask for discussion on the following drafts that deal > >>with > >> >> power consumption reduction in edge and core devices in the internet. > >> >> > >> >> We deal with the problem in a hierarchical approach. One within an > >> >> Autonomous System and the other between Autonomous Systems and hence > >>for the > >> >> whole internet. > >> >> > >> >> We duly submit to you this work that we have done for your kind > >>review and > >> >> consideration. > >> >> > >> >> We deal with solutions for unicast and multicast at the AS level and > >>the > >> >> intra-AS level. Multicast solutions mostly in the intra-AS level. > >> >> > >> >> We submit this work and request you to comment on it. > >> >> > >> >> Multicast intra-AS level > >> >> * mjsraman-pce-power-replic > >> >> > >>(timeline) > >> >> > >> >>ing > >> >> .html> > >> >> * mjsraman-pim-ecmp-redirect-power-replic-cap > >> >> > >> >>-ca > >> >> p> (timeline) > >> >> > >> >>wer > >> >> -replic-cap-timing.html> > >> >> Unicast AS level > >> >> * mjsraman-rtgwg-bgp-power-path > >> >> > >>(timeline) > >> >> > >> >>-ti > >> >> ming.html> > >> >> * mjsraman-rtgwg-inter-as-psp > >> >> > >>(timeline) > >> >> > >> >>imi > >> >> ng.html> > >> >> * mjsraman-rtgwg-inter-as-psp > >> >> > >>(timeline) > >> >> > >> >>imi > >> >> ng.html> > >> >> * mjsraman-rtgwg-inter-as-psp-protect > >> >> > >> > >> >> (timeline) > >> >> > >> >>rot > >> >> ect-timing.html> > >> >> Unicast intra-AS level > >> >> * mjsraman-rtgwg-intra-as-psp-te-leak > >> >> > >> > >> >> (timeline) > >> >> > >> >>e-l > >> >> eak-timing.html> > >> >> * mjsraman-rtgwg-ospf-power-topo > >> >> > >> >> (timeline) > >> >> > >> >>o-t > >> >> iming.html> > >> >> Multicast intra-AS level > >> >> * mjsraman-rtgwg-pim-power > >> >> > >>(timeline) > >> >> > >> >>ng. > >> >> html> > >> >> > >> >> Thanks again to the WG and IETF chairs for letting us share our work > >>with > >> >> this group. > >> >> > >> >> Thanks and regards > >> >> Shankar and team > >> > > >> > > >> > My first reaction was that this was just a really bad idea from some > >> > students who didn't understand very much about how provider networks > >> > were built. > >> > > >> > But looking at some of the citations I'm wondering if this whole thing > >> > is just a joke. > >> > > >> > draft-mjsraman-rtgwg-ospf-power-topo-01 > >> > > >> > [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", > >> > RFC 3514, April 1 2003. > >> > > >> > [RFC5513] Farrel, A., "IANA Considerations for Three Letter > >> > Acronyms", RFC 5513, April 1 2009. > >> > > >> > [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April > >> > 1 2009. > >> > > >> > I'm really hoping the whole thing is a joke, but unfortunately I do > >> > think that you are seriously proposing this. Just confirming first. > >> > > >> > Curtis From tony.li@tony.li Sun Sep 9 15:29:16 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D548A21F8570 for ; Sun, 9 Sep 2012 15:29:16 -0700 (PDT) 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 KwZ3wJ0UNiNJ for ; Sun, 9 Sep 2012 15:29:16 -0700 (PDT) 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 7950C21F856D for ; Sun, 9 Sep 2012 15:29:15 -0700 (PDT) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta12.emeryville.ca.mail.comcast.net with comcast id xAKr1j0090mlR8UACAVFrt; Sun, 09 Sep 2012 22:29:15 +0000 Received: from [192.168.2.103] ([98.248.36.188]) by omta11.emeryville.ca.mail.comcast.net with comcast id xAV91j00R43ZcXW8XAVCMv; Sun, 09 Sep 2012 22:29:15 +0000 Subject: Re: Power consumption reduction in edge and core routers in the internet Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <201209092148.q89LmnOc003787@gateway1.orleans.occnc.com> Date: Sun, 9 Sep 2012 15:29:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201209092148.q89LmnOc003787@gateway1.orleans.occnc.com> To: curtis@occnc.com X-Mailer: Apple Mail (2.1278) 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: Sun, 09 Sep 2012 22:29:16 -0000 On Sep 9, 2012, at 2:48 PM, Curtis Villamizar wrote: > The question for the WG is whether this work is of any interest to the > IETF. My opinion is a *NO*, there is no interest in this work. >=20 > At this point we need to hear other opinions, but so far I hear no > support. I have an interest in this area, but like Curtis, would like to suggest = that we need to understand the degrees of freedom that are possible and = practical. We should try to focus our directions on the pragmatic. Like Curtis, I'm highly skeptical of the ability or opportunity for a = provider to shut down an entire system. If that were truly practical, = it would imply that the system would be wholly unnecessary for primary = or protect paths. While there is a substantial optimization possible = because of diurnal traffic patterns, I suspect that the granularity of = the power savings is at the link level, not at the system level. Unlike Curtis, I'm not convinced that manipulating DWDM optics on the = fly is an insurmountable challenge. I agree that it is non-trivial and = certainly not something supportable immediately, but as our control = systems mature, it is not inconceivable that we will someday get to the = point where this can be automated. Thus, the net is that the real power savings that are possible today are = at the NPU (and associated fabric) level. Having a protocol to support = this, as well as the TE facilities to automate the process seem like a = worthwhile direction. And, as always, solving problems at the intra-AS = level is far, far easier than addressing them at the inter-AS level. Regards, Tony From saku@ytti.fi Mon Sep 10 05:58:43 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4949421F8682 for ; Mon, 10 Sep 2012 05:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 TPJFhLp5U5rW for ; Mon, 10 Sep 2012 05:58:42 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA32721F8673 for ; Mon, 10 Sep 2012 05:58:42 -0700 (PDT) Received: by ieak13 with SMTP id k13so3312048iea.31 for ; Mon, 10 Sep 2012 05:58:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=C2xk/6+PuJ7Sej5WtAoxUpl8F9rhs2OFka2noWfWk6c=; b=eVqBLLg5o4e2JGw745R+2Eb6Pn83i+tjonPZtwMV0W9VUdue/FHIhA/CzlWGO5lwxM DNcunh150Yb97Qpe7Aw61r+5DHMy3+nKMXUt2RVF3V9UBDdhL7rVqnVP/no5X4X7CfoT lW3+hC2V63UXHgNug3lK2qy1xgng5ngjnyKiQ3XTzadimcRj/tZfDPojRJD7CElDkXcf Xvparaf5PzRw8NA6DJf0yJXHaOQZSIfho9PQcNsA6cyWKgDOc6hF6F5eu3EnDoNtrzUY sOyUu0prBsOPWWqwxiH7SyHGMvyX/A5hX3FxAbsyZ7SN5l7KJ8i/e3EwUyq0io1goTA6 wx7g== MIME-Version: 1.0 Received: by 10.50.100.165 with SMTP id ez5mr11007576igb.68.1347281922098; Mon, 10 Sep 2012 05:58:42 -0700 (PDT) Received: by 10.64.81.138 with HTTP; Mon, 10 Sep 2012 05:58:41 -0700 (PDT) In-Reply-To: <504CF1D3.3030009@cisco.com> References: <20120907174057.6594.46348.idtracker@ietfa.amsl.com> <504CF1D3.3030009@cisco.com> Date: Mon, 10 Sep 2012 15:58:41 +0300 Message-ID: Subject: Re: I-D Action: draft-ietf-rtgwg-ordered-fib-07.txt From: Saku Ytti To: stbryant@cisco.com Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQko3PWrs23o0OloEmz3msZdeQzKBmvbYPinCITypeCCjnJNONTaaWWL2wLJ4jC/HokO0XF8 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, 10 Sep 2012 12:58:43 -0000 On 9 September 2012 22:45, Stewart Bryant wrote: > The expected use of this technology in the failure case > is in conjunction with IPFRR where following a protected > failure, and in the absence of a convergence control > technology, microloops may form and/or the repair > may be staved. If failure cannot be IPFRR protected, conventional FIB insertion would be used? > Note not only do you need to learn of the failure > and compute the new SPF, you also need to update the > FIB. The FIB update time can be the dominant factor in > re-convergence. Yes, certain modern chassis based L3 switch can literally take >hour in real network to update its FIB. I once thought of sending commit-to-FIB absolute time in TLV in LSP (Router NTP can give 500us precision easily). But maybe that wouldn't be deterministic enough. In oFIB I fear that FIB delay in devices I'd actually want to use in practical scenarios are less than my linkdelays, so signalling would just reduce convergence time. -- ++ytti From stbryant@cisco.com Mon Sep 10 09:25:04 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78F421E8045 for ; Mon, 10 Sep 2012 09:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 T3ZEKonc3IMT for ; Mon, 10 Sep 2012 09:25:03 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id F1BDB21E8042 for ; Mon, 10 Sep 2012 09:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1320; q=dns/txt; s=iport; t=1347294303; x=1348503903; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=g5KBaGgaNqTAWDq14CTgoqLd6x6w8rvp6MEUzKnx1d0=; b=UuU6rUgv67w83aVjzapmFYH3ClAXM99ZJQCPUX0cOcm91ld4coxww7h5 d9IYnDthPMxcdovPoJPM6+LN9P0bwZF6IQOdtdwHC6+Cb2k5RRfLsj/Dr 2UUGOqMj/u9lCHNofvhNnyqgpAKa548noST8omlMvPh6jtLcD1kFh7/hR U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABMTTlCQ/khR/2dsb2JhbABFhge1PIEHgiABAQEDARIBAg4VQAEQCxgCAgUWCwICCQMCAQIBRQYNAQUCAQEeh2gGm0GDSBCJQZJlgSGJcoUkgRIDlV2ONoEEY4Jn X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="7940054" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 10 Sep 2012 16:25:01 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8AGP1v5027984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2012 16:25:01 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q8AGOwpP014266; Mon, 10 Sep 2012 17:24:59 +0100 (BST) Message-ID: <504E145A.6080809@cisco.com> Date: Mon, 10 Sep 2012 17:24:58 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Saku Ytti Subject: Re: I-D Action: draft-ietf-rtgwg-ordered-fib-07.txt References: <20120907174057.6594.46348.idtracker@ietfa.amsl.com> <504CF1D3.3030009@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 16:25:04 -0000 On 10/09/2012 13:58, Saku Ytti wrote: > On 9 September 2012 22:45, Stewart Bryant wrote: > >> The expected use of this technology in the failure case >> is in conjunction with IPFRR where following a protected >> failure, and in the absence of a convergence control >> technology, microloops may form and/or the repair >> may be staved. > If failure cannot be IPFRR protected, conventional FIB insertion would be used? Yes. > >> Note not only do you need to learn of the failure >> and compute the new SPF, you also need to update the >> FIB. The FIB update time can be the dominant factor in >> re-convergence. > Yes, certain modern chassis based L3 switch can literally take >hour > in real network to update its FIB. If the platform takes hour you definately need IPFRR. > I once thought of sending commit-to-FIB absolute time in TLV in LSP > (Router NTP can give 500us precision easily). But maybe that wouldn't > be deterministic enough. In oFIB I fear that FIB delay in devices I'd > actually want to use in practical scenarios are less than my > linkdelays, so signalling would just reduce convergence time. > Have you looked at the loop free convergence framework? This was an idea we considered in the early days we called it synchronized FIB. - Stewart From allwyn.carvalho@ericsson.com Mon Sep 10 14:12:24 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1943621F8739 for ; Mon, 10 Sep 2012 14:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.141 X-Spam-Level: X-Spam-Status: No, score=-5.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 SNXU9mwv6B7C for ; Mon, 10 Sep 2012 14:12:23 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E485B21F8737 for ; Mon, 10 Sep 2012 14:12:22 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q8ALGDQt003939; Mon, 10 Sep 2012 16:16:15 -0500 Received: from [155.53.129.41] (147.117.20.214) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.3.264.1; Mon, 10 Sep 2012 17:12:17 -0400 Message-ID: <504E57B0.4020505@ericsson.com> Date: Mon, 10 Sep 2012 14:12:16 -0700 From: Allwyn Carvalho User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "stbryant@cisco.com" Subject: Re: I-D Action: draft-ietf-rtgwg-ordered-fib-07.txt References: <20120907174057.6594.46348.idtracker@ietfa.amsl.com> <504CF1D3.3030009@cisco.com> In-Reply-To: <504CF1D3.3030009@cisco.com> Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 21:12:24 -0000 
In the following:

--- start ---

   For example, in Figure 1, if the link between X and Y is shut down by
   an operator, packets destined to X can loop between R and Y when Y
   has updated its FIB while R has not yet updated its FIB, and packets
   destined to Y can loop between X and S if X updates its FIB before S.
   According to the current behaviour of ISIS and OSPF, this scenario
   will happen most of the time because X and Y are the first routers to
   be aware of the failure, so that they will update their FIBs first.

                                     1
                       X-------------/-------------Y
                       |                           |
                       |                           |
                       |                           |
                       |                           |
                     1 |                           | 1
                       |                           |
                       |                           |
                       |                           |
                       |                           |
                       S---------------------------R
                                     2

                        Figure 1: A simple topology
--- end ---

I guess you are talking about packets originating at R and going to X.  Y should not use R as a loop-free alternative because it is not "downstream".  Cost (R,X) > Cost (Y,X).  Y does not have loop free alternative to X.  So, yes, there will be packet loss until convergence, but at least there should be no micro-loops.

Allwyn.

Stewart Bryant wrote: 
Saku

The expected use of this technology in the failure case
is in conjunction with IPFRR where following a protected
failure, and in the absence of a convergence control
technology, microloops may form and/or the repair
may be staved.

Note not only do you need to learn of the failure
and compute the new SPF, you also need to update the
FIB. The FIB update time can be the dominant factor in
re-convergence.

- Stewart



On 08/09/2012 09:35, Saku Ytti wrote:
  
I'm confused.

'2. Introduction' says this:
---
The mechanisms that are used in the
    failure case are exactly the same as those used for managed changes.
    For simplicity this document makes no further distinction between
    managed and unplanned changes.
---

Does this imply, this is as useful in failure cases as it is in
managed changes?


I understand why it would be useful in managed changes such as metric
changes or artificially delayed interface shut. But I don't understand
how this can do any good in unmanaged change.

Domestically my network is 5ms long, it takes me 10ms on fastest
available modern route engine to calculate SPF change. I flood LSP
immediately before calculating SFP. So before I've finished
calculating SPF on local-to-fault router, furthest domestic node has
already been busy calculating it it for 5ms and is 5ms from finishing
it?
Non-domestic routers would not cause loop,, regardless or not if
they've changed FIB.

Wouldn't I double my delay, in the best scenario? As I'm waiting for
permission to update my FIB and I'm bound by network delay not only to
propagate LSP from up->down but to propagate permissions from
down->up?
So essentially I'm trading short transient loop to significantly
longer packet loss (remember, using the old topology will cause packet
loss, as link is already down).

I'm probably not understanding this right. If this feature should also
provide help in failure cases, would it be possible to have step by
step description for both cases normal and oFIB? In terms of what
happens millisecond to millisecond? (In same topology, where each link
has described millisecond, each router described time to calculate SPF
and each router described time to update FIB after SPF).

Thanks,
On 7 September 2012 20:40,  <internet-drafts@ietf.org> wrote:
    
A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Routing Area Working Group Working Group of the IETF.

         Title           : Loop-free convergence using oFIB
         Author(s)       : Mike Shand
                           Stewart Bryant
                           Stefano Previdi
                           Clarence Filsfils
                           Pierre Francois
                           Olivier Bonaventure
         Filename        : draft-ietf-rtgwg-ordered-fib-07.txt
         Pages           : 25
         Date            : 2012-09-07

Abstract:
    This document describes a mechanism for use in conjunction with link
    state routing protocols which prevents the transient loops which
    would otherwise occur during topology changes.  It does this by
    correctly sequencing the forwarding information base (FIB) updates on
    the routers.

    This mechanism can be used in the case of non-urgent link or node
    shutdowns and restarts or link metric changes.  It can also be used
    in conjunction with a fast re-route mechanism which converts a sudden
    link or node failure into a non-urgent topology change.  This is
    possible where a complete repair path is provided for all affected
    destinations.

    After a non-urgent topology change, each router computes a rank that
    defines the time at which it can safely update its FIB.  A method for
    accelerating this loop-free convergence process by the use of
    completion messages is also described.

    The technology described in this document has been subject to
    extensive simulation using real network topologies and costs, and
    pathological convergence behaviour.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ordered-fib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-ordered-fib-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-ordered-fib-07


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 stbryant@cisco.com Mon Sep 10 14:53:00 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DE221F854E for ; Mon, 10 Sep 2012 14:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8TYSLizkVavC for ; Mon, 10 Sep 2012 14:52:59 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3A47A21F853C for ; Mon, 10 Sep 2012 14:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17302; q=dns/txt; s=iport; t=1347313976; x=1348523576; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=nM6VPvvM657ei8oOHV1bX6bpNXbqPYWt53suROOpu9o=; b=RJRXHYl8D9lqS0wlvzYVb/Q6lqwt683tddggY0DWVo3/QoEbA1JHjK14 hdo0igAuORNAfCMF6X/cHs3c4AP6KJEeantzXUONa7xYcDUuV8QFZh99Y D05KQS8Rvl3hjLeARngWtGNjxEK4adn9cisWKBdEZn3VstggA7hTEc8Ff c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFADNgTlCQ/khM/2dsb2JhbABFi2avc4EHgiABAQEEAQEBDwECEgZBCgEQCxgJFg8JAwIBAgEVMAYNAQUCAQEFGYduC5tag0gQnEmLDIY2A5VdgRSKBIMegQRjgmc X-IronPort-AV: E=Sophos;i="4.80,400,1344211200"; d="scan'208,217";a="7939768" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 10 Sep 2012 21:52:55 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8ALqskF013242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2012 21:52:54 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q8ALqp8l005862; Mon, 10 Sep 2012 22:52:52 +0100 (BST) Message-ID: <504E6133.6010802@cisco.com> Date: Mon, 10 Sep 2012 22:52:51 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Allwyn Carvalho Subject: Re: I-D Action: draft-ietf-rtgwg-ordered-fib-07.txt References: <20120907174057.6594.46348.idtracker@ietfa.amsl.com> <504CF1D3.3030009@cisco.com> <504E57B0.4020505@ericsson.com> In-Reply-To: <504E57B0.4020505@ericsson.com> Content-Type: multipart/alternative; boundary="------------080701030808030400080302" Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 21:53:00 -0000 This is a multi-part message in MIME format. --------------080701030808030400080302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/09/2012 22:12, Allwyn Carvalho wrote: > In the following: > > --- start --- > > For example, in Figure 1, Please look at this text: > if the link between X and Y is shut down by > an operator, There is no IPFRR here, it is an ordinary management action. > packets destined to X can loop between R and Y when Y > has updated its FIB while R has not yet updated its FIB, and packets > destined to Y can loop between X and S if X updates its FIB before S. > According to the current behaviour of ISIS and OSPF, this scenario > will happen most of the time because X and Y are the first routers to > be aware of the failure, so that they will update their FIBs first. > > 1 > X-------------/-------------Y > | | > | | > | | > | | > 1 | | 1 > | | > | | > | | > | | > S---------------------------R > 2 > > Figure 1: A simple topology > --- end --- > > I guess you are talking about packets originating at R and going to > X. Y should not use R as a loop-free alternative because it is not > "downstream". Cost (R,X) > Cost (Y,X). Y does not have loop free > alternative to X. So, yes, there will be packet loss until > convergence, but at least there should be no micro-loops. Please see above. The packets originate at R, or arrive at R via some un-shown network fragment. - Stewart > > Allwyn. > > Stewart Bryant wrote: >> Saku >> >> The expected use of this technology in the failure case >> is in conjunction with IPFRR where following a protected >> failure, and in the absence of a convergence control >> technology, microloops may form and/or the repair >> may be staved. >> >> Note not only do you need to learn of the failure >> and compute the new SPF, you also need to update the >> FIB. The FIB update time can be the dominant factor in >> re-convergence. >> >> - Stewart >> >> >> >> On 08/09/2012 09:35, Saku Ytti wrote: >> >>> I'm confused. >>> >>> '2. Introduction' says this: >>> --- >>> The mechanisms that are used in the >>> failure case are exactly the same as those used for managed changes. >>> For simplicity this document makes no further distinction between >>> managed and unplanned changes. >>> --- >>> >>> Does this imply, this is as useful in failure cases as it is in >>> managed changes? >>> >>> >>> I understand why it would be useful in managed changes such as metric >>> changes or artificially delayed interface shut. But I don't understand >>> how this can do any good in unmanaged change. >>> >>> Domestically my network is 5ms long, it takes me 10ms on fastest >>> available modern route engine to calculate SPF change. I flood LSP >>> immediately before calculating SFP. So before I've finished >>> calculating SPF on local-to-fault router, furthest domestic node has >>> already been busy calculating it it for 5ms and is 5ms from finishing >>> it? >>> Non-domestic routers would not cause loop,, regardless or not if >>> they've changed FIB. >>> >>> Wouldn't I double my delay, in the best scenario? As I'm waiting for >>> permission to update my FIB and I'm bound by network delay not only to >>> propagate LSP from up->down but to propagate permissions from >>> down->up? >>> So essentially I'm trading short transient loop to significantly >>> longer packet loss (remember, using the old topology will cause packet >>> loss, as link is already down). >>> >>> I'm probably not understanding this right. If this feature should also >>> provide help in failure cases, would it be possible to have step by >>> step description for both cases normal and oFIB? In terms of what >>> happens millisecond to millisecond? (In same topology, where each link >>> has described millisecond, each router described time to calculate SPF >>> and each router described time to update FIB after SPF). >>> >>> Thanks, >>> On 7 September 2012 20:40, wrote: >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> This draft is a work item of the Routing Area Working Group Working Group of the IETF. >>>> >>>> Title : Loop-free convergence using oFIB >>>> Author(s) : Mike Shand >>>> Stewart Bryant >>>> Stefano Previdi >>>> Clarence Filsfils >>>> Pierre Francois >>>> Olivier Bonaventure >>>> Filename : draft-ietf-rtgwg-ordered-fib-07.txt >>>> Pages : 25 >>>> Date : 2012-09-07 >>>> >>>> Abstract: >>>> This document describes a mechanism for use in conjunction with link >>>> state routing protocols which prevents the transient loops which >>>> would otherwise occur during topology changes. It does this by >>>> correctly sequencing the forwarding information base (FIB) updates on >>>> the routers. >>>> >>>> This mechanism can be used in the case of non-urgent link or node >>>> shutdowns and restarts or link metric changes. It can also be used >>>> in conjunction with a fast re-route mechanism which converts a sudden >>>> link or node failure into a non-urgent topology change. This is >>>> possible where a complete repair path is provided for all affected >>>> destinations. >>>> >>>> After a non-urgent topology change, each router computes a rank that >>>> defines the time at which it can safely update its FIB. A method for >>>> accelerating this loop-free convergence process by the use of >>>> completion messages is also described. >>>> >>>> The technology described in this document has been subject to >>>> extensive simulation using real network topologies and costs, and >>>> pathological convergence behaviour. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ordered-fib >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-rtgwg-ordered-fib-07 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-ordered-fib-07 >>>> >>>> >>>> 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 >>>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>> >> >> >> -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------080701030808030400080302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/09/2012 22:12, Allwyn Carvalho wrote:
In the following:

--- start ---

   For example, in Figure 1,
Please look at this text:
if the link between X and Y is shut down by
   an operator,
There is no IPFRR here, it is an ordinary management action.
packets destined to X can loop between R and Y when Y
   has updated its FIB while R has not yet updated its FIB, and packets
   destined to Y can loop between X and S if X updates its FIB before S.
   According to the current behaviour of ISIS and OSPF, this scenario
   will happen most of the time because X and Y are the first routers to
   be aware of the failure, so that they will update their FIBs first.

                                     1
                       X-------------/-------------Y
                       |                           |
                       |                           |
                       |                           |
                       |                           |
                     1 |                           | 1
                       |                           |
                       |                           |
                       |                           |
                       |                           |
                       S---------------------------R
                                     2

                        Figure 1: A simple topology
--- end ---

I guess you are talking about packets originating at R and going to X.  Y should not use R as a loop-free alternative because it is not "downstream".  Cost (R,X) > Cost (Y,X).  Y does not have loop free alternative to X.  So, yes, there will be packet loss until convergence, but at least there should be no micro-loops.
Please see above.

The packets originate at R, or arrive at R via some un-shown network fragment.

- Stewart

Allwyn.

Stewart Bryant wrote: 
Saku

The expected use of this technology in the failure case
is in conjunction with IPFRR where following a protected
failure, and in the absence of a convergence control
technology, microloops may form and/or the repair
may be staved.

Note not only do you need to learn of the failure
and compute the new SPF, you also need to update the
FIB. The FIB update time can be the dominant factor in
re-convergence.

- Stewart



On 08/09/2012 09:35, Saku Ytti wrote:
  
I'm confused.

'2. Introduction' says this:
---
The mechanisms that are used in the
    failure case are exactly the same as those used for managed changes.
    For simplicity this document makes no further distinction between
    managed and unplanned changes.
---

Does this imply, this is as useful in failure cases as it is in
managed changes?


I understand why it would be useful in managed changes such as metric
changes or artificially delayed interface shut. But I don't understand
how this can do any good in unmanaged change.

Domestically my network is 5ms long, it takes me 10ms on fastest
available modern route engine to calculate SPF change. I flood LSP
immediately before calculating SFP. So before I've finished
calculating SPF on local-to-fault router, furthest domestic node has
already been busy calculating it it for 5ms and is 5ms from finishing
it?
Non-domestic routers would not cause loop,, regardless or not if
they've changed FIB.

Wouldn't I double my delay, in the best scenario? As I'm waiting for
permission to update my FIB and I'm bound by network delay not only to
propagate LSP from up->down but to propagate permissions from
down->up?
So essentially I'm trading short transient loop to significantly
longer packet loss (remember, using the old topology will cause packet
loss, as link is already down).

I'm probably not understanding this right. If this feature should also
provide help in failure cases, would it be possible to have step by
step description for both cases normal and oFIB? In terms of what
happens millisecond to millisecond? (In same topology, where each link
has described millisecond, each router described time to calculate SPF
and each router described time to update FIB after SPF).

Thanks,
On 7 September 2012 20:40,  <internet-drafts@ietf.org> wrote:
    
A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Routing Area Working Group Working Group of the IETF.

         Title           : Loop-free convergence using oFIB
         Author(s)       : Mike Shand
                           Stewart Bryant
                           Stefano Previdi
                           Clarence Filsfils
                           Pierre Francois
                           Olivier Bonaventure
         Filename        : draft-ietf-rtgwg-ordered-fib-07.txt
         Pages           : 25
         Date            : 2012-09-07

Abstract:
    This document describes a mechanism for use in conjunction with link
    state routing protocols which prevents the transient loops which
    would otherwise occur during topology changes.  It does this by
    correctly sequencing the forwarding information base (FIB) updates on
    the routers.

    This mechanism can be used in the case of non-urgent link or node
    shutdowns and restarts or link metric changes.  It can also be used
    in conjunction with a fast re-route mechanism which converts a sudden
    link or node failure into a non-urgent topology change.  This is
    possible where a complete repair path is provided for all affected
    destinations.

    After a non-urgent topology change, each router computes a rank that
    defines the time at which it can safely update its FIB.  A method for
    accelerating this loop-free convergence process by the use of
    completion messages is also described.

    The technology described in this document has been subject to
    extensive simulation using real network topologies and costs, and
    pathological convergence behaviour.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ordered-fib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtgwg-ordered-fib-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-ordered-fib-07


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
      
    


  


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------080701030808030400080302-- From aretana@cisco.com Thu Sep 13 05:52:50 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DE921F8505; Thu, 13 Sep 2012 05:52:50 -0700 (PDT) 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=[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 Y8utbwkoa+tH; Thu, 13 Sep 2012 05:52:49 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9542521F8484; Thu, 13 Sep 2012 05:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32678; q=dns/txt; s=iport; t=1347540768; x=1348750368; h=from:to:cc:subject:date:message-id:mime-version; bh=oLij/3VDymTPGrNAm1DXvHZb5jY6mqwSL6x2hbzTfCY=; b=bFYfLtiJPrmojhshNKhDFKy3GRelSAmYtiBfOMK2abz2zB55Ze0s4aGy M5YxC2kLwRYgzphYUPfcy8V0aGVac3ekOclQpNL8cLSZr8+BplmkEOKoQ s44EZ07SyL9PatEdspzqZIBKJjYipyeKynSMgAHWzEkEqOPMQ0moIxnJQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKzWUVCtJV2Y/2dsb2JhbAA7CoJLuSSBB4InEgFYBwcSAUABPycEAQ0OGYdrC5t2oDaLIAqGHQOVX442gWmCZoFcBxwY X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208,217";a="121173717" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 13 Sep 2012 12:52:43 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8DCqhe3004808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Sep 2012 12:52:43 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.236]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Thu, 13 Sep 2012 07:52:42 -0500 From: "Alvaro Retana (aretana)" To: Adrian Farrel , "iesg-secretary@ietf.org" Subject: Request for Publication of draft-ietf-rtgwg-ipfrr-notvia-addresses-09 as Informational RFC Thread-Topic: Request for Publication of draft-ietf-rtgwg-ipfrr-notvia-addresses-09 as Informational RFC Thread-Index: AQHNka6pCsxA8uQ4UEiZFrds0j22yA== Date: Thu, 13 Sep 2012 12:52:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.236.100] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19180.005 x-tm-as-result: No--65.943300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC6655C91221aretanaciscocom_" MIME-Version: 1.0 Cc: "draft-ietf-rtgwg-ipfrr-notvia-addresses@tools.ietf.org" , "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, 13 Sep 2012 12:52:50 -0000 --_000_CC6655C91221aretanaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! This e-mail is to request the publication of draft-ietf-rtgwg-ipfrr-notvia-= addresses-09 (IP Fast Reroute Using Not-via Addresses) as an Informational = RFC. The corresponding Document Writeup is included below. Thanks! Alvaro. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet S= tandard, Informational, Experimental, or Historic)? Why is this the proper = type of RFC? Is this type of RFC indicated in the title page header? Informational; it documents a valuable mechanism developed by the WG to pro= vide full fast reroute coverage. Yes, the title page indicates the correct type. (2) The IESG approval announcement includes a Document Announcement Write-U= p. Please provide such a Document Announcement Write-Up. Recent examples ca= n be found in the "Action" announcements for approved documents. The approv= al announcement contains the following sections: Technical Summary: This document describes a mechanism that provides fast reroute in an IP net= work through encapsulation to "not-via" addresses. A single level of encap= sulation is used. The mechanism protects unicast, multicast and LDP traffi= c against link, router and shared risk group failure, regardless of network= topology and metrics. Working Group Summary: No issues. There is consensus in the WG to proceed with publication. Document Quality: The document has no substantive issues. Personnel: Alvaro Retana is the Document Shepherd. Adrian Farrel is the Responsible Area Director. [Stewart Bryant is the AD = assigned to the WG, but he is an author.] (3) Briefly describe the review of this document that was performed by the = Document Shepherd. If this version of the document is not ready for publica= tion, please explain why the document is being forwarded to the IESG. The document (currently in it's 9th iteration) has been thoroughly reviewed= . Comments have been made by the Document Shepherd related to clarity, for= m and content. All comments have been addressed. The document is ready fo= r publication. (4) Does the document Shepherd have any concerns about the depth or breadth= of the reviews that have been performed? No concerns. (5) Do portions of the document need review from a particular or from broad= er perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML= , or internationalization? If so, describe the review that took place. N/A (6) Describe any specific concerns or issues that the Document Shepherd has= with this document that the Responsible Area Director and/or the IESG shou= ld be aware of? For example, perhaps he or she is uncomfortable with certai= n parts of the document, or has concerns whether there really is a need for= it. In any event, if the WG has discussed those issues and has indicated t= hat it still wishes to advance the document, detail those concerns here. N/A (7) Has each author confirmed that any and all appropriate IPR disclosures = required for full conformance with the provisions of BCP 78 and BCP 79 have= already been filed. If not, explain why? Yes. The question has been raised throughout the process. (8) Has an IPR disclosure been filed that references this document? If so, = summarize any WG discussion and conclusion regarding the IPR disclosures. Yes, the document has IPR disclosures attached from the authors and a third= party. No concerns have been raised in the WG. (9) How solid is the WG consensus behind this document? Does it represent t= he strong concurrence of a few individuals, with others being silent, or do= es the WG as a whole understand and agree with it? This document has been a WG item for about 6 years. During this time the m= echanism (and alternatives to it) have been discussed in depth. There is s= trong consensus to publish this document as an Informational RFC. (10) Has anyone threatened an appeal or otherwise indicated extreme discont= ent? If so, please summarise the areas of conflict in separate email messag= es to the Responsible Area Director. (It should be in a separate email beca= use this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document.= (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).= Boilerplate checks are not enough; this check needs to be thorough. No nits. (12) Describe how the document meets any required formal review criteria, s= uch as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either nor= mative or informative? Yes. (14) Are there normative references to documents that are not ready for adv= ancement or are otherwise in an unclear state? If such normative references= exist, what is the plan for their completion? None exist. (15) Are there downward normative references references (see RFC 3967)? If = so, list these downward references to support the Area Director in the Last= Call procedure. No. (16) Will publication of this document change the status of any existing RF= Cs? Are those RFCs listed on the title page header, listed in the abstract,= and discussed in the introduction? If the RFCs are not listed in the Abstr= act and Introduction, explain why, and point to the part of the document wh= ere the relationship of this document to the other RFCs is discussed. If th= is information is not in the document, explain why the WG considers it unne= cessary. No. (17) Describe the Document Shepherd's review of the IANA considerations sec= tion, especially with regard to its consistency with the body of the docume= nt. Confirm that all protocol extensions that the document makes are associ= ated with the appropriate reservations in IANA registries. Confirm that any= referenced IANA registries have been clearly identified. Confirm that newl= y created IANA registries include a detailed specification of the initial c= ontents for the registry, that allocations procedures for future registrati= ons are defined, and a reasonable name for the new registry has been sugges= ted (see RFC 5226). There are no IANA considerations which arise from this document. (18) List any new IANA registries that require Expert Review for future all= ocations. Provide any public guidance that the IESG would find useful in se= lecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shephe= rd to validate sections of the document written in a formal language, such = as XML code, BNF rules, MIB definitions, etc. N/A --_000_CC6655C91221aretanaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3B68BA0AEEF0114DA11B48048AB7E4FB@cisco.com> Content-Transfer-Encoding: quoted-printable
Hi!

This e-mail is to request the publication of draft-ietf-rtgwg-ipfrr-notvia-= addresses-09 (IP Fast Reroute Using Not-via Addresses) as an Informational = RFC.  The corresponding Document Writeup is included below.

Thanks!

Alvaro.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet S= tandard, Informational, Experimental, or Historic)? Why is this the proper = type of RFC? Is this type of RFC indicated in the title page header?

Informational; it documents a valuable mechanism developed by the WG t= o provide full fast reroute coverage.

Yes, the title page indicates the correct type.

(2) The IESG approval announcement includes a Document Announcement Write-U= p. Please provide such a Document Announcement Write-Up. Recent examples ca= n be found in the "Action" announcements for approved documents. = The approval announcement contains the following sections:

Technical Summary:
   
This document describes a mechanism that provides fast reroute in an I= P network through encapsulation to "not-via" addresses. = ; A single level of encapsulation is used.  The mechani= sm protects unicast, multicast and LDP traffic against link, router an= d shared risk group failure, regardless of network topology and metrics= .

Working Group Summary:

No issues.  There is consensus in the WG to proceed with pub= lication.

Document Quality:

The document has no substantive issues.  

Personnel:

Alvaro Retana is the Document Shepherd.

Adrian Farrel is the Responsible Area Director.  [Stewart Br= yant is the AD assigned to the WG, but he is an author.]

(3) Briefly describe the review of this document that was performed by the = Document Shepherd. If this version of the document is not ready for publica= tion, please explain why the document is being forwarded to the IESG.

The document (currently in it's 9th iteration) has been thoroughly rev= iewed.  Comments have been made by the Document Shepherd related to cl= arity, form and content.  All comments have been addressed.  The = document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth= of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broad= er perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML= , or internationalization? If so, describe the review that took place.

N/A

(6) Describe any specific concerns or issues that the Document Shepherd has= with this document that the Responsible Area Director and/or the IESG shou= ld be aware of? For example, perhaps he or she is uncomfortable with certai= n parts of the document, or has concerns whether there really is a need for it. In any event, if the WG ha= s discussed those issues and has indicated that it still wishes to advance = the document, detail those concerns here.

N/A

(7) Has each author confirmed that any and all appropriate IPR disclosures = required for full conformance with the provisions of BCP 78 and BCP 79 have= already been filed. If not, explain why?

Yes.  The question has been raised throughout the process.

(8) Has an IPR disclosure been filed that references this document? If so, = summarize any WG discussion and conclusion regarding the IPR disclosures.

Yes, the document has IPR disclosures attached from the authors a= nd a third party.  No concerns have been raised in the WG.

(9) How solid is the WG consensus behind this document? Does it represent t= he strong concurrence of a few individuals, with others being silent, or do= es the WG as a whole understand and agree with it?

This document has been a WG item for about 6 years.  During this = time the mechanism (and alternatives to it) have been discussed in depth. &= nbsp;There is strong consensus to publish this document as an Informational= RFC.

(10) Has anyone threatened an appeal or otherwise indicated extreme discont= ent? If so, please summarise the areas of conflict in separate email messag= es to the Responsible Area Director. (It should be in a separate email beca= use this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document.= (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). B= oilerplate checks are not enough; this check needs to be thorough.

No nits.

(12) Describe how the document meets any required formal review criteria, s= uch as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either nor= mative or informative?

Yes.

(14) Are there normative references to documents that are not ready for adv= ancement or are otherwise in an unclear state? If such normative references= exist, what is the plan for their completion?

None exist.

(15) Are there downward normative references references (see RFC 3967)? If = so, list these downward references to support the Area Director in the Last= Call procedure.

No.

(16) Will publication of this document change the status of any existing RF= Cs? Are those RFCs listed on the title page header, listed in the abstract,= and discussed in the introduction? If the RFCs are not listed in the Abstr= act and Introduction, explain why, and point to the part of the document where the relationship of this docum= ent to the other RFCs is discussed. If this information is not in the docum= ent, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations sec= tion, especially with regard to its consistency with the body of the docume= nt. Confirm that all protocol extensions that the document makes are associ= ated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been = clearly identified. Confirm that newly created IANA registries include a de= tailed specification of the initial contents for the registry, that allocat= ions procedures for future registrations are defined, and a reasonable name for the new registry has been suggested= (see RFC 5226).

There are= no IANA considerations which arise from this document.

(18) List any new IANA registries that require Expert Review for future all= ocations. Provide any public guidance that the IESG would find useful in se= lecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document Shephe= rd to validate sections of the document written in a formal language, such = as XML code, BNF rules, MIB definitions, etc.

N/A
--_000_CC6655C91221aretanaciscocom_-- From aretana@cisco.com Thu Sep 13 05:52:50 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B693A21F8528; Thu, 13 Sep 2012 05:52:50 -0700 (PDT) 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=[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 F8qNQMYFa8L0; Thu, 13 Sep 2012 05:52:49 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 94D7021F847F; Thu, 13 Sep 2012 05:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21843; q=dns/txt; s=iport; t=1347540768; x=1348750368; h=from:to:cc:subject:date:message-id:mime-version; bh=7V7Rdqspc2Bk7Q7kkgrYpl6o3tsMdqi4KHpEHu/i6PU=; b=ZH7Vo5jlc20Ly2bXyH+E41iMiTity+1ifyFZpCNY7yfaOUFUv9xbnLsE XlBI3A2S4PkC6IeM0+76SyBMP5qrqEB4qbik4KSr+Z7ubqjAhMjhYJFUL VWic08x4+xq+UkdVgQA/8FplsMjQmUt51PmgxxakevynWyLMXbWqpVyBB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANzVUVCtJXG//2dsb2JhbAA7CoJLuSSBB4InEgFYBwcSAYEAJwQBDQ4Zh2sLm3agNosgCoYdA5VfjjaBaYJmgVwHHBg X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208,217";a="121225553" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 13 Sep 2012 12:52:37 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8DCqbhL022875 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Sep 2012 12:52:37 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.236]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Thu, 13 Sep 2012 07:52:36 -0500 From: "Alvaro Retana (aretana)" To: Adrian Farrel , "iesg-secretary@ietf.org" Subject: Request for Publication of draft-ietf-rtgwg-ordered-fib-07 as Informational RFC Thread-Topic: Request for Publication of draft-ietf-rtgwg-ordered-fib-07 as Informational RFC Thread-Index: AQHNka6mC2DwFSwEskO7kjEuqjcigg== Date: Thu, 13 Sep 2012 12:52:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.236.100] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19180.005 x-tm-as-result: No--62.305000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC6655B3121Faretanaciscocom_" MIME-Version: 1.0 Cc: "draft-ietf-rtgwg-ordered-fib@tools.ietf.org" , "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, 13 Sep 2012 12:52:51 -0000 --_000_CC6655B3121Faretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! This e-mail is to request the publication of draft-ietf-rtgwg-ordered-fib-0= 7 (Loop-free convergence using oFIB) as an Informational RFC. The correspo= nding Document Writeup is included below. Thanks! Alvaro. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet S= tandard, Informational, Experimental, or Historic)? Why is this the proper = type of RFC? Is this type of RFC indicated in the title page header? Informational; it documents a valuable mechanism developed by the WG to pre= vent transient loops. Yes, the title page indicates the correct type. (2) The IESG approval announcement includes a Document Announcement Write-U= p. Please provide such a Document Announcement Write-Up. Recent examples ca= n be found in the "Action" announcements for approved documents. The approv= al announcement contains the following sections: Technical Summary: This document describes a mechanism for use in conjunction with link state = routing protocols which prevents the transient loops which would otherwise = occur during topology changes. It does this by correctly sequencing the FIB= updates on the routers. Working Group Summary: No issues. There is consensus in the WG to proceed with publication. Document Quality: This document presents the general mechanism and operation of oFIB, it does= n't define routing protocol-specific extensions =97 which means that there = are no implementations possible, but also no further work is planned at thi= s time. The document has no substantive issues. Personnel: Alvaro Retana is the Document Shepherd. Adrian Farrel is the Responsible Area Director. [Stewart Bryant is the AD = assigned to the WG, but he is an author.] (3) Briefly describe the review of this document that was performed by the = Document Shepherd. If this version of the document is not ready for publica= tion, please explain why the document is being forwarded to the IESG. The document (currently in it's 7th iteration) has been thoroughly reviewed= . Comments have been made by the Document Shepherd related to clarity, for= m and content. All comments have been addressed. The document is ready fo= r publication. (4) Does the document Shepherd have any concerns about the depth or breadth= of the reviews that have been performed? No concerns. (5) Do portions of the document need review from a particular or from broad= er perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML= , or internationalization? If so, describe the review that took place. N/A (6) Describe any specific concerns or issues that the Document Shepherd has= with this document that the Responsible Area Director and/or the IESG shou= ld be aware of? For example, perhaps he or she is uncomfortable with certai= n parts of the document, or has concerns whether there really is a need for= it. In any event, if the WG has discussed those issues and has indicated t= hat it still wishes to advance the document, detail those concerns here. N/A (7) Has each author confirmed that any and all appropriate IPR disclosures = required for full conformance with the provisions of BCP 78 and BCP 79 have= already been filed. If not, explain why? Yes. The question has been raised throughout the process. (8) Has an IPR disclosure been filed that references this document? If so, = summarize any WG discussion and conclusion regarding the IPR disclosures. Yes, document has an IPR disclosure attached from the authors. No concerns= have been raised in the WG. (9) How solid is the WG consensus behind this document? Does it represent t= he strong concurrence of a few individuals, with others being silent, or do= es the WG as a whole understand and agree with it? This document has been a WG item for about 6 years. During this time the m= echanism (application and potential implementations) have been discussed in= depth. There is strong consensus to publish this document as an Informati= onal RFC. (10) Has anyone threatened an appeal or otherwise indicated extreme discont= ent? If so, please summarise the areas of conflict in separate email messag= es to the Responsible Area Director. (It should be in a separate email beca= use this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document.= (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).= Boilerplate checks are not enough; this check needs to be thorough. Only nit to point out is that 6 authors are listed. The authors have been = made aware and are prepared to request an exception before publication. (12) Describe how the document meets any required formal review criteria, s= uch as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either nor= mative or informative? Yes. (14) Are there normative references to documents that are not ready for adv= ancement or are otherwise in an unclear state? If such normative references= exist, what is the plan for their completion? None exist. (15) Are there downward normative references references (see RFC 3967)? If = so, list these downward references to support the Area Director in the Last= Call procedure. No. (16) Will publication of this document change the status of any existing RF= Cs? Are those RFCs listed on the title page header, listed in the abstract,= and discussed in the introduction? If the RFCs are not listed in the Abstr= act and Introduction, explain why, and point to the part of the document wh= ere the relationship of this document to the other RFCs is discussed. If th= is information is not in the document, explain why the WG considers it unne= cessary. No. (17) Describe the Document Shepherd's review of the IANA considerations sec= tion, especially with regard to its consistency with the body of the docume= nt. Confirm that all protocol extensions that the document makes are associ= ated with the appropriate reservations in IANA registries. Confirm that any= referenced IANA registries have been clearly identified. Confirm that newl= y created IANA registries include a detailed specification of the initial c= ontents for the registry, that allocations procedures for future registrati= ons are defined, and a reasonable name for the new registry has been sugges= ted (see RFC 5226). There are no IANA considerations which arise from this document. (18) List any new IANA registries that require Expert Review for future all= ocations. Provide any public guidance that the IESG would find useful in se= lecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shephe= rd to validate sections of the document written in a formal language, such = as XML code, BNF rules, MIB definitions, etc. N/A --_000_CC6655B3121Faretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <850FD098B6730248B414DB85CEC87F87@cisco.com> Content-Transfer-Encoding: quoted-printable

Hi!

This e-mai= l is to request the publication of draft-ietf-rtgwg-ordered-fib-07 (Loop-fr= ee convergence using oFIB) as an Informational RFC.  The corresponding= Document Writeup is included below.

Thanks!

Alvaro.


(1) What t= ype of RFC is being requested (BCP, Proposed Standard, Internet Standard, I= nformational, Experimental, or Historic)? Why is this the proper type of RF= C? Is this type of RFC indicated in the title page header?

Informational; it documents a valuable mecha= nism developed by the WG to prevent transient loops.

Yes, the title page indicates the correct ty= pe.

(2) The IE= SG approval announcement includes a Document Announcement Write-Up. Please = provide such a Document Announcement Write-Up. Recent examples can be found= in the "Action" announcements for approved documents. The approval announcement contains the following secti= ons:

Technical = Summary:

This document describes a mechanism for use in conjunction = with link state routing protocols which prevents the transient loops = which would otherwise occur during topology changes. It does this= by correctly sequencing the FIB updates on the routers.=

Working Group Summary:

No issues.  There is consensus in the WG to proceed with publication.<= /p>

Document Quality:

This document presents the general mechanism and operation of oFIB, it does= n't define routing protocol-specific extensions =97 which means that there = are no implementations possible, but also no further work is planned at thi= s time.  The document has no substantive issues.

Personnel:

Alvaro Retana is the Document Shepherd.

Adrian Farrel is the Responsible Area Director.  [Stewart Bryant is th= e AD assigned to the WG, but he is an author.]

(3) Briefl= y describe the review of this document that was performed by the Document S= hepherd. If this version of the document is not ready for publication, plea= se explain why the document is being forwarded to the IESG.

The docume= nt (currently in it's 7th iteration) has been thoroughly reviewed.  Co= mments have been made by the Document Shepherd related to clarity, form and= content.  All comments have been addressed.  The document is ready for publication.

(4) Does t= he document Shepherd have any concerns about the depth or breadth of the re= views that have been performed?

No concern= s.

(5) Do por= tions of the document need review from a particular or from broader perspec= tive, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or inter= nationalization? If so, describe the review that took place.

N/A

(6) Descri= be any specific concerns or issues that the Document Shepherd has with this= document that the Responsible Area Director and/or the IESG should be awar= e of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns wheth= er there really is a need for it. In any event, if the WG has discussed tho= se issues and has indicated that it still wishes to advance the document, d= etail those concerns here.

N/A

(7) Has ea= ch author confirmed that any and all appropriate IPR disclosures required f= or full conformance with the provisions of BCP 78 and BCP 79 have already b= een filed. If not, explain why?

Yes.  = ;The question has been raised throughout the process.

(8) Has an= IPR disclosure been filed that references this document? If so, summarize = any WG discussion and conclusion regarding the IPR disclosures.

Yes, = document has an IPR disclosure attached from the authors.  No concerns= have been raised in the WG.

(9) How so= lid is the WG consensus behind this document? Does it represent the strong = concurrence of a few individuals, with others being silent, or does the WG = as a whole understand and agree with it?

This docum= ent has been a WG item for about 6 years.  During this time the mechan= ism (application and potential implementations) have been discussed in dept= h.  There is strong consensus to publish this document as an Informational RFC.

(10) Has a= nyone threatened an appeal or otherwise indicated extreme discontent? If so= , please summarise the areas of conflict in separate email messages to the = Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) =

No.

(11) Ident= ify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idn= its/ and the Internet-Drafts Checklist). Boilerplate checks are not eno= ugh; this check needs to be thorough.

Only nit t= o point out is that 6 authors are listed.  The authors have been made = aware and are prepared to request an exception before publication.

(12) Descr= ibe how the document meets any required formal review criteria, such as the= MIB Doctor, media type, and URI type reviews.

N/A

(13) Have = all references within this document been identified as either normative or = informative?

Yes.

(14) Are t= here normative references to documents that are not ready for advancement o= r are otherwise in an unclear state? If such normative references exist, wh= at is the plan for their completion?

None exist= .

(15) Are t= here downward normative references references (see RFC 3967)? If so, list t= hese downward references to support the Area Director in the Last Call proc= edure.

No.

(16) Will = publication of this document change the status of any existing RFCs? Are th= ose RFCs listed on the title page header, listed in the abstract, and discu= ssed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to= the part of the document where the relationship of this document to the ot= her RFCs is discussed. If this information is not in the document, explain = why the WG considers it unnecessary.

No.

(17) Descr= ibe the Document Shepherd's review of the IANA considerations section, espe= cially with regard to its consistency with the body of the document. Confir= m that all protocol extensions that the document makes are associated with the appropriate reservations in IAN= A registries. Confirm that any referenced IANA registries have been clearly= identified. Confirm that newly created IANA registries include a detailed = specification of the initial contents for the registry, that allocations procedures for future registrations are= defined, and a reasonable name for the new registry has been suggested (se= e RFC 5226).

There are no IANA cons= iderations which arise from this document.

(18) List = any new IANA registries that require Expert Review for future allocations. = Provide any public guidance that the IESG would find useful in selecting th= e IANA Experts for these new registries.

N/A

(19) Descr= ibe reviews and automated checks performed by the Document Shepherd to vali= date sections of the document written in a formal language, such as XML cod= e, BNF rules, MIB definitions, etc.

N/A

--_000_CC6655B3121Faretanaciscocom_-- From aretana@cisco.com Mon Sep 24 11:37:57 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A89221F887B for ; Mon, 24 Sep 2012 11:37:57 -0700 (PDT) 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 9rZbxB8gi8-k for ; Mon, 24 Sep 2012 11:37:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 92F2F21F8876 for ; Mon, 24 Sep 2012 11:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1353; q=dns/txt; s=iport; t=1348511876; x=1349721476; h=from:to:subject:date:message-id:mime-version; bh=bri7cOT3D+iNylNcHX+aFAG7bQQxmFqErkFK+WVgWaI=; b=GWJ5GqTumjkK0Wn5eK5rYrZQPvmkuvX7Ye/c+/HQUmKD66SgYQ7Ck4y9 UH2Xtue+n7IIZYCJj+NiVTLXmtcyVYT3l/StbeExSysNZ5+xIKVSGs5P2 zk4ufZujbJ4msRkjih+5lucIxPeSJ6zBVXf4tcs8i65FpZUChKu6gAMPz w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJ2nYFCtJV2b/2dsb2JhbABFgku8AIEIghcQEgF4AQsBdCcENYdjl0CBKJ9+kUYDlWWOOoFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,477,1344211200"; d="scan'208,217";a="124781100" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 24 Sep 2012 18:37:56 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8OIbuJL019872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Sep 2012 18:37:56 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.236]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Mon, 24 Sep 2012 13:37:55 -0500 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: Agenda Items for Atlanta Thread-Topic: Agenda Items for Atlanta Thread-Index: AQHNmoO2yUzueOClQUu7pfXKUiCs3w== Date: Mon, 24 Sep 2012 18:37:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.238.186] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19206.004 x-tm-as-result: No--31.880800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC8620C23E45aretanaciscocom_" 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: Mon, 24 Sep 2012 18:37:57 -0000 --_000_CC8620C23E45aretanaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! We're still a few weeks away from the next in-person meeting, but I would l= ike to start collecting topics for the agenda. Please let me know of any time requests. I would like to see discussions o= f any proposed presentations on the list. Thanks! Alvaro. --_000_CC8620C23E45aretanaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi!

We're still a few weeks away from the next in-person meeting, but I wo= uld like to start collecting topics for the agenda.

Please let me know of any time requests.  I would like to see dis= cussions of any proposed presentations on the list.

Thanks!

Alvaro.
--_000_CC8620C23E45aretanaciscocom_-- From adrian@olddog.co.uk Tue Sep 25 05:48:43 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7348B21F865D for ; Tue, 25 Sep 2012 05:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 RqWFcZpQOX76 for ; Tue, 25 Sep 2012 05:48:42 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id DD26D21F862B for ; Tue, 25 Sep 2012 05:48:41 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q8PCmOXC003719; Tue, 25 Sep 2012 13:48:24 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q8PCmI86003655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Sep 2012 13:48:21 +0100 From: "Adrian Farrel" To: , "'Retana, Alvaro'" References: Your message of "Wed, 20 Jun 2012 16:44:11 -0000." <201206201902.q5KJ2NpP080034@gateway.ipv6.occnc.com> In-Reply-To: <201206201902.q5KJ2NpP080034@gateway.ipv6.occnc.com> Subject: RE: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01 Date: Tue, 25 Sep 2012 13:48:18 +0100 Message-ID: <035b01cd9b1c$0b305980$21910c80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHOHM77EQMR0T71g4WEbeB8sRC0vJeZ/NwA Content-Language: en-gb Cc: "'White, Russell'" , rkebler@juniper.net, mike@mshand.org.uk, patent.licensing@ericsson.com, akatlas@juniper.net, maciek@bgp.nu, rtgwg@ietf.org, stbryant@cisco.com X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 12:48:43 -0000 Hey Curtis, Missed this thread, but had I seen it I would have noted that draft-lee-ccamp-rsvp-te-exclude-route-00 was posted in May 2002, and the poorly-named draft-lee-rsvp-te-exclude-route was posted in March 2002. Cheers, Adrian > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@occnc.com] > Sent: 20 June 2012 20:02 > To: Retana, Alvaro > Cc: curtis@occnc.com; Gabor.Sandor.Enyedi@ericsson.com; akatlas@juniper.net; > rkebler@juniper.net; Andras.Csaszar@ericsson.com; mike@mshand.org.uk; > maciek@bgp.nu; adrian@olddog.co.uk; stbryant@cisco.com; rtgwg@ietf.org; > White, Russell; patent.licensing@ericsson.com > Subject: Re: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement > about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01 > > > Alvaro, > > Please remind me. Has there been any discussion as to whether the XRO > (exclude route object) in RSVP-TE (RFC 4874) would qualify as prior > art, since the XRO specifies a "system and method of implementing a > lightweight not-via fast reroute in a telecommunications network"? > The patent seems to be a method patent and not a use patent. It > appears to me that the only major difference between the XRO and the > Ericson patent (which may affect not-via and use of redundant trees of > which maximally redundant would be a subset), is that XRO is applied > to RSVP-TE and was intended to aid in multi-domain use of RSVP-TE and > the Ericson patent uses a functionally identical approach (indicate > which resources to avoid) applied to IP rather than RSVP-TE. > > The XRO was introduced in draft-ietf-ccamp-rsvp-te-exclude-route-00 in > June 2003 which became an RFC in 2007. The patent was submitted in > 2006, three years after XRO publication (not counting individual > submissions prior to the first WG draft). If this counts as prior > art, the patent is invalid. > > I'm not sure how this could affect MRT but not affect the notvia work > (no IPR disclosure from Ericson on that). The > draft-bryant-shand-ipfrr-notvia-addresses-00 individual submission was > published in March 2005. This also precedes the patent. > > The only reason I can see that notvia and XRO might be considered > different is that they don't specify a redundant tree. > > Another question for legal types is whether computing redundant trees > is an algorithm (specifically a graph theory algorithm) and therefore > not patentable at all. Should a patent of this type specify the use > of a redundant tree algorithm in IP or LDP? Can a patent apply to the > use of *any* algorithm which falls within the classification of a > redundant tree algorithm in IP or LDP? > > Of course, I am not an attorney so I cannot give a legal opinion on > this matter or any other legal matter. I am asking if there has ever > been such a discussion and whether my layperson legally uniformed > opinion might by chance be accurate or close to accurate. > > If the patent is valid, does apply to the MRT work, and has no > licensing specified, IMHO the WG should cease to work on this. > > Curtis > > > In message > t> > "Retana, Alvaro" writes: > > As a reminder, having an IPR claim does not disqualify a draft from advancing in > the IETF, being adopted by a working group or from eventually becoming a > standard. It just represents one more item to be considered by the working > group. > > http://www.ietf.org/ipr/policy.html > > To help in the evaluation, the following link is to the patent application itself > (provided by the authors): > > http://www.wipo.int/patentscope/search/en/detail.jsf?docId=WO2010055408&r > ecNum=1&docAn=IB2009007467&queryString=FP:%28PCT/IB2009/007467%29&m > axRec=1 > > > As a chair, my job is to remind the WG of the IETF policy -- the decision of > whether we should continue to work on this item is to be made by the individuals > participating in the WG. Because the concern expressed by Curtis has come up > several times (from different people), including at the meeting in Taipei, I would > like to hear other opinions specific to the impact of the terms of the IPR filing with > respect to the architecture proposed. > > Thanks! > > Alvaro. > > > > -----Original Message----- > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > > Of Curtis Villamizar > > Sent: Wednesday, June 20, 2012 11:53 AM > > To: Gabor.Sandor.Enyedi@ericsson.com; akatlas@juniper.net; > > rkebler@juniper.net; Andras.Csaszar@ericsson.com; russwh@cisco.com; > > mike@mshand.org.uk; maciek@bgp.nu; adrian@olddog.co.uk; > > stbryant@cisco.com; rtgwg@ietf.org > > Cc: patent.licensing@ericsson.com > > Subject: Re: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s > > Statement about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01 > > > > > > In message <20120618155048.18575.97874.idtracker@ietfa.amsl.com> > > IETF Secretariat writes: > > > > > > > > Dear Gabor Sandor Envedi, Alia Atlas, Robert Kebler, Andras Csaszar, > > > Russ White, Mike Shand, Maciek Konstantynowicz: > > > > > > An IPR disclosure that pertains to your Internet-Draft entitled "An > > > Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees" > > > (draft- ietf-rtgwg-mrt-frr-architecture) was submitted to the IETF > > > Secretariat on 2012-06-18 and has been posted on the "IETF Page of > > > Intellectual Property Rights Disclosures" > > > (https://datatracker.ietf.org/ipr/1801/). The title of the IPR > > > disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement > > > about IPR related to draft-ietf-rtgwg-mrt-frr-architecture-01.""); > > > > > > The IETF Secretariat > > > > > > Prior reasons to be hesitant about this work included the rather > > substantial change to routing and forwarding, and the need to deploy > > network wide (no accommodation for legacy equipment). Regardless, it > > became a WG item. > > > > Now that there is an IPR disclosure with no statement at all regarding > > licensing terms, it might be time to reconsider whether the WG should > > go forward with this work. > > > > IMHO- If the IPR disclosure is not updated with a reasonable and > > non-discriminatory, preferably royalty-free, licensing statement, the > > MRT work should be abandoned by RTGWG. > > > > Curtis > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg