From gopakumar.c@huawei.com Tue Jan 1 21:36:33 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FBA21E8087 for ; Tue, 1 Jan 2013 21:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wjaTnf5eLr4 for ; Tue, 1 Jan 2013 21:36:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3D05D21E8085 for ; Tue, 1 Jan 2013 21:36:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AND06276; Wed, 02 Jan 2013 05:36:28 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 2 Jan 2013 05:35:28 +0000 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 2 Jan 2013 05:35:56 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 2 Jan 2013 13:35:48 +0800 From: Gopakumar C To: Bharat Joshi , "rtgwg@ietf.org" Subject: RE: A query on RIPv2 Thread-Topic: A query on RIPv2 Thread-Index: Ac3iiwsWsu05KlXPT+O3nDXOBUFIIQGHsnnw Date: Wed, 2 Jan 2013 05:35:47 +0000 Message-ID: <1C717044A9DD904E83DBD133393FD8D00843EFAD@szxeml525-mbs.china.huawei.com> References: <35347FBF2796F94E936EE76C0E6047ED2B643823@BLRKECMBX13.ad.infosys.com> In-Reply-To: <35347FBF2796F94E936EE76C0E6047ED2B643823@BLRKECMBX13.ad.infosys.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.96.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 05:36:33 -0000 Dear Bharat, In the scenario that you mentioned RIP packet will have two RTEs after the = RIP header, first one will be authentication RTE and second one will be FUL= L table request RTE with address family identifier as 0. This may be follow= ed by authentication trailer depending on the authentication scheme selecte= d. RFC section 3.9.1 first states the general format of RIP Version 2 request = message. Even though authentication is present, there is only one RTE (full= table RTE) other than authentication as authentication RTE doesn't convey = routing information. Hope this helps. Note: I think this is not correct forum to discuss this issue. I am not sur= e where you can post it as RIP mailing list is not active anymore. Regards, -Gopakumar -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of B= harat Joshi Sent: Tuesday, December 25, 2012 4:02 PM To: rtgwg@ietf.org Cc: Bharat Joshi Subject: A query on RIPv2 Hi All, I came across some text in RFC 2453 (RIPv2) which has confused me. It = would be great if someone can clarify this for me. I searched the net and l= ooked through the errata but could not find any reference to this. In section 3.9.1 of RFC 2453 (http://tools.ietf.org/html/rfc2453#section-3.= 9.1), in second para, following text is available: There is one special case. If there is exactly one entry in the request, and it has an address family identifier of zero and a metric of infinity (i.e., 16), then this is a request to send the entire routing table. In section 4.1 of same RFC (http://tools.ietf.org/html/rfc2453#section-4.1)= , in first para, following text is available: If the Address Family Identifier of the first (and only the first) entry in the message is 0xFFFF, then the remainder of the entry contains the authentication. Now what has confused me is that if a router is configured to use authe= ntication, how should its 'request' message for full routing table look? Sh= ould it go without authentication information or with authentication inform= ation? If it goes with authentication information then it is not conforming to= the statement of 3.9.1. If it goes without authentication information then= it is not conforming to the user configuration and also there may be secur= ity issues. Regards, Bharat PS: I am currently not subscribed to RTG working group mailing list, so ple= ase reply all so that I can get your reply. **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solel= y=20 for the use of the addressee(s). If you are not the intended recipient, ple= ase=20 notify the sender by e-mail and delete the original message. Further, you a= re not=20 to copy, disclose, or distribute this e-mail or its contents to any other p= erson and=20 any such actions are unlawful. This e-mail may contain viruses. Infosys has= taken=20 every reasonable precaution to minimize this risk, but is not liable for an= y damage=20 you may sustain as a result of any virus in this e-mail. You should carry o= ut your=20 own virus checks before opening the e-mail or attachment. Infosys reserves = the=20 right to monitor and review the content of all messages sent to or from thi= s e-mail=20 address. Messages sent to or from this e-mail address may be stored on the= =20 Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From bharat_joshi@infosys.com Tue Jan 1 22:08:33 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95CC321F9099 for ; Tue, 1 Jan 2013 22:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cRnySsG4fHK for ; Tue, 1 Jan 2013 22:08:32 -0800 (PST) Received: from kecgate06.infosys.com (kecgate06.infosys.com [122.98.14.33]) by ietfa.amsl.com (Postfix) with ESMTP id 085E521F9096 for ; Tue, 1 Jan 2013 22:08:31 -0800 (PST) X-TM-IMSS-Message-ID: <330d353a002d0693@infosys.com> Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by infosys.com ([122.98.14.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 330d353a002d0693 ; Wed, 2 Jan 2013 11:42:13 +0530 Received: from BLRKECHUB06.ad.infosys.com (10.66.236.116) by blrkechub01.ad.infosys.com (10.66.236.41) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 2 Jan 2013 11:38:27 +0530 Received: from BLRKECMBX12.ad.infosys.com ([fe80::a0dd:c35f:79ad:4993]) by BLRKECHUB06.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 11:38:27 +0530 From: Bharat Joshi To: Gopakumar C , "rtgwg@ietf.org" Subject: RE: A query on RIPv2 Thread-Topic: A query on RIPv2 Thread-Index: Ac3iiwsWsu05KlXPT+O3nDXOBUFIIQGHsnnwAAFS7UA= Date: Wed, 2 Jan 2013 06:08:26 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED2D11A681@BLRKECMBX12.ad.infosys.com> References: <35347FBF2796F94E936EE76C0E6047ED2B643823@BLRKECMBX13.ad.infosys.com>, <1C717044A9DD904E83DBD133393FD8D00843EFAD@szxeml525-mbs.china.huawei.com> In-Reply-To: <1C717044A9DD904E83DBD133393FD8D00843EFAD@szxeml525-mbs.china.huawei.com> Accept-Language: en-US, en-IN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 06:08:33 -0000 Dear Gopakumar, I understand what you are saying. In fact, I tested some vendor's be= haviour to understand how other people have implemented it. When authentication is enabled, there should be 2 route entries for = things to work but I still feel that the RFC is not clear enough on this. I= n fact, in my search, I found that Quagga has issues with this. Regards, Bharat ________________________________________ From: Gopakumar C [gopakumar.c@huawei.com] Sent: Wednesday, January 02, 2013 11:05 AM To: Bharat Joshi; rtgwg@ietf.org Subject: RE: A query on RIPv2 Dear Bharat, In the scenario that you mentioned RIP packet will have two RTEs after the = RIP header, first one will be authentication RTE and second one will be FUL= L table request RTE with address family identifier as 0. This may be follow= ed by authentication trailer depending on the authentication scheme selecte= d. RFC section 3.9.1 first states the general format of RIP Version 2 request = message. Even though authentication is present, there is only one RTE (full= table RTE) other than authentication as authentication RTE doesn't convey = routing information. Hope this helps. Note: I think this is not correct forum to discuss this issue. I am not sur= e where you can post it as RIP mailing list is not active anymore. Regards, -Gopakumar -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of B= harat Joshi Sent: Tuesday, December 25, 2012 4:02 PM To: rtgwg@ietf.org Cc: Bharat Joshi Subject: A query on RIPv2 Hi All, I came across some text in RFC 2453 (RIPv2) which has confused me. It = would be great if someone can clarify this for me. I searched the net and l= ooked through the errata but could not find any reference to this. In section 3.9.1 of RFC 2453 (http://tools.ietf.org/html/rfc2453#section-3.= 9.1), in second para, following text is available: There is one special case. If there is exactly one entry in the request, and it has an address family identifier of zero and a metric of infinity (i.e., 16), then this is a request to send the entire routing table. In section 4.1 of same RFC (http://tools.ietf.org/html/rfc2453#section-4.1)= , in first para, following text is available: If the Address Family Identifier of the first (and only the first) entry in the message is 0xFFFF, then the remainder of the entry contains the authentication. Now what has confused me is that if a router is configured to use authe= ntication, how should its 'request' message for full routing table look? Sh= ould it go without authentication information or with authentication inform= ation? If it goes with authentication information then it is not conforming to= the statement of 3.9.1. If it goes without authentication information then= it is not conforming to the user configuration and also there may be secur= ity issues. Regards, Bharat PS: I am currently not subscribed to RTG working group mailing list, so ple= ase reply all so that I can get your reply. **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solel= y for the use of the addressee(s). If you are not the intended recipient, ple= ase notify the sender by e-mail and delete the original message. Further, you a= re not to copy, disclose, or distribute this e-mail or its contents to any other p= erson and any such actions are unlawful. This e-mail may contain viruses. Infosys has= taken every reasonable precaution to minimize this risk, but is not liable for an= y damage you may sustain as a result of any virus in this e-mail. You should carry o= ut your own virus checks before opening the e-mail or attachment. Infosys reserves = the right to monitor and review the content of all messages sent to or from thi= s e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From internet-drafts@ietf.org Fri Jan 4 10:24:58 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4020221F88BF; Fri, 4 Jan 2013 10:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.243, 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 SF+RXVAFKfRo; Fri, 4 Jan 2013 10:24:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6AF21F8858; Fri, 4 Jan 2013 10:24:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-ordered-fib-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130104182457.32257.66056.idtracker@ietfa.amsl.com> Date: Fri, 04 Jan 2013 10:24:57 -0800 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 18:24: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 : Framework for 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-08.txt Pages : 26 Date : 2013-01-04 Abstract: This document describes the framework of 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. However mechanism described in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment. 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-ordered-fib-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Thu Jan 17 10:46:35 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2E721F8893; Thu, 17 Jan 2013 10:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 ILPY57lYHzY8; Thu, 17 Jan 2013 10:46:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3DD21F8860; Thu, 17 Jan 2013 10:46:16 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (A Framework for IP and MPLS Fast Reroute Using Not-via Addresses) to Informational RFC X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130117184616.30687.53894.idtracker@ietfa.amsl.com> Date: Thu, 17 Jan 2013 10:46:16 -0800 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:46:35 -0000 The IESG has received a request from the Routing Area Working Group WG (rtgwg) to consider the following document: - 'A Framework for IP and MPLS Fast Reroute Using Not-via Addresses' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document presents a framework for providing fast reroute in an IP or MPLS network through encapsulation and forwarding to "not-via" addresses. The general approach described uses a single level of encapsulation and could be used to protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics. The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-rtgwg-ipfrr-notvia-addresses/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-rtgwg-ipfrr-notvia-addresses/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1794/ http://datatracker.ietf.org/ipr/1455/ From iesg-secretary@ietf.org Thu Jan 17 10:47:19 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97AA21F888B; Thu, 17 Jan 2013 10:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 1P8E4bTO+xH4; Thu, 17 Jan 2013 10:47:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FA621F888C; Thu, 17 Jan 2013 10:47:15 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Framework for Loop-free convergence using oFIB) to Informational RFC X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130117184715.30663.73380.idtracker@ietfa.amsl.com> Date: Thu, 17 Jan 2013 10:47:15 -0800 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:47:20 -0000 The IESG has received a request from the Routing Area Working Group WG (rtgwg) to consider the following document: - 'Framework for Loop-free convergence using oFIB' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the framework of 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. However mechanism described in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-rtgwg-ordered-fib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-rtgwg-ordered-fib/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/875/ From pthubert@cisco.com Tue Jan 22 17:26:14 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9D621F8824 for ; Tue, 22 Jan 2013 17:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVOuNa8JWF2a for ; Tue, 22 Jan 2013 17:26:13 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D90AB21F881A for ; Tue, 22 Jan 2013 17:26:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2346; q=dns/txt; s=iport; t=1358904374; x=1360113974; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ZuQ+g4ZoUYQhTvgFhfz9FQ9WY+NDvfzC1oBbkt7ZdyE=; b=T07g/EU+0qh3/E52S5mT6CATNMzP6Zbllv7w9OC1AoGb6bouUrsUqYxI BbcN3TwyeRc/unFz+ovI1vkXIBqJnZNcY4LTPE8wmCK/kgHNQGi4a1qNo Lnu+NndKS8gL10O5xc/G4EvaKROmhJ5niKYWX6mD/P67d/3Kqgwx1qQ7q k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAFM7/1CtJV2d/2dsb2JhbABEhkW2X34Wc4IeAQEBBCMRQw4GAQgRBAEBAwIGHQMCBDAUAQYBAQUEAQQTCAESh34Mm1qOVYRRjhyBI48AMmEDklmET48tgmgNgiQ X-IronPort-AV: E=Sophos;i="4.84,518,1355097600"; d="scan'208";a="166494230" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 23 Jan 2013 01:26:13 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0N1QDjX028062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 23 Jan 2013 01:26:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.32]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 22 Jan 2013 19:26:13 -0600 From: "Pascal Thubert (pthubert)" To: "rtgwg@ietf.org" Subject: FW: New Version Notification for draft-thubert-rtgwg-arc-vs-mrt-00.txt Thread-Topic: New Version Notification for draft-thubert-rtgwg-arc-vs-mrt-00.txt Thread-Index: Ac35CGQJ25zdjKvIRSe1dp9r8ExxSw== Date: Wed, 23 Jan 2013 01:26:12 +0000 Deferred-Delivery: Wed, 23 Jan 2013 01:25:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.212.137] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 01:26:14 -0000 SGk6DQoNClRoaXMgZHJhZnQgcmVzcG9uZHMgdG8gYSBzdWdnZXN0aW9uIGJ5IFN0ZXdhcnQgZHVy aW5nIHRoZSBSVEdXRyBtZWV0aW5nIGluIEF0bGFudGEuIFN0ZXdhcnQgc3VnZ2VzdGVkIHRoYXQg d2UgbGVhdmUgYSB3cml0dGVuIHJlY29yZCBvbiB0aGUgcHJlc2VudGF0aW9uIGNvbXBhcmluZyBB UkMgYW5kIE1SVC4NClNpbmNlIGJvdGggdGVjaG5pY2FsIHNvbHV0aW9ucyBhcmUgc3ViamVjdCB0 byBjaGFuZ2VzLCB0aGlzIHdvcmsgY2FuIG9ubHkgYmUgYSBzbmFwc2hvdCB0aGF0IHJlcHJlc2Vu dCB0aGUgYmVzdCB1bmRlcnN0YW5kaW5nLyBrbm93bGVkZ2Ugb2YgdGhlIGF1dGhvcnMgYXQgdGhh dCBwYXJ0aWN1bGFyIHRpbWUuDQoNCkl0IGlzIHVuY2xlYXIgdG8gdGhlIGF1dGhvciB3aGV0aGVy IHdlIHNob3VsZCBtYWludGFpbiB0aGlzIGRvY3VtZW50IG92ZXJ0aW1lIG9yIGp1c3QgY2xlYW4g aXQgdXAgYW5kIHB1Ymxpc2ggd2l0aCBwcm9wZXIgY2F1dGlvbiB3b3Jkcy4gDQoNCldoYXQgZG8g eW91IHRoaW5rPw0KDQpQYXNjYWwNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnXSANClNlbnQ6IGx1bmRpIDIxIGphbnZpZXIgMjAxMyAwMDoxMg0KVG86IFBhc2NhbCBUaHVi ZXJ0IChwdGh1YmVydCkNCkNjOiBzcmluaUBlY2UuYXJpem9uYS5lZHUNClN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdGh1YmVydC1ydGd3Zy1hcmMtdnMtbXJ0LTAw LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10aHViZXJ0LXJ0Z3dnLWFyYy12 cy1tcnQtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBhc2NhbCBU aHViZXJ0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBk cmFmdC10aHViZXJ0LXJ0Z3dnLWFyYy12cy1tcnQNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIEF2 YWlsYWJsZSBSb3V0aW5nIENvbnN0cnVjdHMNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTAxLTIxDQpX RyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTgNClVSTDog ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGh1 YmVydC1ydGd3Zy1hcmMtdnMtbXJ0LTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRodWJlcnQtcnRnd2ctYXJjLXZzLW1ydA0KSHRt bGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aHViZXJ0LXJ0 Z3dnLWFyYy12cy1tcnQtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZHJhZnQgY29tcGFyZXMg dGhlIGNhcGFiaWxpdGllcyBvZmZlcmVkIGJ5IHRoZSBBdmFpbGFibGUgUm91dGluZw0KICAgQ29u c3RydWN0IChBUkMpIGFuZCB0aGUgTWF4aW1hbGx5IFJlZHVuZGFudCBUcmVlcyAoTVJUKSB0ZWNo bmlxdWVzIGluDQogICBvcmRlciB0byBzdXBwb3J0IGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50cy4N Cg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0K From hannes@juniper.net Fri Jan 25 08:19:49 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F3A21F8795 for ; Fri, 25 Jan 2013 08:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMcm0yX19P0C for ; Fri, 25 Jan 2013 08:19:49 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1C721F8462 for ; Fri, 25 Jan 2013 08:19:46 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUQKwoo/5qohJHJlX1K3wCwTR0Fz2FZWi@postini.com; Fri, 25 Jan 2013 08:19:49 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 25 Jan 2013 08:16:37 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 25 Jan 2013 08:16:36 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.16) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 25 Jan 2013 08:19:03 -0800 Received: from mail9-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 25 Jan 2013 16:16:35 +0000 Received: from mail9-va3 (localhost [127.0.0.1]) by mail9-va3-R.bigfish.com (Postfix) with ESMTP id 5B21BE007E for ; Fri, 25 Jan 2013 16:16:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); (null); H:BLUPRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371I148cI1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1155h) Received: from mail9-va3 (localhost.localdomain [127.0.0.1]) by mail9-va3 (MessageSwitch) id 1359130593686387_30064; Fri, 25 Jan 2013 16:16:33 +0000 (UTC) Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.253]) by mail9-va3.bigfish.com (Postfix) with ESMTP id A25A32C0094; Fri, 25 Jan 2013 16:16:33 +0000 (UTC) Received: from BLUPRD0512HT003.namprd05.prod.outlook.com (132.245.1.149) by VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 25 Jan 2013 16:16:32 +0000 Received: from sa-nc-mfg-193.static.jnpr.net (66.129.224.36) by pod51010.outlook.com (10.255.215.164) with Microsoft SMTP Server (TLS) id 14.16.257.4; Fri, 25 Jan 2013 16:16:31 +0000 Subject: Re: IPR for draft-ietf-rtgwg-remote-lfa-00 ??? MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: Date: Fri, 25 Jan 2013 17:16:23 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: <1E824B0C-8A0F-4AB7-9005-4B11D9C29832@juniper.net> References: To: Alvaro Retana X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "rtgwg@ietf.org" , "rtgwg-chairs@tools.ietf.org" , "Stewart Bryant \(stbryant\)" 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, 25 Jan 2013 16:19:49 -0000 hi alvaro, i see now the disclosure when i use the IPR search function - e.g. = https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id_docum= ent_tag=3Ddraft-ietf-rtgwg-remote-lfa thanks for fixing this. what is still broken is the IPR column (=3Dempty) in the rtgwg master = page. http://datatracker.ietf.org/wg/rtgwg/ thanks, /hannes On Dec 19, 2012, at 6:29 PM, Alvaro Retana (aretana) wrote: > Just to close the loop.. This issue has been fixed and the IPR now = shows up. >=20 > Alvaro. >=20 > On 12/12/12 7:09 AM, "Stewart Bryant (stbryant)" = wrote: >=20 > There was a declaration against draft-shand-remote-lfa-0, > but the chairs did not set the replacement status correctly > when draft-ietf-rtgwg-remote-lfa-00 was published, so=20 > the new draft did not automatically inherit the existing > IPR disclosure. >=20 > Please can the chairs email the secretariat and request > that they correct the meta-data so that the WG draft draft=20 > picks up IPR disclosure 1770 in the tracker. From aretana@cisco.com Fri Jan 25 08:28:43 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397AE21F8441 for ; Fri, 25 Jan 2013 08:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGVTtE9qwLcf for ; Fri, 25 Jan 2013 08:28:42 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8A18E21F8436 for ; Fri, 25 Jan 2013 08:28:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1349; q=dns/txt; s=iport; t=1359131322; x=1360340922; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=q4usXQsfTXjtSf923iA9qdodzA+wRQc6DXQcxT+3uSc=; b=F7RaGp5NE7a1wsSe51Fk+mC6vAHyTq7CQAoBXafzdEg80zBcJShe56xw eVjjWrF0cd3tx/vsO1FBA9XgoNqa6Nyd8XzM7fE08WZUcRSKJfzb0sgZY s42W+HqljwuEae3ouJ2AO5DpkxCJ5QUGcVqx09s5PiqBi2HZMA/3ZE5QU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFWxAlGtJXHB/2dsb2JhbABEvlMWc4IeAQEBBDo/EgEIGAoUQiUCBA4FCIgHDL5FjHkLg1phA5cpjyyCd4FvNQ X-IronPort-AV: E=Sophos;i="4.84,539,1355097600"; d="scan'208";a="168152660" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 25 Jan 2013 16:28:42 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0PGSg5O013527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 16:28:42 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.174]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 10:28:41 -0600 From: "Alvaro Retana (aretana)" To: Hannes Gredler Subject: Re: IPR for draft-ietf-rtgwg-remote-lfa-00 ??? Thread-Topic: IPR for draft-ietf-rtgwg-remote-lfa-00 ??? Thread-Index: AQHN3g5dZzgwzUr1VEWYpTHsq/IIrJha1xuA//+vmgA= Date: Fri, 25 Jan 2013 16:28:40 +0000 Message-ID: In-Reply-To: <1E824B0C-8A0F-4AB7-9005-4B11D9C29832@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.237.65] Content-Type: text/plain; charset="us-ascii" Content-ID: <8D0405D3B1A1F64EB65B717B7BCD5B5B@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg@ietf.org" , "rtgwg-chairs@tools.ietf.org" , "Stewart Bryant \(stbryant\)" 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, 25 Jan 2013 16:28:43 -0000 Hmm..I see. Let me look into it. The drafts are linked (as in one replaced the other), but the "forwarding" of the IPR seems not to have worked. Thanks! Alvaro. On 1/25/13 11:16 AM, "Hannes Gredler" wrote: >hi alvaro, > >i see now the disclosure when i use the IPR search function - e.g. >https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id_docum= en >t_tag=3Ddraft-ietf-rtgwg-remote-lfa >thanks for fixing this. > >what is still broken is the IPR column (=3Dempty) in the rtgwg master page= . > >http://datatracker.ietf.org/wg/rtgwg/ > >thanks, > >/hannes > >On Dec 19, 2012, at 6:29 PM, Alvaro Retana (aretana) wrote: > >> Just to close the loop.. This issue has been fixed and the IPR now >>shows up. >>=20 >> Alvaro. >>=20 >> On 12/12/12 7:09 AM, "Stewart Bryant (stbryant)" >>wrote: >>=20 >> There was a declaration against draft-shand-remote-lfa-0, >> but the chairs did not set the replacement status correctly >> when draft-ietf-rtgwg-remote-lfa-00 was published, so >> the new draft did not automatically inherit the existing >> IPR disclosure. >>=20 >> Please can the chairs email the secretariat and request >> that they correct the meta-data so that the WG draft draft >> picks up IPR disclosure 1770 in the tracker. > > From stbryant@cisco.com Fri Jan 25 09:58:20 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D6121F845E for ; Fri, 25 Jan 2013 09:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.582 X-Spam-Level: X-Spam-Status: No, score=-110.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 Bf4M5hfgecom for ; Fri, 25 Jan 2013 09:58:20 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 07DB921F8200 for ; Fri, 25 Jan 2013 09:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1382; q=dns/txt; s=iport; t=1359136700; x=1360346300; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=yb0svF4MhO46Wm5RKMhVZLZyK5iYXBfDDj+xJXVtd7M=; b=FBRm41C9A/AcecA7cX/4+l5IZRNAr22mlKzoatkSzTCnT7uGSZStNUUu 6FfDDw14q4pDZlzmKfm9p9VpIVcldAnj8nfWmXgZZfbMYjVIO5tr1w2lE /sIZNDG+T+0Wm6lRbjc22q7YiiEFotabpOCMh+fJJfCtEbd93MCI/HJjo I=; X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208";a="149784754" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 25 Jan 2013 17:58:17 +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 r0PHwHQZ020128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jan 2013 17:58:17 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r0PHwGf3018464; Fri, 25 Jan 2013 17:58:16 GMT Message-ID: <5102C7B8.5050506@cisco.com> Date: Fri, 25 Jan 2013 17:58:16 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Hannes Gredler Subject: Re: IPR for draft-ietf-rtgwg-remote-lfa-00 ??? References: <1E824B0C-8A0F-4AB7-9005-4B11D9C29832@juniper.net> In-Reply-To: <1E824B0C-8A0F-4AB7-9005-4B11D9C29832@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtgwg-chairs@tools.ietf.org" , "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: Fri, 25 Jan 2013 17:58:20 -0000 Looks OK here - does one of us have a caching problem? Can you provide the exact path that fails so we can get it fixed. Stewart On 25/01/2013 16:16, Hannes Gredler wrote: > hi alvaro, > > i see now the disclosure when i use the IPR search function - e.g. > https://datatracker.ietf.org/ipr/search/?option=document_search&id_document_tag=draft-ietf-rtgwg-remote-lfa > thanks for fixing this. > > what is still broken is the IPR column (=empty) in the rtgwg master page. > > http://datatracker.ietf.org/wg/rtgwg/ > > thanks, > > /hannes > > On Dec 19, 2012, at 6:29 PM, Alvaro Retana (aretana) wrote: > >> Just to close the loop.. This issue has been fixed and the IPR now shows up. >> >> Alvaro. >> >> On 12/12/12 7:09 AM, "Stewart Bryant (stbryant)" wrote: >> >> There was a declaration against draft-shand-remote-lfa-0, >> but the chairs did not set the replacement status correctly >> when draft-ietf-rtgwg-remote-lfa-00 was published, so >> the new draft did not automatically inherit the existing >> IPR disclosure. >> >> Please can the chairs email the secretariat and request >> that they correct the meta-data so that the WG draft draft >> picks up IPR disclosure 1770 in the tracker. > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From aretana@cisco.com Fri Jan 25 10:21:47 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B572B21F8432 for ; Fri, 25 Jan 2013 10:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnvcQ0ljWvmL for ; Fri, 25 Jan 2013 10:21:47 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0C96C21F844F for ; Fri, 25 Jan 2013 10:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=797; q=dns/txt; s=iport; t=1359138107; x=1360347707; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PhiAQY/uIsrXHHYCa4ixRh9jgrsVrIlXvzVVFWjTkgg=; b=KWQ3FIrTkzXrDS4RTC9ewYMmcva2Bjg84VGioscexgbi1FhVInmRkubI VSCVcxd6r7nztU5nnuy6CF1wVfluwa+LIwgKN/rcUpsFYYVRVcaLRjnQ5 KKk/hleVLTO7+9XqHOIFiQWWeZQ0hmxqyI0Stsb/j90KI6PtvdTLuAgkf s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFALLMAlGtJXHA/2dsb2JhbABFhX+4VBZzgiABBDo/EgEIIhRCJQIEAQ0FCIgHDL5akF5hA5cpjyyCd4Ik X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208";a="168214287" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 25 Jan 2013 18:21:46 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0PILjQh010647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 18:21:45 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.174]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 12:21:45 -0600 From: "Alvaro Retana (aretana)" To: "Stewart Bryant (stbryant)" , Hannes Gredler Subject: Re: IPR for draft-ietf-rtgwg-remote-lfa-00 ??? Thread-Topic: IPR for draft-ietf-rtgwg-remote-lfa-00 ??? Thread-Index: AQHN3g5dZzgwzUr1VEWYpTHsq/IIrJha1xuAgAAcdwD//7K7gA== Date: Fri, 25 Jan 2013 18:21:45 +0000 Message-ID: In-Reply-To: <5102C7B8.5050506@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.237.65] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg-chairs@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: Fri, 25 Jan 2013 18:21:47 -0000 On 1/25/13 12:58 PM, "Stewart Bryant (stbryant)" wrote: >Looks OK here - does one of us have a caching problem? > >Can you provide the exact path that fails so we can get it fixed. Stewart: I see it wrong too. 1. https://datatracker.ietf.org/wg/rtgwg/ Doesn't show anything in the IPR column. 2. http://tools.ietf.org/html/draft-ietf-rtgwg-remote-lfa-01 Doesn't have an IPR option at the top (as does http://tools.ietf.org/html/draft-shand-remote-lfa-01) 3.=20 https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id_docume= nt _tag=3Ddraft-ietf-rtgwg-remote-lfa Does show that there is IPR on a "related" document.. I can follow up with the Secretariat, but let me know if you are so we don't duplicate. Thanks! Alvaro. From rcallon@juniper.net Mon Jan 28 11:50:06 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF7F21F8786; Mon, 28 Jan 2013 11:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.166 X-Spam-Level: X-Spam-Status: No, score=-101.166 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_STOP=2.3, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, 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 272DZcTkvojD; Mon, 28 Jan 2013 11:50:02 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8199E21F8609; Mon, 28 Jan 2013 11:50:00 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUQbWaAm+IjCwOmsd33bgGCxP1oyrySpc@postini.com; Mon, 28 Jan 2013 11:50:00 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 28 Jan 2013 11:49:46 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 28 Jan 2013 11:49:46 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.31) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 28 Jan 2013 11:58:42 -0800 Received: from mail177-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Mon, 28 Jan 2013 19:49:45 +0000 Received: from mail177-va3 (localhost [127.0.0.1]) by mail177-va3-R.bigfish.com (Postfix) with ESMTP id ED6812C02A5; Mon, 28 Jan 2013 19:49:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -21 X-BigFish: PS-21(zzd6eahc85fh1418Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh18c673hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail177-va3 (localhost.localdomain [127.0.0.1]) by mail177-va3 (MessageSwitch) id 1359402554583527_23746; Mon, 28 Jan 2013 19:49:14 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.243]) by mail177-va3.bigfish.com (Postfix) with ESMTP id 7DE1C2A038B; Mon, 28 Jan 2013 19:49:14 +0000 (UTC) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 28 Jan 2013 19:49:11 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.95]) by CH1PRD0510HT002.namprd05.prod.outlook.com ([10.255.150.37]) with mapi id 14.16.0263.000; Mon, 28 Jan 2013 19:49:11 +0000 From: Ross Callon To: "rtg-ads@tools.ietf.org" , "stbryant@cisco.com" , "sprevidi@cisco.com" , "imc.shand@googlemail.com" Subject: RtgDir review: draft-ietf-rtgwg-ipfrr-notvia-addresses-10 Thread-Topic: RtgDir review: draft-ietf-rtgwg-ipfrr-notvia-addresses-10 Thread-Index: Ac39kIjuJs7ZF2k9QSqE3UIX51Y07g== Date: Mon, 28 Jan 2013 19:49:10 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD309A77BCC@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_62CCD4C52ACDAD4481149BD5D8A72FD309A77BCCCH1PRD0510MB355_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GOOGLEMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Ross Callon , "rtg-dir@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: Mon, 28 Jan 2013 19:50:06 -0000 --_000_62CCD4C52ACDAD4481149BD5D8A72FD309A77BCCCH1PRD0510MB355_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-rtgwg-ipfrr-notvia-addresses-10 Reviewer: Ross Callon Review Date: January 28, 2013 IETF LC End Date: January 31, 2013 Intended Status: informational Summary: This document is basically ready for publication, but has nits th= at should be considered prior to publication. Comments: Generally this document is very well written and is very readable. I have o= nly very minor comments that I think that you should consider prior to publ= ication. Major Issues: No major issues found. Minor Issues: The first paragraph of 3.2 is a bit imprecise. It says that there are advan= tages of using not-via in combination with LFA, but then two of the three a= dvantages cited don't actually apply to the combination, but only to using = LFA without not-via (which of course has the disadvantage of not offering c= omplete coverage, as is discussed in the next paragraph). Up until section 4.1, the document pretty much reads as if we are talking a= bout node protection. 4.1 then just sort of forgets (or generalizes) this a= nd jumps into options for both node protection and link protection. I think= that it is appropriate for section 3 to read the way that it currently doe= s, since it is an overview and does a good job of introducing the technique= without confusing the reader with complexities (which are appropriately co= vered later in the document). To me this implies that somewhere in section = 4, prior to the current section 4.1, you might want a brief discussion of n= ode protection versus link protection. You might consider adding something = like: In general it may be difficult for a router to quickly distinguish betwee= n link failure and node failure. For example in figure 1 node S might see the link to node P suddenly totally fail. In general it is impossible to immediately determine whether node P has failed or if the link from S to = P has failed (in some cases link layer indications might give information regarding what is going on, and the updates to link state packets from node P or from all neighbors of node P will eventually clarify what has failed once received and processed). For this reason it is generally safer to assume that node P has failed and where possible reroute traffic to the next node downstream from P. However, there may be cases where this is impossible. For example some destinations might be only reachable via node P, and in some topologies the failure of node P may partition the network. For this reason we need to consider both node and link failures. Returning to section 4.1, I think that it would be a bit clearer if the las= t sentence of the first paragraph were its own paragraph. This would cause = 4.1 to start with a general discussion, then have a paragraph about link pr= otection, then have a paragraph about node protection. The last sentence of section 4.1 is imprecise. It currently states: "In the= case of link protection this simply means that the advertisement from P to= S is suppressed, with the result that S and all other nodes compute a rout= e to Ps which doesn't traverse S, as required". However, this does not actu= ally compute a route that is guaranteed to not traverse node S, it computes= a route that does not traverse the link from S to P. The sentence should r= ead: "In the case of link protection this simply means that the advertiseme= nt from P to S is suppressed, with the result that S and all other nodes co= mpute a route to Ps which doesn't traverse the link from S to P, as require= d". Section 5.1, second paragraph: "ANY failure" should be "ANY single failure"= . Section 6.1: At first glance it seemed somewhat drastic to have a MUST assu= me that all other links of the SRLG have failed. After reading the entire s= ection and thinking about this for a while, I have come to the conclusion t= hat you are correct. However, I am wondering whether just a bit more explan= ation might be useful. I am therefore wondering about additional explanatio= n so that the first paragraph of section 6.1 might read: A Shared Risk Link Group (SRLG) is a set of links whose failure can be caused by a single action such as a conduit cut or line card failure. When repairing the failure of a link that is a member of an SRLG, it is not immediately known whether the entire group has failed or only that link. In order to avoid multiple problems as explained below, it MUST be assumed that all the other links that are also members of the SRLG have also failed. Consequently, any repair path MUST be computed to avoid not just the adjacent link, but also all the links which are members of the same SRLG. Nit: At first glance section 3.1 seems a bit terse. I am undecided whether it wo= uld be worthwhile to add a bit more explanation. The current text is clear = enough to one well versed in the various routing technologies and what I ha= ve been able to think of as possible additional text seems almost too obvio= us. As an example the first paragraph could be added to, to read: A router can use an equal cost multi-path (ECMP) repair in place of a not-via repair. For example, if a router has multiple equal cost next ho= ps to a particular destination, and the link to one fails, it just forwards= all traffic to the other equal cost next hop(s) without using not-via. Similarly the second paragraph could be added to, to read: A router computing a not-via repair path MAY subject the repair to ECMP. For example in figure 1 there may be multiple equal cost paths from S to Bp, each of which avoids node P. Since not-via encapsulates a packet to Bp, equal cost multipath will work in the normal way for computing and using paths from S to Bp. Again these updates almost seem too trivial, so I have included this sugges= tion under "nits" and will leave it to the discretion of the authors whethe= r they want to make any changes. --_000_62CCD4C52ACDAD4481149BD5D8A72FD309A77BCCCH1PRD0510MB355_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
I have been selected as the Routing Directorate reviewer for this draf= t. The Routing Directorate seeks to review all routing or routing-related d= rafts as they pass through IETF last call and IESG review, and sometimes on= special request. The purpose of the review is to provide assistance to the Routing ADs. For more informatio= n about the Routing Directorate, please see http://www.ie= tf.org/iesg/directorate/routing.html
 
Although these comments are primarily for the use of the Routing ADs, = it would be helpful if you could consider them along with any other IETF La= st Call comments that you receive, and strive to resolve them through discu= ssion or by updating the draft.
 
Document: draft-ietf-rtgwg-ipfrr-notvia-addresses-10
Reviewer: Ross Callon
Review Date: January 28, 2013
IETF LC End Date: January 31, 2013
Intended Status: informational 
 
Summary:  This document is basically ready for publication, but h= as nits that should be considered prior to publication.
 
Comments:
 
Generally this document is very well written and is very readable. I h= ave only very minor comments that I think that you should consider prior to= publication.
 
Major Issues:  No major issues found.
 
Minor Issues:
 
The first paragraph of 3.2 is a bit imprecise. It says that there are = advantages of using not-via in combination with LFA, but then two of the th= ree advantages cited don’t actually apply to the combination, but onl= y to using LFA without not-via (which of course has the disadvantage of not offering complete coverage, as is dis= cussed in the next paragraph).
 
Up until section 4.1, the document pretty much reads as if we are talk= ing about node protection. 4.1 then just sort of forgets (or generalizes) t= his and jumps into options for both node protection and link protection. I = think that it is appropriate for section 3 to read the way that it currently does, since it is an overview a= nd does a good job of introducing the technique without confusing the reade= r with complexities (which are appropriately covered later in the document)= . To me this implies that somewhere in section 4, prior to the current section 4.1, you might want a brief disc= ussion of node protection versus link protection. You might consider adding= something like:
 
  In general it may be difficult for a router to quickly distingu= ish between
  link failure and node failure. For example in figure 1 node S m= ight see
  the link to node P suddenly totally fail. In general it is impo= ssible to
  immediately determine whether node P has failed or if the link = from S to P
  has failed (in some cases link layer indications might give inf= ormation
  regarding what is going on, and the updates to link state packe= ts from
  node P or from all neighbors of node P will eventually clarify = what has
  failed once received and processed). For this reason it is gene= rally
  safer to assume that node P has failed and where possible rerou= te
  traffic to the next node downstream from P. However, there may = be cases
  where this is impossible. For example some destinations might b= e only
  reachable via node P, and in some topologies the failure of nod= e P may
  partition the network. For this reason we need to consider both= node and
  link failures.
 
Returning to section 4.1, I think that it would be a bit clearer if th= e last sentence of the first paragraph were its own paragraph. This would c= ause 4.1 to start with a general discussion, then have a paragraph about li= nk protection, then have a paragraph about node protection.
 
The last sentence of section 4.1 is imprecise. It currently states: &#= 8220;In the case of link protection this simply means that the advertisemen= t from P to S is suppressed, with the result that S and all other nodes com= pute a route to Ps which doesn't traverse S, as required”. However, this does not actually compute a route that= is guaranteed to not traverse node S, it computes a route that does not tr= averse the link from S to P. The sentence should read: “In the case o= f link protection this simply means that the advertisement from P to S is suppressed, with the result that S and all oth= er nodes compute a route to Ps which doesn't traverse the link from S to P,= as required”.
 
Section 5.1, second paragraph: “ANY failure” should be = 220;ANY single failure”.
 
Section 6.1: At first glance it seemed somewhat drastic to have a MUST= assume that all other links of the SRLG have failed. After reading the ent= ire section and thinking about this for a while, I have come to the conclus= ion that you are correct. However, I am wondering whether just a bit more explanation might be useful. I am th= erefore wondering about additional explanation so that the first paragraph = of section 6.1 might read:
 
   A Shared Risk Link Group (SRLG) is a set of links whose f= ailure can
   be caused by a single action such as a conduit cut or lin= e card
   failure.  When repairing the failure of a link that = is a member of an
   SRLG, it is not immediately known whether the entire grou= p has failed
   or only that link. In order to avoid multiple problems as= explained
   below, it MUST be assumed that all the other links that a= re also
   members of the SRLG have also failed.  Consequently,= any repair path
   MUST be computed to avoid not just the adjacent link, but= also all
   the links which are members of the same SRLG.
 
Nit:
 
At first glance section 3.1 seems a bit terse. I am undecided whether = it would be worthwhile to add a bit more explanation. The current text is c= lear enough to one well versed in the various routing technologies and what= I have been able to think of as possible additional text seems almost too obvious. As an example the first = paragraph could be added to, to read:
 
   A router can use an equal cost multi-path (ECMP) repair i= n place of a
   not-via repair. For example, if a router has multiple equ= al cost next hops
   to a particular destination, and the link to one fails, i= t just forwards all
   traffic to the other equal cost next hop(s) without using= not-via.
 
Similarly the second paragraph could be added to, to read:
 
   A router computing a not-via repair path MAY subject the = repair to
   ECMP. For example in figure 1 there may be multiple equal= cost paths
   from S to Bp, each of which avoids node P. Since not-via = encapsulates
   a packet to Bp, equal cost multipath will work in the nor= mal way for
   computing and using paths from S to Bp.
 
Again these updates almost seem too trivial, so I have included this s= uggestion under “nits” and will leave it to the discretion of t= he authors whether they want to make any changes.
 
 --_000_62CCD4C52ACDAD4481149BD5D8A72FD309A77BCCCH1PRD0510MB355_-- From acee.lindem@ericsson.com Wed Jan 30 10:34:04 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD3821F886C; Wed, 30 Jan 2013 10:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbTBgUhSxYIV; Wed, 30 Jan 2013 10:34:03 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 30D8B21F888E; Wed, 30 Jan 2013 10:34:02 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-77-51096792fac4 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BB.5A.31450.29769015; Wed, 30 Jan 2013 19:33:55 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.004; Wed, 30 Jan 2013 13:33:54 -0500 From: Acee Lindem To: Stewart Bryant , "Stefano Previdi (sprevidi)" , "Mike Shand (mshand)" , "Pierre Francois" , Clarence FilsFils , Olivier Bonaventure Subject: Routing Directorate Review of "Framework for Loop-free convergence using oFIB" Thread-Topic: Routing Directorate Review of "Framework for Loop-free convergence using oFIB" Thread-Index: AQHN/xhbkBCAkpY70028Ms+8Xewwcg== Date: Wed, 30 Jan 2013 18:33:54 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470B5BF8@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE470B5BF8eusaamb101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLonSndyOmegQWsTt8XO2T1sFs+/XmC2 uNHwg8Xizbs/bBYL1jxlt7jw5jezxfrdj5gszj2dw+jA4THl90ZWjyVLfjJ5fF97jdnj1bHv LAEsUVw2Kak5mWWpRfp2CVwZt1ZMYy/YU1bx++pMxgbGowldjBwcEgImEn96RboYOYFMMYkL 99azdTFycQgJHGGU+DlrKTOEs5xR4sO/h8wgVWwCOhLPH/0DS4gIzGSS+DZ5KgtIglnAR+Jd 4092EFtYIEpi0YVjbCC2iEC8xLflW5kgbD2JX38vgA1iEVCV+LFgDyOIzSvgLdG/5i1YnBHo jO+n1jBBzBSXuPVkPhPEeQISS/acZ4awRSVePv7HCmErSyx5sh/qhnyJC78hDuUVEJQ4OfMJ ywRG4VlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx5D9VpL3P75mQVZzQJGjlWMHKXF qWW56UYGmxiB8XhMgk13B+Oel5aHGKU5WJTEeYNcLwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi 4JRqYAxcuOHjq4zN+44s8L3988iyxRIxTmqL9DdfTJ3u42yX8//4rtAnnhZBPq9OxRrNOBLA 0sa0OSj/+mUl3f9asX0svKV/3I7U9P/gWr/SuVry36V056dPkytObOWNUfz6YaFBS+v6SbZd hsY8azxduCvtb5W5+MbP8SzaULHc7PiK5yyPZp+XZ1diKc5INNRiLipOBADSh+6VlQIAAA== Cc: "rtg-dir@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: Wed, 30 Jan 2013 18:34:04 -0000 --_000_94A203EA12AECE4BA92D42DBFFE0AE470B5BF8eusaamb101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, et al, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-rtgwg-ipfrr-ordered-fib-08 Reviewer: Acee Lindem Review Date: January 30, 2013 IETF LC End Date: January 31, 2013 Intended Status: informational Summary: This document is basically ready for publication, but has clarifi= cation that should be considered prior to publication. Comments: The document accomplishes what it sets out to achieve in document= ing the ordered FIB mechanism for avoidance of transient loops. While Appen= dix B is useful, I think the document would be better without Appendix A. O= f course, this is just my opinion. Major Issues: None Minor Issues: 1. The document could benefit for a precise defi= nition of a "non-urgent topology change". From what I gathered, this is any= change that can be deferred during the ordered FIB delay. 2. Similarly, the document could benefit from a = precise definition of the "rSPF". I checked RFC 5715 and it is not defined = there either. I believe our discussions indicate that this is simply an SPF= where the shortest path back to us is used as the cost. For example, for t= he first pass, the SPF would use our neighbor's link cost rather than our o= wn. 3. It would be good to state early on that the c= urrent oFIB mechanism is limited to a single link or node failure and that = multiple unrelated failures result in reversion to normal FIB convergence. 4. Make sure the hold down timer is defined prec= isely and early in the document. Currently, this doesn't happen until secti= on 8.2. 5. Upon the initial reading, one may think there= is some correspondence between the Router (R) in sections 4 and the Router= (R) in section 5. Can this be clearer? Perhaps, (R) is not needed in secti= on 4 since in all other sections, it refers to the computing router. 6. In section 5, I have trouble envisioning a ca= se where a router would not be in an pre or post failure SPT. I guess if it= had no loopbacks and only unnumbered interfaces or only interfaces to broa= dcast links offering a longer path??? 7. In section 6.2, it would be instructive to sa= y that a Link Down condition is represented by an infinite metric (or other= wise cover this condition). 8. In section 8.5, I believe this a different ho= ld down timer than the one used to group LSPs related to the same failure. Nits: 1. Abstract - replace "However mechanism" with "Howeve= r the mechanism". I chose singular since it is singular in the preceding te= xt. 2. Introduction - replace "base (FIB)" with "bases (FI= Bs)" in the first sentence. 3. Page 5, replace "change order no" with "change orde= r, no". 4. Page 9, suggest adding "IGP " to "reverse connectiv= ity check". 5. Page 10, suggest using parenthesis rather than rely= ing on arithmetic precedence for equations, e.g., T0 + H + (rank * MAX_FIB) 6. There is a mixture of "neighbor" and "neighbour" in= the document. Of course, I prefer the US English to UK English since this = is what all the OSPF RFCs use. 7. Section 8.1, the actions are formatting inconsisten= tly. In one case, as a paragraph and the other as a list. 8. Page 19, replace "algorithms i.e." with "algorithms= , i.e.". 9. Page 19 and Page 22, use of (PNSM) and (PN) is inco= nsistent. 10. Page 23, Run-on sentence beginning "Manual configurat= ion...". 11. There some instances where the opening clause for a s= entence is preceded with a comma and some where it is not. I prefer the for= mer. For example, section 4.2 appears to be written in a different style wi= th missing punctuation. Thanks, Acee --_000_94A203EA12AECE4BA92D42DBFFE0AE470B5BF8eusaamb101ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <923B7C27A8F7824F95E62CA87FF8D8E7@ericsson.com> Content-Transfer-Encoding: quoted-printable
Authors, et al,
 
I have been selected= as the Routing Directorate reviewer for this draft. The Routing Directorat= e seeks to review all routing or routing-related drafts as they pass throug= h IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing Direc= torate, please see http://www.ietf.org/iesg/directorate/routing.html
 
Although these comme= nts are primarily for the use of the Routing ADs, it would be helpful if yo= u could consider them along with any other IETF Last Call comments that you= receive, and strive to resolve them through discussion or by updating the draft.
 
Document: draft-ietf= -rtgwg-ipfrr-ordered-fib-08
Reviewer: Acee Linde= m
Review Date: January= 30, 2013
IETF LC End Date: Ja= nuary 31, 2013
Intended Status: inf= ormational 
 
Summary:  This = document is basically ready for publication, but has clarification that sho= uld be considered prior to publication.
 
Comments: The docume= nt accomplishes what it sets out to achieve in documenting the ordered FIB = mechanism for avoidance of transient loops. While Appendix B is useful, I t= hink the document would be better without Appendix A. Of course, this is just my opinion. 

Major Issues: None&n= bsp;

Minor Issues:  =                     = ;   
     =                     &nbs= p;1. The document could benefit for a precise definition of a "non-urg= ent topology change". From what I gathered, this is any change that ca= n be deferred during the ordered FIB delay. 
     =                     &nbs= p;2. Similarly, the document could benefit from a precise definition of the= "rSPF". I checked RFC 5715 and it is not defined there either. I= believe our discussions indicate that this is simply an SPF where the shortest path back to us is used as the co= st. For example, for the first pass, the SPF would use our neighbor's link = cost rather than our own. 
     =                     &nbs= p;3. It would be good to state early on that the current oFIB mechanism is = limited to a single link or node failure and that multiple unrelated failur= es result in reversion to normal FIB convergence. 
     =                     &nbs= p;4. Make sure the hold down timer is defined precisely and early in the do= cument. Currently, this doesn't happen until section 8.2. 
     =                     &nbs= p;5. Upon the initial reading, one may think there is some correspondence b= etween the Router (R) in sections 4 and the Router (R) in section 5. Can th= is be clearer? Perhaps, (R) is not needed in section 4 since in all other sections, it refers to the comp= uting router. 
     =                     &nbs= p;6. In section 5, I have trouble envisioning a case where a router would n= ot be in an pre or post failure SPT. I guess if it had no loopbacks and onl= y unnumbered interfaces or only interfaces to broadcast links offering a longer path??? 
     =                     &nbs= p;7. In section 6.2, it would be instructive to say that a Link Down condit= ion is represented by an infinite metric (or otherwise cover this condition= ). 
     =                     &nbs= p;8. In section 8.5, I believe this a different hold down timer than the on= e used to group LSPs related to the same failure. 

Nits: 

     =                1. Abstract - repla= ce "However mechanism" with "However the mechanism". I = chose singular since it is singular in the preceding text. 
     =                2. Introduction - r= eplace "base (FIB)" with "bases (FIBs)" in the first se= ntence. 
     =                3. Page 5, replace = "change order no" with "change order, no". 
     =                4. Page 9, suggest = adding "IGP " to "reverse connectivity check". 
     =                5. Page 10, suggest= using parenthesis rather than relying on arithmetic precedence for equatio= ns, e.g., T0 + H + (rank * MAX_FIB) 
     =                6. There is a mixtu= re of "neighbor" and "neighbour" in the document. Of co= urse, I prefer the US English to UK English since this is what all the OSPF= RFCs use. 
     =                7. Section 8.1, the= actions are formatting inconsistently. In one case, as a paragraph and the= other as a list.  
     =                8. Page 19, replace= "algorithms i.e." with "algorithms, i.e.". 
     =                9. Page 19 and Page= 22, use of (PNSM) and (PN) is inconsistent. 
     =             10. Page 23, Run-on sentence beg= inning "Manual configuration...". 
     =             11. There some instances where t= he opening clause for a sentence is preceded with a comma and some where it= is not. I prefer the former. For example, section 4.2 appears to be writte= n in a different style with missing punctuation. 


Thanks,
Acee 



 
 

--_000_94A203EA12AECE4BA92D42DBFFE0AE470B5BF8eusaamb101ericsso_-- From stbryant@cisco.com Thu Jan 31 11:47:53 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7336421F8860; Thu, 31 Jan 2013 11:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.512 X-Spam-Level: X-Spam-Status: No, score=-110.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 TWp4s9Im20Dl; Thu, 31 Jan 2013 11:47:52 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB0021F885C; Thu, 31 Jan 2013 11:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7611; q=dns/txt; s=iport; t=1359661671; x=1360871271; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZWmqj7GpHk6EL7Xbc3QH/0dTv6xUktE+eagiGhTqpWk=; b=Y+PBt4mgPkBsJEVh5hQ5cKGWRR3/hcilvLhE8W3T5MwjkNnLW2ZmULx8 W6wKTo+wFyyzez02M6s2EPD0mytquD01GKuHIanHPfzmI3M4DmZxhkW3q Jbzz9CI7FX+6D1jw+HUXZmrgmEgBoFwqLaA7dStEZJDGZi0G5a/RFjxqd Y=; X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="80156022" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 31 Jan 2013 19:47:50 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0VJloFV032226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2013 19:47:50 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r0VJlnhg023558; Thu, 31 Jan 2013 19:47:49 GMT Message-ID: <510ACA65.9010307@cisco.com> Date: Thu, 31 Jan 2013 19:47:49 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Acee Lindem Subject: Re: Routing Directorate Review of "Framework for Loop-free convergence using oFIB" References: <94A203EA12AECE4BA92D42DBFFE0AE470B5BF8@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470B5BF8@eusaamb101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtg-dir@ietf.org" , Olivier Bonaventure , "Stefano Previdi \(sprevidi\)" , "rtgwg@ietf.org" , "Mike Shand \(mshand\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 19:47:53 -0000 On 30/01/2013 18:33, Acee Lindem wrote: > Authors, et al, > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review is > to provide assistance to the Routing ADs. For more information about > the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > Although these comments are primarily for the use of the Routing ADs, > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft. > Document: draft-ietf-rtgwg-ipfrr-ordered-fib-08 > Reviewer: Acee Lindem > Review Date: January 30, 2013 > IETF LC End Date: January 31, 2013 > Intended Status: informational > Summary: This document is basically ready for publication, but has > clarification that should be considered prior to publication. > Comments: The document accomplishes what it sets out to achieve in > documenting the ordered FIB mechanism for avoidance of transient > loops. While Appendix B is useful, I think the document would be > better without Appendix A. Of course, this is just my opinion. AAH took a lot of thought, so we would rather not loose it, if it works better I could reverse the order of the appendixes. > > Major Issues: None > > Minor Issues: > 1. The document could benefit for a precise definition of > a "non-urgent topology change". From what I gathered, this is any > change that can be deferred during the ordered FIB delay. The abstract now says "This mechanism can be used in the case of non-urgent (management action) link or node shutdowns and restarts or link metric changes." 3.1.1 says "First consider the non-urgent failure of a link (i.e. where an operator or a network management system (NMS) shuts down a link thereby removing it from the currently active topology) or the increase of a link metric by the operator or NMS ." The point is of course that although a link is shut down rather than failing, a remote node cannot distinguish the two cases. > 2. Similarly, the document could benefit from a precise > definition of the "rSPF". I checked RFC 5715 and it is not defined > there either. I believe our discussions indicate that this is simply > an SPF where the shortest path back to us is used as the cost. For > example, for the first pass, the SPF would use our neighbor's link > cost rather than our own. We use rSPT in here. As you know we are looking for a formal definition. I have put in Section 5 This computation required the introduction of the concept of a reverse Shortest Path Tree (rSPT). The rSPT uses the cost towards the root rather than from it and yields the best paths towards the root from other nodes in the network [I-D.draft-bryant-ipfrr-tunnels]. If there is a better ref we can swap in Auth48. > 3. It would be good to state early on that the current > oFIB mechanism is limited to a single link or node failure and that > multiple unrelated failures result in reversion to normal FIB > convergence. Done (in section 2). > 4. Make sure the hold down timer is defined precisely and > early in the document. Currently, this doesn't happen until section 8.2. On first use it says: If all events received within some hold-down period (the time that a router waits to acquire a set of LSPs which should be processed together) h > 5. Upon the initial reading, one may think there is some > correspondence between the Router (R) in sections 4 and the Router (R) > in section 5. Can this be clearer? Perhaps, (R) is not needed in > section 4 since in all other sections, it refers to the computing router. R is now removed. As has been described, a single event such as the failure or restoration of a single link, single router or a linecard may be notified to the rest of the network as a set of individual link change events. It is necessary to deduce from this collection of link state notifications the type of event that has occurred in the network and hence the required ordering. When a link change event is received which impacts the receiving router's FIB, the routers at the near and far end of the link are noted. If all events received within some hold-down period (the time that a router waits to acquire a set of LSPs which should be processed together) have a single router in common, then it is assumed that the change reflects an event (line-card or router change) concerning that router. In the case of a link change event, the router at the far end of the link is deemed to be the common router. All ordering computations are based on treating the common router as the root for both link and node events. > 6. In section 5, I have trouble envisioning a case where > a router would not be in an pre or post failure SPT. I guess if it had > no loopbacks and only unnumbered interfaces or only interfaces to > broadcast links offering a longer path??? This is the case where you have an unused link (due to costs), i.e. a link not on any shortest path. > 7. In section 6.2, it would be instructive to say that a > Link Down condition is represented by an infinite metric (or otherwise > cover this condition). I have added "Inclusion or removal of link" to the information list. > 8. In section 8.5, I believe this a different hold down > timer than the one used to group LSPs related to the same failure. Yes. I have changes this to AAH_Hold_down_timer expires Pierre and Mike please check this. > > Nits: > > 1. Abstract - replace "However mechanism" with "However the > mechanism". I chose singular since it is singular in the preceding text. done > 2. Introduction - replace "base (FIB)" with "bases (FIBs)" in > the first sentence. Done > 3. Page 5, replace "change order no" with "change order, no". Done > 4. Page 9, suggest adding "IGP " to "reverse connectivity check". Done > 5. Page 10, suggest using parenthesis rather than relying on > arithmetic precedence for equations, e.g., T0 + H + (rank * MAX_FIB) Done > 6. There is a mixture of "neighbor" and "neighbour" in the > document. Of course, I prefer the US English to UK English since this > is what all the OSPF RFCs use. I will deal - but given we are Europeans... :) > 7. Section 8.1, the actions are formatting inconsistently. In > one case, as a paragraph and the other as a list. Done 8. Page 19, replace "algorithms i.e." with "algorithms, i.e.". Done > 9. Page 19 and Page 22, use of (PNSM) and (PN) is inconsistent. Done > 10. Page 23, Run-on sentence beginning "Manual configuration...". Done > 11. There some instances where the opening clause for a sentence > is preceded with a comma and some where it is not. I prefer the > former. For example, section 4.2 appears to be written in a different > style with missing punctuation. > > I think I got them, but RFC Editor will get this Thanks for the review Stewart > Thanks, > Acee > > > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From internet-drafts@ietf.org Thu Jan 31 12:04:49 2013 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD00721F869F; Thu, 31 Jan 2013 12:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 jDXW-+qNFgPX; Thu, 31 Jan 2013 12:04:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBFC21F863F; Thu, 31 Jan 2013 12:04:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-ordered-fib-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130131200449.5227.97666.idtracker@ietfa.amsl.com> Date: Thu, 31 Jan 2013 12:04:49 -0800 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 20:04:50 -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 : Framework for 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-09.txt Pages : 27 Date : 2013-01-31 Abstract: This document describes the framework of 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 (management action) 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. However the mechanism described in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment. 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-ordered-fib-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/