From exim@www1.ietf.org Mon May 3 15:38:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24647 for ; Mon, 3 May 2004 15:38:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjCI-0006SY-DK for rtgwg-archive@odin.ietf.org; Mon, 03 May 2004 15:33:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43JXoY3024831 for rtgwg-archive@odin.ietf.org; Mon, 3 May 2004 15:33:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKj0f-00046Q-TZ for rtgwg-web-archive@optimus.ietf.org; Mon, 03 May 2004 15:21:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23513 for ; Mon, 3 May 2004 15:21:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKj0e-0001gt-Mf for rtgwg-web-archive@ietf.org; Mon, 03 May 2004 15:21:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKizi-0001ZM-00 for rtgwg-web-archive@ietf.org; Mon, 03 May 2004 15:20:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKiyn-0001Ru-00 for rtgwg-web-archive@ietf.org; Mon, 03 May 2004 15:19:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKinI-0001Eq-L5; Mon, 03 May 2004 15:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiiU-0005QM-Rr for rtgwg@optimus.ietf.org; Mon, 03 May 2004 15:03:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20730 for ; Mon, 3 May 2004 15:02:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKiiR-0006vr-QU for rtgwg@ietf.org; Mon, 03 May 2004 15:02:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKihZ-0006ob-00 for rtgwg@ietf.org; Mon, 03 May 2004 15:02:05 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1BKigi-0006a3-00 for rtgwg@ietf.org; Mon, 03 May 2004 15:01:12 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i43J0YX02054; Mon, 3 May 2004 15:00:35 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 May 2004 15:00:34 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60A23BF30@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: Alex Zinin , rtgwg@ietf.org Subject: RE: Review Call: draft-atlas-ip-local-protect-00.txt as WG item Date: Mon, 3 May 2004 15:00:34 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Alex Please see comments inline. Regards, Don > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > > At this point I would like to solicit opinions on the following > points: > > 1. Technical comments on the substance of the document I support the document because it addresses a practical problem of minimizing packet loss. As stated in the document, this is most noticeable with certain real-time applications like voice. > > 2. More specifically, comments on the U-Turn part (e.g. useful/not > useful, > comfortable/concerned with the approach, etc.) I think the U-turn is useful. I can understand that the U-turn is a bit of a difficult problem and solution to understand. I had a few discussions with Alia myself before I was convinced the options and the pieces were complete. I am comfortable with the U-turn mechanism and I believe it is useful because: 1. U-turns can happen for momentary periods in any packet network after the SPF and the FIB update on downstream nodes. Nodal updates are not synchronous and the logic for U-turn does not need to know why the packet is coming back from a primary neighbor it just deals with it preventing loss or black hole effects. 2. U-turn alternates in the draft invoke the U-turn alternatives immediately when no loop-free alternates exist, (after the fault is detected, but before the SPF calculation and new FIB update is complete). > > 3. Should the WG use this document as the basis for work on the IP > fast > reroute topic Others have pointed out that IP Fast reroute involves areas such as: Link Change/Failure Detection, Link State Advertisements, SPF, FIB updates and alternative routing. I agree. Each area is important. The local protect draft provides a basis for work on alternative paths from the after failure detection time to the FIB updates. This document is scoped to what you can do practically while keeping state and logic dependence contained on a single node. Other areas related to fast IP reroute but out of scope for this document: Fast detection of link failures. Efficient LSA distribution. Fast SPF calculation. Building logic for loop free alternates by other means. _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Mon May 3 17:39:35 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04738 for ; Mon, 3 May 2004 17:39:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKl0J-0000jn-PR for rtgwg-archive@odin.ietf.org; Mon, 03 May 2004 17:29:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43LTZih002771 for rtgwg-archive@odin.ietf.org; Mon, 3 May 2004 17:29:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKkQv-0007Bn-Kt for rtgwg-web-archive@optimus.ietf.org; Mon, 03 May 2004 16:53:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00068 for ; Mon, 3 May 2004 16:52:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKkQt-0006h1-FC for rtgwg-web-archive@ietf.org; Mon, 03 May 2004 16:52:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKkOZ-0006AD-00 for rtgwg-web-archive@ietf.org; Mon, 03 May 2004 16:50:36 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKkMx-0005lz-01 for rtgwg-web-archive@ietf.org; Mon, 03 May 2004 16:48:55 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BKkFT-0000Vo-Uz for rtgwg-web-archive@ietf.org; Mon, 03 May 2004 16:41:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjb1-00064H-Cr; Mon, 03 May 2004 15:59:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjWK-0004uT-Dv for rtgwg@optimus.ietf.org; Mon, 03 May 2004 15:54:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25657; Mon, 3 May 2004 15:54:29 -0400 (EDT) Message-Id: <200405031954.PAA25657@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ipv6@ietf.org, rtgwg@ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-perlman-rbridge-00.txt Date: Mon, 03 May 2004 15:54:29 -0400 Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RBridges: Transparent Routing Author(s) : R. Perlman, et al. Filename : draft-perlman-rbridge-00.txt Pages : 0 Date : 2004-5-3 This design provides the ability to have an entire campus, with multiple physical links, look to IP like a single subnet. This allows zero configuration of the switches within the campus, and allows nodes to move around within the campus without changing IP addresses. This capability is often provided today with bridges. Bridges do accomplish this goal. However, bridges have disadvantages: routing is confined to a spanning tree (precluding pair-wise shortest paths), the header on which the spanning tree forwards has no hop count, spanning tree forwarding in the presence of temporary loops spawns exponential copies of packets, nodes can have only a single point of attachment, and the spanning tree, in order to avoid temporary loops, is slow to start forwarding on new ports. The design in this paper avoids these disadvantages of bridges while maintaining the advantages. This design works for both IPv4 and IPv6. This document is a work in progress; we invite you to participate on the rbridge mailing list at http://www.postel.org/rbridge A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perlman-rbridge-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-perlman-rbridge-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-perlman-rbridge-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-3161505.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-perlman-rbridge-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-perlman-rbridge-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-3161505.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Tue May 4 07:14:10 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24027 for ; Tue, 4 May 2004 07:14:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxk2-000074-Sf for rtgwg-archive@odin.ietf.org; Tue, 04 May 2004 07:05:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44B5cdw000429 for rtgwg-archive@odin.ietf.org; Tue, 4 May 2004 07:05:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxgE-00078q-JX for rtgwg-web-archive@optimus.ietf.org; Tue, 04 May 2004 07:01:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22943 for ; Tue, 4 May 2004 07:01:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKxgA-0000nd-ED for rtgwg-web-archive@ietf.org; Tue, 04 May 2004 07:01:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKxei-0000MX-00 for rtgwg-web-archive@ietf.org; Tue, 04 May 2004 07:00:09 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BKxcR-0007XV-00 for rtgwg-web-archive@ietf.org; Tue, 04 May 2004 06:57:47 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BKxcU-0005Nq-Cb for rtgwg-web-archive@ietf.org; Tue, 04 May 2004 06:57:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxam-0005A5-4n; Tue, 04 May 2004 06:56:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKxL1-0001Ao-4o for rtgwg@optimus.ietf.org; Tue, 04 May 2004 06:39:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21195 for ; Tue, 4 May 2004 06:39:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKxKx-0003a0-1z for rtgwg@ietf.org; Tue, 04 May 2004 06:39:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKxK8-0003NH-00 for rtgwg@ietf.org; Tue, 04 May 2004 06:38:53 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BKxJX-00037a-00 for rtgwg@ietf.org; Tue, 04 May 2004 06:38:15 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 04 May 2004 02:50:46 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i44AabC1008218; Tue, 4 May 2004 03:37:04 -0700 (PDT) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4246.cisco.com [10.61.80.149]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA10125; Tue, 4 May 2004 11:36:34 +0100 (BST) Message-Id: <4.3.2.7.2.20040504112443.02c70b28@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 May 2004 11:36:31 +0100 To: "Don Fedyk" From: mike shand Subject: RE: Review Call: draft-atlas-ip-local-protect-00.txt as WG item Cc: Alex Zinin , rtgwg@ietf.org In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E60A23BF30@zcard0ke.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 15:00 03/05/2004 -0400, Don Fedyk wrote: >1. U-turns can happen for momentary periods in any packet network after the >SPF and the FIB update on downstream nodes. Nodal updates are not >synchronous and the logic for U-turn does not need to know why the packet is >coming back from a primary neighbor it just deals with it preventing loss or >black hole effects. But surely, when the U-turn is invoked because of desynchronized FIB updates there is no guarantee that the packet will be delivered successfully. The packet will be sent on a path computed to avoid the next next hop. This might be OK, but it equally might not. It might take it to another place where the U-turn would be triggered by desynchronized FIBs, and the repair path for that U-turn might lead back to the first case. It would appear that this introduces unpredictable behaviour into the network, which isn't desirable. Mike _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Tue May 4 10:28:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04373 for ; Tue, 4 May 2004 10:28:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0rA-0003IK-3e for rtgwg-archive@odin.ietf.org; Tue, 04 May 2004 10:25:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44EPCZ3012660 for rtgwg-archive@odin.ietf.org; Tue, 4 May 2004 10:25:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0pg-0002pP-5a for rtgwg-web-archive@optimus.ietf.org; Tue, 04 May 2004 10:23:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04053 for ; Tue, 4 May 2004 10:23:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL0pd-0005T4-UO for rtgwg-web-archive@ietf.org; Tue, 04 May 2004 10:23:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0oh-0005PN-00 for rtgwg-web-archive@ietf.org; Tue, 04 May 2004 10:22:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL0oN-0005ML-00 for rtgwg-web-archive@ietf.org; Tue, 04 May 2004 10:22:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0kC-0000j0-Hl; Tue, 04 May 2004 10:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0f4-00070s-Jm for rtgwg@optimus.ietf.org; Tue, 04 May 2004 10:12:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03288 for ; Tue, 4 May 2004 10:12:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL0f2-0004p5-Ey for rtgwg@ietf.org; Tue, 04 May 2004 10:12:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0e6-0004kw-00 for rtgwg@ietf.org; Tue, 04 May 2004 10:11:43 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1BL0dC-0004e0-00 for rtgwg@ietf.org; Tue, 04 May 2004 10:10:46 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i44DwQM17366; Tue, 4 May 2004 09:58:26 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 May 2004 09:58:26 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60A2ADE56@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: mike shand Cc: Alex Zinin , rtgwg@ietf.org Subject: RE: Review Call: draft-atlas-ip-local-protect-00.txt as WG item Date: Tue, 4 May 2004 09:58:17 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Mike First lets make it clear we are talking about a subset of packets that are affected by transient conditions. So following this lets say conditions are such that some percent of packets are not delivered or looped when the U-turn logic is invoked whereas currently 100 percent of these same packets are not delivered or looped. Both condition produce packet loss as viewed from outside the network. But comparing them, doing the U-turn logic has much less packet loss. This seems beneficial to me. Don > -----Original Message----- > From: mike shand [mailto:mshand@cisco.com] > > At 15:00 03/05/2004 -0400, Don Fedyk wrote: > >1. U-turns can happen for momentary periods in any packet > network after > >the SPF and the FIB update on downstream nodes. Nodal > updates are not > >synchronous and the logic for U-turn does not need to know why the > >packet is coming back from a primary neighbor it just deals with it > >preventing loss or black hole effects. > > But surely, when the U-turn is invoked because of desynchronized FIB > updates there is no guarantee that the packet will be delivered > successfully. The packet will be sent on a path computed to > avoid the next > next hop. This might be OK, but it equally might not. It > might take it to > another place where the U-turn would be triggered by > desynchronized FIBs, > and the repair path for that U-turn might lead back to the first case. > > It would appear that this introduces unpredictable behaviour into the > network, which isn't desirable. > > Mike > > > > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Tue May 4 10:44:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05724 for ; Tue, 4 May 2004 10:44:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL18P-0008CM-PU for rtgwg-archive@odin.ietf.org; Tue, 04 May 2004 10:43:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44Eh1aW031509 for rtgwg-archive@odin.ietf.org; Tue, 4 May 2004 10:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL12J-00068Z-Tw for rtgwg-web-archive@optimus.ietf.org; Tue, 04 May 2004 10:36:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04817 for ; Tue, 4 May 2004 10:36:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL12H-0006JJ-Op for rtgwg-web-archive@ietf.org; Tue, 04 May 2004 10:36:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL11K-0006F2-00 for rtgwg-web-archive@ietf.org; Tue, 04 May 2004 10:35:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL10K-0006BH-00 for rtgwg-web-archive@ietf.org; Tue, 04 May 2004 10:34:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0s1-0003NQ-Lp; Tue, 04 May 2004 10:26:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0qm-000345-7q for rtgwg@optimus.ietf.org; Tue, 04 May 2004 10:24:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04122 for ; Tue, 4 May 2004 10:24:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL0qj-0005ZU-Pe for rtgwg@ietf.org; Tue, 04 May 2004 10:24:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0ps-0005VT-00 for rtgwg@ietf.org; Tue, 04 May 2004 10:23:53 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BL0pR-0005Q2-00 for rtgwg@ietf.org; Tue, 04 May 2004 10:23:25 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 May 2004 06:35:54 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i44EMlW9010345; Tue, 4 May 2004 07:22:48 -0700 (PDT) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4246.cisco.com [10.61.80.149]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA18187; Tue, 4 May 2004 15:22:45 +0100 (BST) Message-Id: <4.3.2.7.2.20040504151848.00c94d68@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 May 2004 15:22:24 +0100 To: "Don Fedyk" From: mike shand Subject: RE: Review Call: draft-atlas-ip-local-protect-00.txt as WG item Cc: Alex Zinin , rtgwg@ietf.org In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E60A2ADE56@zcard0ke.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 09:58 04/05/2004 -0400, Don Fedyk wrote: >Hi Mike > >First lets make it clear we are talking about a subset of packets that are >affected by transient conditions. So following this lets say conditions are >such that some percent of packets are not delivered or looped when the >U-turn logic is invoked whereas currently 100 percent of these same packets >are not delivered or looped. Both condition produce packet loss as viewed >from outside the network. But comparing them, doing the U-turn logic has >much less packet loss. This seems beneficial to me. Yes, its beneficial in some cases. Some other cases will loop, and some other cases will be dropped because the node didn't have a U-turn path. But I was just pointing out that taking your statement "the logic for U-turn does not need to know why the packet is coming back from a primary neighbor it just deals with it preventing loss or black hole effects." at face value may lead one to suppose that ALL such looping problems were prevented, which is not the case. Mike >Don > > > -----Original Message----- > > From: mike shand [mailto:mshand@cisco.com] > > > > At 15:00 03/05/2004 -0400, Don Fedyk wrote: > > >1. U-turns can happen for momentary periods in any packet > > network after > > >the SPF and the FIB update on downstream nodes. Nodal > > updates are not > > >synchronous and the logic for U-turn does not need to know why the > > >packet is coming back from a primary neighbor it just deals with it > > >preventing loss or black hole effects. > > > > But surely, when the U-turn is invoked because of desynchronized FIB > > updates there is no guarantee that the packet will be delivered > > successfully. The packet will be sent on a path computed to > > avoid the next > > next hop. This might be OK, but it equally might not. It > > might take it to > > another place where the U-turn would be triggered by > > desynchronized FIBs, > > and the repair path for that U-turn might lead back to the first case. > > > > It would appear that this introduces unpredictable behaviour into the > > network, which isn't desirable. > > > > Mike > > > > > > > > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Tue May 4 16:02:46 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25969 for ; Tue, 4 May 2004 16:02:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL65F-0006Jk-U4 for rtgwg-archive@odin.ietf.org; Tue, 04 May 2004 16:00:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44K05Y1024285 for rtgwg-archive@odin.ietf.org; Tue, 4 May 2004 16:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL609-0005N4-2r for rtgwg-web-archive@optimus.ietf.org; Tue, 04 May 2004 15:54:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25613 for ; Tue, 4 May 2004 15:54:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL607-0007Gh-II for rtgwg-web-archive@ietf.org; Tue, 04 May 2004 15:54:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL5zC-0007Ap-00 for rtgwg-web-archive@ietf.org; Tue, 04 May 2004 15:53:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL5yT-00075I-00 for rtgwg-web-archive@ietf.org; Tue, 04 May 2004 15:53:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL5wU-0004X8-46; Tue, 04 May 2004 15:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL5qy-00032B-5W for rtgwg@optimus.ietf.org; Tue, 04 May 2004 15:45:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24953 for ; Tue, 4 May 2004 15:45:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL5qw-00064S-NF for rtgwg@ietf.org; Tue, 04 May 2004 15:45:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL5pq-0005vS-00 for rtgwg@ietf.org; Tue, 04 May 2004 15:44:11 -0400 Received: from [208.246.215.201] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1BL5p4-0005ke-00 for rtgwg@ietf.org; Tue, 04 May 2004 15:43:23 -0400 Received: from aatlas-lt2.avici.com (b2-pc109.avici.com [10.2.100.109]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i44JfEcu018799; Tue, 4 May 2004 15:41:14 -0400 Message-Id: <5.1.0.14.2.20040504132742.01d99968@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 May 2004 15:41:25 -0400 To: mike shand From: Alia Atlas Subject: RE: Review Call: draft-atlas-ip-local-protect-00.txt as WG item Cc: "Don Fedyk" , Alex Zinin , rtgwg@ietf.org In-Reply-To: <4.3.2.7.2.20040504151848.00c94d68@jaws.cisco.com> References: <0D7FC1D8D861D511AEA70002A52CE5E60A2ADE56@zcard0ke.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Mike, At 10:22 AM 5/4/2004, mike shand wrote: >At 09:58 04/05/2004 -0400, Don Fedyk wrote: >>Hi Mike >> >>First lets make it clear we are talking about a subset of packets that are >>affected by transient conditions. So following this lets say conditions are >>such that some percent of packets are not delivered or looped when the >>U-turn logic is invoked whereas currently 100 percent of these same packets >>are not delivered or looped. Both condition produce packet loss as viewed >>from outside the network. But comparing them, doing the U-turn logic has >>much less packet loss. This seems beneficial to me. > >Yes, its beneficial in some cases. Some other cases will loop, and some >other cases will be dropped because the node didn't have a U-turn path. The cases where it would loop require something like the following, where A is sending the traffic to some D downstream: [A]----[B] | | | | [E] ----[C[ where A is using an updated topology and thinks that B is its primary, B is using the old topology and thinks that A is its primary and C is its loop-free node-protecting alternate C is using the old topology and thinks that E is its primary E is using the new topology and thinks that C is its primary and A is its loop-free node-protecting alternate In this case, there are two upstream forwarding loops required simultaneous and a relatively constrained topology. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Tue May 4 20:45:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11248 for ; Tue, 4 May 2004 20:45:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLARP-0000W6-Sd for rtgwg-archive@odin.ietf.org; Tue, 04 May 2004 20:39:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i450dFEg001980 for rtgwg-archive@odin.ietf.org; Tue, 4 May 2004 20:39:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLANI-0007Za-Kx for rtgwg-web-archive@optimus.ietf.org; Tue, 04 May 2004 20:35:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10612 for ; Tue, 4 May 2004 20:34:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLANG-0002FZ-E9 for rtgwg-web-archive@ietf.org; Tue, 04 May 2004 20:34:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLAMJ-00028S-00 for rtgwg-web-archive@ietf.org; Tue, 04 May 2004 20:34:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLALO-000213-00 for rtgwg-web-archive@ietf.org; Tue, 04 May 2004 20:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLAIT-0006PD-Ln; Tue, 04 May 2004 20:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLA9v-0004Py-6w for rtgwg@optimus.ietf.org; Tue, 04 May 2004 20:21:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09968 for ; Tue, 4 May 2004 20:21:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLA9s-0000Wb-Rj for rtgwg@ietf.org; Tue, 04 May 2004 20:21:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLA8u-0000O5-00 for rtgwg@ietf.org; Tue, 04 May 2004 20:20:09 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BLA8A-0000GJ-00 for rtgwg@ietf.org; Tue, 04 May 2004 20:19:22 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLA8B-000LXM-J2 for rtgwg@ietf.org; Wed, 05 May 2004 00:19:23 +0000 Date: Tue, 4 May 2004 17:19:23 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <599615177.20040504171923@psg.com> To: rtgwg@ietf.org Subject: Re: WG Last Call: draft-ietf-rtgwg-igp-shortcut-00.txt In-Reply-To: <706435436.20040419161935@psg.com> References: <706435436.20040419161935@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This concludes the WG Last Call. A few comments on the document from me: 1. Security considerations section is weak. It needs to at least point the reader to the relevant protocol specifications. 2. None of the references is actually used in the document. We only received comments from Joel during the Last Call and he agreed to try and come up with a more elaborate version by the end of this week. -- Alex http://www.psg.com/~zinin/ Monday, April 19, 2004, 4:19:35 PM, Alex Zinin wrote: > Folks- > This is to start a 2-week WG Last Call for draft-ietf-rtgwg-igp-shortcut-00.txt. > The document target status is Informational. The Last Call ends on May 3rd, 2004. > Please send your comments to rtgwg@ietf.org. > The document is available from the WG web-page or at the following URL: > http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-igp-shortcut-00.txt > The Abstract from the document is included below: > This document describes how conventional hop-by-hop link-state > routing protocols interact with new Traffic Engineering capabilities > to create IGP shortcuts. In particular this document describes how > Dijkstra's SPF algorithm should be adapted so that link-state IGPs > will calculate IP routes to forward traffic over tunnels that are > set up by Traffic Engineering. _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Wed May 5 12:57:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25563 for ; Wed, 5 May 2004 12:57:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPUq-0008JN-0a for rtgwg-archive@odin.ietf.org; Wed, 05 May 2004 12:43:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45GhlNN031941 for rtgwg-archive@odin.ietf.org; Wed, 5 May 2004 12:43:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPNE-0004pW-BP for rtgwg-web-archive@optimus.ietf.org; Wed, 05 May 2004 12:35:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24482 for ; Wed, 5 May 2004 12:35:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLPNC-0002jE-LW for rtgwg-web-archive@ietf.org; Wed, 05 May 2004 12:35:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPMM-0002Rs-00 for rtgwg-web-archive@ietf.org; Wed, 05 May 2004 12:35:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLPLg-0002Ak-00 for rtgwg-web-archive@ietf.org; Wed, 05 May 2004 12:34:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPCn-0001GF-SB; Wed, 05 May 2004 12:25:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOvw-0001n6-Pd for rtgwg@optimus.ietf.org; Wed, 05 May 2004 12:07:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22932 for ; Wed, 5 May 2004 12:07:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLOvv-0002xD-Gr for rtgwg@ietf.org; Wed, 05 May 2004 12:07:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLOuv-0002gH-00 for rtgwg@ietf.org; Wed, 05 May 2004 12:06:42 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BLOtx-0002OS-00 for rtgwg@ietf.org; Wed, 05 May 2004 12:05:41 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLOtx-000GxG-1U for rtgwg@ietf.org; Wed, 05 May 2004 16:05:41 +0000 Date: Wed, 5 May 2004 09:05:40 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1565422706.20040505090540@psg.com> To: rtgwg@ietf.org Subject: Re: WG Last Call: draft-ietf-rtgwg-igp-shortcut-00.txt In-Reply-To: <599615177.20040504171923@psg.com> References: <706435436.20040419161935@psg.com> <599615177.20040504171923@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tuesday, May 4, 2004, 5:19:23 PM, Alex Zinin wrote: [...] > 2. None of the references is actually used in the document. Please ignore this comment. The doc does use the refs. Alex _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Wed May 5 16:12:06 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09353 for ; Wed, 5 May 2004 16:12:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLSfQ-0005YA-8S for rtgwg-archive@odin.ietf.org; Wed, 05 May 2004 16:06:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45K6ufP021325 for rtgwg-archive@odin.ietf.org; Wed, 5 May 2004 16:06:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLSaX-0002Kr-Bx for rtgwg-web-archive@optimus.ietf.org; Wed, 05 May 2004 16:01:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08807 for ; Wed, 5 May 2004 16:01:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLSaV-0006yU-Q7 for rtgwg-web-archive@ietf.org; Wed, 05 May 2004 16:01:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLSZc-0006fm-00 for rtgwg-web-archive@ietf.org; Wed, 05 May 2004 16:00:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLSYh-0006NQ-00 for rtgwg-web-archive@ietf.org; Wed, 05 May 2004 15:59:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLSSw-0008Qg-NG; Wed, 05 May 2004 15:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLSL7-0004fq-29 for rtgwg@optimus.ietf.org; Wed, 05 May 2004 15:45:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07987 for ; Wed, 5 May 2004 15:45:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLSL5-0002Lt-Jg for rtgwg@ietf.org; Wed, 05 May 2004 15:45:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLSKE-00025n-00 for rtgwg@ietf.org; Wed, 05 May 2004 15:45:03 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BLSJY-0001ot-00 for rtgwg@ietf.org; Wed, 05 May 2004 15:44:20 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i45JiH0O014046; Wed, 5 May 2004 21:44:17 +0200 Received: from alcatel.be ([138.203.67.90]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004050521441559:6058 ; Wed, 5 May 2004 21:44:15 +0200 Message-ID: <4099448B.3020401@alcatel.be> Date: Wed, 05 May 2004 21:46:19 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin CC: rtgwg@ietf.org Subject: Re: Review Call: draft-atlas-ip-local-protect-00.txt as WG item References: <363818486.20040429130509@psg.com> In-Reply-To: <363818486.20040429130509@psg.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/05/2004 21:44:15, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/05/2004 21:44:17, Serialize complete at 05/05/2004 21:44:17 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi alex, Alex Zinin wrote: > Folks- > > As discussed in Seoul, draft-atlas-ip-local-protect-00.txt is being considered > for becoming a WG item. > > At this point I would like to solicit opinions on the following points: > > 1. Technical comments on the substance of the document - some assumptions are made in the document that should probably be spelled out as working assumptions - as example "In essence, the assumption being made is that the time budget to recover traffic in the event of a failure is being consumed by router S's detection of the failure and switchover to its pre-computed alternate." "It is extremely desirable to have at most one forwarding table per interface." how this would translate in case of sub-interfaces ? "Normally, if traffic fails a reverse forwarding check (i.e. would be forwarded out to the same neighbor as received from), then that traffic is either discarded or forwarded into a loop. In IP/LDP Local Protection, however, traffic that fails a reverse forwarding check is forwarded to the appropriate R_i_j, if available, rather than being discarded." "In examining realistic networks, it was seen that loop-free alternates did not provide adequate coverage for the traffic between all the source-destination pairs." would it be possible to give a average characterization of such networks ? - i don't understand the sentence "For neighbor N_4, the path to D is N_3 to S to N_1 to R_1 to D; because there is a node between N4 and S on the path, N_4 is a looping neighbor." from the picture 3 but i'm not sure you meant figure 3 - in the example of section 4.2 is also sending an ICMP re-direct during U-turn mode ? in this case how the condition on top of the figure 8 holds - why this document is referred to as IP*/LDP* protection, if it is referring to the section 5 then it would be need some further details in particular what about the re-direction of the sessions themselves > 2. More specifically, comments on the U-Turn part (e.g. useful/not useful, > comfortable/concerned with the approach, etc.) - seems useful in some particular p2p cases (but really difficult to assess computational complexity impact) since from the wg discussions it delivers ~ +20% coverage - concerned in terms of robustness in non-p2p environment - would prefer keep (d) and (e) case (detailed in section 3.2.3) for a next step (are there exp.results available ?) - no details about retrieving the initial state once the failure is recovered (reversion) > 3. Should the WG use this document as the basis for work on the IP fast > reroute topic it introduces a formalism that can be used for to initiate work on this as well as gives a sensible classification, now its readability is difficult and its structure (since imho oriented towards the use of U-turn) not necessarily in-line with the direction of general topic i-d thanks, - dimitri. > Please send your comments by May 9th. > > The document is available at: > > http://www.ietf.org/internet-drafts/draft-atlas-ip-local-protect-00.txt > > The IPR statement is available at: > > http://www.ietf.org/ietf/IPR/avici-ipr-draft-atlas-ip-local-protect.txt > > Abstract from the document: > > This document defines an architecture and selection process for > providing local protection for IP unicast and/or LDP traffic in the > event of a single link or node failure until the router has > converged. When computing the primary next-hop for a prefix, a > router S also determines an alternate next-hop which can be used if > the primary next-hop fails. The alternate can be either a loop-free > alternate, which goes to a neighbor whose shortest path to the prefix > does not go back through the router S, or a U-turn alternate, which > goes to a neighbor whose primary next-hop to the prefix is the router > S, and which has itself a loop-free node-protecting alternate, which > thus does not go through router S to reach the destination prefix. > > A router may indicate the capability to break U-turns on its links; > only such links can be used as U-turn alternate next-hops. To signal > this capability, a router must be capable of detecting when it > receives traffic for a given destination from a primary neighbor for > that destination and the router must forward that traffic to the > selected alternate next-hop. > > To support U-Turn alternates and node-protection, a router must know > what links its neighbor can consider for alternates, how a neighbor > will select an alternate, and upon which interfaces a neighbor can > break U-turns. This document defines a common selection criteria > which MUST be followed. In addition, it is necessary to signal two > capabilities per link. First is whether U-turns can be broken on the > link and second is whether the link can be used as an alternate, as > determined administratively. > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Thu May 6 14:38:31 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10089 for ; Thu, 6 May 2004 14:38:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLndh-00044W-LC for rtgwg-archive@odin.ietf.org; Thu, 06 May 2004 14:30:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46IUXH2015653 for rtgwg-archive@odin.ietf.org; Thu, 6 May 2004 14:30:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnXJ-0001Wc-Ma for rtgwg-web-archive@optimus.ietf.org; Thu, 06 May 2004 14:23:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09086 for ; Thu, 6 May 2004 14:23:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLnXH-0000Pm-9h for rtgwg-web-archive@ietf.org; Thu, 06 May 2004 14:23:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLnWL-00000U-00 for rtgwg-web-archive@ietf.org; Thu, 06 May 2004 14:22:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLnVM-0007P1-00 for rtgwg-web-archive@ietf.org; Thu, 06 May 2004 14:21:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnHx-0003Ve-7u; Thu, 06 May 2004 14:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLn5R-0005dA-Qq for rtgwg@optimus.ietf.org; Thu, 06 May 2004 13:55:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07487 for ; Thu, 6 May 2004 13:55:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLn5P-0003ge-I2 for rtgwg@ietf.org; Thu, 06 May 2004 13:55:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLn4f-0003FV-00 for rtgwg@ietf.org; Thu, 06 May 2004 13:54:22 -0400 Received: from [208.246.215.201] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1BLn3c-0002O1-00 for rtgwg@ietf.org; Thu, 06 May 2004 13:53:16 -0400 Received: from aatlas-lt2.avici.com (b2-pc109.avici.com [10.2.100.109]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i46HqTcu015389; Thu, 6 May 2004 13:52:30 -0400 Message-Id: <5.1.0.14.2.20040506133242.029dc108@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 May 2004 13:52:36 -0400 To: Dimitri.Papadimitriou@alcatel.be From: Alia Atlas Subject: Re: Review Call: draft-atlas-ip-local-protect-00.txt as WG item Cc: Alex Zinin , rtgwg@ietf.org In-Reply-To: <4099448B.3020401@alcatel.be> References: <363818486.20040429130509@psg.com> <363818486.20040429130509@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Dimitri, At 03:46 PM 5/5/2004, Dimitri.Papadimitriou@alcatel.be wrote: >hi alex, > >Alex Zinin wrote: > >>Folks- >> As discussed in Seoul, draft-atlas-ip-local-protect-00.txt is being >> considered >> for becoming a WG item. >> At this point I would like to solicit opinions on the following points: >> 1. Technical comments on the substance of the document > >- some assumptions are made in the document that should probably be > spelled out as working assumptions - as example Yes, this makes sense. > "In essence, the assumption being made is that the time budget to > recover traffic in the event of a failure is being consumed by router > S's detection of the failure and switchover to its pre-computed > alternate." > "It is extremely desirable to have at most one forwarding table per > interface." how this would translate in case of sub-interfaces ? I meant interface or sub-interface. > "Normally, if traffic fails a reverse forwarding check (i.e. would > be forwarded out to the same neighbor as received from), then that > traffic is either discarded or forwarded into a loop. In IP/LDP Local > Protection, however, traffic that fails a reverse forwarding check is > forwarded to the appropriate R_i_j, if available, rather than being > discarded." > "In examining realistic networks, it was seen that loop-free > alternates did not provide adequate coverage for the traffic between > all the source-destination pairs." would it be possible to give a > average characterization of such networks ? I'm not sure I can give you an average characterization. Anyplace where you have something like the following, a loop-free alternate won't exist for S. In this case, D could be replaced by a cloud with D accessed elsewhere. <--- <---- [ P ]-----------[ S ]----------[ N_1 ]---------[ R_1 ] | | | ---> <--- | |------------------------------[D]------------------| >- i don't understand the sentence "For neighbor N_4, the path to D is > N_3 to S to N_1 to R_1 to D; because there is a node between N4 and S > on the path, N_4 is a looping neighbor." from the picture 3 but i'm > not sure you meant figure 3 Replace N_1 with P. I do mean Figure 3. >- in the example of section 4.2 is also sending an ICMP re-direct > during U-turn mode ? in this case how the condition on top of the > figure 8 holds It is not also sending an ICMP re-direct. I'm a bit confused by this question. Can you clarify? >- why this document is referred to as IP*/LDP* protection, if it is > referring to the section 5 then it would be need some further details > in particular what about the re-direction of the sessions themselves The sessions do not need to be redirected; that is one of the benefits. If there is no existing LDP session with the selected alternate neighbor, then that LDP FEC cannot use the alternate. Generally, a router will have an LDP session with its neighbors in that area. >> 2. More specifically, comments on the U-Turn part (e.g. useful/not useful, >> comfortable/concerned with the approach, etc.) > >- seems useful in some particular p2p cases (but really difficult to > assess computational complexity impact) since from the wg discussions > it delivers ~ +20% coverage >- concerned in terms of robustness in non-p2p environment For non-p2p, you have to know that all the neighbors on that interface are in the same area, and thus working on the same topology. It is of more limited use there. >- would prefer keep (d) and (e) case (detailed in section 3.2.3) for a > next step (are there exp.results available ?) What type of exp. results are you looking for? >- no details about retrieving the initial state once the failure is > recovered (reversion) This falls into the assumptions, I guess. Once a new SPF has been run, its results are installed into the FIB and are used. >> 3. Should the WG use this document as the basis for work on the IP fast >> reroute topic > >it introduces a formalism that can be used for to initiate work on this >as well as gives a sensible classification, now its readability is >difficult and its structure (since imho oriented towards the use of >U-turn) not necessarily in-line with the direction of general topic i-d The U-turn alternates clearly require some standardized signaling and agreement on selection, which is why the document was written with that orientation. Thanks, Alia >thanks, >- dimitri. > >> Please send your comments by May 9th. >> The document is available at: >> http://www.ietf.org/internet-drafts/draft-atlas-ip-local-protect-00.txt >> The IPR statement is available at: >> http://www.ietf.org/ietf/IPR/avici-ipr-draft-atlas-ip-local-protect.txt >> Abstract from the document: >> This document defines an architecture and selection process for >> providing local protection for IP unicast and/or LDP traffic in the >> event of a single link or node failure until the router has >> converged. When computing the primary next-hop for a prefix, a >> router S also determines an alternate next-hop which can be used if >> the primary next-hop fails. The alternate can be either a loop-free >> alternate, which goes to a neighbor whose shortest path to the prefix >> does not go back through the router S, or a U-turn alternate, which >> goes to a neighbor whose primary next-hop to the prefix is the router >> S, and which has itself a loop-free node-protecting alternate, which >> thus does not go through router S to reach the destination prefix. >> A router may indicate the capability to break U-turns on its links; >> only such links can be used as U-turn alternate next-hops. To signal >> this capability, a router must be capable of detecting when it >> receives traffic for a given destination from a primary neighbor for >> that destination and the router must forward that traffic to the >> selected alternate next-hop. >> To support U-Turn alternates and node-protection, a router must know >> what links its neighbor can consider for alternates, how a neighbor >> will select an alternate, and upon which interfaces a neighbor can >> break U-turns. This document defines a common selection criteria >> which MUST be followed. In addition, it is necessary to signal two >> capabilities per link. First is whether U-turns can be broken on the >> link and second is whether the link can be used as an alternate, as >> determined administratively. > >-- >Papadimitriou Dimitri >E-mail : dimitri.papadimitriou@alcatel.be >E-mail : dpapadimitriou@psg.com >Webpage: http://psg.com/~dpapadimitriou/ >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >Phone : +32 3 240-8491 > > > > >_______________________________________________ >Rtgwg mailing list >Rtgwg@ietf.org >https://www1.ietf.org/mailman/listinfo/rtgwg _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Thu May 6 18:21:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24246 for ; Thu, 6 May 2004 18:21:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLrDp-0005Cg-QQ for rtgwg-archive@odin.ietf.org; Thu, 06 May 2004 18:20:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46MK5Rd020002 for rtgwg-archive@odin.ietf.org; Thu, 6 May 2004 18:20:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLr8G-0001p9-5V for rtgwg-web-archive@optimus.ietf.org; Thu, 06 May 2004 18:14:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23720 for ; Thu, 6 May 2004 18:14:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLr8D-0003Zg-Bt for rtgwg-web-archive@ietf.org; Thu, 06 May 2004 18:14:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLr7B-0003AH-00 for rtgwg-web-archive@ietf.org; Thu, 06 May 2004 18:13:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLr6i-0002kc-00 for rtgwg-web-archive@ietf.org; Thu, 06 May 2004 18:12:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLr39-0006dL-GA; Thu, 06 May 2004 18:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLqyN-0003TA-8v for rtgwg@optimus.ietf.org; Thu, 06 May 2004 18:04:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22490 for ; Thu, 6 May 2004 18:04:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLqyK-0007C7-Cd for rtgwg@ietf.org; Thu, 06 May 2004 18:04:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLqxO-0006n9-00 for rtgwg@ietf.org; Thu, 06 May 2004 18:03:07 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1BLqwf-0006Mq-00 for rtgwg@ietf.org; Thu, 06 May 2004 18:02:21 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6928733 for rtgwg@ietf.org; Thu, 06 May 2004 18:02:13 -0400 Message-Id: <5.1.0.14.0.20040506173659.024f9e70@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 May 2004 18:01:49 -0400 To: rtgwg@ietf.org From: "Joel M. Halpern" Subject: Re: WG Last Call: draft-ietf-rtgwg-igp-shortcut-00.txt In-Reply-To: <5.1.0.14.0.20040420115408.0239bde0@localhost> References: <706435436.20040419161935@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This note is an effort to provide clear explanation of what changes I think are needed to make this document an acceptable information RFC. I will assign numbers in what follows to the specific issues I feel need to be addressed. I can not provide full replacement text, but I believe I can provide reasonably clear guidance as to what the problem is. First, except for a small aspect of clarity, the technical material in sections 4 and onward appears sound to me. It describes a valid way to select useful shortcuts, and a valid set of behaviors to use with those. 1) The references to routing tables and metrics could use some clarification. I finally concluded that the routing table being referred to was an intermediate conceptual structure between the per-protocol RIBs and the actual FIB. And I concluded that the metrics being referred to were internal implementation specific metrics used for selecting routes from the conceptual RIB for the FIB. This is indeed a useful way to look at things. Specifically, at the beginning of section 6, it would help if there were additional text describing what "routing table" and what "metric" are meant in the ensuing discussion. I am much more concerned by the early portions of text that attempt to describe the applicability of this document. One can argue that the abstract and introduction do not matter much, since they are just stage setting. However, for an informational document such as this, the stage setting and applicability are critical. It is necessary to tell the reader when the document may be of use. Incorrect assertions about what is necessary for interoperability, or about the relationship to other RFCs is not acceptable. 2) With regard to the Abstract (section 2) the document states that the document describes how the SPF should be adapted so that link-state IGPs will calculate IP routes to forward traffic over tunnels that are set up by Traffic Engineering. I have two concerns with this. 2a) "should" is an inappropriate term to use in a document like this. "can" or "may" are entirely reasonable. The particular algorithm recommended in this document works, but it is not the only mechanism that can be used to enable IGP forwarding over tunnels. 2b) The relationship between this work and Traffic Engineering needs a lot more explanation. This is one of the key reasons I can not provide text. Reading teh Traffic Engineering Applicability RFC, I see that the TE group explicitly says that TE tunnels are for use instead of shortest path routes. I see that they talk about affinities, and about selecting traffic to make use of specific tunnels. The algorithms defined in this shortcut document, while they will send some traffic over tunnels, do not as described meet the applicability of the TE document. I do assume that there is actually an underlying consistency that can be found, but without text I do not know what it is. I believe that the last paragraph of the introduction (section 4) mis-describes the constraints that must be met, and the reasons that TE tunnels can be used in conjunction with the algorithm given, or in fact in conjunction with a range of other algorithms. I would propose that the last paragraph be reword along the following lines. 3) This document describes a mechanism by which Link-state IGPs can make use of these shortcuts, and how tehy can install routes in the internal routing table (and then in the forwarding tables) that point out over these TE-tunnels. The tunnels under consideration are tunnels created explicitly by the node performing the calculation, and with an end-point known to this node. For use in algorithms such as the one described here, it does not matter whether the tunnel itself is strictly routed, or if only the head and tail end-points of the tunnel are known. It is important that the mechanisms used by routers to choose to inject packets into tunnels are such that different routers, with potentially different algorithms, do not induce packet loops in the non-tunneled network. (While it may be sub-optimal, it is not a failure of routing if a packet crosses the same link once in a tunnel and once un-encapsulated.) A simple constraint can ensure that when a router chooses to inject a packet into a tunnel it is not risking inducing an unacceptable loop. For a packet addressed to a destination D, a router may inject the packet into to a tunnel for which the router is the head end iff the tunnel end-point is closer, according to the IGP metric, to the destination D than the injecting router is. The algorithms that follow are one way that a router may obey this rule and make intelligent choices about when to use TE tunnels for traffic. This algorithm may be used in conjunction with other mechanisms such as affinity based tunnel selection. Yours, Joel M. Halpern >At 04:19 PM 4/19/2004 -0700, Alex Zinin wrote: >>Folks- >> >> This is to start a 2-week WG Last Call for >> draft-ietf-rtgwg-igp-shortcut-00.txt. >> The document target status is Informational. The Last Call ends on May >> 3rd, 2004. >> Please send your comments to rtgwg@ietf.org. >> >> The document is available from the WG web-page or at the following URL: >> >> http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-igp-shortcut-00.txt >> >> The Abstract from the document is included below: >> >> This document describes how conventional hop-by-hop link-state >> routing protocols interact with new Traffic Engineering capabilities >> to create IGP shortcuts. In particular this document describes how >> Dijkstra's SPF algorithm should be adapted so that link-state IGPs >> will calculate IP routes to forward traffic over tunnels that are >> set up by Traffic Engineering. >> >>-- >>Alex Zinin >> >> >>_______________________________________________ >>Rtgwg mailing list >>Rtgwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/rtgwg > > >_______________________________________________ >Rtgwg mailing list >Rtgwg@ietf.org >https://www1.ietf.org/mailman/listinfo/rtgwg _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Thu May 6 19:04:46 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25902 for ; Thu, 6 May 2004 19:04:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLrtK-0001OW-Ic for rtgwg-archive@odin.ietf.org; Thu, 06 May 2004 19:02:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46N2wSi005356 for rtgwg-archive@odin.ietf.org; Thu, 6 May 2004 19:02:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLrt1-00016q-7B for rtgwg-web-archive@optimus.ietf.org; Thu, 06 May 2004 19:02:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25805 for ; Thu, 6 May 2004 19:02:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLrsy-0000Jm-1S for rtgwg-web-archive@ietf.org; Thu, 06 May 2004 19:02:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLrrw-0007fC-00 for rtgwg-web-archive@ietf.org; Thu, 06 May 2004 19:01:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLrrD-0007DH-00 for rtgwg-web-archive@ietf.org; Thu, 06 May 2004 19:00:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLrpV-0000T3-SQ; Thu, 06 May 2004 18:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLrog-00009V-Og for rtgwg@optimus.ietf.org; Thu, 06 May 2004 18:58:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25623 for ; Thu, 6 May 2004 18:58:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLrod-0006Mf-FA for rtgwg@ietf.org; Thu, 06 May 2004 18:58:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLrni-0005wu-00 for rtgwg@ietf.org; Thu, 06 May 2004 18:57:12 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BLrmx-0005X6-00 for rtgwg@ietf.org; Thu, 06 May 2004 18:56:23 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i46MtS0O020144; Fri, 7 May 2004 00:55:30 +0200 Received: from alcatel.be ([138.203.118.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004050700552589:195 ; Fri, 7 May 2004 00:55:25 +0200 Message-ID: <409AC2CC.7010003@alcatel.be> Date: Fri, 07 May 2004 00:57:16 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alia Atlas Cc: Alex Zinin , rtgwg@ietf.org Subject: Re: Review Call: draft-atlas-ip-local-protect-00.txt as WG item References: <363818486.20040429130509@psg.com> <363818486.20040429130509@psg.com> <5.1.0.14.2.20040506133242.029dc108@pop.avici.com> In-Reply-To: <5.1.0.14.2.20040506133242.029dc108@pop.avici.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/07/2004 00:55:26, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/07/2004 00:55:30, Serialize complete at 05/07/2004 00:55:30 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi alia, [snip] >>> Folks- >>> As discussed in Seoul, draft-atlas-ip-local-protect-00.txt is being >>> considered >>> for becoming a WG item. >>> At this point I would like to solicit opinions on the following points: >>> 1. Technical comments on the substance of the document >> >> - some assumptions are made in the document that should probably be >> spelled out as working assumptions - as example > > Yes, this makes sense. would it possible to group them (suggestion at the beginning) they were put in different sections (may even help to have those listed per method >> "In essence, the assumption being made is that the time budget to >> recover traffic in the event of a failure is being consumed by router >> S's detection of the failure and switchover to its pre-computed >> alternate." >> "It is extremely desirable to have at most one forwarding table per >> interface." how this would translate in case of sub-interfaces ? > > I meant interface or sub-interface. ok - >> "Normally, if traffic fails a reverse forwarding check (i.e. would >> be forwarded out to the same neighbor as received from), then that >> traffic is either discarded or forwarded into a loop. In IP/LDP Local >> Protection, however, traffic that fails a reverse forwarding check is >> forwarded to the appropriate R_i_j, if available, rather than being >> discarded." >> "In examining realistic networks, it was seen that loop-free >> alternates did not provide adequate coverage for the traffic between >> all the source-destination pairs." would it be possible to give a >> average characterization of such networks ? > > I'm not sure I can give you an average characterization. Anyplace where > you have something like the following, a loop-free alternate won't exist > for S. In this case, D could be replaced by a cloud with D accessed > elsewhere. > > <--- <---- > [ P ]-----------[ S ]----------[ N_1 ]---------[ R_1 ] > | | > | ---> <--- | > |------------------------------[D]------------------| i asked this because you mentioned "realistic networks", as asking you what realistic mean wouldn't have helped, was trying to see how for these realistic network characterizes in order to assess computational complexity (it won't be easy anyway) >> - i don't understand the sentence "For neighbor N_4, the path to D is >> N_3 to S to N_1 to R_1 to D; because there is a node between N4 and S >> on the path, N_4 is a looping neighbor." from the picture 3 but i'm >> not sure you meant figure 3 > > Replace N_1 with P. I do mean Figure 3. ok >> - in the example of section 4.2 is also sending an ICMP re-direct >> during U-turn mode ? in this case how the condition on top of the >> figure 8 holds > > It is not also sending an ICMP re-direct. I'm a bit confused by this > question. Can you clarify? taking figure 8, the condition mentions "Because all link costs are positive, no neighbor on the broadcast interface will ever send traffic to S along that interface in order to reach P. Therefore, S can assume that any traffic received on the broadcast interface which goes to a destination via a primary next-hop neighbor that is also on the broadcast interface is in fact sent by that primary next-hop neighbor and should be redirected to break the U-Turn." where should it be redirect (is it N_4 ? i think so because the figure uses the @@@ arrow) but we would have then N_1/N_2/N_3 (-> P) -> S -> N_4 isn't P sending a redirect (and how the condition holds ?) if the link to P fails i don't understand how this would work (how would N_1/N_2/N_3 detect link to P has failed), would you clarify ? but it seems looking at the next sentence that it seems that the interpretation i have is that S attracts the traffic "Thus, if router S has a primary next-hop neighbor for a given prefix on the broadcast interface, S should redirect all traffic received destined to that prefix on the broadcast interface to S's alternate next-hop." (N_4 is pointed by the @@@ arrow that's indicating the alternate next-hop towards D" >> - why this document is referred to as IP*/LDP* protection, if it is >> referring to the section 5 then it would be need some further details >> in particular what about the re-direction of the sessions themselves > > The sessions do not need to be redirected; that is one of the benefits. > If there is no existing LDP session with the selected alternate > neighbor, then that LDP FEC cannot use the alternate. Generally, a > router will have an LDP session with its neighbors in that area. i would have started the discussion on "FEC protection", and then try to see if there is an impact on LDP from the link/node failures that could affect it, i think we say the same in fact, you've concentrated the doc on FEC (distributed from LDP) - LDP is simply another section in the protocol interactions described in section 6 - but you would agree with me that first sentence of the abstract is rather confusing then from that perspective "This document defines an architecture and selection process for providing local protection for IP unicast and/or LDP traffic in the event of a single link or node failure until the router has converged." btw is the working assumption that the network is running in a uniform mode ? both ? >>> 2. More specifically, comments on the U-Turn part (e.g. useful/not >>> useful, >>> comfortable/concerned with the approach, etc.) >> >> - seems useful in some particular p2p cases (but really difficult to >> assess computational complexity impact) since from the wg discussions >> it delivers ~ +20% coverage by the way i was re-looking at the slides discussed in atlanta and is seems that thre any loop free reached at least 89% (and it was mention that in terms of % of protected links it should be higher) >> - concerned in terms of robustness in non-p2p environment > > For non-p2p, you have to know that all the neighbors on that interface > are in the same area, and thus working on the same topology. It is of > more limited use there. up so far for non p2p environments i have been more looking at the problems it could generate (because without diminishing the merit of the effort i think - and the above statement confirms this - that we're probably running outside of its relevant utilization scope) you may still argue that you can emulate a point to point environment (see p2p-over-lan) but once above point will be clarified i think it will be easier to assess >> - would prefer keep (d) and (e) case (detailed in section 3.2.3) for a >> next step (are there exp.results available ?) > > What type of exp. results are you looking for? computational overhead (we know all the system constraints) wrt to loop-free alternates (for the same topology & in terms of the #nodes, #links, #dest.prefixes) we can even take the topologies for which the succesful events would be greater than simply with loop free alternates >> - no details about retrieving the initial state once the failure is >> recovered (reversion) > > This falls into the assumptions, I guess. Once a new SPF has been run, > its results are installed into the FIB and are used. my question is related to overhead to retrieve the initial state it is in the introduction "until a new SPF is run and its results are installed." there are no further details upon conditions (assuming that breaking a U turn occur) you would require to have something equivalent in terms of succesful events (which results are installed) >>> 3. Should the WG use this document as the basis for work on the IP >>> fast >>> reroute topic >> >> it introduces a formalism that can be used for to initiate work on this >> as well as gives a sensible classification, now its readability is >> difficult and its structure (since imho oriented towards the use of >> U-turn) not necessarily in-line with the direction of general topic i-d > > The U-turn alternates clearly require some standardized signaling and > agreement on selection, which is why the document was written with that > orientation. it would need to be revisited from that perspective (even it would need to make abstraction of the use of U-turns or any "optimized" method beyond loop free alternates in a first phase (?) - would you agree ? thanks, - dimitri. > Thanks, > Alia > >> thanks, >> - dimitri. >> >>> Please send your comments by May 9th. >>> The document is available at: >>> http://www.ietf.org/internet-drafts/draft-atlas-ip-local-protect-00.txt >>> The IPR statement is available at: >>> http://www.ietf.org/ietf/IPR/avici-ipr-draft-atlas-ip-local-protect.txt >>> Abstract from the document: >>> This document defines an architecture and selection process for >>> providing local protection for IP unicast and/or LDP traffic in the >>> event of a single link or node failure until the router has >>> converged. When computing the primary next-hop for a prefix, a >>> router S also determines an alternate next-hop which can be used if >>> the primary next-hop fails. The alternate can be either a loop-free >>> alternate, which goes to a neighbor whose shortest path to the prefix >>> does not go back through the router S, or a U-turn alternate, which >>> goes to a neighbor whose primary next-hop to the prefix is the router >>> S, and which has itself a loop-free node-protecting alternate, which >>> thus does not go through router S to reach the destination prefix. >>> A router may indicate the capability to break U-turns on its links; >>> only such links can be used as U-turn alternate next-hops. To signal >>> this capability, a router must be capable of detecting when it >>> receives traffic for a given destination from a primary neighbor for >>> that destination and the router must forward that traffic to the >>> selected alternate next-hop. >>> To support U-Turn alternates and node-protection, a router must know >>> what links its neighbor can consider for alternates, how a neighbor >>> will select an alternate, and upon which interfaces a neighbor can >>> break U-turns. This document defines a common selection criteria >>> which MUST be followed. In addition, it is necessary to signal two >>> capabilities per link. First is whether U-turns can be broken on the >>> link and second is whether the link can be used as an alternate, as >>> determined administratively. >> >> >> -- >> Papadimitriou Dimitri >> E-mail : dimitri.papadimitriou@alcatel.be >> E-mail : dpapadimitriou@psg.com >> Webpage: http://psg.com/~dpapadimitriou/ >> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >> Phone : +32 3 240-8491 >> >> >> >> >> _______________________________________________ >> Rtgwg mailing list >> Rtgwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/rtgwg > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Thu May 6 21:51:13 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03860 for ; Thu, 6 May 2004 21:51:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLuUi-0001Gi-M6 for rtgwg-archive@odin.ietf.org; Thu, 06 May 2004 21:49:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i471niPK004864 for rtgwg-archive@odin.ietf.org; Thu, 6 May 2004 21:49:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLuRN-0000Ga-8Y for rtgwg-web-archive@optimus.ietf.org; Thu, 06 May 2004 21:46:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03688 for ; Thu, 6 May 2004 21:46:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLuRK-0006hl-D4 for rtgwg-web-archive@ietf.org; Thu, 06 May 2004 21:46:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLuQO-0006J8-00 for rtgwg-web-archive@ietf.org; Thu, 06 May 2004 21:45:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLuPg-0005uh-00 for rtgwg-web-archive@ietf.org; Thu, 06 May 2004 21:44:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLuNE-00078w-V7; Thu, 06 May 2004 21:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLuIb-0005ur-Uk for rtgwg@optimus.ietf.org; Thu, 06 May 2004 21:37:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03398 for ; Thu, 6 May 2004 21:37:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLuIZ-00033S-2O for rtgwg@ietf.org; Thu, 06 May 2004 21:37:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLuHa-0002bv-00 for rtgwg@ietf.org; Thu, 06 May 2004 21:36:11 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BLuGc-0002Bq-00 for rtgwg@ietf.org; Thu, 06 May 2004 21:35:10 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 85E142C2BAB; Thu, 6 May 2004 18:35:10 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18854-09; Thu, 6 May 2004 18:35:10 -0700 (PDT) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id CFDC32C2BA2; Thu, 6 May 2004 18:35:09 -0700 (PDT) Received: from malt (localhost [127.0.0.1]) by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) with ESMTP id SAA07461; Thu, 6 May 2004 18:35:09 -0700 (PDT) Message-Id: <200405070135.SAA07461@redback.com> To: "Joel M. Halpern" Cc: rtgwg@ietf.org Subject: Re: WG Last Call: draft-ietf-rtgwg-igp-shortcut-00.txt In-reply-to: Mail from "Joel M. Halpern" dated Thu, 06 May 2004 18:01:49 EDT <5.1.0.14.0.20040506173659.024f9e70@localhost> Date: Thu, 06 May 2004 18:35:09 -0700 From: Naiming Shen X-Virus-Scanned: by amavisd-new at redback.com Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Joel, thanks so much for the detailed comments. will try to incorporate them into the draft. Regards. ] This note is an effort to provide clear explanation of what changes I think ] are needed to make this document an acceptable information RFC. I will ] assign numbers in what follows to the specific issues I feel need to be ] addressed. I can not provide full replacement text, but I believe I can ] provide reasonably clear guidance as to what the problem is. ] ] ] First, except for a small aspect of clarity, the technical material in ] sections 4 and onward appears sound to me. It describes a valid way to ] select useful shortcuts, and a valid set of behaviors to use with those. ] ] 1) The references to routing tables and metrics could use some ] clarification. I finally concluded that the routing table being referred ] to was an intermediate conceptual structure between the per-protocol RIBs ] and the actual FIB. And I concluded that the metrics being referred to ] were internal implementation specific metrics used for selecting routes ] from the conceptual RIB for the FIB. This is indeed a useful way to look ] at things. Specifically, at the beginning of section 6, it would help if ] there were additional text describing what "routing table" and what ] "metric" are meant in the ensuing discussion. ] ] ] I am much more concerned by the early portions of text that attempt to ] describe the applicability of this document. One can argue that the ] abstract and introduction do not matter much, since they are just stage ] setting. However, for an informational document such as this, the stage ] setting and applicability are critical. It is necessary to tell the reader ] when the document may be of use. Incorrect assertions about what is ] necessary for interoperability, or about the relationship to other RFCs is ] not acceptable. ] ] 2) With regard to the Abstract (section 2) the document states that the ] document describes how the SPF should be adapted so that link-state IGPs ] will calculate IP routes to forward traffic over tunnels that are set up by ] Traffic Engineering. I have two concerns with this. ] 2a) "should" is an inappropriate term to use in a document like ] this. "can" or "may" are entirely reasonable. The particular algorithm ] recommended in this document works, but it is not the only mechanism that ] can be used to enable IGP forwarding over tunnels. ] 2b) The relationship between this work and Traffic Engineering needs a lot ] more explanation. This is one of the key reasons I can not provide ] text. Reading teh Traffic Engineering Applicability RFC, I see that the TE ] group explicitly says that TE tunnels are for use instead of shortest path ] routes. I see that they talk about affinities, and about selecting traffic ] to make use of specific tunnels. The algorithms defined in this shortcut ] document, while they will send some traffic over tunnels, do not as ] described meet the applicability of the TE document. I do assume that ] there is actually an underlying consistency that can be found, but without ] text I do not know what it is. ] ] I believe that the last paragraph of the introduction (section 4) ] mis-describes the constraints that must be met, and the reasons that TE ] tunnels can be used in conjunction with the algorithm given, or in fact in ] conjunction with a range of other algorithms. I would propose that the ] last paragraph be reword along the following lines. ] ] 3) This document describes a mechanism by which Link-state IGPs can make ] use of these shortcuts, and how tehy can install routes in the internal ] routing table (and then in the forwarding tables) that point out over these ] TE-tunnels. The tunnels under consideration are tunnels created explicitly ] by the node performing the calculation, and with an end-point known to this ] node. For use in algorithms such as the one described here, it does not ] matter whether the tunnel itself is strictly routed, or if only the head ] and tail end-points of the tunnel are known. It is important that the ] mechanisms used by routers to choose to inject packets into tunnels are ] such that different routers, with potentially different algorithms, do not ] induce packet loops in the non-tunneled network. (While it may be ] sub-optimal, it is not a failure of routing if a packet crosses the same ] link once in a tunnel and once un-encapsulated.) A simple constraint can ] ensure that when a router chooses to inject a packet into a tunnel it is ] not risking inducing an unacceptable loop. For a packet addressed to a ] destination D, a router may inject the packet into to a tunnel for which ] the router is the head end iff the tunnel end-point is closer, according to ] the IGP metric, to the destination D than the injecting router is. The ] algorithms that follow are one way that a router may obey this rule and ] make intelligent choices about when to use TE tunnels for traffic. This ] algorithm may be used in conjunction with other mechanisms such as affinity ] based tunnel selection. ] ] ] Yours, ] Joel M. Halpern ] ] ] >At 04:19 PM 4/19/2004 -0700, Alex Zinin wrote: ] >>Folks- ] >> ] >> This is to start a 2-week WG Last Call for ] >> draft-ietf-rtgwg-igp-shortcut-00.txt. ] >> The document target status is Informational. The Last Call ends on May ] >> 3rd, 2004. ] >> Please send your comments to rtgwg@ietf.org. ] >> ] >> The document is available from the WG web-page or at the following URL: ] >> ] >> http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-igp-shortcut-00.t xt ] >> ] >> The Abstract from the document is included below: ] >> ] >> This document describes how conventional hop-by-hop link-state ] >> routing protocols interact with new Traffic Engineering capabilities ] >> to create IGP shortcuts. In particular this document describes how ] >> Dijkstra's SPF algorithm should be adapted so that link-state IGPs ] >> will calculate IP routes to forward traffic over tunnels that are ] >> set up by Traffic Engineering. ] >> ] >>-- ] >>Alex Zinin ] >> ] >> ] >>_______________________________________________ ] >>Rtgwg mailing list ] >>Rtgwg@ietf.org ] >>https://www1.ietf.org/mailman/listinfo/rtgwg ] > ] > ] >_______________________________________________ ] >Rtgwg mailing list ] >Rtgwg@ietf.org ] >https://www1.ietf.org/mailman/listinfo/rtgwg ] ] ] _______________________________________________ ] Rtgwg mailing list ] Rtgwg@ietf.org ] https://www1.ietf.org/mailman/listinfo/rtgwg - Naiming _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Fri May 7 12:24:01 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03714 for ; Fri, 7 May 2004 12:24:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM7pS-0007fY-FQ for rtgwg-archive@odin.ietf.org; Fri, 07 May 2004 12:04:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47G42eQ029480 for rtgwg-archive@odin.ietf.org; Fri, 7 May 2004 12:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM7jU-0005qC-2q for rtgwg-web-archive@optimus.ietf.org; Fri, 07 May 2004 11:57:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02559 for ; Fri, 7 May 2004 11:57:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM7jS-0006x8-Rg for rtgwg-web-archive@ietf.org; Fri, 07 May 2004 11:57:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM7iZ-0006WD-00 for rtgwg-web-archive@ietf.org; Fri, 07 May 2004 11:56:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM7hY-00065Y-00 for rtgwg-web-archive@ietf.org; Fri, 07 May 2004 11:55:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM7by-0003Zc-8I; Fri, 07 May 2004 11:50:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM7Tz-0000wL-R3 for rtgwg@optimus.ietf.org; Fri, 07 May 2004 11:41:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02035 for ; Fri, 7 May 2004 11:41:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM7Ty-0007mY-OL for rtgwg@ietf.org; Fri, 07 May 2004 11:41:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM7Sx-0007M2-00 for rtgwg@ietf.org; Fri, 07 May 2004 11:40:49 -0400 Received: from [208.246.215.201] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1BM7SE-0006WK-00 for rtgwg@ietf.org; Fri, 07 May 2004 11:40:03 -0400 Received: from aatlas-lt2.avici.com (b2-pc109.avici.com [10.2.100.109]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i47FdBcu009868; Fri, 7 May 2004 11:39:12 -0400 Message-Id: <5.1.0.14.2.20040507104505.0248f3a0@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 May 2004 11:39:21 -0400 To: Dimitri.Papadimitriou@alcatel.be From: Alia Atlas Subject: Re: Review Call: draft-atlas-ip-local-protect-00.txt as WG item Cc: Alex Zinin , rtgwg@ietf.org In-Reply-To: <409AC2CC.7010003@alcatel.be> References: <5.1.0.14.2.20040506133242.029dc108@pop.avici.com> <363818486.20040429130509@psg.com> <363818486.20040429130509@psg.com> <5.1.0.14.2.20040506133242.029dc108@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Dimitri, At 06:57 PM 5/6/2004, Dimitri.Papadimitriou@alcatel.be wrote: >[snip] >>>>Folks- >>>> As discussed in Seoul, draft-atlas-ip-local-protect-00.txt is being >>>> considered >>>> for becoming a WG item. >>>> At this point I would like to solicit opinions on the following points: >>>> 1. Technical comments on the substance of the document >>> >>>- some assumptions are made in the document that should probably be >>> spelled out as working assumptions - as example >>Yes, this makes sense. > >would it possible to group them (suggestion at the beginning) they were >put in different sections (may even help to have those listed per method Yes, this makes sense as long as sufficient context has been introduced for the assumptions and methods to be understood. >>> "Normally, if traffic fails a reverse forwarding check (i.e. would >>> be forwarded out to the same neighbor as received from), then that >>> traffic is either discarded or forwarded into a loop. In IP/LDP Local >>> Protection, however, traffic that fails a reverse forwarding check is >>> forwarded to the appropriate R_i_j, if available, rather than being >>> discarded." >>> "In examining realistic networks, it was seen that loop-free >>> alternates did not provide adequate coverage for the traffic between >>> all the source-destination pairs." would it be possible to give a >>> average characterization of such networks ? >>I'm not sure I can give you an average characterization. Anyplace where >>you have something like the following, a loop-free alternate won't exist >>for S. In this case, D could be replaced by a cloud with D accessed elsewhere. >> <--- <---- >> [ P ]-----------[ S ]----------[ N_1 ]---------[ R_1 ] >> | | >> | ---> <--- | >> |------------------------------[D]------------------| > >i asked this because you mentioned "realistic networks", as asking you >what realistic mean wouldn't have helped, was trying to see how for these >realistic network characterizes in order to assess computational >complexity (it won't be easy anyway) Well, in this case realistic networks meant a combination of actual core networks. The complexity depends on how many neighbors a router has to consider for an alternate. >>>- in the example of section 4.2 is also sending an ICMP re-direct >>> during U-turn mode ? in this case how the condition on top of the >>> figure 8 holds >>It is not also sending an ICMP re-direct. I'm a bit confused by this >>question. Can you clarify? > >taking figure 8, the condition mentions "Because all link costs are >positive, no neighbor on the broadcast interface will ever send traffic to >S along that interface in order to reach P. Therefore, S can assume that >any traffic received on the broadcast interface which goes to a >destination via a primary next-hop neighbor that is also on the broadcast >interface is in fact sent by that primary next-hop neighbor and should be >redirected to break the U-Turn." where should it be redirect (is it N_4 ? >i think so because the figure uses the @@@ arrow) >but we would have then N_1/N_2/N_3 (-> P) -> S -> N_4 isn't P sending >a redirect (and how the condition holds ?) if the link to P fails i don't >understand how this would work (how would N_1/N_2/N_3 detect link to P has >failed), would you clarify ? but it seems looking at the next sentence >that it seems that the interpretation i have is that S attracts the >traffic "Thus, if router S has a primary next-hop neighbor for a given >prefix on the broadcast interface, S should redirect all traffic received >destined to that prefix on the broadcast interface to S's alternate >next-hop." (N_4 is pointed by the @@@ arrow that's indicating the >alternate next-hop towards D" Ok. In ref to Figure 8, first, N_1, N_2 and N_3 would have P has their primary neighbor. So would S. If the link from P to D failed, then P would send traffic destined for D to S. S, on receiving traffic from its primary neighbor, would detect and break the U-turn and therefore send the traffic to N_4. This picture is trying to address the question of whether N_1, N_2 or N_3 might send traffic destined to D towards S with the belief that it should then go to P. P could send redirects for traffic it receives; that's on a longer time-scale, and doesn't make much sense to me if N_1, N_2 and N_3 are all in the same routing area running the same IGP. >>>- why this document is referred to as IP*/LDP* protection, if it is >>> referring to the section 5 then it would be need some further details >>> in particular what about the re-direction of the sessions themselves >> >>The sessions do not need to be redirected; that is one of the benefits. >>If there is no existing LDP session with the selected alternate neighbor, >>then that LDP FEC cannot use the alternate. Generally, a router will >>have an LDP session with its neighbors in that area. > >i would have started the discussion on "FEC protection", and then try to >see if there is an impact on LDP from the link/node failures that could >affect it, i think we say the same in fact, you've concentrated the doc >on FEC (distributed from LDP) - LDP is simply another section in the >protocol interactions described in section 6 - but you would agree with me >that first sentence of the abstract is rather confusing then from that >perspective "This document defines an architecture and selection process >for providing local protection for IP unicast and/or LDP traffic in the >event of a single link or node failure until the router has converged." >btw is the working assumption that the network is running in a uniform >mode ? both ? It is true that the LDP protection comes from following the IGP and using the alternates that the IGP has computed for a FEC. This works as long as LDP is running in liberal label retention mode and downstream unsolicited, so that LDP has the necessary labels. I wanted to put that benefit up front in the abstract... What do you mean by running in a uniform mode? Are you asking if I'm assuming that the network topology was stable (and the routers converged to use it) before the single failure? Or are you asking if I'm assuming LDP is running everywhere if running anywhere? Or something else? >>>> 2. More specifically, comments on the U-Turn part (e.g. useful/not >>>> useful, >>>> comfortable/concerned with the approach, etc.) >>> >>>- seems useful in some particular p2p cases (but really difficult to >>> assess computational complexity impact) since from the wg discussions >>> it delivers ~ +20% coverage > >by the way i was re-looking at the slides discussed in atlanta and is >seems that thre any loop free reached at least 89% (and it was mention >that in terms of % of protected links it should be higher) The coverage benefits are very much network topology dependent. I'm probably looking at a different set of networks than Cengiz & Alex were. >>>- concerned in terms of robustness in non-p2p environment >>For non-p2p, you have to know that all the neighbors on that interface >>are in the same area, and thus working on the same topology. It is of >>more limited use there. > >up so far for non p2p environments i have been more looking at the >problems it could generate (because without diminishing the merit of the >effort i think - and the above statement confirms this - that we're >probably running outside of its relevant utilization scope) you may still >argue that you can emulate a point to point environment (see p2p-over-lan) >but once above point will be clarified i think it will be easier to assess If emulating a p2p environment, then it works without additional restrictions. >>>- would prefer keep (d) and (e) case (detailed in section 3.2.3) for a >>> next step (are there exp.results available ?) >>What type of exp. results are you looking for? > >computational overhead (we know all the system constraints) wrt to >loop-free alternates (for the same topology & in terms of the #nodes, >#links, #dest.prefixes) we can even take the topologies for which the >succesful events would be greater than simply with loop free alternates That very much depends on the details of the algorithm used for the computation. >>>- no details about retrieving the initial state once the failure is >>> recovered (reversion) >> >>This falls into the assumptions, I guess. Once a new SPF has been run, >>its results are installed into the FIB and are used. > >my question is related to overhead to retrieve the initial state it is in >the introduction "until a new SPF is run and its results are installed." >there are no further details upon conditions (assuming that breaking a U >turn occur) you would require to have something equivalent in terms of >succesful events (which results are installed) Sorry, but could you clarify your question even further? >>>> 3. Should the WG use this document as the basis for work on the IP fast >>>> reroute topic >>> >>>it introduces a formalism that can be used for to initiate work on this >>>as well as gives a sensible classification, now its readability is >>>difficult and its structure (since imho oriented towards the use of >>>U-turn) not necessarily in-line with the direction of general topic i-d >>The U-turn alternates clearly require some standardized signaling and >>agreement on selection, which is why the document was written with that >>orientation. > >it would need to be revisited from that perspective (even it would need to >make abstraction of the use of U-turns or any "optimized" method beyond >loop free alternates in a first phase (?) - would you agree ? Certainly it will need to given a perspective suitable to the sub-set of information contained in it. If that doesn't include U-Turns (because that is in a separate draft for Experimental, for instance), then that would certainly change the perspective. Thanks, Alia >thanks, >- dimitri. > >>Thanks, >>Alia >> >>>thanks, >>>- dimitri. >>> >>>> Please send your comments by May 9th. >>>> The document is available at: >>>> http://www.ietf.org/internet-drafts/draft-atlas-ip-local-protect-00.txt >>>> The IPR statement is available at: >>>> http://www.ietf.org/ietf/IPR/avici-ipr-draft-atlas-ip-local-protect.txt >>>> Abstract from the document: >>>> This document defines an architecture and selection process for >>>> providing local protection for IP unicast and/or LDP traffic in the >>>> event of a single link or node failure until the router has >>>> converged. When computing the primary next-hop for a prefix, a >>>> router S also determines an alternate next-hop which can be used if >>>> the primary next-hop fails. The alternate can be either a loop-free >>>> alternate, which goes to a neighbor whose shortest path to the prefix >>>> does not go back through the router S, or a U-turn alternate, which >>>> goes to a neighbor whose primary next-hop to the prefix is the router >>>> S, and which has itself a loop-free node-protecting alternate, which >>>> thus does not go through router S to reach the destination prefix. >>>> A router may indicate the capability to break U-turns on its links; >>>> only such links can be used as U-turn alternate next-hops. To signal >>>> this capability, a router must be capable of detecting when it >>>> receives traffic for a given destination from a primary neighbor for >>>> that destination and the router must forward that traffic to the >>>> selected alternate next-hop. >>>> To support U-Turn alternates and node-protection, a router must know >>>> what links its neighbor can consider for alternates, how a neighbor >>>> will select an alternate, and upon which interfaces a neighbor can >>>> break U-turns. This document defines a common selection criteria >>>> which MUST be followed. In addition, it is necessary to signal two >>>> capabilities per link. First is whether U-turns can be broken on the >>>> link and second is whether the link can be used as an alternate, as >>>> determined administratively. >>> >>> >>>-- >>>Papadimitriou Dimitri >>>E-mail : dimitri.papadimitriou@alcatel.be >>>E-mail : dpapadimitriou@psg.com >>>Webpage: http://psg.com/~dpapadimitriou/ >>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >>>Phone : +32 3 240-8491 >>> >>> >>> >>> >>>_______________________________________________ >>>Rtgwg mailing list >>>Rtgwg@ietf.org >>>https://www1.ietf.org/mailman/listinfo/rtgwg >> > >-- >Papadimitriou Dimitri >E-mail : dimitri.papadimitriou@alcatel.be >E-mail : dpapadimitriou@psg.com >Webpage: http://psg.com/~dpapadimitriou/ >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >Phone : +32 3 240-8491 > > >_______________________________________________ >Rtgwg mailing list >Rtgwg@ietf.org >https://www1.ietf.org/mailman/listinfo/rtgwg _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Sun May 9 15:08:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17252 for ; Sun, 9 May 2004 15:08:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMtbx-0004ig-Kp for rtgwg-archive@odin.ietf.org; Sun, 09 May 2004 15:05:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i49J5HFL018046 for rtgwg-archive@odin.ietf.org; Sun, 9 May 2004 15:05:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMtX3-0007ae-R2 for rtgwg-web-archive@optimus.ietf.org; Sun, 09 May 2004 15:00:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16541 for ; Sun, 9 May 2004 15:00:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMtX0-0004mH-PA for rtgwg-web-archive@ietf.org; Sun, 09 May 2004 15:00:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMtW0-0004Sj-00 for rtgwg-web-archive@ietf.org; Sun, 09 May 2004 14:59:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMtVB-0004AA-00 for rtgwg-web-archive@ietf.org; Sun, 09 May 2004 14:58:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMtTw-0006zH-BG; Sun, 09 May 2004 14:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMtT0-0006t3-I1 for rtgwg@optimus.ietf.org; Sun, 09 May 2004 14:56:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16374 for ; Sun, 9 May 2004 14:55:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMtSx-0003YH-OX for rtgwg@ietf.org; Sun, 09 May 2004 14:55:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMtS2-0003Fy-00 for rtgwg@ietf.org; Sun, 09 May 2004 14:55:03 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BMtR4-0002xw-00 for rtgwg@ietf.org; Sun, 09 May 2004 14:54:02 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BMtR4-000Cq3-2X; Sun, 09 May 2004 18:54:02 +0000 Date: Sun, 9 May 2004 11:53:59 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1342466946.20040509115359@psg.com> To: Naiming Shen CC: "Joel M. Halpern" , rtgwg@ietf.org Subject: Re: WG Last Call: draft-ietf-rtgwg-igp-shortcut-00.txt In-Reply-To: <200405070135.SAA07461@redback.com> References: Mail from "Joel M. Halpern" dated Thu, 06 May 2004 18:01:49 EDT <5.1.0.14.0.20040506173659.024f9e70@localhost> <200405070135.SAA07461@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Naiming, How much time do you need to revise the doc? Regards. -- Alex http://www.psg.com/~zinin/ Thursday, May 6, 2004, 6:35:09 PM, Naiming Shen wrote: > Joel, > thanks so much for the detailed comments. will try to incorporate them > into the draft. > Regards. _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Mon May 10 02:12:54 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24642 for ; Mon, 10 May 2004 02:12:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN40t-0006PK-2l for rtgwg-archive@odin.ietf.org; Mon, 10 May 2004 02:11:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4A6Bg9e024601 for rtgwg-archive@odin.ietf.org; Mon, 10 May 2004 02:11:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN3yy-0005eR-Uk for rtgwg-web-archive@optimus.ietf.org; Mon, 10 May 2004 02:09:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21431 for ; Mon, 10 May 2004 02:09:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN3yv-00058j-H9 for rtgwg-web-archive@ietf.org; Mon, 10 May 2004 02:09:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN3y1-0004oy-00 for rtgwg-web-archive@ietf.org; Mon, 10 May 2004 02:08:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BN3xE-0004V8-00 for rtgwg-web-archive@ietf.org; Mon, 10 May 2004 02:07:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN3pl-0001To-5N; Mon, 10 May 2004 02:00:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN3nE-00014x-Rw for rtgwg@optimus.ietf.org; Mon, 10 May 2004 01:57:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11303 for ; Mon, 10 May 2004 01:57:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN3nB-0001YJ-Ex for rtgwg@ietf.org; Mon, 10 May 2004 01:57:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN3mB-0001H0-00 for rtgwg@ietf.org; Mon, 10 May 2004 01:56:31 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BN3lg-0000yz-00 for rtgwg@ietf.org; Mon, 10 May 2004 01:56:01 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 92FC12A630A; Sun, 9 May 2004 22:55:53 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09943-09; Sun, 9 May 2004 22:55:53 -0700 (PDT) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id F0A002A6309; Sun, 9 May 2004 22:55:52 -0700 (PDT) Received: from malt (localhost [127.0.0.1]) by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) with ESMTP id WAA21010; Sun, 9 May 2004 22:55:52 -0700 (PDT) Message-Id: <200405100555.WAA21010@redback.com> To: Alex Zinin Cc: Naiming Shen , "Joel M. Halpern" , rtgwg@ietf.org Subject: Re: WG Last Call: draft-ietf-rtgwg-igp-shortcut-00.txt In-reply-to: Mail from Alex Zinin dated Sun, 09 May 2004 11:53:59 PDT <1342466946.20040509115359@psg.com> Date: Sun, 09 May 2004 22:55:52 -0700 From: Naiming Shen X-Virus-Scanned: by amavisd-new at redback.com Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi Alex, ] Naiming, ] ] How much time do you need to revise the doc? ] I'm on a trip next week, will try to address this in the following week. So will be around two weeks time and hope that's cool. thanks. ] Regards. ] ] -- ] Alex ] http://www.psg.com/~zinin/ ] ] Thursday, May 6, 2004, 6:35:09 PM, Naiming Shen wrote: ] ] > Joel, ] ] > thanks so much for the detailed comments. will try to incorporate them ] > into the draft. ] ] > Regards. ] ] ] - Naiming _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Mon May 10 02:18:55 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00778 for ; Mon, 10 May 2004 02:18:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN43s-0007SY-Aw for rtgwg-archive@odin.ietf.org; Mon, 10 May 2004 02:14:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4A6EmUa028670 for rtgwg-archive@odin.ietf.org; Mon, 10 May 2004 02:14:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN42k-00078o-U5 for rtgwg-web-archive@optimus.ietf.org; Mon, 10 May 2004 02:13:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25355 for ; Mon, 10 May 2004 02:13:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN42h-0006MU-Es for rtgwg-web-archive@ietf.org; Mon, 10 May 2004 02:13:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN41j-000644-00 for rtgwg-web-archive@ietf.org; Mon, 10 May 2004 02:12:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BN41J-0005ld-00 for rtgwg-web-archive@ietf.org; Mon, 10 May 2004 02:12:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN3zG-0005kU-RJ; Mon, 10 May 2004 02:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN3xJ-00053t-6N for rtgwg@optimus.ietf.org; Mon, 10 May 2004 02:08:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19674 for ; Mon, 10 May 2004 02:07:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN3xF-0004VC-Gn for rtgwg@ietf.org; Mon, 10 May 2004 02:07:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN3w5-00049f-00 for rtgwg@ietf.org; Mon, 10 May 2004 02:06:46 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BN3vD-0003q8-00 for rtgwg@ietf.org; Mon, 10 May 2004 02:05:51 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BN3vE-000Iip-G9; Mon, 10 May 2004 06:05:52 +0000 Date: Sun, 9 May 2004 23:05:51 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1535365092.20040509230551@psg.com> To: Naiming Shen CC: "Joel M. Halpern" , rtgwg@ietf.org Subject: Re: WG Last Call: draft-ietf-rtgwg-igp-shortcut-00.txt In-Reply-To: <200405100555.WAA21010@redback.com> References: Mail from Alex Zinin dated Sun, 09 May 2004 11:53:59 PDT <1342466946.20040509115359@psg.com> <200405100555.WAA21010@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks a lot, Naiming! -- Alex http://www.psg.com/~zinin/ Sunday, May 9, 2004, 10:55:52 PM, Naiming Shen wrote: > Hi Alex, > ] Naiming, > ] > ] How much time do you need to revise the doc? > ] > I'm on a trip next week, will try to address this in the following > week. So will be around two weeks time and hope that's cool. > thanks. > ] Regards. > ] > ] -- > ] Alex > ] http://www.psg.com/~zinin/ > ] > ] Thursday, May 6, 2004, 6:35:09 PM, Naiming Shen wrote: > ] > ] > Joel, > ] > ] > thanks so much for the detailed comments. will try to incorporate them > ] > into the draft. > ] > ] > Regards. > ] > ] > ] > - Naiming _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Mon May 10 07:04:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24342 for ; Mon, 10 May 2004 07:04:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8S9-0002vY-FI for rtgwg-archive@odin.ietf.org; Mon, 10 May 2004 06:56:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AAu98r011250 for rtgwg-archive@odin.ietf.org; Mon, 10 May 2004 06:56:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8Rg-0002qI-4l for rtgwg-web-archive@optimus.ietf.org; Mon, 10 May 2004 06:55:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23757 for ; Mon, 10 May 2004 06:55:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN8Rc-0006UX-0g for rtgwg-web-archive@ietf.org; Mon, 10 May 2004 06:55:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN8Qf-0006Br-00 for rtgwg-web-archive@ietf.org; Mon, 10 May 2004 06:54:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BN8Pj-0005sl-00 for rtgwg-web-archive@ietf.org; Mon, 10 May 2004 06:53:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8NC-0002Op-Cj; Mon, 10 May 2004 06:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN8Ly-0002BD-Gx for rtgwg@optimus.ietf.org; Mon, 10 May 2004 06:49:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23516 for ; Mon, 10 May 2004 06:49:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN8Lu-0004g3-BZ for rtgwg@ietf.org; Mon, 10 May 2004 06:49:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN8Kw-0004NK-00 for rtgwg@ietf.org; Mon, 10 May 2004 06:48:42 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BN8KO-00044m-00 for rtgwg@ietf.org; Mon, 10 May 2004 06:48:08 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 10 May 2004 03:47:49 -0700 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i4AAla0Q022111; Mon, 10 May 2004 03:47:37 -0700 (PDT) Received: from cisco.com (dhcp-rea-gp250-64-103-65-193.cisco.com [64.103.65.193]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA29440; Mon, 10 May 2004 11:47:35 +0100 (BST) Message-ID: <409F5DE0.70000@cisco.com> Date: Mon, 10 May 2004 11:48:00 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rtgwg@ietf.org CC: Alex Zinin Subject: Re: Review Call: draft-atlas-ip-local-protect-00.txt as WG item References: <5.1.0.14.2.20040506133242.029dc108@pop.avici.com> <363818486.20040429130509@psg.com> <363818486.20040429130509@psg.com> <5.1.0.14.2.20040506133242.029dc108@pop.avici.com> <5.1.0.14.2.20040507104505.0248f3a0@pop.avici.com> In-Reply-To: <5.1.0.14.2.20040507104505.0248f3a0@pop.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Whilst I agree that the topic of link and node protection in an IP network should be a work item for the IETF, it is premature to accept draft-atlas-ip-local-protect-00.txt as WG item. I believe that there may exist a number of alternate solutions to this problem. I think that we should fully describe the problem and properly explore the alternative solutions before accepting this draft as a WG item. - Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Mon May 10 11:36:22 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11645 for ; Mon, 10 May 2004 11:36:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNChB-0004Jk-48 for rtgwg-archive@odin.ietf.org; Mon, 10 May 2004 11:27:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AFRvrM016597 for rtgwg-archive@odin.ietf.org; Mon, 10 May 2004 11:27:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNCaR-0002XN-5J for rtgwg-web-archive@optimus.ietf.org; Mon, 10 May 2004 11:20:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10855 for ; Mon, 10 May 2004 11:20:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNCaQ-0001bI-9c for rtgwg-web-archive@ietf.org; Mon, 10 May 2004 11:20:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNCZZ-0001Gi-00 for rtgwg-web-archive@ietf.org; Mon, 10 May 2004 11:20:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNCYm-0000vP-00 for rtgwg-web-archive@ietf.org; Mon, 10 May 2004 11:19:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNCTh-0001Lb-2N; Mon, 10 May 2004 11:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNCIv-0007VO-1C for rtgwg@optimus.ietf.org; Mon, 10 May 2004 11:02:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09753 for ; Mon, 10 May 2004 11:02:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNCIs-00032J-D7 for rtgwg@ietf.org; Mon, 10 May 2004 11:02:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNCHt-0002gg-00 for rtgwg@ietf.org; Mon, 10 May 2004 11:01:50 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BNCGv-00022k-00 for rtgwg@ietf.org; Mon, 10 May 2004 11:00:49 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4AEvpm20529; Mon, 10 May 2004 10:57:51 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 May 2004 10:57:52 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60A39E550@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: stbryant@cisco.com, rtgwg@ietf.org Cc: Alex Zinin Subject: RE: Review Call: draft-atlas-ip-local-protect-00.txt as WG item Date: Mon, 10 May 2004 10:57:44 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Stewart > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Monday, May 10, 2004 6:48 AM > > Whilst I agree that the topic of link and node protection > in an IP network should be a work item for the IETF, it > is premature to accept draft-atlas-ip-local-protect-00.txt > as WG item. > > I believe that there may exist a number of alternate > solutions to this problem. I think that we should > fully describe the problem and properly explore > the alternative solutions before accepting this draft > as a WG item. > Please elaborate more on the solutions. Thanks, Don > - Stewart > > > _______________________________________________ > Rtgwg mailing list > Rtgwg@ietf.org > https://www1.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Tue May 11 17:02:20 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25179 for ; Tue, 11 May 2004 17:02:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNe7P-0000Cj-2p for rtgwg-archive@odin.ietf.org; Tue, 11 May 2004 16:44:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BKiplt000781 for rtgwg-archive@odin.ietf.org; Tue, 11 May 2004 16:44:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNe34-0006qv-DW for rtgwg-web-archive@optimus.ietf.org; Tue, 11 May 2004 16:40:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23896 for ; Tue, 11 May 2004 16:40:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNe32-00026b-Fa for rtgwg-web-archive@ietf.org; Tue, 11 May 2004 16:40:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNe22-0001bV-00 for rtgwg-web-archive@ietf.org; Tue, 11 May 2004 16:39:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNe0t-000148-00 for rtgwg-web-archive@ietf.org; Tue, 11 May 2004 16:38:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNdbt-0007EB-C0; Tue, 11 May 2004 16:12:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNdS2-000524-6z for rtgwg@optimus.ietf.org; Tue, 11 May 2004 16:02:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21529 for ; Tue, 11 May 2004 16:02:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNdS0-0000jX-Je for rtgwg@ietf.org; Tue, 11 May 2004 16:02:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNdR8-0000L5-00 for rtgwg@ietf.org; Tue, 11 May 2004 16:01:10 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BNdQV-0007dz-00 for rtgwg@ietf.org; Tue, 11 May 2004 16:00:31 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 11 May 2004 12:05:57 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4BJxvC1028510; Tue, 11 May 2004 12:59:58 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp275.cisco.com [10.61.65.19]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA06600; Tue, 11 May 2004 20:59:55 +0100 (BST) Message-ID: <40A130BB.2070301@cisco.com> Date: Tue, 11 May 2004 20:59:55 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fedyk CC: rtgwg@ietf.org, Alex Zinin Subject: Re: Review Call: draft-atlas-ip-local-protect-00.txt as WG item References: <0D7FC1D8D861D511AEA70002A52CE5E60A39E550@zcard0ke.ca.nortel.com> In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E60A39E550@zcard0ke.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Don Fedyk wrote: > Hi Stewart > > >>-----Original Message----- >>From: Stewart Bryant [mailto:stbryant@cisco.com] >>Sent: Monday, May 10, 2004 6:48 AM >> >>Whilst I agree that the topic of link and node protection >>in an IP network should be a work item for the IETF, it >>is premature to accept draft-atlas-ip-local-protect-00.txt >>as WG item. >> >>I believe that there may exist a number of alternate >>solutions to this problem. I think that we should >>fully describe the problem and properly explore >>the alternative solutions before accepting this draft >>as a WG item. >> > > Please elaborate more on the solutions. > We will submit a draft on our proposals. - Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Tue May 11 19:09:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05014 for ; Tue, 11 May 2004 19:09:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgM9-0002np-JE for rtgwg-archive@odin.ietf.org; Tue, 11 May 2004 19:08:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BN8DFq010773 for rtgwg-archive@odin.ietf.org; Tue, 11 May 2004 19:08:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgJI-0001sx-UY for rtgwg-web-archive@optimus.ietf.org; Tue, 11 May 2004 19:05:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04794 for ; Tue, 11 May 2004 19:05:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNgJF-0004Ia-Nj for rtgwg-web-archive@ietf.org; Tue, 11 May 2004 19:05:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNgIF-0003qr-00 for rtgwg-web-archive@ietf.org; Tue, 11 May 2004 19:04:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNgHD-0003IM-00 for rtgwg-web-archive@ietf.org; Tue, 11 May 2004 19:03:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgDK-0000gO-2Y; Tue, 11 May 2004 18:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNg9f-0008IK-2V for rtgwg@optimus.ietf.org; Tue, 11 May 2004 18:55:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04108 for ; Tue, 11 May 2004 18:55:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNg9b-0007XW-VC for rtgwg@ietf.org; Tue, 11 May 2004 18:55:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNg8g-000736-00 for rtgwg@ietf.org; Tue, 11 May 2004 18:54:18 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BNg7x-0006d0-00 for rtgwg@ietf.org; Tue, 11 May 2004 18:53:33 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNg7x-0009RY-Pz for rtgwg@ietf.org; Tue, 11 May 2004 22:53:33 +0000 Date: Tue, 11 May 2004 15:53:28 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1021346238.20040511155328@psg.com> To: rtgwg@ietf.org Subject: Re: Work on IP fast rerouting in IGPs In-Reply-To: <1625160134.20040429124240@psg.com> References: <20040422234321.GA29149@1-4-5.net> <1625160134.20040429124240@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks- Thursday, April 29, 2004, 12:42:40 PM, Alex Zinin wrote: ... > I also sense that it will be useful to produce a framework kind of document > explaining what we're talking about and how different pieces of technology fit > together. I would be fine with this, provided that it will be a lean and crisp > document that we can finish within months, and someone commits to take an > active (I mean really active) lead on this. FYI, Mike Shand volunteered to work on such document and submit the first version within a couple of week. I asked Mike to produce a very laconic and precise document roughly along the following lines: > 1. Introduction > - brief problem definition and scoping > - brief description of the desired results > > 2. Problem Analysis > > -components of network rerouting time today (detection, local reaction, > network-wide topology update, route recalculation, fib update) > > 3. Mechanism for IP fast-reroute > > - mechanisms for fast detection (link-layer, fast Hellos, BFD) > > - node-local reaction before network-wide reconvergence > > - FIB update--implementation-specific Once Mike has something ready, we'll let the list know. Thanks, Mike! Alex _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Thu May 13 14:37:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04219 for ; Thu, 13 May 2004 14:37:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOKzB-00084N-8G for rtgwg-archive@odin.ietf.org; Thu, 13 May 2004 14:31:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DIVDq8031019 for rtgwg-archive@odin.ietf.org; Thu, 13 May 2004 14:31:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOKmZ-0001ps-UQ for rtgwg-web-archive@optimus.ietf.org; Thu, 13 May 2004 14:18:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01570 for ; Thu, 13 May 2004 14:18:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOKmX-0000c7-E5 for rtgwg-web-archive@ietf.org; Thu, 13 May 2004 14:18:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOKjn-00070w-00 for rtgwg-web-archive@ietf.org; Thu, 13 May 2004 14:15:19 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BOKhm-0005mC-00 for rtgwg-web-archive@ietf.org; Thu, 13 May 2004 14:13:14 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BOKXH-0006xj-PZ for rtgwg-web-archive@ietf.org; Thu, 13 May 2004 14:02:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOJz7-0005eI-Iw; Thu, 13 May 2004 13:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOJb8-0004xa-Ki for rtgwg@optimus.ietf.org; Thu, 13 May 2004 13:02:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23650 for ; Thu, 13 May 2004 13:02:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOJb6-0007hh-Pe for rtgwg@ietf.org; Thu, 13 May 2004 13:02:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOJaB-0007Aw-00 for rtgwg@ietf.org; Thu, 13 May 2004 13:01:19 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BOJZW-0006dr-00 for rtgwg@ietf.org; Thu, 13 May 2004 13:00:38 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOJZV-0009Xd-Gz for rtgwg@ietf.org; Thu, 13 May 2004 17:00:37 +0000 Date: Thu, 13 May 2004 10:00:35 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <414681324.20040513100035@psg.com> To: rtgwg@ietf.org Subject: Re: Review Call: draft-atlas-ip-local-protect-00.txt as WG item In-Reply-To: <40A130BB.2070301@cisco.com> References: <0D7FC1D8D861D511AEA70002A52CE5E60A39E550@zcard0ke.ca.nortel.com> <40A130BB.2070301@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks- Based on the feedback we got on the list and I got unicast, making draft-atlas-ip-local-protect-00.txt as a whole a WG item would be premature. On the other hand, I believe we need to make progress on this topic. I suggest that we do the following: 1. I believe that we have a pretty good understanding on what the _basic_ IP FRR mechanism should be: vanilla loop-free feasible next-hops (what is called "loop-free alternates" in Alia's document, or "downstream paths" in 10589, I believe), no U-turns-like optimizations, simple and safe. I think we shouldn't spend a lot of time on this topic, just write the spec. 2. Advanced methods is where I see the field for play: U-turns, what Mike and Stewart have, etc. Here we can take more time to discuss and see which direction we want to go long-term. Note that I think these SHOULD NOT be part of the basic spec, but rather separate document(s). 3. Alia's draft covers both the basic mechanism, and U-turns. Other folks are coming up with more drafts. My recommendation to Alia would be to move U-turns to a separate draft and revise the main draft to talk about the basic mechanism only. It seems that the draft would then have a good chance of becoming a WG item. My recommendation to others would be to submit their [advanced] proposals reasonably soon--I'd like us to have the first review of the available methods in San Diego and complete the selection process by the DC meeting. Opinions are welcome. -- Alex _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Fri May 14 09:07:04 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19730 for ; Fri, 14 May 2004 09:07:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOcJM-00064D-2h for rtgwg-archive@odin.ietf.org; Fri, 14 May 2004 09:01:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ED1CQ6023322 for rtgwg-archive@odin.ietf.org; Fri, 14 May 2004 09:01:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOcEU-00055I-4D for rtgwg-web-archive@optimus.ietf.org; Fri, 14 May 2004 08:56:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19257 for ; Fri, 14 May 2004 08:56:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOcES-0004cg-Gx for rtgwg-web-archive@ietf.org; Fri, 14 May 2004 08:56:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOcDd-00047l-00 for rtgwg-web-archive@ietf.org; Fri, 14 May 2004 08:55:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOcCm-0003ca-00 for rtgwg-web-archive@ietf.org; Fri, 14 May 2004 08:54:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOc8a-0003vZ-HX; Fri, 14 May 2004 08:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOc4j-00035A-Ji for rtgwg@optimus.ietf.org; Fri, 14 May 2004 08:46:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18601 for ; Fri, 14 May 2004 08:46:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOc4i-0007Nb-8Z for rtgwg@ietf.org; Fri, 14 May 2004 08:46:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOc3s-0006t4-00 for rtgwg@ietf.org; Fri, 14 May 2004 08:45:13 -0400 Received: from [208.246.215.201] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 1BOc37-0006GP-00 for rtgwg@ietf.org; Fri, 14 May 2004 08:44:25 -0400 Received: from aatlas-lt2.avici.com (b2vpn2pc170.avici.com [10.2.104.170]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i4EChhcu022466; Fri, 14 May 2004 08:43:43 -0400 Message-Id: <5.1.0.14.2.20040514083932.01d72770@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 14 May 2004 08:43:51 -0400 To: Alex Zinin From: Alia Atlas Subject: Re: Review Call: draft-atlas-ip-local-protect-00.txt as WG item Cc: rtgwg@ietf.org In-Reply-To: <414681324.20040513100035@psg.com> References: <40A130BB.2070301@cisco.com> <0D7FC1D8D861D511AEA70002A52CE5E60A39E550@zcard0ke.ca.nortel.com> <40A130BB.2070301@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 01:00 PM 5/13/2004, Alex Zinin wrote: > 3. Alia's draft covers both the basic mechanism, and U-turns. Other > folks are > coming up with more drafts. > > My recommendation to Alia would be to move U-turns to a separate > draft and > revise the main draft to talk about the basic mechanism only. It > seems that > the draft would then have a good chance of becoming a WG item. I'll break up the draft, move the U-turns to a separate document, and submit a revised draft on the basic loop-free feasible alternates. > My recommendation to others would be to submit their [advanced] > proposals > reasonably soon--I'd like us to have the first review of the available > methods in San Diego and complete the selection process by the DC > meeting. Yes, I'd very much like to start discussing U-turn alternates and whatever alternatives that Stewart is planning on describing. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Thu May 20 18:03:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29675 for ; Thu, 20 May 2004 18:03:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvb4-0002SY-3a for rtgwg-archive@odin.ietf.org; Thu, 20 May 2004 18:01:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KM12gp009444 for rtgwg-archive@odin.ietf.org; Thu, 20 May 2004 18:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvYA-0000eM-Jf for rtgwg-web-archive@optimus.ietf.org; Thu, 20 May 2004 17:58:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29127 for ; Thu, 20 May 2004 17:57:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQvY8-0003nC-0Z for rtgwg-web-archive@ietf.org; Thu, 20 May 2004 17:58:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQvWG-0003iw-00 for rtgwg-web-archive@ietf.org; Thu, 20 May 2004 17:56:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQvVl-0003gD-00 for rtgwg-web-archive@ietf.org; Thu, 20 May 2004 17:55:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvKu-0003w0-Cg; Thu, 20 May 2004 17:44:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQv8y-0007D8-QP for rtgwg@optimus.ietf.org; Thu, 20 May 2004 17:32:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27307 for ; Thu, 20 May 2004 17:31:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQv8w-0001ho-BZ for rtgwg@ietf.org; Thu, 20 May 2004 17:31:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQv6v-0001LB-00 for rtgwg@ietf.org; Thu, 20 May 2004 17:29:54 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BQv3F-0000od-00 for rtgwg@ietf.org; Thu, 20 May 2004 17:26:05 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQv3D-000ONC-Em for rtgwg@ietf.org; Thu, 20 May 2004 21:26:05 +0000 Date: Thu, 20 May 2004 14:25:46 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1149488005.20040520142546@psg.com> To: rtgwg@ietf.org Subject: Charter milestones for IP FRR MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks- Below's the list of IP FRR-related items to be added to the WG charter that I'll be sending to the IESG. Please see if the dates make sense to you. MAY 2004 Submit initial Internet Draft on IP Fast Reroute framework APR 2004 Submit initial Internet Draft on Basic IP Fast Reroute mechanism AUG 2004 Review various mechanisms for Advanced IP Fast Reroute OCT 2004 Submit specification on Basic IP Fast Reroute mechanism to IESG for publication as Proposed Standard NOV 2004 Select the Advanced IP Fast Reroute mechanism MAY 2005 Submit specification on Advanced IP Fast Reroute mechanism to IESG for publication as Proposed Standard -- Alex http://www.psg.com/~zinin/ _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Thu May 20 18:13:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01226 for ; Thu, 20 May 2004 18:13:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvhq-0007Bx-Qi for rtgwg-archive@odin.ietf.org; Thu, 20 May 2004 18:08:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KM82Zj027639 for rtgwg-archive@odin.ietf.org; Thu, 20 May 2004 18:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvbE-0002ch-RN for rtgwg-web-archive@optimus.ietf.org; Thu, 20 May 2004 18:01:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29423 for ; Thu, 20 May 2004 18:01:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQvbC-00042H-5l for rtgwg-web-archive@ietf.org; Thu, 20 May 2004 18:01:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQvaA-0003yW-00 for rtgwg-web-archive@ietf.org; Thu, 20 May 2004 18:00:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQvZb-0003vR-00 for rtgwg-web-archive@ietf.org; Thu, 20 May 2004 17:59:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvOT-0006ER-UW; Thu, 20 May 2004 17:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvBX-0008F1-Bc for rtgwg@optimus.ietf.org; Thu, 20 May 2004 17:34:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27544 for ; Thu, 20 May 2004 17:34:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQvBU-00020G-UB for rtgwg@ietf.org; Thu, 20 May 2004 17:34:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQvAL-0001re-00 for rtgwg@ietf.org; Thu, 20 May 2004 17:33:26 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BQv8r-0001h3-00 for rtgwg@ietf.org; Thu, 20 May 2004 17:31:53 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQv8n-000PG8-Ne for rtgwg@ietf.org; Thu, 20 May 2004 21:31:53 +0000 Date: Thu, 20 May 2004 14:31:30 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <69369195.20040520143130@psg.com> To: rtgwg@ietf.org Subject: GTSM to STD track? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks- Dave and I talked about putting a revision of GTSH on STD tracks as a DoS-prevention mechanism. I'd like to know what folks in the WG think about this idea. Yes/No/"what's STD tracks"? -- Alex http://www.psg.com/~zinin/ _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Fri May 21 00:43:18 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20123 for ; Fri, 21 May 2004 00:43:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR1n8-0007EV-Ox for rtgwg-archive@odin.ietf.org; Fri, 21 May 2004 00:37:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L4bskQ027780 for rtgwg-archive@odin.ietf.org; Fri, 21 May 2004 00:37:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR1if-00060U-11 for rtgwg-web-archive@optimus.ietf.org; Fri, 21 May 2004 00:33:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19887 for ; Fri, 21 May 2004 00:33:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR1ic-0006O9-H6 for rtgwg-web-archive@ietf.org; Fri, 21 May 2004 00:33:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR1hf-0006I4-00 for rtgwg-web-archive@ietf.org; Fri, 21 May 2004 00:32:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR1hD-0006CB-00 for rtgwg-web-archive@ietf.org; Fri, 21 May 2004 00:31:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR1ag-0004RR-OM; Fri, 21 May 2004 00:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR1X1-0003Xl-83 for rtgwg@optimus.ietf.org; Fri, 21 May 2004 00:21:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19110 for ; Fri, 21 May 2004 00:21:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR1Wy-0004tB-P6 for rtgwg@ietf.org; Fri, 21 May 2004 00:21:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR1W3-0004lk-00 for rtgwg@ietf.org; Fri, 21 May 2004 00:20:15 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BR1VF-0004W9-00 for rtgwg@ietf.org; Fri, 21 May 2004 00:19:26 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4L4Iml20811; Fri, 21 May 2004 07:18:48 +0300 Date: Fri, 21 May 2004 07:18:48 +0300 (EEST) From: Pekka Savola To: Alex Zinin cc: rtgwg@ietf.org Subject: Re: Charter milestones for IP FRR In-Reply-To: <1149488005.20040520142546@psg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 20 May 2004, Alex Zinin wrote: > Below's the list of IP FRR-related items to be added to the WG charter that I'll > be sending to the IESG. Please see if the dates make sense to you. > > MAY 2004 Submit initial Internet Draft on IP Fast Reroute framework > > APR 2004 Submit initial Internet Draft on Basic IP Fast Reroute mechanism This should probably be May? > MAY 2005 Submit specification on Advanced IP Fast Reroute mechanism to > IESG for publication as Proposed Standard We might also want to consider whether one or both of these should go to experimental. But that's probably something to think about when we have a better idea of what we're talking about.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Fri May 21 00:43:18 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20139 for ; Fri, 21 May 2004 00:43:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR1n8-0007EX-Q0 for rtgwg-archive@odin.ietf.org; Fri, 21 May 2004 00:37:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L4bsPK027798 for rtgwg-archive@odin.ietf.org; Fri, 21 May 2004 00:37:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR1ih-00060d-Q6 for rtgwg-web-archive@optimus.ietf.org; Fri, 21 May 2004 00:33:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19890 for ; Fri, 21 May 2004 00:33:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR1if-0006OK-8n for rtgwg-web-archive@ietf.org; Fri, 21 May 2004 00:33:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR1hi-0006IR-00 for rtgwg-web-archive@ietf.org; Fri, 21 May 2004 00:32:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR1hL-0006CH-00 for rtgwg-web-archive@ietf.org; Fri, 21 May 2004 00:31:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR1ah-0004Rh-Hf; Fri, 21 May 2004 00:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR1Xs-0003bA-6y for rtgwg@optimus.ietf.org; Fri, 21 May 2004 00:22:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19164 for ; Fri, 21 May 2004 00:22:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR1Xp-0004z4-Nt for rtgwg@ietf.org; Fri, 21 May 2004 00:22:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR1Wr-0004sF-00 for rtgwg@ietf.org; Fri, 21 May 2004 00:21:05 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BR1Vs-0004d1-00 for rtgwg@ietf.org; Fri, 21 May 2004 00:20:05 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4L4JT920818; Fri, 21 May 2004 07:19:29 +0300 Date: Fri, 21 May 2004 07:19:29 +0300 (EEST) From: Pekka Savola To: Alex Zinin cc: rtgwg@ietf.org Subject: Re: GTSM to STD track? In-Reply-To: <69369195.20040520143130@psg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 20 May 2004, Alex Zinin wrote: > Dave and I talked about putting a revision of GTSH on STD tracks as a > DoS-prevention mechanism. I'd like to know what folks in the WG think about > this idea. Yes/No/"what's STD tracks"? Definitely for STDs track, especially as it has to be revised in any case ASAP! -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Fri May 21 13:23:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16292 for ; Fri, 21 May 2004 13:23:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRDeA-0006X3-Og for rtgwg-archive@odin.ietf.org; Fri, 21 May 2004 13:17:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LHHQ3F025110 for rtgwg-archive@odin.ietf.org; Fri, 21 May 2004 13:17:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRDXb-00053w-9K for rtgwg-web-archive@optimus.ietf.org; Fri, 21 May 2004 13:10:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15825 for ; Fri, 21 May 2004 13:10:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRDXZ-00055Q-EY for rtgwg-web-archive@ietf.org; Fri, 21 May 2004 13:10:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRDWc-00050P-00 for rtgwg-web-archive@ietf.org; Fri, 21 May 2004 13:09:39 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BRDVn-0004us-00 for rtgwg-web-archive@ietf.org; Fri, 21 May 2004 13:08:47 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BRDVo-0001L1-Vi for rtgwg-web-archive@ietf.org; Fri, 21 May 2004 13:08:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRDML-0001mO-5H; Fri, 21 May 2004 12:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRDGC-0000hc-3l for rtgwg@optimus.ietf.org; Fri, 21 May 2004 12:52:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14755 for ; Fri, 21 May 2004 12:52:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRDGA-0003lK-Cv for rtgwg@ietf.org; Fri, 21 May 2004 12:52:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRDFG-0003ij-00 for rtgwg@ietf.org; Fri, 21 May 2004 12:51:43 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1BRDEN-0003g7-00 for rtgwg@ietf.org; Fri, 21 May 2004 12:50:47 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6975941; Fri, 21 May 2004 12:50:46 -0400 Message-Id: <5.1.0.14.0.20040520181521.02400630@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 21 May 2004 12:50:24 -0400 To: Alex Zinin , rtgwg@ietf.org From: "Joel M. Halpern" Subject: Re: GTSM to STD track? In-Reply-To: <69369195.20040520143130@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Assuming that the operational folks agree that this is as good an idea as it appears (which is rather supported by the operational background of the authors), I would support some form of standardization for GTSM. Looking at the draft, it looks to me like a better candidate for BCP than for Proposed Standard. Given that the on-the-wire behavior of the protocols is not changed (one of the positive features of this approach) it would be awkward to describe it as a proposed standard protocol. Yours, Joel M. Halpern At 02:31 PM 5/20/2004 -0700, Alex Zinin wrote: >Folks- > > Dave and I talked about putting a revision of GTSM on STD tracks as a > DoS-prevention mechanism. I'd like to know what folks in the WG think about > this idea. Yes/No/"what's STD tracks"? > >-- >Alex >http://www.psg.com/~zinin/ > > >_______________________________________________ >Rtgwg mailing list >Rtgwg@ietf.org >https://www1.ietf.org/mailman/listinfo/rtgwg _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Fri May 21 14:24:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19649 for ; Fri, 21 May 2004 14:24:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREdn-0004Dd-Bc for rtgwg-archive@odin.ietf.org; Fri, 21 May 2004 14:21:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LIL71o016212 for rtgwg-archive@odin.ietf.org; Fri, 21 May 2004 14:21:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRETm-00025M-NN for rtgwg-web-archive@optimus.ietf.org; Fri, 21 May 2004 14:10:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18976 for ; Fri, 21 May 2004 14:10:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRETk-0001R1-7F for rtgwg-web-archive@ietf.org; Fri, 21 May 2004 14:10:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRESp-0001Lw-00 for rtgwg-web-archive@ietf.org; Fri, 21 May 2004 14:09:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRERu-0001IE-00 for rtgwg-web-archive@ietf.org; Fri, 21 May 2004 14:08:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREJc-0007vl-Om; Fri, 21 May 2004 14:00:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRECB-0006Hy-2w for rtgwg@optimus.ietf.org; Fri, 21 May 2004 13:52:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17917 for ; Fri, 21 May 2004 13:52:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BREC8-0007nc-IZ for rtgwg@ietf.org; Fri, 21 May 2004 13:52:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BREBA-0007kV-00 for rtgwg@ietf.org; Fri, 21 May 2004 13:51:32 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1BREAC-0007f2-00 for rtgwg@ietf.org; Fri, 21 May 2004 13:50:33 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i4LHo2Y3013930; Fri, 21 May 2004 10:50:02 -0700 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) with ESMTP id i4LHo1nT013923; Fri, 21 May 2004 10:50:01 -0700 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Fri, 21 May 2004 10:50:01 -0700 (PDT) From: Tony Tauber To: "Joel M. Halpern" cc: Alex Zinin , rtgwg@ietf.org Subject: Re: GTSM to STD track? In-Reply-To: <5.1.0.14.0.20040520181521.02400630@localhost> Message-ID: References: <5.1.0.14.0.20040520181521.02400630@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Fri, 21 May 2004, Joel M. Halpern wrote: > > At 02:31 PM 5/20/2004 -0700, Alex Zinin wrote: > >Folks- > > > > Dave and I talked about putting a revision of GTSM on STD tracks > > as a DoS-prevention mechanism. I'd like to know what folks in the > > WG think about this idea. Yes/No/"what's STD tracks"? > > Assuming that the operational folks agree that this is as good an > idea as it appears (which is rather supported by the operational > background of the authors), I would support some form of > standardization for GTSM. Looking at the draft, it looks to me like > a better candidate for BCP than for Proposed Standard. Given that > the on-the-wire behavior of the protocols is not changed (one of the > positive features of this approach) it would be awkward to describe > it as a proposed standard protocol. > > Yours, > Joel M. Halpern Yes, I'm also not sure what kind of Standard it would be. It's not a protocol and I'm not sure there are interoperability ramifications or not (would depend on the specifics, I guess.) Pehaps a BCP to operators and implementors and guidance to designers of future protocols? Tony _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Fri May 21 14:48:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21144 for ; Fri, 21 May 2004 14:48:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREzR-0000pM-Gf for rtgwg-archive@odin.ietf.org; Fri, 21 May 2004 14:43:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LIhTNu003167 for rtgwg-archive@odin.ietf.org; Fri, 21 May 2004 14:43:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREpD-0006vd-Hz for rtgwg-web-archive@optimus.ietf.org; Fri, 21 May 2004 14:32:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20207 for ; Fri, 21 May 2004 14:32:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BREpA-00037z-Vj for rtgwg-web-archive@ietf.org; Fri, 21 May 2004 14:32:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BREnj-0002yS-00 for rtgwg-web-archive@ietf.org; Fri, 21 May 2004 14:31:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BREli-0002pe-00 for rtgwg-web-archive@ietf.org; Fri, 21 May 2004 14:29:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREgf-0005Ck-2l; Fri, 21 May 2004 14:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BREbi-0003hZ-LP for rtgwg@optimus.ietf.org; Fri, 21 May 2004 14:18:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19415 for ; Fri, 21 May 2004 14:18:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BREbg-0002Af-4m for rtgwg@ietf.org; Fri, 21 May 2004 14:18:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BREap-00026H-00 for rtgwg@ietf.org; Fri, 21 May 2004 14:18:04 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BREaI-00020O-00 for rtgwg@ietf.org; Fri, 21 May 2004 14:17:30 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id DEDAD2D4847; Fri, 21 May 2004 14:17:00 -0400 (EDT) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09665-02-44; Fri, 21 May 2004 14:16:49 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9849B2D487B; Fri, 21 May 2004 14:16:49 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i4LIGkA24404; Fri, 21 May 2004 14:16:46 -0400 (EDT) Date: Fri, 21 May 2004 14:16:46 -0400 From: Jeffrey Haas To: Tony Tauber Cc: "Joel M. Halpern" , Alex Zinin , rtgwg@ietf.org Subject: Re: GTSM to STD track? Message-ID: <20040521181646.GA18957@nexthop.com> References: <5.1.0.14.0.20040520181521.02400630@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, May 21, 2004 at 10:50:01AM -0700, Tony Tauber wrote: > Yes, I'm also not sure what kind of Standard it would be. > It's not a protocol and I'm not sure there are interoperability > ramifications or not (would depend on the specifics, I guess.) In a sense it is a protocol extension to IPv4/v6. It might even be worth having those groups review this. The main interoperability issue is that if you configure this on a host to communicate with another host that doesn't support the feature you may send the packets *much* farther than you otherwise might, especially when communicating with non directly connected hosts. > Tony -- Jeff Haas NextHop Technologies _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Sat May 22 02:36:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15532 for ; Sat, 22 May 2004 02:36:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRPzw-00046W-1E for rtgwg-archive@odin.ietf.org; Sat, 22 May 2004 02:28:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4M6ShDp015777 for rtgwg-archive@odin.ietf.org; Sat, 22 May 2004 02:28:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRPxR-0003fn-Bb for rtgwg-web-archive@optimus.ietf.org; Sat, 22 May 2004 02:26:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14877 for ; Sat, 22 May 2004 02:26:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRPxN-0002h8-9C for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 02:26:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRPwP-0002Z0-00 for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 02:25:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRPw2-0002S7-00 for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 02:24:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRPoe-0001W6-A3; Sat, 22 May 2004 02:17:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRPkE-0008TF-D3 for rtgwg@optimus.ietf.org; Sat, 22 May 2004 02:12:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12816 for ; Sat, 22 May 2004 02:12:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRPkA-00014e-QT for rtgwg@ietf.org; Sat, 22 May 2004 02:12:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRPj8-0000w1-00 for rtgwg@ietf.org; Sat, 22 May 2004 02:11:23 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BRPiM-0000my-00 for rtgwg@ietf.org; Sat, 22 May 2004 02:10:34 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRPiK-0005bx-Ig; Sat, 22 May 2004 06:10:32 +0000 Date: Fri, 21 May 2004 23:10:31 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <6110631371.20040521231031@psg.com> To: Jeffrey Haas CC: Tony Tauber , "Joel M. Halpern" , Subject: Re: GTSM to STD track? In-Reply-To: <20040521181646.GA18957@nexthop.com> References: <5.1.0.14.0.20040520181521.02400630@localhost> <20040521181646.GA18957@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit To add to Jeff's points: We do change bits on the wire (TTL setting) and the input packet processing rules (packet discrimination, ICMP generation.) As an interop-related ramification, following or not following the spec will also affect: a) whether the receiving side (using GTSM) accepts your packets with TTL < 255, or (in the extreme case) drops them on the floor, AND: b) whether the GSTM-enabled side can expect the other side to cooperate and hence whether a certain level of DoS protection can be assumed. Joel, Tony, does this make sense? At the end of the day, the question is: "Is GTSM an important enough DoS prevention mechanism for the IETF to have Standard on it?" That said, if we decide to put it on the STD track, we will certainly need to review the document with the STD glasses on and see what changes would be needed. -- Alex Friday, May 21, 2004, 11:16:46 AM, Jeffrey Haas wrote: > On Fri, May 21, 2004 at 10:50:01AM -0700, Tony Tauber wrote: >> Yes, I'm also not sure what kind of Standard it would be. >> It's not a protocol and I'm not sure there are interoperability >> ramifications or not (would depend on the specifics, I guess.) > In a sense it is a protocol extension to IPv4/v6. It might even > be worth having those groups review this. > The main interoperability issue is that if you configure this on > a host to communicate with another host that doesn't support the feature > you may send the packets *much* farther than you otherwise might, especially > when communicating with non directly connected hosts. >> Tony _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Sat May 22 02:47:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15790 for ; Sat, 22 May 2004 02:47:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRQ7w-0005c1-DS for rtgwg-archive@odin.ietf.org; Sat, 22 May 2004 02:37:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4M6b0Ch021570 for rtgwg-archive@odin.ietf.org; Sat, 22 May 2004 02:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRQ1K-0004W6-5F for rtgwg-web-archive@optimus.ietf.org; Sat, 22 May 2004 02:30:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15127 for ; Sat, 22 May 2004 02:30:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRQ1F-0003EG-BL for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 02:30:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRQ0I-00034p-00 for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 02:29:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRPzb-0002xg-00 for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 02:28:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRPxK-0003cZ-9Q; Sat, 22 May 2004 02:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRPqW-0001ub-Ty for rtgwg@optimus.ietf.org; Sat, 22 May 2004 02:19:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14417 for ; Sat, 22 May 2004 02:18:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRPqT-0001vG-At for rtgwg@ietf.org; Sat, 22 May 2004 02:18:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRPpW-0001ns-00 for rtgwg@ietf.org; Sat, 22 May 2004 02:17:59 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BRPob-0001fi-00 for rtgwg@ietf.org; Sat, 22 May 2004 02:17:02 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRPoc-0006qW-Vz; Sat, 22 May 2004 06:17:03 +0000 Date: Fri, 21 May 2004 23:17:01 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <8310518438.20040521231701@psg.com> To: Pekka Savola CC: rtgwg@ietf.org Subject: Re: Charter milestones for IP FRR In-Reply-To: References: <1149488005.20040520142546@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for looking at this, Pekka! >> APR 2004 Submit initial Internet Draft on Basic IP Fast Reroute mechanism > This should probably be May? Actually, even June, I think. Thanks for catching. >> MAY 2005 Submit specification on Advanced IP Fast Reroute mechanism to >> IESG for publication as Proposed Standard > We might also want to consider whether one or both of these should go > to experimental. But that's probably something to think about when we > have a better idea of what we're talking about.. Yes. The last one is more of a goal we should ultimately aim for. As we go through the discussion, we'll adjust the actual milestones. Here's the new milestones: MAY 2004 Submit initial Internet Draft on IP Fast Reroute framework JUN 2004 Submit initial Internet Draft on Basic IP Fast Reroute mechanism AUG 2004 Review various mechanisms for Advanced IP Fast Reroute OCT 2004 Submit specification on Basic IP Fast Reroute mechanism to IESG for publication as Proposed Standard NOV 2004 Select the Advanced IP Fast Reroute mechanism MAY 2005 Submit specification on Advanced IP Fast Reroute mechanism to IESG for publication as Proposed Standard Alex _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Sat May 22 03:25:07 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17917 for ; Sat, 22 May 2004 03:25:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRQl2-0005RS-Vn for rtgwg-archive@odin.ietf.org; Sat, 22 May 2004 03:17:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4M7HOkc020911 for rtgwg-archive@odin.ietf.org; Sat, 22 May 2004 03:17:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRQZD-0002x1-LJ for rtgwg-web-archive@optimus.ietf.org; Sat, 22 May 2004 03:05:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17123 for ; Sat, 22 May 2004 03:04:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRQYY-0000E0-2X for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 03:04:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRQXL-0007kj-00 for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 03:03:16 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BRQWA-0007No-00 for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 03:02:02 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BRQIU-0001Q2-S8 for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 02:47:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRQ7x-0005dW-Rw; Sat, 22 May 2004 02:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRQ1G-0004Vj-Tg for rtgwg@optimus.ietf.org; Sat, 22 May 2004 02:30:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15120 for ; Sat, 22 May 2004 02:30:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRQ1C-0003CP-EB for rtgwg@ietf.org; Sat, 22 May 2004 02:30:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRQ0F-00034S-00 for rtgwg@ietf.org; Sat, 22 May 2004 02:29:03 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BRPzN-0002xZ-00 for rtgwg@ietf.org; Sat, 22 May 2004 02:28:09 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRPzO-0008gg-Mq for rtgwg@ietf.org; Sat, 22 May 2004 06:28:10 +0000 Date: Fri, 21 May 2004 23:28:09 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <12168157.20040521232809@psg.com> To: rtgwg@ietf.org Subject: draft-shand-ipfrr-framework-00.txt as a WG document In-Reply-To: <200405211949.PAA25452@ietf.org> References: <200405211949.PAA25452@ietf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------3B1636E200327EF" Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 ------------3B1636E200327EF Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Folks- Mike wrote the first draft of the IP FRR framework that was mentioned earlier. I've reviewed the draft, believe that it is very well written, and serves the purpose as the basis for the corresponding work item. I suggest that this document becomes a WG item with Mike as the editor. Please send your comments within two weeks (by June 4th, 2004.) -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: Date: Friday, May 21, 2004, 12:49:42 PM Subject: I-D ACTION:draft-shand-ipfrr-framework-00.txt ===8<==============Original message text=============== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Fast Reroute Framework Author(s) : M. Shand Filename : draft-shand-ipfrr-framework-00.txt Pages : 8 Date : 2004-5-21 This document provides a framework for the development of IP fast re- route mechanisms which provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS Fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. An essential part of such mechanisms is the prevention of packet loss caused by the loops which normally occur during the re-convergence of the network following a failure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shand-ipfrr-framework-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shand-ipfrr-framework-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shand-ipfrr-framework-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ===8<===========End of original message text=========== ------------3B1636E200327EF Content-Type: MESSAGE/EXTERNAL-BODY; name="1.msg" Content-Disposition: attachment; filename="1.msg" Content-Transfer-Encoding: 8bit Content-Type: text/plain Content-ID: <2004-5-21155556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shand-ipfrr-framework-00.txt ------------3B1636E200327EF Content-Type: MESSAGE/EXTERNAL-BODY; name="draft-shand-ipfrr-framework-00.txt" Content-Disposition: attachment; filename="draft-shand-ipfrr-framework-00.txt" Content-Transfer-Encoding: 8bit Content-Type: text/plain Content-ID: <2004-5-21155556.I-D@ietf.org> ------------3B1636E200327EF-- _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Sat May 22 03:25:37 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17956 for ; Sat, 22 May 2004 03:25:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRQl3-0005Rd-2u for rtgwg-archive@odin.ietf.org; Sat, 22 May 2004 03:17:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4M7HOQL020912 for rtgwg-archive@odin.ietf.org; Sat, 22 May 2004 03:17:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRQZD-0002x3-Mq for rtgwg-web-archive@optimus.ietf.org; Sat, 22 May 2004 03:05:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17114 for ; Sat, 22 May 2004 03:04:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRQYV-0000Da-B4 for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 03:04:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRQXI-0007kD-00 for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 03:03:13 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BRQWA-0007NT-00 for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 03:02:03 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BRQIL-0001O4-Ro for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 02:47:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRQ7x-0005d0-8Z; Sat, 22 May 2004 02:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRQ0I-0004D0-HP for rtgwg@optimus.ietf.org; Sat, 22 May 2004 02:29:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15109 for ; Sat, 22 May 2004 02:29:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRQ0E-00034N-T7 for rtgwg@ietf.org; Sat, 22 May 2004 02:29:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRPzI-0002xS-00 for rtgwg@ietf.org; Sat, 22 May 2004 02:28:05 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1BRPya-0002q9-00 for rtgwg@ietf.org; Sat, 22 May 2004 02:27:20 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6978138 for rtgwg@ietf.org; Sat, 22 May 2004 02:27:07 -0400 Message-Id: <5.1.0.14.0.20040522022245.022bc3e0@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 22 May 2004 02:27:04 -0400 To: From: "Joel M. Halpern" Subject: Re: GTSM to STD track? In-Reply-To: <6110631371.20040521231031@psg.com> References: <20040521181646.GA18957@nexthop.com> <5.1.0.14.0.20040520181521.02400630@localhost> <20040521181646.GA18957@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I will admit that we are regularly fuzzy about what constitutes suitability for PS vs BCP. I do not think we should use "important enough" as a measure for whether it is PS. Some very important pieces have ended up BCP. I have trouble seeing the setting of an existing field to an existing valid value as a protocol change. This is advice on configuration. Particularly since the way it is used depends upon the particularly topological placement of the communicating peers. It sure seems to be good advice. And if you really feel strongly that it is important to make it PS, I won't scream during last call. I just think it is better suited to BCP. Yours, Joel M. Halpern At 11:10 PM 5/21/2004 -0700, Alex Zinin wrote: >To add to Jeff's points: > >We do change bits on the wire (TTL setting) and the input packet processing >rules (packet discrimination, ICMP generation.) > >As an interop-related ramification, following or not following the spec will >also affect: > > a) whether the receiving side (using GTSM) accepts your packets with TTL > < 255, > or (in the extreme case) drops them on the floor, AND: > > b) whether the GSTM-enabled side can expect the other side to cooperate and > hence whether a certain level of DoS protection can be assumed. > >Joel, Tony, does this make sense? > >At the end of the day, the question is: "Is GTSM an important enough DoS >prevention mechanism for the IETF to have Standard on it?" > >That said, if we decide to put it on the STD track, we will certainly need to >review the document with the STD glasses on and see what changes would be >needed. > >-- >Alex > >Friday, May 21, 2004, 11:16:46 AM, Jeffrey Haas wrote: > > On Fri, May 21, 2004 at 10:50:01AM -0700, Tony Tauber wrote: > >> Yes, I'm also not sure what kind of Standard it would be. > >> It's not a protocol and I'm not sure there are interoperability > >> ramifications or not (would depend on the specifics, I guess.) > > > In a sense it is a protocol extension to IPv4/v6. It might even > > be worth having those groups review this. > > > The main interoperability issue is that if you configure this on > > a host to communicate with another host that doesn't support the feature > > you may send the packets *much* farther than you otherwise might, > especially > > when communicating with non directly connected hosts. > > >> Tony _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Sat May 22 05:56:27 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24175 for ; Sat, 22 May 2004 05:56:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRT9c-0007CP-9A for rtgwg-archive@odin.ietf.org; Sat, 22 May 2004 05:50:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4M9oucA027669 for rtgwg-archive@odin.ietf.org; Sat, 22 May 2004 05:50:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRT2T-00062x-4s for rtgwg-web-archive@optimus.ietf.org; Sat, 22 May 2004 05:43:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23001 for ; Sat, 22 May 2004 05:43:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRT2P-0005vo-I8 for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 05:43:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRT1Q-0005gj-00 for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 05:42:29 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BRT0k-0005W9-02 for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 05:41:46 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BRSu5-0000v7-1v for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 05:34:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRSpR-00046P-9S; Sat, 22 May 2004 05:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRSii-0002zQ-Qt for rtgwg@optimus.ietf.org; Sat, 22 May 2004 05:23:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22185 for ; Sat, 22 May 2004 05:23:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRSif-0002yc-Ae for rtgwg@ietf.org; Sat, 22 May 2004 05:23:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRShg-0002rM-00 for rtgwg@ietf.org; Sat, 22 May 2004 05:22:05 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BRSgt-0002kP-00 for rtgwg@ietf.org; Sat, 22 May 2004 05:21:15 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i4M9LF2S018614; Sat, 22 May 2004 11:21:15 +0200 Received: from alcatel.be ([138.203.118.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004052211211410:682 ; Sat, 22 May 2004 11:21:14 +0200 Message-ID: <40AF1BDF.80701@alcatel.be> Date: Sat, 22 May 2004 11:22:39 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin Cc: Pekka Savola , rtgwg@ietf.org Subject: Re: Charter milestones for IP FRR References: <1149488005.20040520142546@psg.com> <8310518438.20040521231701@psg.com> In-Reply-To: <8310518438.20040521231701@psg.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/22/2004 11:21:14, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/22/2004 11:21:14, Serialize complete at 05/22/2004 11:21:14 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi alex, 1) in the below milestones it seems there is no deadline for framework submission to the IESG - was there any expected deadline ? 2) the Nov'04 deadline refers to the selection of "the" Advanced mechanism based on the review targeted for Aug'04 - which form is this review expected to take (for instance, aren't some guidelines to the selection process desirable to achieve the expected result in due time) thanks in advance for your clarifications, - dimitri. Alex Zinin wrote: > Thanks for looking at this, Pekka! > > >>> APR 2004 Submit initial Internet Draft on Basic IP Fast Reroute mechanism > > >>This should probably be May? > > > Actually, even June, I think. Thanks for catching. > > >>> MAY 2005 Submit specification on Advanced IP Fast Reroute mechanism to >>> IESG for publication as Proposed Standard > > >>We might also want to consider whether one or both of these should go >>to experimental. But that's probably something to think about when we >>have a better idea of what we're talking about.. > > > Yes. The last one is more of a goal we should ultimately aim for. As > we go through the discussion, we'll adjust the actual milestones. > > Here's the new milestones: > > MAY 2004 Submit initial Internet Draft on IP Fast Reroute framework > > JUN 2004 Submit initial Internet Draft on Basic IP Fast Reroute mechanism > > AUG 2004 Review various mechanisms for Advanced IP Fast Reroute > > OCT 2004 Submit specification on Basic IP Fast Reroute mechanism to IESG > for publication as Proposed Standard > > NOV 2004 Select the Advanced IP Fast Reroute mechanism > > MAY 2005 Submit specification on Advanced IP Fast Reroute mechanism to > IESG for publication as Proposed Standard > > Alex > > > _______________________________________________ > Rtgwg mailing list > Rtgwg@ietf.org > https://www1.ietf.org/mailman/listinfo/rtgwg -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Sat May 22 14:19:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19933 for ; Sat, 22 May 2004 14:19:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRb47-0004Ox-Iw for rtgwg-archive@odin.ietf.org; Sat, 22 May 2004 14:17:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4MIHlJN016919 for rtgwg-archive@odin.ietf.org; Sat, 22 May 2004 14:17:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRb10-0003t0-Qb for rtgwg-web-archive@optimus.ietf.org; Sat, 22 May 2004 14:14:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19768 for ; Sat, 22 May 2004 14:14:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRb0y-0003hF-Ek for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 14:14:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRb02-0003VR-00 for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 14:13:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRazA-0003JZ-00 for rtgwg-web-archive@ietf.org; Sat, 22 May 2004 14:12:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRaxb-0002vm-6C; Sat, 22 May 2004 14:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRaqN-0001nL-JA for rtgwg@optimus.ietf.org; Sat, 22 May 2004 14:03:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19419 for ; Sat, 22 May 2004 14:03:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRaqL-0001e7-5x for rtgwg@ietf.org; Sat, 22 May 2004 14:03:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRapT-0001RK-00 for rtgwg@ietf.org; Sat, 22 May 2004 14:02:40 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx with esmtp (Exim 4.12) id 1BRaoW-00013I-00 for rtgwg@ietf.org; Sat, 22 May 2004 14:01:40 -0400 Received: from [192.168.0.2] (pcp09296126pcs.arlngt01.va.comcast.net[69.143.165.226]) by comcast.net (rwcrmhc12) with ESMTP id <2004052218010101400g4loce> (Authid: hcb8); Sat, 22 May 2004 18:01:01 +0000 Mime-Version: 1.0 X-Sender: hcb8@smtp.comcast.net (Unverified) Message-Id: In-Reply-To: <12168157.20040521232809@psg.com> References: <200405211949.PAA25452@ietf.org> <12168157.20040521232809@psg.com> Date: Sat, 22 May 2004 14:00:58 -0400 To: rtgwg@ietf.org From: "Howard C. Berkowitz" Subject: Re: draft-shand-ipfrr-framework-00.txt as a WG document Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 11:28 PM -0700 5/21/04, Alex Zinin wrote: >Folks- > > Mike wrote the first draft of the IP FRR framework that was >mentioned earlier. > I've reviewed the draft, believe that it is very well written, and serves the > purpose as the basis for the corresponding work item. I suggest that this > document becomes a WG item with Mike as the editor. > > Please send your comments within two weeks (by June 4th, 2004.) A very nice piece of work, Mike. Now, some general and very prelimimary comments. I would suggest there be a management framework section in this document. This will relate both to the IGP-independent aspects of fast reroute, plus specific implications for specific IGPs. In the latter, we will have both the considerations of the MIB proper, as well as some specific protocol implications. First, we may want to think of what aspects of some very fast events and computations reasonably can have a goal of being tracked in a MIB. For example, in stages where we reasonably can expect micro-loops, do we expect the various tables (e.g., interface status, LSDB, RIB and FIB) to track the real-time status and possible inconsistencies, or is it adequate to add a variable that tags the appropriate element(s) in all of these "fast reroute in progress"? As something of an aside, we might want to look at the FORCES model, as well as some of the control vs. forwarding plane convergence work in BMWG, so that we have consistent terminology for the status of various events. This is a place to look at Mike's Section 2. Current MIBs, and indeed protocols, emphasize the hello mechanism as the means of failure detection. We need to have an abstraction of failure status, quite likely IGP-specific, that says up/down (plus possibly a "in transition" value), which abstracts both hardware and software (IGP hellos, liveliness protocols, etc.) up/down perspective. Second, some of the things we currently track, such as missed hellos, may need to be optional if we rely on hardware link failure detection. Alternatively,hello tracking may continue to be mandatory for some functions, such as neighbor discovery and dead router detection, but optional for link failure detection. I suspect that this will take some rethinking of the MIB, of capabilities negotiation between neighbors and dead router detection. Even if we have a hardware failure detection mechanism, we will still need hellos for neighbor discovery and mutual recognition. IGPs, however, need to constrain their current MIB generalization of the use of hellos. We need to have a status mechanism that allows hello mechanisms to be bypassed. ospfIfRtrDeadInterval, for example, is not necessarily meaningful in a situation where the primary reliance is on hardware detection. It may be meaningful if we rely on it to tell us when a router is taken out of service, a more general event than a link failure. Consider, though, a case when we need to know about a dead router faster than we might learn from a dead timer. There might need to be either some additional protocol messages, or possibly SNMP traps that are signaled to the IGP, when a routing process is shut down. _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Sun May 23 17:39:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08428 for ; Sun, 23 May 2004 17:39:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS0gH-0000nA-Nf for rtgwg-archive@odin.ietf.org; Sun, 23 May 2004 17:38:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4NLcrj6003044 for rtgwg-archive@odin.ietf.org; Sun, 23 May 2004 17:38:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS0fE-0000XX-G0 for rtgwg-web-archive@optimus.ietf.org; Sun, 23 May 2004 17:37:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08357 for ; Sun, 23 May 2004 17:37:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS0fB-0007Dv-Us for rtgwg-web-archive@ietf.org; Sun, 23 May 2004 17:37:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS0eK-0006yZ-00 for rtgwg-web-archive@ietf.org; Sun, 23 May 2004 17:36:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS0ds-0006in-00 for rtgwg-web-archive@ietf.org; Sun, 23 May 2004 17:36:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS0Zd-0007qh-8d; Sun, 23 May 2004 17:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS0YS-0007hm-ED for rtgwg@optimus.ietf.org; Sun, 23 May 2004 17:30:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07705 for ; Sun, 23 May 2004 17:30:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS0YQ-00059g-4C for rtgwg@ietf.org; Sun, 23 May 2004 17:30:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS0XV-0004um-00 for rtgwg@ietf.org; Sun, 23 May 2004 17:29:50 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BS0X9-0004fU-00 for rtgwg@ietf.org; Sun, 23 May 2004 17:29:27 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i4NLTQ2S009183; Sun, 23 May 2004 23:29:26 +0200 Received: from alcatel.be ([138.203.118.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004052323292509:34 ; Sun, 23 May 2004 23:29:25 +0200 Message-ID: <40B11834.4080405@alcatel.be> Date: Sun, 23 May 2004 23:31:32 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin CC: rtgwg@ietf.org Subject: Re: draft-shand-ipfrr-framework-00.txt as a WG document References: <200405211949.PAA25452@ietf.org> <12168157.20040521232809@psg.com> In-Reply-To: <12168157.20040521232809@psg.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/23/2004 23:29:25, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/23/2004 23:29:26, Serialize complete at 05/23/2004 23:29:26 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi mike, all, this is a good start, a concise document going to be point; some early comments here below: (1) section 2 1. The time taken to detect the failure. This may be of the order of a few mS when it can be detected at the physical layer, up to several tens of seconds when a routing protocol hello is employed. During this period packets will be unavoidably lost. 2. The time taken for the local router to react to the failure. This will typically involve generating and flooding new routing updates, and re-computing the router's FIB. -> is there no waiting for transient flaps (false alarms) and some waiting time before sending out updates considered ? 3. The time taken to pass the information about the failure to other routers in the network. In the absence of routing protocol packet loss, this is typically between 10mS and 100mS per hop in a well designed router. [...] (2) section 3.1 - Mechanisms for fast failure detection it would appropriate to propose the following classification: - physical detection data plane loss of signal/loss of light - non-associated protocol detection (BFD) - associated routing protocol detection (Hellos) note that the media dependent detection will be there independently of the additional media independent/generic BFD but their applicability as trigger may vary wrt to the different network environments commonly considered: P2P, (P2MP,) and BA it is also worth noticing that having a mechanism like BFD elevates the issue of non-homogeneous physical behaviour of both side of the links, i'd like to make this clearer compared to methods like MPLS FRR (3) Section 3.1 - advisable to include appropriate references to the numbers of provided for the applicability of each method (if it is an evaluation performed in the scope of the document, corresponding reasoning could be included) (4) Section 3.2.2 concerning the discussions on link versus node protection - Discussion about multiple adjacencies b/w two nodes should be also covered nodes (5) Processing in case of failure of the loop free alternates, since the failure probability of the alternates should not be different from the failure probability of the primary path(s) (6) Editorial comments - from the introduction "This is analogous to the technique employed by MPLS Fast Reroute [MPLSFRR], but the mechanisms employed for the backup routes in pure IP networks are necessarily very different." i don't perceive the real intent of this sentence - section 3.3 "A number of solutions to the problem of micro-loop formation have been proposed." would you provide some material/ref's ? thanks for the clarifications, - dimitri. --- Alex Zinin wrote: > Folks- > > Mike wrote the first draft of the IP FRR framework that was mentioned earlier. > I've reviewed the draft, believe that it is very well written, and serves the > purpose as the basis for the corresponding work item. I suggest that this > document becomes a WG item with Mike as the editor. > > Please send your comments within two weeks (by June 4th, 2004.) > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Mon May 24 04:12:54 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19123 for ; Mon, 24 May 2004 04:12:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSAXi-000775-BW for rtgwg-archive@odin.ietf.org; Mon, 24 May 2004 04:10:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O8Agbw027343 for rtgwg-archive@odin.ietf.org; Mon, 24 May 2004 04:10:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSALg-0005TE-2h for rtgwg-web-archive@optimus.ietf.org; Mon, 24 May 2004 03:58:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18487 for ; Mon, 24 May 2004 03:58:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSALd-0004nU-Bk for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 03:58:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSAKq-0004Vr-00 for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 03:57:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSAK7-0004Cz-00 for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 03:56:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSAFh-0004kJ-63; Mon, 24 May 2004 03:52:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSABy-0004Mz-2E for rtgwg@optimus.ietf.org; Mon, 24 May 2004 03:48:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17634 for ; Mon, 24 May 2004 03:48:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSABv-0001Ze-IM for rtgwg@ietf.org; Mon, 24 May 2004 03:48:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSAAz-0001H4-00 for rtgwg@ietf.org; Mon, 24 May 2004 03:47:13 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BSAA5-0000hi-00 for rtgwg@ietf.org; Mon, 24 May 2004 03:46:17 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4O7jjf9021055 for ; Mon, 24 May 2004 00:45:46 -0700 (PDT) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp391.cisco.com [10.61.65.135]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA25537 for ; Mon, 24 May 2004 08:45:44 +0100 (BST) Message-Id: <4.3.2.7.2.20040524084141.02b7f2b8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 May 2004 08:45:40 +0100 To: rtgwg@ietf.org From: mike shand Subject: draft-bryant-ipfrr-tunnels-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 We have posted the following draft, which describes an approach to IP fast Re-route based on the use of tunnels. http://www.ietf.org/internet-drafts/draft-bryant-ipfrr-tunnels-00.txt Mike Abstract: This draft describes an IP fast re-route mechanism that provides backup connectivity in the event of a link or router failure. In the absence of single points of failure and asymmetric costs, the mechanism provides complete protection against any single failure. If perfect repair is not possible, the identity of all the unprotected links and routers is known in advance. The draft also describes the mechanisms needed to prevent the packet loss caused by loops which normally occur during the reconvergence of the network following a failure. _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Mon May 24 04:40:38 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20399 for ; Mon, 24 May 2004 04:40:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSAuq-0001Th-I2 for rtgwg-archive@odin.ietf.org; Mon, 24 May 2004 04:34:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O8YauT005658 for rtgwg-archive@odin.ietf.org; Mon, 24 May 2004 04:34:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSAmj-0000fu-V8 for rtgwg-web-archive@optimus.ietf.org; Mon, 24 May 2004 04:26:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19809 for ; Mon, 24 May 2004 04:26:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSAmg-0005QJ-Uo for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 04:26:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSAln-00058L-00 for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 04:25:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSAku-0004qU-00 for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 04:24:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSAfo-0008HA-2T; Mon, 24 May 2004 04:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSAZR-0007Z8-3g for rtgwg@optimus.ietf.org; Mon, 24 May 2004 04:12:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19106 for ; Mon, 24 May 2004 04:12:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSAZO-0001Fu-Dz for rtgwg@ietf.org; Mon, 24 May 2004 04:12:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSAYX-0000w8-00 for rtgwg@ietf.org; Mon, 24 May 2004 04:11:34 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BSAXm-0000Zg-00 for rtgwg@ietf.org; Mon, 24 May 2004 04:10:46 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 May 2004 00:18:40 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4O8AEDe014058; Mon, 24 May 2004 01:10:15 -0700 (PDT) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp391.cisco.com [10.61.65.135]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA26104; Mon, 24 May 2004 09:10:12 +0100 (BST) Message-Id: <4.3.2.7.2.20040524084754.02cb3078@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 May 2004 09:10:10 +0100 To: Dimitri.Papadimitriou@alcatel.be From: mike shand Subject: Re: draft-shand-ipfrr-framework-00.txt as a WG document Cc: Alex Zinin , rtgwg@ietf.org In-Reply-To: <40B11834.4080405@alcatel.be> References: <12168157.20040521232809@psg.com> <200405211949.PAA25452@ietf.org> <12168157.20040521232809@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 23:31 23/05/2004 +0200, Dimitri.Papadimitriou@alcatel.be wrote: >hi mike, all, > >this is a good start, a concise document going to be point; some early >comments here below: > >(1) section 2 > >1. The time taken to detect the failure. This may be of the order > of a few mS when it can be detected at the physical layer, up to > several tens of seconds when a routing protocol hello is > employed. During this period packets will be unavoidably lost. > >2. The time taken for the local router to react to the failure. > This will typically involve generating and flooding new routing > updates, and re-computing the router's FIB. > >-> is there no waiting for transient flaps (false alarms) and some >waiting time before sending out updates considered ? Yes, that's true. In one sense these are artificially imposed delays which can be lowered in the search for rapid convergence, as opposed to fundamental limitations. However, it would do no harm to mention them. >3. The time taken to pass the information about the failure to > other routers in the network. In the absence of routing protocol > packet loss, this is typically between 10mS and 100mS per hop in > a well designed router. > > [...] > >(2) section 3.1 - Mechanisms for fast failure detection > >it would appropriate to propose the following classification: >- physical detection data plane loss of signal/loss of light >- non-associated protocol detection (BFD) >- associated routing protocol detection (Hellos) Yes. that is more abstract. >note that the media dependent detection will be there independently of the >additional media independent/generic BFD but their applicability as >trigger may vary wrt to the different network environments commonly >considered: P2P, (P2MP,) and BA Of course. >it is also worth noticing that having a mechanism like BFD elevates the >issue of non-homogeneous physical behaviour of both side of the links, i'd >like to make this clearer compared to methods like MPLS FRR Not quite sure what you mean here. Do you mean that use of BFD on both ends of the link is more likely to result in de-synchronized triggers (which I don't think would necessarily be true), or do you mean that one end may use BFD and the other not. Or do you mean something else? >(3) Section 3.1 - advisable to include appropriate references to the >numbers of provided for the applicability of each method (if it is an >evaluation performed in the scope of the document, corresponding reasoning >could be included) Sorry, I'm confused again. Are you referring to the 80% and 95% numbers in section 3.2? Those numbers (or an approximation of them) come from Alia's presentation, but they are supported by my own simulations of real world networks. >(4) Section 3.2.2 concerning the discussions on link versus node >protection - Discussion about multiple adjacencies b/w two nodes >should be also covered nodes Sorry, I don't understand. Do you mean something like the material covered in section 4.6.2 of http://www.ietf.org/internet-drafts/draft-bryant-ipfrr-tunnels-00.txt Although that is explicitly the ECMP case. You could have parallel links with different costs (why I don't know). >(5) Processing in case of failure of the loop free alternates, since the >failure probability of the alternates should not be different from the >failure probability of the primary path(s) Again, could you expand on that please? >(6) Editorial comments > >- from the introduction "This is analogous to the technique employed by >MPLS Fast Reroute [MPLSFRR], but the mechanisms employed for the backup >routes in pure IP networks are necessarily very different." i don't >perceive the real intent of this sentence It was to give readers an idea that the concept of rapidly switching to a pre-computed backup path was similar to something with which they are familiar (i.e. MPLS FRR), but pointing out that the way the backup paths is computed is very different. >- section 3.3 "A number of solutions to the problem of micro-loop >formation have been proposed." would you provide some material/ref's ? See section 6 of http://www.ietf.org/internet-drafts/draft-bryant-ipfrr-tunnels-00.txt >thanks for the clarifications, >- dimitri. Thanks for the comments. Mike >--- > >Alex Zinin wrote: > >>Folks- >> Mike wrote the first draft of the IP FRR framework that was mentioned >> earlier. >> I've reviewed the draft, believe that it is very well written, and >> serves the >> purpose as the basis for the corresponding work item. I suggest that this >> document becomes a WG item with Mike as the editor. >> Please send your comments within two weeks (by June 4th, 2004.) > >-- >Papadimitriou Dimitri >E-mail : dimitri.papadimitriou@alcatel.be >E-mail : dpapadimitriou@psg.com >Webpage: http://psg.com/~dpapadimitriou/ >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >Phone : +32 3 240-8491 > > > >_______________________________________________ >Rtgwg mailing list >Rtgwg@ietf.org >https://www1.ietf.org/mailman/listinfo/rtgwg _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Mon May 24 04:41:54 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20446 for ; Mon, 24 May 2004 04:41:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSAvi-0001dZ-N2 for rtgwg-archive@odin.ietf.org; Mon, 24 May 2004 04:35:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O8ZUPu006289 for rtgwg-archive@odin.ietf.org; Mon, 24 May 2004 04:35:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSAtS-0001Cf-Vs for rtgwg-web-archive@optimus.ietf.org; Mon, 24 May 2004 04:33:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20043 for ; Mon, 24 May 2004 04:33:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSAtQ-0007Tm-1M for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 04:33:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSAsR-000799-00 for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 04:32:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSArQ-0006l5-00 for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 04:31:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSAla-0000Qp-9I; Mon, 24 May 2004 04:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSAg0-0008Ju-8G for rtgwg@optimus.ietf.org; Mon, 24 May 2004 04:19:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19477 for ; Mon, 24 May 2004 04:19:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSAfx-0003Le-GE for rtgwg@ietf.org; Mon, 24 May 2004 04:19:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSAf1-00034U-00 for rtgwg@ietf.org; Mon, 24 May 2004 04:18:16 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BSAeb-0002nY-00 for rtgwg@ietf.org; Mon, 24 May 2004 04:17:49 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 24 May 2004 00:25:43 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4O8HHf9014461; Mon, 24 May 2004 01:17:18 -0700 (PDT) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp391.cisco.com [10.61.65.135]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA26283; Mon, 24 May 2004 09:17:16 +0100 (BST) Message-Id: <4.3.2.7.2.20040524091156.02b7ddb8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 May 2004 09:16:43 +0100 To: "Howard C. Berkowitz" From: mike shand Subject: Re: draft-shand-ipfrr-framework-00.txt as a WG document Cc: rtgwg@ietf.org In-Reply-To: References: <12168157.20040521232809@psg.com> <200405211949.PAA25452@ietf.org> <12168157.20040521232809@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Howard, I agree that we will need to consider the management/MIB implications, but I suspect that until we have gone down this road a little further we can only really put a placeholder in the framework document. When we have a clearer idea of where we are going (and in particular what mechanisms we are using to get there), we will be able to think of the management aspects in more concrete terms. What you say below is a good basis. Mike At 14:00 22/05/2004 -0400, Howard C. Berkowitz wrote: >At 11:28 PM -0700 5/21/04, Alex Zinin wrote: >>Folks- >> >> Mike wrote the first draft of the IP FRR framework that was mentioned >> earlier. >> I've reviewed the draft, believe that it is very well written, and >> serves the >> purpose as the basis for the corresponding work item. I suggest that this >> document becomes a WG item with Mike as the editor. >> >> Please send your comments within two weeks (by June 4th, 2004.) > >A very nice piece of work, Mike. > >Now, some general and very prelimimary comments. I would suggest there >be a management framework section in this document. This will relate both >to the IGP-independent aspects of fast reroute, plus specific implications >for specific IGPs. In the latter, we will have both the considerations of >the MIB proper, as well as some specific protocol implications. > >First, we may want to think of what aspects of some very fast events and >computations reasonably can have a goal of being tracked in a MIB. For >example, in stages where we reasonably can expect micro-loops, do we >expect the various tables (e.g., interface status, LSDB, RIB and FIB) to >track the real-time status and possible inconsistencies, or is it adequate >to add a variable that tags the appropriate element(s) in all of these >"fast reroute in progress"? > >As something of an aside, we might want to look at the FORCES model, as >well as some of the control vs. forwarding plane convergence work in BMWG, >so that we have consistent terminology for the status of various >events. This is a place to look at Mike's Section 2. > >Current MIBs, and indeed protocols, emphasize the hello mechanism as the >means of failure detection. We need to have an abstraction of failure >status, quite likely IGP-specific, that says up/down (plus possibly a "in >transition" value), which abstracts both hardware and software (IGP >hellos, liveliness protocols, etc.) up/down perspective. > >Second, some of the things we currently track, such as missed hellos, may >need to be optional if we rely on hardware link failure >detection. Alternatively,hello tracking may continue to be mandatory for >some functions, such as neighbor discovery and dead router detection, but >optional for link failure detection. I suspect that this will take some >rethinking of the MIB, of capabilities negotiation between neighbors and >dead router detection. Even if we have a hardware failure detection >mechanism, we will still need hellos for neighbor discovery and mutual >recognition. > >IGPs, however, need to constrain their current MIB generalization of the >use of hellos. We need to have a status mechanism that allows hello >mechanisms to be bypassed. ospfIfRtrDeadInterval, for example, is not >necessarily meaningful in a situation where the primary reliance is on >hardware detection. It may be meaningful if we rely on it to tell us when >a router is taken out of service, a more general event than a link >failure. Consider, though, a case when we need to know about a dead router >faster than we might learn from a dead timer. There might need to be >either some additional protocol messages, or possibly SNMP traps that are >signaled to the IGP, when a routing process is shut down. > >_______________________________________________ >Rtgwg mailing list >Rtgwg@ietf.org >https://www1.ietf.org/mailman/listinfo/rtgwg _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Mon May 24 06:02:29 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23873 for ; Mon, 24 May 2004 06:02:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCDd-0003iX-R7 for rtgwg-archive@odin.ietf.org; Mon, 24 May 2004 05:58:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O9w5t1014289 for rtgwg-archive@odin.ietf.org; Mon, 24 May 2004 05:58:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSC74-0002ql-P1 for rtgwg-web-archive@optimus.ietf.org; Mon, 24 May 2004 05:51:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23223 for ; Mon, 24 May 2004 05:51:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSC70-0007RI-UU for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 05:51:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSC68-000797-00 for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 05:50:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSC5C-0006qt-00 for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 05:49:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSC12-0001yp-IR; Mon, 24 May 2004 05:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBkr-00087K-76 for rtgwg@optimus.ietf.org; Mon, 24 May 2004 05:28:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22325 for ; Mon, 24 May 2004 05:28:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSBkn-0000Oo-Oc for rtgwg@ietf.org; Mon, 24 May 2004 05:28:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSBjn-00005i-00 for rtgwg@ietf.org; Mon, 24 May 2004 05:27:16 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BSBiu-0007JM-00 for rtgwg@ietf.org; Mon, 24 May 2004 05:26:20 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 24 May 2004 02:25:38 -0700 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i4O9PlVh013267; Mon, 24 May 2004 02:25:48 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp212.cisco.com [10.61.64.212]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA28673; Mon, 24 May 2004 10:25:45 +0100 (BST) Message-ID: <40B1BF99.8080209@cisco.com> Date: Mon, 24 May 2004 10:25:45 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: Alex Zinin , rtgwg@ietf.org Subject: Re: draft-shand-ipfrr-framework-00.txt as a WG document References: <200405211949.PAA25452@ietf.org> <12168157.20040521232809@psg.com> <40B11834.4080405@alcatel.be> In-Reply-To: <40B11834.4080405@alcatel.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dimitri.Papadimitriou@alcatel.be wrote: > hi mike, all, > > this is a good start, a concise document going to be point; some early > comments here below: > > (1) section 2 > > 1. The time taken to detect the failure. This may be of the order > of a few mS when it can be detected at the physical layer, up to > several tens of seconds when a routing protocol hello is > employed. During this period packets will be unavoidably lost. > > 2. The time taken for the local router to react to the failure. > This will typically involve generating and flooding new routing > updates, and re-computing the router's FIB. > > -> is there no waiting for transient flaps (false alarms) and some > waiting time before sending out updates considered ? Yes, but this was taken to be a component of (1) above. > > 3. The time taken to pass the information about the failure to > other routers in the network. In the absence of routing protocol > packet loss, this is typically between 10mS and 100mS per hop in > a well designed router. > > [...] > > (2) section 3.1 - Mechanisms for fast failure detection > > it would appropriate to propose the following classification: > - physical detection data plane loss of signal/loss of light > - non-associated protocol detection (BFD) > - associated routing protocol detection (Hellos) > > note that the media dependent detection will be there independently of > the additional media independent/generic BFD but their applicability as > trigger may vary wrt to the different network environments commonly > considered: P2P, (P2MP,) and BA > > it is also worth noticing that having a mechanism like BFD elevates the > issue of non-homogeneous physical behaviour of both side of the links, > i'd like to make this clearer compared to methods like MPLS FRR I do not understand this statement. In particular I do not see why there is any difference between the BFD failure detection in an IP system vs an MPLS system. > > (3) Section 3.1 - advisable to include appropriate references to the > numbers of provided for the applicability of each method (if it is an > evaluation performed in the scope of the document, corresponding > reasoning could be included) I assume that you mean the detection latency. That is highly dependent on the media, the netwoek and the implementation. > > (4) Section 3.2.2 concerning the discussions on link versus node > protection - Discussion about multiple adjacencies b/w two nodes > should be also covered nodes > Isn't this covered by 3.2.2 item 1 which says that the IPFRR path must not transit the failure? If you are doing node protection you have to exclude all links to the failed node. > (5) Processing in case of failure of the loop free alternates, since the > failure probability of the alternates should not be different from the > failure probability of the primary path(s) > I do not understand this comment. > (6) Editorial comments > > - from the introduction "This is analogous to the technique employed by > MPLS Fast Reroute [MPLSFRR], but the mechanisms employed for the backup > routes in pure IP networks are necessarily very different." i don't > perceive the real intent of this sentence > To say that IPFRR is conceptually similar to MPLS FRR as far a preplanning the repair, having fast detection and fast local invocation of FRR with communicating with other nodes at the time of failure, BUT the absence of the circuit switching mode that MPLS has (because source routing is not implemented in the IP fast path) means that we have to use alternative methods to force the packet along the repair path. > - section 3.3 "A number of solutions to the problem of micro-loop > formation have been proposed." would you provide some material/ref's ? > Some of the techniques are described in draft-bryant-ipfrr-tunnels-00.txt which. - Stewart > thanks for the clarifications, > - dimitri. > > --- > > Alex Zinin wrote: > >> Folks- >> >> Mike wrote the first draft of the IP FRR framework that was mentioned >> earlier. >> I've reviewed the draft, believe that it is very well written, and >> serves the >> purpose as the basis for the corresponding work item. I suggest that >> this >> document becomes a WG item with Mike as the editor. >> >> Please send your comments within two weeks (by June 4th, 2004.) >> > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Mon May 24 06:50:49 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25982 for ; Mon, 24 May 2004 06:50:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCwT-00027x-9M for rtgwg-archive@odin.ietf.org; Mon, 24 May 2004 06:44:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OAiP1S008171 for rtgwg-archive@odin.ietf.org; Mon, 24 May 2004 06:44:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCsr-0001fF-24 for rtgwg-web-archive@optimus.ietf.org; Mon, 24 May 2004 06:40:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25565 for ; Mon, 24 May 2004 06:40:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSCsm-0007Ly-VF for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 06:40:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSCrq-00070p-00 for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 06:39:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSCrE-0006fm-00 for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 06:39:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCdj-0007vx-Jc; Mon, 24 May 2004 06:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCMc-0004tC-IW for rtgwg@optimus.ietf.org; Mon, 24 May 2004 06:07:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24029 for ; Mon, 24 May 2004 06:07:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSCMY-0004jN-O4 for rtgwg@ietf.org; Mon, 24 May 2004 06:07:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSCLc-0004P3-00 for rtgwg@ietf.org; Mon, 24 May 2004 06:06:21 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BSCKr-0003oP-00 for rtgwg@ietf.org; Mon, 24 May 2004 06:05:33 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 May 2004 02:11:49 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4OA4xDe014385; Mon, 24 May 2004 03:05:00 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp212.cisco.com [10.61.64.212]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA00172; Mon, 24 May 2004 11:04:57 +0100 (BST) Message-ID: <40B1C8C8.90704@cisco.com> Date: Mon, 24 May 2004 11:04:56 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mike shand CC: "Howard C. Berkowitz" , rtgwg@ietf.org Subject: Re: draft-shand-ipfrr-framework-00.txt as a WG document References: <12168157.20040521232809@psg.com> <200405211949.PAA25452@ietf.org> <12168157.20040521232809@psg.com> <4.3.2.7.2.20040524091156.02b7ddb8@jaws.cisco.com> In-Reply-To: <4.3.2.7.2.20040524091156.02b7ddb8@jaws.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit mike shand wrote: > Howard, > I agree that we will need to consider the management/MIB > implications, but I suspect that until we have gone down this road a > little further we can only really put a placeholder in the framework > document. When we have a clearer idea of where we are going (and in > particular what mechanisms we are using to get there), we will be able > to think of the management aspects in more concrete terms. What you say > below is a good basis. > > Mike > Don't forget that we need to consider both the management of IPFRR and the use of loop-free in the management of the network. - Stewart > At 14:00 22/05/2004 -0400, Howard C. Berkowitz wrote: > >> At 11:28 PM -0700 5/21/04, Alex Zinin wrote: >> >>> Folks- >>> >>> Mike wrote the first draft of the IP FRR framework that was >>> mentioned earlier. >>> I've reviewed the draft, believe that it is very well written, and >>> serves the >>> purpose as the basis for the corresponding work item. I suggest that >>> this >>> document becomes a WG item with Mike as the editor. >>> >>> Please send your comments within two weeks (by June 4th, 2004.) >> >> >> A very nice piece of work, Mike. >> >> Now, some general and very prelimimary comments. I would suggest >> there be a management framework section in this document. This will >> relate both to the IGP-independent aspects of fast reroute, plus >> specific implications for specific IGPs. In the latter, we will have >> both the considerations of the MIB proper, as well as some specific >> protocol implications. >> >> First, we may want to think of what aspects of some very fast events >> and computations reasonably can have a goal of being tracked in a >> MIB. For example, in stages where we reasonably can expect >> micro-loops, do we expect the various tables (e.g., interface status, >> LSDB, RIB and FIB) to track the real-time status and possible >> inconsistencies, or is it adequate to add a variable that tags the >> appropriate element(s) in all of these "fast reroute in progress"? >> >> As something of an aside, we might want to look at the FORCES model, >> as well as some of the control vs. forwarding plane convergence work >> in BMWG, so that we have consistent terminology for the status of >> various events. This is a place to look at Mike's Section 2. >> >> Current MIBs, and indeed protocols, emphasize the hello mechanism as >> the means of failure detection. We need to have an abstraction of >> failure status, quite likely IGP-specific, that says up/down (plus >> possibly a "in transition" value), which abstracts both hardware and >> software (IGP hellos, liveliness protocols, etc.) up/down perspective. >> >> Second, some of the things we currently track, such as missed hellos, >> may need to be optional if we rely on hardware link failure >> detection. Alternatively,hello tracking may continue to be mandatory >> for some functions, such as neighbor discovery and dead router >> detection, but optional for link failure detection. I suspect that >> this will take some rethinking of the MIB, of capabilities negotiation >> between neighbors and dead router detection. Even if we have a >> hardware failure detection mechanism, we will still need hellos for >> neighbor discovery and mutual recognition. >> >> IGPs, however, need to constrain their current MIB generalization of >> the use of hellos. We need to have a status mechanism that allows >> hello mechanisms to be bypassed. ospfIfRtrDeadInterval, for example, >> is not necessarily meaningful in a situation where the primary >> reliance is on hardware detection. It may be meaningful if we rely on >> it to tell us when a router is taken out of service, a more general >> event than a link failure. Consider, though, a case when we need to >> know about a dead router faster than we might learn from a dead timer. >> There might need to be either some additional protocol messages, or >> possibly SNMP traps that are signaled to the IGP, when a routing >> process is shut down. >> >> _______________________________________________ >> Rtgwg mailing list >> Rtgwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/rtgwg > > > > _______________________________________________ > Rtgwg mailing list > Rtgwg@ietf.org > https://www1.ietf.org/mailman/listinfo/rtgwg > > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Mon May 24 08:05:17 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00252 for ; Mon, 24 May 2004 08:05:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSE20-0002OH-Ea for rtgwg-archive@odin.ietf.org; Mon, 24 May 2004 07:54:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OBsCb4009190 for rtgwg-archive@odin.ietf.org; Mon, 24 May 2004 07:54:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDqy-0001Fi-3L for rtgwg-web-archive@optimus.ietf.org; Mon, 24 May 2004 07:42:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28806 for ; Mon, 24 May 2004 07:42:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSDqx-0004Ip-Cr for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 07:42:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSDpm-0003wR-00 for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 07:41:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSDpD-0003c7-00 for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 07:40:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDa4-0007Nm-PD; Mon, 24 May 2004 07:25:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDSN-0006B7-VK for rtgwg@optimus.ietf.org; Mon, 24 May 2004 07:17:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27630 for ; Mon, 24 May 2004 07:17:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSDSN-0003vw-Av for rtgwg@ietf.org; Mon, 24 May 2004 07:17:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSDRS-0003bd-00 for rtgwg@ietf.org; Mon, 24 May 2004 07:16:27 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BSDQn-0003G0-00 for rtgwg@ietf.org; Mon, 24 May 2004 07:15:45 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i4OBFd2S020297; Mon, 24 May 2004 13:15:39 +0200 Received: from alcatel.be ([138.203.64.251]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004052413153812:2733 ; Mon, 24 May 2004 13:15:38 +0200 Message-ID: <40B1D9D0.2000103@alcatel.be> Date: Mon, 24 May 2004 13:17:36 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mike shand Cc: Alex Zinin , rtgwg@ietf.org Subject: Re: draft-shand-ipfrr-framework-00.txt as a WG document References: <12168157.20040521232809@psg.com> <200405211949.PAA25452@ietf.org> <12168157.20040521232809@psg.com> <4.3.2.7.2.20040524084754.02cb3078@jaws.cisco.com> In-Reply-To: <4.3.2.7.2.20040524084754.02cb3078@jaws.cisco.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/24/2004 13:15:38, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/24/2004 13:15:38, Serialize complete at 05/24/2004 13:15:38 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: 7bit Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi mike, mike shand wrote: > At 23:31 23/05/2004 +0200, Dimitri.Papadimitriou@alcatel.be wrote: > >> hi mike, all, >> >> this is a good start, a concise document going to be point; some early >> comments here below: >> >> (1) section 2 >> >> 1. The time taken to detect the failure. This may be of the order >> of a few mS when it can be detected at the physical layer, up to >> several tens of seconds when a routing protocol hello is >> employed. During this period packets will be unavoidably lost. >> >> 2. The time taken for the local router to react to the failure. >> This will typically involve generating and flooding new routing >> updates, and re-computing the router's FIB. >> >> -> is there no waiting for transient flaps (false alarms) and some >> waiting time before sending out updates considered ? > > Yes, that's true. In one sense these are artificially imposed delays > which can be lowered in the search for rapid convergence, as opposed to > fundamental limitations. However, it would do no harm to mention them. > >> 3. The time taken to pass the information about the failure to >> other routers in the network. In the absence of routing protocol >> packet loss, this is typically between 10mS and 100mS per hop in >> a well designed router. >> >> [...] >> >> (2) section 3.1 - Mechanisms for fast failure detection >> >> it would appropriate to propose the following classification: >> - physical detection data plane loss of signal/loss of light >> - non-associated protocol detection (BFD) >> - associated routing protocol detection (Hellos) > > Yes. that is more abstract. > >> note that the media dependent detection will be there independently of >> the additional media independent/generic BFD but their applicability >> as trigger may vary wrt to the different network environments commonly >> considered: P2P, (P2MP,) and BA > > Of course. > >> it is also worth noticing that having a mechanism like BFD elevates >> the issue of non-homogeneous physical behaviour of both side of the >> links, i'd like to make this clearer compared to methods like MPLS FRR > > Not quite sure what you mean here. Do you mean that use of BFD on both > ends of the link is more likely to result in de-synchronized triggers > (which I don't think would necessarily be true), or do you mean that one > end may use BFD and the other not. Or do you mean something else? i mean that usage of BFD is a clear improvment compared to mechanisms that rely only data plane failure detection that do not guarantee that both sides would react in the same in case of failure, here there is an opportunity to make the design more robust from this perspective, it is also possible to explicit the sequence that could happen (since physical detection and loss of adjacency will occur) >> (3) Section 3.1 - advisable to include appropriate references to the >> numbers of provided for the applicability of each method (if it is an >> evaluation performed in the scope of the document, corresponding >> reasoning could be included) > > Sorry, I'm confused again. Are you referring to the 80% and 95% numbers > in section 3.2? Those numbers (or an approximation of them) come from > Alia's presentation, but they are supported by my own simulations of > real world networks. yes this is what i meant by adding the references >> (4) Section 3.2.2 concerning the discussions on link versus node >> protection - Discussion about multiple adjacencies b/w two nodes >> should be also covered nodes > > Sorry, I don't understand. Do you mean something like the material > covered in section 4.6.2 of > > http://www.ietf.org/internet-drafts/draft-bryant-ipfrr-tunnels-00.txt sorry for the typo in the above sentence, i was referring to the discussion concerning multiple adjacencies b/w two nodes > Although that is explicitly the ECMP case. You could have parallel links > with different costs (why I don't know). yes - it is a generic 4.6.2 (sub-case 1) case - as an another example one may point out to (and subsequent): and it would be advisable to have a (small) discussion upon the tradeoff between making them "invisible" wrt to capacity of loop free alternates computation >> (5) Processing in case of failure of the loop free alternates, since >> the failure probability of the alternates should not be different from >> the failure probability of the primary path(s) > > Again, could you expand on that please? document focuses on pre-computation of alternates for the primary path in case of failure, it doesn't say anything related to the maintenance of these alternates >> (6) Editorial comments >> >> - from the introduction "This is analogous to the technique employed >> by MPLS Fast Reroute [MPLSFRR], but the mechanisms employed for the >> backup routes in pure IP networks are necessarily very different." i >> don't perceive the real intent of this sentence > > It was to give readers an idea that the concept of rapidly switching to > a pre-computed backup path was similar to something with which they are > familiar (i.e. MPLS FRR), but pointing out that the way the backup paths > is computed is very different. ok >> - section 3.3 "A number of solutions to the problem of micro-loop >> formation have been proposed." would you provide some material/ref's ? > > See section 6 of > > http://www.ietf.org/internet-drafts/draft-bryant-ipfrr-tunnels-00.txt ok thanks (if there are points that are still unclear please let me know) - dimitri. >> thanks for the clarifications, >> - dimitri. > > > > Thanks for the comments. > > Mike > > > >> --- >> >> Alex Zinin wrote: >> >>> Folks- >>> Mike wrote the first draft of the IP FRR framework that was >>> mentioned earlier. >>> I've reviewed the draft, believe that it is very well written, and >>> serves the >>> purpose as the basis for the corresponding work item. I suggest that >>> this >>> document becomes a WG item with Mike as the editor. >>> Please send your comments within two weeks (by June 4th, 2004.) >> >> >> -- >> Papadimitriou Dimitri >> E-mail : dimitri.papadimitriou@alcatel.be >> E-mail : dpapadimitriou@psg.com >> Webpage: http://psg.com/~dpapadimitriou/ >> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >> Phone : +32 3 240-8491 >> >> >> >> _______________________________________________ >> Rtgwg mailing list >> Rtgwg@ietf.org >> https://www1.ietf.org/mailman/listinfo/rtgwg > > > > _______________________________________________ > Rtgwg mailing list > Rtgwg@ietf.org > https://www1.ietf.org/mailman/listinfo/rtgwg -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Mon May 24 08:42:59 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02226 for ; Mon, 24 May 2004 08:42:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEdL-0008Gq-KD for rtgwg-archive@odin.ietf.org; Mon, 24 May 2004 08:32:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OCWlQs031792 for rtgwg-archive@odin.ietf.org; Mon, 24 May 2004 08:32:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSETd-0006xo-Bs for rtgwg-web-archive@optimus.ietf.org; Mon, 24 May 2004 08:22:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01267 for ; Mon, 24 May 2004 08:22:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSETc-0001qb-3Z for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 08:22:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSESM-0001Q7-00 for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 08:21:28 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BSERA-0000nM-01 for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 08:20:12 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BSEEq-0007lH-A2 for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 08:07:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSE7x-0003Vv-Ht; Mon, 24 May 2004 08:00:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSDtb-0001U5-TD for rtgwg@optimus.ietf.org; Mon, 24 May 2004 07:45:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28927 for ; Mon, 24 May 2004 07:45:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSDtb-0005Hc-4k for rtgwg@ietf.org; Mon, 24 May 2004 07:45:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSDsc-0004yH-00 for rtgwg@ietf.org; Mon, 24 May 2004 07:44:31 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BSDs3-0004ZN-00 for rtgwg@ietf.org; Mon, 24 May 2004 07:43:55 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4OBhLDe014618; Mon, 24 May 2004 04:43:21 -0700 (PDT) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp391.cisco.com [10.61.65.135]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA03784; Mon, 24 May 2004 12:43:19 +0100 (BST) Message-Id: <4.3.2.7.2.20040524122443.03785c40@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 May 2004 12:42:43 +0100 To: Dimitri.Papadimitriou@alcatel.be From: mike shand Subject: Re: draft-shand-ipfrr-framework-00.txt as a WG document Cc: Alex Zinin , rtgwg@ietf.org In-Reply-To: <40B1D9D0.2000103@alcatel.be> References: <4.3.2.7.2.20040524084754.02cb3078@jaws.cisco.com> <12168157.20040521232809@psg.com> <200405211949.PAA25452@ietf.org> <12168157.20040521232809@psg.com> <4.3.2.7.2.20040524084754.02cb3078@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 13:17 24/05/2004 +0200, Dimitri.Papadimitriou@alcatel.be wrote: >hi mike, > >mike shand wrote: >>At 23:31 23/05/2004 +0200, Dimitri.Papadimitriou@alcatel.be wrote: >> >>>hi mike, all, >>> >>>this is a good start, a concise document going to be point; some early >>>comments here below: >>> >>>(1) section 2 >>> >>>1. The time taken to detect the failure. This may be of the order >>> of a few mS when it can be detected at the physical layer, up to >>> several tens of seconds when a routing protocol hello is >>> employed. During this period packets will be unavoidably lost. >>> >>>2. The time taken for the local router to react to the failure. >>> This will typically involve generating and flooding new routing >>> updates, and re-computing the router's FIB. >>> >>>-> is there no waiting for transient flaps (false alarms) and some >>>waiting time before sending out updates considered ? >>Yes, that's true. In one sense these are artificially imposed delays >>which can be lowered in the search for rapid convergence, as opposed to >>fundamental limitations. However, it would do no harm to mention them. >> >>>3. The time taken to pass the information about the failure to >>> other routers in the network. In the absence of routing protocol >>> packet loss, this is typically between 10mS and 100mS per hop in >>> a well designed router. >>> >>> [...] >>> >>>(2) section 3.1 - Mechanisms for fast failure detection >>> >>>it would appropriate to propose the following classification: >>>- physical detection data plane loss of signal/loss of light >>>- non-associated protocol detection (BFD) >>>- associated routing protocol detection (Hellos) >>Yes. that is more abstract. >> >>>note that the media dependent detection will be there independently of >>>the additional media independent/generic BFD but their applicability as >>>trigger may vary wrt to the different network environments commonly >>>considered: P2P, (P2MP,) and BA >>Of course. >> >>>it is also worth noticing that having a mechanism like BFD elevates the >>>issue of non-homogeneous physical behaviour of both side of the links, >>>i'd like to make this clearer compared to methods like MPLS FRR >>Not quite sure what you mean here. Do you mean that use of BFD on both >>ends of the link is more likely to result in de-synchronized triggers >>(which I don't think would necessarily be true), or do you mean that one >>end may use BFD and the other not. Or do you mean something else? > >i mean that usage of BFD is a clear improvment compared to mechanisms that >rely only data plane failure detection that do not guarantee that both >sides would react in the same in case of failure, here there is an >opportunity to make the design more robust from this perspective, it is >also possible to explicit the sequence that could happen (since physical >detection and loss of adjacency will occur) I would anticipate that most IPFRR implementations would use a combination of physical (Loss of light etc.) and BFD and trigger on whichever gave the first indication of failure. Note that I would expect the repair paths to be invoked immediately, but that the announcement of the failure in the IGP would be held down in case the link came back quickly. Simply invoking repair is much less disruptive than reconverging the network, although it will introduce potential packet misordering and jitter, so should not be invoked gratuitously. What I am saying is that with IPFRR, while we should be careful to avoid false indications of failure, the consequences of a false indication are rather less than in the conventional case, and so we can perhaps afford to sail a little closer to the wind. >>>(3) Section 3.1 - advisable to include appropriate references to the >>>numbers of provided for the applicability of each method (if it is an >>>evaluation performed in the scope of the document, corresponding >>>reasoning could be included) >> >>Sorry, I'm confused again. Are you referring to the 80% and 95% numbers >>in section 3.2? Those numbers (or an approximation of them) come from >>Alia's presentation, but they are supported by my own simulations of real >>world networks. > >yes this is what i meant by adding the references OK. >>>(4) Section 3.2.2 concerning the discussions on link versus node >>>protection - Discussion about multiple adjacencies b/w two nodes >>>should be also covered nodes >>Sorry, I don't understand. Do you mean something like the material >>covered in section 4.6.2 of >>http://www.ietf.org/internet-drafts/draft-bryant-ipfrr-tunnels-00.txt > >sorry for the typo in the above sentence, i was referring to the >discussion concerning multiple adjacencies b/w two nodes > >>Although that is explicitly the ECMP case. You could have parallel links >>with different costs (why I don't know). > >yes - it is a generic 4.6.2 (sub-case 1) case - as an another example one >may point out to (and subsequent): > Yes such information hiding is standard practise, but I don't think it matters here because (depending on the level of abstraction at which you view it), the local router which detects the failure does have the information about the potential multiple paths even though it has chosen not to advertise those links in its LSP/As. There is a LOT of such detailed discussion which COULD be included in the framework, but my initial brief was to keep it very concise. I therefore omitted such material from the first draft. We need to decide as a WG whether we want to keep the framework in that style, or whether we want to make it a comprehensive treatise on every aspect of the subject. i.e. which are the important aspects. >and it would be advisable to have a (small) discussion upon the tradeoff >between making them "invisible" wrt to capacity of loop free alternates >computation > >>>(5) Processing in case of failure of the loop free alternates, since the >>>failure probability of the alternates should not be different from the >>>failure probability of the primary path(s) >>Again, could you expand on that please? > >document focuses on pre-computation of alternates for the primary path in >case of failure, it doesn't say anything related to the maintenance of >these alternates Yes. That's an omission. Alex has already mentioned that to me. There are (at least) two things which need to be mentioned: 1) Once you have invoked repair paths, when do you stop using them? The simple answer is when they are no longer needed because the network has reconverged and no traffic is being directed towards them. 2) When do you recompute new repair paths? Again you do this when the network has reconverged. There is no particular hurry to perform these computations (which could be extensive) and so they would typically be performed as a background task. The only important factor (and perhaps what you were alluding to with your first comment) is that until you have completed this recomputation you are exposed to a "second" failure occurring in the network. >>>(6) Editorial comments >>> >>>- from the introduction "This is analogous to the technique employed by >>>MPLS Fast Reroute [MPLSFRR], but the mechanisms employed for the backup >>>routes in pure IP networks are necessarily very different." i don't >>>perceive the real intent of this sentence >>It was to give readers an idea that the concept of rapidly switching to a >>pre-computed backup path was similar to something with which they are >>familiar (i.e. MPLS FRR), but pointing out that the way the backup paths >>is computed is very different. > >ok > >>>- section 3.3 "A number of solutions to the problem of micro-loop >>>formation have been proposed." would you provide some material/ref's ? >>See section 6 of >>http://www.ietf.org/internet-drafts/draft-bryant-ipfrr-tunnels-00.txt > >ok > >thanks (if there are points that are still unclear please let me know) >- dimitri. > >>>thanks for the clarifications, >>>- dimitri. >> >>Thanks for the comments. >> Mike >> >> >>>--- >>> >>>Alex Zinin wrote: >>> >>>>Folks- >>>> Mike wrote the first draft of the IP FRR framework that was mentioned >>>> earlier. >>>> I've reviewed the draft, believe that it is very well written, and >>>> serves the >>>> purpose as the basis for the corresponding work item. I suggest that this >>>> document becomes a WG item with Mike as the editor. >>>> Please send your comments within two weeks (by June 4th, 2004.) >>> >>> >>>-- >>>Papadimitriou Dimitri >>>E-mail : dimitri.papadimitriou@alcatel.be >>>E-mail : dpapadimitriou@psg.com >>>Webpage: http://psg.com/~dpapadimitriou/ >>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >>>Phone : +32 3 240-8491 >>> >>> >>> >>>_______________________________________________ >>>Rtgwg mailing list >>>Rtgwg@ietf.org >>>https://www1.ietf.org/mailman/listinfo/rtgwg >> >>_______________________________________________ >>Rtgwg mailing list >>Rtgwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/rtgwg > >-- >Papadimitriou Dimitri >E-mail : dimitri.papadimitriou@alcatel.be >E-mail : dpapadimitriou@psg.com >Webpage: http://psg.com/~dpapadimitriou/ >Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >Phone : +32 3 240-8491 > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From exim@www1.ietf.org Mon May 24 09:56:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06674 for ; Mon, 24 May 2004 09:56:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFl7-00024H-Ko for rtgwg-archive@odin.ietf.org; Mon, 24 May 2004 09:44:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ODirpN007945 for rtgwg-archive@odin.ietf.org; Mon, 24 May 2004 09:44:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFeq-0001O4-O2 for rtgwg-web-archive@optimus.ietf.org; Mon, 24 May 2004 09:38:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05458 for ; Mon, 24 May 2004 09:38:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSFeo-0004dR-SK for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 09:38:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSFdv-0004Zv-00 for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 09:37:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSFdR-0004Xq-00 for rtgwg-web-archive@ietf.org; Mon, 24 May 2004 09:36:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFQy-0007tZ-Fl; Mon, 24 May 2004 09:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFKu-0006pB-Ut for rtgwg@optimus.ietf.org; Mon, 24 May 2004 09:17:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04351 for ; Mon, 24 May 2004 09:17:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSFKt-0003Iy-C8 for rtgwg@ietf.org; Mon, 24 May 2004 09:17:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSFJg-0002yh-00 for rtgwg@ietf.org; Mon, 24 May 2004 09:16:33 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1BSFJB-0002g8-00 for rtgwg@ietf.org; Mon, 24 May 2004 09:16:01 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i4ODFU4a020079; Mon, 24 May 2004 06:15:30 -0700 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) with ESMTP id i4ODFRaS020076; Mon, 24 May 2004 06:15:27 -0700 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Mon, 24 May 2004 06:15:27 -0700 (PDT) From: Tony Tauber To: Alex Zinin cc: Jeffrey Haas , "Joel M. Halpern" , rtgwg@ietf.org Subject: Re: GTSM to STD track? In-Reply-To: <6110631371.20040521231031@psg.com> Message-ID: References: <5.1.0.14.0.20040520181521.02400630@localhost> <20040521181646.GA18957@nexthop.com> <6110631371.20040521231031@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtgwg-admin@ietf.org Errors-To: rtgwg-admin@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Fri, 21 May 2004, Alex Zinin wrote: > To add to Jeff's points: > > We do change bits on the wire (TTL setting) and the input packet > processing rules (packet discrimination, ICMP generation.) > > As an interop-related ramification, following or not following the > spec will also affect: > > a) whether the receiving side (using GTSM) accepts your packets > with TTL < 255, or (in the extreme case) drops them on the floor, > AND: > > b) whether the GSTM-enabled side can expect the other side to > cooperate and hence whether a certain level of DoS protection can > be assumed. Would something change based on that assumption? I hadn't thought of it, but might the router CPU stand down from a more defensive posture as a result (eg. regarding treatment of input queues or the like?) If some real decision is made based on this mechanism, one would need some positive capability negotiation, etc. Then concerns about authenticating those messages pop up. I'm inclined to suggest advice against such a presumption unless the mechanism is built into the protocol itself; eg. there are no other modes of operation. > Joel, Tony, does this make sense? > > At the end of the day, the question is: "Is GTSM an important enough > DoS prevention mechanism for the IETF to have Standard on it?" Put that way, it begs the question, "a standard for what?" Is it just for routing protocols or are there other subnet-local cases which could benefit? In terms that spoofing packets from off-net is now considered an expected threat though it wasn't years ago, there's value in "standard-izing". I'm in favor but some thought and words should be put toward applicability. Tony > > That said, if we decide to put it on the STD track, we will > certainly need to review the document with the STD glasses on and > see what changes would be needed. > > -- > Alex _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg