From rtgwg-bounces@ietf.org Tue Nov 2 03:05:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24315 for ; Tue, 2 Nov 2004 03:05:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COtuC-0002sT-Pw for rtgwg-web-archive@ietf.org; Tue, 02 Nov 2004 03:20:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COta2-0005y6-4D; Tue, 02 Nov 2004 02:59:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COtV9-0003l2-4H for rtgwg@megatron.ietf.org; Tue, 02 Nov 2004 02:54:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23342 for ; Tue, 2 Nov 2004 02:54:46 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COtkA-0002fb-Jm for rtgwg@ietf.org; Tue, 02 Nov 2004 03:10:21 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1COtV4-000ODP-GQ for rtgwg@ietf.org; Tue, 02 Nov 2004 07:54:42 +0000 Date: Mon, 1 Nov 2004 23:54:37 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <683979109.20041101235437@psg.com> To: rtgwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Subject: DT announcement: micro-loop prevention X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Folks- A few members of the WG have been discussing different microloop prevention mechanisms recently. To ensure transparency of the process, the WG chairs decided to formalize this effort as a design team (for more information on design teams, please see http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt). In the interest of rapid progress, we decided to keep this DT small and focused. Current members of the design team are listed below: Alia Atlas Don Fedyk Mike Shand Stewart Bryant Chris Martin Joel M. Halpern We can add one or two more persons to the DT. If you believe you can make a useful contribution to the DT, please send me an e-mail and explain what your contribution would be. Requests to join the DT to "ensure being in the loop" will not be satisfied--the DT will report to the WG on a regular basis, and will hand the matter to the WG as a whole after its done with the discussion. At this point the DT has the following milestones: NOV 2004: clarify technical details of proposed methods NOV 2004: present & discuss proposed methods at IETF61 DEC 2004: evaluate micro-loop prevention mechanisms for Basic IPFRR DEC 2004: report its considerations and recommendation to the WG The DT will also update the WG on its results as it progresses. -- Alex http://www.psg.com/~zinin _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Nov 2 12:06:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12361 for ; Tue, 2 Nov 2004 12:06:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2MI-00079H-Lq for rtgwg-web-archive@ietf.org; Tue, 02 Nov 2004 12:22:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1nJ-0006AW-09; Tue, 02 Nov 2004 11:46:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1Wp-0004Fl-JP for rtgwg@megatron.ietf.org; Tue, 02 Nov 2004 11:29:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06883 for ; Tue, 2 Nov 2004 11:29:01 -0500 (EST) Received: from astrolabe.info.ucl.ac.be ([130.104.229.109] helo=info.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1ly-0005pL-7S for rtgwg@ietf.org; Tue, 02 Nov 2004 11:44:42 -0500 Received: from [127.0.0.1] (astrolabe [130.104.229.109]) by info.ucl.ac.be (8.12.11/8.12.11) with ESMTP id iA2GSsvL004705; Tue, 2 Nov 2004 17:28:54 +0100 (MET) From: Olivier Bonaventure To: Alex Zinin In-Reply-To: <683979109.20041101235437@psg.com> References: <683979109.20041101235437@psg.com> Content-Type: text/plain Message-Id: <1099412934.20393.302.camel@pcobo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 02 Nov 2004 17:28:54 +0100 Content-Transfer-Encoding: 7bit X-INGI-MailScanner-Information: Please contact the ISP for more information X-INGI-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Pierre Francois , rtgwg@ietf.org Subject: Re: DT announcement: micro-loop prevention X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Alex, > A few members of the WG have been discussing different microloop prevention > mechanisms recently. To ensure transparency of the process, the WG chairs > decided to formalize this effort as a design team (for more information on > design teams, please see http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt). > In the interest of rapid progress, we decided to keep this DT small and > focused. Current members of the design team are listed below: We have worked a lot on microloop prevention during the last few months. Our approach is somewhat different from the approaches discussed in the mailing list. Basically, we propose some extensions to ISIS/OSPF to allow the routers to determine when they can safely update their FIB to avoid microloops. The extension that we propose is simply to add a new TLV inside the ISIS/OSPF Hello packets. The paper describing this protocol and the proof of the ordering will be presented at INFOCOM 2005 in March. We are currently updating the paper based on the received reviewer's comments. In the mean time, we have placed a draft version of the paper on the web. You can download it from : http://www.info.ucl.ac.be/people/OBO/papers/infocom2005.pdf If you think that this proposal could be useful for the work on microloops or that we could, Pierre and myself, contribute to the design team, let me know. Best regards, Olivier Bonaventure -- CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/ _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Nov 9 09:44:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03042 for ; Tue, 9 Nov 2004 09:44:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXEw-0005Kd-Pd for rtgwg-web-archive@ietf.org; Tue, 09 Nov 2004 09:44:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRX77-0000aC-H2; Tue, 09 Nov 2004 09:36:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRWzQ-00074G-4X for rtgwg@megatron.ietf.org; Tue, 09 Nov 2004 09:28:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01576 for ; Tue, 9 Nov 2004 09:28:53 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRX08-0004yl-OF for rtgwg@ietf.org; Tue, 09 Nov 2004 09:29:43 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRWzL-000JyG-IO for rtgwg@ietf.org; Tue, 09 Nov 2004 14:28:51 +0000 Date: Tue, 9 Nov 2004 09:28:48 -0500 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <24685528.20041109092848@psg.com> To: rtgwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: RTGWG IETF61 Agenda X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit RTGWG will meet: > THURSDAY, November 11, 2004 > 1300-1500 Afternoon Sessions I > Military RTG rtgwg Routing Area Working Group Agenda below: 1. Agenda bashing, aministrivia (chairs) [5m] 00:05 2. Document status (chairs) [5m] 00:10 3. Basic IP FRR spec update (Alia) [15] 00:25 4. IPFRR MIB (Alia) [20m] 00:45 5. Micro-loop prevent DT report (Alia, Mike) [20m] 01:05 Discussion [20m] 01:25 6. Update on draft-atlas-ip-local-protect-uturn (Alia)[20m] 01:45 -- Alex http://www.psg.com/~zinin _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Nov 11 13:53:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11864 for ; Thu, 11 Nov 2004 13:53:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSK60-0001IQ-LX for rtgwg-web-archive@ietf.org; Thu, 11 Nov 2004 13:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSJwD-0008Sq-Ku; Thu, 11 Nov 2004 13:44:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSJs8-0007Qi-DS for rtgwg@megatron.ietf.org; Thu, 11 Nov 2004 13:40:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11059 for ; Thu, 11 Nov 2004 13:40:39 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSJtK-00013B-Of for rtgwg@ietf.org; Thu, 11 Nov 2004 13:41:56 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 3D656E000138; Thu, 11 Nov 2004 18:40:06 +0000 (GMT) Received: from Puppy ([130.129.135.167] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Nov 2004 18:39:09 +0000 Message-ID: <005001c4c81d$d2d7c7a0$a7878182@Puppy> From: "Adrian Farrel" To: , References: <24685528.20041109092848@psg.com> Date: Thu, 11 Nov 2004 18:38:48 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 11 Nov 2004 18:39:09.0127 (UTC) FILETIME=[BB10E570:01C4C81D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: draft-atlas-rtgwg-ipfrr-ip-mib-00.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit A few nits, probably worth getting them out early. 1. Please say "MIB module" not "MIB" 2. As suggested at the mic, do consider SNMP Notifications, but also consider the amount of information overload that might arise on recovery from a single network fault. Probably much more interesting to keep statistics and history about actions and errors. 3. Please split references into normative and informational. I suspect draft-ietf-ipv6-rfc2096-update-07 is needed as a normative reference 4. I agree that write access will be needed for some objects. Adrian _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 15 17:27:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19573 for ; Mon, 15 Nov 2004 17:27:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTpLg-0004Jb-Kb for rtgwg-web-archive@ietf.org; Mon, 15 Nov 2004 17:29:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTpB7-0005Cf-AC; Mon, 15 Nov 2004 17:18:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTp7z-0003sx-UU for rtgwg@megatron.ietf.org; Mon, 15 Nov 2004 17:15:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18524 for ; Mon, 15 Nov 2004 17:15:11 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTp9y-00043o-Ns for rtgwg@ietf.org; Mon, 15 Nov 2004 17:17:23 -0500 Received: from aatlas-lt.avici.com ([10.2.104.65]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAFMEMpr004275 for ; Mon, 15 Nov 2004 17:14:22 -0500 Message-Id: <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 15 Nov 2004 17:13:58 -0500 To: rtgwg@ietf.org From: Alia Atlas 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Stewart, Have you had a chance to look at the questions I sent out about your draft a few weeks ago (now that IETF is over :)? Thanks, Alia >I have a number of questions on your updated draft as follows. > >1) Why is shared risk group protection an explicit non-goal? > a) Is there something about the proposed method which makes it >impractical to provide SRG protection? > b) What is the additional computational complexity to provide such >protection? > c) What are the ramifications of SRGs for the coverage? > >2) From the description of computation, it appears that you must >calculate at a minimum: > 1 reverse SPF per neighbor N_i > 1 reverseSPF per neighbor's neighbor R_i_j > >To handle the extended F-space, you need an additional SPF per >neighbor N_i; this is the same computation needed for loop-free >alternates, though, and so could be assumed as already available. > >4) Tunnel set-up time is also important and should be described. For >the duration of the tunnel set-up time, there will be unprotected >traffic. > >6) You state that this method can provide complete protection against >any single failure (except for single points of failure and asymmetric >link costs), but then have an example for interference between >potential node repair paths. > > a) Are you considering that only link protection is necessary for > the coverage? Do the interference scenarios never exist for > link protection? > b) What is the coverage for node protection with this method? > c) Could you explain the example in Figure 9? I don't see why the > traffic would have a 50% probability of looping. > d) Could you clarify what you are seriously suggesting to avoid the > problem of looping secondary repair paths? What is the > associated computational complexity of that? It seems to be > rather high, depending on the number of routers to which S could > establish repair paths as well as the number of neighbor's > neighbors to which repair paths haven't been established. This > seems to me to be excessively complicated (both to compute and > as a mechanism). > >The number of enhancements and complicated details left out of scope >is certainly a concern. It does seem to me that as you flesh out this >idea, the corner cases make it even more complex. > >On the positive side, I think that the section multi-homed prefixes is >quite useful; the base spec draft should say something about this as well. >The concern about the node failure detection mechanism is interesting >and applies equally to loop-free link-protecting alternates. _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Nov 18 09:45:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29470 for ; Thu, 18 Nov 2004 09:45:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUnaK-0002tv-4O for rtgwg-web-archive@ietf.org; Thu, 18 Nov 2004 09:48:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUnWk-0003Zt-5Z; Thu, 18 Nov 2004 09:44:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUnRD-00027J-CH for rtgwg@megatron.ietf.org; Thu, 18 Nov 2004 09:39:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29032 for ; Thu, 18 Nov 2004 09:39:05 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUnTq-0002kW-JU for rtgwg@ietf.org; Thu, 18 Nov 2004 09:41:51 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2004 15:45:24 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAIEcQeG020234; Thu, 18 Nov 2004 15:38:26 +0100 (MET) Received: from cisco.com (dhcp-rea-gp250-64-103-64-169.cisco.com [64.103.64.169]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA29642; Thu, 18 Nov 2004 14:38:23 GMT Message-ID: <419CB3DE.8050207@cisco.com> Date: Thu, 18 Nov 2004 14:38:22 +0000 From: Stewart Bryant 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: Alia Atlas References: <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> In-Reply-To: <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: 7bit Cc: rtgwg@ietf.org Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: 7bit Alia Atlas wrote: > Stewart, > > Have you had a chance to look at the questions I sent out about your > draft a few weeks ago (now that IETF is over :)? > > Thanks, > Alia > >> I have a number of questions on your updated draft as follows. >> >> 1) Why is shared risk group protection an explicit non-goal? It was a simplification. We were completely sure of the voracity of the scheme in the non-SRLG case, but had not analyzed the SRLG case. We also have concerns about the relative frequency of known SRLGs members vs unknown SRLG members. Clearly if the proportion of unknown SRLG members is significant, then the usefulness of SRLG aware repairs is questionable. We decided that we really needed some answer to this question before pursuing this additional complication to the solution. >> a) Is there something about the proposed method which makes it >> impractical to provide SRG protection? SRLGs require an analysis of the SRLG behavior of the routers on the proposed repair path. This is relatively straight forward since P and Q space can trivially be trimmed to exclude SRLG traversals, but the resultant connectivity may require us to perform a secondary repair analysis. >> b) What is the additional computational complexity to provide such >> protection? Almost nothing if a primary repair is feasible. Then about as much work as a secondary repair calculation per SRLG that must be traversed. >> c) What are the ramifications of SRGs for the coverage? >> It really depends on the topology, but it may result in no solution. However to put this in context, it is not clear that this approach will be worse than any of the other proposed approaches in terms of finding a solution if one exists. Indeed the contrary is more likely i.e. with the longer reach of this approach we are more likely to find a repair where one is possible. >> 2) From the description of computation, it appears that you must >> calculate at a minimum: >> 1 reverse SPF per neighbor N_i >> 1 reverseSPF per neighbor's neighbor R_i_j Correct >> >> To handle the extended F-space, you need an additional SPF per >> neighbor N_i; this is the same computation needed for loop-free >> alternates, though, and so could be assumed as already available. Yes. >> >> 4) Tunnel set-up time is also important and should be described. For >> the duration of the tunnel set-up time, there will be unprotected >> traffic. We do not understand. The tunnel endpoints are set up in advance and only used when needed. To the repairing router a tunnel looks just like any other next-hop and takes the same time to cut over to, and to set up. Of course when this is an MPLS network we have to get the labels, but that is the case for any multi-hop repair strategy and has to be done in advance. >> >> 6) You state that this method can provide complete protection against >> any single failure (except for single points of failure and asymmetric >> link costs), but then have an example for interference between >> potential node repair paths. >> >> a) Are you considering that only link protection is necessary for >> the coverage? No, we need both link and node protection. Do the interference scenarios never exist for link protection? There is no interference to link protection, although with SRLGs this changes. >> b) What is the coverage for node protection with this method? 100% with our normal single point of failure and asymmetric link cost caveats. >> c) Could you explain the example in Figure 9? I don't see why the >> traffic would have a 50% probability of looping. The furthest that S can reach is K - via DF from L. K has an equal cost path split for destination S1 via K-L-S-E-S1 and K-J-I-E-S1. The former path would cause a loop. >> d) Could you clarify what you are seriously suggesting to avoid the >> problem of looping secondary repair paths? We encapsulate to I in the above case. To solve the more general case we need to run a computation at each of the neighbors of E that can be reached via a primary path, until you find a solution. What is the >> associated computational complexity of that? It is highly topology dependent, because as K increases the number of SPFs increases, BUT so does the richness of the connectivity and therefore the search completes earlier. Mike did some analysis of the number of SPFs per node in our set of example topologies. The typical number of SPFs per node was 12, with a worst case of 80 for a tiny number of nodes. However you need to note that most of these SPFs complete as a very small radius - as soon as a solution was found. It seems to be >> rather high, depending on the number of routers to which S could >> establish repair paths as well as the number of neighbor's >> neighbors to which repair paths haven't been established. This >> seems to me to be excessively complicated (both to compute and >> as a mechanism). See above. >> >> The number of enhancements and complicated details left out of scope >> is certainly a concern. It does seem to me that as you flesh out this >> idea, the corner cases make it even more complex. To some extent this is the price of complete coverage. But the alternative of incomplete coverage may be more unpalatable. The SRLG extensions seem to need no new techniques, just greater application of the ones we have already described. >> >> On the positive side, I think that the section multi-homed prefixes is >> quite useful; the base spec draft should say something about this as >> well. Yes. Indeed you could argue that MHPs are the most important prefixes to repair - that is why they were MHP. >> The concern about the node failure detection mechanism is interesting >> and applies equally to loop-free link-protecting alternates. > Yes. - Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Nov 18 12:35:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14644 for ; Thu, 18 Nov 2004 12:35:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUqEa-0006rc-Kq for rtgwg-web-archive@ietf.org; Thu, 18 Nov 2004 12:38:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUq27-00045k-7E; Thu, 18 Nov 2004 12:25:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUpo2-00067q-1G for rtgwg@megatron.ietf.org; Thu, 18 Nov 2004 12:10:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12452 for ; Thu, 18 Nov 2004 12:10:47 -0500 (EST) Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CUpqh-0006Ew-DS for rtgwg@ietf.org; Thu, 18 Nov 2004 12:13:35 -0500 Received: (qmail 77516 invoked from network); 18 Nov 2004 17:10:46 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 18 Nov 2004 17:10:46 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAIHAAMH091528; Thu, 18 Nov 2004 12:10:10 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200411181710.iAIHAAMH091528@workhorse.faster-light.net> To: Stewart Bryant In-reply-to: Your message of "Thu, 18 Nov 2004 14:38:22 GMT." <419CB3DE.8050207@cisco.com> Date: Thu, 18 Nov 2004 12:10:10 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Alia Atlas , rtgwg@ietf.org Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 In message <419CB3DE.8050207@cisco.com> Stewart Bryant writes: > > > We also have concerns about the relative frequency of known SRLGs > members vs unknown SRLG members. Clearly if the proportion of > unknown SRLG members is significant, then the usefulness of SRLG > aware repairs is questionable. We decided that we really needed > some answer to this question before pursuing this additional > complication to the solution. If unknown SRLG is a problem and not supporting SRLG makes all SRLG behave like unknown SRLG, then an approach which does not support SRLG is more problematic than an approach which does support SRLG. The only case where the two are equal (approaches that do and don't support SRLG) is where SRLG do not exist which we know is not the case in any real network. Therefore I think any argument opposing the support of SRLG due to the possibility (or certainty) that unknown SRLG will exist is quite flawed. For example, WDM introduces SRLG that have to be considered for a fast restoration approach to be at all viable. Logical links that traverse hundreds of miles on the same fiber are going to have a high percentage of correlated failure. Curtis ps - we not return you to our regularly scheduled arguments about why SRLG are a hard problem for some approaches. _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Nov 18 14:43:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25581 for ; Thu, 18 Nov 2004 14:43:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUsE0-0001Wy-Mj for rtgwg-web-archive@ietf.org; Thu, 18 Nov 2004 14:45:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUs2b-0005NF-FC; Thu, 18 Nov 2004 14:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUruh-0003FZ-E3 for rtgwg@megatron.ietf.org; Thu, 18 Nov 2004 14:25:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23810 for ; Thu, 18 Nov 2004 14:25:49 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUrxN-0001Am-9A for rtgwg@ietf.org; Thu, 18 Nov 2004 14:28:37 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUruZ-000P5t-IA for rtgwg@ietf.org; Thu, 18 Nov 2004 19:25:43 +0000 Date: Thu, 18 Nov 2004 11:25:41 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <734353544.20041118112541@psg.com> To: rtgwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Content-Transfer-Encoding: 7bit Subject: IETF61 RTGWG Minutes X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Content-Transfer-Encoding: 7bit Thanks to John Scudder for taking the notes. Folks, please review and send your corrections to the list. -- Alex http://www.psg.com/~zinin RTGWG IETF 61 ------------- 1. Agenda bashing, aministrivia (chairs) [5m] 00:05 2. Document status (chairs) [5m] 00:10 RFC 3906 published (informational) GTSM -- more comments need to be integrated, last call before Minneapolis. Implementors please inform mailing list/authors Framework, loopfree, MIB well along. uloop prevention design team constituted (names already sent to list). Desire to keep membership small (already not small, so maybe "less big"). Goal total coverage if possible, extensible if not. Design team to report back by December '04. 3. Basic IP FRR spec update (Alia) [15] 00:25 Document revved to be more of a spec and less of a survey. Need to read framework too because that's where definitions section is! To do: Multihomed prefixes, link selection, SRLG. Need more people to read & comment. Comments to list please. 4. IPFRR MIB (Alia) [20m] 00:45 draft-atlas-ip-local-protect-loopfree-00.txt Only the first of many MIBs. Doesn't cover SRLGs (yet?) Includes protected route table (with NH, alternate NH including alt NH type) Includes unprotected route table (just route and why) Global routing stats (various kinds of route counts) Interface table. Not covered: IGP (IPFRR enabled? local holddown time?), LDP (protected/unprotected FECs, alt NH info including alt label). Other (small) MIBs will probably be needed for these. Please comment on: is this grouping of MIBs appropriate? Alex Zinin: re protected/unprotected route tables, why use a different table instead of augmenting an existing table? Alia: I don't know how to do that, my understanding is you can't really extend a MIB, this one is indexed the same as an IP routing table MIB which I think is as good as it gets. Alex: so how do I use these tables? Joel Halpern: please remember that a MIB is a MIB, it's just used for management purposes, it doesn't drive the implementation. Alex: Are these different sets of routes, will it be recorded twice, once in normal routing table and once in unprotected table? Alia: Yep. Bill Fenner: I will sometimes admit to being MIB-literate. This is the right thing to do. Indexes are dup'd but info isn't. Stewart Bryant: How do we report dynamic info like "repair attempted but failed"? No doubt there will be other dynamic info. Alia: Q is what level to detect, what level to report at. Probably will be in IGP MIB and not this one. Stewart: I think this is really important for O&M, because these faults are transient so we must be very attentive to this issue. Alia: Yep. We need to make sure that we can actually detect the errors we put in the MIB! Stewart: Need to go to ipfix? Maybe doesn't even need to be in MIB. Alia: We should talk about it. Stewart: We'll try to write a draft up about it. Don Fedyk: We did consider that. Error reason is in there but there's no history associated with it. Take a look at what we have and see what needs to be improved on. Stewart: An example of what I'm talking about is we think we have a protection path but when we try to send a packet on it, it fails. Is MIB grouping sensible, are MIBs sensible, please read and comment or you will get what you deserve? Right now draft has u-turn alternates in it, should it include other candidate alternate types? Stewart: First MIB should include basic, where there is common ground, then have a different MIB for advanced. Alia: All I mean is that there is type defined for "u-turn" for alternate type, and a row in interface for "can I break u-turns". Alex: Maybe we should just rename u-turn to "reserved"? Comments to list please. Very few admit to having read it. Alex: We'll ask on the list about making draft a WG doc. David Ward: Who will do IGP MIBs? Alia: Are you volunteering? David: No. Someone from this WG should do the work and then present it to the IGP WGs. Alia: Yep. 5. Micro-loop prevent DT report (Alia, Mike) [20m] 01:05 Discussion [20m] 01:25 draft-bryant-shand-lf-conv-frmwk-00.txt draft-zinin-microloop-analysis-00.txt Mike presenting. Trying to bring order to chaos, we have too many partial solutions right now. Trying to explain, divide solution space into types, consider types, summarize. Basic problem: Microloops resulting from conventional IGP converge-as-fast-as-you-can loses traffic, undoing IPFRR goodness. Reason for uloops: Independent/asynchronous decisions. Loops are temporary! Duration can be much longer than IPFRR time though. Duration driven by relative time to update FIBs (i.e., degree of asynchrony). No way to guarantee two routers will take similar length of time to update FIBs (from one router's PoV the network change may cause just a few routes to change -> fast download, from another PoV many routes may change -> slow download). Solution: Controlled convergence. Inevitably makes convergence slower, but this is OK because IPFRR repair covers failure allowing leisurely convergence. But: still want to keep traditional method as fallback in case of multiple failures. Solution taxonomy: - Controlled information flow (incremental cost change) - Controlled distributed behavior (synchronized FIB installation, ordered FIB changes, path locking) (See slides for full comparison matrix, highlights follow) - Incremental cost change -- can take hours - Synchronized FIB install -- seems simple, but isn't, and dependency on NTP - ordered spf's. no changes in forwarding plane. doesn't deal with SRLG (only single failure is supported). Need to extend algo to a per-destination base. Long delays if large network diameter. Worst case can be pretty long... - path locking. cons: complete coverage requires additional forwarding mechanisms. pros: small delay in rib/fib installation. Detailed description of the above four methods Ordering by signalling Alex: Is node failure a SRLG case? Mike, Alia: No. Node failure can be handled by any of these techniques. Ordering by delay "Lollipop topology" (for example) can make delay-ordered SPF slower than needed (known techniques are more pessimistic than needed). Can combine delay and signalling (optimization of delay-based version, point is that signalling doesn't need to be reliable since delay backs it up) Backwards compatibility is a problem. Alex: how much is it really a problem? Can't you just announce the capability in your IGP and only start using the method when all routers support it? Mike: yes but that means if you infect your network with one router that doesn't support this, you've broken the scheme. Path Locking Three epochs -- change discovery time, use transitional paths time, lock to new topology time. Potential transitional path types -- tunnels, safe neighbors, packet marking, u-turn Sorting out the possibilities -- what are the criteria? Time to be converged (ballpark: 10 sec), simplicity, SRLG support (or really, unpredicted multiple failure coverage), no additional mechanisms beyond IP (may hurt coverage), common additional mechanisms for this and other advanced methods, also work for LDP. Tentative conclusion: - Incremental cost change impractical - Sync'd FIB swap -- skeptical about practicality - Ordered SPF -- long delay, poor SLRG support -- enough to be an issue? - Path locking -- seems most promising, many possibilities (ed: but, maybe it's just that the newest toy is always the shiniest?) - Haven't thought of any new methods this morning but we haven't been to the bar yet - Need more brain power on this, more discussion Danny: Is incremental deployability a hard requirement? Alex: Yeah, and is 100% coverage required? Danny: Sure but is incremental really a hard requirement? Alia: Path locking can be done incremental. You can't have a flag day. Danny: Well not a flag day, but it would be OK to require all routers to have same version of code before solution becomes viable. Alia: But still need to worry about turning it all on Andrew Lange: That's what maintencance windows are for. Voch Kompella: Re sync'd FIB swap -- If requirements were externally provided (and included atomic clocks) problem would be easier. Are we making the problem harder than we have to because we are inventing our own requirements? George Swallow: Are you only worried about clock skew during failure? Mike: Skew isn't the problem, problem is skew in FIB install time. George: So clock sync is not the biggest issue here actually. Mike: Yes although I'm nervous about inter-layer dependencies. Stewart: Well if you can detect that NTP isn't working then you can just disable the loopfree thingy. David Ward: So we've asked for a collection of requirements but have no place to collect them. Alex: Actually we haven't asked for requirements. David: Wow. David: How do you multicast? Mike: General thinking is that you have to get the packet to the other side of the failure, can't just drop it off some place and use the unicast/downstream approaches because of RPF, etc. Bill: Two halves to problem, other half is you need state to know where downstream neighbors are for mcast. So fast repair has to repair that state as well. You can get the packet to the other end of the failure OR get the join state down the repair path real fast. Stewart: We're talking about for the repair, right? For the uloop convergence you have lots of time to fix up the mfib? Everyone: Nope nope. Bill: You're moving the tree around. PIM needs to get access to the new SPF topology before the new FIB is put into use, that might work. Alia: At a minimum we have to not break mcast/make it worse! Secondary question is how to protect mcast too. Alex: So getting back to uloop prevention... David: Design team requested requirements, how are we going to provide them Alex? Alex: Oh, thought you were asking about a requirements document Alex: In particular SPs should try to respond to presenters questions/strawman requirements. SRLGs? Less than full coverage? These are important because they will drive the selection of mechanism. Danny: Where ARE we going to record the requirements? Alex: The mailing list? Alia: The taxonomy doc? Alex: OK. 6. Update on draft-atlas-ip-local-protect-uturn (Alia)[20m] 01:45 Changes: - Explicitly marked packet identification (well known label?). Makes ID'ing potential U-turn packets easier, etc. - Example algorithm for how to look for U-turn alternates. (Worst case is 1 additional SPF per neighbor.) Next?: - Simplify alternate selection - More detailed explanation considering link protection Other suggestions? Other comments? _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 19 07:36:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24670 for ; Fri, 19 Nov 2004 07:36:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV839-0002tl-U1 for rtgwg-web-archive@ietf.org; Fri, 19 Nov 2004 07:39:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV7uG-0006cR-Fu; Fri, 19 Nov 2004 07:30:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV7tM-0006ME-Ez for rtgwg@megatron.ietf.org; Fri, 19 Nov 2004 07:29:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24039 for ; Fri, 19 Nov 2004 07:29:31 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV7wA-0002jo-Ck for rtgwg@ietf.org; Fri, 19 Nov 2004 07:32:28 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2004 13:36:07 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAJCSseG013768; Fri, 19 Nov 2004 13:28:54 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp115.cisco.com [10.61.64.115]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA11337; Fri, 19 Nov 2004 12:28:53 GMT Message-ID: <419DE705.2060100@cisco.com> Date: Fri, 19 Nov 2004 12:28:53 +0000 From: Stewart Bryant 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: curtis@faster-light.net References: <200411181710.iAIHAAMH091528@workhorse.faster-light.net> In-Reply-To: <200411181710.iAIHAAMH091528@workhorse.faster-light.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Alia Atlas , rtgwg@ietf.org Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit OK, we will describe how to handle SRLG in the next version. However unknown SRLGs will affect all solutions, so if SRLG is a MUST, then all solutions need text describing their behavior under conditions of unknown SRLG. In particular unknown SRLG can result in mutually looping repairs (which could even be cyclic) and the solution must describe how to detect and break these loops. Curtis Villamizar wrote: > In message <419CB3DE.8050207@cisco.com> > Stewart Bryant writes: > >> >> >>We also have concerns about the relative frequency of known SRLGs >>members vs unknown SRLG members. Clearly if the proportion of >>unknown SRLG members is significant, then the usefulness of SRLG >>aware repairs is questionable. We decided that we really needed >>some answer to this question before pursuing this additional >>complication to the solution. > > > > If unknown SRLG is a problem and not supporting SRLG makes all SRLG > behave like unknown SRLG, then an approach which does not support SRLG > is more problematic than an approach which does support SRLG. The > only case where the two are equal (approaches that do and don't > support SRLG) is where SRLG do not exist which we know is not the case > in any real network. > > Therefore I think any argument opposing the support of SRLG due to the > possibility (or certainty) that unknown SRLG will exist is quite flawed. > > For example, WDM introduces SRLG that have to be considered for a fast > restoration approach to be at all viable. Logical links that traverse > hundreds of miles on the same fiber are going to have a high > percentage of correlated failure. > > Curtis > > > ps - we not return you to our regularly scheduled arguments about why > SRLG are a hard problem for some approaches. If tunnels were to perform a per prefix search for a two hop solution the results would be identical to that of U-turn. Therefore tunnels are a true superset of the U-turn approach. For simplicity we did not describe this per-prefix search, because we achieved complete coverage without it in all the networks we examined. However give that tunnels are a superset of U-turns, then any SRLG issue applies equally to both. - Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 19 10:34:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12618 for ; Fri, 19 Nov 2004 10:34:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVAp7-0007FH-Hn for rtgwg-web-archive@ietf.org; Fri, 19 Nov 2004 10:37:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVAhW-0001cm-Ib; Fri, 19 Nov 2004 10:29:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVAVd-0006Eo-8B for rtgwg@megatron.ietf.org; Fri, 19 Nov 2004 10:17:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10658 for ; Fri, 19 Nov 2004 10:17:11 -0500 (EST) Received: from relay00.pair.com ([209.68.1.20] helo=relay.pair.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CVAYT-0006qS-Kg for rtgwg@ietf.org; Fri, 19 Nov 2004 10:20:09 -0500 Received: (qmail 65415 invoked from network); 19 Nov 2004 15:17:01 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 19 Nov 2004 15:17:01 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAJFG9To001667; Fri, 19 Nov 2004 10:16:09 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200411191516.iAJFG9To001667@workhorse.faster-light.net> To: Stewart Bryant In-reply-to: Your message of "Fri, 19 Nov 2004 12:28:53 GMT." <419DE705.2060100@cisco.com> Date: Fri, 19 Nov 2004 10:16:09 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Alia Atlas , curtis@faster-light.net, rtgwg@ietf.org Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f In message <419DE705.2060100@cisco.com> Stewart Bryant writes: > > OK, we will describe how to handle SRLG in the next version. > > However unknown SRLGs will affect all solutions, so if > SRLG is a MUST, then all solutions need text describing > their behavior under conditions of unknown SRLG. In > particular unknown SRLG can result in mutually looping > repairs (which could even be cyclic) and the solution > must describe how to detect and break these loops. MPLS RSVP/TE FRR is loop free in the presense of unknown SRLG. At worst the fast restoration fails and a new LSP is needed from ingress to egress. So the worst case is a slow restoration but not a loop. If you meant all IP FRR can be subject to transient looping due to unknown SRLG, then you are correct. That is a consequence of hop-by-hop forwarding. IP itself is subject to transient looping due to correlated failures even without IP FRR. We seemed to have lived with it so far. With the greater empahsis on reliability and fast restoration of service in todays commercial backbones, providers need to be vigilant in maintaining their SRLG database. Its easy to swap circuits and not update the database, etc. I've seen two carriers handle this, one very well and one not very well. Many providers who have leased "disjoint circuits" from a carrier whether internally or external lease (and paid a premium for that) have had them both go down due to failure of a common resource that the carrier failed to consider or had the circuits swapped in a maintenance or circuit grooming such that they were no longer disjoint. This is less a problem the higher up you go on the food chain because the SRLG database is more rigorously maintained. Providers that don't care about fast restoration need not keep an up to date SRLG database, or keep one at all. If so, they are kidding themselves if the run any form of FRR. Just my opinion. I don't know that the WG has decided that SRLG is a MUST. It should be obvious from what I've written that I think its important. > Curtis Villamizar wrote: > > In message <419CB3DE.8050207@cisco.com> > > Stewart Bryant writes: > > > >> > >> > >>We also have concerns about the relative frequency of known SRLGs > >>members vs unknown SRLG members. Clearly if the proportion of > >>unknown SRLG members is significant, then the usefulness of SRLG > >>aware repairs is questionable. We decided that we really needed > >>some answer to this question before pursuing this additional > >>complication to the solution. > > > > > > > > If unknown SRLG is a problem and not supporting SRLG makes all SRLG > > behave like unknown SRLG, then an approach which does not support SRLG > > is more problematic than an approach which does support SRLG. The > > only case where the two are equal (approaches that do and don't > > support SRLG) is where SRLG do not exist which we know is not the case > > in any real network. > > > > Therefore I think any argument opposing the support of SRLG due to the > > possibility (or certainty) that unknown SRLG will exist is quite flawed. > > > > For example, WDM introduces SRLG that have to be considered for a fast > > restoration approach to be at all viable. Logical links that traverse > > hundreds of miles on the same fiber are going to have a high > > percentage of correlated failure. > > > > Curtis > > > > > > ps - we not return you to our regularly scheduled arguments about why > > SRLG are a hard problem for some approaches. > > If tunnels were to perform a per prefix search for a two hop > solution the results would be identical to that of U-turn. > Therefore tunnels are a true superset of the U-turn approach. > For simplicity we did not describe this per-prefix search, > because we achieved complete coverage without it in all the > networks we examined. > > However give that tunnels are a superset of U-turns, then > any SRLG issue applies equally to both. > > - Stewart Could you please explain how a two hop per prefix search addresses SRLG and perhaps address the time complexity of the algorithm. It is not at all clear what sort of algorithm you have in mind from the description above. I'm assuming that this was supposed to be just a quick explanation and you are not suggesting that this would be an adequate entry in the draft to address SRLG. Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 12:48:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26272 for ; Mon, 22 Nov 2004 12:48:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWILn-0004cm-72 for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 12:51:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWID9-0001Q1-JO; Mon, 22 Nov 2004 12:42:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIBj-0001DB-F3 for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 12:41:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25372 for ; Mon, 22 Nov 2004 12:41:15 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWIEK-0003iI-2f for rtgwg@ietf.org; Mon, 22 Nov 2004 12:44:04 -0500 Received: from aatlas-lt.avici.com (b2-pc76.avici.com [10.2.100.76]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAMHdi4I029109; Mon, 22 Nov 2004 12:39:44 -0500 Message-Id: <5.1.0.14.2.20041122115220.0292ba80@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Nov 2004 12:39:15 -0500 To: Stewart Bryant From: Alia Atlas In-Reply-To: <419CB3DE.8050207@cisco.com> References: <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> <5.1.0.14.2.20041115171224.0291bbc8@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-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: rtgwg@ietf.org Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Hi Stewart, At 09:38 AM 11/18/2004, Stewart Bryant wrote: >>>1) Why is shared risk group protection an explicit non-goal? > >It was a simplification. We were completely sure of the voracity >of the scheme in the non-SRLG case, but had not analyzed the >SRLG case. > >We also have concerns about the relative frequency of known SRLGs >members vs unknown SRLG members. Clearly if the proportion of >unknown SRLG members is significant, then the usefulness of SRLG >aware repairs is questionable. We decided that we really needed >some answer to this question before pursuing this additional >complication to the solution. It is useful to consider known SRLGs. This reduces the traffic impact from having SRLGs in the network, and they certainly exist. Nothing is trying to solve uncorrelated failures that happen simultaneously; it's unclear how one would in anything >>> b) What is the additional computational complexity to provide such >>>protection? > >Almost nothing if a primary repair is feasible. Then about as much >work as a secondary repair calculation per SRLG that must be traversed. Presumably, there is the work of either pruning the topology or tracking the SRLGs used in a path. >>>2) From the description of computation, it appears that you must >>>calculate at a minimum: >>> 1 reverse SPF per neighbor N_i >>> 1 reverseSPF per neighbor's neighbor R_i_j > >Correct Does this increase for SRLG coverage or have you not really thought about it? I.e., can the same computation find an alternate with SRLG coverage and, if no such alternate exists, an alternate without SRLG coverage? >>>4) Tunnel set-up time is also important and should be described. For >>>the duration of the tunnel set-up time, there will be unprotected >>>traffic. > >We do not understand. The tunnel endpoints are set up in advance >and only used when needed. To the repairing router a tunnel looks >just like any other next-hop and takes the same time to cut over >to, and to set up. Of course when this is an MPLS network we >have to get the labels, but that is the case for any multi-hop >repair strategy and has to be done in advance. I was referring to three different aspects. One is, as you mention, the extra time for a tunnel approach to obtain the necessary MPLS labels to allow protection of LDP traffic. The second is how are the tunnel endpoints set up in advance? Is this that they are set up when the network is configured to support IP FRR? Do they need to be set up when it is determined that an alternate tunneled to that endpoint is desirable? Third, and more of an internal router issue, is the amount of time that it may take to configure the router to create a way of sending traffic into that tunnel. I am also concerned about the impact of tunnels on fragmentation. There are also the cases where a packet that is tunneled is tunneled again because of a second failure; this isn't supposed to be protected against, but it would be good to not break badly. On the other hand, the draft is suggesting secondary and even tertiary tunnel encapsulation... >>> b) What is the coverage for node protection with this method? > >100% with our normal single point of failure and asymmetric link cost >caveats. K. So can you get 100% coverage for node protection in all 2-connected networks with symmetrical costs? Is this with a single primary repair or are you thinking of secondary etc repairs? What can you get with a single primary repair? >>> c) Could you explain the example in Figure 9? I don't see why the >>> traffic would have a 50% probability of looping. > >The furthest that S can reach is K - via DF from L. >K has an equal cost path split for destination S1 via K-L-S-E-S1 >and K-J-I-E-S1. The former path would cause a loop. Thanks. That made it clearer. >>> d) Could you clarify what you are seriously suggesting to avoid the >>> problem of looping secondary repair paths? > >We encapsulate to I in the above case. To solve the more general case >we need to run a computation at each of the neighbors of E that can >be reached via a primary path, until you find a solution. Aren't you running an SPF rooted at each neighbor of E already for the node protection case to proxy for the destinations that are reached via that neighbor? > What is the >>> associated computational complexity of that? > >It is highly topology dependent, because as K increases the number >of SPFs increases, BUT so does the richness of the connectivity >and therefore the search completes earlier. Mike did some analysis >of the number of SPFs per node in our set of example topologies. >The typical number of SPFs per node was 12, with a worst case of 80 >for a tiny number of nodes. However you need to note that most >of these SPFs complete as a very small radius - as soon as a >solution was found. What was the typical number of neighbors of E in the example topologies? How much of an improvement was this over the worst case of an additional SPF per neighbors' neighbors? > It seems to be >>> rather high, depending on the number of routers to which S could >>> establish repair paths as well as the number of neighbor's >>> neighbors to which repair paths haven't been established. This >>> seems to me to be excessively complicated (both to compute and >>> as a mechanism). > >See above. I'm still not convinced about the complexity of computing and determining these secondary and tertiary repair paths. >>>The number of enhancements and complicated details left out of scope >>>is certainly a concern. It does seem to me that as you flesh out this >>>idea, the corner cases make it even more complex. > >To some extent this is the price of complete coverage. But the alternative >of incomplete coverage may be more unpalatable. The >SRLG extensions seem to need no new techniques, just greater application >of the ones we have already described. Well, I think that you know that I disagree about paying the price of complete coverage in the mechanism. :-) This added complexity feels like overkill; minor changes in network design are sufficient to get there. If you think of the problem as being solved on two fronts - network design and SPF/protocol mechanisms, then the mechanisms needed can be reduced to a manageable complexity. We already have 2 points on the spectrum. In the first point, the mechanism is just ECMP and the bulk of the work is in the network design to get ECMP paths everywhere; this is difficult for network design. Therefore, we have the second point, where loop-free alternates are used and the network design needs to be modified to get loop-free alternates everywhere. This is still considered (by some for some networks) to require too much network design to be practical. That's why we're looking at the advanced methods for IPFRR. Given that asymmetric link costs and SRLGs do exist, it isn't clear that any method short of completely source-routed tunnels will provide guaranteed complete coverage to all 2-connected networks. Certainly none of the others can do so. Then what is the proper level of mechanism complexity versus network design complexity? Is it using a new protocol just to obtain resiliency? We need to arrive at a method that is simpler and easier to use than RSVP-TE source-routed tunnels. Otherwise, the only benefit we'd get from an advanced IPFRR method is that it "isn't MPLS", and that's not sufficient IMHO. >>>On the positive side, I think that the section multi-homed prefixes is >>>quite useful; the base spec draft should say something about this as well. > >Yes. Indeed you could argue that MHPs are the most important prefixes >to repair - that is why they were MHP. Agreed. As I mentioned at IETF, I'd like to include some of this into the loop-free alternates draft. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 13:16:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28661 for ; Mon, 22 Nov 2004 13:16:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWIn0-0007cx-By for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 13:19:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIci-00065R-Sy; Mon, 22 Nov 2004 13:09:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIX8-0004y8-B6 for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 13:03:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27495 for ; Mon, 22 Nov 2004 13:03:23 -0500 (EST) Received: from 67.111.75.190.ptr.us.xo.net ([67.111.75.190] helo=BCNW02.bcn-inc.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWIaZ-0006FO-O9 for rtgwg@ietf.org; Mon, 22 Nov 2004 13:07:00 -0500 Received: from [10.10.20.60] ([10.10.20.60]) by BCNW02.bcn-inc.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Nov 2004 10:02:46 -0800 Message-ID: <41A2297D.7080200@bcn-inc.net> Date: Mon, 22 Nov 2004 10:01:33 -0800 From: Naiming Shen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alia Atlas References: <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> <5.1.0.14.2.20041122115220.0292ba80@pop.avici.com> In-Reply-To: <5.1.0.14.2.20041122115220.0292ba80@pop.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2004 18:02:46.0746 (UTC) FILETIME=[78CF3BA0:01C4D0BD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Alia, > We need to arrive at a method that is simpler and easier to use than > RSVP-TE source-routed tunnels. Otherwise, the only benefit we'd get > from an advanced IPFRR method is that it "isn't MPLS", and that's not > sufficient IMHO. > It does not have to be "MPLS" if you consider the IP TE mechanism though :-) Regards, - Naiming _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 13:31:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00267 for ; Mon, 22 Nov 2004 13:31:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWJ1O-0000fL-5E for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 13:34:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIqX-0000I7-IT; Mon, 22 Nov 2004 13:23:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIjD-0007DI-HW for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 13:15:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28585 for ; Mon, 22 Nov 2004 13:15:52 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWImh-0007bu-Le for rtgwg@ietf.org; Mon, 22 Nov 2004 13:19:32 -0500 Received: from aatlas-lt.avici.com (b2-pc76.avici.com [10.2.100.76]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAMIF54I002745; Mon, 22 Nov 2004 13:15:05 -0500 Message-Id: <5.1.0.14.2.20041122131009.0291fde0@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Nov 2004 13:14:36 -0500 To: Stewart Bryant From: Alia Atlas In-Reply-To: <419DE705.2060100@cisco.com> References: <200411181710.iAIHAAMH091528@workhorse.faster-light.net> <200411181710.iAIHAAMH091528@workhorse.faster-light.net> 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-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: curtis@faster-light.net, rtgwg@ietf.org Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa At 07:28 AM 11/19/2004, Stewart Bryant wrote: >However unknown SRLGs will affect all solutions, so if >SRLG is a MUST, then all solutions need text describing >their behavior under conditions of unknown SRLG. In >particular unknown SRLG can result in mutually looping >repairs (which could even be cyclic) and the solution >must describe how to detect and break these loops. Unknown SRLGs are uncorrelated failures. The detection of uncorrelated failures is by the IGP, which can then install the new primaries as quickly as possible. In the meantime, traffic loops until TTL expires. IPFRR is quite clearly not handling uncorrelated failures; no protection mechanism that I am aware of does. >Curtis Villamizar wrote: > >>ps - we not return you to our regularly scheduled arguments about why >>SRLG are a hard problem for some approaches. > >If tunnels were to perform a per prefix search for a two hop >solution the results would be identical to that of U-turn. >Therefore tunnels are a true superset of the U-turn approach. In terms of alternates provided, but not in terms of forwarding or complexity. >For simplicity we did not describe this per-prefix search, >because we achieved complete coverage without it in all the >networks we examined. > >However give that tunnels are a superset of U-turns, then >any SRLG issue applies equally to both. The algorithm for computing U-turn alternates is a bit different from the algorithm that you are using to look for tunnels. Therefore, the computational impact of SRLGs may be different as well. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 13:36:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00877 for ; Mon, 22 Nov 2004 13:36:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWJ6L-0001Qv-2r for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 13:39:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWJ00-0002tH-KO; Mon, 22 Nov 2004 13:33:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIvB-0001rz-O9 for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 13:28:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29985 for ; Mon, 22 Nov 2004 13:28:15 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWIyg-0000RP-W0 for rtgwg@ietf.org; Mon, 22 Nov 2004 13:31:55 -0500 Received: from aatlas-lt.avici.com (b2-pc76.avici.com [10.2.100.76]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAMIRc4I004280; Mon, 22 Nov 2004 13:27:38 -0500 Message-Id: <5.1.0.14.2.20041122132206.02873048@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Nov 2004 13:27:09 -0500 To: Naiming Shen From: Alia Atlas In-Reply-To: <41A2297D.7080200@bcn-inc.net> References: <5.1.0.14.2.20041122115220.0292ba80@pop.avici.com> <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> <5.1.0.14.2.20041122115220.0292ba80@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-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi Naiming, At 01:01 PM 11/22/2004, Naiming Shen wrote: >>We need to arrive at a method that is simpler and easier to use than >>RSVP-TE source-routed tunnels. Otherwise, the only benefit we'd get from >>an advanced IPFRR method is that it "isn't MPLS", and that's not >>sufficient IMHO. > >It does not have to be "MPLS" if you consider the IP TE mechanism though >:-) Sure. We can have a different protocol in the network solely for resiliency to create those source-routed tunnels with the associated complexity, but at least it wouldn't be MPLS :-) I do think that the complexity of the mechanism we select for an advanced IPFRR method has to be bounded by a consideration of what other potential solutions exist. If a mechanism is more complicated to understand, manage, and configure than RSVP-TE, then I think we need to seriously consider where the benefit is. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 13:44:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01563 for ; Mon, 22 Nov 2004 13:44:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWJEB-0002Ii-DM for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 13:47:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWJ1Z-0003FB-Ut; Mon, 22 Nov 2004 13:34:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIxu-0002LO-K9 for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 13:31:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00285 for ; Mon, 22 Nov 2004 13:31:04 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWJ1P-0000f9-Ib for rtgwg@ietf.org; Mon, 22 Nov 2004 13:34:44 -0500 Received: from aatlas-lt.avici.com (b2-pc76.avici.com [10.2.100.76]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAMIUP4I004588; Mon, 22 Nov 2004 13:30:25 -0500 Message-Id: <5.1.0.14.2.20041122131506.02860bc8@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Nov 2004 13:29:55 -0500 To: curtis@faster-light.net From: Alia Atlas In-Reply-To: <200411191516.iAJFG9To001667@workhorse.faster-light.net> References: 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-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d At 10:16 AM 11/19/2004, Curtis Villamizar wrote: >MPLS RSVP/TE FRR is loop free in the presense of unknown SRLG. At >worst the fast restoration fails and a new LSP is needed from ingress >to egress. So the worst case is a slow restoration but not a loop. This is true, but only for the length of the TE tunnel. TE gets this benefit only because it is an overlay approach; the issue occurs where ever the overlay ends. If one is doing 1 or 2-hop tunnels, then looping is also possible. >If you meant all IP FRR can be subject to transient looping due to >unknown SRLG, then you are correct. That is a consequence of >hop-by-hop forwarding. IP itself is subject to transient looping due >to correlated failures even without IP FRR. We seemed to have lived >with it so far. Part of the question is how often do uncorrelated failures happen as compared to single failures (which could also be a known SRLG)? If uncorrelated failures are relatively rare in comparison, then the trade-off of saving the traffic via an IPFRR alternate for the single failures in exchange for potentially looping saved traffic for an uncorrelated failure seems reasonable to me. >I don't know that the WG has decided that SRLG is a MUST. It should >be obvious from what I've written that I think its important. I also think that SRLGs are important. We do need to have the basic mechanisms understood before trying to add the additional complexity of SRLG handling. I certainly think that the ability to handle SRLGs is an important criterion in considering different approaches. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 14:23:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05141 for ; Mon, 22 Nov 2004 14:23:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWJpu-0006sH-3r for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 14:26:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWJX9-0001E3-DS; Mon, 22 Nov 2004 14:07:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWJRP-0007ew-P0 for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 14:01:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02947 for ; Mon, 22 Nov 2004 14:01:34 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWJUt-0004F6-T5 for rtgwg@ietf.org; Mon, 22 Nov 2004 14:05:13 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 22 Nov 2004 20:09:11 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAMJ0xCu005235; Mon, 22 Nov 2004 20:01:00 +0100 (MET) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4452.cisco.com [10.61.81.99]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA12105; Mon, 22 Nov 2004 19:00:59 GMT Message-Id: <4.3.2.7.2.20041122183226.023823d0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Nov 2004 18:59:50 +0000 To: Alia Atlas From: mike shand In-Reply-To: <5.1.0.14.2.20041122115220.0292ba80@pop.avici.com> References: <419CB3DE.8050207@cisco.com> <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 At 12:39 22/11/2004 -0500, Alia Atlas wrote: >What can you get with a single primary repair? Some examples of the percentage of node repairs which require secondaries below. This is calculated by taking the number of repairs for node repair which require a secondary repair divided by the total number of repairs. Where a repair is a repair to a single neighbor's neighbor. e.g. V | S---------E----U | T The repairs for node E failing would be SV,SU,ST VS,VT,VU etc. 0.79% 13.77% 3.98% 1.47% 0.50% 4.64% 0.00% (Note that the 13% one is a hub and spoke like network which gives only about 70% coverage for U-turns (link repair; I haven't simulated U-turns for node repair). It is quite a nasty topology for any IPFRR mechanism) Mike _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 14:50:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08043 for ; Mon, 22 Nov 2004 14:50:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWKG6-0001jg-LM for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 14:53:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWK6j-0006ms-Px; Mon, 22 Nov 2004 14:44:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWK2q-0005wC-9B for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 14:40:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06929 for ; Mon, 22 Nov 2004 14:40:14 -0500 (EST) Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWK6L-0000A9-Nn for rtgwg@ietf.org; Mon, 22 Nov 2004 14:43:54 -0500 Received: (qmail 62839 invoked from network); 22 Nov 2004 19:40:13 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 22 Nov 2004 19:40:13 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAMJckRc011197; Mon, 22 Nov 2004 14:38:46 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200411221938.iAMJckRc011197@workhorse.faster-light.net> To: Alia Atlas In-reply-to: Your message of "Mon, 22 Nov 2004 13:14:36 EST." <5.1.0.14.2.20041122131009.0291fde0@pop.avici.com> Date: Mon, 22 Nov 2004 14:38:45 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: curtis@faster-light.net, rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 In message <5.1.0.14.2.20041122131009.0291fde0@pop.avici.com> Alia Atlas writes: > > At 07:28 AM 11/19/2004, Stewart Bryant wrote: > >However unknown SRLGs will affect all solutions, so if > >SRLG is a MUST, then all solutions need text describing > >their behavior under conditions of unknown SRLG. In > >particular unknown SRLG can result in mutually looping > >repairs (which could even be cyclic) and the solution > >must describe how to detect and break these loops. > > Unknown SRLGs are uncorrelated failures. The detection of > uncorrelated failures is by the IGP, which can then install the new > primaries as quickly as possible. In the meantime, traffic loops > until TTL expires. > > IPFRR is quite clearly not handling uncorrelated failures; no > protection mechanism that I am aware of does. Alia. I think we have a terminology problem here. Unless I'm mistaken correlated failures are simply ones that happen at about the same time. Just because someone didn't realize that two logical links used a common physical resource (unknown SRLG) doesn't mean the failures were not correlated. For example, when the earthquake outside San Diego took out three of four major fiber paths in the mid 1990s, the failure was definitely correlated. It was not anticipated and would not have been listed in a set of SRLGs but after it happenned it didn't take much to figure out that the failures shared a common cause leading to them occurring at about the same time (correlated with known cause). Failures can also be correlated without a known cause of the correlation. This is when at least initially no one knows why but for some reasons two (or more) circuits are observed failing at the same time. Again there is no SRLG entry. There is work in the literature on handling multiple failures. One simple way is to make path B disjoint with path A. Then make path C disjoint with path A and B. Obviously I'm oversimplifying for illustration. If two correlated failures occur that are not anticipated, then all three paths can't go down. OTOH .. a third failure will take them all down. I don't know that this is considered practical for most data communication problems (perhaps NASA or the military has a need for this - war has a way of causing correlated failures that are not planned for so maybe there is an application, though that is a reason that connectionless networking got started). > >Curtis Villamizar wrote: > > > >>ps - we not return you to our regularly scheduled arguments about why > >>SRLG are a hard problem for some approaches. > > > >If tunnels were to perform a per prefix search for a two hop > >solution the results would be identical to that of U-turn. > >Therefore tunnels are a true superset of the U-turn approach. > > In terms of alternates provided, but not in terms of forwarding or > complexity. > > >For simplicity we did not describe this per-prefix search, > >because we achieved complete coverage without it in all the > >networks we examined. > > > >However give that tunnels are a superset of U-turns, then > >any SRLG issue applies equally to both. > > The algorithm for computing U-turn alternates is a bit different from > the algorithm that you are using to look for tunnels. > > Therefore, the computational impact of SRLGs may be different as well. > > Alia I think what this is leading to is whether it is a requirement that techniques address SRLG and if so whether it is also a requirment that the proposed SRLG solution (or overall solution) is computational practical. The latter would seem to be consistent with routing area scalability requirements. Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 14:52:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08206 for ; Mon, 22 Nov 2004 14:52:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWKIT-0001mP-PY for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 14:56:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWK6n-0006pv-NJ; Mon, 22 Nov 2004 14:44:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWK4g-0006Al-KR for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 14:42:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07258 for ; Mon, 22 Nov 2004 14:42:09 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWK8C-0000Y2-G6 for rtgwg@ietf.org; Mon, 22 Nov 2004 14:45:48 -0500 Received: from aatlas-lt.avici.com (b2-pc76.avici.com [10.2.100.76]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAMJfX4I016837; Mon, 22 Nov 2004 14:41:33 -0500 Message-Id: <5.1.0.14.2.20041122143832.02937958@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Nov 2004 14:41:02 -0500 To: mike shand From: Alia Atlas In-Reply-To: <4.3.2.7.2.20041122183226.023823d0@jaws.cisco.com> References: <5.1.0.14.2.20041122115220.0292ba80@pop.avici.com> <419CB3DE.8050207@cisco.com> <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> <5.1.0.14.2.20041115171224.0291bbc8@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-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Mike, Thanks. That's very interesting. For the primary repairs, can you get the percentages that require the directed forwarding? I'm curious to see if the benefit comes from less restricted tunnels or the extension via the single end-hop source routing. For the U-turn alternates, on the topologies I've got, I found about 72% node protection. That's a percentage of the src/dest pairs covered. Alia At 01:59 PM 11/22/2004, mike shand wrote: >At 12:39 22/11/2004 -0500, Alia Atlas wrote: >>What can you get with a single primary repair? > > >Some examples of the percentage of node repairs which require secondaries >below. This is calculated by taking the number of repairs for node repair >which require a secondary repair divided by the total number of repairs. >Where a repair is a repair to a single neighbor's neighbor. > >e.g. > V > | >S---------E----U > | > T > >The repairs for node E failing would be > >SV,SU,ST >VS,VT,VU >etc. > > >0.79% >13.77% >3.98% >1.47% >0.50% >4.64% >0.00% > > >(Note that the 13% one is a hub and spoke like network which gives only >about 70% coverage for U-turns (link repair; I haven't simulated U-turns >for node repair). It is quite a nasty topology for any IPFRR mechanism) > > > Mike _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 15:02:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09244 for ; Mon, 22 Nov 2004 15:02:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWKSK-0003Ag-8l for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 15:06:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWKMD-0003GW-CO; Mon, 22 Nov 2004 15:00:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWKBR-0007fb-8q for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 14:49:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07992 for ; Mon, 22 Nov 2004 14:49:07 -0500 (EST) Received: from 67.111.75.190.ptr.us.xo.net ([67.111.75.190] helo=BCNW02.bcn-inc.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWKEw-0001NA-Vd for rtgwg@ietf.org; Mon, 22 Nov 2004 14:52:47 -0500 Received: from [10.10.20.60] ([10.10.20.60]) by BCNW02.bcn-inc.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Nov 2004 11:48:34 -0800 Message-ID: <41A2424C.5050008@bcn-inc.net> Date: Mon, 22 Nov 2004 11:47:24 -0800 From: Naiming Shen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alia Atlas References: <5.1.0.14.2.20041122115220.0292ba80@pop.avici.com> <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> <5.1.0.14.2.20041122115220.0292ba80@pop.avici.com> <5.1.0.14.2.20041122132206.02873048@pop.avici.com> In-Reply-To: <5.1.0.14.2.20041122132206.02873048@pop.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2004 19:48:34.0058 (UTC) FILETIME=[401A2EA0:01C4D0CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Hi Alia, Alia Atlas wrote: > Hi Naiming, > > At 01:01 PM 11/22/2004, Naiming Shen wrote: > >>> We need to arrive at a method that is simpler and easier to use than >>> RSVP-TE source-routed tunnels. Otherwise, the only benefit we'd get >>> from an advanced IPFRR method is that it "isn't MPLS", and that's not >>> sufficient IMHO. >> >> >> It does not have to be "MPLS" if you consider the IP TE mechanism though >> :-) > > > Sure. We can have a different protocol in the network solely for > resiliency to create those source-routed tunnels with the associated > complexity, but at least it wouldn't be MPLS :-) Well, the main purpose is to enable backbone IP tunnels with the capability of TE, IPFRR is just a side effect of that :-) > > I do think that the complexity of the mechanism we select for an > advanced IPFRR method has to be bounded by a consideration of what other > potential solutions exist. > > If a mechanism is more complicated to understand, manage, and configure > than RSVP-TE, then I think we need to seriously consider where the > benefit is. I agree with finding the simpler solution approach, but I disagree that the RSVP-TE or NFRR to be "complicated" solution though... Regards, - Naiming > > Alia > > > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 15:07:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09794 for ; Mon, 22 Nov 2004 15:07:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWKWM-0003cN-8Z for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 15:10:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWKMJ-0003gj-Ve; Mon, 22 Nov 2004 15:00:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWKGN-0008WH-Hw for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 14:54:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08321 for ; Mon, 22 Nov 2004 14:54:14 -0500 (EST) Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWKJt-0001s2-3V for rtgwg@ietf.org; Mon, 22 Nov 2004 14:57:53 -0500 Received: (qmail 91592 invoked from network); 22 Nov 2004 19:54:13 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 22 Nov 2004 19:54:13 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAMJqjID011243; Mon, 22 Nov 2004 14:52:45 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200411221952.iAMJqjID011243@workhorse.faster-light.net> To: Alia Atlas In-reply-to: Your message of "Mon, 22 Nov 2004 13:29:55 EST." <5.1.0.14.2.20041122131506.02860bc8@pop.avici.com> Date: Mon, 22 Nov 2004 14:52:45 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: curtis@faster-light.net, rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 In message <5.1.0.14.2.20041122131506.02860bc8@pop.avici.com> Alia Atlas writes: > > At 10:16 AM 11/19/2004, Curtis Villamizar wrote: > > >MPLS RSVP/TE FRR is loop free in the presense of unknown SRLG. At > >worst the fast restoration fails and a new LSP is needed from ingress > >to egress. So the worst case is a slow restoration but not a loop. > > This is true, but only for the length of the TE tunnel. TE gets this > benefit only because it is an overlay approach; the issue occurs where ever > the overlay ends. If one is doing 1 or 2-hop tunnels, then looping is also > possible. There is still no possibility of routing loops in multiarea TE. Actually it is a benefit of source specified forwarding. So something like NIMROD would have the same benefit even though it is significantly different from MPLS RSVP/TE. NIMROD is not an overlay. > >If you meant all IP FRR can be subject to transient looping due to > >unknown SRLG, then you are correct. That is a consequence of > >hop-by-hop forwarding. IP itself is subject to transient looping due > >to correlated failures even without IP FRR. We seemed to have lived > >with it so far. > > Part of the question is how often do uncorrelated failures happen as > compared to single failures (which could also be a known SRLG)? If > uncorrelated failures are relatively rare in comparison, then the trade-off > of saving the traffic via an IPFRR alternate for the single failures in > exchange for potentially looping saved traffic for an uncorrelated failure > seems reasonable to me. Again - terminology. Uncorrelated failures would be ones that don't happen at the sake time. I still got what you said. Yes the tradeoff is probably worth it. The point that I was trying to make is you *can't* loop with MPLS/TE and you *can* loop with IP even without IP FRR. Looping is really bad since you affect other triaffic if you congest links going around long enough for TTL to expire. > >I don't know that the WG has decided that SRLG is a MUST. It should > >be obvious from what I've written that I think its important. > > I also think that SRLGs are important. We do need to have the basic > mechanisms understood before trying to add the additional complexity of > SRLG handling. I certainly think that the ability to handle SRLGs is an > important criterion in considering different approaches. > > Alia Its nice to be in agreement. A real good question for providers though is given the widespread use of TDM or switched services in low speed, and WDM in high speed networking, is IPFRR useful without SRLG. Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 15:08:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10084 for ; Mon, 22 Nov 2004 15:08:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWKXP-0003zM-SN for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 15:11:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWKNM-0004Ti-AP; Mon, 22 Nov 2004 15:01:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWKLn-0001dZ-Hh for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 14:59:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08853 for ; Mon, 22 Nov 2004 14:59:50 -0500 (EST) Received: from relay00.pair.com ([209.68.1.20] helo=relay.pair.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWKPI-0002dI-KR for rtgwg@ietf.org; Mon, 22 Nov 2004 15:03:29 -0500 Received: (qmail 85810 invoked from network); 22 Nov 2004 19:59:47 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 22 Nov 2004 19:59:47 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAMJwJHP011278; Mon, 22 Nov 2004 14:58:19 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200411221958.iAMJwJHP011278@workhorse.faster-light.net> To: Naiming Shen In-reply-to: Your message of "Mon, 22 Nov 2004 10:01:33 PST." <41A2297D.7080200@bcn-inc.net> Date: Mon, 22 Nov 2004 14:58:19 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Alia Atlas , Stewart Bryant , rtgwg@ietf.org Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 In message <41A2297D.7080200@bcn-inc.net> Naiming Shen writes: > > Alia, > > > We need to arrive at a method that is simpler and easier to use than > > RSVP-TE source-routed tunnels. Otherwise, the only benefit we'd get > > from an advanced IPFRR method is that it "isn't MPLS", and that's not > > sufficient IMHO. > > > > It does not have to be "MPLS" if you consider the IP TE mechanism though > :-) > > Regards, > - Naiming True. But the IP TE is so similar to MPLS TE that the objection to MPLS TE (which I personally think is FUD) involves the effort to manage it. If you configure MPLS TE for zero bandwidth then the main difference is the forwarding. An autoconfig for MPLS TE to set up a tunnel to all IGP nodes (for example) would eliminate any management overhead. If IP FRR were considering such solutions, then that would seem to me to make more sense than IP TE (why reinvent the wheel). Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 15:12:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10638 for ; Mon, 22 Nov 2004 15:12:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWKbX-0004PM-0z for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 15:16:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWKX7-0004MK-9M; Mon, 22 Nov 2004 15:11:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWKWL-00042X-Ik for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 15:10:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10409 for ; Mon, 22 Nov 2004 15:10:44 -0500 (EST) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWKZq-00042R-LO for rtgwg@ietf.org; Mon, 22 Nov 2004 15:14:23 -0500 Received: (qmail 14220 invoked from network); 22 Nov 2004 20:10:43 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 22 Nov 2004 20:10:43 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAMK9EvE011393; Mon, 22 Nov 2004 15:09:14 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200411222009.iAMK9EvE011393@workhorse.faster-light.net> To: mike shand In-reply-to: Your message of "Mon, 22 Nov 2004 18:59:50 GMT." <4.3.2.7.2.20041122183226.023823d0@jaws.cisco.com> Date: Mon, 22 Nov 2004 15:09:14 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Alia Atlas , Stewart Bryant , rtgwg@ietf.org Subject: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a In message <4.3.2.7.2.20041122183226.023823d0@jaws.cisco.com> mike shand writes: > > At 12:39 22/11/2004 -0500, Alia Atlas wrote: > >What can you get with a single primary repair? > > > Some examples of the percentage of node repairs which require secondaries > below. This is calculated by taking the number of repairs for node repair > which require a secondary repair divided by the total number of repairs. > Where a repair is a repair to a single neighbor's neighbor. > > e.g. > V > | > S---------E----U > | > T > > The repairs for node E failing would be > > SV,SU,ST > VS,VT,VU > etc. > > > 0.79% > 13.77% > 3.98% > 1.47% > 0.50% > 4.64% > 0.00% > > > (Note that the 13% one is a hub and spoke like network which gives only > about 70% coverage for U-turns (link repair; I haven't simulated U-turns > for node repair). It is quite a nasty topology for any IPFRR mechanism) > > > Mike So what you are saying seems to be that covering the node disjoint problem is mostly not needed. I think some providers would dispute that (if providers ever did speak up in IETF and if one does please disregard my speculation on what providers might say). Also this does not address SRLG at all which was another part of this thread. Thats why I changed the subject line. You could further split that into node disjoint and SRLG since they are different problems (though the node disjoint problem can be considered a proper subset of SRLG). Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 16:48:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24249 for ; Mon, 22 Nov 2004 16:48:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWM6T-00025N-Te for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 16:52:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWLmj-0005Fb-2X; Mon, 22 Nov 2004 16:31:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWLCP-0001on-V4 for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 15:54:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14702 for ; Mon, 22 Nov 2004 15:54:12 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWLFw-0001d3-EE for rtgwg@ietf.org; Mon, 22 Nov 2004 15:57:52 -0500 Received: from aatlas-lt.avici.com (b2-pc76.avici.com [10.2.100.76]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAMKrS4I028703; Mon, 22 Nov 2004 15:53:28 -0500 Message-Id: <5.1.0.14.2.20041122155108.0291f2e8@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Nov 2004 15:52:56 -0500 To: curtis@faster-light.net From: Alia Atlas In-Reply-To: <200411221938.iAMJckRc011197@workhorse.faster-light.net> References: 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-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: curtis@faster-light.net, rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Curtis, You may be right on the terminology. What about unexpected simultaneous failures? One can do a mechanism, as you said, to protect against a limited number of unexpected simultaneous failures, but not a large or arbitrary number without fair expense. Alia At 02:38 PM 11/22/2004, Curtis Villamizar wrote: >In message <5.1.0.14.2.20041122131009.0291fde0@pop.avici.com> >Alia Atlas writes: > > > > At 07:28 AM 11/19/2004, Stewart Bryant wrote: > > >However unknown SRLGs will affect all solutions, so if > > >SRLG is a MUST, then all solutions need text describing > > >their behavior under conditions of unknown SRLG. In > > >particular unknown SRLG can result in mutually looping > > >repairs (which could even be cyclic) and the solution > > >must describe how to detect and break these loops. > > > > Unknown SRLGs are uncorrelated failures. The detection of > > uncorrelated failures is by the IGP, which can then install the new > > primaries as quickly as possible. In the meantime, traffic loops > > until TTL expires. > > > > IPFRR is quite clearly not handling uncorrelated failures; no > > protection mechanism that I am aware of does. > > >Alia. > >I think we have a terminology problem here. > >Unless I'm mistaken correlated failures are simply ones that happen at >about the same time. Just because someone didn't realize that two >logical links used a common physical resource (unknown SRLG) doesn't >mean the failures were not correlated. For example, when the >earthquake outside San Diego took out three of four major fiber paths >in the mid 1990s, the failure was definitely correlated. It was not >anticipated and would not have been listed in a set of SRLGs but after >it happenned it didn't take much to figure out that the failures >shared a common cause leading to them occurring at about the same time >(correlated with known cause). Failures can also be correlated >without a known cause of the correlation. This is when at least >initially no one knows why but for some reasons two (or more) circuits >are observed failing at the same time. Again there is no SRLG entry. > >There is work in the literature on handling multiple failures. One >simple way is to make path B disjoint with path A. Then make path C >disjoint with path A and B. Obviously I'm oversimplifying for >illustration. If two correlated failures occur that are not >anticipated, then all three paths can't go down. OTOH .. a third >failure will take them all down. I don't know that this is considered >practical for most data communication problems (perhaps NASA or the >military has a need for this - war has a way of causing correlated >failures that are not planned for so maybe there is an application, >though that is a reason that connectionless networking got started). ... >I think what this is leading to is whether it is a requirement that >techniques address SRLG and if so whether it is also a requirment that >the proposed SRLG solution (or overall solution) is computational >practical. The latter would seem to be consistent with routing area >scalability requirements. Yes . Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 16:49:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24364 for ; Mon, 22 Nov 2004 16:49:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWM7A-00027I-9e for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 16:52:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWLn4-0005qp-BZ; Mon, 22 Nov 2004 16:32:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWLJc-0005jv-C2 for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 16:01:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15834 for ; Mon, 22 Nov 2004 16:01:38 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWLN6-0002nm-EP for rtgwg@ietf.org; Mon, 22 Nov 2004 16:05:18 -0500 Received: from aatlas-lt.avici.com (b2-pc76.avici.com [10.2.100.76]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAML0q4I029827; Mon, 22 Nov 2004 16:00:52 -0500 Message-Id: <5.1.0.14.2.20041122155643.0287dca0@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Nov 2004 16:00:20 -0500 To: curtis@faster-light.net From: Alia Atlas In-Reply-To: <200411221952.iAMJqjID011243@workhorse.faster-light.net> References: 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-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: curtis@faster-light.net, rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 At 02:52 PM 11/22/2004, Curtis Villamizar wrote: > > >MPLS RSVP/TE FRR is loop free in the presense of unknown SRLG. At > > >worst the fast restoration fails and a new LSP is needed from ingress > > >to egress. So the worst case is a slow restoration but not a loop. > > > > This is true, but only for the length of the TE tunnel. TE gets this > > benefit only because it is an overlay approach; the issue occurs where > ever > > the overlay ends. If one is doing 1 or 2-hop tunnels, then looping is > also > > possible. > >There is still no possibility of routing loops in multiarea TE. For the traffic in the full overlay. >Actually it is a benefit of source specified forwarding. So something >like NIMROD would have the same benefit even though it is >significantly different from MPLS RSVP/TE. NIMROD is not an overlay. Sure. But this works only for the region where the traffic is following source specified forwarding; as soon as there's a local decision, it's back to the possibility of loops. >Again - terminology. Uncorrelated failures would be ones that don't >happen at the sake time. I still got what you said. > >Yes the tradeoff is probably worth it. The point that I was trying to >make is you *can't* loop with MPLS/TE and you *can* loop with IP even >without IP FRR. Looping is really bad since you affect other triaffic >if you congest links going around long enough for TTL to expire. Any time you go back to hop-by-hop forwarding, you can loop. The only way that MPLS/TE avoids it is with a full overlay. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 16:53:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24869 for ; Mon, 22 Nov 2004 16:53:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMAw-0002u4-LZ for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 16:56:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWLnH-0006AP-9h; Mon, 22 Nov 2004 16:32:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWLMe-0007X9-Kh for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 16:04:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16310 for ; Mon, 22 Nov 2004 16:04:46 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWLQ9-00033K-G4 for rtgwg@ietf.org; Mon, 22 Nov 2004 16:08:27 -0500 Received: from aatlas-lt.avici.com (b2-pc76.avici.com [10.2.100.76]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAML474I030369; Mon, 22 Nov 2004 16:04:07 -0500 Message-Id: <5.1.0.14.2.20041122160056.0286a0c0@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Nov 2004 16:03:35 -0500 To: Naiming Shen From: Alia Atlas In-Reply-To: <41A2424C.5050008@bcn-inc.net> References: <5.1.0.14.2.20041122132206.02873048@pop.avici.com> <5.1.0.14.2.20041122115220.0292ba80@pop.avici.com> <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> <5.1.0.14.2.20041122115220.0292ba80@pop.avici.com> <5.1.0.14.2.20041122132206.02873048@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-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Stewart Bryant , rtgwg@ietf.org Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi Naiming, At 02:47 PM 11/22/2004, Naiming Shen wrote: >>Sure. We can have a different protocol in the network solely for >>resiliency to create those source-routed tunnels with the associated >>complexity, but at least it wouldn't be MPLS :-) > >Well, the main purpose is to enable backbone IP tunnels with the >capability of TE, IPFRR is just a side effect of that :-) Coming full circle, I suppose. :-) If a network is already doing TE and is willing to do the configuration, etc., then it makes sense to use TE Fast-Reroute. Whether the forwarding path is MPLS or IP seems irrelevant to me in that piece of the discussion. >>I do think that the complexity of the mechanism we select for an advanced >>IPFRR method has to be bounded by a consideration of what other potential >>solutions exist. >>If a mechanism is more complicated to understand, manage, and configure >>than RSVP-TE, then I think we need to seriously consider where the benefit is. > >I agree with finding the simpler solution approach, but I disagree that >the RSVP-TE or NFRR to be "complicated" solution though... Since that's what I started with and a requirement for something simpler for those not interested in TE, I do think of it as the upper bound on the acceptable complexity. Whether that makes it "complicated" is a matter of opinion. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 16:53:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24911 for ; Mon, 22 Nov 2004 16:53:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMB5-0002uL-Af for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 16:56:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWLnO-0006KU-Br; Mon, 22 Nov 2004 16:32:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWLOP-0008TJ-CR for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 16:06:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16690 for ; Mon, 22 Nov 2004 16:06:35 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWLRv-0003WR-Sx for rtgwg@ietf.org; Mon, 22 Nov 2004 16:10:16 -0500 Received: from aatlas-lt.avici.com (b2-pc76.avici.com [10.2.100.76]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAML5t4I031901; Mon, 22 Nov 2004 16:05:55 -0500 Message-Id: <5.1.0.14.2.20041122160429.0292f008@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Nov 2004 16:05:22 -0500 To: curtis@faster-light.net From: Alia Atlas In-Reply-To: <200411222009.iAMK9EvE011393@workhorse.faster-light.net> References: 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-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Stewart Bryant , rtgwg@ietf.org, mike shand Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Curtis, I think that Mike's numbers are for the percentage of node failures that can't be repaired with a single primary tunnel+directed forwarding. I.e., it covers the node disjoint case pretty well. Alia At 03:09 PM 11/22/2004, Curtis Villamizar wrote: >In message <4.3.2.7.2.20041122183226.023823d0@jaws.cisco.com> >mike shand writes: > > > > At 12:39 22/11/2004 -0500, Alia Atlas wrote: > > >What can you get with a single primary repair? > > > > > > Some examples of the percentage of node repairs which require secondaries > > below. This is calculated by taking the number of repairs for node repair > > which require a secondary repair divided by the total number of repairs. > > Where a repair is a repair to a single neighbor's neighbor. > > > > e.g. > > V > > | > > S---------E----U > > | > > T > > > > The repairs for node E failing would be > > > > SV,SU,ST > > VS,VT,VU > > etc. > > > > > > 0.79% > > 13.77% > > 3.98% > > 1.47% > > 0.50% > > 4.64% > > 0.00% > > > > > > (Note that the 13% one is a hub and spoke like network which gives only > > about 70% coverage for U-turns (link repair; I haven't simulated U-turns > > for node repair). It is quite a nasty topology for any IPFRR mechanism) > > > > > > Mike > > >So what you are saying seems to be that covering the node disjoint >problem is mostly not needed. I think some providers would dispute >that (if providers ever did speak up in IETF and if one does please >disregard my speculation on what providers might say). > >Also this does not address SRLG at all which was another part of this >thread. Thats why I changed the subject line. You could further >split that into node disjoint and SRLG since they are different >problems (though the node disjoint problem can be considered a proper >subset of SRLG). > >Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 17:50:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01579 for ; Mon, 22 Nov 2004 17:50:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWN4T-0002gy-53 for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 17:54:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMcg-0000fY-It; Mon, 22 Nov 2004 17:25:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMZC-000881-OF for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 17:21:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28370 for ; Mon, 22 Nov 2004 17:21:48 -0500 (EST) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWMcj-0006oR-FR for rtgwg@ietf.org; Mon, 22 Nov 2004 17:25:29 -0500 Received: (qmail 47945 invoked from network); 22 Nov 2004 22:21:48 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 22 Nov 2004 22:21:48 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAMMKA1s012104; Mon, 22 Nov 2004 17:20:14 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200411222220.iAMMKA1s012104@workhorse.faster-light.net> To: Alia Atlas In-reply-to: Your message of "Mon, 22 Nov 2004 15:52:56 EST." <5.1.0.14.2.20041122155108.0291f2e8@pop.avici.com> Date: Mon, 22 Nov 2004 17:20:10 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: curtis@faster-light.net, rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 In message <5.1.0.14.2.20041122155108.0291f2e8@pop.avici.com> Alia Atlas writes: > > Curtis, > > You may be right on the terminology. > > What about unexpected simultaneous failures? One can do a mechanism, as > you said, to protect against a limited number of unexpected simultaneous > failures, but not a large or arbitrary number without fair expense. > > Alia Thats already in another response. Briefly, unexpected simultaneous failures are covered in the literature but the solutions may not be practical for commercial data communications. It usually just called multiple failures in the literature that doesn't specificly address SRLG even where the algorithms would still be applicable with SRLG. Curtis > At 02:38 PM 11/22/2004, Curtis Villamizar wrote: > > >In message <5.1.0.14.2.20041122131009.0291fde0@pop.avici.com> > >Alia Atlas writes: > > > > > > At 07:28 AM 11/19/2004, Stewart Bryant wrote: > > > >However unknown SRLGs will affect all solutions, so if > > > >SRLG is a MUST, then all solutions need text describing > > > >their behavior under conditions of unknown SRLG. In > > > >particular unknown SRLG can result in mutually looping > > > >repairs (which could even be cyclic) and the solution > > > >must describe how to detect and break these loops. > > > > > > Unknown SRLGs are uncorrelated failures. The detection of > > > uncorrelated failures is by the IGP, which can then install the new > > > primaries as quickly as possible. In the meantime, traffic loops > > > until TTL expires. > > > > > > IPFRR is quite clearly not handling uncorrelated failures; no > > > protection mechanism that I am aware of does. > > > > > >Alia. > > > >I think we have a terminology problem here. > > > >Unless I'm mistaken correlated failures are simply ones that happen at > >about the same time. Just because someone didn't realize that two > >logical links used a common physical resource (unknown SRLG) doesn't > >mean the failures were not correlated. For example, when the > >earthquake outside San Diego took out three of four major fiber paths > >in the mid 1990s, the failure was definitely correlated. It was not > >anticipated and would not have been listed in a set of SRLGs but after > >it happenned it didn't take much to figure out that the failures > >shared a common cause leading to them occurring at about the same time > >(correlated with known cause). Failures can also be correlated > >without a known cause of the correlation. This is when at least > >initially no one knows why but for some reasons two (or more) circuits > >are observed failing at the same time. Again there is no SRLG entry. > > > >There is work in the literature on handling multiple failures. One > >simple way is to make path B disjoint with path A. Then make path C > >disjoint with path A and B. Obviously I'm oversimplifying for > >illustration. If two correlated failures occur that are not > >anticipated, then all three paths can't go down. OTOH .. a third > >failure will take them all down. I don't know that this is considered > >practical for most data communication problems (perhaps NASA or the > >military has a need for this - war has a way of causing correlated > >failures that are not planned for so maybe there is an application, > >though that is a reason that connectionless networking got started). > > ... > >I think what this is leading to is whether it is a requirement that > >techniques address SRLG and if so whether it is also a requirment that > >the proposed SRLG solution (or overall solution) is computational > >practical. The latter would seem to be consistent with routing area > >scalability requirements. > > Yes > . > Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 17:51:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01844 for ; Mon, 22 Nov 2004 17:51:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWN5m-0002lp-JE for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 17:55:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMj0-0001zu-E2; Mon, 22 Nov 2004 17:31:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMcC-0000Rz-NK for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 17:24:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28627 for ; Mon, 22 Nov 2004 17:24:53 -0500 (EST) Received: from 67.111.75.190.ptr.us.xo.net ([67.111.75.190] helo=BCNW02.bcn-inc.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMfj-0007Bp-Ar for rtgwg@ietf.org; Mon, 22 Nov 2004 17:28:35 -0500 Received: from [10.10.20.60] ([10.10.20.60]) by BCNW02.bcn-inc.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Nov 2004 14:24:23 -0800 Message-ID: <41A266CA.3080701@bcn-inc.net> Date: Mon, 22 Nov 2004 14:23:06 -0800 From: Naiming Shen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@faster-light.net References: <200411221958.iAMJwJHP011278@workhorse.faster-light.net> In-Reply-To: <200411221958.iAMJwJHP011278@workhorse.faster-light.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2004 22:24:23.0673 (UTC) FILETIME=[04E83690:01C4D0E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: Alia Atlas , Stewart Bryant , rtgwg@ietf.org Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > In message <41A2297D.7080200@bcn-inc.net> > Naiming Shen writes: > >> >>Alia, >> >> >>>We need to arrive at a method that is simpler and easier to use than >>>RSVP-TE source-routed tunnels. Otherwise, the only benefit we'd get >>>from an advanced IPFRR method is that it "isn't MPLS", and that's not >>>sufficient IMHO. >>> >> >> >>It does not have to be "MPLS" if you consider the IP TE mechanism though >>:-) >> >>Regards, >>- Naiming > > > > True. But the IP TE is so similar to MPLS TE that the objection to > MPLS TE (which I personally think is FUD) involves the effort to > manage it. If you configure MPLS TE for zero bandwidth then the main > difference is the forwarding. An autoconfig for MPLS TE to set up a > tunnel to all IGP nodes (for example) would eliminate any management > overhead. If IP FRR were considering such solutions, then that would > seem to me to make more sense than IP TE (why reinvent the wheel). > As I mentioned in the previous email, IP TE is really for the backbone IP tunnels. And IP TE not only handles the IPFRR, it does the IP multicast FRR also, and optionally it can handle LDP and RSVP related MPLS LSPs, since I don't imagine anyone would say they only want pure MPLS solution FRR, no IP solution can be tolerated ;-) On the other hand I will be happy to see a simpler solution even if it can not do IP multicast FRR. Regards, - Naiming > Curtis > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 17:57:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02563 for ; Mon, 22 Nov 2004 17:57:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWNBG-0003fA-0v for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 18:01:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWN2P-0007do-Es; Mon, 22 Nov 2004 17:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMls-0002VC-O6 for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 17:34:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29550 for ; Mon, 22 Nov 2004 17:34:53 -0500 (EST) Received: from 67.111.75.190.ptr.us.xo.net ([67.111.75.190] helo=BCNW02.bcn-inc.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMpP-0008Ty-5l for rtgwg@ietf.org; Mon, 22 Nov 2004 17:38:35 -0500 Received: from [10.10.20.60] ([10.10.20.60]) by BCNW02.bcn-inc.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Nov 2004 14:34:22 -0800 Message-ID: <41A26925.70301@bcn-inc.net> Date: Mon, 22 Nov 2004 14:33:09 -0800 From: Naiming Shen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alia Atlas References: <5.1.0.14.2.20041122132206.02873048@pop.avici.com> <5.1.0.14.2.20041122115220.0292ba80@pop.avici.com> <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> <5.1.0.14.2.20041122115220.0292ba80@pop.avici.com> <5.1.0.14.2.20041122132206.02873048@pop.avici.com> <5.1.0.14.2.20041122160056.0286a0c0@pop.avici.com> In-Reply-To: <5.1.0.14.2.20041122160056.0286a0c0@pop.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2004 22:34:22.0434 (UTC) FILETIME=[69CBE420:01C4D0E3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: Stewart Bryant , rtgwg@ietf.org Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Hi Alia, Alia Atlas wrote: > Hi Naiming, > > At 02:47 PM 11/22/2004, Naiming Shen wrote: > >>> Sure. We can have a different protocol in the network solely for >>> resiliency to create those source-routed tunnels with the associated >>> complexity, but at least it wouldn't be MPLS :-) >> >> >> Well, the main purpose is to enable backbone IP tunnels with the >> capability of TE, IPFRR is just a side effect of that :-) > > > Coming full circle, I suppose. :-) The reason it seems comming to a full circle is that, I keep waiting for a simpler solution, and yet to see one ;-) > If a network is already doing TE and is willing to do the configuration, > etc., then it makes sense to use TE Fast-Reroute. Whether the > forwarding path is MPLS or IP seems irrelevant to me in that piece of > the discussion. I thought that was relevant in this IPFRR discussion, otherwise there is no way the NFRR solution should be outside this discussion. In terms of configuration "complication", it's all relative thing. People need to do comparison for their network in order to reach some conclusion. Also, the NFRR or MPLS TE configuration is mostly implementation issue, majority of that can be automated just like the IPFRR approaches discussed in this working group. Cheers, - Naiming > >>> I do think that the complexity of the mechanism we select for an >>> advanced IPFRR method has to be bounded by a consideration of what >>> other potential solutions exist. >>> If a mechanism is more complicated to understand, manage, and >>> configure than RSVP-TE, then I think we need to seriously consider >>> where the benefit is. >> >> >> I agree with finding the simpler solution approach, but I disagree that >> the RSVP-TE or NFRR to be "complicated" solution though... > > > Since that's what I started with and a requirement for something simpler > for those not interested in TE, I do think of it as the upper bound on > the acceptable complexity. Whether that makes it "complicated" is a > matter of opinion. > > Alia > > > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 17:58:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02602 for ; Mon, 22 Nov 2004 17:58:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWNBs-0003fu-PX for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 18:01:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWN34-00089i-I9; Mon, 22 Nov 2004 17:52:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMnc-0002mo-9t for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 17:36:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29754 for ; Mon, 22 Nov 2004 17:36:41 -0500 (EST) Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWMr6-0000SL-Ix for rtgwg@ietf.org; Mon, 22 Nov 2004 17:40:23 -0500 Received: (qmail 25451 invoked from network); 22 Nov 2004 22:36:39 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 22 Nov 2004 22:36:39 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAMMZ5kC012135; Mon, 22 Nov 2004 17:35:10 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200411222235.iAMMZ5kC012135@workhorse.faster-light.net> To: Alia Atlas In-reply-to: Your message of "Mon, 22 Nov 2004 16:05:22 EST." <5.1.0.14.2.20041122160429.0292f008@pop.avici.com> Date: Mon, 22 Nov 2004 17:35:05 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Stewart Bryant , curtis@faster-light.net, rtgwg@ietf.org, mike shand Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 In message <5.1.0.14.2.20041122160429.0292f008@pop.avici.com> Alia Atlas writes: > > Curtis, > > I think that Mike's numbers are for the percentage of node failures that > can't be repaired with a single primary tunnel+directed forwarding. > > I.e., it covers the node disjoint case pretty well. > > Alia What he's saying is that in the worst case he looked at 13.77% of the cases were not covered by single hop. With 2 hop there is 100% coverage but there is still some question about how computationally feasible the 2 hop algoritm is. I thought the point of this message was to indicate that node disjoint 1) is covered by the 2 hop case, but 2) is low probability. My point was that the node disjoint problem is a subset of the SRLG problem. It is a subset because you can define a SRLG to be all links adjacent to a given node and therefore define the node disjoint case as an SRLG case. The local SRLG problem is also a subset of the SRLG problem. So far only MPLS/TE fully addresses SRLG and it does so very cleanly. If the general SRLG problem is not addressed, the failure to address the problem should at least be acknowledged in the documents. If SRLG is not a requirement for IP FRR, that should at least be stated in the framework document, but the limitations should also be acknowledged. Normally it would be sufficient to list something as future work in the framework but that should be done where algorithms are known and only the protocol bits need to be defined later (and if needed). In this case there is question about whether feasible algorithms exists so the limitation should be acknowledged and not just dismissed. I personally think that an important requirement for an IP FRR technique is that feasible algorithms for SRLG be known so the product of the WG isn't a dead end. So far there doesn't seem to be WG concensus either way. Curtis > At 03:09 PM 11/22/2004, Curtis Villamizar wrote: > > >In message <4.3.2.7.2.20041122183226.023823d0@jaws.cisco.com> > >mike shand writes: > > > > > > At 12:39 22/11/2004 -0500, Alia Atlas wrote: > > > >What can you get with a single primary repair? > > > > > > > > > Some examples of the percentage of node repairs which require secondaries > > > below. This is calculated by taking the number of repairs for node repair > > > which require a secondary repair divided by the total number of repairs. > > > Where a repair is a repair to a single neighbor's neighbor. > > > > > > e.g. > > > V > > > | > > > S---------E----U > > > | > > > T > > > > > > The repairs for node E failing would be > > > > > > SV,SU,ST > > > VS,VT,VU > > > etc. > > > > > > > > > 0.79% > > > 13.77% > > > 3.98% > > > 1.47% > > > 0.50% > > > 4.64% > > > 0.00% > > > > > > > > > (Note that the 13% one is a hub and spoke like network which gives only > > > about 70% coverage for U-turns (link repair; I haven't simulated U-turns > > > for node repair). It is quite a nasty topology for any IPFRR mechanism) > > > > > > > > > Mike > > > > > >So what you are saying seems to be that covering the node disjoint > >problem is mostly not needed. I think some providers would dispute > >that (if providers ever did speak up in IETF and if one does please > >disregard my speculation on what providers might say). > > > >Also this does not address SRLG at all which was another part of this > >thread. Thats why I changed the subject line. You could further > >split that into node disjoint and SRLG since they are different > >problems (though the node disjoint problem can be considered a proper > >subset of SRLG). > > > >Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 18:16:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04739 for ; Mon, 22 Nov 2004 18:16:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWNTW-00063H-QM for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 18:20:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWNEJ-0004rM-SV; Mon, 22 Nov 2004 18:04:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWN77-0001It-9k for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 17:56:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02516 for ; Mon, 22 Nov 2004 17:56:50 -0500 (EST) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWNAe-0003dE-VU for rtgwg@ietf.org; Mon, 22 Nov 2004 18:00:33 -0500 Received: (qmail 54942 invoked from network); 22 Nov 2004 22:56:51 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 22 Nov 2004 22:56:51 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAMMtME1012301; Mon, 22 Nov 2004 17:55:22 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200411222255.iAMMtME1012301@workhorse.faster-light.net> To: Naiming Shen In-reply-to: Your message of "Mon, 22 Nov 2004 14:23:06 PST." <41A266CA.3080701@bcn-inc.net> Date: Mon, 22 Nov 2004 17:55:22 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Alia Atlas , curtis@faster-light.net, Stewart Bryant , rtgwg@ietf.org Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 In message <41A266CA.3080701@bcn-inc.net> Naiming Shen writes: > > Curtis Villamizar wrote: > > In message <41A2297D.7080200@bcn-inc.net> > > Naiming Shen writes: > > > >> > >>Alia, > >> > >> > >>>We need to arrive at a method that is simpler and easier to use than > >>>RSVP-TE source-routed tunnels. Otherwise, the only benefit we'd get > >>>from an advanced IPFRR method is that it "isn't MPLS", and that's not > >>>sufficient IMHO. > >>> > >> > >> > >>It does not have to be "MPLS" if you consider the IP TE mechanism though > >>:-) > >> > >>Regards, > >>- Naiming > > > > > > > > True. But the IP TE is so similar to MPLS TE that the objection to > > MPLS TE (which I personally think is FUD) involves the effort to > > manage it. If you configure MPLS TE for zero bandwidth then the main > > difference is the forwarding. An autoconfig for MPLS TE to set up a > > tunnel to all IGP nodes (for example) would eliminate any management > > overhead. If IP FRR were considering such solutions, then that would > > seem to me to make more sense than IP TE (why reinvent the wheel). > > > > As I mentioned in the previous email, IP TE is really for the backbone > IP tunnels. And IP TE not only handles the IPFRR, it does the > IP multicast FRR also, and optionally it can handle LDP and RSVP related > MPLS LSPs, since I don't imagine anyone would say they only want > pure MPLS solution FRR, no IP solution can be tolerated ;-) > > On the other hand I will be happy to see a simpler solution > even if it can not do IP multicast FRR. > > Regards, > - Naiming You definitely have an advantage in providing FRR for IP multicast. I question whether that is a requirement for anyone. FRR seems to be popular among those doing VOIP which is unicase, and VPNs. The VPNs are typically LDP. Often the VOIP resides within an LDP VPN. There is existance proof that you can run VOIP over LDP over MPLS/TE quite nicely and use MPLS FRR. So far there hasn't been a lot of interest in multicast over MPLS because those providers doing MPLS are not seeing a lot of multicast traffic (and some don't offer native multicast) so they are fine with offering multicast over IP with no TE or FRR. Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 18:39:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06633 for ; Mon, 22 Nov 2004 18:39:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWNpV-0000kH-JL for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 18:42:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWNko-0000EM-BD; Mon, 22 Nov 2004 18:37:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWNa1-0007Cg-Ie for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 18:26:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05918 for ; Mon, 22 Nov 2004 18:26:42 -0500 (EST) Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWNdY-0007f1-9L for rtgwg@ietf.org; Mon, 22 Nov 2004 18:30:25 -0500 Received: (qmail 32897 invoked from network); 22 Nov 2004 23:26:41 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 22 Nov 2004 23:26:41 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAMNPC5Z012488; Mon, 22 Nov 2004 18:25:12 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200411222325.iAMNPC5Z012488@workhorse.faster-light.net> To: Naiming Shen In-reply-to: Your message of "Mon, 22 Nov 2004 14:33:09 PST." <41A26925.70301@bcn-inc.net> Date: Mon, 22 Nov 2004 18:25:12 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Alia Atlas , rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe In message <41A26925.70301@bcn-inc.net> Naiming Shen writes: > > > Hi Alia, > > Alia Atlas wrote: > > Hi Naiming, > > > > At 02:47 PM 11/22/2004, Naiming Shen wrote: > > > >>> Sure. We can have a different protocol in the network solely for > >>> resiliency to create those source-routed tunnels with the associated > >>> complexity, but at least it wouldn't be MPLS :-) > >> > >> > >> Well, the main purpose is to enable backbone IP tunnels with the > >> capability of TE, IPFRR is just a side effect of that :-) > > > > > > Coming full circle, I suppose. :-) > > The reason it seems comming to a full circle is that, I keep waiting for > a simpler solution, and yet to see one ;-) I think this work exists due to anti-MPLS sentiment and a need for FRR. The alternative (IP FRR) may be proving to be problematic and the argument that there is something hard about doing MPLS FRR seems to be losing credibility )or maybe just more so when FRR is added to the list of requirements). > > If a network is already doing TE and is willing to do the configuration, > > etc., then it makes sense to use TE Fast-Reroute. Whether the > > forwarding path is MPLS or IP seems irrelevant to me in that piece of > > the discussion. > > I thought that was relevant in this IPFRR discussion, otherwise there is > no way the NFRR solution should be outside this discussion. In terms of > configuration "complication", it's all relative thing. People need to > do comparison for their network in order to reach some conclusion. > Also, the NFRR or MPLS TE configuration is mostly implementation issue, > majority of that can be automated just like the IPFRR approaches > discussed in this working group. > > Cheers, > - Naiming Yep. Agree completely. The requirement *not* to use MPLS may not be based on any technical issue. Anyway we may be either out of scope or committing herasy as far as this WG is concerned. Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 22 20:51:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18951 for ; Mon, 22 Nov 2004 20:51:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWPtc-0001eh-BV for rtgwg-web-archive@ietf.org; Mon, 22 Nov 2004 20:55:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWPp9-0001DF-V2; Mon, 22 Nov 2004 20:50:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWPaE-0006T8-7J for rtgwg@megatron.ietf.org; Mon, 22 Nov 2004 20:35:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17588 for ; Mon, 22 Nov 2004 20:35:04 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWPdk-0007iU-2R for rtgwg@ietf.org; Mon, 22 Nov 2004 20:38:47 -0500 Received: from aatlas-lt.avici.com ([10.2.103.25]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAN1YH4I008681; Mon, 22 Nov 2004 20:34:18 -0500 Message-Id: <5.1.0.14.2.20041122201101.02886df8@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Nov 2004 20:33:48 -0500 To: curtis@faster-light.net From: Alia Atlas In-Reply-To: <200411222235.iAMMZ5kC012135@workhorse.faster-light.net> References: 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-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Stewart Bryant , rtgwg@ietf.org, mike shand Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Curtis, At 05:35 PM 11/22/2004, Curtis Villamizar wrote: >My point was that the node disjoint problem is a subset of the SRLG >problem. It is a subset because you can define a SRLG to be all links >adjacent to a given node and therefore define the node disjoint case >as an SRLG case. The local SRLG problem is also a subset of the SRLG >problem. Local SRLGs and node disjoint are easier cases to handle than general SRLGs. Certainly, if one solves the general case, those can come for free. One issue that I see for the non-source-routed tunnel based approach is that it uses the original next-next-hop as a proxy for a set of destinations. It is possible that the path from the next-next-hop to a particular destination will not be available because it traverses a link in the same SRLG. I think that this may make the destination assignment a bit trickier. >So far only MPLS/TE fully addresses SRLG and it does so very cleanly. In a full overlay, MPLS/TE requires a CSPF per IGP node. If we were willing to accept an SPF per node in the topology, then looking at SRLGs would be a lot simpler! If I were even willing to accept an SPF per neighbors' neighbor, it would be completely clear how to do SRLGs for U-turn alternates. The computational complexity for MPLS/TE can be quite large, depending on the number of tunnels to be considered. Sure, one can use techniques to minimize the impact, but it is there. I'd say it's clear that for IP FRR, there's a desire to have substantially fewer SPFs than 1 per node. There is the basic fact that without source-based routing, it might not be possible to find an alternate. >If the general SRLG problem is not addressed, the failure to address >the problem should at least be acknowledged in the documents. If SRLG >is not a requirement for IP FRR, that should at least be stated in the >framework document, but the limitations should also be acknowledged. > >Normally it would be sufficient to list something as future work in >the framework but that should be done where algorithms are known and >only the protocol bits need to be defined later (and if needed). In >this case there is question about whether feasible algorithms exists >so the limitation should be acknowledged and not just dismissed. I guess it depends on the particular technique considered, but there are feasible algorithms for some of them. For loop-free alternates, one can track the SRLGs traversed by each neighbor, and decide whether to use a loop-free neighbor based on whether the SRLGs of concern are passed. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Nov 23 04:45:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21089 for ; Tue, 23 Nov 2004 04:45:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWXIq-0004My-Km for rtgwg-web-archive@ietf.org; Tue, 23 Nov 2004 04:49:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWXDQ-0003jE-DW; Tue, 23 Nov 2004 04:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWXAn-0002xN-Hn for rtgwg@megatron.ietf.org; Tue, 23 Nov 2004 04:41:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20920 for ; Tue, 23 Nov 2004 04:41:18 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWXEP-0003yD-Vk for rtgwg@ietf.org; Tue, 23 Nov 2004 04:45:06 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 23 Nov 2004 10:49:09 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAN9ehCu005580; Tue, 23 Nov 2004 10:40:43 +0100 (MET) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4407.cisco.com [10.61.81.54]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA06172; Tue, 23 Nov 2004 09:40:40 GMT Message-Id: <4.3.2.7.2.20041123085914.023cddc8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Nov 2004 09:40:33 +0000 To: Alia Atlas From: mike shand In-Reply-To: <5.1.0.14.2.20041122160429.0292f008@pop.avici.com> References: <200411222009.iAMK9EvE011393@workhorse.faster-light.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: curtis@faster-light.net, Stewart Bryant , rtgwg@ietf.org Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b At 16:05 22/11/2004 -0500, Alia Atlas wrote: >Curtis, > >I think that Mike's numbers are for the percentage of node failures that >can't be repaired with a single primary tunnel+directed forwarding. Correct. Yes I was puzzled by Curtis' comment too. What these figures say is that MOST node failures can be repaired using primary tunnels only, and that the remaining few percent can be repaired using a secondary tunnel. i.e. repair to one neighbor's neighbor and then let that node repair again. (note that this is not nested tunnel encapsulation, since the packet is decapsulated before being re-encapsulated. Indeed, it is often the case that one (or even both) of the repairs would not need tunnels at all. i.e. both the primary and secondary repair could be LFAs. But note that to avoid the problem with looping secondaries we would encap the first repair, although this isn't strictly necessary in all topologies; it could be avoided in some topologies at the expense of extra computation (to determine if it were necessary). Mike Alia, these may not be in the form you would like (but since I have them to hand....). These are the same networks as before. df% is the percentage of repairs which required directed forwarding (the same as before, the fraction of individual repairs which needed DF). LFA% is the percentage which simply used LFA (i.e. no tunnels) Note that is no tunnels for ALL traffic. This doesn't mean that this is the percentage of traffic which would not be tunnelled. That would be much higher, since we can easily do per destination LFA determination. In case that is not clear, let me elaborate for the simple link failure case. We can compute a repair for the failure of SE. Sometimes we can repair ALL traffic (even that with a destination of E) by using LFA. Other times we will need a tunnel to get to E. However, in that case, we can compute the set of destinations which have LFAs, and we would only use the tunnel for the remaining traffic. Of course it would theoretically be possible to compute different tunnels for different destinations, but that is not computational feasible. sec % df% LFA% 0.79% 4.6% 69.4% 13.77% 41.9% 45.5% 3.98% 19.1% 66.3% 1.47% 1.2% 59.3% 0.50% 1.3% 79.4% 4.64% 1.3% 61.9% 0.00% 0.0% 62.6% Mike >I.e., it covers the node disjoint case pretty well. > >Alia > >At 03:09 PM 11/22/2004, Curtis Villamizar wrote: > >>In message <4.3.2.7.2.20041122183226.023823d0@jaws.cisco.com> >>mike shand writes: >> > >> > At 12:39 22/11/2004 -0500, Alia Atlas wrote: >> > >What can you get with a single primary repair? >> > >> > >> > Some examples of the percentage of node repairs which require secondaries >> > below. This is calculated by taking the number of repairs for node repair >> > which require a secondary repair divided by the total number of repairs. >> > Where a repair is a repair to a single neighbor's neighbor. >> > >> > e.g. >> > V >> > | >> > S---------E----U >> > | >> > T >> > >> > The repairs for node E failing would be >> > >> > SV,SU,ST >> > VS,VT,VU >> > etc. >> > >> > >> > 0.79% >> > 13.77% >> > 3.98% >> > 1.47% >> > 0.50% >> > 4.64% >> > 0.00% >> > >> > >> > (Note that the 13% one is a hub and spoke like network which gives only >> > about 70% coverage for U-turns (link repair; I haven't simulated U-turns >> > for node repair). It is quite a nasty topology for any IPFRR mechanism) >> > >> > >> > Mike >> >> >>So what you are saying seems to be that covering the node disjoint >>problem is mostly not needed. I think some providers would dispute >>that (if providers ever did speak up in IETF and if one does please >>disregard my speculation on what providers might say). >> >>Also this does not address SRLG at all which was another part of this >>thread. Thats why I changed the subject line. You could further >>split that into node disjoint and SRLG since they are different >>problems (though the node disjoint problem can be considered a proper >>subset of SRLG). >> >>Curtis > > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Nov 23 05:14:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23375 for ; Tue, 23 Nov 2004 05:14:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWXkr-0008Fq-7y for rtgwg-web-archive@ietf.org; Tue, 23 Nov 2004 05:18:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWXdI-0001bm-Iy; Tue, 23 Nov 2004 05:10:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWXV2-0000OF-SP for rtgwg@megatron.ietf.org; Tue, 23 Nov 2004 05:02:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22307 for ; Tue, 23 Nov 2004 05:02:15 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWXYf-0006gt-SM for rtgwg@ietf.org; Tue, 23 Nov 2004 05:06:03 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 23 Nov 2004 11:10:05 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iANA1gCu011368; Tue, 23 Nov 2004 11:01:42 +0100 (MET) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4407.cisco.com [10.61.81.54]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA06853; Tue, 23 Nov 2004 10:01:41 GMT Message-Id: <4.3.2.7.2.20041123094512.0236a2e0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Nov 2004 10:01:40 +0000 To: curtis@faster-light.net From: mike shand In-Reply-To: <200411222235.iAMMZ5kC012135@workhorse.faster-light.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: Alia Atlas , curtis@faster-light.net, Stewart Bryant , rtgwg@ietf.org Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 At 17:35 22/11/2004 -0500, Curtis Villamizar wrote: >In message <5.1.0.14.2.20041122160429.0292f008@pop.avici.com> >Alia Atlas writes: > > > > Curtis, > > > > I think that Mike's numbers are for the percentage of node failures that > > can't be repaired with a single primary tunnel+directed forwarding. > > > > I.e., it covers the node disjoint case pretty well. > > > > Alia > > >What he's saying is that in the worst case he looked at 13.77% of the >cases were not covered by single hop. With 2 hop there is 100% >coverage but there is still some question about how computationally >feasible the 2 hop algoritm is. Yes. Although there being some question is not the same as it being infeasible. >I thought the point of this message was to indicate that node disjoint >1) is covered by the 2 hop case, but 2) is low probability. Yes. 100% of node failures can be covered by using 2 hop, but that is only necessary in a small percentage of cases in most topologies, although there are some pathological cases where the percentage may be higher. >My point was that the node disjoint problem is a subset of the SRLG >problem. It is a subset because you can define a SRLG to be all links >adjacent to a given node and therefore define the node disjoint case >as an SRLG case. The local SRLG problem is also a subset of the SRLG >problem. Yes. >So far only MPLS/TE fully addresses SRLG and it does so very cleanly. > >If the general SRLG problem is not addressed, the failure to address >the problem should at least be acknowledged in the documents. If SRLG >is not a requirement for IP FRR, that should at least be stated in the >framework document, but the limitations should also be acknowledged. I don't think we have ever said it is not a requirement. So far we have avoided the complication of discussing it until we get some kind of a handle on the simple cases. It has always been the intention to extend the solutions to cover (known) SRLG. As stewart has said, as far as the tunnel method is concerned, the extension to SRLG is relatively straightforward. The computation of F and G space (aka P & Q space) can be trivially extended to excise any sub-trees that traverse any SRLG member. If that finds a solution then we are done. If not it may be necessary to consider "secondary" repairs, and the techniques for doing that are the same as with node repair. This is not surprising, since as you point out node repair is a case of SRLG. >Normally it would be sufficient to list something as future work in >the framework but that should be done where algorithms are known and >only the protocol bits need to be defined later (and if needed). In >this case there is question about whether feasible algorithms exists >so the limitation should be acknowledged and not just dismissed. Yes I see your point. >I personally think that an important requirement for an IP FRR >technique is that feasible algorithms for SRLG be known so the product >of the WG isn't a dead end. So far there doesn't seem to be WG >concensus either way. I would tend to agree. It would be useful to ave some other opinions. Mike >Curtis > > > > At 03:09 PM 11/22/2004, Curtis Villamizar wrote: > > > > >In message <4.3.2.7.2.20041122183226.023823d0@jaws.cisco.com> > > >mike shand writes: > > > > > > > > At 12:39 22/11/2004 -0500, Alia Atlas wrote: > > > > >What can you get with a single primary repair? > > > > > > > > > > > > Some examples of the percentage of node repairs which require > secondaries > > > > below. This is calculated by taking the number of repairs for node > repair > > > > which require a secondary repair divided by the total number of > repairs. > > > > Where a repair is a repair to a single neighbor's neighbor. > > > > > > > > e.g. > > > > V > > > > | > > > > S---------E----U > > > > | > > > > T > > > > > > > > The repairs for node E failing would be > > > > > > > > SV,SU,ST > > > > VS,VT,VU > > > > etc. > > > > > > > > > > > > 0.79% > > > > 13.77% > > > > 3.98% > > > > 1.47% > > > > 0.50% > > > > 4.64% > > > > 0.00% > > > > > > > > > > > > (Note that the 13% one is a hub and spoke like network which gives only > > > > about 70% coverage for U-turns (link repair; I haven't simulated > U-turns > > > > for node repair). It is quite a nasty topology for any IPFRR > mechanism) > > > > > > > > > > > > Mike > > > > > > > > >So what you are saying seems to be that covering the node disjoint > > >problem is mostly not needed. I think some providers would dispute > > >that (if providers ever did speak up in IETF and if one does please > > >disregard my speculation on what providers might say). > > > > > >Also this does not address SRLG at all which was another part of this > > >thread. Thats why I changed the subject line. You could further > > >split that into node disjoint and SRLG since they are different > > >problems (though the node disjoint problem can be considered a proper > > >subset of SRLG). > > > > > >Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Nov 23 05:18:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23868 for ; Tue, 23 Nov 2004 05:18:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWXoM-0000E5-FT for rtgwg-web-archive@ietf.org; Tue, 23 Nov 2004 05:22:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWXgP-00026N-VX; Tue, 23 Nov 2004 05:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWXc4-0001Oj-KN for rtgwg@megatron.ietf.org; Tue, 23 Nov 2004 05:09:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22930 for ; Tue, 23 Nov 2004 05:09:26 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWXff-0007UC-0f for rtgwg@ietf.org; Tue, 23 Nov 2004 05:13:15 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 23 Nov 2004 11:17:18 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iANA8tCu013288; Tue, 23 Nov 2004 11:08:55 +0100 (MET) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4407.cisco.com [10.61.81.54]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA07061; Tue, 23 Nov 2004 10:08:54 GMT Message-Id: <4.3.2.7.2.20041123100156.02c5cac8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Nov 2004 10:08:53 +0000 To: Alia Atlas From: mike shand In-Reply-To: <5.1.0.14.2.20041122201101.02886df8@pop.avici.com> References: <200411222235.iAMMZ5kC012135@workhorse.faster-light.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: curtis@faster-light.net, Stewart Bryant , rtgwg@ietf.org Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 At 20:33 22/11/2004 -0500, Alia Atlas wrote: >Curtis, > >At 05:35 PM 11/22/2004, Curtis Villamizar wrote: >>My point was that the node disjoint problem is a subset of the SRLG >>problem. It is a subset because you can define a SRLG to be all links >>adjacent to a given node and therefore define the node disjoint case >>as an SRLG case. The local SRLG problem is also a subset of the SRLG >>problem. > >Local SRLGs and node disjoint are easier cases to handle than general >SRLGs. Certainly, if one solves the general case, those can come for free. Yes. >One issue that I see for the non-source-routed tunnel based approach is >that it uses the original next-next-hop as a proxy for a set of >destinations. It is possible that the path from the next-next-hop to a >particular destination will not be available because it traverses a link >in the same SRLG. > >I think that this may make the destination assignment a bit trickier. Well, by analogy with the node failure case, one way to deal with this is to consider a separate repair to the far side of each SRLG. I'm not sure it is always necessary, but I think it is sufficeient. >>So far only MPLS/TE fully addresses SRLG and it does so very cleanly. > >In a full overlay, MPLS/TE requires a CSPF per IGP node. > >If we were willing to accept an SPF per node in the topology, then looking >at SRLGs would be a lot simpler! Yes! >If I were even willing to accept an SPF per neighbors' neighbor, it would >be completely clear how to do SRLGs for U-turn alternates. > >The computational complexity for MPLS/TE can be quite large, depending on >the number of tunnels to be considered. Sure, one can use techniques to >minimize the impact, but it is there. > >I'd say it's clear that for IP FRR, there's a desire to have substantially >fewer SPFs than 1 per node. Yes, given that some of the networks we have been looking at have getting on for 1000 nodes, that would seem a reasonable assumtption. >There is the basic fact that without source-based routing, it might not be >possible to find an alternate. Yes this is always the problem with what are effectively loose source routing methods (with various restrictions). >>If the general SRLG problem is not addressed, the failure to address >>the problem should at least be acknowledged in the documents. If SRLG >>is not a requirement for IP FRR, that should at least be stated in the >>framework document, but the limitations should also be acknowledged. >> >>Normally it would be sufficient to list something as future work in >>the framework but that should be done where algorithms are known and >>only the protocol bits need to be defined later (and if needed). In >>this case there is question about whether feasible algorithms exists >>so the limitation should be acknowledged and not just dismissed. > >I guess it depends on the particular technique considered, but there are >feasible algorithms for some of them. Agreed. >For loop-free alternates, one can track the SRLGs traversed by each >neighbor, and decide whether to use a loop-free neighbor based on whether >the SRLGs of concern are passed. > >Alia > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Nov 23 10:35:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21933 for ; Tue, 23 Nov 2004 10:35:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWclP-0000Sp-F1 for rtgwg-web-archive@ietf.org; Tue, 23 Nov 2004 10:39:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcRc-0007wa-Mz; Tue, 23 Nov 2004 10:19:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWcKO-0004aZ-AK for rtgwg@megatron.ietf.org; Tue, 23 Nov 2004 10:11:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19096 for ; Tue, 23 Nov 2004 10:11:33 -0500 (EST) Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWcO4-0005iS-8G for rtgwg@ietf.org; Tue, 23 Nov 2004 10:15:24 -0500 Received: (qmail 56420 invoked from network); 23 Nov 2004 15:11:31 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 23 Nov 2004 15:11:31 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iANF9r0t017524; Tue, 23 Nov 2004 10:09:53 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200411231509.iANF9r0t017524@workhorse.faster-light.net> To: mike shand In-reply-to: Your message of "Tue, 23 Nov 2004 10:01:40 GMT." <4.3.2.7.2.20041123094512.0236a2e0@jaws.cisco.com> Date: Tue, 23 Nov 2004 10:09:53 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: Alia Atlas , curtis@faster-light.net, Stewart Bryant , rtgwg@ietf.org Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 In message <4.3.2.7.2.20041123094512.0236a2e0@jaws.cisco.com> mike shand writes: > > At 17:35 22/11/2004 -0500, Curtis Villamizar wrote: > > >In message <5.1.0.14.2.20041122160429.0292f008@pop.avici.com> > >Alia Atlas writes: > > > > > > Curtis, > > > > > > I think that Mike's numbers are for the percentage of node failures that > > > can't be repaired with a single primary tunnel+directed forwarding. > > > > > > I.e., it covers the node disjoint case pretty well. > > > > > > Alia > > > > > >What he's saying is that in the worst case he looked at 13.77% of the > >cases were not covered by single hop. With 2 hop there is 100% > >coverage but there is still some question about how computationally > >feasible the 2 hop algoritm is. > > Yes. Although there being some question is not the same as it being > infeasible. Yes, I agree. As worded "still some question about how computationally feasible ..." simply says that we haven't seen anything that assures us that it is computationally feasible. > >I thought the point of this message was to indicate that node disjoint > >1) is covered by the 2 hop case, but 2) is low probability. > > Yes. 100% of node failures can be covered by using 2 hop, but that is only > necessary in a small percentage of cases in most topologies, although there > are some pathological cases where the percentage may be higher. > > > >My point was that the node disjoint problem is a subset of the SRLG > >problem. It is a subset because you can define a SRLG to be all links > >adjacent to a given node and therefore define the node disjoint case > >as an SRLG case. The local SRLG problem is also a subset of the SRLG > >problem. > > Yes. > > > >So far only MPLS/TE fully addresses SRLG and it does so very cleanly. > > > >If the general SRLG problem is not addressed, the failure to address > >the problem should at least be acknowledged in the documents. If SRLG > >is not a requirement for IP FRR, that should at least be stated in the > >framework document, but the limitations should also be acknowledged. > > I don't think we have ever said it is not a requirement. So far we have > avoided the complication of discussing it until we get some kind of a > handle on the simple cases. It has always been the intention to extend the > solutions to cover (known) SRLG. As stewart has said, as far as the tunnel > method is concerned, the extension to SRLG is relatively straightforward. > The computation of F and G space (aka P & Q space) can be trivially > extended to excise any sub-trees that traverse any SRLG member. If that > finds a solution then we are done. If not it may be necessary to consider > "secondary" repairs, and the techniques for doing that are the same as with > node repair. This is not surprising, since as you point out node repair is > a case of SRLG. > > > >Normally it would be sufficient to list something as future work in > >the framework but that should be done where algorithms are known and > >only the protocol bits need to be defined later (and if needed). In > >this case there is question about whether feasible algorithms exists > >so the limitation should be acknowledged and not just dismissed. > > Yes I see your point. > > > >I personally think that an important requirement for an IP FRR > >technique is that feasible algorithms for SRLG be known so the product > >of the WG isn't a dead end. So far there doesn't seem to be WG > >concensus either way. > > I would tend to agree. It would be useful to ave some other opinions. > > Mike This is a requirements question so it is time for providers who intend to use IP FRR to speak up. Curtis > >Curtis > > > > > > > At 03:09 PM 11/22/2004, Curtis Villamizar wrote: > > > > > > >In message <4.3.2.7.2.20041122183226.023823d0@jaws.cisco.com> > > > >mike shand writes: > > > > > > > > > > At 12:39 22/11/2004 -0500, Alia Atlas wrote: > > > > > >What can you get with a single primary repair? > > > > > > > > > > > > > > > Some examples of the percentage of node repairs which require > > secondaries > > > > > below. This is calculated by taking the number of repairs for node > > repair > > > > > which require a secondary repair divided by the total number of > > repairs. > > > > > Where a repair is a repair to a single neighbor's neighbor. > > > > > > > > > > e.g. > > > > > V > > > > > | > > > > > S---------E----U > > > > > | > > > > > T > > > > > > > > > > The repairs for node E failing would be > > > > > > > > > > SV,SU,ST > > > > > VS,VT,VU > > > > > etc. > > > > > > > > > > > > > > > 0.79% > > > > > 13.77% > > > > > 3.98% > > > > > 1.47% > > > > > 0.50% > > > > > 4.64% > > > > > 0.00% > > > > > > > > > > > > > > > (Note that the 13% one is a hub and spoke like network which gives only > > > > > about 70% coverage for U-turns (link repair; I haven't simulated > > U-turns > > > > > for node repair). It is quite a nasty topology for any IPFRR > > mechanism) > > > > > > > > > > > > > > > Mike > > > > > > > > > > > >So what you are saying seems to be that covering the node disjoint > > > >problem is mostly not needed. I think some providers would dispute > > > >that (if providers ever did speak up in IETF and if one does please > > > >disregard my speculation on what providers might say). > > > > > > > >Also this does not address SRLG at all which was another part of this > > > >thread. Thats why I changed the subject line. You could further > > > >split that into node disjoint and SRLG since they are different > > > >problems (though the node disjoint problem can be considered a proper > > > >subset of SRLG). > > > > > > > >Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Nov 23 11:24:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26969 for ; Tue, 23 Nov 2004 11:24:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWdWF-00075s-OW for rtgwg-web-archive@ietf.org; Tue, 23 Nov 2004 11:27:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWdLO-00067g-99; Tue, 23 Nov 2004 11:16:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWd5q-0001go-K4 for rtgwg@megatron.ietf.org; Tue, 23 Nov 2004 11:00:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24695 for ; Tue, 23 Nov 2004 11:00:36 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWd9W-0003Ut-EX for rtgwg@ietf.org; Tue, 23 Nov 2004 11:04:27 -0500 Received: from aatlas-lt.avici.com (b2-pc76.avici.com [10.2.100.76]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iANFww4I026716; Tue, 23 Nov 2004 10:58:58 -0500 Message-Id: <5.1.0.14.2.20041123105145.02861ad8@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Nov 2004 10:58:33 -0500 To: mike shand From: Alia Atlas In-Reply-To: <4.3.2.7.2.20041123085914.023cddc8@jaws.cisco.com> References: <5.1.0.14.2.20041122160429.0292f008@pop.avici.com> <200411222009.iAMK9EvE011393@workhorse.faster-light.net> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: curtis@faster-light.net, Stewart Bryant , rtgwg@ietf.org Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Mike, The percentage that is missing is then those that require a single primary tunnel for repair? These are the number for repair for node failure? I'm trying to get a sense of what the benefit from LFA is versus the tunnels versus the DF versus the secondary, etc. I'm interested in the different benefits for link protection and for node protection. In a somewhat related question, I understand that you are using a next-next-hop to proxy for destinations. Is it possible that you miss a viable LFA to a destination because of this? I.e., the neighbor may be LFA with respect to the destination but not the next-next-hop? Also, how do you handle the ECMP cases where you may have multiple next-next-hops (even from the same next-hop)? That seems like a per-destination decision. Thanks, Alia At 04:40 AM 11/23/2004, mike shand wrote: >Alia, these may not be in the form you would like (but since I have them >to hand....). > >These are the same networks as before. df% is the percentage of repairs >which required directed forwarding (the same as before, the fraction of >individual repairs which needed DF). LFA% is the percentage which simply >used LFA (i.e. no tunnels) >Note that is no tunnels for ALL traffic. This doesn't mean that this is >the percentage of traffic which would not be tunnelled. That would be much >higher, since we can easily do per destination LFA determination. > >In case that is not clear, let me elaborate for the simple link failure >case. We can compute a repair for the failure of SE. Sometimes we can >repair ALL traffic (even that with a destination of E) by using LFA. Other >times we will need a tunnel to get to E. However, in that case, we can >compute the set of destinations which have LFAs, and we would only use the >tunnel for the remaining traffic. Of course it would theoretically be >possible to compute different tunnels for different destinations, but that >is not computational feasible. > > >sec % df% LFA% >0.79% 4.6% 69.4% >13.77% 41.9% 45.5% >3.98% 19.1% 66.3% >1.47% 1.2% 59.3% >0.50% 1.3% 79.4% >4.64% 1.3% 61.9% >0.00% 0.0% 62.6% _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Nov 23 11:25:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27120 for ; Tue, 23 Nov 2004 11:25:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWdXk-0007Nt-7R for rtgwg-web-archive@ietf.org; Tue, 23 Nov 2004 11:29:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWdLV-0006Ap-63; Tue, 23 Nov 2004 11:16:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWd9j-0002gb-Jw for rtgwg@megatron.ietf.org; Tue, 23 Nov 2004 11:04:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24967 for ; Tue, 23 Nov 2004 11:04:37 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWdDP-0004Bo-5d for rtgwg@ietf.org; Tue, 23 Nov 2004 11:08:28 -0500 Received: from aatlas-lt.avici.com (b2-pc76.avici.com [10.2.100.76]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iANG3v4I027610; Tue, 23 Nov 2004 11:03:58 -0500 Message-Id: <5.1.0.14.2.20041123105932.02885a50@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Nov 2004 11:03:32 -0500 To: mike shand From: Alia Atlas In-Reply-To: <4.3.2.7.2.20041123100156.02c5cac8@jaws.cisco.com> References: <5.1.0.14.2.20041122201101.02886df8@pop.avici.com> <200411222235.iAMMZ5kC012135@workhorse.faster-light.net> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: curtis@faster-light.net, Stewart Bryant , rtgwg@ietf.org Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Mke, At 05:08 AM 11/23/2004, mike shand wrote: >>One issue that I see for the non-source-routed tunnel based approach is >>that it uses the original next-next-hop as a proxy for a set of >>destinations. It is possible that the path from the next-next-hop to a >>particular destination will not be available because it traverses a link >>in the same SRLG. >> >>I think that this may make the destination assignment a bit trickier. > >Well, by analogy with the node failure case, one way to deal with this is >to consider a separate repair to the far side of each SRLG. I'm not sure >it is always necessary, but I think it is sufficeient. But what is the far side of the SRLG? Trimming the trees after they're computed makes some sense, but then it a next-next-hop is dependent on the same SRLG to reach a destination, that destination won't be given an alternate (where there might be one without the proxying). Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Nov 23 11:47:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29039 for ; Tue, 23 Nov 2004 11:47:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWdt4-0001pf-07 for rtgwg-web-archive@ietf.org; Tue, 23 Nov 2004 11:51:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWdhC-00048f-LW; Tue, 23 Nov 2004 11:39:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWdVt-0000xH-5f for rtgwg@megatron.ietf.org; Tue, 23 Nov 2004 11:27:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27329 for ; Tue, 23 Nov 2004 11:27:30 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWdZa-0007Un-0e for rtgwg@ietf.org; Tue, 23 Nov 2004 11:31:22 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 23 Nov 2004 17:35:27 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iANGQwCu027892; Tue, 23 Nov 2004 17:26:58 +0100 (MET) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4407.cisco.com [10.61.81.54]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA22705; Tue, 23 Nov 2004 16:26:57 GMT Message-Id: <4.3.2.7.2.20041123160319.02a89008@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Nov 2004 16:26:55 +0000 To: Alia Atlas From: mike shand In-Reply-To: <5.1.0.14.2.20041123105145.02861ad8@pop.avici.com> References: <4.3.2.7.2.20041123085914.023cddc8@jaws.cisco.com> <5.1.0.14.2.20041122160429.0292f008@pop.avici.com> <200411222009.iAMK9EvE011393@workhorse.faster-light.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: curtis@faster-light.net, Stewart Bryant , rtgwg@ietf.org Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f At 10:58 23/11/2004 -0500, Alia Atlas wrote: >Mike, > >The percentage that is missing is then those that require a single primary >tunnel for repair? These are the number for repair for node failure? Yes, this is all node failure sec % df% LFA% 0.79% 4.6% 69.4% So what this tells us is that 69% of the repair paths required didn't need a tunnel (to get to the nnh), so 31% did require a tunnel. Of these 4.6% need DF as well, and 0.8% required a secondary repair (which itself may have been satisfied by LFA or required DF). > I'm trying to get a sense of what the benefit from LFA is versus the > tunnels versus the DF versus the secondary, etc. I'm interested in the > different benefits for link protection and for node protection. I may have some numbers for link protection.... I should probably re-run the simulations with some better stats, but these will do for now. LFA DF 82% 1% 78% 12% 73% 20% 89% 1% 79% 0% 78% 1% All give 100% protection if DF is used where necessary. Of course secondaries are not necessary for link repair (except perhaps for the case of SRLG). SO what this LFA DF 82% 1% means is that 82% of links can be repaired without using tunnels. 18% require tunnels and these are split with 17% not requiring DF and 1% requiring DF. >In a somewhat related question, I understand that you are using a >next-next-hop to proxy for destinations. Yes. > Is it possible that you miss a viable LFA to a destination because of > this? I.e., the neighbor may be LFA with respect to the destination but > not the next-next-hop? Yes, but that is why I say that in practice we skim the LFA reachable destinations off the top, since that computation falls out of the rest. That way we only tunnel traffic that HAS to be tunnelled. It would of course work if we put this traffic in the tunnel, but it seems sensible to avoid using a tunnel where possible. >Also, how do you handle the ECMP cases where you may have multiple >next-next-hops (even from the same next-hop)? That seems like a >per-destination decision. OK, so you have S------E-----X | Y Traffic for destination D is split through X and Y. You have a choice. If you want to preserve (some semblance of) the ECMP, then you split the traffic between the repair for X and the repair for Y. Or you can simply arbitrarily choose either of X or Y. You have to determine which nnh is used for which destination anyway to do the traffic assignment to the correct repair even when there is no ECMP. You can do this by noting the nnh when you run the normal SPF at S. Mike >Thanks, >Alia > >At 04:40 AM 11/23/2004, mike shand wrote: >>Alia, these may not be in the form you would like (but since I have them >>to hand....). >> >>These are the same networks as before. df% is the percentage of repairs >>which required directed forwarding (the same as before, the fraction of >>individual repairs which needed DF). LFA% is the percentage which simply >>used LFA (i.e. no tunnels) >>Note that is no tunnels for ALL traffic. This doesn't mean that this is >>the percentage of traffic which would not be tunnelled. That would be >>much higher, since we can easily do per destination LFA determination. >> >>In case that is not clear, let me elaborate for the simple link failure >>case. We can compute a repair for the failure of SE. Sometimes we can >>repair ALL traffic (even that with a destination of E) by using LFA. >>Other times we will need a tunnel to get to E. However, in that case, we >>can compute the set of destinations which have LFAs, and we would only >>use the tunnel for the remaining traffic. Of course it would >>theoretically be possible to compute different tunnels for different >>destinations, but that is not computational feasible. >> >> >>sec % df% LFA% >>0.79% 4.6% 69.4% >>13.77% 41.9% 45.5% >>3.98% 19.1% 66.3% >>1.47% 1.2% 59.3% >>0.50% 1.3% 79.4% >>4.64% 1.3% 61.9% >>0.00% 0.0% 62.6% > > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Nov 23 11:58:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00020 for ; Tue, 23 Nov 2004 11:58:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWe3z-0003Sl-0i for rtgwg-web-archive@ietf.org; Tue, 23 Nov 2004 12:02:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWdyQ-0000wM-Rc; Tue, 23 Nov 2004 11:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWdqz-0007b7-6T for rtgwg@megatron.ietf.org; Tue, 23 Nov 2004 11:49:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29201 for ; Tue, 23 Nov 2004 11:49:18 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWduf-0001rq-Dz for rtgwg@ietf.org; Tue, 23 Nov 2004 11:53:10 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 23 Nov 2004 17:57:14 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iANGmjCu004190; Tue, 23 Nov 2004 17:48:46 +0100 (MET) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4407.cisco.com [10.61.81.54]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA23558; Tue, 23 Nov 2004 16:48:45 GMT Message-Id: <4.3.2.7.2.20041123164815.02ac63e0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Nov 2004 16:48:44 +0000 To: Alia Atlas From: mike shand In-Reply-To: <5.1.0.14.2.20041123105932.02885a50@pop.avici.com> References: <4.3.2.7.2.20041123100156.02c5cac8@jaws.cisco.com> <5.1.0.14.2.20041122201101.02886df8@pop.avici.com> <200411222235.iAMMZ5kC012135@workhorse.faster-light.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: curtis@faster-light.net, Stewart Bryant , rtgwg@ietf.org Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 At 11:03 23/11/2004 -0500, Alia Atlas wrote: >Mke, >At 05:08 AM 11/23/2004, mike shand wrote: >>>One issue that I see for the non-source-routed tunnel based approach is >>>that it uses the original next-next-hop as a proxy for a set of >>>destinations. It is possible that the path from the next-next-hop to a >>>particular destination will not be available because it traverses a link >>>in the same SRLG. >>> >>>I think that this may make the destination assignment a bit trickier. >> >>Well, by analogy with the node failure case, one way to deal with this is >>to consider a separate repair to the far side of each SRLG. I'm not sure >>it is always necessary, but I think it is sufficeient. > >But what is the far side of the SRLG? When you run a normal SPF rooted at S, as you traverse each SRLG you will find which is the far side. >Trimming the trees after they're computed makes some sense, but then it a >next-next-hop is dependent on the same SRLG to reach a destination, that >destination won't be given an alternate (where there might be one without >the proxying). It certainly true that proxying reduces your options. Even in the non-SRLG case it is true that if it were the case that a repair was impossible to a proxy it may still be possible for all destinations except that proxy. However, our view is that if the failure is not 100% repairable then it is irreparable, so rather than giving some destinations poorer service it would probably be better not to attempt repair at all for that link. Not that we have seen any such irreparable links in real networks, but that is the principle behind the proxying. In the case of SRLG, this might translate to a case where it was necessary to use secondary repairs because a few destinations could not otherwise be repaired. What this would mean is that we might use a secondary repair for some destinations which (if we had done the whole calculation per destination) could ave been repaired via a single primary repair. This is also true of node failures (which are of course SRLGs in disguse). Mike >Alia > > > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Nov 23 13:40:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07157 for ; Tue, 23 Nov 2004 13:40:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWfeg-0008LN-Dt for rtgwg-web-archive@ietf.org; Tue, 23 Nov 2004 13:44:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWfTW-0007mr-UI; Tue, 23 Nov 2004 13:33:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWfOU-0006VS-Fp for rtgwg@megatron.ietf.org; Tue, 23 Nov 2004 13:28:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06240 for ; Tue, 23 Nov 2004 13:27:58 -0500 (EST) Received: from 67.111.75.190.ptr.us.xo.net ([67.111.75.190] helo=BCNW02.bcn-inc.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWfSC-0006aD-6b for rtgwg@ietf.org; Tue, 23 Nov 2004 13:31:52 -0500 Received: from [10.10.20.60] ([10.10.20.60]) by BCNW02.bcn-inc.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Nov 2004 10:27:26 -0800 Message-ID: <41A380C4.1060107@bcn-inc.net> Date: Tue, 23 Nov 2004 10:26:12 -0800 From: Naiming Shen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@faster-light.net References: <200411222325.iAMNPC5Z012488@workhorse.faster-light.net> In-Reply-To: <200411222325.iAMNPC5Z012488@workhorse.faster-light.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Nov 2004 18:27:26.0022 (UTC) FILETIME=[14F09660:01C4D18A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: Alia Atlas , rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Another issue I have not seen any discussion on the list is how fast the "FRR" can be accomplished on the node for a IPFRR scheme. For MPLS LSPs and it's FRR, a node may only have hundreds or thousands of LSPs, it's not common to see 10s of thousands LSPs using the same interface on a node. For IPFRR, we need to consider maybe half a million routes pointing to the same nexthop, it's very different in scaling comparing to MPLS LSPs. if a scheme requires to change each one of the nexthop in response to link/node failure for a million routes, it may not be 'fast' enough to be considered as fast-reroute. Just want to mention that for NFRR, since it's only dealing with a known nexthop, regardless of the number of routes using this nexthop, it only needs to have one operation to redirect to an alternative nexthop. It works the same if there is only a hundred routes pointing to it, or one million routes pointing to it. For non-nexthop based IPFRR schemes, another level of redirection can be introduced, but this also will increase the complexity of the scheme for implementation. When anyone wants to compare comlexity of mechanisms, we need to keep this in mind. thanks, - Naiming Curtis Villamizar wrote: > In message <41A26925.70301@bcn-inc.net> > Naiming Shen writes: > >> >> >>Hi Alia, >> >>Alia Atlas wrote: >> >>>Hi Naiming, >>> >>>At 02:47 PM 11/22/2004, Naiming Shen wrote: >>> >>> >>>>>Sure. We can have a different protocol in the network solely for >>>>>resiliency to create those source-routed tunnels with the associated >>>>>complexity, but at least it wouldn't be MPLS :-) >>>> >>>> >>>>Well, the main purpose is to enable backbone IP tunnels with the >>>>capability of TE, IPFRR is just a side effect of that :-) >>> >>> >>>Coming full circle, I suppose. :-) >> >> >>The reason it seems comming to a full circle is that, I keep waiting for >>a simpler solution, and yet to see one ;-) > > > > I think this work exists due to anti-MPLS sentiment and a need for > FRR. The alternative (IP FRR) may be proving to be problematic and > the argument that there is something hard about doing MPLS FRR seems > to be losing credibility )or maybe just more so when FRR is added to > the list of requirements). > > > >>>If a network is already doing TE and is willing to do the configuration, >>>etc., then it makes sense to use TE Fast-Reroute. Whether the >>>forwarding path is MPLS or IP seems irrelevant to me in that piece of >>>the discussion. >> >> >>I thought that was relevant in this IPFRR discussion, otherwise there is >>no way the NFRR solution should be outside this discussion. In terms of >>configuration "complication", it's all relative thing. People need to >>do comparison for their network in order to reach some conclusion. >>Also, the NFRR or MPLS TE configuration is mostly implementation issue, >>majority of that can be automated just like the IPFRR approaches >>discussed in this working group. >> >>Cheers, >>- Naiming > > > > Yep. Agree completely. The requirement *not* to use MPLS may not be > based on any technical issue. > > Anyway we may be either out of scope or committing herasy as far as > this WG is concerned. > > Curtis > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Nov 23 13:59:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08789 for ; Tue, 23 Nov 2004 13:59:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWfwu-0002U2-PE for rtgwg-web-archive@ietf.org; Tue, 23 Nov 2004 14:03:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWfmn-0003Np-KY; Tue, 23 Nov 2004 13:53:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWfje-0002oM-Ld for rtgwg@megatron.ietf.org; Tue, 23 Nov 2004 13:49:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08171 for ; Tue, 23 Nov 2004 13:49:52 -0500 (EST) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWfnM-00014r-Mf for rtgwg@ietf.org; Tue, 23 Nov 2004 13:53:45 -0500 Received: (qmail 42267 invoked from network); 23 Nov 2004 18:49:52 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 23 Nov 2004 18:49:52 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iANImCcX018549; Tue, 23 Nov 2004 13:48:12 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200411231848.iANImCcX018549@workhorse.faster-light.net> To: mike shand In-reply-to: Your message of "Tue, 23 Nov 2004 16:48:44 GMT." <4.3.2.7.2.20041123164815.02ac63e0@jaws.cisco.com> Date: Tue, 23 Nov 2004 13:48:12 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: Alia Atlas , curtis@faster-light.net, Stewart Bryant , rtgwg@ietf.org Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 In message <4.3.2.7.2.20041123164815.02ac63e0@jaws.cisco.com> mike shand writes: > > At 11:03 23/11/2004 -0500, Alia Atlas wrote: > >Mke, > >At 05:08 AM 11/23/2004, mike shand wrote: > >>>One issue that I see for the non-source-routed tunnel based approach is > >>>that it uses the original next-next-hop as a proxy for a set of > >>>destinations. It is possible that the path from the next-next-hop to a > >>>particular destination will not be available because it traverses a link > >>>in the same SRLG. > >>> > >>>I think that this may make the destination assignment a bit trickier. > >> > >>Well, by analogy with the node failure case, one way to deal with this is > >>to consider a separate repair to the far side of each SRLG. I'm not sure > >>it is always necessary, but I think it is sufficeient. > > > >But what is the far side of the SRLG? > > > When you run a normal SPF rooted at S, as you traverse each SRLG you will > find which is the far side. > > >Trimming the trees after they're computed makes some sense, but then it a > >next-next-hop is dependent on the same SRLG to reach a destination, that > >destination won't be given an alternate (where there might be one without > >the proxying). > > > It certainly true that proxying reduces your options. Even in the non-SRLG > case it is true that if it were the case that a repair was impossible to a > proxy it may still be possible for all destinations except that proxy. > However, our view is that if the failure is not 100% repairable then it is > irreparable, so rather than giving some destinations poorer service it > would probably be better not to attempt repair at all for that link. Not > that we have seen any such irreparable links in real networks, but that is > the principle behind the proxying. > > In the case of SRLG, this might translate to a case where it was necessary > to use secondary repairs because a few destinations could not otherwise be > repaired. What this would mean is that we might use a secondary repair for > some destinations which (if we had done the whole calculation per > destination) could ave been repaired via a single primary repair. This is > also true of node failures (which are of course SRLGs in disguse). > > Mike > > > >Alia Mike, I don't understand the algorithm(s?) that you two are discussing. In MPLS/TE you simply remove all links from the topology that share a common SRLG or for some types of SRLG don't remove the links but weight those links to encourage avoiding them. Then run the CSPF. An interesting problem with IP FRR and SRLG is that an SRLG means that the links *might* go down concurrently. It does not indicate that the links *will* go down concurrently. If two links share a common resource they will go down simulaneously if failure of that resource is the cause of the outage. If you use the above approach and the failure is due to some other cause, normal hop by hop forwarding could cause a loop. MPLS/TE FRR does not suffer from this problem because tunnels are used in the backup that terminate at the egress where the path is dictated by the ingress or the PLR (point of local repair). Therefore MPLS/TE FRR can select a path which avoids all links that could potentially fail without being concerned that a routing loop could form due to an inconsistent decision. Alia has addressed the problem of local SRLG and has provided a clear enough description of how that works. There is some question whether the more general SRLG problem can be adequately addressed because of the above problem. The algorithm description above doesn't seem complete and therefore doesn't make sense to me but that might be becuase the description was sketchy or it might be just because I'm being dense. For example: . . . . X . . a --- b . | \ . | e | / c --- d A is trying to get to e and looking to protect against failure of a-b but a-b and d-e share a common fiber (a, c, d may be near each other geographicly and b, e may be near each other). A needs to use a long path via X. I don't see how this "far side of the SRLG" idea fits into an algorithm that solves this problem. Note that U-turn doesn't address this since d-e is not local to A. The SRLG could also be a-b and c-d in a slightly different example. The physical fiber involved in the SRLGs may look more like this (where the = are two lambdas on the same segment of fiber). ..X1..X2..Xn-1.. ..Xn.. / \ / . a ----=========----====---b Xn+1 \ / \ \ . c --- d ----- e Even more interesting is the case were a-b shares one SRLG with a..x and a-b shares another SRLG with a-c. In MPLS TE, the primary path can be changed to a-c-d-e so that the backup path a..x..e could be used and the primary and backup paths did not share any SRLG. This is generally done only with primary and standby (backup from ingress to egress) or ingress as a PLR in FRR since the ingress and not the PLR determines the primary path. It would be difficult for the ingress to select a primary path that assures that a feasible backup is available at any PLR. For example: . . . . X . . - a --- b . / | \ . z | e \ | / - c --- d If Z is now the ingress, Z is unlikely to consider whether A has a viable repair path when selecting the path to E. Z would likely pick the path z-a-b-e if the path z-c-d-e was a viable packup for failure of z-a and then A would have no way to create a viable backup. A better example of this is where one SRLG is a-b and a.x and another SRLG is a-b and a-c and the third is a-b and z-a. The path z-a-b-e and z-c-d-e are fully disjoint but A has no backup path. OTOH if A picked a primary path of z-c-d-e, Z, C and D all have viable backups when acting as the PLR. Note: I'm using . to mean multiple hops and - to mean one hop, but it only matters in the a.x.e case since there I just want to indicate higher cost. Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Nov 23 14:15:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09836 for ; Tue, 23 Nov 2004 14:15:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWgBi-0004Q7-TD for rtgwg-web-archive@ietf.org; Tue, 23 Nov 2004 14:18:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWg3G-0006aR-0q; Tue, 23 Nov 2004 14:10:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWfzS-0005Rh-71 for rtgwg@megatron.ietf.org; Tue, 23 Nov 2004 14:06:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09151 for ; Tue, 23 Nov 2004 14:06:12 -0500 (EST) Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWg38-0003F9-NL for rtgwg@ietf.org; Tue, 23 Nov 2004 14:10:05 -0500 Received: (qmail 81484 invoked from network); 23 Nov 2004 19:06:10 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 23 Nov 2004 19:06:10 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iANJ4Ue9018665; Tue, 23 Nov 2004 14:04:30 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200411231904.iANJ4Ue9018665@workhorse.faster-light.net> To: Naiming Shen In-reply-to: Your message of "Tue, 23 Nov 2004 10:26:12 PST." <41A380C4.1060107@bcn-inc.net> Date: Tue, 23 Nov 2004 14:04:30 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: Alia Atlas , curtis@faster-light.net, rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 In message <41A380C4.1060107@bcn-inc.net> Naiming Shen writes: > > > Another issue I have not seen any discussion on the > list is how fast the "FRR" can be accomplished on the > node for a IPFRR scheme. > > For MPLS LSPs and it's FRR, a node may only have hundreds > or thousands of LSPs, it's not common to see 10s of > thousands LSPs using the same interface on a node. There might be a larger number of LDP and/or VPN labels, but not MPLS/TE LSPs. So I agree completely. Thousands is rare. I've not yet heard of anyone actually getting to 10,000. > For IPFRR, we need to consider maybe half a million routes > pointing to the same nexthop, it's very different in > scaling comparing to MPLS LSPs. That is done with a two stage forwarding. IPFRR protects IGP destinations and routes are mapped into IGP destinations. The IGP destinations are protected, then switched over first, then any BGP routes that map into different IGP routes as a result of the topology change see a route change. Its faster and avoids the problem of needing to jam a few hundred thousand entries into hardware to get the fast recovery to work. > if a scheme requires to change each one of the nexthop > in response to link/node failure for a million routes, it > may not be 'fast' enough to be considered as fast-reroute. Very true. > Just want to mention that for NFRR, since it's only dealing > with a known nexthop, regardless of the number of routes > using this nexthop, it only needs to have one operation > to redirect to an alternative nexthop. It works the > same if there is only a hundred routes pointing to it, or > one million routes pointing to it. How do you do node protection in this case: b--d--g,h,i... / | a -- e \ | c--f--q,r,s... If the best path from a to d and from a to f used a-e, what is your backup path for a-e? I also don't think NFRR covers SRLG in that case. > For non-nexthop based IPFRR schemes, another level of > redirection can be introduced, but this also will increase > the complexity of the scheme for implementation. When > anyone wants to compare comlexity of mechanisms, we > need to keep this in mind. > > thanks, > - Naiming Reducing complexity is a worthy goal, but you know what Einstein said about as simple as possible but no simpler. If it no longer works we've gone to a solution which is too simple. Curtis > Curtis Villamizar wrote: > > In message <41A26925.70301@bcn-inc.net> > > Naiming Shen writes: > > > >> > >> > >>Hi Alia, > >> > >>Alia Atlas wrote: > >> > >>>Hi Naiming, > >>> > >>>At 02:47 PM 11/22/2004, Naiming Shen wrote: > >>> > >>> > >>>>>Sure. We can have a different protocol in the network solely for > >>>>>resiliency to create those source-routed tunnels with the associated > >>>>>complexity, but at least it wouldn't be MPLS :-) > >>>> > >>>> > >>>>Well, the main purpose is to enable backbone IP tunnels with the > >>>>capability of TE, IPFRR is just a side effect of that :-) > >>> > >>> > >>>Coming full circle, I suppose. :-) > >> > >> > >>The reason it seems comming to a full circle is that, I keep waiting for > >>a simpler solution, and yet to see one ;-) > > > > > > > > I think this work exists due to anti-MPLS sentiment and a need for > > FRR. The alternative (IP FRR) may be proving to be problematic and > > the argument that there is something hard about doing MPLS FRR seems > > to be losing credibility )or maybe just more so when FRR is added to > > the list of requirements). > > > > > > > >>>If a network is already doing TE and is willing to do the configuration, > >>>etc., then it makes sense to use TE Fast-Reroute. Whether the > >>>forwarding path is MPLS or IP seems irrelevant to me in that piece of > >>>the discussion. > >> > >> > >>I thought that was relevant in this IPFRR discussion, otherwise there is > >>no way the NFRR solution should be outside this discussion. In terms of > >>configuration "complication", it's all relative thing. People need to > >>do comparison for their network in order to reach some conclusion. > >>Also, the NFRR or MPLS TE configuration is mostly implementation issue, > >>majority of that can be automated just like the IPFRR approaches > >>discussed in this working group. > >> > >>Cheers, > >>- Naiming > > > > > > > > Yep. Agree completely. The requirement *not* to use MPLS may not be > > based on any technical issue. > > > > Anyway we may be either out of scope or committing herasy as far as > > this WG is concerned. > > > > Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Nov 23 14:20:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10200 for ; Tue, 23 Nov 2004 14:20:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWgGn-0005Bh-AN for rtgwg-web-archive@ietf.org; Tue, 23 Nov 2004 14:24:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWg8m-0007T0-Os; Tue, 23 Nov 2004 14:15:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWg4M-0006kf-A0 for rtgwg@megatron.ietf.org; Tue, 23 Nov 2004 14:11:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09517 for ; Tue, 23 Nov 2004 14:11:16 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWg81-000408-Iq for rtgwg@ietf.org; Tue, 23 Nov 2004 14:15:09 -0500 Received: from aatlas-lt.avici.com (b2-pc76.avici.com [10.2.100.76]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iANJ9K4I030067; Tue, 23 Nov 2004 14:09:20 -0500 Message-Id: <5.1.0.14.2.20041123134345.02889558@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Nov 2004 14:08:51 -0500 To: Naiming Shen From: Alia Atlas In-Reply-To: <41A380C4.1060107@bcn-inc.net> References: <200411222325.iAMNPC5Z012488@workhorse.faster-light.net> <200411222325.iAMNPC5Z012488@workhorse.faster-light.net> 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-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: curtis@faster-light.net, rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Hi Naiming, At 01:26 PM 11/23/2004, Naiming Shen wrote: >Another issue I have not seen any discussion on the >list is how fast the "FRR" can be accomplished on the >node for a IPFRR scheme. > >For MPLS LSPs and it's FRR, a node may only have hundreds >or thousands of LSPs, it's not common to see 10s of >thousands LSPs using the same interface on a node. Each of those LSPs requires separate forwarding state, both for primary and for backup, because there is a different label or label stack involved. For good scaling, it is desirable to be able to fail-over from primary to backup based on a next-hop event regardless of the number of LSPs. >For IPFRR, we need to consider maybe half a million routes >pointing to the same nexthop, it's very different in >scaling comparing to MPLS LSPs. A difference is that most of those routes can use the same forwarding state as that associated with one or more IGP nodes. Thus, while there may be more routes than LSPs, there is indirection possible. This is more clearly seen with LDP, where that vast number of routes can be and generally is reduced down to a small number of FECs. >if a scheme requires to change each one of the nexthop >in response to link/node failure for a million routes, it >may not be 'fast' enough to be considered as fast-reroute. Absolutely. Implementation does matter. You can do TE-FRR way too slow also. >Just want to mention that for NFRR, since it's only dealing >with a known nexthop, regardless of the number of routes >using this nexthop, it only needs to have one operation >to redirect to an alternative nexthop. It works the >same if there is only a hundred routes pointing to it, or >one million routes pointing to it. This seems to me to be missing several points. First, if only link protection is desired, then all routes that are using a particular link can be given the same alternate; this may mean that some destinations aren't protected when they could have been, but it's a first pass simplification. This is the case regardless of whether NFRR is used or some other mechanism; it is simply a side-effect of the far end of the link proxying for all destinations reached through that link. Second, if node protection is desired, then it is necessary, in NFRR as in any of the tunneling schemes, to track the next-next-hop for each route or IGP destination. In that case, you need to organize indirection of routes to primary & alternate based upon the next-next-hop. NFRR provides no added benefit that I can see here. If one has the ability to add that extra level of indirecton (desirable anyway for fast IGP convergence), then that level can be added in to handle any of these IPFRR schemes. >For non-nexthop based IPFRR schemes, another level of >redirection can be introduced, but this also will increase >the complexity of the scheme for implementation. When >anyone wants to compare comlexity of mechanisms, we >need to keep this in mind. As I said above, I don't think that a non-nexthop based IPFRR scheme adds another level of indirection. It is the same level that is necessary for node protection. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Nov 23 16:36:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06612 for ; Tue, 23 Nov 2004 16:36:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWiOu-0001of-AQ for rtgwg-web-archive@ietf.org; Tue, 23 Nov 2004 16:40:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWi8W-00033i-F9; Tue, 23 Nov 2004 16:23:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWhQh-0001Jb-K3 for rtgwg@megatron.ietf.org; Tue, 23 Nov 2004 15:38:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22479 for ; Tue, 23 Nov 2004 15:38:25 -0500 (EST) Received: from [208.246.215.5] (helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWhUM-0007mZ-GT for rtgwg@ietf.org; Tue, 23 Nov 2004 15:42:19 -0500 Received: from aatlas-lt.avici.com ([10.2.104.245]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iANKbc4I013233; Tue, 23 Nov 2004 15:37:38 -0500 Message-Id: <5.1.0.14.2.20041123152645.02899b90@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Nov 2004 15:37:10 -0500 To: curtis@faster-light.net From: Alia Atlas In-Reply-To: <200411231848.iANImCcX018549@workhorse.faster-light.net> References: 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-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Stewart Bryant , rtgwg@ietf.org, mike shand Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 At 01:48 PM 11/23/2004, Curtis Villamizar wrote: >In MPLS/TE you simply remove all links from the topology that share a >common SRLG or for some types of SRLG don't remove the links but >weight those links to encourage avoiding them. Then run the CSPF. > >An interesting problem with IP FRR and SRLG is that an SRLG means that >the links *might* go down concurrently. It does not indicate that the >links *will* go down concurrently. If two links share a common >resource they will go down simulaneously if failure of that resource >is the cause of the outage. If you use the above approach and the >failure is due to some other cause, normal hop by hop forwarding could >cause a loop. The big difference is that with IPFRR, one can't prune the topology, b/c the topology is what the other nodes will obey. Instead, I think that one tracks the SRLGs that are traversed. Then a path can be discarded if a common SRLG is traversed. It isn't desirable to go to a node that would also be using an alternate, b/c then you can get looping alternates or need to consider what alternate that node would have selected. It's much better to go to a node whose primary path doesn't traverse the common SRLG. If no such path is available, then one could give weights to SRLGs and select an alternate appropriately. >MPLS/TE FRR does not suffer from this problem because tunnels are used >in the backup that terminate at the egress where the path is dictated >by the ingress or the PLR (point of local repair). Therefore MPLS/TE >FRR can select a path which avoids all links that could potentially >fail without being concerned that a routing loop could form due to an >inconsistent decision. > >Alia has addressed the problem of local SRLG and has provided a clear >enough description of how that works. There is some question whether >the more general SRLG problem can be adequately addressed because of >the above problem. I think that it can; it requires tracking SRLGs, which is unfortunate. >The algorithm description above doesn't seem complete and therefore >doesn't make sense to me but that might be becuase the description was >sketchy or it might be just because I'm being dense. > >For example: > > . . . . X > . . > a --- b . > | \ . > | e > | / > c --- d > >A is trying to get to e and looking to protect against failure of a-b >but a-b and d-e share a common fiber (a, c, d may be near each other >geographicly and b, e may be near each other). A needs to use a long >path via X. I don't see how this "far side of the SRLG" idea fits >into an algorithm that solves this problem. Note that U-turn doesn't >address this since d-e is not local to A. The SRLG could also be a-b >and c-d in a slightly different example. One could address this with loop-free or U-turn, depending on tracking SRLGs traversed by each neighbor or neighbor's neighbor to the destination. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Wed Nov 24 00:22:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15087 for ; Wed, 24 Nov 2004 00:22:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWpfX-00048A-N5 for rtgwg-web-archive@ietf.org; Wed, 24 Nov 2004 00:26:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWpb7-0007RE-M4; Wed, 24 Nov 2004 00:21:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWpaM-0007Ev-H4 for rtgwg@megatron.ietf.org; Wed, 24 Nov 2004 00:20:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15049 for ; Wed, 24 Nov 2004 00:20:54 -0500 (EST) Received: from 67.111.75.190.ptr.us.xo.net ([67.111.75.190] helo=BCNW02.bcn-inc.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWpe9-00046J-Qy for rtgwg@ietf.org; Wed, 24 Nov 2004 00:24:54 -0500 Received: from [10.10.20.60] ([10.10.20.60]) by BCNW02.bcn-inc.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Nov 2004 21:20:26 -0800 Message-ID: <41A419CF.2070505@bcn-inc.net> Date: Tue, 23 Nov 2004 21:19:11 -0800 From: Naiming Shen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@faster-light.net References: <200411231904.iANJ4Ue9018665@workhorse.faster-light.net> In-Reply-To: <200411231904.iANJ4Ue9018665@workhorse.faster-light.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Nov 2004 05:20:26.0631 (UTC) FILETIME=[4E671170:01C4D1E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: 7bit Cc: Alia Atlas , rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > In message <41A380C4.1060107@bcn-inc.net> > Naiming Shen writes: > >> >> >>Another issue I have not seen any discussion on the >>list is how fast the "FRR" can be accomplished on the >>node for a IPFRR scheme. >> >>For MPLS LSPs and it's FRR, a node may only have hundreds >>or thousands of LSPs, it's not common to see 10s of >>thousands LSPs using the same interface on a node. > > > > There might be a larger number of LDP and/or VPN labels, but not > MPLS/TE LSPs. So I agree completely. Thousands is rare. I've not > yet heard of anyone actually getting to 10,000. > > > >>For IPFRR, we need to consider maybe half a million routes >>pointing to the same nexthop, it's very different in >>scaling comparing to MPLS LSPs. > > > > That is done with a two stage forwarding. IPFRR protects IGP > destinations and routes are mapped into IGP destinations. The IGP > destinations are protected, then switched over first, then any BGP > routes that map into different IGP routes as a result of the topology > change see a route change. Its faster and avoids the problem of > needing to jam a few hundred thousand entries into hardware to get the > fast recovery to work. > That's cool. I guess my concern was that not all the forwarding architecture has the indirect adjacency forwarding capability due to hardware or performance issues. > > >>if a scheme requires to change each one of the nexthop >>in response to link/node failure for a million routes, it >>may not be 'fast' enough to be considered as fast-reroute. > > > > Very true. > > > >>Just want to mention that for NFRR, since it's only dealing >>with a known nexthop, regardless of the number of routes >>using this nexthop, it only needs to have one operation >>to redirect to an alternative nexthop. It works the >>same if there is only a hundred routes pointing to it, or >>one million routes pointing to it. > > > > How do you do node protection in this case: > > b--d--g,h,i... > / | > a -- e > \ | > c--f--q,r,s... > > If the best path from a to d and from a to f used a-e, what is your > backup path for a-e? You meant when "e" is gone? wouldn't 'a' use a-b-d and a-c-f out ? > > I also don't think NFRR covers SRLG in that case. which links are related in this case? > > >>For non-nexthop based IPFRR schemes, another level of >>redirection can be introduced, but this also will increase >>the complexity of the scheme for implementation. When >>anyone wants to compare comlexity of mechanisms, we >>need to keep this in mind. >> >>thanks, >>- Naiming > > > > Reducing complexity is a worthy goal, but you know what Einstein said > about as simple as possible but no simpler. If it no longer works > we've gone to a solution which is too simple. Agreed, if you can approve that something is "as simple as possible";-) thanks. - Naiming > > Curtis > > > >>Curtis Villamizar wrote: >> >>>In message <41A26925.70301@bcn-inc.net> >>>Naiming Shen writes: >>> >>> >>>> >>>>Hi Alia, >>>> >>>>Alia Atlas wrote: >>>> >>>> >>>>>Hi Naiming, >>>>> >>>>>At 02:47 PM 11/22/2004, Naiming Shen wrote: >>>>> >>>>> >>>>> >>>>>>>Sure. We can have a different protocol in the network solely for >>>>>>>resiliency to create those source-routed tunnels with the associated >>>>>>>complexity, but at least it wouldn't be MPLS :-) >>>>>> >>>>>> >>>>>>Well, the main purpose is to enable backbone IP tunnels with the >>>>>>capability of TE, IPFRR is just a side effect of that :-) >>>>> >>>>> >>>>>Coming full circle, I suppose. :-) >>>> >>>> >>>>The reason it seems comming to a full circle is that, I keep waiting for >>>>a simpler solution, and yet to see one ;-) >>> >>> >>> >>>I think this work exists due to anti-MPLS sentiment and a need for >>>FRR. The alternative (IP FRR) may be proving to be problematic and >>>the argument that there is something hard about doing MPLS FRR seems >>>to be losing credibility )or maybe just more so when FRR is added to >>>the list of requirements). >>> >>> >>> >>> >>>>>If a network is already doing TE and is willing to do the configuration, >>>>>etc., then it makes sense to use TE Fast-Reroute. Whether the >>>>>forwarding path is MPLS or IP seems irrelevant to me in that piece of >>>>>the discussion. >>>> >>>> >>>>I thought that was relevant in this IPFRR discussion, otherwise there is >>>>no way the NFRR solution should be outside this discussion. In terms of >>>>configuration "complication", it's all relative thing. People need to >>>>do comparison for their network in order to reach some conclusion. >>>>Also, the NFRR or MPLS TE configuration is mostly implementation issue, >>>>majority of that can be automated just like the IPFRR approaches >>>>discussed in this working group. >>>> >>>>Cheers, >>>>- Naiming >>> >>> >>> >>>Yep. Agree completely. The requirement *not* to use MPLS may not be >>>based on any technical issue. >>> >>>Anyway we may be either out of scope or committing herasy as far as >>>this WG is concerned. >>> >>>Curtis > > > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Wed Nov 24 02:10:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29544 for ; Wed, 24 Nov 2004 02:10:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWrM2-00011R-Iq for rtgwg-web-archive@ietf.org; Wed, 24 Nov 2004 02:14:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWrGk-0002sf-U4; Wed, 24 Nov 2004 02:08:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWrCT-0008Oy-3v for rtgwg@megatron.ietf.org; Wed, 24 Nov 2004 02:04:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24784 for ; Wed, 24 Nov 2004 02:04:08 -0500 (EST) Received: from 67.111.75.190.ptr.us.xo.net ([67.111.75.190] helo=BCNW02.bcn-inc.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWrFz-0000D9-FP for rtgwg@ietf.org; Wed, 24 Nov 2004 02:08:06 -0500 Received: from [10.10.20.60] ([10.10.20.60]) by BCNW02.bcn-inc.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Nov 2004 23:03:29 -0800 Message-ID: <41A431F8.2090909@bcn-inc.net> Date: Tue, 23 Nov 2004 23:02:16 -0800 From: Naiming Shen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alia Atlas References: <200411222325.iAMNPC5Z012488@workhorse.faster-light.net> <200411222325.iAMNPC5Z012488@workhorse.faster-light.net> <5.1.0.14.2.20041123134345.02889558@pop.avici.com> In-Reply-To: <5.1.0.14.2.20041123134345.02889558@pop.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Nov 2004 07:03:29.0380 (UTC) FILETIME=[B39BB240:01C4D1F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: curtis@faster-light.net, rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Hi Alia, Alia Atlas wrote: > Hi Naiming, > > At 01:26 PM 11/23/2004, Naiming Shen wrote: > >> Another issue I have not seen any discussion on the >> list is how fast the "FRR" can be accomplished on the >> node for a IPFRR scheme. >> >> For MPLS LSPs and it's FRR, a node may only have hundreds >> or thousands of LSPs, it's not common to see 10s of >> thousands LSPs using the same interface on a node. > > > Each of those LSPs requires separate forwarding state, both for primary > and for backup, because there is a different label or label stack involved. > > For good scaling, it is desirable to be able to fail-over from primary > to backup based on a next-hop event regardless of the number of LSPs. yes, it's regardless of the number of LSPs for each LSP switch-over, but the total switch-over time is linear to the number of LSPs affected. > >> For IPFRR, we need to consider maybe half a million routes >> pointing to the same nexthop, it's very different in >> scaling comparing to MPLS LSPs. > > > A difference is that most of those routes can use the same forwarding > state as that associated with one or more IGP nodes. > > Thus, while there may be more routes than LSPs, there is indirection > possible. yes, indirection makes it scalable. but a hardware design or an existing forwarding engine may not want to do indirection due to extra processing at forwarding time. > This is more clearly seen with LDP, where that vast number of routes can > be and generally is reduced down to a small number of FECs. > >> if a scheme requires to change each one of the nexthop >> in response to link/node failure for a million routes, it >> may not be 'fast' enough to be considered as fast-reroute. > > > Absolutely. Implementation does matter. You can do TE-FRR way too slow > also. > >> Just want to mention that for NFRR, since it's only dealing >> with a known nexthop, regardless of the number of routes >> using this nexthop, it only needs to have one operation >> to redirect to an alternative nexthop. It works the >> same if there is only a hundred routes pointing to it, or >> one million routes pointing to it. > > > This seems to me to be missing several points. > > First, if only link protection is desired, then all routes that are > using a particular link can be given the same alternate; this may mean > that some destinations aren't protected when they could have been, but > it's a first pass simplification. This is the case regardless of > whether NFRR is used or some other mechanism; it is simply a side-effect > of the far end of the link proxying for all destinations reached through > that link. > yes, I guess my comment was more related to the link-protection case, which is simple enough and most vendors will just do it. > Second, if node protection is desired, then it is necessary, in NFRR as > in any of the tunneling schemes, to track the next-next-hop for each > route or IGP destination. In that case, you need to organize > indirection of routes to primary & alternate based upon the next-next-hop. > > NFRR provides no added benefit that I can see here. If one has the > ability to add that extra level of indirecton (desirable anyway for fast > IGP convergence), then that level can be added in to handle any of these > IPFRR schemes. For the hardware can do indirection of adjacencies, you are right, that's not a big problem. But even that, NFRR is only concerned about a couple of next-nexthop adjacencies and the traffic is for sure being switched over to the next-nexthop nodes. For non-nexthop schemes, I guess one needs to worry about BGP nexthops which are IGP nodes, and next-nexthops of those IGP routes, so there is more complexities to figure out those alternative indirections. And in the case of inter-area node-protection of ABR router, this will be rather tricky. thanks. - Naiming > >> For non-nexthop based IPFRR schemes, another level of >> redirection can be introduced, but this also will increase >> the complexity of the scheme for implementation. When >> anyone wants to compare comlexity of mechanisms, we >> need to keep this in mind. > > > As I said above, I don't think that a non-nexthop based IPFRR scheme > adds another level of indirection. It is the same level that is > necessary for node protection. > > Alia > > > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Wed Nov 24 03:31:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27637 for ; Wed, 24 Nov 2004 03:31:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWscu-0003YC-FP for rtgwg-web-archive@ietf.org; Wed, 24 Nov 2004 03:35:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWsTe-0003SU-Oj; Wed, 24 Nov 2004 03:26:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWsM8-0001XF-78 for rtgwg@megatron.ietf.org; Wed, 24 Nov 2004 03:18:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26161 for ; Wed, 24 Nov 2004 03:18:26 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWsPx-0001XV-Ae for rtgwg@ietf.org; Wed, 24 Nov 2004 03:22:26 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 24 Nov 2004 09:26:34 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAO8HrCu001751; Wed, 24 Nov 2004 09:17:53 +0100 (MET) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4368.cisco.com [10.61.81.15]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA19857; Wed, 24 Nov 2004 08:17:52 GMT Message-Id: <4.3.2.7.2.20041124074442.033e9728@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Nov 2004 08:17:52 +0000 To: curtis@faster-light.net From: mike shand In-Reply-To: <200411231848.iANImCcX018549@workhorse.faster-light.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: Alia Atlas , curtis@faster-light.net, Stewart Bryant , rtgwg@ietf.org Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Curtis, See inline. Mike At 13:48 23/11/2004 -0500, Curtis Villamizar wrote: >Mike, > >I don't understand the algorithm(s?) that you two are discussing. > >In MPLS/TE you simply remove all links from the topology that share a >common SRLG or for some types of SRLG don't remove the links but >weight those links to encourage avoiding them. Then run the CSPF. > >An interesting problem with IP FRR and SRLG is that an SRLG means that >the links *might* go down concurrently. It does not indicate that the >links *will* go down concurrently. True, but in IPFRR we have no knowledge of which of these has happened so we have to assume the worst case. The whole point is that we install the repair before the information about the failure has had time to propagate. I suppose if we were prepared to lower our sights somewhat, and have a mechanism which operated at the limit of propagation time we COUL wait a while after detecting a failure to see if we saw any LSPs from anywhere else, and then act accordingly. We already have this concept for loop prevention, but that is somewhat different since in that case we have the luxury of knowing that any failure has already been repaired, so we are not loosing traffic while we are waiting. >If two links share a common >resource they will go down simulaneously if failure of that resource >is the cause of the outage. If you use the above approach and the >failure is due to some other cause, normal hop by hop forwarding could >cause a loop. I don't see why that would be true. Remember that in that case of the tunnels appraoch, the whole essense of the approach is that the paths are unaffected by the failures. i.e. Fspace (aka Pspace) is the set of nodes which can be reached from S by paths which are unaffected by the failure, and Gspace (aka Qspace) is the set of nodes which can reach the "target" (proxy for destination) by paths which are unaffacted by the failure. Hence the entire path tunneled to F/G and released to the destination is guaranteed to be unaffected by the failure. >MPLS/TE FRR does not suffer from this problem because tunnels are used >in the backup that terminate at the egress where the path is dictated >by the ingress or the PLR (point of local repair). Therefore MPLS/TE >FRR can select a path which avoids all links that could potentially >fail without being concerned that a routing loop could form due to an >inconsistent decision. > >Alia has addressed the problem of local SRLG and has provided a clear >enough description of how that works. There is some question whether >the more general SRLG problem can be adequately addressed because of >the above problem. > >The algorithm description above doesn't seem complete and therefore >doesn't make sense to me but that might be becuase the description was >sketchy or it might be just because I'm being dense. > >For example: > > . . . . X > . . > a --- b . > | \ . > | e > | / > c --- d > >A is trying to get to e and looking to protect against failure of a-b >but a-b and d-e share a common fiber (a, c, d may be near each other >geographicly and b, e may be near each other). A needs to use a long >path via X. I don't see how this "far side of the SRLG" idea fits >into an algorithm that solves this problem. Ok from A's perspective, run a normal SPF and you find that B and D are the far sides. No actually, assuming dashes are hops or something, then D is not reached via CD. So in this case you would find A's F-space with respect to AB and CD failure, and then computes B's G space with respect to AB and CD failure (by running a reverse SPF rooted at B and excising any sub-tree which traversed either AB or C. The resulting overlap between F sapce and Gspace would occur somewhere in the A....X....B brnach, and that is where the repair traffic for B,E and D would be sent. From C's perspective the situation is similar and again the repair point would be somewhere near X. > Note that U-turn doesn't >address this since d-e is not local to A. The SRLG could also be a-b >and c-d in a slightly different example. > >The physical fiber involved in the SRLGs may look more like this >(where the = are two lambdas on the same segment of fiber). > > ..X1..X2..Xn-1.. ..Xn.. > / \ / . > a ----=========----====---b Xn+1 > \ / \ \ . > c --- d ----- e Yes this is the classic GMPLS case and there are well known algorithms for calculating link and or node diverse paths. To solve this it is necessary (as you point out) to move the primary path away from the normal shortest path in order to avoid blocking. However, we do not have the luxury of this sort of thing in a pure IP network. The primary path is always the shortest path and there is nothing we can o about it. Its a very different problem. >Even more interesting is the case were a-b shares one SRLG with a..x >and a-b shares another SRLG with a-c. In MPLS TE, the primary path >can be changed to a-c-d-e so that the backup path a..x..e could be >used and the primary and backup paths did not share any SRLG. This is >generally done only with primary and standby (backup from ingress to >egress) or ingress as a PLR in FRR since the ingress and not >the PLR determines the primary path. It would be difficult for the >ingress to select a primary path that assures that a feasible backup >is available at any PLR. > >For example: > > . . . . X > . . > - a --- b . > / | \ . > z | e > \ | / > - c --- d > >If Z is now the ingress, Z is unlikely to consider whether A has a >viable repair path when selecting the path to E. Z's primary path to E will be strictly the shortest path and hence in your example will be an ECMP via A and C. As before A's repair for the SRLG of AB,CD will be via X, and so will that of C. So if AB only has failed, traffic from Z to E will be split between ZAXE and ZCDE. But if AB and CD have failed it will be split between ZAXE and ZCZAXE (since C's shortest path to X is via Z. Note that this is NOT a loop, since the packet when it comes back through Z is encapped with a destination of X not E. This is ugly, but not disastrous. > Z would likely pick >the path z-a-b-e if the path z-c-d-e was a viable packup for failure >of z-a and then A would have no way to create a viable backup. A >better example of this is where one SRLG is a-b and a.x and another >SRLG is a-b and a-c and the third is a-b and z-a. This case is not very interesting from Z's perspective. IF it detected ZA had failed it would also have to assume that AB had failed, but it would do this anyway since it must assume that node A has failed. But this does raise an interesting question. So far we (well at least I) have been thinking of SRLG in terms of a set of links failing. But we know already that we need to consider node failure as an SRLG consisting of all the links from a neighboring node, so if we see the link to our neighbor go down we must assume that the node itself has gone down. So does this mean that if we have a neighbor E, and SE is an SRLG with links XY and ST, the ACTUAL SRLG we have to consider is node E failure and links ST and XY failure? > The path z-a-b-e >and z-c-d-e are fully disjoint but A has no backup path. OTOH if A >picked a primary path of z-c-d-e, Z, C and D all have viable backups >when acting as the PLR. > >Note: I'm using . to mean multiple hops and - to mean one hop, but it >only matters in the a.x.e case since there I just want to indicate >higher cost. > >Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Wed Nov 24 09:58:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00008 for ; Wed, 24 Nov 2004 09:58:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWyfH-0003Jn-7o for rtgwg-web-archive@ietf.org; Wed, 24 Nov 2004 10:02:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWyUW-0001xK-Vz; Wed, 24 Nov 2004 09:51:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWyRD-0000yf-Ak for rtgwg@megatron.ietf.org; Wed, 24 Nov 2004 09:48:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29057 for ; Wed, 24 Nov 2004 09:48:05 -0500 (EST) Received: from relay00.pair.com ([209.68.1.20] helo=relay.pair.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWyV6-00024R-14 for rtgwg@ietf.org; Wed, 24 Nov 2004 09:52:08 -0500 Received: (qmail 66939 invoked from network); 24 Nov 2004 14:48:05 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 24 Nov 2004 14:48:05 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAOEk6gc024065; Wed, 24 Nov 2004 09:46:10 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200411241446.iAOEk6gc024065@workhorse.faster-light.net> To: Naiming Shen In-reply-to: Your message of "Tue, 23 Nov 2004 21:19:11 PST." <41A419CF.2070505@bcn-inc.net> Date: Wed, 24 Nov 2004 09:46:06 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: Alia Atlas , curtis@faster-light.net, rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac In message <41A419CF.2070505@bcn-inc.net> Naiming Shen writes: > > Curtis Villamizar wrote: > > In message <41A380C4.1060107@bcn-inc.net> > > Naiming Shen writes: > > > >> > >> > >>Another issue I have not seen any discussion on the > >>list is how fast the "FRR" can be accomplished on the > >>node for a IPFRR scheme. > >> > >>For MPLS LSPs and it's FRR, a node may only have hundreds > >>or thousands of LSPs, it's not common to see 10s of > >>thousands LSPs using the same interface on a node. > > > > > > > > There might be a larger number of LDP and/or VPN labels, but not > > MPLS/TE LSPs. So I agree completely. Thousands is rare. I've not > > yet heard of anyone actually getting to 10,000. > > > > > > > >>For IPFRR, we need to consider maybe half a million routes > >>pointing to the same nexthop, it's very different in > >>scaling comparing to MPLS LSPs. > > > > > > > > That is done with a two stage forwarding. IPFRR protects IGP > > destinations and routes are mapped into IGP destinations. The IGP > > destinations are protected, then switched over first, then any BGP > > routes that map into different IGP routes as a result of the topology > > change see a route change. Its faster and avoids the problem of > > needing to jam a few hundred thousand entries into hardware to get the > > fast recovery to work. > > > > That's cool. I guess my concern was that not all the forwarding > architecture has the indirect adjacency forwarding capability > due to hardware or performance issues. This is true. The performance issues of older hardware from specific vendors is out of scope for a discussion of the protocols although it is a practical consideration for providers that have certain older hardware. I don't pretend to know which hardware can and can't do this, but I do think its quite a lot of it. OTOH if the goal of the provider is to support VOIP and the gateways that need the fast restoration are in the IGP it might be good enough to support fast restoration of the IGP only and let BGP catch up at its own slower pace. Again this is a practical consideration for the operator and out of scope for the protocol specs themselves. > >>if a scheme requires to change each one of the nexthop > >>in response to link/node failure for a million routes, it > >>may not be 'fast' enough to be considered as fast-reroute. > > > > > > > > Very true. > > > > > > > >>Just want to mention that for NFRR, since it's only dealing > >>with a known nexthop, regardless of the number of routes > >>using this nexthop, it only needs to have one operation > >>to redirect to an alternative nexthop. It works the > >>same if there is only a hundred routes pointing to it, or > >>one million routes pointing to it. > > > > > > > > How do you do node protection in this case: > > > > b--d--g,h,i... > > / | > > a -- e > > \ | > > c--f--q,r,s... > > > > If the best path from a to d and from a to f used a-e, what is your > > backup path for a-e? > > You meant when "e" is gone? wouldn't 'a' use a-b-d and a-c-f out ? Yes. For the node disjoint case. > > I also don't think NFRR covers SRLG in that case. > > which links are related in this case? Node disjoint. > >>For non-nexthop based IPFRR schemes, another level of > >>redirection can be introduced, but this also will increase > >>the complexity of the scheme for implementation. When > >>anyone wants to compare comlexity of mechanisms, we > >>need to keep this in mind. > >> > >>thanks, > >>- Naiming > > > > > > > > Reducing complexity is a worthy goal, but you know what Einstein said > > about as simple as possible but no simpler. If it no longer works > > we've gone to a solution which is too simple. > > Agreed, if you can approve that something is "as simple as possible";-) > > thanks. > - Naiming Its the other way around. You have to prove that something works. If it works use it unless you can find something simpler that also works. When considering an alternative that seems simpler you have to prove that it really does work. If you are having a lot of trouble proving that it will work or even coming up with a convincing argument that it should work, then you might want to stick with what you know works. Anyway the point of the discussion we are having is to better understand any limitations to IP FRR. If it usually works except when X, we understand what X is. So far X seems to include SRLG and in some techniques asymetric costs, and in all techniques under discussion full coverage for all topologies, and maybe other things. There is no consensus within the WG that any of this is a reason not to continue, but we should discuss and known limitations and acknowledge them in the framework document or individual documents. Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Wed Nov 24 16:31:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06002 for ; Wed, 24 Nov 2004 16:31:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX4nJ-0007EK-Lu for rtgwg-web-archive@ietf.org; Wed, 24 Nov 2004 16:35:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4fe-0000an-OK; Wed, 24 Nov 2004 16:27:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4ea-0000F2-8y for rtgwg@megatron.ietf.org; Wed, 24 Nov 2004 16:26:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05787 for ; Wed, 24 Nov 2004 16:26:17 -0500 (EST) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CX4iW-0007Ak-7o for rtgwg@ietf.org; Wed, 24 Nov 2004 16:30:24 -0500 Received: (qmail 38938 invoked from network); 24 Nov 2004 21:26:15 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 24 Nov 2004 21:26:14 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAOLOLpu027851; Wed, 24 Nov 2004 16:24:21 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200411242124.iAOLOLpu027851@workhorse.faster-light.net> To: mike shand In-reply-to: Your message of "Wed, 24 Nov 2004 08:17:52 GMT." <4.3.2.7.2.20041124074442.033e9728@jaws.cisco.com> Date: Wed, 24 Nov 2004 16:24:20 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: Alia Atlas , curtis@faster-light.net, Stewart Bryant , rtgwg@ietf.org Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b In message <4.3.2.7.2.20041124074442.033e9728@jaws.cisco.com> mike shand writes: > > Curtis, > See inline. > > Mike You misunderstood part of the message because I was elaborating on a limitation of MPLS/TE in the last part of this. Sorry for the confusion. I made a point about MPSL FRR and then followed with the example. That was the final example with a Z in the topology. You did acknowledge another limitation of all IP FRR approaches that hadn't been explicitly mentioned previously. See inline. There were a few points that maybe I didn't make clearly so I'll try to clarify. Part of the problem is you seem to be replying to every post as if all the comments are directed only at your approach. See comments inline. Curtis > At 13:48 23/11/2004 -0500, Curtis Villamizar wrote: > > >Mike, > > > >I don't understand the algorithm(s?) that you two are discussing. > > > >In MPLS/TE you simply remove all links from the topology that share a > >common SRLG or for some types of SRLG don't remove the links but > >weight those links to encourage avoiding them. Then run the CSPF. > > > >An interesting problem with IP FRR and SRLG is that an SRLG means that > >the links *might* go down concurrently. It does not indicate that the > >links *will* go down concurrently. > > True, but in IPFRR we have no knowledge of which of these has happened so > we have to assume the worst case. The whole point is that we install the > repair before the information about the failure has had time to propagate. > I suppose if we were prepared to lower our sights somewhat, and have a > mechanism which operated at the limit of propagation time we COUL wait a > while after detecting a failure to see if we saw any LSPs from anywhere > else, and then act accordingly. We already have this concept for loop > prevention, but that is somewhat different since in that case we have the > luxury of knowing that any failure has already been repaired, so we are not > loosing traffic while we are waiting. > > >If two links share a common > >resource they will go down simulaneously if failure of that resource > >is the cause of the outage. If you use the above approach and the > >failure is due to some other cause, normal hop by hop forwarding could > >cause a loop. > > I don't see why that would be true. Remember that in that case of the > tunnels appraoch, the whole essense of the approach is that the paths are > unaffected by the failures. i.e. Fspace (aka Pspace) is the set of nodes > which can be reached from S by paths which are unaffected by the failure, > and Gspace (aka Qspace) is the set of nodes which can reach the "target" > (proxy for destination) by paths which are unaffacted by the failure. Hence > the entire path tunneled to F/G and released to the destination is > guaranteed to be unaffected by the failure. The first part of your tunneling (since it isn't explicit route tunneling) relies on IP forwarding. Plain IP with a multiple link failure can have loops form even with symetric routes due to some nodes reacting to the failure earlier than others. > >MPLS/TE FRR does not suffer from this problem because tunnels are used > >in the backup that terminate at the egress where the path is dictated > >by the ingress or the PLR (point of local repair). Therefore MPLS/TE > >FRR can select a path which avoids all links that could potentially > >fail without being concerned that a routing loop could form due to an > >inconsistent decision. > > > >Alia has addressed the problem of local SRLG and has provided a clear > >enough description of how that works. There is some question whether > >the more general SRLG problem can be adequately addressed because of > >the above problem. > > > >The algorithm description above doesn't seem complete and therefore > >doesn't make sense to me but that might be becuase the description was > >sketchy or it might be just because I'm being dense. > > > >For example: > > > > . . . . X > > . . > > a --- b . > > | \ . > > | e > > | / > > c --- d > > > >A is trying to get to e and looking to protect against failure of a-b > >but a-b and d-e share a common fiber (a, c, d may be near each other > >geographicly and b, e may be near each other). A needs to use a long > >path via X. I don't see how this "far side of the SRLG" idea fits > >into an algorithm that solves this problem. > > Ok from A's perspective, run a normal SPF and you find that B and D are the > far sides. No actually, assuming dashes are hops or something, then D is > not reached via CD. So in this case you would find A's F-space with respect > to AB and CD failure, and then computes B's G space with respect to AB and > CD failure (by running a reverse SPF rooted at B and excising any sub-tree > which traversed either AB or C. The resulting overlap between F sapce and > Gspace would occur somewhere in the A....X....B brnach, and that is where > the repair traffic for B,E and D would be sent. You didn't read down to the line that said: Note: I'm using . to mean multiple hops and - to mean one hop, but it only matters in the a.x.e case since there I just want to indicate higher cost. Any path by way of X is a high cost path. The point was that without considering SRLG in this case IPFRR would loop. Of course you had to read the whole email message before replying so my fault for putting that paragraph at the bottom of the message. Common notation is to use ... to mean a long (high cost) path. A-X and A-B share an SRLG. When a failure occurs at A-B, A does not know if A-B alone failed, if A-B and C-D have both failed or if A-B and A..X have failed (non-local failure). In IP FRR if the failure at A-B directs traffic toward X the traffic would never reach X. There may be a repair at that point in IP FRR that would send the traffic back around the other way, encapsulating a second time but if the lowest cost path to X required it to go by way of e (best path from d to X is by way of c) then there would be a loop. > From C's perspective the situation is similar and again the repair point > would be somewhere near X. > > > Note that U-turn doesn't > >address this since d-e is not local to A. The SRLG could also be a-b > >and c-d in a slightly different example. > > > >The physical fiber involved in the SRLGs may look more like this > >(where the = are two lambdas on the same segment of fiber). > > > > ..X1..X2..Xn-1.. ..Xn.. > > / \ / . > > a ----=========----====---b Xn+1 > > \ / \ \ . > > c --- d ----- e > > Yes this is the classic GMPLS case and there are well known algorithms for > calculating link and or node diverse paths. To solve this it is necessary > (as you point out) to move the primary path away from the normal shortest > path in order to avoid blocking. > > However, we do not have the luxury of this sort of thing in a pure IP > network. The primary path is always the shortest path and there is nothing > we can o about it. > > Its a very different problem. This is a type of problem that occur in the real world. It is not addressed by any of the IP FRR solutions but is addressed by MPLS FRR. This is just something that the framework document should mention. The remainder of this message starts out but saying "In MPLS TE, ...". Somehow you seemed to lose the fact that I was describing a limitation of MPLS FRR below. > >Even more interesting is the case were a-b shares one SRLG with a..x > >and a-b shares another SRLG with a-c. In MPLS TE, the primary path > >can be changed to a-c-d-e so that the backup path a..x..e could be > >used and the primary and backup paths did not share any SRLG. This is > >generally done only with primary and standby (backup from ingress to > >egress) or ingress as a PLR in FRR since the ingress and not > >the PLR determines the primary path. It would be difficult for the > >ingress to select a primary path that assures that a feasible backup > >is available at any PLR. > > > >For example: > > > > . . . . X > > . . > > - a --- b . > > / | \ . > > z | e > > \ | / > > - c --- d > > > >If Z is now the ingress, Z is unlikely to consider whether A has a > >viable repair path when selecting the path to E. > > Z's primary path to E will be strictly the shortest path and hence in your > example will be an ECMP via A and C. As before A's repair for the SRLG of > AB,CD will be via X, and so will that of C. So if AB only has failed, > traffic from Z to E will be split between ZAXE and ZCDE. But if AB and CD > have failed it will be split between ZAXE and ZCZAXE (since C's shortest > path to X is via Z. Note that this is NOT a loop, since the packet when it > comes back through Z is encapped with a destination of X not E. This is > ugly, but not disastrous. In MPLS TE A would simply have no backup that didn't violate an SRLG and the local-protect-available bit would not be set notifying the ingress of the problem. Given current algorithms the ingress would not know what to do about it (the CSPF would still show z-a-b-e as the best path). When this occurs the only way to solve it would be for Z to do an SPF rooted at each node on the path that could not get local-protect-available and figure out which links needed to be avoided for that reason. > > Z would likely pick > >the path z-a-b-e if the path z-c-d-e was a viable packup for failure > >of z-a and then A would have no way to create a viable backup. A > >better example of this is where one SRLG is a-b and a.x and another > >SRLG is a-b and a-c and the third is a-b and z-a. > > This case is not very interesting from Z's perspective. IF it detected ZA > had failed it would also have to assume that AB had failed, but it would do > this anyway since it must assume that node A has failed. Since the example was illustrating a limitation of MPLS TE, it is interesting from Z's perspective. > But this does raise an interesting question. So far we (well at least I) > have been thinking of SRLG in terms of a set of links failing. But we know > already that we need to consider node failure as an SRLG consisting of all > the links from a neighboring node, so if we see the link to our neighbor go > down we must assume that the node itself has gone down. So does this mean > that if we have a neighbor E, and SE is an SRLG with links XY and ST, the > ACTUAL SRLG we have to consider is node E failure and links ST and XY failure? > > > > > The path z-a-b-e > >and z-c-d-e are fully disjoint but A has no backup path. OTOH if A > >picked a primary path of z-c-d-e, Z, C and D all have viable backups > >when acting as the PLR. > > > >Note: I'm using . to mean multiple hops and - to mean one hop, but it > >only matters in the a.x.e case since there I just want to indicate > >higher cost. > > > >Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Wed Nov 24 16:47:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07032 for ; Wed, 24 Nov 2004 16:47:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX53B-0007Xd-JE for rtgwg-web-archive@ietf.org; Wed, 24 Nov 2004 16:51:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4wB-0004Vu-V2; Wed, 24 Nov 2004 16:44:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX4tp-0003oJ-Fj for rtgwg@megatron.ietf.org; Wed, 24 Nov 2004 16:42:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06718 for ; Wed, 24 Nov 2004 16:42:03 -0500 (EST) Received: from [208.246.215.5] (helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX4xe-0007S8-Qc for rtgwg@ietf.org; Wed, 24 Nov 2004 16:46:10 -0500 Received: from aatlas-lt.avici.com (b2-pc76.avici.com [10.2.100.76]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAOLfA4I029544; Wed, 24 Nov 2004 16:41:10 -0500 Message-Id: <5.1.0.14.2.20041124163517.02955f48@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 24 Nov 2004 16:40:40 -0500 To: curtis@faster-light.net From: Alia Atlas In-Reply-To: <200411242124.iAOLOLpu027851@workhorse.faster-light.net> References: 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-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Stewart Bryant , rtgwg@ietf.org, mike shand Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Curtis, At 04:24 PM 11/24/2004, Curtis Villamizar wrote: > > I don't see why that would be true. Remember that in that case of the > > tunnels appraoch, the whole essense of the approach is that the paths are > > unaffected by the failures. i.e. Fspace (aka Pspace) is the set of nodes > > which can be reached from S by paths which are unaffected by the failure, > > and Gspace (aka Qspace) is the set of nodes which can reach the "target" > > (proxy for destination) by paths which are unaffacted by the failure. > Hence > > the entire path tunneled to F/G and released to the destination is > > guaranteed to be unaffected by the failure. > > >The first part of your tunneling (since it isn't explicit route >tunneling) relies on IP forwarding. Plain IP with a multiple link >failure can have loops form even with symetric routes due to some >nodes reacting to the failure earlier than others. I think that Mike (and I) are using an implicit assumption. There are two potential causes for loops. The first case is when the use of the alternates themselves cause loops. This could occur if, as described in the LFA draft, two routers both have link-protecting LFAs that point at each other and the node fails, so that both those routers invoke their alternates. I believe that Mike was arguing that an alternate could be found which prepares for an SRLG failure, and therefore one wouldn't have that type of loops. The second potential cause for loops would be due to the different new FIB installation times of routers in the network. That is being addressed separately in the micro-loop prevention work. Take a look at http://www.psg.com/~zinin/ietf/rtgwg/IETF61-rtgwg-uloop-prev.ppt for the presentation that Mike, Stewart and I did at the last IETF. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Wed Nov 24 17:27:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09973 for ; Wed, 24 Nov 2004 17:27:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX5fv-0008OI-Uv for rtgwg-web-archive@ietf.org; Wed, 24 Nov 2004 17:31:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX5b5-0004gV-Ed; Wed, 24 Nov 2004 17:26:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX5Yp-0004FM-Hw for rtgwg@megatron.ietf.org; Wed, 24 Nov 2004 17:24:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09547 for ; Wed, 24 Nov 2004 17:24:24 -0500 (EST) Received: from 67.111.75.190.ptr.us.xo.net ([67.111.75.190] helo=BCNW02.bcn-inc.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX5cm-0008Fk-2Y for rtgwg@ietf.org; Wed, 24 Nov 2004 17:28:32 -0500 Received: from [10.10.20.60] ([10.10.20.60]) by BCNW02.bcn-inc.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Nov 2004 14:23:50 -0800 Message-ID: <41A509AC.2030003@bcn-inc.net> Date: Wed, 24 Nov 2004 14:22:36 -0800 From: Naiming Shen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@faster-light.net References: <200411241446.iAOEk6gc024065@workhorse.faster-light.net> In-Reply-To: <200411241446.iAOEk6gc024065@workhorse.faster-light.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Nov 2004 22:23:50.0426 (UTC) FILETIME=[45EA9FA0:01C4D274] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: Alia Atlas , rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit >> >>That's cool. I guess my concern was that not all the forwarding >>architecture has the indirect adjacency forwarding capability >>due to hardware or performance issues. > > > This is true. The performance issues of older hardware from specific > vendors is out of scope for a discussion of the protocols although it > is a practical consideration for providers that have certain older > hardware. I don't pretend to know which hardware can and can't do > this, but I do think its quite a lot of it. You might be surprised on this, since it's not just with the legacy hardware pieces, even the new ones, with increasing demand on services, features, and marketing requirement for small packet in line rate, this is one place performance can be boosted. Of course, this has "nothing" to do with the protocol design ;-) Cheers. - Naiming > > OTOH if the goal of the provider is to support VOIP and the gateways > that need the fast restoration are in the IGP it might be good enough > to support fast restoration of the IGP only and let BGP catch up at > its own slower pace. Again this is a practical consideration for the > operator and out of scope for the protocol specs themselves. > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Wed Nov 24 17:49:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11713 for ; Wed, 24 Nov 2004 17:49:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX60j-0000MJ-Kz for rtgwg-web-archive@ietf.org; Wed, 24 Nov 2004 17:53:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX5u7-0008VN-Cu; Wed, 24 Nov 2004 17:46:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX5rg-000818-VB for rtgwg@megatron.ietf.org; Wed, 24 Nov 2004 17:43:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11519 for ; Wed, 24 Nov 2004 17:43:54 -0500 (EST) Received: from [208.246.215.5] (helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX5vd-0000Gn-5X for rtgwg@ietf.org; Wed, 24 Nov 2004 17:48:02 -0500 Received: from aatlas-lt.avici.com (b2-pc76.avici.com [10.2.100.76]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAOMhF4I004022; Wed, 24 Nov 2004 17:43:15 -0500 Message-Id: <5.1.0.14.2.20041124174003.02950e30@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 24 Nov 2004 17:42:44 -0500 To: Naiming Shen From: Alia Atlas In-Reply-To: <41A509AC.2030003@bcn-inc.net> References: <200411241446.iAOEk6gc024065@workhorse.faster-light.net> <200411241446.iAOEk6gc024065@workhorse.faster-light.net> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: curtis@faster-light.net, Stewart Bryant , rtgwg@ietf.org Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 At 05:22 PM 11/24/2004, Naiming Shen wrote: >>This is true. The performance issues of older hardware from specific >>vendors is out of scope for a discussion of the protocols although it >>is a practical consideration for providers that have certain older >>hardware. I don't pretend to know which hardware can and can't do >>this, but I do think its quite a lot of it. > >You might be surprised on this, since it's not just with the legacy >hardware pieces, even the new ones, with increasing demand on services, >features, and marketing requirement for small packet in line rate, >this is one place performance can be boosted. Of course, this has >"nothing" to do with the protocol design ;-) Indirection is powerful, but can come at a performance cost. It doesn't have to; the hardware may need to fetch a memory location anyway, for instance, and this could just have the same memory location used multiple places. The side-benefit is that it can save substantially on FIB memory. As you say, nothing to do with protocol design, except that the protocol hierarchy makes it useful :-) Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Wed Nov 24 19:08:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19150 for ; Wed, 24 Nov 2004 19:08:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX7FR-00026R-LY for rtgwg-web-archive@ietf.org; Wed, 24 Nov 2004 19:12:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX796-0005WF-7w; Wed, 24 Nov 2004 19:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX71t-000488-AH for rtgwg@megatron.ietf.org; Wed, 24 Nov 2004 18:58:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18308 for ; Wed, 24 Nov 2004 18:58:29 -0500 (EST) Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CX75h-0001rX-5I for rtgwg@ietf.org; Wed, 24 Nov 2004 19:02:39 -0500 Received: (qmail 37792 invoked from network); 24 Nov 2004 23:58:22 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 24 Nov 2004 23:58:22 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAONuIih028404; Wed, 24 Nov 2004 18:56:26 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200411242356.iAONuIih028404@workhorse.faster-light.net> To: Naiming Shen In-reply-to: Your message of "Wed, 24 Nov 2004 14:22:36 PST." <41A509AC.2030003@bcn-inc.net> Date: Wed, 24 Nov 2004 18:56:18 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Alia Atlas , curtis@faster-light.net, rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa In message <41A509AC.2030003@bcn-inc.net> Naiming Shen writes: > > > >> > >>That's cool. I guess my concern was that not all the forwarding > >>architecture has the indirect adjacency forwarding capability > >>due to hardware or performance issues. > > > > > > This is true. The performance issues of older hardware from specific > > vendors is out of scope for a discussion of the protocols although it > > is a practical consideration for providers that have certain older > > hardware. I don't pretend to know which hardware can and can't do > > this, but I do think its quite a lot of it. > > You might be surprised on this, since it's not just with the legacy > hardware pieces, even the new ones, with increasing demand on services, > features, and marketing requirement for small packet in line rate, > this is one place performance can be boosted. Of course, this has > "nothing" to do with the protocol design ;-) > > Cheers. > - Naiming Or I might not be surprised and I was being generous. Either that or I was trying to imply that some vendors are currently making legacy hardware. But that wasn't the case. :-) Curtis > > OTOH if the goal of the provider is to support VOIP and the gateways > > that need the fast restoration are in the IGP it might be good enough > > to support fast restoration of the IGP only and let BGP catch up at > > its own slower pace. Again this is a practical consideration for the > > operator and out of scope for the protocol specs themselves. _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Nov 25 00:21:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12915 for ; Thu, 25 Nov 2004 00:21:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXC8X-0000OQ-JW for rtgwg-web-archive@ietf.org; Thu, 25 Nov 2004 00:25:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXC3A-0002yN-Ei; Thu, 25 Nov 2004 00:20:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXByX-0000pB-I2 for rtgwg@megatron.ietf.org; Thu, 25 Nov 2004 00:15:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12606 for ; Thu, 25 Nov 2004 00:15:20 -0500 (EST) Received: from [208.246.215.5] (helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXC2S-0000Gq-2D for rtgwg@ietf.org; Thu, 25 Nov 2004 00:19:32 -0500 Received: from aatlas-lt.avici.com ([10.2.103.22]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAP5Ee4I011452; Thu, 25 Nov 2004 00:14:40 -0500 Message-Id: <5.1.0.14.2.20041125000431.01dbe7a0@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Nov 2004 00:14:07 -0500 To: mike shand From: Alia Atlas In-Reply-To: <4.3.2.7.2.20041123160319.02a89008@jaws.cisco.com> References: <5.1.0.14.2.20041123105145.02861ad8@pop.avici.com> <4.3.2.7.2.20041123085914.023cddc8@jaws.cisco.com> <5.1.0.14.2.20041122160429.0292f008@pop.avici.com> <200411222009.iAMK9EvE011393@workhorse.faster-light.net> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: curtis@faster-light.net, Stewart Bryant , rtgwg@ietf.org Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Mike, It sounds like you're doing per-destination alternate assignment and the proxying is just limiting the set of candidate alternates then. I am a bit surprised by the numbers you have for just LFA plus tunnel protection. They seem very comparable to what I'm seeing with the U-turn alternates. I thought that the added degree of freedom with the tunnel might have made a noticeable difference. I know you've only simulated the U-turn alternates with link protection, but since you've got these topologies :-), do you have numbers for comparison there? The directed forwarding gets you up to 3 routers away and that adds enough to cover most cases. I've been thinking about the cascaded U-turns which could offer a similar reach. It's pretty straightforward to go upstream 2 hops instead of 1; there's a need to do additional computation for it. One can combine the computation, but at the cost of greater pessimism (likelihood of ignoring an alternate that did exist b/c it might not offer the desired protection). If combining the computation is worth the pessimism (something I'm still investigating), then it is possible to go an arbitrary number of hops upstream u-turning. Alia At 11:26 AM 11/23/2004, mike shand wrote: >At 10:58 23/11/2004 -0500, Alia Atlas wrote: >>Mike, >> >>The percentage that is missing is then those that require a single >>primary tunnel for repair? These are the number for repair for node failure? > >Yes, this is all node failure > >sec % df% LFA% >0.79% 4.6% 69.4% > >So what this tells us is that 69% of the repair paths required didn't need >a tunnel (to get to the nnh), so 31% did require a tunnel. Of these 4.6% >need DF as well, and 0.8% required a secondary repair (which itself may >have been satisfied by LFA or required DF). > > > >> I'm trying to get a sense of what the benefit from LFA is versus the >> tunnels versus the DF versus the secondary, etc. I'm interested in the >> different benefits for link protection and for node protection. > > >I may have some numbers for link protection.... > >I should probably re-run the simulations with some better stats, but these >will do for now. > >LFA DF >82% 1% >78% 12% >73% 20% >89% 1% >79% 0% >78% 1% > >All give 100% protection if DF is used where necessary. Of course >secondaries are not necessary for link repair (except perhaps for the case >of SRLG). > >SO what this > >LFA DF >82% 1% > >means is that 82% of links can be repaired without using tunnels. 18% >require tunnels and these are split with 17% not requiring DF and 1% >requiring DF. > > > > > >>In a somewhat related question, I understand that you are using a >>next-next-hop to proxy for destinations. > >Yes. > >> Is it possible that you miss a viable LFA to a destination because of >> this? I.e., the neighbor may be LFA with respect to the destination but >> not the next-next-hop? > >Yes, but that is why I say that in practice we skim the LFA reachable >destinations off the top, since that computation falls out of the rest. >That way we only tunnel traffic that HAS to be tunnelled. It would of >course work if we put this traffic in the tunnel, but it seems sensible to >avoid using a tunnel where possible. > > >>Also, how do you handle the ECMP cases where you may have multiple >>next-next-hops (even from the same next-hop)? That seems like a >>per-destination decision. > >OK, so you have > >S------E-----X > | > Y > >Traffic for destination D is split through X and Y. You have a choice. If >you want to preserve (some semblance of) the ECMP, then you split the >traffic between the repair for X and the repair for Y. Or you can simply >arbitrarily choose either of X or Y. You have to determine which nnh is >used for which destination anyway to do the traffic assignment to the >correct repair even when there is no ECMP. You can do this by noting the >nnh when you run the normal SPF at S. > > Mike > > > > >>Thanks, >>Alia >> >>At 04:40 AM 11/23/2004, mike shand wrote: >>>Alia, these may not be in the form you would like (but since I have them >>>to hand....). >>> >>>These are the same networks as before. df% is the percentage of repairs >>>which required directed forwarding (the same as before, the fraction of >>>individual repairs which needed DF). LFA% is the percentage which simply >>>used LFA (i.e. no tunnels) >>>Note that is no tunnels for ALL traffic. This doesn't mean that this is >>>the percentage of traffic which would not be tunnelled. That would be >>>much higher, since we can easily do per destination LFA determination. >>> >>>In case that is not clear, let me elaborate for the simple link failure >>>case. We can compute a repair for the failure of SE. Sometimes we can >>>repair ALL traffic (even that with a destination of E) by using LFA. >>>Other times we will need a tunnel to get to E. However, in that case, we >>>can compute the set of destinations which have LFAs, and we would only >>>use the tunnel for the remaining traffic. Of course it would >>>theoretically be possible to compute different tunnels for different >>>destinations, but that is not computational feasible. >>> >>> >>>sec % df% LFA% >>>0.79% 4.6% 69.4% >>>13.77% 41.9% 45.5% >>>3.98% 19.1% 66.3% >>>1.47% 1.2% 59.3% >>>0.50% 1.3% 79.4% >>>4.64% 1.3% 61.9% >>>0.00% 0.0% 62.6% >> _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Nov 25 00:34:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14081 for ; Thu, 25 Nov 2004 00:34:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXCKx-0000fE-2e for rtgwg-web-archive@ietf.org; Thu, 25 Nov 2004 00:38:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXCGG-0005GD-Gw; Thu, 25 Nov 2004 00:33:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXCBw-0004AQ-JB for rtgwg@megatron.ietf.org; Thu, 25 Nov 2004 00:29:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13743 for ; Thu, 25 Nov 2004 00:29:13 -0500 (EST) Received: from [208.246.215.5] (helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXCFx-0000Y6-DY for rtgwg@ietf.org; Thu, 25 Nov 2004 00:33:25 -0500 Received: from aatlas-lt.avici.com ([10.2.103.22]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAP5SS4I012409; Thu, 25 Nov 2004 00:28:28 -0500 Message-Id: <5.1.0.14.2.20041125001426.029ab980@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Nov 2004 00:27:57 -0500 To: mike shand From: Alia Atlas In-Reply-To: <4.3.2.7.2.20041123164815.02ac63e0@jaws.cisco.com> References: <5.1.0.14.2.20041123105932.02885a50@pop.avici.com> <4.3.2.7.2.20041123100156.02c5cac8@jaws.cisco.com> <5.1.0.14.2.20041122201101.02886df8@pop.avici.com> <200411222235.iAMMZ5kC012135@workhorse.faster-light.net> 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-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: curtis@faster-light.net, Stewart Bryant , rtgwg@ietf.org Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Hi Mike, At 11:48 AM 11/23/2004, mike shand wrote: >>But what is the far side of the SRLG? > >When you run a normal SPF rooted at S, as you traverse each SRLG you will >find which is the far side. And store all of them and use them as proxies? What about SRLG links in series? I guess you'd need to trim the trees as well. >>Trimming the trees after they're computed makes some sense, but then it a >>next-next-hop is dependent on the same SRLG to reach a destination, that >>destination won't be given an alternate (where there might be one without >>the proxying). > > >It certainly true that proxying reduces your options. Even in the non-SRLG >case it is true that if it were the case that a repair was impossible to a >proxy it may still be possible for all destinations except that proxy. >However, our view is that if the failure is not 100% repairable then it is >irreparable, so rather than giving some destinations poorer service it >would probably be better not to attempt repair at all for that link. Not >that we have seen any such irreparable links in real networks, but that is >the principle behind the proxying. I think I disagree with that argument. Consider a case where one wants to protect VPN traffic, but not necessarily all traffic. In that case, as long as all sources to the set of relevant PE routers are protected, it doesn't matter (as much) that the other destinations aren't protected. There can definitely be cases where one or more particular destination nodes are of the most importance; think of protecting a valuable video broadcast stream, for instance. It does seem to me that the proxying at just a next-next-hop won't work well for SRLGs. Doing the proxying at the end of each link of the SRLG and then deciding which to use for each destination might. >In the case of SRLG, this might translate to a case where it was necessary >to use secondary repairs because a few destinations could not otherwise be >repaired. What this would mean is that we might use a secondary repair for >some destinations which (if we had done the whole calculation per >destination) could ave been repaired via a single primary repair. This is >also true of node failures (which are of course SRLGs in disguse). Where would you do the secondary repair to? It couldn't be the next-next-hop normally used, because that path is at risk of failing due to the same SRLG (for some sub-set of the destinations). Also, on the secondary repairs, didn't you have some concerns about the computational feasibility of them? Node failures aren't general SRLGs in disguise; they're local SRLGs in disguise and that makes all the difference. The main difference is that distance comparisons don't help at all for SRLGs. The only way to tell that a path traverses an SRLG is to track it! SRLGs are random attributes of a link. For node failures or local SRLGs, one can simply avoid the relevant node. If you've got a local SRLG and no node-protection, then it's back to tracking, but a hopefully more limited set of SRLGs. Do you know a cleaner way to handle them? We can't prune them beforehand (b/c the routers in the network consider them for their SPFs) and one can't prune them during the SPF, b/c the path across a particular SRLG isn't known to be the shortest. One could poison the path at a certain distance, but the poisoning would be SRLG dependent. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Nov 25 00:40:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14556 for ; Thu, 25 Nov 2004 00:40:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXCQi-0000o8-75 for rtgwg-web-archive@ietf.org; Thu, 25 Nov 2004 00:44:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXCLo-0006pM-VW; Thu, 25 Nov 2004 00:39:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXCJG-00068P-C2 for rtgwg@megatron.ietf.org; Thu, 25 Nov 2004 00:36:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14332 for ; Thu, 25 Nov 2004 00:36:47 -0500 (EST) Received: from [208.246.215.5] (helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXCNH-0000iJ-B2 for rtgwg@ietf.org; Thu, 25 Nov 2004 00:40:59 -0500 Received: from aatlas-lt.avici.com ([10.2.103.22]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAP5Zw4I013901; Thu, 25 Nov 2004 00:35:59 -0500 Message-Id: <5.1.0.14.2.20041125002832.02962e90@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Nov 2004 00:35:27 -0500 To: Naiming Shen From: Alia Atlas In-Reply-To: <41A431F8.2090909@bcn-inc.net> References: <5.1.0.14.2.20041123134345.02889558@pop.avici.com> <200411222325.iAMNPC5Z012488@workhorse.faster-light.net> <200411222325.iAMNPC5Z012488@workhorse.faster-light.net> <5.1.0.14.2.20041123134345.02889558@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-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: curtis@faster-light.net, rtgwg@ietf.org, Stewart Bryant Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Hi Naiming, At 02:02 AM 11/24/2004, Naiming Shen wrote: >yes, it's regardless of the number of LSPs for each LSP switch-over, >but the total switch-over time is linear to the number of LSPs affected. The total switch-over time doesn't have to be linear with the number of LSPs affected. It's certainly possible to design a fast path where this isn't the case. I even think it is highly desirable (seen through the focused glare of fast-reroute technologies). >yes, indirection makes it scalable. but a hardware design or an >existing forwarding engine may not want to do indirection due to >extra processing at forwarding time. As I mentioned elsewhere, this is very hardware dependent. It doesn't have to be extra processing and it saves on FIB memory. >>Second, if node protection is desired, then it is necessary, in NFRR as >>in any of the tunneling schemes, to track the next-next-hop for each >>route or IGP destination. In that case, you need to organize indirection >>of routes to primary & alternate based upon the next-next-hop. >>NFRR provides no added benefit that I can see here. If one has the >>ability to add that extra level of indirecton (desirable anyway for fast >>IGP convergence), then that level can be added in to handle any of these >>IPFRR schemes. > >For the hardware can do indirection of adjacencies, you are right, >that's not a big problem. But even that, NFRR is only concerned about >a couple of next-nexthop adjacencies and the traffic is for sure >being switched over to the next-nexthop nodes. For non-nexthop schemes, >I guess one needs to worry about BGP nexthops which are IGP nodes, >and next-nexthops of those IGP routes, so there is more complexities >to figure out those alternative indirections. And in the case of >inter-area node-protection of ABR router, this will be rather tricky. These are the multi-homed prefix cases. Mike and Stewart have a good discussion of them (even slanted towards tunnels oddly enough ;-) in their draft. It's a bit of added complexity, but not too bad. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Nov 25 01:01:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16380 for ; Thu, 25 Nov 2004 01:01:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXCkz-0001Fj-28 for rtgwg-web-archive@ietf.org; Thu, 25 Nov 2004 01:05:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXCfr-0002SD-Sm; Thu, 25 Nov 2004 01:00:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXCes-0002Ct-3c for rtgwg@megatron.ietf.org; Thu, 25 Nov 2004 00:59:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16151 for ; Thu, 25 Nov 2004 00:59:06 -0500 (EST) Received: from [208.246.215.5] (helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXCis-0001Cz-7w for rtgwg@ietf.org; Thu, 25 Nov 2004 01:03:19 -0500 Received: from aatlas-lt.avici.com ([10.2.103.22]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAP5wR4I015472; Thu, 25 Nov 2004 00:58:28 -0500 Message-Id: <5.1.0.14.2.20041125004754.029658d8@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Nov 2004 00:57:56 -0500 To: mike shand From: Alia Atlas In-Reply-To: <4.3.2.7.2.20041124074442.033e9728@jaws.cisco.com> References: <200411231848.iANImCcX018549@workhorse.faster-light.net> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: curtis@faster-light.net, Stewart Bryant , rtgwg@ietf.org Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 At 03:17 AM 11/24/2004, mike shand wrote: >But this does raise an interesting question. So far we (well at least I) >have been thinking of SRLG in terms of a set of links failing. But we know >already that we need to consider node failure as an SRLG consisting of all >the links from a neighboring node, so if we see the link to our neighbor >go down we must assume that the node itself has gone down. So does this >mean that if we have a neighbor E, and SE is an SRLG with links XY and ST, >the ACTUAL SRLG we have to consider is node E failure and links ST and XY >failure? I think that the ideal is to have an alternate that provides link, node and SRLG protection. Each protection set is a different check. If such an alternate doesn't exist, then it's just a question of prioritization. We have the same problem between link and node protection. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 26 09:58:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12671 for ; Fri, 26 Nov 2004 09:58:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXhcl-0002SS-VF for rtgwg-web-archive@ietf.org; Fri, 26 Nov 2004 10:03:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhTI-0005WF-Fc; Fri, 26 Nov 2004 09:53:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhMJ-0002aF-DK for rtgwg@megatron.ietf.org; Fri, 26 Nov 2004 09:46:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28794 for ; Fri, 26 Nov 2004 06:24:37 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXeHQ-00069r-7Z for rtgwg@ietf.org; Fri, 26 Nov 2004 06:29:04 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2004 12:33:09 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAQBNlCu016225; Fri, 26 Nov 2004 12:23:48 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp4209.cisco.com [10.61.80.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA11580; Fri, 26 Nov 2004 11:23:46 GMT Message-ID: <41A71243.9080307@cisco.com> Date: Fri, 26 Nov 2004 11:23:47 +0000 From: Stewart Bryant 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: Alia Atlas References: <5.1.0.14.2.20041123105932.02885a50@pop.avici.com> <4.3.2.7.2.20041123100156.02c5cac8@jaws.cisco.com> <5.1.0.14.2.20041122201101.02886df8@pop.avici.com> <200411222235.iAMMZ5kC012135@workhorse.faster-light.net> <5.1.0.14.2.20041125001426.029ab980@pop.avici.com> In-Reply-To: <5.1.0.14.2.20041125001426.029ab980@pop.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: curtis@faster-light.net, rtgwg@ietf.org, mike shand Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit > I think I disagree with that argument. Consider a case where one wants > to protect VPN traffic, but not necessarily all traffic. In that case, > as long as all sources to the set of relevant PE routers are protected, > it doesn't matter (as much) that the other destinations aren't > protected. There can definitely be cases where one or more particular > destination nodes are of the most importance; think of protecting a > valuable video broadcast stream, for instance. > What we have not discussed, but which applies in this case, is applying LF to a subset of the prefixes. What Mike and I have always been alarmed at is the thought that in protecting some subset of the prefixes, we damage - perhaps quite badly- the service to other prefixes unless we have 100% coverage. Now what we could perhaps to is to run LF on just the prefixes that we can protect. So if we knew that we had 100% protection on say VPN and PWs. We could run controlled convergence on the adresses of those endpoint address and run uncontrolled on the rest. Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 26 10:29:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17531 for ; Fri, 26 Nov 2004 10:29:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXi6E-0003aA-L1 for rtgwg-web-archive@ietf.org; Fri, 26 Nov 2004 10:33:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhmg-0006nt-OO; Fri, 26 Nov 2004 10:13:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhlE-0005C2-Ni for rtgwg@megatron.ietf.org; Fri, 26 Nov 2004 10:11:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00322 for ; Fri, 26 Nov 2004 06:48:05 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXeeP-0006bk-1y for rtgwg@ietf.org; Fri, 26 Nov 2004 06:52:33 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2004 12:56:54 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAQBlXCu021174; Fri, 26 Nov 2004 12:47:33 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp4209.cisco.com [10.61.80.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA12233; Fri, 26 Nov 2004 11:47:31 GMT Message-ID: <41A717D4.3080803@cisco.com> Date: Fri, 26 Nov 2004 11:47:32 +0000 From: Stewart Bryant 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: Naiming Shen References: <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> <5.1.0.14.2.20041122115220.0292ba80@pop.avici.com> <41A2297D.7080200@bcn-inc.net> In-Reply-To: <41A2297D.7080200@bcn-inc.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Alia Atlas , rtgwg@ietf.org Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Naiming Shen wrote: > Alia, > >> We need to arrive at a method that is simpler and easier to use than >> RSVP-TE source-routed tunnels. Otherwise, the only benefit we'd get >> from an advanced IPFRR method is that it "isn't MPLS", and that's not >> sufficient IMHO. >> > > It does not have to be "MPLS" if you consider the IP TE mechanism though > :-) Can you summarise how you steer these packets through an IP network? Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 26 10:30:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17698 for ; Fri, 26 Nov 2004 10:30:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXi7I-0003ck-Md for rtgwg-web-archive@ietf.org; Fri, 26 Nov 2004 10:34:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhmk-0006ur-ME; Fri, 26 Nov 2004 10:13:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhlS-0005C2-E6 for rtgwg@megatron.ietf.org; Fri, 26 Nov 2004 10:12:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00684 for ; Fri, 26 Nov 2004 06:54:34 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXekf-0006it-Op for rtgwg@ietf.org; Fri, 26 Nov 2004 06:59:02 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2004 13:03:23 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAQBs2Cu022605; Fri, 26 Nov 2004 12:54:02 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp4209.cisco.com [10.61.80.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA12473; Fri, 26 Nov 2004 11:54:01 GMT Message-ID: <41A71958.5040903@cisco.com> Date: Fri, 26 Nov 2004 11:54:00 +0000 From: Stewart Bryant 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: curtis@faster-light.net References: <200411222255.iAMMtME1012301@workhorse.faster-light.net> In-Reply-To: <200411222255.iAMMtME1012301@workhorse.faster-light.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: rtgwg@ietf.org, Alia Atlas Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit > You definitely have an advantage in providing FRR for IP multicast. I > question whether that is a requirement for anyone. FRR seems to be > popular among those doing VOIP which is unicase, and VPNs. The VPNs > are typically LDP. Often the VOIP resides within an LDP VPN. There > is existance proof that you can run VOIP over LDP over MPLS/TE quite > nicely and use MPLS FRR. > > So far there hasn't been a lot of interest in multicast over MPLS > because those providers doing MPLS are not seeing a lot of multicast > traffic (and some don't offer native multicast) so they are fine with > offering multicast over IP with no TE or FRR. No, but video providers doing TV over IP use multicast, and I would have thought that they would have been interested in a fast-reroute capability that supported multicast. However there are simplications that one might be able to apply to such applications. - Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 26 10:34:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18798 for ; Fri, 26 Nov 2004 10:34:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXiB4-0003r6-4O for rtgwg-web-archive@ietf.org; Fri, 26 Nov 2004 10:38:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXi3l-00072M-3b; Fri, 26 Nov 2004 10:30:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhms-0005C2-7y for rtgwg@megatron.ietf.org; Fri, 26 Nov 2004 10:13:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00104 for ; Fri, 26 Nov 2004 06:44:34 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXeay-0006YN-Q6 for rtgwg@ietf.org; Fri, 26 Nov 2004 06:49:02 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2004 12:53:22 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAQBi1Cu020407; Fri, 26 Nov 2004 12:44:01 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp4209.cisco.com [10.61.80.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA12136; Fri, 26 Nov 2004 11:44:00 GMT Message-ID: <41A71701.2020602@cisco.com> Date: Fri, 26 Nov 2004 11:44:01 +0000 From: Stewart Bryant 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: curtis@faster-light.net References: <200411191516.iAJFG9To001667@workhorse.faster-light.net> In-Reply-To: <200411191516.iAJFG9To001667@workhorse.faster-light.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Alia Atlas , rtgwg@ietf.org Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > In message <419DE705.2060100@cisco.com> > Stewart Bryant writes: > >> >>OK, we will describe how to handle SRLG in the next version. >> >>However unknown SRLGs will affect all solutions, so if >>SRLG is a MUST, then all solutions need text describing >>their behavior under conditions of unknown SRLG. In >>particular unknown SRLG can result in mutually looping >>repairs (which could even be cyclic) and the solution >>must describe how to detect and break these loops. > > > > MPLS RSVP/TE FRR is loop free in the presense of unknown SRLG. At > worst the fast restoration fails and a new LSP is needed from ingress > to egress. So the worst case is a slow restoration but not a loop. How is this achieved? Presumably by excluding from the set of packets that can be repaired and packet with a label that indicates that it is part of a repair tunnel. If we were to always tunnel to the other side of the failure we could do the same sort of thing in IPFRR, but prefer to sent the packets native. We could however mark the packet as being repaired somehow (TOS bit perhaps) and then refuse to re-repair it. - Stewart > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 26 10:36:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19082 for ; Fri, 26 Nov 2004 10:36:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXiCy-0003tz-Ve for rtgwg-web-archive@ietf.org; Fri, 26 Nov 2004 10:40:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXi3s-00078n-56; Fri, 26 Nov 2004 10:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhnG-0005C2-3d for rtgwg@megatron.ietf.org; Fri, 26 Nov 2004 10:13:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26686 for ; Fri, 26 Nov 2004 05:50:26 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXdka-0005Tj-E3 for rtgwg@ietf.org; Fri, 26 Nov 2004 05:54:53 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2004 11:59:13 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAQAnrCu009505; Fri, 26 Nov 2004 11:49:54 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp4209.cisco.com [10.61.80.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA10646; Fri, 26 Nov 2004 10:49:52 GMT Message-ID: <41A70A51.2000805@cisco.com> Date: Fri, 26 Nov 2004 10:49:53 +0000 From: Stewart Bryant 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: curtis@faster-light.net References: <200411231509.iANF9r0t017524@workhorse.faster-light.net> In-Reply-To: <200411231509.iANF9r0t017524@workhorse.faster-light.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Alia Atlas , rtgwg@ietf.org, mike shand Subject: Re: node disjoint and SRLG X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit >>>I personally think that an important requirement for an IP FRR >>>technique is that feasible algorithms for SRLG be known so the product >>>of the WG isn't a dead end. So far there doesn't seem to be WG >>>concensus either way. >> >> >>I would tend to agree. It would be useful to ave some other opinions. >> >> Mike > > > > This is a requirements question so it is time for providers who intend > to use IP FRR to speak up. > I agree. The only way that we will ever resolve the issues that arise from the constraints that are intrinsic to each method is via a set of agree requirements. Such requirements need to address the needs of both the SP market and the Enterprise market. - Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 26 10:40:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19769 for ; Fri, 26 Nov 2004 10:40:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXiHQ-00043p-CG for rtgwg-web-archive@ietf.org; Fri, 26 Nov 2004 10:45:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXi47-0007M3-Qw; Fri, 26 Nov 2004 10:31:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhnt-0005C2-FJ for rtgwg@megatron.ietf.org; Fri, 26 Nov 2004 10:14:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24957 for ; Fri, 26 Nov 2004 05:14:36 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXdBt-0004nR-L3 for rtgwg@ietf.org; Fri, 26 Nov 2004 05:19:02 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2004 11:23:22 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAQAE3Cu001160; Fri, 26 Nov 2004 11:14:03 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp4209.cisco.com [10.61.80.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA09684; Fri, 26 Nov 2004 10:14:02 GMT Message-ID: <41A701EA.2090604@cisco.com> Date: Fri, 26 Nov 2004 10:14:02 +0000 From: Stewart Bryant 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 References: <4.3.2.7.2.20041123094512.0236a2e0@jaws.cisco.com> In-Reply-To: <4.3.2.7.2.20041123094512.0236a2e0@jaws.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Alia Atlas , curtis@faster-light.net, rtgwg@ietf.org Subject: Re: node disjoint and SRLG X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit mike shand wrote: > At 17:35 22/11/2004 -0500, Curtis Villamizar wrote: > >> In message <5.1.0.14.2.20041122160429.0292f008@pop.avici.com> >> Alia Atlas writes: >> > >> > Curtis, >> > >> > I think that Mike's numbers are for the percentage of node failures >> that >> > can't be repaired with a single primary tunnel+directed forwarding. >> > >> > I.e., it covers the node disjoint case pretty well. >> > >> > Alia >> >> >> What he's saying is that in the worst case he looked at 13.77% of the >> cases were not covered by single hop. With 2 hop there is 100% >> coverage but there is still some question about how computationally >> feasible the 2 hop algoritm is. The use of the word hop may be confusing here. This is two stage rather than two hop, and there may be multiple hops per stage. Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 26 10:41:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19939 for ; Fri, 26 Nov 2004 10:41:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXiIG-00045c-2Q for rtgwg-web-archive@ietf.org; Fri, 26 Nov 2004 10:45:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXi4A-0007Pl-Sc; Fri, 26 Nov 2004 10:31:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhnx-0005C2-Tw for rtgwg@megatron.ietf.org; Fri, 26 Nov 2004 10:14:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24815 for ; Fri, 26 Nov 2004 05:11:17 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXd8f-0004jz-Tb for rtgwg@ietf.org; Fri, 26 Nov 2004 05:15:43 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2004 11:20:02 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAQAAbCu000309; Fri, 26 Nov 2004 11:10:40 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp4209.cisco.com [10.61.80.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA09535; Fri, 26 Nov 2004 10:10:33 GMT Message-ID: <41A7011A.6080401@cisco.com> Date: Fri, 26 Nov 2004 10:10:34 +0000 From: Stewart Bryant 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: Alia Atlas References: <5.1.0.14.2.20041122201101.02886df8@pop.avici.com> In-Reply-To: <5.1.0.14.2.20041122201101.02886df8@pop.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Cc: curtis@faster-light.net, rtgwg@ietf.org, mike shand Subject: Re: node disjoint and SRLG X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit Alia Atlas wrote: > Curtis, > > At 05:35 PM 11/22/2004, Curtis Villamizar wrote: > >> My point was that the node disjoint problem is a subset of the SRLG >> problem. It is a subset because you can define a SRLG to be all links >> adjacent to a given node and therefore define the node disjoint case >> as an SRLG case. The local SRLG problem is also a subset of the SRLG >> problem. > > > Local SRLGs and node disjoint are easier cases to handle than general > SRLGs. Certainly, if one solves the general case, those can come for free. > > One issue that I see for the non-source-routed tunnel based approach is > that it uses the original next-next-hop as a proxy for a set of > destinations. This was to reduce the number of SPFs that we ran. If we relax that constaint we that look at alternatives. > It is possible that the path from the next-next-hop to a > particular destination will not be available because it traverses a link > in the same SRLG. Strictly because there is no G such that the path from S to G and the path from G to Si does not contain an SRLG member, even via a secondary repair. > > I think that this may make the destination assignment a bit trickier. > >> So far only MPLS/TE fully addresses SRLG and it does so very cleanly. > > > In a full overlay, MPLS/TE requires a CSPF per IGP node. > > If we were willing to accept an SPF per node in the topology, then > looking at SRLGs would be a lot simpler! Agreed. Indeed I suspect a number of new approaches then become feasible. > > If I were even willing to accept an SPF per neighbors' neighbor, it > would be completely clear how to do SRLGs for U-turn alternates. I can see how with one SPF per node you can increase the reach of U-turn, but surely to do SRLG you need to carry some vector in the packet to steer it at critical places? > > The computational complexity for MPLS/TE can be quite large, depending > on the number of tunnels to be considered. Sure, one can use techniques > to minimize the impact, but it is there. > > I'd say it's clear that for IP FRR, there's a desire to have > substantially fewer SPFs than 1 per node. That is a desire, although I have some personal doubts at the validity of that constraint. Remember that when we designed link state protocols we were using CPUs that were three orders of magnitude slower than those that we use today. > > There is the basic fact that without source-based routing, it might not > be possible to find an alternate. > >> If the general SRLG problem is not addressed, the failure to address >> the problem should at least be acknowledged in the documents. We can certainly do much better than the current document implies and any description should include some sort of applicability statement that describes the constraints. >> If SRLG >> is not a requirement for IP FRR, that should at least be stated in the >> framework document, but the limitations should also be acknowledged. Agreed. >> >> Normally it would be sufficient to list something as future work in >> the framework but that should be done where algorithms are known and >> only the protocol bits need to be defined later (and if needed). In >> this case there is question about whether feasible algorithms exists >> so the limitation should be acknowledged and not just dismissed. > > > I guess it depends on the particular technique considered, but there are > feasible algorithms for some of them. > > For loop-free alternates, one can track the SRLGs traversed by each > neighbor, and decide whether to use a loop-free neighbor based on > whether the SRLGs of concern are passed. We can do the same for tunnels, and you can do the same for U-turn. The general approach is that you must check that you do not go over an SRLG member during the period that you control the packet, and then make sure that it does not go over one after it is released. The issue is what to you do if it does. - Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 26 11:41:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27601 for ; Fri, 26 Nov 2004 11:41:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXjEa-00061I-CC for rtgwg-web-archive@ietf.org; Fri, 26 Nov 2004 11:46:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXj8a-0000yE-0u; Fri, 26 Nov 2004 11:40:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXj63-0007xB-R9 for rtgwg@megatron.ietf.org; Fri, 26 Nov 2004 11:37:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26854 for ; Fri, 26 Nov 2004 11:37:21 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXjAJ-0005ru-RV for rtgwg@ietf.org; Fri, 26 Nov 2004 11:41:51 -0500 Received: from aatlas-lt.avici.com ([10.2.103.13]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAQGaM4I005757; Fri, 26 Nov 2004 11:36:24 -0500 Message-Id: <5.1.0.14.2.20041126113353.0281a648@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 26 Nov 2004 11:35:53 -0500 To: Stewart Bryant From: Alia Atlas In-Reply-To: <41A71701.2020602@cisco.com> References: <200411191516.iAJFG9To001667@workhorse.faster-light.net> <200411191516.iAJFG9To001667@workhorse.faster-light.net> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: curtis@faster-light.net, rtgwg@ietf.org Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 At 06:44 AM 11/26/2004, Stewart Bryant wrote: >>MPLS RSVP/TE FRR is loop free in the presense of unknown SRLG. At >>worst the fast restoration fails and a new LSP is needed from ingress >>to egress. So the worst case is a slow restoration but not a loop. > >How is this achieved? Presumably by excluding from the set of packets >that can be repaired and packet with a label that indicates that it is >part of a repair tunnel. > >If we were to always tunnel to the other side of the failure we >could do the same sort of thing in IPFRR, but prefer to sent >the packets native. We could however mark the packet as being >repaired somehow (TOS bit perhaps) and then refuse to re-repair it. I think that if the point where a repaired packet re-joins the SPT is always a downstream path, then we could have the same property. Unfortunately that does limit coverage a bit. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 26 11:57:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28964 for ; Fri, 26 Nov 2004 11:57:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXjTq-0006PA-Jc for rtgwg-web-archive@ietf.org; Fri, 26 Nov 2004 12:01:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXjGL-0004cA-1V; Fri, 26 Nov 2004 11:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXjF2-0004BB-U9 for rtgwg@megatron.ietf.org; Fri, 26 Nov 2004 11:46:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28289 for ; Fri, 26 Nov 2004 11:46:38 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXjJM-00069m-EM for rtgwg@ietf.org; Fri, 26 Nov 2004 11:51:08 -0500 Received: from aatlas-lt.avici.com ([10.2.103.13]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAQGjt4I006371; Fri, 26 Nov 2004 11:45:57 -0500 Message-Id: <5.1.0.14.2.20041126114151.028208a0@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 26 Nov 2004 11:45:26 -0500 To: Stewart Bryant From: Alia Atlas In-Reply-To: <41A7011A.6080401@cisco.com> References: <5.1.0.14.2.20041122201101.02886df8@pop.avici.com> <5.1.0.14.2.20041122201101.02886df8@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-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: curtis@faster-light.net, rtgwg@ietf.org, mike shand Subject: Re: node disjoint and SRLG X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 At 05:10 AM 11/26/2004, Stewart Bryant wrote: >>If I were even willing to accept an SPF per neighbors' neighbor, it would >>be completely clear how to do SRLGs for U-turn alternates. > >I can see how with one SPF per node you can increase the reach of >U-turn, but surely to do SRLG you need to carry some vector in the >packet to steer it at critical places? There's no need for a vector in the packet. There needs to be a path from S to the node from which the SPT will be followed. The path from that node on the SPT needs to avoid the SRLG. Whether one can find this depends on the topology. >>I'd say it's clear that for IP FRR, there's a desire to have >>substantially fewer SPFs than 1 per node. > >That is a desire, although I have some personal doubts at the validity of >that constraint. Remember that when we designed link state >protocols we were using CPUs that were three orders of magnitude slower >than those that we use today. Which means we can do a handful of SPFs, not 100s or 1000s. >>I guess it depends on the particular technique considered, but there are >>feasible algorithms for some of them. >>For loop-free alternates, one can track the SRLGs traversed by each >>neighbor, and decide whether to use a loop-free neighbor based on whether >>the SRLGs of concern are passed. > >We can do the same for tunnels, and you can do the same for U-turn. >The general approach is that you must check that you do not go over >an SRLG member during the period that you control the packet, and >then make sure that it does not go over one after it is released. The >issue is what to you do if it does. Give up on that as an alternate and hunt for another one? Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 26 11:59:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29064 for ; Fri, 26 Nov 2004 11:59:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXjWG-0006RU-Nk for rtgwg-web-archive@ietf.org; Fri, 26 Nov 2004 12:04:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXjRY-000797-MG; Fri, 26 Nov 2004 11:59:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXjIc-00052F-DX for rtgwg@megatron.ietf.org; Fri, 26 Nov 2004 11:50:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28530 for ; Fri, 26 Nov 2004 11:50:19 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXjMu-0006Ds-Sj for rtgwg@ietf.org; Fri, 26 Nov 2004 11:54:50 -0500 Received: from aatlas-lt.avici.com ([10.2.103.13]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iAQGmb4I006535; Fri, 26 Nov 2004 11:48:39 -0500 Message-Id: <5.1.0.14.2.20041126114557.0288b258@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 26 Nov 2004 11:48:08 -0500 To: Stewart Bryant From: Alia Atlas In-Reply-To: <41A71243.9080307@cisco.com> References: <5.1.0.14.2.20041125001426.029ab980@pop.avici.com> <5.1.0.14.2.20041123105932.02885a50@pop.avici.com> <4.3.2.7.2.20041123100156.02c5cac8@jaws.cisco.com> <5.1.0.14.2.20041122201101.02886df8@pop.avici.com> <200411222235.iAMMZ5kC012135@workhorse.faster-light.net> <5.1.0.14.2.20041125001426.029ab980@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-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: curtis@faster-light.net, rtgwg@ietf.org, mike shand Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d At 06:23 AM 11/26/2004, Stewart Bryant wrote: >What we have not discussed, but which applies in this case, is applying LF >to a subset of the prefixes. The importance of the micro-loop prevention depends on the duration of the possible micro-loops. >What Mike and I have always been alarmed at is the thought that in >protecting some subset of the prefixes, we damage - perhaps quite badly- >the service to other prefixes unless we have 100% coverage. The micro-loop prevention can't make the service to other prefixes substantially worse. >Now what we could perhaps to is to run LF on just the prefixes that >we can protect. So if we knew that we had 100% protection on say >VPN and PWs. We could run controlled convergence on the adresses >of those endpoint address and run uncontrolled on the rest. Right, but how do we communicate the prefixes that are protected (or unprotected) in a reasonable fashion? Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 26 12:20:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00459 for ; Fri, 26 Nov 2004 12:20:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXjpX-0006sE-QE for rtgwg-web-archive@ietf.org; Fri, 26 Nov 2004 12:24:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXjkJ-0006CA-Cx; Fri, 26 Nov 2004 12:18:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXjTa-0007qI-EH for rtgwg@megatron.ietf.org; Fri, 26 Nov 2004 12:01:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29160 for ; Fri, 26 Nov 2004 12:01:40 -0500 (EST) Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXjXt-0006Tc-7H for rtgwg@ietf.org; Fri, 26 Nov 2004 12:06:10 -0500 Received: from [68.80.129.152] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8033005 for rtgwg@ietf.org; Fri, 26 Nov 2004 12:01:32 -0500 Message-Id: <6.1.2.0.0.20041126115755.03aaeec0@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 26 Nov 2004 12:01:18 -0500 To: rtgwg@ietf.org From: "Joel M. Halpern" In-Reply-To: <41A71243.9080307@cisco.com> References: <5.1.0.14.2.20041123105932.02885a50@pop.avici.com> <4.3.2.7.2.20041123100156.02c5cac8@jaws.cisco.com> <5.1.0.14.2.20041122201101.02886df8@pop.avici.com> <200411222235.iAMMZ5kC012135@workhorse.faster-light.net> <5.1.0.14.2.20041125001426.029ab980@pop.avici.com> <41A71243.9080307@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: Re: node disjoint and SRLG (was: questions on draft-bryant-ipfrr-tunnels-01.txt) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 There is a subtlety that I am missing in the phrase 100% protection for some traffic". Do you mean that we should be careful not to redirect (LF, U-turn, or tunnel) traffic which will not be properly protected by the technique, and use the tool for traffic for which we can know it will work? I had thought that when we said 100% protection we were talking about proptecting all traffic against all possible failures. Maybe I misunderstood. Yours, Joel At 06:23 AM 11/26/2004, Stewart Bryant wrote: >>I think I disagree with that argument. Consider a case where one wants >>to protect VPN traffic, but not necessarily all traffic. In that case, >>as long as all sources to the set of relevant PE routers are protected, >>it doesn't matter (as much) that the other destinations aren't >>protected. There can definitely be cases where one or more particular >>destination nodes are of the most importance; think of protecting a >>valuable video broadcast stream, for instance. > >What we have not discussed, but which applies in this case, is applying LF >to a subset of the prefixes. > >What Mike and I have always been alarmed at is the thought that in >protecting some subset of the prefixes, we damage - perhaps quite badly- >the service to other prefixes unless we have 100% coverage. > >Now what we could perhaps to is to run LF on just the prefixes that >we can protect. So if we knew that we had 100% protection on say >VPN and PWs. We could run controlled convergence on the adresses >of those endpoint address and run uncontrolled on the rest. > > >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 rtgwg-bounces@ietf.org Fri Nov 26 12:41:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02358 for ; Fri, 26 Nov 2004 12:41:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXkAr-0007Sc-UB for rtgwg-web-archive@ietf.org; Fri, 26 Nov 2004 12:46:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXk0z-0003bW-7x; Fri, 26 Nov 2004 12:36:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXjvg-0000wL-Ef for rtgwg@megatron.ietf.org; Fri, 26 Nov 2004 12:30:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01312 for ; Fri, 26 Nov 2004 12:30:42 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXk00-00077c-GG for rtgwg@ietf.org; Fri, 26 Nov 2004 12:35:12 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2004 18:39:35 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAQHU9Cu006193; Fri, 26 Nov 2004 18:30:10 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp4209.cisco.com [10.61.80.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA23730; Fri, 26 Nov 2004 17:30:08 GMT Message-ID: <41A76820.5000408@cisco.com> Date: Fri, 26 Nov 2004 17:30:08 +0000 From: Stewart Bryant 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: Alia Atlas References: <200411191516.iAJFG9To001667@workhorse.faster-light.net> <200411191516.iAJFG9To001667@workhorse.faster-light.net> <5.1.0.14.2.20041126113353.0281a648@pop.avici.com> In-Reply-To: <5.1.0.14.2.20041126113353.0281a648@pop.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: curtis@faster-light.net, rtgwg@ietf.org Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Alia Atlas wrote: > At 06:44 AM 11/26/2004, Stewart Bryant wrote: > >>> MPLS RSVP/TE FRR is loop free in the presense of unknown SRLG. At >>> worst the fast restoration fails and a new LSP is needed from ingress >>> to egress. So the worst case is a slow restoration but not a loop. >> >> >> How is this achieved? Presumably by excluding from the set of packets >> that can be repaired and packet with a label that indicates that it is >> part of a repair tunnel. >> >> If we were to always tunnel to the other side of the failure we >> could do the same sort of thing in IPFRR, but prefer to sent >> the packets native. We could however mark the packet as being >> repaired somehow (TOS bit perhaps) and then refuse to re-repair it. > > > I think that if the point where a repaired packet re-joins the SPT is > always a downstream path, then we could have the same property. > Unfortunately that does limit coverage a bit. > The assertion was that MPLS RSVP/TE FRR is unconditionally LF against unexpeceted SRLG. +---------------------------------+ | | A-----B--------C---------E--------F | D AB breaks and unexpectedly FE breaks. What stops the loop? Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 26 12:58:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03431 for ; Fri, 26 Nov 2004 12:58:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXkRI-0007pU-Hy for rtgwg-web-archive@ietf.org; Fri, 26 Nov 2004 13:03:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXkK3-0000iM-Q6; Fri, 26 Nov 2004 12:55:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXkIy-0000Mn-2x for rtgwg@megatron.ietf.org; Fri, 26 Nov 2004 12:54:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03182 for ; Fri, 26 Nov 2004 12:54:45 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXkNH-0007hc-Da for rtgwg@ietf.org; Fri, 26 Nov 2004 12:59:16 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2004 19:03:38 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAQHsCCu009675; Fri, 26 Nov 2004 18:54:12 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp4209.cisco.com [10.61.80.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA24508; Fri, 26 Nov 2004 17:54:11 GMT Message-ID: <41A76DC2.1050409@cisco.com> Date: Fri, 26 Nov 2004 17:54:10 +0000 From: Stewart Bryant 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: Alia Atlas References: <5.1.0.14.2.20041122201101.02886df8@pop.avici.com> <5.1.0.14.2.20041122201101.02886df8@pop.avici.com> <5.1.0.14.2.20041126114151.028208a0@pop.avici.com> In-Reply-To: <5.1.0.14.2.20041126114151.028208a0@pop.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: curtis@faster-light.net, rtgwg@ietf.org, mike shand Subject: Re: node disjoint and SRLG X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit >> That is a desire, although I have some personal doubts at the validity >> of that constraint. Remember that when we designed link state >> protocols we were using CPUs that were three orders of magnitude >> slower than those that we use today. > > > Which means we can do a handful of SPFs, not 100s or 1000s. Sorry I don't follow. When LS protocols were introduced (say 1990) we had processors that could do 1 mip doing everything. As I recall speed doubles every 18mths, which I think is 2^(14*2/3) which is over 500. So why can't we run order 500 SPFs? Where did all the performance go? Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 26 13:10:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04077 for ; Fri, 26 Nov 2004 13:10:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXkcE-00082S-RI for rtgwg-web-archive@ietf.org; Fri, 26 Nov 2004 13:14:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXkOj-0002Du-B7; Fri, 26 Nov 2004 13:00:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXkKz-00017r-8b for rtgwg@megatron.ietf.org; Fri, 26 Nov 2004 12:56:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03257 for ; Fri, 26 Nov 2004 12:56:50 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXkPJ-0007kx-Ju for rtgwg@ietf.org; Fri, 26 Nov 2004 13:01:21 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2004 19:05:45 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAQHuICu009970; Fri, 26 Nov 2004 18:56:19 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp4209.cisco.com [10.61.80.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA24587; Fri, 26 Nov 2004 17:56:17 GMT Message-ID: <41A76E41.8060207@cisco.com> Date: Fri, 26 Nov 2004 17:56:17 +0000 From: Stewart Bryant 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: Alia Atlas References: <5.1.0.14.2.20041122201101.02886df8@pop.avici.com> <5.1.0.14.2.20041122201101.02886df8@pop.avici.com> <5.1.0.14.2.20041126114151.028208a0@pop.avici.com> In-Reply-To: <5.1.0.14.2.20041126114151.028208a0@pop.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: curtis@faster-light.net, rtgwg@ietf.org, mike shand Subject: Re: node disjoint and SRLG X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Alia Atlas wrote: >>> If I were even willing to accept an SPF per neighbors' neighbor, it >>> would be completely clear how to do SRLGs for U-turn alternates. >> >> >> I can see how with one SPF per node you can increase the reach of >> U-turn, but surely to do SRLG you need to carry some vector in the >> packet to steer it at critical places? > > > There's no need for a vector in the packet. There needs to be a path > from S to the node from which the SPT will be followed. The path from > that node on the SPT needs to avoid the SRLG. > > Whether one can find this depends on the topology. > I think that you are saying if we don't have the vector we can look for a repair, but might not find one - depending on topology. Whilst I am saying if you have a vector you can create one where otherwise you mightnot find it. Is that right? Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 26 13:36:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07495 for ; Fri, 26 Nov 2004 13:36:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXl1b-0000nb-19 for rtgwg-web-archive@ietf.org; Fri, 26 Nov 2004 13:40:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXklz-0007kO-CA; Fri, 26 Nov 2004 13:24:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXkjG-0006v4-L6 for rtgwg@megatron.ietf.org; Fri, 26 Nov 2004 13:21:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04696 for ; Fri, 26 Nov 2004 13:21:55 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXknb-0008GB-1N for rtgwg@ietf.org; Fri, 26 Nov 2004 13:26:27 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2004 19:30:50 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAQILOCu014210; Fri, 26 Nov 2004 19:21:24 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp4209.cisco.com [10.61.80.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA25371; Fri, 26 Nov 2004 18:20:58 GMT Message-ID: <41A77409.7090303@cisco.com> Date: Fri, 26 Nov 2004 18:20:57 +0000 From: Stewart Bryant 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: Alia Atlas References: <5.1.0.14.2.20041125001426.029ab980@pop.avici.com> <5.1.0.14.2.20041123105932.02885a50@pop.avici.com> <4.3.2.7.2.20041123100156.02c5cac8@jaws.cisco.com> <5.1.0.14.2.20041122201101.02886df8@pop.avici.com> <200411222235.iAMMZ5kC012135@workhorse.faster-light.net> <5.1.0.14.2.20041125001426.029ab980@pop.avici.com> <5.1.0.14.2.20041126114557.0288b258@pop.avici.com> In-Reply-To: <5.1.0.14.2.20041126114557.0288b258@pop.avici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: curtis@faster-light.net, rtgwg@ietf.org, mike shand Subject: Re: node disjoint and SRLG X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Alia Atlas wrote: > At 06:23 AM 11/26/2004, Stewart Bryant wrote: > >> What we have not discussed, but which applies in this case, is >> applying LF to a subset of the prefixes. > > > The importance of the micro-loop prevention depends on the duration of > the possible micro-loops. Yes, we agree on that. > >> What Mike and I have always been alarmed at is the thought that in >> protecting some subset of the prefixes, we damage - perhaps quite >> badly- the service to other prefixes unless we have 100% coverage. > > > The micro-loop prevention can't make the service to other prefixes > substantially worse. If a prefix is not repaired, it is black-holed until we reconverge. All the LF approaches delay convergence, then those prefixes are black-holed for longer. > >> Now what we could perhaps to is to run LF on just the prefixes that >> we can protect. So if we knew that we had 100% protection on say >> VPN and PWs. We could run controlled convergence on the adresses >> of those endpoint address and run uncontrolled on the rest. > > > Right, but how do we communicate the prefixes that are protected (or > unprotected) in a reasonable fashion? Surely the simplest approach is for the node that issues the LSP to say "and by the way I am protecting the following IGP paths". That would take about 1000 bits which is not unreasonable. Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 26 13:46:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08623 for ; Fri, 26 Nov 2004 13:46:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXlB1-0001FW-Rx for rtgwg-web-archive@ietf.org; Fri, 26 Nov 2004 13:50:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXkxe-0001h6-9n; Fri, 26 Nov 2004 13:36:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXksQ-0000Sj-V3 for rtgwg@megatron.ietf.org; Fri, 26 Nov 2004 13:31:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06684 for ; Fri, 26 Nov 2004 13:31:24 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXkwl-0000Ww-Jg for rtgwg@ietf.org; Fri, 26 Nov 2004 13:35:55 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2004 19:40:18 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAQIUqCu015797; Fri, 26 Nov 2004 19:30:52 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp4209.cisco.com [10.61.80.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA25594; Fri, 26 Nov 2004 18:30:36 GMT Message-ID: <41A7764B.6020404@cisco.com> Date: Fri, 26 Nov 2004 18:30:35 +0000 From: Stewart Bryant 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: "Joel M. Halpern" References: <5.1.0.14.2.20041123105932.02885a50@pop.avici.com> <4.3.2.7.2.20041123100156.02c5cac8@jaws.cisco.com> <5.1.0.14.2.20041122201101.02886df8@pop.avici.com> <200411222235.iAMMZ5kC012135@workhorse.faster-light.net> <5.1.0.14.2.20041125001426.029ab980@pop.avici.com> <41A71243.9080307@cisco.com> <6.1.2.0.0.20041126115755.03aaeec0@localhost> In-Reply-To: <6.1.2.0.0.20041126115755.03aaeec0@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: rtgwg@ietf.org Subject: Re: node disjoint and SRLG X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Joel M. Halpern wrote: > There is a subtlety that I am missing in the phrase 100% protection for > some traffic". > Do you mean that we should be careful not to redirect (LF, U-turn, or > tunnel) traffic which will not be properly protected by the technique, > and use the tool for traffic for which we can know it will work? > > I had thought that when we said 100% protection we were talking about > proptecting all traffic against all possible failures. Maybe I > misunderstood. Mike and I wanted to do all src all dest repair for any failure. Say you cannot do this, you have a problem. If you use uncontrolled convergence then you damage the repairs, but you restore connectivity to unrepaired prefixes ASAP. If you use controlled convergence you protect the repairs, but you blackhole the unrepaired prefixes whilst you converge - which takes time. The suggestion below is to run controlled convergence on the prefixes that are repaired and uncontrolled (faster) convergence on the rest. Stewart > > Yours, > Joel > > At 06:23 AM 11/26/2004, Stewart Bryant wrote: > >>> I think I disagree with that argument. Consider a case where one >>> wants to protect VPN traffic, but not necessarily all traffic. In >>> that case, as long as all sources to the set of relevant PE routers >>> are protected, it doesn't matter (as much) that the other >>> destinations aren't protected. There can definitely be cases where >>> one or more particular destination nodes are of the most importance; >>> think of protecting a valuable video broadcast stream, for instance. >> >> >> What we have not discussed, but which applies in this case, is >> applying LF to a subset of the prefixes. >> >> What Mike and I have always been alarmed at is the thought that in >> protecting some subset of the prefixes, we damage - perhaps quite >> badly- the service to other prefixes unless we have 100% coverage. >> >> Now what we could perhaps to is to run LF on just the prefixes that >> we can protect. So if we knew that we had 100% protection on say >> VPN and PWs. We could run controlled convergence on the adresses >> of those endpoint address and run uncontrolled on the rest. >> >> >> 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 > > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Nov 26 22:59:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26936 for ; Fri, 26 Nov 2004 22:59:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXtoB-0006d2-Tj for rtgwg-web-archive@ietf.org; Fri, 26 Nov 2004 23:03:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXthZ-0000aR-Mg; Fri, 26 Nov 2004 22:56:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXtea-00005P-0O for rtgwg@megatron.ietf.org; Fri, 26 Nov 2004 22:53:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26701 for ; Fri, 26 Nov 2004 22:53:41 -0500 (EST) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CXtip-0006PJ-5A for rtgwg@ietf.org; Fri, 26 Nov 2004 22:58:17 -0500 Received: (qmail 36697 invoked from network); 27 Nov 2004 03:53:22 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 27 Nov 2004 03:53:22 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iAR3rN03001540; Fri, 26 Nov 2004 22:53:27 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200411270353.iAR3rN03001540@workhorse.faster-light.net> To: stbryant@cisco.com, mshand@cisco.com, aatlas@avici.com Date: Fri, 26 Nov 2004 22:53:23 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: curtis@faster-light.net, rtgwg@ietf.org Subject: Consolidated threads on node disjoint and SRLG X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 In-reply-to: Your message of "Thu, 25 Nov 2004 00:57:56 EST." <5.1.0.14.2.20041125004754.029658d8@pop.avici.com> In message <5.1.0.14.2.20041125004754.029658d8@pop.avici.com> Alia Atlas writes: > > At 03:17 AM 11/24/2004, mike shand wrote: > >But this does raise an interesting question. So far we (well at least I) > >have been thinking of SRLG in terms of a set of links failing. But we know > >already that we need to consider node failure as an SRLG consisting of all > >the links from a neighboring node, so if we see the link to our neighbor > >go down we must assume that the node itself has gone down. So does this > >mean that if we have a neighbor E, and SE is an SRLG with links XY and ST, > >the ACTUAL SRLG we have to consider is node E failure and links ST and XY > >failure? > > I think that the ideal is to have an alternate that provides link, node and > SRLG protection. Each protection set is a different check. If such an > alternate doesn't exist, then it's just a question of prioritization. We > have the same problem between link and node protection. > > Alia At least on MPLS FRR implementation provides a cost assigned per SRLG and something called a bias which is another number space. A non-zero bias in the path means that the backup is considered inadequate (the local-protect-available bit is not set). Setting costs on the SRLGs allows the operator to specify which SRLG are most in need of avoiding, where node-disjoint may be specified as an SRLG, therefore giving among ranking SRLG to the probability that the node goes down. Being able to support the same in IP FRR might be nice. Curtis ============================================================ In-reply-to: Your message of "Fri, 26 Nov 2004 11:44:01 GMT." <41A71701.2020602@cisco.com> In message <41A71701.2020602@cisco.com> Stewart Bryant writes: > > > Curtis Villamizar wrote: > > > In message <419DE705.2060100@cisco.com> > > Stewart Bryant writes: > > > >> > >>OK, we will describe how to handle SRLG in the next version. > >> > >>However unknown SRLGs will affect all solutions, so if > >>SRLG is a MUST, then all solutions need text describing > >>their behavior under conditions of unknown SRLG. In > >>particular unknown SRLG can result in mutually looping > >>repairs (which could even be cyclic) and the solution > >>must describe how to detect and break these loops. > > > > > > > > MPLS RSVP/TE FRR is loop free in the presense of unknown SRLG. At > > worst the fast restoration fails and a new LSP is needed from ingress > > to egress. So the worst case is a slow restoration but not a loop. > > How is this achieved? Presumably by excluding from the set of packets > that can be repaired and packet with a label that indicates that it is > part of a repair tunnel. The MPLS RSVP/TE tunnel is a source specified path from ingress to egress. The backup from any given PLR is a PLR specified path from ingress to egress that happens to merge with the primary as close as it is safe and efficient to do so. If the PLR is put into action and a link along the backup path fails, the traffic by definition goes into the bit bucket until the ingress determines a new path and reroutes the primary. No loop on unknown SRLG. Typically there is also a holddown on the primary tunnel so that traffic is forced into the tunnel even though it is known/thought to be down. If the old primary repairs its forwarding (SONET repair, whatever, PFM?) before the reroute completes, then traffic won't blackhole but the primary will continue the reroute. This prevents immediately falling back to IP and sending traffic into an IP loop. > If we were to always tunnel to the other side of the failure we > could do the same sort of thing in IPFRR, but prefer to sent > the packets native. We could however mark the packet as being > repaired somehow (TOS bit perhaps) and then refuse to re-repair it. > > - Stewart That would only work if you tunnel always went all the way to the exit point for the IGP which would mean that you couldn't use IP forwarding. At that point you might as well use MPLS FRR. Curtis ============================================================ In-reply-to: Your message of "Fri, 26 Nov 2004 11:35:53 EST." <5.1.0.14.2.20041126113353.0281a648@pop.avici.com> In message <5.1.0.14.2.20041126113353.0281a648@pop.avici.com> Alia Atlas writes: > > At 06:44 AM 11/26/2004, Stewart Bryant wrote: > >>MPLS RSVP/TE FRR is loop free in the presense of unknown SRLG. At > >>worst the fast restoration fails and a new LSP is needed from ingress > >>to egress. So the worst case is a slow restoration but not a loop. > > > >How is this achieved? Presumably by excluding from the set of packets > >that can be repaired and packet with a label that indicates that it is > >part of a repair tunnel. > > > >If we were to always tunnel to the other side of the failure we > >could do the same sort of thing in IPFRR, but prefer to sent > >the packets native. We could however mark the packet as being > >repaired somehow (TOS bit perhaps) and then refuse to re-repair it. > > I think that if the point where a repaired packet re-joins the SPT is > always a downstream path, then we could have the same > property. Unfortunately that does limit coverage a bit. > > Alia You seem to be missing the point. If there is an unknown SRLG the hop that you thought was downstream isn't really downstream anymore. That is the basis for loop formation with unknown SRLG. Curtis ============================================================ In-reply-to: Your message of "Fri, 26 Nov 2004 17:30:08 GMT." <41A76820.5000408@cisco.com> In message <41A76820.5000408@cisco.com> Stewart Bryant writes: > > > > Alia Atlas wrote: > > > At 06:44 AM 11/26/2004, Stewart Bryant wrote: > > > >>> MPLS RSVP/TE FRR is loop free in the presense of unknown SRLG. At > >>> worst the fast restoration fails and a new LSP is needed from ingress > >>> to egress. So the worst case is a slow restoration but not a loop. > >> > >> > >> How is this achieved? Presumably by excluding from the set of packets > >> that can be repaired and packet with a label that indicates that it is > >> part of a repair tunnel. > >> > >> If we were to always tunnel to the other side of the failure we > >> could do the same sort of thing in IPFRR, but prefer to sent > >> the packets native. We could however mark the packet as being > >> repaired somehow (TOS bit perhaps) and then refuse to re-repair it. > > > > > > I think that if the point where a repaired packet re-joins the SPT is > > always a downstream path, then we could have the same property. > > Unfortunately that does limit coverage a bit. > > > > The assertion was that MPLS RSVP/TE FRR is unconditionally LF against > unexpeceted SRLG. > > +---------------------------------+ > | | > A-----B--------C---------E--------F > | > D > > AB breaks and unexpectedly FE breaks. What stops the loop? > > Stewart I'm assuming that traffic is from A to D? Anyway, if the backup was A-F-E-C-D, then there is an MPLS label on F that points to interface E. That label is different from the label for the tunnel the originates at F and has the path F-E-C-D, and the label for A-F-E-C-D has no backup. It blackholes traffic rather than loop. MPLS does not rip off the MPLS encapsulation and try to forward the packet via IP when a failure occurs midway across a tunnel and put it into another tunnel in doing so. MPLS/TE does not do destination based forwarding of labeled packets, therefore if both the primary and the backup path breaks traffic blackholes rather than loops. Curtis ============================================================ In-reply-to: Your message of "Fri, 26 Nov 2004 17:54:10 GMT." <41A76DC2.1050409@cisco.com> In message <41A76DC2.1050409@cisco.com> Stewart Bryant writes: > > > >> That is a desire, although I have some personal doubts at the validity > >> of that constraint. Remember that when we designed link state > >> protocols we were using CPUs that were three orders of magnitude > >> slower than those that we use today. > > > > > > Which means we can do a handful of SPFs, not 100s or 1000s. > > Sorry I don't follow. When LS protocols were introduced (say 1990) > we had processors that could do 1 mip doing everything. As I recall > speed doubles every 18mths, which I think is 2^(14*2/3) which is > over 500. So why can't we run order 500 SPFs? Where did all the > performance go? > > Stewart Stewart, What certain providers called the "Macintosh based routers" (68030 based, not really a Mac) started to fall apart at a few hundred nodes. Processors in those days were in the 30-100 MHz range. Today that are a few GHz so at best 100 times faster but DRAM clock rates have not gone up at the same rate (not even a factor of 10) and that is the limiting factor for all but problems with good memory localization that fit into a small amount of memory (into the on-chip or SRAM cache). If anything better code has given us more than faster CPU (those old Mac routers had some pretty awful code from what I could tell). SPFs in the 1000 node range (just going from 100 to 1000 nodes requires almost 15 times more processor power - CPF is NlogN at best) seem to be running in the 50 msec range so 100s of them following an IGP change wouldn't seem to be a very good idea (5 sec solid CPU time for 100, which btw has to be shared with such things as BGP) and 1000s seems like a real bad idea. Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Sun Nov 28 13:51:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05943 for ; Sun, 28 Nov 2004 13:51:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYUE0-00027G-VW for rtgwg-web-archive@ietf.org; Sun, 28 Nov 2004 13:56:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYU4N-0003VU-Ti; Sun, 28 Nov 2004 13:46:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYU1s-0002rx-D7 for rtgwg@megatron.ietf.org; Sun, 28 Nov 2004 13:44:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05526 for ; Sun, 28 Nov 2004 13:44:11 -0500 (EST) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYU6Z-0001tF-Fq for rtgwg@ietf.org; Sun, 28 Nov 2004 13:49:07 -0500 Received: from aatlas-lt.avici.com ([10.2.103.236]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id iASIhH4I025252; Sun, 28 Nov 2004 13:43:17 -0500 Message-Id: <5.1.0.14.2.20041128133507.02818390@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 28 Nov 2004 13:42:50 -0500 To: curtis@faster-light.net From: Alia Atlas In-Reply-To: <200411270353.iAR3rN03001540@workhorse.faster-light.net> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: curtis@faster-light.net, mshand@cisco.com, rtgwg@ietf.org, stbryant@cisco.com Subject: Re: Consolidated threads on node disjoint and SRLG X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 At 10:53 PM 11/26/2004, Curtis Villamizar wrote: >At least on MPLS FRR implementation provides a cost assigned per SRLG >and something called a bias which is another number space. A non-zero >bias in the path means that the backup is considered inadequate (the >local-protect-available bit is not set). Setting costs on the SRLGs >allows the operator to specify which SRLG are most in need of >avoiding, where node-disjoint may be specified as an SRLG, therefore >giving among ranking SRLG to the probability that the node goes down. > >Being able to support the same in IP FRR might be nice. The mechanisms would need to be different. There are 2 parts to the problem - the first part is controllable (to some extent) like TE FRR and the second part isn't, b/c it is just the SPT. One can track the SRLGs and neighbors visited and make decisions based upon that. Those decisions could be made based on weighting of the SRLGs. It's not clear to me that it is necessary to go to this level of complication. It also makes it difficult for any distributed decisions where X needs to be able to determine what Y picked as an alternate or whether Y picked anything. > > I think that if the point where a repaired packet re-joins the SPT is > > always a downstream path, then we could have the same > > property. Unfortunately that does limit coverage a bit. > >You seem to be missing the point. If there is an unknown SRLG the hop >that you thought was downstream isn't really downstream anymore. That >is the basis for loop formation with unknown SRLG. Curtis, think about this as a 2 stage problem. The first stage is do the alternates cause a loop. The second stage is does the convergence to the new topology cause a loop. We are working on mechanisms to handle the second; for instance the path-locking with safe neighbors doesn't care about whether the set of failures were expected. For the first stage of do the alternates cause a loop, that can be handled by requiring that the alternate rejoin the SPT at a point downstream of where it left. This is very similar to TE FRR, where the backup rejoins the primary always downstream of the failure. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Nov 29 13:34:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17675 for ; Mon, 29 Nov 2004 13:34:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqRH-0008L8-Fl for rtgwg-web-archive@ietf.org; Mon, 29 Nov 2004 13:39:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYqHu-0004Np-4u; Mon, 29 Nov 2004 13:30:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYq9c-0003Iz-Ek for rtgwg@megatron.ietf.org; Mon, 29 Nov 2004 13:21:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16565 for ; Mon, 29 Nov 2004 13:21:37 -0500 (EST) Received: from 67.111.75.190.ptr.us.xo.net ([67.111.75.190] helo=BCNW02.bcn-inc.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqEZ-00082x-Ca for rtgwg@ietf.org; Mon, 29 Nov 2004 13:26:47 -0500 Received: from [10.10.20.60] ([10.10.20.60]) by BCNW02.bcn-inc.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 Nov 2004 10:21:06 -0800 Message-ID: <41AB6847.4070804@bcn-inc.net> Date: Mon, 29 Nov 2004 10:19:51 -0800 From: Naiming Shen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stewart Bryant References: <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> <5.1.0.14.2.20041115171224.0291bbc8@pop.avici.com> <5.1.0.14.2.20041122115220.0292ba80@pop.avici.com> <41A2297D.7080200@bcn-inc.net> <41A717D4.3080803@cisco.com> In-Reply-To: <41A717D4.3080803@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Nov 2004 18:21:06.0010 (UTC) FILETIME=[30E9DBA0:01C4D640] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Alia Atlas , rtgwg@ietf.org Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: rtgwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtgwg-bounces@ietf.org Errors-To: rtgwg-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Hi Stewart, Stewart Bryant wrote: > > > Naiming Shen wrote: > >> Alia, >> >>> We need to arrive at a method that is simpler and easier to use than >>> RSVP-TE source-routed tunnels. Otherwise, the only benefit we'd get >>> from an advanced IPFRR method is that it "isn't MPLS", and that's not >>> sufficient IMHO. >>> >> >> It does not have to be "MPLS" if you consider the IP TE mechanism though >> :-) > > > Can you summarise how you steer these packets through an IP network? I did a presentation in San Diego on IP TE, and here is the updated draft, http://www.ietf.org/internet-drafts/draft-shen-ip-te-rsp-03.txt Cheers, - Naiming > > Stewart > > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg