From rtgwg-bounces@ietf.org Fri Oct 1 04:26: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 EAA05418 for ; Fri, 1 Oct 2004 04:26:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDIsa-0001B7-Id for rtgwg-web-archive@ietf.org; Fri, 01 Oct 2004 04:35:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDITU-000627-Gk; Fri, 01 Oct 2004 04:09:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDIJo-0003rN-HN for rtgwg@megatron.ietf.org; Fri, 01 Oct 2004 03:59:09 -0400 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 DAA03899 for ; Fri, 1 Oct 2004 03:59:07 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDISD-0000es-54 for rtgwg@ietf.org; Fri, 01 Oct 2004 04:07:50 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Oct 2004 10:07:54 +0200 X-BrightmailFiltered: true 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 i917wVV8002430; Fri, 1 Oct 2004 09:58:32 +0200 (MEST) Received: from cisco.com (ams-clip-vpn-dhcp4396.cisco.com [10.61.81.43]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA07048; Fri, 1 Oct 2004 08:58:26 +0100 (BST) Message-ID: <415D0E22.70603@cisco.com> Date: Fri, 01 Oct 2004 08:58:26 +0100 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: <200409281749.i8SHnhIS012248@laptoy770.faster-light.net> <4159EAFC.1030502@cisco.com> <4159FA00.C2ADEC8F@redback.com> <1778930365.20040928171713@psg.com> <415A5955.CA2ED6CA@redback.com> <415A6700.706@cisco.com> <5.1.0.14.2.20040929210618.01d83d78@pop.avici.com> In-Reply-To: <5.1.0.14.2.20040929210618.01d83d78@pop.avici.com> 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: Alex Zinin , Don Fedyk , curtis@faster-light.net, rtgwg@ietf.org, mike shand Subject: Re: Reconvergence micro-loops: problem and solutions overview 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 Alia Atlas wrote: > > The benefit of U-Turn alternates is that it doesn't require MPLS or > any tunneling mechanism; without the tunneling, the full mesh for LDP > (if that is of interest) is not necessary. But the downside of U-turn is that it is a short range repair mechanism that can only direct over at most two hops and hence requires a downstream path within one hop of the repairer. - Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 1 13:45:21 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 NAA00024 for ; Fri, 1 Oct 2004 13:45:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDRbb-0005NA-Tx for rtgwg-web-archive@ietf.org; Fri, 01 Oct 2004 13:54:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDR3Q-0003zc-KX; Fri, 01 Oct 2004 13:18:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQTU-00009C-Mt for rtgwg@megatron.ietf.org; Fri, 01 Oct 2004 12:41:43 -0400 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 MAA22843 for ; Fri, 1 Oct 2004 12:41:38 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQbz-0002rE-3R for rtgwg@ietf.org; Fri, 01 Oct 2004 12:50:27 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CDQTP-0007KK-Py; Fri, 01 Oct 2004 16:41:35 +0000 Date: Fri, 1 Oct 2004 12:41:33 -0400 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1232775602.20041001124133@psg.com> To: Alia Atlas In-Reply-To: <5.1.0.14.2.20040929210618.01d83d78@pop.avici.com> References: <200409281749.i8SHnhIS012248@laptoy770.faster-light.net> <4159EAFC.1030502@cisco.com> <4159FA00.C2ADEC8F@redback.com> <1778930365.20040928171713@psg.com> <415A5955.CA2ED6CA@redback.com> <415A6700.706@cisco.com> <5.1.0.14.2.20040929210618.01d83d78@pop.avici.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Don Fedyk , Stewart Bryant , curtis@faster-light.net, mike shand , rtgwg@ietf.org Subject: Re: Reconvergence micro-loops: problem and solutions overview 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: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Alia, folks Wednesday, September 29, 2004, 9:21:51 PM, Alia Atlas wrote: ... > The claim that only the tunnel egress needs to understand this mechanism > appears to conflict with the argument being made that 100% coverage without > any network change is utterly critical and worth any complexity. I'd like to understand where this "100% without any network change" requirement is coming from. While I understand the desire to maximize coverage, I also have learned a while ago that trying to get that 100 or solve every corner case often comes at the price of greater complexity. I'm sure service providers knows even better than I do, so I'm wondering what the reasons behind this requirement are. Alex _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 1 13:50: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 NAA01114 for ; Fri, 1 Oct 2004 13:50:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDRgA-0005gz-9L for rtgwg-web-archive@ietf.org; Fri, 01 Oct 2004 13:58:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDRIf-0002S2-EH; Fri, 01 Oct 2004 13:34:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQig-0001WE-Uu for rtgwg@megatron.ietf.org; Fri, 01 Oct 2004 12:57:23 -0400 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 MAA24390 for ; Fri, 1 Oct 2004 12:57:20 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQrB-0003Pj-Jk for rtgwg@ietf.org; Fri, 01 Oct 2004 13:06:09 -0400 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 i91Gtx75012897; Fri, 1 Oct 2004 12:55:59 -0400 Message-Id: <5.1.0.14.2.20041001125328.0212d6b0@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Oct 2004 12:56:12 -0400 To: Stewart Bryant From: Alia Atlas In-Reply-To: <415D0E22.70603@cisco.com> References: <5.1.0.14.2.20040929210618.01d83d78@pop.avici.com> <200409281749.i8SHnhIS012248@laptoy770.faster-light.net> <4159EAFC.1030502@cisco.com> <4159FA00.C2ADEC8F@redback.com> <1778930365.20040928171713@psg.com> <415A5955.CA2ED6CA@redback.com> <415A6700.706@cisco.com> <5.1.0.14.2.20040929210618.01d83d78@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Alex Zinin , Don Fedyk , curtis@faster-light.net, rtgwg@ietf.org, mike shand Subject: Re: Reconvergence micro-loops: problem and solutions overview 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: 8abaac9e10c826e8252866cbe6766464 At 03:58 AM 10/1/2004, Stewart Bryant wrote: >Alia Atlas wrote: > > > >> >>The benefit of U-Turn alternates is that it doesn't require MPLS or any >>tunneling mechanism; without the tunneling, the full mesh for LDP (if >>that is of interest) is not necessary. > >But the downside of U-turn is that it is a short range repair mechanism >that can only direct over at most two hops and hence requires a >downstream path within one hop of the repairer. It is important to engineer the network; how they are currently engineered is extremely close to what is needed. Network engineering is necessary anyway, to ensure that a network remains at least 2-connected after a failure and to ensure that the use of links for alternates does not cause excessive congestion. Alia >- Stewart > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 1 14:42: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 OAA05726 for ; Fri, 1 Oct 2004 14:42:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDSV3-0007HK-VF for rtgwg-web-archive@ietf.org; Fri, 01 Oct 2004 14:51:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDS43-0005oE-LC; Fri, 01 Oct 2004 14:23:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDRbY-0008Hu-7Q for rtgwg@megatron.ietf.org; Fri, 01 Oct 2004 13:54:04 -0400 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 NAA01422 for ; Fri, 1 Oct 2004 13:54:01 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDRk3-0005nu-8C for rtgwg@ietf.org; Fri, 01 Oct 2004 14:02:51 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i91HrHC09639; Fri, 1 Oct 2004 13:53:17 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Oct 2004 13:53:17 -0400 Message-ID: <1E7140413C19AD4E827D63B820A24D2B01E20F49@zrtphxm2> From: "Don Fedyk" To: Alex Zinin , Alia Atlas Date: Fri, 1 Oct 2004 13:53:04 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: curtis@faster-light.net, rtgwg@ietf.org, mike shand , Stewart Bryant Subject: RE: Reconvergence micro-loops: problem and solutions overview 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 Hi Alex I agree with your comment. I believe we need to let Stewart and Mike answer where the requirement came from because it comes from their draft and presentation to the WG. By the way, I think the full description is 100% coverage during router convergence after single link failures. The fraction of time a network is converging versus stable is usually small. The fraction of single link failures compared to other type of failures tends to be higher. It might be worth capturing all of these statistics to get a perspective. Regards, Don > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Friday, October 01, 2004 12:42 PM > > Alia, folks > > Wednesday, September 29, 2004, 9:21:51 PM, Alia Atlas wrote: ... > > The claim that only the tunnel egress needs to understand this > > mechanism appears to conflict with the argument being made > that 100% > > coverage without any network change is utterly critical and > worth any > > complexity. > > I'd like to understand where this "100% without any network > change" requirement is coming from. While I understand the > desire to maximize coverage, I also have learned a while ago > that trying to get that 100 or solve every corner case often > comes at the price of greater complexity. I'm sure service > providers knows even better than I do, so I'm wondering what > the reasons behind this requirement are. > > Alex > > > _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 1 15:27: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 PAA09642 for ; Fri, 1 Oct 2004 15:27:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDTCS-0000di-QS for rtgwg-web-archive@ietf.org; Fri, 01 Oct 2004 15:36:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDSnE-0004Jm-Bl; Fri, 01 Oct 2004 15:10:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDSVl-0003UR-Nn for rtgwg@megatron.ietf.org; Fri, 01 Oct 2004 14:52:09 -0400 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 OAA06449 for ; Fri, 1 Oct 2004 14:52:06 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDSeG-0007ag-B9 for rtgwg@ietf.org; Fri, 01 Oct 2004 15:00:57 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 732188534AB; Fri, 1 Oct 2004 11:52:06 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00704-03; Fri, 1 Oct 2004 11:52:05 -0700 (PDT) Received: from redback.com (redwood.redback.com [155.53.44.120]) by prattle.redback.com (Postfix) with ESMTP id 99FA38534A7; Fri, 1 Oct 2004 11:52:01 -0700 (PDT) Message-ID: <415DA751.B1B5D7DD@redback.com> Date: Fri, 01 Oct 2004 11:52:01 -0700 From: Albert Tian X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.18 i386) X-Accept-Language: en MIME-Version: 1.0 To: Stewart Bryant References: <200409281749.i8SHnhIS012248@laptoy770.faster-light.net> <4159EAFC.1030502@cisco.com> <4159FA00.C2ADEC8F@redback.com> <1778930365.20040928171713@psg.com> <415A5955.CA2ED6CA@redback.com> <415A6700.706@cisco.com> <5.1.0.14.2.20040929210618.01d83d78@pop.avici.com> <415D0E22.70603@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Alex Zinin , Don Fedyk , Alia Atlas , curtis@faster-light.net, rtgwg@ietf.org, mike shand Subject: Re: Reconvergence micro-loops: problem and solutions overview 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, Another downside of U-turn seems to be that it is a unicast only strategy, which (correct me if I'm wrong) has no easy way to cover multicast traffic. If we would like to go one step further from basic loopfree, it would very desirable to have a mechanism that covers both unicast and multicast, perferably LDP as well. For link protection, if we use explicit repair paths that terminate on nexthops, all types of traffic are covered: unicast, multicast, LDP traffic. No extension is needed for PIM or LDP (except some minor ones to fix the RPF). Using explicit repair paths, node protection for all these traffic types is also achievable with more extensions. Thanks, Albert Stewart Bryant wrote: > > Alia Atlas wrote: > > > > > > > The benefit of U-Turn alternates is that it doesn't require MPLS or > > any tunneling mechanism; without the tunneling, the full mesh for LDP > > (if that is of interest) is not necessary. > > But the downside of U-turn is that it is a short range repair mechanism > that can only direct over at most two hops and hence requires a > downstream path within one hop of the repairer. > > - Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 1 15: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 PAA11286 for ; Fri, 1 Oct 2004 15:53:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDTbO-00024Q-0n for rtgwg-web-archive@ietf.org; Fri, 01 Oct 2004 16:02:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDTMM-000786-OL; Fri, 01 Oct 2004 15:46:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDT8A-0004HT-Eo for rtgwg@megatron.ietf.org; Fri, 01 Oct 2004 15:31:50 -0400 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 PAA09915 for ; Fri, 1 Oct 2004 15:31:47 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDTGf-0000nM-4C for rtgwg@ietf.org; Fri, 01 Oct 2004 15:40:38 -0400 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 i91JUs75015249; Fri, 1 Oct 2004 15:30:54 -0400 Message-Id: <5.1.0.14.2.20041001150514.02133448@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Oct 2004 15:30:58 -0400 To: Albert Tian From: Alia Atlas In-Reply-To: <415DA751.B1B5D7DD@redback.com> References: <200409281749.i8SHnhIS012248@laptoy770.faster-light.net> <4159EAFC.1030502@cisco.com> <4159FA00.C2ADEC8F@redback.com> <1778930365.20040928171713@psg.com> <415A5955.CA2ED6CA@redback.com> <415A6700.706@cisco.com> <5.1.0.14.2.20040929210618.01d83d78@pop.avici.com> <415D0E22.70603@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Alex Zinin , Don Fedyk , Stewart Bryant , curtis@faster-light.net, mike shand , rtgwg@ietf.org Subject: Re: Reconvergence micro-loops: problem and solutions overview 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: 0a7aa2e6e558383d84476dc338324fab Albert, The loop-free alternates are a unicast only strategy. One can extend them in multiple directions. One such direction is to look for a multicast solution. It would be interesting to consider what modifications to the RPF check might be possible for just loop-free. I believe that node protection is also quite interesting. Alia At 02:52 PM 10/1/2004, Albert Tian wrote: >Hi, > >Another downside of U-turn seems to be that it is a unicast only strategy, >which >(correct me if I'm wrong) has no easy way to cover multicast traffic. > >If we would like to go one step further from basic loopfree, it would very >desirable to have a mechanism that covers both unicast and multicast, >perferably >LDP as well. > >For link protection, if we use explicit repair paths that terminate on >nexthops, >all types of traffic are covered: unicast, multicast, LDP traffic. No >extension >is needed for PIM or LDP (except some minor ones to fix the RPF). Using >explicit >repair paths, node protection for all these traffic types is also achievable >with more extensions. > >Thanks, > >Albert > >Stewart Bryant wrote: > > > > Alia Atlas wrote: > > > > > > > > > > > > The benefit of U-Turn alternates is that it doesn't require MPLS or > > > any tunneling mechanism; without the tunneling, the full mesh for LDP > > > (if that is of interest) is not necessary. > > > > But the downside of U-turn is that it is a short range repair mechanism > > that can only direct over at most two hops and hence requires a > > downstream path within one hop of the repairer. > > > > - Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 1 19:01: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 TAA06628 for ; Fri, 1 Oct 2004 19:01:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWXM-0007MY-DP for rtgwg-web-archive@ietf.org; Fri, 01 Oct 2004 19:10:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDWK3-00073W-IY; Fri, 01 Oct 2004 18:56:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDVvO-0002a3-I0 for rtgwg@megatron.ietf.org; Fri, 01 Oct 2004 18:30:55 -0400 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 SAA03596 for ; Fri, 1 Oct 2004 18:30:48 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDW3t-0003DC-9u for rtgwg@ietf.org; Fri, 01 Oct 2004 18:39:40 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 4877BAD7518; Fri, 1 Oct 2004 15:30:46 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20897-07; Fri, 1 Oct 2004 15:30:45 -0700 (PDT) Received: from redback.com (redwood.redback.com [155.53.44.120]) by prattle.redback.com (Postfix) with ESMTP id 5347CAD7519; Fri, 1 Oct 2004 15:30:45 -0700 (PDT) Message-ID: <415DDA95.EC1B763F@redback.com> Date: Fri, 01 Oct 2004 15:30:45 -0700 From: Albert Tian X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.18 i386) X-Accept-Language: en MIME-Version: 1.0 To: Alia Atlas References: <200409281749.i8SHnhIS012248@laptoy770.faster-light.net> <4159EAFC.1030502@cisco.com> <4159FA00.C2ADEC8F@redback.com> <1778930365.20040928171713@psg.com> <415A5955.CA2ED6CA@redback.com> <415A6700.706@cisco.com> <5.1.0.14.2.20040929210618.01d83d78@pop.avici.com> <415D0E22.70603@cisco.com> <5.1.0.14.2.20041001150514.02133448@pop.avici.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Cc: Alex Zinin , Don Fedyk , Stewart Bryant , curtis@faster-light.net, mike shand , rtgwg@ietf.org Subject: FRR for ip multicast traffic 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: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Hi, Alia, I'm starting a new thread as multicast seems to a big topic. (Our real subjects have drifted thousand miles from micro-loop prevention already :-) We all know multicast routing protocols build distribution trees to deliver multicast packets. When a link or node on the tree fails, some of the sub trees downstream to the failure will be detached. So the key to protect multicast traffic is to construct the repair paths to reattach the root of these subtrees without going through the link or node being protected. Therefore the repair paths have to terminate on these subtree roots. Because of this, both the basic loopfree and the U-turn will not work for multicast. You can not find an alternative that is not on the distribution tree and send traffic to it since that alternative will not have proper multicast forwarding state. Also because multicast forwarding states only exists on the distribution tree, rerouted multicast traffic has to be encapsulated while traversing the repair path. In other words, the repair paths have to be tunnels. A clear solution is to use explicit paths to attach the subtree roots. In most cases the subtree roots will be the nexthop or next-nexthops from unicast routing point of view. In link protection, only one subtree can be detached due the link failure. So the solution is to use an explicit repair path to connect the downstream node to the upstream via a different route. The same explicit path can also be used for unicast/LDP traffic protection, so in most of the cases no additional explicit tunnels are needed. In node protection, several subtrees can be detached due to node failure. So multiple repair paths have to be established to connect each of the subtree roots to the upstream nodes. The upstream must replicate the packets and send onto each repair paths. In most cases, the subtree roots will be next-nexthops for unicast routing. Regarding the RPF, packets arriving from the repair path has to be accepted. They may arrive on wrong interface and fail the RPF check. So here are the requirements in summary: a) repair paths have to terminate at the nexthops or next-nexthops (subtree roots) b) rerouted traffic must be encapsulated. (repair paths must be tunnels). c) rerouted traffic must be accepted (pass the RPF check) The TE tunnel based FRR solution satisfies all these requirements, and in most cases no (or very few) additional tunels need to be maintained compares to unicast FRR. The current U-turn solution can not satisfy the first two requirements. The last one is beyond the point if the first two issues can not be solved. The tunnel based FRR solution satisfies the first requirement, but will need double encapsulation (two GRE headers probably) for repair traffic when comes to the second, since they used one encapsulation already. Thanks, Albert Alia Atlas wrote: > > Albert, > > The loop-free alternates are a unicast only strategy. One can extend them > in multiple directions. One such direction is to look for a multicast > solution. It would be interesting to consider what modifications to the > RPF check might be possible for just loop-free. > > I believe that node protection is also quite interesting. > > Alia > > At 02:52 PM 10/1/2004, Albert Tian wrote: > >Hi, > > > >Another downside of U-turn seems to be that it is a unicast only strategy, > >which > >(correct me if I'm wrong) has no easy way to cover multicast traffic. > > > >If we would like to go one step further from basic loopfree, it would very > >desirable to have a mechanism that covers both unicast and multicast, > >perferably > >LDP as well. > > > >For link protection, if we use explicit repair paths that terminate on > >nexthops, > >all types of traffic are covered: unicast, multicast, LDP traffic. No > >extension > >is needed for PIM or LDP (except some minor ones to fix the RPF). Using > >explicit > >repair paths, node protection for all these traffic types is also achievable > >with more extensions. > > > >Thanks, > > > >Albert > > > >Stewart Bryant wrote: > > > > > > Alia Atlas wrote: > > > > > > > > > > > > > > > > > The benefit of U-Turn alternates is that it doesn't require MPLS or > > > > any tunneling mechanism; without the tunneling, the full mesh for LDP > > > > (if that is of interest) is not necessary. > > > > > > But the downside of U-turn is that it is a short range repair mechanism > > > that can only direct over at most two hops and hence requires a > > > downstream path within one hop of the repairer. > > > > > > - Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Mon Oct 4 17:11: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 RAA23627 for ; Mon, 4 Oct 2004 17:11:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEaGc-0007Ut-Fp for rtgwg-web-archive@ietf.org; Mon, 04 Oct 2004 17:21:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEZ2Z-0007c1-6z; Mon, 04 Oct 2004 16:02:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEYmq-0008J3-Ee; Mon, 04 Oct 2004 15:46:20 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08810; Mon, 4 Oct 2004 15:46:18 -0400 (EDT) Message-Id: <200410041946.PAA08810@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 04 Oct 2004 15:46:18 -0400 Cc: rtgwg@ietf.org Subject: I-D ACTION:draft-ietf-rtgwg-ipfrr-spec-base-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.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group Working Group of the IETF. Title : Basic Specification for IP Fast-Reroute: Loop-free Alternates Author(s) : A. Atlas Filename : draft-ietf-rtgwg-ipfrr-spec-base-01.txt Pages : 18 Date : 2004-10-4 This document defines an architecture and selection process for providing local protection for IP unicast and/or LDP traffic in the event of a single link or node failure until the router has converged. When computing the primary next-hop for a prefix, a router S also determines an alternate next-hop which can be used if the primary next-hop fails. The alternate next-hop is said to be a loop-free alternate, which goes to a neighbor whose shortest path to the prefix does not go back through the router S. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-ipfrr-spec-base-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rtgwg-ipfrr-spec-base-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rtgwg-ipfrr-spec-base-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-4152713.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rtgwg-ipfrr-spec-base-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rtgwg-ipfrr-spec-base-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-4152713.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg --NextPart-- From rtgwg-bounces@ietf.org Mon Oct 4 22:59: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 WAA25011 for ; Mon, 4 Oct 2004 22:59:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEfhd-0004oQ-Up for rtgwg-web-archive@ietf.org; Mon, 04 Oct 2004 23:09:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEfXR-0000R8-Dw; Mon, 04 Oct 2004 22:58:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEfVM-0008Nd-6S for rtgwg@megatron.ietf.org; Mon, 04 Oct 2004 22:56:44 -0400 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 WAA24841 for ; Mon, 4 Oct 2004 22:56:41 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEfeV-0004BR-Kd for rtgwg@ietf.org; Mon, 04 Oct 2004 23:06:15 -0400 Received: from aatlas-lt.avici.com (b2vpnpc159.avici.com [10.2.103.159]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i952tjPb029040; Mon, 4 Oct 2004 22:55:49 -0400 Message-Id: <5.1.0.14.2.20041004225103.021e4fa0@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Oct 2004 22:55:58 -0400 To: Albert Tian From: Alia Atlas In-Reply-To: <415DDA95.EC1B763F@redback.com> References: <200409281749.i8SHnhIS012248@laptoy770.faster-light.net> <4159EAFC.1030502@cisco.com> <4159FA00.C2ADEC8F@redback.com> <1778930365.20040928171713@psg.com> <415A5955.CA2ED6CA@redback.com> <415A6700.706@cisco.com> <5.1.0.14.2.20040929210618.01d83d78@pop.avici.com> <415D0E22.70603@cisco.com> <5.1.0.14.2.20041001150514.02133448@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: Alex Zinin , Don Fedyk , Stewart Bryant , curtis@faster-light.net, mike shand , rtgwg@ietf.org Subject: Re: FRR for ip multicast traffic 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: 42e3ed3f10a1d8bef690f09da16f507a Hi Albert, I am not convinced that tunnels are the only way to go for multicast. Don't they reduce or remove the benefit of sending the traffic as multicast for that portion of the network? If the alternate path is to protect against a node failure and there are multiple neighbor's neighbors to be sent to, then it seems that bandwidth is wasted by doing the replication at the PLR. Alia At 06:30 PM 10/1/2004, Albert Tian wrote: >Hi, Alia, > >I'm starting a new thread as multicast seems to a big topic. (Our real >subjects >have drifted thousand miles from micro-loop prevention already :-) > >We all know multicast routing protocols build distribution trees to deliver >multicast packets. When a link or node on the tree fails, some of the sub >trees >downstream to the failure will be detached. So the key to protect multicast >traffic is to construct the repair paths to reattach the root of these >subtrees >without going through the link or node being protected. Therefore the repair >paths have to terminate on these subtree roots. > >Because of this, both the basic loopfree and the U-turn will not work for >multicast. You can not find an alternative that is not on the distribution >tree >and send traffic to it since that alternative will not have proper multicast >forwarding state. > >Also because multicast forwarding states only exists on the distribution tree, >rerouted multicast traffic has to be encapsulated while traversing the repair >path. In other words, the repair paths have to be tunnels. > >A clear solution is to use explicit paths to attach the subtree roots. In most >cases the subtree roots will be the nexthop or next-nexthops from unicast >routing point of view. > >In link protection, only one subtree can be detached due the link failure. So >the solution is to use an explicit repair path to connect the downstream >node to >the upstream via a different route. The same explicit path can also be >used for >unicast/LDP traffic protection, so in most of the cases no additional explicit >tunnels are needed. > >In node protection, several subtrees can be detached due to node failure. So >multiple repair paths have to be established to connect each of the subtree >roots to the upstream nodes. The upstream must replicate the packets and send >onto each repair paths. In most cases, the subtree roots will be next-nexthops >for unicast routing. > >Regarding the RPF, packets arriving from the repair path has to be accepted. >They may arrive on wrong interface and fail the RPF check. > >So here are the requirements in summary: > >a) repair paths have to terminate at the nexthops or next-nexthops (subtree >roots) >b) rerouted traffic must be encapsulated. (repair paths must be tunnels). >c) rerouted traffic must be accepted (pass the RPF check) > >The TE tunnel based FRR solution satisfies all these requirements, and in most >cases no (or very few) additional tunels need to be maintained compares to >unicast FRR. > >The current U-turn solution can not satisfy the first two requirements. >The last >one is beyond the point if the first two issues can not be solved. > >The tunnel based FRR solution satisfies the first requirement, but will need >double encapsulation (two GRE headers probably) for repair traffic when >comes to >the second, since they used one encapsulation already. > >Thanks, > >Albert > > >Alia Atlas wrote: > > > > Albert, > > > > The loop-free alternates are a unicast only strategy. One can extend them > > in multiple directions. One such direction is to look for a multicast > > solution. It would be interesting to consider what modifications to the > > RPF check might be possible for just loop-free. > > > > I believe that node protection is also quite interesting. > > > > Alia > > > > At 02:52 PM 10/1/2004, Albert Tian wrote: > > >Hi, > > > > > >Another downside of U-turn seems to be that it is a unicast only strategy, > > >which > > >(correct me if I'm wrong) has no easy way to cover multicast traffic. > > > > > >If we would like to go one step further from basic loopfree, it would very > > >desirable to have a mechanism that covers both unicast and multicast, > > >perferably > > >LDP as well. > > > > > >For link protection, if we use explicit repair paths that terminate on > > >nexthops, > > >all types of traffic are covered: unicast, multicast, LDP traffic. No > > >extension > > >is needed for PIM or LDP (except some minor ones to fix the RPF). Using > > >explicit > > >repair paths, node protection for all these traffic types is also > achievable > > >with more extensions. > > > > > >Thanks, > > > > > >Albert > > > > > >Stewart Bryant wrote: > > > > > > > > Alia Atlas wrote: > > > > > > > > > > > > > > > > > > > > > > The benefit of U-Turn alternates is that it doesn't require MPLS or > > > > > any tunneling mechanism; without the tunneling, the full mesh for LDP > > > > > (if that is of interest) is not necessary. > > > > > > > > But the downside of U-turn is that it is a short range repair mechanism > > > > that can only direct over at most two hops and hence requires a > > > > downstream path within one hop of the repairer. > > > > > > > > - Stewart _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Oct 5 10:11:18 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 KAA01150 for ; Tue, 5 Oct 2004 10:11:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEqBV-0002Su-1Z for rtgwg-web-archive@ietf.org; Tue, 05 Oct 2004 10:20:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEpyo-00020f-W3; Tue, 05 Oct 2004 10:07:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEpr9-0006fV-7n for rtgwg@megatron.ietf.org; Tue, 05 Oct 2004 09:59:59 -0400 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 JAA29553 for ; Tue, 5 Oct 2004 09:59:53 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEq0R-00012G-0D for rtgwg@ietf.org; Tue, 05 Oct 2004 10:09:32 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 33A2E82299B; Tue, 5 Oct 2004 06:59:46 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05118-04; Tue, 5 Oct 2004 06:59:45 -0700 (PDT) Received: from redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id 0F9F0822997; Tue, 5 Oct 2004 06:59:38 -0700 (PDT) Received: from malt (localhost [127.0.0.1]) by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) with ESMTP id GAA23682; Tue, 5 Oct 2004 06:59:37 -0700 (PDT) Message-Id: <200410051359.GAA23682@redback.com> To: Alia Atlas In-reply-to: Mail from Alia Atlas dated Mon, 04 Oct 2004 22:55:58 EDT <5.1.0.14.2.20041004225103.021e4fa0@pop.avici.com> Date: Tue, 05 Oct 2004 06:59:37 -0700 From: Naiming Shen X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: Alex Zinin , rtgwg@ietf.org, Don Fedyk , curtis@faster-light.net, Stewart Bryant , mike shand Subject: Re: FRR for ip multicast traffic 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: ded6070f7eed56e10c4f4d0d5043d9c7 Alia, We are discussing in the context of FRR multicast traffic during the nexthop link/node failure, for a limited number of nexthop or next-nexthop nodes, for a limited time such as a couple of seconds. I don't think efficiency of bandwidth usage is a major concern in this case. thanks. ] Hi Albert, ] ] I am not convinced that tunnels are the only way to go for ] multicast. Don't they reduce or remove the benefit of sending the traffic ] as multicast for that portion of the network? If the alternate path is to ] protect against a node failure and there are multiple neighbor's neighbors ] to be sent to, then it seems that bandwidth is wasted by doing the ] replication at the PLR. ] ] Alia ] ] At 06:30 PM 10/1/2004, Albert Tian wrote: ] >Hi, Alia, ] > ] >I'm starting a new thread as multicast seems to a big topic. (Our real ] >subjects ] >have drifted thousand miles from micro-loop prevention already :-) ] > ] >We all know multicast routing protocols build distribution trees to deliver ] >multicast packets. When a link or node on the tree fails, some of the sub ] >trees ] >downstream to the failure will be detached. So the key to protect multicast ] >traffic is to construct the repair paths to reattach the root of these ] >subtrees ] >without going through the link or node being protected. Therefore the repai r ] >paths have to terminate on these subtree roots. ] > ] >Because of this, both the basic loopfree and the U-turn will not work for ] >multicast. You can not find an alternative that is not on the distribution ] >tree ] >and send traffic to it since that alternative will not have proper multicas t ] >forwarding state. ] > ] >Also because multicast forwarding states only exists on the distribution tr ee, ] >rerouted multicast traffic has to be encapsulated while traversing the repa ir ] >path. In other words, the repair paths have to be tunnels. ] > ] >A clear solution is to use explicit paths to attach the subtree roots. In m ost ] >cases the subtree roots will be the nexthop or next-nexthops from unicast ] >routing point of view. ] > ] >In link protection, only one subtree can be detached due the link failure. So ] >the solution is to use an explicit repair path to connect the downstream ] >node to ] >the upstream via a different route. The same explicit path can also be ] >used for ] >unicast/LDP traffic protection, so in most of the cases no additional expli cit ] >tunnels are needed. ] > ] >In node protection, several subtrees can be detached due to node failure. S o ] >multiple repair paths have to be established to connect each of the subtree ] >roots to the upstream nodes. The upstream must replicate the packets and se nd ] >onto each repair paths. In most cases, the subtree roots will be next-nexth ops ] >for unicast routing. ] > ] >Regarding the RPF, packets arriving from the repair path has to be accepted . ] >They may arrive on wrong interface and fail the RPF check. ] > ] >So here are the requirements in summary: ] > ] >a) repair paths have to terminate at the nexthops or next-nexthops (subtree ] >roots) ] >b) rerouted traffic must be encapsulated. (repair paths must be tunnels). ] >c) rerouted traffic must be accepted (pass the RPF check) ] > ] >The TE tunnel based FRR solution satisfies all these requirements, and in m ost ] >cases no (or very few) additional tunels need to be maintained compares to ] >unicast FRR. ] > ] >The current U-turn solution can not satisfy the first two requirements. ] >The last ] >one is beyond the point if the first two issues can not be solved. ] > ] >The tunnel based FRR solution satisfies the first requirement, but will nee d ] >double encapsulation (two GRE headers probably) for repair traffic when ] >comes to ] >the second, since they used one encapsulation already. ] > ] >Thanks, ] > ] >Albert ] > ] > ] >Alia Atlas wrote: ] > > ] > > Albert, ] > > ] > > The loop-free alternates are a unicast only strategy. One can extend th em ] > > in multiple directions. One such direction is to look for a multicast ] > > solution. It would be interesting to consider what modifications to the ] > > RPF check might be possible for just loop-free. ] > > ] > > I believe that node protection is also quite interesting. ] > > ] > > Alia ] > > ] > > At 02:52 PM 10/1/2004, Albert Tian wrote: ] > > >Hi, ] > > > ] > > >Another downside of U-turn seems to be that it is a unicast only strate gy, ] > > >which ] > > >(correct me if I'm wrong) has no easy way to cover multicast traffic. ] > > > ] > > >If we would like to go one step further from basic loopfree, it would v ery ] > > >desirable to have a mechanism that covers both unicast and multicast, ] > > >perferably ] > > >LDP as well. ] > > > ] > > >For link protection, if we use explicit repair paths that terminate on ] > > >nexthops, ] > > >all types of traffic are covered: unicast, multicast, LDP traffic. No ] > > >extension ] > > >is needed for PIM or LDP (except some minor ones to fix the RPF). Using ] > > >explicit ] > > >repair paths, node protection for all these traffic types is also ] > achievable ] > > >with more extensions. ] > > > ] > > >Thanks, ] > > > ] > > >Albert ] > > > ] > > >Stewart Bryant wrote: ] > > > > ] > > > > Alia Atlas wrote: ] > > > > ] > > > > ] > > > > ] > > > > > ] > > > > > The benefit of U-Turn alternates is that it doesn't require MPLS o r ] > > > > > any tunneling mechanism; without the tunneling, the full mesh for LDP ] > > > > > (if that is of interest) is not necessary. ] > > > > ] > > > > But the downside of U-turn is that it is a short range repair mechan ism ] > > > > that can only direct over at most two hops and hence requires a ] > > > > downstream path within one hop of the repairer. ] > > > > ] > > > > - Stewart ] ] ] ] _______________________________________________ ] Rtgwg mailing list ] Rtgwg@ietf.org ] https://www1.ietf.org/mailman/listinfo/rtgwg - Naiming _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Wed Oct 6 21:22: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 VAA07477 for ; Wed, 6 Oct 2004 21:22:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFN8W-0001va-KS for rtgwg-web-archive@ietf.org; Wed, 06 Oct 2004 21:32:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFMu3-0007az-U1; Wed, 06 Oct 2004 21:17:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFMn1-0005zK-Ce for rtgwg@megatron.ietf.org; Wed, 06 Oct 2004 21:09:53 -0400 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 VAA06393 for ; Wed, 6 Oct 2004 21:09:49 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFMwc-0001BA-Tq for rtgwg@ietf.org; Wed, 06 Oct 2004 21:19:47 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFMmv-0005AN-BU; Thu, 07 Oct 2004 01:09:45 +0000 Date: Wed, 6 Oct 2004 18:09:43 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <153510862.20041006180943@psg.com> To: Stewart Bryant In-Reply-To: <1E7140413C19AD4E827D63B820A24D2B01E20F49@zrtphxm2> References: <1E7140413C19AD4E827D63B820A24D2B01E20F49@zrtphxm2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: Don Fedyk , Alia Atlas , curtis@faster-light.net, rtgwg@ietf.org, mike shand Subject: Re: Reconvergence micro-loops: problem and solutions overview 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: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Stewart, any comments? -- Alex http://www.psg.com/~zinin Friday, October 1, 2004, 10:53:04 AM, Don Fedyk wrote: > Hi Alex > I agree with your comment. I believe we need to let Stewart and Mike answer > where the requirement came from because it comes from their draft and > presentation to the WG. > By the way, I think the full description is 100% coverage during router > convergence after single link failures. The fraction of time a network is > converging versus stable is usually small. The fraction of single link > failures compared to other type of failures tends to be higher. It might be > worth capturing all of these statistics to get a perspective. > Regards, > Don >> -----Original Message----- >> From: Alex Zinin [mailto:zinin@psg.com] >> Sent: Friday, October 01, 2004 12:42 PM >> >> Alia, folks >> >> Wednesday, September 29, 2004, 9:21:51 PM, Alia Atlas wrote: ... >> > The claim that only the tunnel egress needs to understand this >> > mechanism appears to conflict with the argument being made >> that 100% >> > coverage without any network change is utterly critical and >> worth any >> > complexity. >> >> I'd like to understand where this "100% without any network >> change" requirement is coming from. While I understand the >> desire to maximize coverage, I also have learned a while ago >> that trying to get that 100 or solve every corner case often >> comes at the price of greater complexity. I'm sure service >> providers knows even better than I do, so I'm wondering what >> the reasons behind this requirement are. >> >> Alex >> >> >> _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Oct 7 04:49: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 EAA24189 for ; Thu, 7 Oct 2004 04:49:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFU7P-00048G-Hs for rtgwg-web-archive@ietf.org; Thu, 07 Oct 2004 04:59:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFTrt-0001ar-Mo; Thu, 07 Oct 2004 04:43:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFTf5-0006xR-98 for rtgwg@megatron.ietf.org; Thu, 07 Oct 2004 04:30:07 -0400 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 EAA23072 for ; Thu, 7 Oct 2004 04:30:04 -0400 (EDT) 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 1CFToh-00030E-EK for rtgwg@ietf.org; Thu, 07 Oct 2004 04:40:06 -0400 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 i978SbmF015300; Thu, 7 Oct 2004 10:28:38 +0200 (MET DST) From: Olivier Bonaventure To: Don Fedyk In-Reply-To: <1E7140413C19AD4E827D63B820A24D2B01E20F49@zrtphxm2> References: <1E7140413C19AD4E827D63B820A24D2B01E20F49@zrtphxm2> Content-Type: text/plain Message-Id: <1097137718.5049.398.camel@pcobo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 07 Oct 2004 10:28:38 +0200 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: Alex Zinin , rtgwg@ietf.org, Alia Atlas , curtis@faster-light.net, Stewart Bryant , mike shand Subject: RE: Reconvergence micro-loops: problem and solutions overview 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: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Don, > > I agree with your comment. I believe we need to let Stewart and Mike answer > where the requirement came from because it comes from their draft and > presentation to the WG. > > By the way, I think the full description is 100% coverage during router > convergence after single link failures. The fraction of time a network is > converging versus stable is usually small. The fraction of single link > failures compared to other type of failures tends to be higher. It might be > worth capturing all of these statistics to get a perspective. There are a few papers about the analysis of link failures in ISP networks, see e.g. : Athina Markopoulou and Gianluca Iannaccone and Supratik Bhattacharyya and Chen-Nee Chuah and Christophe Diot (2004). Characterization of Failures in an IP Backbone. In: To appear in IEEE Infocom. Hong Kong. March 2004. http://ipmon.sprint.com/pubs_trs/webpages/ATLPUB.php D. Watson, C. Labovitz, and F. Jahanian, "Experiences with monitoring OSPF on a regional service provider network," in Proc. International Conference on Distributed Computing Systems, pp. 204--213, May 2003. http://citeseer.ist.psu.edu/667063.html In the Sprint paper, the authors note that 70% of the unplanned failures are link failures while 30% are shared failures. Half of those shared failures affect links connected to a single router and the other half links connected to the same optical infrastructure. Of course, those results are network dependent and not all networks are designed like Sprint. Olivier -- 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 Fri Oct 8 17:47:41 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 RAA20821 for ; Fri, 8 Oct 2004 17:47:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG2kV-0005mf-Au for rtgwg-web-archive@ietf.org; Fri, 08 Oct 2004 17:58:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG2Y8-0007dG-IB; Fri, 08 Oct 2004 17:45:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG2Q2-0004D2-1X for rtgwg@megatron.ietf.org; Fri, 08 Oct 2004 17:36:54 -0400 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 RAA19751 for ; Fri, 8 Oct 2004 17:36:51 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG2a1-0005Vd-6r for rtgwg@ietf.org; Fri, 08 Oct 2004 17:47:13 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CG2Q0-000Kfj-7z for rtgwg@ietf.org; Fri, 08 Oct 2004 21:36:52 +0000 Date: Fri, 8 Oct 2004 14:36:51 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1435294225.20041008143651@psg.com> To: rtgwg@ietf.org In-Reply-To: <200410081937.PAA28408@ietf.org> References: <200410081937.PAA28408@ietf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------D69E1BA1CA6EBF8" X-Spam-Score: 0.8 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Subject: Fwd: I-D ACTION:draft-zinin-microloop-analysis-00.txt 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: 6640e3bbe8a4d70c4469bcdcbbf0921d ------------D69E1BA1CA6EBF8 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Folks- This draft is a result of a discussion we had among a few folks (Alia, Don, Mike, Stewart, et al). My goal with this document was to try and analyze formation of microloops, plus identify the scenarios where they will not form, and categorize scenarios where they normally will. The next goal was to see if we can do something in the scenarios where microloops normally form. I didn't try to get 100% coverage though (it's likely to require tunnels). Hopefully this should help the discussion on the list. -- Alex http://www.psg.com/~zinin This is a forwarded message From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: Date: Friday, October 8, 2004, 12:37:39 PM Subject: I-D ACTION:draft-zinin-microloop-analysis-00.txt ===8<==============Original message text=============== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis and Minimization of Microloops in Link-state Routing Protocols Author(s) : A. Zinin Filename : draft-zinin-microloop-analysis-00.txt Pages : 10 Date : 2004-10-8 Link-state routing protocols (e.g. OSPF or IS-IS) are known to converge to a loop-free state within a finite period of time after a failure. It is normal, however, to observe short-term loops during the period of failure propagation, route recalculation, and forwarding table update, due to the asynchronous nature of link-state protocol operation. This document provides an analysis of formation of such microloops and suggests simple mechanisms to minimize them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zinin-microloop-analysis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zinin-microloop-analysis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zinin-microloop-analysis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ===8<===========End of original message text=========== ------------D69E1BA1CA6EBF8 Content-Type: MESSAGE/EXTERNAL-BODY; name="1.msg" Content-Disposition: attachment; filename="1.msg" Content-Transfer-Encoding: 8bit Content-Type: text/plain Content-ID: <2004-10-8160046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zinin-microloop-analysis-00.txt ------------D69E1BA1CA6EBF8 Content-Type: MESSAGE/EXTERNAL-BODY; name="draft-zinin-microloop-analysis-00.txt" Content-Disposition: attachment; filename="draft-zinin-microloop-analysis-00.txt" Content-Transfer-Encoding: 8bit Content-Type: text/plain Content-ID: <2004-10-8160046.I-D@ietf.org> ------------D69E1BA1CA6EBF8 Content-Type: TEXT/PLAIN; name="Part.txt" Content-Disposition: attachment; filename="Part.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------------D69E1BA1CA6EBF8 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg ------------D69E1BA1CA6EBF8-- From rtgwg-bounces@ietf.org Tue Oct 12 17:56: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 RAA19337 for ; Tue, 12 Oct 2004 17:56:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHUo0-0004mj-9d for rtgwg-web-archive@ietf.org; Tue, 12 Oct 2004 18:07:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHUNt-0004bv-Nr; Tue, 12 Oct 2004 17:40:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHTvn-0007vi-Td; Tue, 12 Oct 2004 17:11:39 -0400 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 RAA11040; Tue, 12 Oct 2004 17:11:38 -0400 (EDT) Received: from sa.infonet.com ([192.157.130.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHU6M-0002NG-KI; Tue, 12 Oct 2004 17:22:50 -0400 Received: from zhangr2.sa.infonet.com (sfjl161.us.info.net [204.79.139.161] (may be forged)) by sa.infonet.com with ESMTP id i9CLBKOA023203; Tue, 12 Oct 2004 21:11:20 GMT Message-Id: <6.0.3.0.2.20041012135124.03d399c8@sa.infonet.com> X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 12 Oct 2004 14:10:02 -0700 To: Adrian Farrel , , From: raymond zhang In-Reply-To: <045b01c490e4$ccd8f3d0$b6849ed9@Puppy> References: <045b01c490e4$ccd8f3d0$b6849ed9@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ccamp@ops.ietf.org, mpls@ietf.org, pce@ietf.org Subject: Re: [mpls] Mailing List for Path Computation Element (PCE) 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: 32b73d73e8047ed17386f9799119ce43 Hi Adrian, JP, Jerry, I've gone through the I-D "draft-ash-pce-architecture-00.txt" and I think this document has very well stated the architectural objectives and need for a separate WG for this area. Also please find some minor comments below: - section 3. Definitions " Path Computation Element (PCE) is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. The PCE entity can be located within an application" (RZ: I'd suggest some rewording here: The PCE entity is an application process that can be located on a network node or component, on an out-of- network server, etc.) - Page 4, first paragraph: 1) Path computation is applicable in both intra-domain, inter-domain, and inter-layer contexts. Inter-domain path computation may involve the correlation of topology and routing information between domains. Overlapping domains are not within the scope of this document. In the inter-domain case, the domains may belong to a single or multiple (RZ:"inter-layer contexts" is mentioned at the beginning of this paragraph so it would be good to explain this a bit as did for inter-domain) - Page 4. 3) "Centralized computation model" ... There would (RZ: add "be")... - Page 6, 2nd paragraph: (RZ: From SP's perspective, it is not a difficult thing to migrate a legacy IGP plane, e.g. ISIS with narrow metrics to a new ISIS plane supporting TE ext. So I dont seem to see a strong case for this...) - Page 6, section 4.4. (RZ: there maybe some inconsistence here to say on one hand this scenario does not relay on loose hops, yet on the other hand PCE based solution provides loose hops in the computed paths ?) - Page 7, section 5.1. 5.1. Composite PCE "Figure 1 below shows the components of a typical composite PCE node (that is, a router that also implements the PCE functionality) that utilizes path computation. The routing protocol is used to exchange TE information from which the TED is constructed. Service requests are received by the node and converted into signaling requests" (RZ:it would be good to clarify between service requests to the PCE or inter- PCE requests and service requests to signal a TE-LSP request) ... - Page 12, first paragraph (RZ: It would be probably more appropriate to rename to this section to "Service Request/Response Synchronization" vs. "TED Sync" in a subsequent section. It may be more productive here in describing service request/reponse sync of PCC-PCE and PCE-PCE as part of the architectural discussion, rather than illustrating more detailed procedures since these procedures could be discussed in a detailed spec document in which it may transform to something different.) - page 13, 2nd paragrah: "No assumption is made at this stage about whether the PCC-PCE and PCE-PCE communication protocols are identical." (RZ: but I think it would be architectrually more scalable if they are same, so are such comments are warranted here (same protocols for both PCC-PCE/PCE-PCE...) in an arch doc ? - Section 6.8: (RZ: since this is an arch doc, does it imply that implementation of either scheme would meet the arch framework established here ?) - A general comment: there are a lot of very good, analytical discussions in the document presenting different cases. It would be good I think if the authors could provide some guidance in drawing up some architecture recommendations after comparing/analyzing some of these cases or simply say all cases presented in some of these sections are considered valid architectural options ? Regards, Raymond _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Oct 12 18:43:32 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 SAA24397 for ; Tue, 12 Oct 2004 18:43:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHVXa-0005iI-7f for rtgwg-web-archive@ietf.org; Tue, 12 Oct 2004 18:54:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHVLX-0002nc-L4; Tue, 12 Oct 2004 18:42:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHVF0-0000tg-CF for rtgwg@megatron.ietf.org; Tue, 12 Oct 2004 18:35:34 -0400 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 SAA23923 for ; Tue, 12 Oct 2004 18:35:30 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHVPo-0005Z3-7u for rtgwg@ietf.org; Tue, 12 Oct 2004 18:46:44 -0400 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 i9CMYsAt002747 for ; Tue, 12 Oct 2004 18:34:54 -0400 Message-Id: <5.1.0.14.2.20041012140810.023184d0@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Oct 2004 18:34:57 -0400 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: 36c793b20164cfe75332aa66ddb21196 Subject: Fwd: I-D ACTION:draft-ietf-rtgwg-ipfrr-spec-base-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: 1676547e4f33b5e63227e9c02bd359e3 I've submitted an updated version of the loop-free alternates draft. The major changes are as follows: 1) Section on local hold-down which is a SHOULD 2) Discussion of downstream paths & loop-free alternates, with looping scenario shown for link-protecting alternates in the event of node failure. 3) Clarified the behavior for broadcast links 4) Cleaned up the text a lot and more clearly specified the behavior. Please send any comments to the list. Thanks, Alia >To: i-d-announce@ietf.org >From: Internet-Drafts@ietf.org >Date: Mon, 04 Oct 2004 15:46:18 -0400 >Cc: rtgwg@ietf.org >Subject: I-D ACTION:draft-ietf-rtgwg-ipfrr-spec-base-01.txt >X-BeenThere: i-d-announce@ietf.org >X-Mailman-Version: 2.1.5 >Reply-To: internet-drafts@ietf.org >List-Id: i-d-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: i-d-announce-bounces@ietf.org >X-Avici-MailScanner: Found to be clean, Found to be clean >X-Avici-MailScanner-SpamCheck: not spam, SpamAssassin (score=-98.685, > required 5, AV_BSPAMST2 2.00, AWL 2.05, BAYES_00 -4.90, > MIME_BOUND_NEXTPART 0.90, NO_REAL_NAME 1.19, TW_GW 0.08, > USER_IN_WHITELIST -100.00) >X-MailScanner-From: i-d-announce-bounces@ietf.org >X-Avici-MailScanner-Information: Please contact the ISP for more information > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Routing Area Working Group Working Group >of the IETF. > > Title : Basic Specification for IP Fast-Reroute: > Loop-free Alternates > Author(s) : A. Atlas > Filename : draft-ietf-rtgwg-ipfrr-spec-base-01.txt > Pages : 18 > Date : 2004-10-4 > >This document defines an architecture and selection process for > providing local protection for IP unicast and/or LDP traffic in the > event of a single link or node failure until the router has > converged. When computing the primary next-hop for a prefix, a > router S also determines an alternate next-hop which can be used if > the primary next-hop fails. The alternate next-hop is said to be a > loop-free alternate, which goes to a neighbor whose shortest path to > the prefix does not go back through the router S. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-ipfrr-spec-base-01.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the >message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-rtgwg-ipfrr-spec-base-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-rtgwg-ipfrr-spec-base-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-10-4152713.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-rtgwg-ipfrr-spec-base-01.txt > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Wed Oct 13 05:44: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 FAA06963 for ; Wed, 13 Oct 2004 05:44:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHfrF-0000U4-6k for rtgwg-web-archive@ietf.org; Wed, 13 Oct 2004 05:55:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHfdK-0007iH-El; Wed, 13 Oct 2004 05:41:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHfVq-0005Y4-4Z for rtgwg@megatron.ietf.org; Wed, 13 Oct 2004 05:33:38 -0400 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 FAA06084 for ; Wed, 13 Oct 2004 05:33:33 -0400 (EDT) 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 1CHfgh-0000HG-3S for rtgwg@ietf.org; Wed, 13 Oct 2004 05:44:51 -0400 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 i9D9XK8x016145; Wed, 13 Oct 2004 11:33:21 +0200 (MET DST) From: Olivier Bonaventure To: Alex Zinin In-Reply-To: <1435294225.20041008143651@psg.com> References: <200410081937.PAA28408@ietf.org> <1435294225.20041008143651@psg.com> Content-Type: text/plain Message-Id: <1097588577.1283.39.camel@pcobo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 13 Oct 2004 11:33:08 +0200 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: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: rtgwg@ietf.org Subject: Re: {Blocked Content} Fwd: I-D ACTION:draft-zinin-microloop-analysis-00.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: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Alex, > > This draft is a result of a discussion we had among a few folks (Alia, Don, > Mike, Stewart, et al). > > My goal with this document was to try and analyze formation of microloops, > plus identify the scenarios where they will not form, and categorize scenarios > where they normally will. I have several comments on your new draft. 1. Introduction Microloops can also occur between non-directly connected routers in the case of asymetrical link weights. Although most links use the same IGP weights in ISPs, in some cases asymetrical weights are used, sometimes due to configuration errors, but sometimes for valid operational reasons. 2.2 The cost of checking the safety condition inside a router appears to compute the SPT for each of its neighbors after each IGP change. Am I right ? 3.2 Transition types For the types B transitions, it is unclear to me how often such types occur in real networks. I would be interested by quantitative information on the amount of Type B cases in ISPs. I guess this be placed in section 2.6 I think that it would be useful to provide one example of types B1 and types B2 transitions in the draft. 3.3 Basic loop prevention mechanisms For a change that affects a Type B route, the cost appears to be two updates of the FIB, a transient one and the finale one. My main concern/question over the draft are the delays mentionned in this section. First, the starting time of the timers is unclear. Is it the time when the ISIS/OSPF packet indicating the event is received or something else ? Second, most routers do not recompute their SPT immediately when a link state packet indicating a change is received. Instead, they wait for the expiration of a timer whose interval may be fixed or depend on the previous runs of the SPF computation. The interactions between this timer and the two timers that you propose should probably be discuss Third, you implicitly assume that the fault-propagation-time (which includes the time to compute the SPT and check the safety condition) is below 2 seconds. There have been few studies on the time required to propagate a link state packet inside ISP networks, but this time may be high in some environments. The two publically available studies related to this topic are : @Unpublished{Villfor_Operator:2004, author = {H. Villfor}, title = {Operator Experience from ISIS Convergence Tuning}, note = {Presented at RIPE47}, month = {January}, year = 2004 } http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-routing-igp.pdf @Unpublished{Alaettinoglu:ISIS:2001, author = {C. Alaettinoglu and S. Casner}, title = {ISIS Routing on the Qwest Backbone: a Recipe for Subsecond ISIS Convergence}, note = {NANOG23, http://www.nanog.org/mtg-0202/cengiz.html }, month = {October}, year = 2001 } 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 Wed Oct 13 11:39: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 LAA09062 for ; Wed, 13 Oct 2004 11:39:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHlPK-0007er-Bp for rtgwg-web-archive@ietf.org; Wed, 13 Oct 2004 11:51:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHlAi-0005aq-GA; Wed, 13 Oct 2004 11:36:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHl6k-0004aa-4E for rtgwg@megatron.ietf.org; Wed, 13 Oct 2004 11:32:06 -0400 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 LAA08445 for ; Wed, 13 Oct 2004 11:32:05 -0400 (EDT) Received: from relay.pair.com ([209.68.1.20]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHlHh-0007WI-KY for rtgwg@ietf.org; Wed, 13 Oct 2004 11:43:27 -0400 Received: (qmail 22564 invoked from network); 13 Oct 2004 15:29:47 -0000 Received: from 69.37.59.189.adsl.snet.net (HELO laptoy770.faster-light.net) (69.37.59.189) by relay.pair.com with SMTP; 13 Oct 2004 15:29:47 -0000 X-pair-Authenticated: 69.37.59.189 Received: from laptoy770.faster-light.net (localhost [127.0.0.1]) by laptoy770.faster-light.net (8.12.9p2/8.12.9) with ESMTP id i9DFWsI9022298; Wed, 13 Oct 2004 11:32:55 -0400 (EDT) (envelope-from curtis@laptoy770.faster-light.net) Message-Id: <200410131532.i9DFWsI9022298@laptoy770.faster-light.net> To: Olivier Bonaventure In-reply-to: Your message of "13 Oct 2004 11:33:08 +0200." <1097588577.1283.39.camel@pcobo> Date: Wed, 13 Oct 2004 11:32:54 -0400 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Alex Zinin , rtgwg@ietf.org Subject: Re: {Blocked Content} Fwd: I-D ACTION:draft-zinin-microloop-analysis-00.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: 0fa76816851382eb71b0a882ccdc29ac In message <1097588577.1283.39.camel@pcobo> Olivier Bonaventure writes: > > Alex, > > > > This draft is a result of a discussion we had among a few folks (Alia, Don, > > Mike, Stewart, et al). > > > > My goal with this document was to try and analyze formation of microloops, > > plus identify the scenarios where they will not form, and categorize scenarios > > where they normally will. > > I have several comments on your new draft. > > 1. Introduction > > Microloops can also occur between non-directly connected routers in the > case of asymetrical link weights. Although most links use the same IGP > weights in ISPs, in some cases asymetrical weights are used, sometimes > due to configuration errors, but sometimes for valid operational > reasons. Transient loops can also occur where the IGP has symmetric costs if multiple IGP changes occur. You need both an up and a down transition and a few routeres to react to it in a different order. It could be an up on one link very close to a down on another or a very fast down/up transition on one link (which should never occur) or a very quick up/down (which sometimes can't be helped). Flapping links caused by either intermittent failure or degredation that is close to a threshhold of link acceptance can do it. With logical links going throught the same physical equipment (TDM, WDM) this can occur on multiple links simultaneously. This was more of a problem when some routers converged very slowly a decade ago compared to today. Asymetric costs just make it possible for the loop to form as a result of a single transition. Otherwise a minimum of two closely spaced transitions is required. Microloops probably still occur, but are brief enough to be very hard to observe, certainly impossible looking only at the packet counters on a link. You can only see it if you have a way to record queue utilization (particularly capture peak utilization or queue overflow) since loops today may only last a few RTT of the loop. Queue overflow on low utilization links occurs if the RTT of the loop is small compared to the RTT of the traffic crossing it and/or the loop persists for more than a few RTT, so sometime you know it has happenned just by the non-zero SNMP counters on links with very low utilization that happen to form a cycle. A decade ago when routers ran their SPF every couple of seconds (or more) this "curriosity" was often observed but not considered a problem since a rare few seconds of loss was considered acceptable. For example, in the early days of the T3-NSFNET (early 1990s) link costs were symetric, link utilizations were low (20-30% at most), and evidence of loops were observed. These things are fairly rare but if you are trying to get IGP restoration times that are comparable to path RTTs with some form of local protection and have built in consequences for exceeding it (like SLA violation refunds for example), then they might be a real problem. Of course, with assymetric costs, an isolated failure can cause a loop so loops will be more common. This is what Alex is trying to address in draft-zinin-microloop-analysis. I don't think any mechanism on top of a link state protocol short of end to end tunneling such as RSVP/TE would completely solve the problem of intermittent failing links. Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Wed Oct 13 16:06: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 QAA01326 for ; Wed, 13 Oct 2004 16:06:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHpZd-000593-6f for rtgwg-web-archive@ietf.org; Wed, 13 Oct 2004 16:18:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHpFp-0000Ax-No; Wed, 13 Oct 2004 15:57:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHp7m-000417-RB for rtgwg@megatron.ietf.org; Wed, 13 Oct 2004 15:49:27 -0400 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 PAA29171 for ; Wed, 13 Oct 2004 15:49:27 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHpIn-0004Za-Mj for rtgwg@ietf.org; Wed, 13 Oct 2004 16:00:50 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHp7l-000Ez2-1A; Wed, 13 Oct 2004 19:49:25 +0000 Date: Wed, 13 Oct 2004 12:49:23 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5942751.20041013124923@psg.com> To: Olivier Bonaventure In-Reply-To: <1097588577.1283.39.camel@pcobo> References: <200410081937.PAA28408@ietf.org> <1435294225.20041008143651@psg.com> <1097588577.1283.39.camel@pcobo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: rtgwg@ietf.org Subject: Re: {Blocked Content} Fwd: I-D ACTION:draft-zinin-microloop-analysis-00.txt 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: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Olivier, Thanks for reviewing the document, see my answers inline below: > I have several comments on your new draft. > 1. Introduction > Microloops can also occur between non-directly connected routers in the > case of asymetrical link weights. Although most links use the same IGP > weights in ISPs, in some cases asymetrical weights are used, sometimes > due to configuration errors, but sometimes for valid operational > reasons. I purposely avoided looking at the asymmetric link cost case as a rather rare situation. I do have it on my to-do list for my next flight, which will be next week :) > 2.2 > The cost of checking the safety condition inside a router appears to > compute the SPT for each of its neighbors after each IGP change. Am I > right ? With reasonable optimizations, if the router already implements basic IP FRR, the cost should be not be very high. Here's some considerations: - if the node implements IP FRR, the LFA BF condition should be precomputed and known a priori - checking the safety condition for type-As costs almost nothing, since after the regular SPT you know new primaries - checking the no-LFA-BF part of type-Cs also has low overhead - for the remaining cases (checking the DS AF part of the safety condition) it is necessary to calculate SPT only for neighbors that were LFA BF for some destinations that need to be checked for type-B/C. If the implementation is more advanced and does incremental SPF, it may as well decide to compute SPTs for each of its neighbors. > 3.2 Transition types > For the types B transitions, it is unclear to me how often such types > occur in real networks. I would be interested by quantitative > information on the amount of Type B cases in ISPs. I guess this be > placed in section 2.6 Alia modified its tool to do coverage analysis by this method. We're working on normalizing the data and making sense of it ;) I hope we'll have some interesting data by DC. > I think that it would be useful to provide one example of types B1 and > types B2 transitions in the draft. I'll note this for the next rev. > 3.3 Basic loop prevention mechanisms > For a change that affects a Type B route, the cost appears to be two > updates of the FIB, a transient one and the finale one. That is correct. The first one reroutes traffic to safe hops, and the second installs the final next-hops. > My main concern/question over the draft are the delays mentionned in > this section. First, the starting time of the timers is unclear. Is it > the time when the ISIS/OSPF packet indicating the event is received or > something else ? your start the timer once you know you're type-B or type-C for that destination. > Second, most routers do not recompute their SPT immediately when a link > state packet indicating a change is received. Instead, they wait for the > expiration of a timer whose interval may be fixed or depend on the > previous runs of the SPF computation. The interactions between this > timer and the two timers that you propose should probably be discuss Yes, this is probably worth noting. The sub-second IGP convergence effort drove some implementations towards the behavior where they react quickly to a small "stand-alone" set of topology changes, and then start to increase the delay to ensure robustness if the network topology becomes unstable. This is consistent with the FRR and microloops prevention. > Third, you implicitly assume that the fault-propagation-time (which > includes the time to compute the SPT and check the safety condition) is > below 2 seconds. There have been few studies on the time required to > propagate a link state packet inside ISP networks, but this time may be > high in some environments. The two publically available studies related > to this topic are : Difference in topologies, link delays, and implementations is exactly why those delays were made configurable variables. On the other hand, I will note that for a given failure, only a subset of nodes will be actually affected (will change their next-hops), and it will be even smaller subset where the delays will actually matter. In other words, excluding pathological cases (e.g. networks made of big rings), we're interested in clusters of nodes, not the whole network, so practically, 2 secs is likely to be enough, and I would even expect it to go lower as more implementations support subsecond convergence. Yet again, it's configurable... Alex _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Wed Oct 13 18:15:51 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 SAA19191 for ; Wed, 13 Oct 2004 18:15:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHraL-0001f0-Gv for rtgwg-web-archive@ietf.org; Wed, 13 Oct 2004 18:27:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHrGa-0002EK-93; Wed, 13 Oct 2004 18:06:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHqj3-0005Fv-Q2 for rtgwg@megatron.ietf.org; Wed, 13 Oct 2004 17:32:01 -0400 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 RAA13328 for ; Wed, 13 Oct 2004 17:32:01 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHqu1-0008OG-QL for rtgwg@ietf.org; Wed, 13 Oct 2004 17:43:25 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2004 23:44:37 +0200 X-BrightmailFiltered: true 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 i9DLVNSf008325; Wed, 13 Oct 2004 23:31:23 +0200 (MEST) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4244.cisco.com [10.61.80.147]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA06117; Wed, 13 Oct 2004 22:31:22 +0100 (BST) Message-Id: <4.3.2.7.2.20041013222927.03497790@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Oct 2004 22:31:22 +0100 To: Alex Zinin From: mike shand In-Reply-To: <5942751.20041013124923@psg.com> References: <1097588577.1283.39.camel@pcobo> <200410081937.PAA28408@ietf.org> <1435294225.20041008143651@psg.com> <1097588577.1283.39.camel@pcobo> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: rtgwg@ietf.org Subject: Re: {Blocked Content} Fwd: I-D ACTION:draft-zinin-microloop-analysis-00.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: 79899194edc4f33a41f49410777972f8 At 12:49 13/10/2004 -0700, Alex Zinin wrote: > > For a change that affects a Type B route, the cost appears to be two > > updates of the FIB, a transient one and the finale one. > >That is correct. The first one reroutes traffic to safe hops, and the >second installs the final next-hops. As we discussed, the document should say that for ECMP where not all of the splits meet the "type A" criterion, you need to treat it as "type B". i.e. have an interim FIB update to the safe path(s) and delay as for type B. Mike _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Oct 14 12:31: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 MAA05102 for ; Thu, 14 Oct 2004 12:31:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI8gq-00068F-TF for rtgwg-web-archive@ietf.org; Thu, 14 Oct 2004 12:42:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI8QX-0007eZ-N2; Thu, 14 Oct 2004 12:26:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI8A3-0001EL-Ek for rtgwg@megatron.ietf.org; Thu, 14 Oct 2004 12:09:03 -0400 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 MAA03496 for ; Thu, 14 Oct 2004 12:09:00 -0400 (EDT) Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI8LF-0005eR-1R for rtgwg@ietf.org; Thu, 14 Oct 2004 12:20:37 -0400 Received: from sehan001fe.han.telia.se ([131.115.18.154]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.80); Thu, 14 Oct 2004 18:08:58 +0200 Received: from YBDH014427.teliasonera.com ([131.116.231.83]) by sehan001fe.han.telia.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 14 Oct 2004 18:08:56 +0200 Message-Id: <6.0.1.1.0.20041014180535.036a51d8@tmspop.telia.se> X-Sender: ther45@tmspop.telia.se X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 14 Oct 2004 18:08:57 +0200 To: Olivier Bonaventure From: Thomas Eriksson In-Reply-To: <1097588577.1283.39.camel@pcobo> References: <200410081937.PAA28408@ietf.org> <1435294225.20041008143651@psg.c om> <1097588577.1283.39.camel@pcobo> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Oct 2004 16:08:57.0041 (UTC) FILETIME=[1BE0B410:01C4B208] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: rtgwg@ietf.org Subject: Re: {Blocked Content} Fwd: I-DACTION:draft-zinin-microloop-analysis-00.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 Just a short comment on one of the references below. >The two publically available studies related >to this topic are : >@Unpublished{Villfor_Operator:2004, > author = {H. Villfor}, > title = {Operator Experience from ISIS Convergence Tuning}, > note = {Presented at RIPE47}, > month = {January}, > year = 2004 >} >http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-routing-igp.pdf This link is to the presentation by Clerance Filsfis. The actual document referenced can be found at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-routing-isis.pdf Thomas >@Unpublished{Alaettinoglu:ISIS:2001, > author = {C. Alaettinoglu and S. Casner}, > title = {ISIS Routing on the Qwest Backbone: a Recipe for Subsecond >ISIS Convergence}, > note = {NANOG23, http://www.nanog.org/mtg-0202/cengiz.html }, > month = {October}, > year = 2001 >} > >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 _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Oct 14 12:55: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 MAA06867 for ; Thu, 14 Oct 2004 12:55:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI941-0006dW-QF for rtgwg-web-archive@ietf.org; Thu, 14 Oct 2004 13:06:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI8g6-00033j-6q; Thu, 14 Oct 2004 12:42:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI8Zm-0001aM-FW for rtgwg@megatron.ietf.org; Thu, 14 Oct 2004 12:35:40 -0400 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 MAA05447 for ; Thu, 14 Oct 2004 12:35:33 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI8ks-0006CT-TF for rtgwg@ietf.org; Thu, 14 Oct 2004 12:47:11 -0400 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 i9EGYgAt006850; Thu, 14 Oct 2004 12:34:42 -0400 Message-Id: <5.1.0.14.2.20041014105420.0249cb68@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Oct 2004 12:34:51 -0400 To: curtis@faster-light.net From: Alia Atlas In-Reply-To: <200410131532.i9DFWsI9022298@laptoy770.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-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Alex Zinin , rtgwg@ietf.org Subject: Re: {Blocked Content} Fwd: I-D ACTION:draft-zinin-microloop-analysis-00.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: 798b2e660f1819ae38035ac1d8d5e3ab Curtis, At 11:32 AM 10/13/2004, Curtis Villamizar wrote: >I don't think any mechanism on top of a link state protocol short of >end to end tunneling such as RSVP/TE would completely solve the >problem of intermittent failing links. I'm a bit puzzled by this. Certainly, with TE, how adaptive a tunnel is to topology changes can dampen the effects. That is just because the CSPF won't be run for a while and thus won't use the link. Presumably, a similar effect could be gained by dampening the reporting of the link into the IGP. For instance, the exponential back-off based on how recently the link has flapped. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 15 12:04: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 MAA16129 for ; Fri, 15 Oct 2004 12:04:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIUkI-00034J-OA for rtgwg-web-archive@ietf.org; Fri, 15 Oct 2004 12:16:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUSw-0002u7-7J; Fri, 15 Oct 2004 11:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUO5-0001xh-1p for rtgwg@megatron.ietf.org; Fri, 15 Oct 2004 11:53:01 -0400 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 LAA15388 for ; Fri, 15 Oct 2004 11:52:57 -0400 (EDT) Received: from relay.pair.com ([209.68.1.20]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CIUZS-0002nc-Og for rtgwg@ietf.org; Fri, 15 Oct 2004 12:04:47 -0400 Received: (qmail 6542 invoked from network); 15 Oct 2004 15:52:48 -0000 Received: from 69.37.59.189.adsl.snet.net (HELO laptoy770.faster-light.net) (69.37.59.189) by relay.pair.com with SMTP; 15 Oct 2004 15:52:48 -0000 X-pair-Authenticated: 69.37.59.189 Received: from laptoy770.faster-light.net (localhost [127.0.0.1]) by laptoy770.faster-light.net (8.12.9p2/8.12.9) with ESMTP id i9FFuF04092982; Fri, 15 Oct 2004 11:56:19 -0400 (EDT) (envelope-from curtis@laptoy770.faster-light.net) Message-Id: <200410151556.i9FFuF04092982@laptoy770.faster-light.net> To: Alia Atlas In-reply-to: Your message of "Thu, 14 Oct 2004 12:34:51 EDT." <5.1.0.14.2.20041014105420.0249cb68@pop.avici.com> Date: Fri, 15 Oct 2004 11:56:15 -0400 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Alex Zinin , curtis@faster-light.net, rtgwg@ietf.org Subject: Re: {Blocked Content} Fwd: I-D ACTION:draft-zinin-microloop-analysis-00.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: 31247fb3be228bb596db9127becad0bc In message <5.1.0.14.2.20041014105420.0249cb68@pop.avici.com> Alia Atlas writes: > > Curtis, > > At 11:32 AM 10/13/2004, Curtis Villamizar wrote: > >I don't think any mechanism on top of a link state protocol short of > >end to end tunneling such as RSVP/TE would completely solve the > >problem of intermittent failing links. > > I'm a bit puzzled by this. Certainly, with TE, how adaptive a tunnel is to > topology changes can dampen the effects. That is just because the CSPF > won't be run for a while and thus won't use the link. There are two separate timers. One is referred to as the resilience timer and is used to reroute when the existing path fails (with FRR handling the traffic until the reroute occurs). The other is adaptivity timer and is used when new resources become available. The resilience timer is very short. The adaptivity timer is very long (in practice it can be tens of minutes to a few hours). If a failure occurs, the TE FRR backup is supposed to go into use within 50 msec. If a very large number of tunnels must reroute, the new primary tunnels may all be available within seconds, after which the old is taken down and the FRR backup goes down with it. If the link flaps the long adaptivity timer alone results in the link being avoided but past history can be used in the decsion to move a tunnel from a stable path to one of lower cost to further insure a flapping link is not used. > Presumably, a similar effect could be gained by dampening the reporting of > the link into the IGP. For instance, the exponential back-off based on how > recently the link has flapped. > > Alia If you are running a link state IGP you probably don't want to keep the link down for 10 minutes to a few hours. If you have massively overprovisioned, then maybe you do want to hold a link down for a very long time period after it seems to be usable. With TE you can (and should) apply a brief holddown, but then advertise the link as back up and let each ingress decide when/if to use it. Our implementation (the "adaptivity linear" method which allows two peicewise linear relationships to be configured) allow the percentage of link utilization to be used in the decision as to when to schedule an initial CSPF and then uses the percentage link utilization gained to make the decison as to whether to actually reroute now or schedule the reroute farther in the future. This way if the primary path for one ingress/egress is too heavily loaded it will move back to a better path quickly but if for another ingress/egress there is not much to be gained by moving to another path, the reroute will be deferred for a very long time (we suggest up to hours, but it could be indefinite) in the interest of not moving around traffic often (avoiding the brief delay discontinuity and reordering of a reroute, though it is lossless) in addition to avoiding any use of a flapping path except where there is no sufficiently uncongested alternate. Other TE implementations are free to take similar approaches with TE but this sort of more intelligent use of the available resources is not possible if IGP forwarding is used. This just goes back to the question of whether TE is useful, and if someone feels that it is not, then how about when a link is persistently down or when a link is flapping. I vaguely recall the anecdote that "Too much optimizing of transient behevior might lead to blindness". I think that Yakov deserved credit for that (but its not worth searching 10 year old email archives to find out for sure). Completely avoiding microloops in a link state IGP may be unacheivable. The draft Alex came up with is simple enough and does afford some improvement so it doesn't seem to meet the criteria for "too much optimizing of transient behevior" and Alex is probably safe. Anyone trying to completely eliminate microloops in a link state IGP probably isn't. Curtis _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 15 12:38:08 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 MAA18208 for ; Fri, 15 Oct 2004 12:38:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIVHB-0003kr-3f for rtgwg-web-archive@ietf.org; Fri, 15 Oct 2004 12:49:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUr2-0001II-52; Fri, 15 Oct 2004 12:22:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUnq-0000Qs-Ks for rtgwg@megatron.ietf.org; Fri, 15 Oct 2004 12:19:38 -0400 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 MAA17128 for ; Fri, 15 Oct 2004 12:19:35 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIUzD-0003Mu-Nn for rtgwg@ietf.org; Fri, 15 Oct 2004 12:31:25 -0400 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 i9FGIYAt023232; Fri, 15 Oct 2004 12:18:34 -0400 Message-Id: <5.1.0.14.2.20041015121510.024e2c90@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Oct 2004 12:18:40 -0400 To: curtis@faster-light.net From: Alia Atlas In-Reply-To: <200410151556.i9FFuF04092982@laptoy770.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-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Alex Zinin , curtis@faster-light.net, rtgwg@ietf.org Subject: Re: {Blocked Content} Fwd: I-D ACTION:draft-zinin-microloop-analysis-00.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 At 11:56 AM 10/15/2004, Curtis Villamizar wrote: >If a failure occurs, the TE FRR backup is supposed to go into use >within 50 msec. If a very large number of tunnels must reroute, the >new primary tunnels may all be available within seconds, after which >the old is taken down and the FRR backup goes down with it. If the >link flaps the long adaptivity timer alone results in the link being >avoided but past history can be used in the decsion to move a tunnel >from a stable path to one of lower cost to further insure a flapping >link is not used. Certainly using the past history allows other routers to decide not to use the flapping link. If all of the IP traffic is expected to be carried inside these TE tunnels, then doesn't this suffer from the same problem of not wanting to keep a link down for 10 minutes to a few hours? I.e., the link may be up, but not carrying substantial real traffic, because the TE tunnels avoid it. >I vaguely recall the anecdote that "Too much optimizing of transient >behevior might lead to blindness". I think that Yakov deserved credit >for that (but its not worth searching 10 year old email archives to >find out for sure). Completely avoiding microloops in a link state >IGP may be unacheivable. The draft Alex came up with is simple enough >and does afford some improvement so it doesn't seem to meet the >criteria for "too much optimizing of transient behevior" and Alex is >probably safe. Anyone trying to completely eliminate microloops in a >link state IGP probably isn't. Certainly the longer that the network hasn't converged after a failure, the more vulnerable the network is to a second failure. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 15 14:09:51 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 OAA25534 for ; Fri, 15 Oct 2004 14:09:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIWhh-0005oB-Rq for rtgwg-web-archive@ietf.org; Fri, 15 Oct 2004 14:21:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIWOr-0002wo-CI; Fri, 15 Oct 2004 14:01:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIWGv-0001MO-Vr for rtgwg@megatron.ietf.org; Fri, 15 Oct 2004 13:53:46 -0400 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 NAA24397 for ; Fri, 15 Oct 2004 13:53:42 -0400 (EDT) Received: from relay.pair.com ([209.68.1.20]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CIWSG-0005SD-Ni for rtgwg@ietf.org; Fri, 15 Oct 2004 14:05:29 -0400 Received: (qmail 11667 invoked from network); 15 Oct 2004 17:52:47 -0000 Received: from 69.37.59.189.adsl.snet.net (HELO laptoy770.faster-light.net) (69.37.59.189) by relay.pair.com with SMTP; 15 Oct 2004 17:52:47 -0000 X-pair-Authenticated: 69.37.59.189 Received: from laptoy770.faster-light.net (localhost [127.0.0.1]) by laptoy770.faster-light.net (8.12.9p2/8.12.9) with ESMTP id i9FHuM04096926; Fri, 15 Oct 2004 13:56:22 -0400 (EDT) (envelope-from curtis@laptoy770.faster-light.net) Message-Id: <200410151756.i9FHuM04096926@laptoy770.faster-light.net> To: Alia Atlas In-reply-to: Your message of "Fri, 15 Oct 2004 12:18:40 EDT." <5.1.0.14.2.20041015121510.024e2c90@pop.avici.com> Date: Fri, 15 Oct 2004 13:56:22 -0400 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Alex Zinin , curtis@faster-light.net, rtgwg@ietf.org Subject: Re: {Blocked Content} Fwd: I-D ACTION:draft-zinin-microloop-analysis-00.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: 52f7a77164458f8c7b36b66787c853da In message <5.1.0.14.2.20041015121510.024e2c90@pop.avici.com> Alia Atlas writes: > > At 11:56 AM 10/15/2004, Curtis Villamizar wrote: > >If a failure occurs, the TE FRR backup is supposed to go into use > >within 50 msec. If a very large number of tunnels must reroute, the > >new primary tunnels may all be available within seconds, after which > >the old is taken down and the FRR backup goes down with it. If the > >link flaps the long adaptivity timer alone results in the link being > >avoided but past history can be used in the decsion to move a tunnel > >from a stable path to one of lower cost to further insure a flapping > >link is not used. > > Certainly using the past history allows other routers to decide not to use > the flapping link. If all of the IP traffic is expected to be carried > inside these TE tunnels, then doesn't this suffer from the same problem of > not wanting to keep a link down for 10 minutes to a few hours? I.e., the > link may be up, but not carrying substantial real traffic, because the TE > tunnels avoid it. Each ingress decides separately and each decides on a per path basis whether there is a better path. If you need to use a link that has recently gone down, at least you will be making minimal use of it. > >I vaguely recall the anecdote that "Too much optimizing of transient > >behevior might lead to blindness". I think that Yakov deserved credit > >for that (but its not worth searching 10 year old email archives to > >find out for sure). Completely avoiding microloops in a link state > >IGP may be unacheivable. The draft Alex came up with is simple enough > >and does afford some improvement so it doesn't seem to meet the > >criteria for "too much optimizing of transient behevior" and Alex is > >probably safe. Anyone trying to completely eliminate microloops in a > >link state IGP probably isn't. > > Certainly the longer that the network hasn't converged after a failure, the > more vulnerable the network is to a second failure. > > Alia The ability to support SRLGs helps, but even with SRLG, the real world is full of examples of correlated failures for which you couldn't reasonably expect SRLG to be configured. Off the top of my head, these range from an Amtrak train taking out the fiber on both sides of the track in 192 in a major fiber run in NJ, to floods in the midwest in 1993 submerging entire POPs, to hurricanes in NC taking out fiber, to the Raritan bridge collapsing and breaking fiber, to an earthquake in San Diego taking out three of four fiber paths, most if not all of these affecting every major provider since many the same right of ways. There have been plenty of examples, way too many to list. No SLA promising extremely low outages based on expectation of fast restoration covering every possible scenario will ever go unbroken for very long. Also TCP's end-to-end congestion avoidance will still come in handy for the rare but inevitable extensive outages. Curtis ps - my last message wasn't intended to go out to the list, but no serious harm done. We are a bit off topic though. _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 15 14:25: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 OAA26816 for ; Fri, 15 Oct 2004 14:25:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIWx9-0006CN-2T for rtgwg-web-archive@ietf.org; Fri, 15 Oct 2004 14:37:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIWjg-0008Bc-29; Fri, 15 Oct 2004 14:23:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIWeS-00075t-Q0 for rtgwg@megatron.ietf.org; Fri, 15 Oct 2004 14:18:04 -0400 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 OAA26203 for ; Fri, 15 Oct 2004 14:18:03 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIWpr-00061A-Oy for rtgwg@ietf.org; Fri, 15 Oct 2004 14:29:53 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9FIHSA02184; Fri, 15 Oct 2004 14:17:29 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id <49CZ910B>; Fri, 15 Oct 2004 14:17:27 -0400 Message-ID: <1E7140413C19AD4E827D63B820A24D2B02329F65@zrtphxm2> From: "Don Fedyk" To: Alex Zinin , rtgwg@ietf.org Date: Fri, 15 Oct 2004 14:17:15 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: RE: I-D ACTION:draft-zinin-microloop-analysis-00.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 Hi Alex In the draft: >Type C: > Installation of the new route is delayed by time DELAY_TYPEC. > Until then, the router continues to use its old next-hops. >DELAY_TYPEB and DELAY_TYPEC are two configurable constants. They >should be configured with the same value on all routers in the net- >work and such that following equation is true: > >DELAY_TYPEB > DELAY_TYPEC > fault-propagation-time > >where fault-propagation-time is the time it is expected to take >routers in the network to propagate new link-state information, cal- >culate the new SPT, check the safety condition of the neighbors, and >install required FIB entries. > >Suggested default values for DELAY_TYPEB and DELAY_TYPEC are 4 and 2 >seconds correspondingly. - I'm O.K. with DELAY_TYPEB timers at this length. - But I think DELAY_TYPEC > time for an immediate neighbor to install an alternate. This value is probably not very long (in the order of 100msec). In my understanding Delay_TYPEC starts ticking very close to the time that updates are being sent from C to B (In the Figure 1 the immediate neighbor). Once B has its alternates in place, C can forward to B with no issues. So I suggest: DELAY_TYPEB > fault-propagation-time DELAY_TYPEC > time for an immediate neighbor to install an alternate. I suppose one could then ask: Could I live with no timer on C? Regards, Don _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 15 20:22:51 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 UAA08592 for ; Fri, 15 Oct 2004 20:22:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcWx-0001UD-Gv for rtgwg-web-archive@ietf.org; Fri, 15 Oct 2004 20:34:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcAH-0004tl-Co; Fri, 15 Oct 2004 20:11:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIc6I-0003zH-6q for rtgwg@megatron.ietf.org; Fri, 15 Oct 2004 20:07:10 -0400 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 UAA07713 for ; Fri, 15 Oct 2004 20:07:06 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcHk-0001DU-Bt for rtgwg@ietf.org; Fri, 15 Oct 2004 20:19:01 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CIc6E-000BuQ-JO; Sat, 16 Oct 2004 00:07:06 +0000 Date: Fri, 15 Oct 2004 17:07:05 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1263296317.20041015170705@psg.com> To: mike shand In-Reply-To: <4.3.2.7.2.20041013222927.03497790@jaws.cisco.com> References: <1097588577.1283.39.camel@pcobo> <200410081937.PAA28408@ietf.org> <1435294225.20041008143651@psg.com> <1097588577.1283.39.camel@pcobo> <4.3.2.7.2.20041013222927.03497790@jaws.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: rtgwg@ietf.org Subject: Re: {Blocked Content} Fwd: I-D ACTION:draft-zinin-microloop-analysis-00.txt 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit >>That is correct. The first one reroutes traffic to safe hops, and the >>second installs the final next-hops. > As we discussed, the document should say that for ECMP where not all of the > splits meet the "type A" criterion, you need to treat it as "type B". i.e. > have an interim FIB update to the safe path(s) and delay as for type B. Right. Here's an excerpt from our discussion: > For ECMP, we have the following possibilities: > > 1) All NPs are safe > 2) Some NPs are safe, some not > 3) All NPs are not safe, but they are B1's (one safe-hop makes > all unsafe NPs B1's) > 4) All NPs are C's > > Cases 1, 3, and 4 are simple. > For case 2, I would install safe NPs and schedule SPF for a later time > to give the rest of NPs a chance to get installed. Alex _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 15 20:49:21 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 UAA10724 for ; Fri, 15 Oct 2004 20:49:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcwc-000260-SS for rtgwg-web-archive@ietf.org; Fri, 15 Oct 2004 21:01:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIciK-00068I-Ue; Fri, 15 Oct 2004 20:46:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcgi-0005f2-85 for rtgwg@megatron.ietf.org; Fri, 15 Oct 2004 20:44:48 -0400 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 UAA10368 for ; Fri, 15 Oct 2004 20:44:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcsA-0001z9-Ne for rtgwg@ietf.org; Fri, 15 Oct 2004 20:56:40 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CIcgg-000F8c-4o; Sat, 16 Oct 2004 00:44:46 +0000 Date: Fri, 15 Oct 2004 17:44:45 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <212885698.20041015174445@psg.com> To: "Don Fedyk" In-Reply-To: <1E7140413C19AD4E827D63B820A24D2B02329F65@zrtphxm2> References: <1E7140413C19AD4E827D63B820A24D2B02329F65@zrtphxm2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: rtgwg@ietf.org Subject: Re: I-D ACTION:draft-zinin-microloop-analysis-00.txt 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: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Friday, October 15, 2004, 11:17:15 AM, Don Fedyk wrote: > - I'm O.K. with DELAY_TYPEB timers at this length. > - But I think DELAY_TYPEC > time for an immediate neighbor to install an > alternate. > This value is probably not very long (in the order of 100msec). In my > understanding Delay_TYPEC starts ticking very close to the time that updates > are being sent from C to B (In the Figure 1 the immediate neighbor). Once > B has its alternates in place, C can forward to B with no issues. > So I suggest: > DELAY_TYPEB > fault-propagation-time > DELAY_TYPEC > time for an immediate neighbor to install an alternate. Don, as I mentioned in one of my previous messages, actual delays mentioned in the document are not mandatory and are configurable, so it is perfectly fine to take them down if implementations in the network calculate routes fast enough. Regarding your suggested equations above, here's what the draft says about fault-propagation-time: > where fault-propagation-time is the time it is expected to take > routers in the network to propagate new link-state information, cal- > culate the new SPT, check the safety condition of the neighbors, and > install required FIB entries. As I mentioned in my reply to Olivier, this is not network-wide propagation time, but only the time for propagation within a certain proximity where there is dependency between type-Bs and type-Cs. Keeping this in mind, fault-propagation-time is already what you're looking for. I chose 2 seconds only to be on the safe side to make sure that people who follow the spec word to word can deploy their implementations and it will work with default settings. > I suppose one could then ask: Could I live with no timer on C? Not really. We would then not remove the uncertainty about FIB update time compared to a type-B and would still get microloops if C's new primary is type-B and used to route to us. Alex _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Oct 19 21:47: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 VAA14180 for ; Tue, 19 Oct 2004 21:47:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK5m8-0002jl-HT for rtgwg-web-archive@ietf.org; Tue, 19 Oct 2004 22:00:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK3wy-0004lx-4w; Tue, 19 Oct 2004 20:03:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJtnQ-0001kC-8l for rtgwg@megatron.ietf.org; Tue, 19 Oct 2004 09:13:00 -0400 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 JAA22026 for ; Tue, 19 Oct 2004 09:12:53 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJtzX-0004fy-2M for rtgwg@ietf.org; Tue, 19 Oct 2004 09:25:32 -0400 Received: from aatlas-lt.avici.com ([10.2.103.188]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i9JDC8ni008718 for ; Tue, 19 Oct 2004 09:12:08 -0400 Message-Id: <5.1.0.14.2.20041019090635.0241ce38@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Oct 2004 09:12:16 -0400 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: 7bac9cb154eb5790ae3b2913587a40de Subject: MIB for IP FRR (draft-atlas-rtgwg-ipfrr-ip-mib-00.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: 08170828343bcf1325e4a0fb4584481c We've submitted a draft for MIB for IP Fast Reroute (http://www1.ietf.org/internet-drafts/draft-atlas-rtgwg-ipfrr-ip-mib-00.txt). This is covering the MIB for determining the alternates and any unprotected routes. Please take a look and send any comments to the list. Thanks, Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Wed Oct 20 04:29: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 EAA10202 for ; Wed, 20 Oct 2004 04:29:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKC2r-0002c8-EB for rtgwg-web-archive@ietf.org; Wed, 20 Oct 2004 04:42:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKAA9-00044u-BJ; Wed, 20 Oct 2004 02:41:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK8n6-0005KV-CH for rtgwg@megatron.ietf.org; Wed, 20 Oct 2004 01:13:40 -0400 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 BAA29575 for ; Wed, 20 Oct 2004 01:13:34 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK8zL-0007Kw-Oi for rtgwg@ietf.org; Wed, 20 Oct 2004 01:26:21 -0400 Received: from aatlas-lt.avici.com ([10.2.103.12]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i9K5Cmni005392 for ; Wed, 20 Oct 2004 01:12:51 -0400 Message-Id: <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Oct 2004 01:12:53 -0400 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: 4d87d2aa806f79fed918a62e834505ca Subject: ordered SPFs 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 Hi Mike & Stewart, I was taking another look at the Ordered SPF idea and what you've written in draft-bryant-shand-lf-conv-frmwk-00.txt and have a few comments/questions. First, I'd picked up the idea (looking through emails I'm not sure where :) that you'd calculate a reverse spanning tree from each router connected to the failure and wait based on the minimum hops. It sounds like you are actually calculating from the failed component itself. For a point-to-point link failure, I don't think it matters, but for a node or broadcast link failure, it definitely does. I think that you may need the same thing when computing for a new link coming up. More details, particularly on the ECMP cases would be useful. There's also a bit more complexity to the reverse spanning tree in terms of what paths are inherited in the ECMP case. If you just break ties based on IP address or keep the first shortest path that's found, you could end up with rather bad results. Also, you'd need to keep track of the highest hop-count on a shortest path to know how long to wait. I do see why the delay isn't computed based on destination; all the affected traffic took the same shortest paths to the failed component (or will take the same shortest paths to the added component). Where I think this method may have a problem is with SRLGs. For what I've been calling local SRLGs (all members connected to the same router), there wouldn't be an issue, b/c you could pretend that the node had failed from the perspective of rooting your reverse spanning tree. For more general SRLGs, there would be a problem. At a minimum, one would need to do destination-based delay and determine which destinations were reached via which failed element(s). One would also have to decide how to handle destinations which were reached via equal-cost paths, where each equal-cost path went via a different failed element. One would need to couple the separate reverse spanning trees at the point where the ECMP existed and bump up the hop-count equivalently (or something similar). Have you thought about the implications of SRLGs? I realize that we have not been discussing SRLGs substantially in the context of IP FRR. I think this is just b/c of wanting to get the basics down first, before starting to embellish with all the details. It is, of course, completely possible to consider SRLGs. This can just be an additional factor in the acceptance criteria of a loop-free alternate; the same thing works for U-turn alternates. The concern would be the additional computation such tracking would require. Another issue, of course, is how much engineering current networks would require to have protection if important SRLGs were considered. What do you think? Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Wed Oct 20 09:35: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 JAA02594 for ; Wed, 20 Oct 2004 09:35:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKGpI-0000g7-Aq for rtgwg-web-archive@ietf.org; Wed, 20 Oct 2004 09:48:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKG2C-0003Ts-OG; Wed, 20 Oct 2004 08:57:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKFFA-0001Z8-6n for rtgwg@megatron.ietf.org; Wed, 20 Oct 2004 08:07:04 -0400 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 IAA26007 for ; Wed, 20 Oct 2004 08:06:57 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKFRU-0007IO-19 for rtgwg@ietf.org; Wed, 20 Oct 2004 08:19:48 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2004 14:21:41 +0200 X-BrightmailFiltered: true 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 i9KC6LSf018415; Wed, 20 Oct 2004 14:06:22 +0200 (MEST) Received: from mshand-w2k02.cisco.com (dhcp-rea-gp250-64-103-64-218.cisco.com [64.103.64.218]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA20501; Wed, 20 Oct 2004 13:06:21 +0100 (BST) Message-Id: <4.3.2.7.2.20041020130338.036020b8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Oct 2004 13:05:58 +0100 To: alia Atlas From: mike shand Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: rtgwg@ietf.org Subject: Re: ordered SPFs 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: 5011df3e2a27abcc044eaa15befcaa87 At 01:12 20/10/2004 -0400, Alia Atlas wrote: >Hi Mike & Stewart, > >I was taking another look at the Ordered SPF idea and what you've written >in draft-bryant-shand-lf-conv-frmwk-00.txt and have a few comments/questions. > >First, I'd picked up the idea (looking through emails I'm not sure where >:) that you'd calculate a reverse spanning tree from each router connected >to the failure and wait based on the minimum hops. It sounds like you >are actually calculating from the failed component itself. For a >point-to-point link failure, I don't think it matters, but for a node or >broadcast link failure, it definitely does. I think that you may need the >same thing when computing for a new link coming up. More details, >particularly on the ECMP cases would be useful. Yes. In each case you compute the reverse SPF rooted at the far end of the failed link as indicated in the LSP you are considering. A node failure does not appear as a single event, but causes multiple LSPs to be sent (1 for each link failure). Each of these is considered as for a link failure. It can be shown that in the special case of an "SRLG" which is a node failure, there can be no conflict in the required ordering of SPFs. >There's also a bit more complexity to the reverse spanning tree in terms >of what paths are inherited in the ECMP case. If you just break ties >based on IP address or keep the first shortest path that's found, you >could end up with rather bad results. Also, you'd need to keep track of >the highest hop-count on a shortest path to know how long to wait. Yes, exactly. You need the highest hop count of any ECMP paths. This is because the SPT isn't a simple tree in the case of ECMP. Note that there is a general problem with (I think) all the methods we are talking about for loop prevention and repair, where you have routers which are imposing different ECMP limits. Any calculation should be made assuming the "worst" case which is the largest number of path splits. >I do see why the delay isn't computed based on destination; all the >affected traffic took the same shortest paths to the failed component (or >will take the same shortest paths to the added component). > >Where I think this method may have a problem is with SRLGs. For what I've >been calling local SRLGs (all members connected to the same router), there >wouldn't be an issue, b/c you could pretend that the node had failed from >the perspective of rooting your reverse spanning tree. For more general >SRLGs, there would be a problem. At a minimum, one would need to do >destination-based delay and determine which destinations were reached via >which failed element(s). One would also have to decide how to handle >destinations which were reached via equal-cost paths, where each >equal-cost path went via a different failed element. One would need to >couple the separate reverse spanning trees at the point where the ECMP >existed and bump up the hop-count equivalently (or something >similar). Have you thought about the implications of SRLGs? Yes. Clearly it is possible for unrelated SRLG (as opposed to the special case of node failure), to introduce conflicting ordering requirements on the whole FIB. As you say this would introduce a lot of extra complexity, and require per destination (or at least per destination set) ordering of the FIB. >I realize that we have not been discussing SRLGs substantially in the >context of IP FRR. I think this is just b/c of wanting to get the basics >down first, before starting to embellish with all the details. It is, of >course, completely possible to consider SRLGs. This can just be an >additional factor in the acceptance criteria of a loop-free alternate; the >same thing works for U-turn alternates. The concern would be the >additional computation such tracking would require. Absolutely. The other problem with SRLG as far as repair is concerned is that you cannot be sure about your SRLGs. On the one hand you may have a failure of a single link which is part of an SRLG, and hence you may invoke a more complex repair strategy that actually required (or worse, decide that the failure was irreparable, when in fact the single link failure could have been repaired). On the other hand, you may get multiple link failures occurring as a result of a real world SRLG of which you were previously aware. >Another issue, of course, is how much engineering current networks would >require to have protection if important SRLGs were considered. Indeed. >What do you think? > >Alia > > >_______________________________________________ >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 Wed Oct 20 10:37: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 KAA10110 for ; Wed, 20 Oct 2004 10:37:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKHmk-00020O-NE for rtgwg-web-archive@ietf.org; Wed, 20 Oct 2004 10:49:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKGlr-00073C-7Y; Wed, 20 Oct 2004 09:44:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKGDu-000575-Ff for rtgwg@megatron.ietf.org; Wed, 20 Oct 2004 09:09:50 -0400 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 JAA00878 for ; Wed, 20 Oct 2004 09:09:43 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKGQD-0000AT-Ns for rtgwg@ietf.org; Wed, 20 Oct 2004 09:22:35 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2004 15:24:27 +0200 X-BrightmailFiltered: true 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 i9KD99Sf002555 for ; Wed, 20 Oct 2004 15:09:10 +0200 (MEST) Received: from mshand-w2k02.cisco.com (dhcp-rea-gp250-64-103-64-218.cisco.com [64.103.64.218]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA23017 for ; Wed, 20 Oct 2004 14:09:09 +0100 (BST) Message-Id: <4.3.2.7.2.20041020132249.0291ba20@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Oct 2004 14:09:02 +0100 To: rtgwg@ietf.org From: mike shand Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: Proposed Terminology section for IPFRR framework document 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: c83ccb5cc10e751496398f1233ca9c3a Here is the proposed terminology section to be included in the framework document. Alia and I have had some discussion about this, and come up with the following. Note that we have changed from P to E for the primary next hop partly because there was some confusion with Provider routers and partly because we were both using "P" for different things. The equitable thing seemed be for neither of us to use P. Alia's latest version of the basic draft uses this terminology, and we will be re-spinning our draft to use this terminology where appropriate. If anyone has any comments please let me have them by the end of the week. Mike TERMINOLOGY This section defines words and acronyms used in this draft. S Used to denote a router that is the source of a repair that is computed in anticipation of the failure of a neighboring router denoted as E, or of the link between S and E. It is the viewpoint from which IP Fast-Reroute is described. D Used to denote the destination router under discussion. E Used to denote the router which is the primary next-hop neighbor to get from S to the destination D. Where there is an ECMP set for the shortest path from S to D, these are referred to as E_1, E_2, etc. N_i The ith neighbor of S. R_i_j The jth neighbor of N_i. Distance_opt(A,B) The distance of the shortest path from A to B. Link(A->B) A link connecting router A to router B. Loop-Free This is a neighbor N, that is not a primary Alternate next-hop neighbor E, whose shortest path to the destination D does not go back through the router S. The neighbor N must meet the following condition:- Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D) Downstream Path This is a subset of the loop-free alternates where the neighbor N meet the following condition:- Distance_opt(N, D) < Distance_opt(S,D) Upstream This is a forwarding loop which involves a set Forwarding Loop of routers, none of which are directly connected to the link which has caused the topology change that triggered a new SPF in any of the routers. Primary Neighbor One or more of the primary next-hops for S to reach the destination D goes directly to this neighbor. Loop-Free A Neighbor N_i which is not the primary Neighbor neighbor and whose shortest path to D does not go through S. Loop-Free This is a path via a Loop-Free Neighbor N_i Link-Protecting which does not go through the particular link Alternate of S which is being protected to reach the destination D. Loop-Free This is a path via a Loop-Free Neighbor N_i Node-Protecting which does not go through the particular Alternate primary neighbor of S which is being protected to reach the destination D. FIB Forwarding Information Base. The database used by the packet forwarder to determine what actions to perform on a packet. IPFRR IP fast re-route Routing The process whereby routers converge on a new transition topology. In conventional networks this process frequently causes some disruption to packet delivery. Micro-loop A temporary forwarding loop which exists during a routing transition as a result of temporary inconsistencies between FIBs. RPF Reverse Path Forwarding. I.e. checking that a packet is received over the interface which would be used to send packets addressed to the source address of the packet. SPF Shortest Path First, e.g. Dijkstra's algorithm. SPT Shortest path tree _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Wed Oct 20 21:05: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 VAA00421 for ; Wed, 20 Oct 2004 21:05:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKRbJ-00077H-1d for rtgwg-web-archive@ietf.org; Wed, 20 Oct 2004 21:18:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKILW-00057e-Nh; Wed, 20 Oct 2004 11:25:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHjQ-0001Nm-LB for rtgwg@megatron.ietf.org; Wed, 20 Oct 2004 10:46:28 -0400 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 KAA11188 for ; Wed, 20 Oct 2004 10:46:21 -0400 (EDT) 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 1CKHvj-0002Dm-3H for rtgwg@ietf.org; Wed, 20 Oct 2004 10:59:14 -0400 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 i9KEg4pR011892; Wed, 20 Oct 2004 16:42:05 +0200 (MET DST) From: Olivier Bonaventure To: Alia Atlas In-Reply-To: <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> References: <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1098283324.15751.132.camel@pcobo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 20 Oct 2004 16:42:04 +0200 X-INGI-MailScanner-Information: Please contact the ISP for more information X-INGI-MailScanner: Found to be clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by info.ucl.ac.be id i9KEg4pR011892 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: Pierre Francois , rtgwg@ietf.org Subject: Re: ordered SPFs 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: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Alia, >=20 > I was taking another look at the Ordered SPF idea and what you've writt= en=20 > in draft-bryant-shand-lf-conv-frmwk-00.txt and have a few comments/ques= tions. >=20 > First, I'd picked up the idea (looking through emails I'm not sure wher= e :)=20 > that you'd calculate a reverse spanning tree from each router connected= to=20 > the failure and wait based on the minimum hops. It sounds like you ar= e=20 > actually calculating from the failed component itself. For a=20 > point-to-point link failure, I don't think it matters, but for a node o= r=20 > broadcast link failure, it definitely does. I think that you may need = the=20 > same thing when computing for a new link coming up. More details,=20 > particularly on the ECMP cases would be useful. Pierre Francois and I have worked on the problem of ordering the updates of the FIBs in the routers in an IP network after link and router failures. We have proposed in a paper under submission a formal proof that such an ordering is possible for link up, link down and changes in the IGP weights events. First, the two directions of each link are considered independently for the ordering. This is because a single router cannot use both X->Y and Y->X to send packets. It will have at most one direction of each link in its own SPT. In the case of link down or metric increase events, the ordering of the FIB updates should be along the RSPT centered on the directed link. A router can only update its FIB once all of its children in the RSPT have updated their FIB. draft-bryant-shand-lf-conv-frmwk-00.txt uses this ordering. In the case of link up or metric decrease events, the ordering of the FIB updates is different. A router can only update its FIB once its parents on the RSPT centered on the new directed link have updated their FIB. A similar ordering can be defined for the router failures and similarly for the router up events. For a router down a router should update its FIB only once its children in the RPST centered on the failing router have all updated their FIBs. For a router up event, a router should update its FIB only when its parents in the RSPT centered on the upcoming router have all updated their FIB. A consequence is that the upcoming router must be the first to update its FIB. We have a formal proof for those orderings in our submitted paper but it would be too long for this email. =20 Best regards, Olivier Bonaventure and Pierre Fran=E7ois --=20 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 Thu Oct 21 07:34:21 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 HAA04502 for ; Thu, 21 Oct 2004 07:34:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbPe-0005AJ-0B for rtgwg-web-archive@ietf.org; Thu, 21 Oct 2004 07:47:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUHp-0005ZP-3u; Thu, 21 Oct 2004 00:10:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKJ3s-000592-69 for rtgwg@megatron.ietf.org; Wed, 20 Oct 2004 12:11:40 -0400 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 MAA19000 for ; Wed, 20 Oct 2004 12:11:32 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKJGE-0003yP-FX for rtgwg@ietf.org; Wed, 20 Oct 2004 12:24:26 -0400 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 i9KGAmni021498; Wed, 20 Oct 2004 12:10:52 -0400 Message-Id: <5.1.0.14.2.20041020115915.02546ef0@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Oct 2004 12:10:51 -0400 To: Olivier Bonaventure From: Alia Atlas In-Reply-To: <1098283324.15751.132.camel@pcobo> References: <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable 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: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: Pierre Francois , rtgwg@ietf.org Subject: Re: ordered SPFs 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: quoted-printable Olivier & Mike, I agree that what you are describing works for a node failure if the node=20 is the root for the RSPT. My question/confusion is what is actually done for a node failure. Mike=20 seems to indicate that a separate RSPT is computed for each end connected=20 to each down link. The RSPT must be computed on the topology before any= =20 of the failures occurred. Then I guess that a node takes its furthest=20 hop-count to use as its position. Alia At 10:42 AM 10/20/2004, Olivier Bonaventure wrote: >Alia, > > > > I was taking another look at the Ordered SPF idea and what you've= written > > in draft-bryant-shand-lf-conv-frmwk-00.txt and have a few=20 > comments/questions. > > > > First, I'd picked up the idea (looking through emails I'm not sure=20 > where :) > > that you'd calculate a reverse spanning tree from each router connected= to > > the failure and wait based on the minimum hops. It sounds like you are > > actually calculating from the failed component itself. For a > > point-to-point link failure, I don't think it matters, but for a node or > > broadcast link failure, it definitely does. I think that you may need= the > > same thing when computing for a new link coming up. More details, > > particularly on the ECMP cases would be useful. > >Pierre Francois and I have worked on the problem of ordering the updates >of the FIBs in the routers in an IP network after link and router >failures. We have proposed in a paper under submission a formal proof >that such an ordering is possible for link up, link down and changes in >the IGP weights events. > >First, the two directions of each link are considered independently for >the ordering. This is because a single router cannot use both X->Y and >Y->X to send packets. It will have at most one direction of each link in >its own SPT. > >In the case of link down or metric increase events, the ordering of the >FIB updates should be along the RSPT centered on the directed link. A >router can only update its FIB once all of its children in the RSPT have >updated their FIB. draft-bryant-shand-lf-conv-frmwk-00.txt uses this >ordering. > >In the case of link up or metric decrease events, the ordering of the >FIB updates is different. A router can only update its FIB once its >parents on the RSPT centered on the new directed link have updated their >FIB. > >A similar ordering can be defined for the router failures and similarly >for the router up events. For a router down a router should update its >FIB only once its children in the RPST centered on the failing router >have all updated their FIBs. For a router up event, a router should >update its FIB only when its parents in the RSPT centered on the >upcoming router have all updated their FIB. A consequence is that the >upcoming router must be the first to update its FIB. > >We have a formal proof for those orderings in our submitted paper but it >would be too long for this email. > >Best regards, > > >Olivier Bonaventure and Pierre Fran=E7ois > >-- >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 Thu Oct 21 07:35: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 HAA04854 for ; Thu, 21 Oct 2004 07:35:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbRD-0005EO-RH for rtgwg-web-archive@ietf.org; Thu, 21 Oct 2004 07:49:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUI3-0005eK-7w; Thu, 21 Oct 2004 00:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKJHv-0000JA-KO for rtgwg@megatron.ietf.org; Wed, 20 Oct 2004 12:26:11 -0400 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 MAA20586 for ; Wed, 20 Oct 2004 12:26:08 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKJUJ-0004Ki-DR for rtgwg@ietf.org; Wed, 20 Oct 2004 12:39:03 -0400 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 i9KGPSni024034; Wed, 20 Oct 2004 12:25:28 -0400 Message-Id: <5.1.0.14.2.20041020121435.02559980@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Oct 2004 12:25:31 -0400 To: mike shand From: Alia Atlas In-Reply-To: <4.3.2.7.2.20041020130338.036020b8@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: rtgwg@ietf.org Subject: Re: ordered SPFs 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 Mike, At 08:05 AM 10/20/2004, mike shand wrote: >Yes. In each case you compute the reverse SPF rooted at the far end of the >failed link as indicated in the LSP you are considering. A node failure >does not appear as a single event, but causes multiple LSPs to be sent (1 >for each link failure). Each of these is considered as for a link failure. >It can be shown that in the special case of an "SRLG" which is a node >failure, there can be no conflict in the required ordering of SPFs. How do you combine/determine the node position to use if there are multiple trees? I assume that it must be the furthest away hopCount (for the failure case) and, if a node were to instantly come up with multiple links, then it would be the closest hopCount (for the recovery case). It would also be very good to specify what topology the RSPT is being calculated on. I.e., this requires that one store the old topology, which is a slightly different complication. >Note that there is a general problem with (I think) all the methods we are >talking about for loop prevention and repair, where you have routers which >are imposing different ECMP limits. Any calculation should be made >assuming the "worst" case which is the largest number of path splits. I don't think that one needs to assume the "worst" case; I think you just need correct inheritance rules within the SPF. Certainly, that is what I have for the loop-free and for the U-turn alternates. The problem otherwise isn't just with different ECMP limits, but with different tie-breaking criteria within those. >Yes. Clearly it is possible for unrelated SRLG (as opposed to the special >case of node failure), to introduce conflicting ordering requirements on >the whole FIB. As you say this would introduce a lot of extra complexity, >and require per destination (or at least per destination set) ordering of >the FIB. Do you see this as a problem or as a reasonable trade-off given we have per-destination hold-down for the local repair? Also, how would you combine hopCounts from different trees? Can this work for SRLGs? >>I realize that we have not been discussing SRLGs substantially in the >>context of IP FRR. I think this is just b/c of wanting to get the basics >>down first, before starting to embellish with all the details. It is, of >>course, completely possible to consider SRLGs. This can just be an >>additional factor in the acceptance criteria of a loop-free alternate; >>the same thing works for U-turn alternates. The concern would be the >>additional computation such tracking would require. > >Absolutely. The other problem with SRLG as far as repair is concerned is >that you cannot be sure about your SRLGs. On the one hand you may have a >failure of a single link which is part of an SRLG, and hence you may >invoke a more complex repair strategy that actually required (or worse, >decide that the failure was irreparable, when in fact the single link >failure could have been repaired). On the other hand, you may get multiple >link failures occurring as a result of a real world SRLG of which you were >previously aware. Sure, it's a question of how paranoid does one really want to be. Do you always use an alternate (if available) that will provide SRLG protection? I tend to be in the paranoid in planning (i.e. get the most protective alternate you can) and simplistic in the set of repair strategies. A separate one for link & node is not unreasonable, given BFD to make a very quick determination. Beyond that, I don't see how a router could know about an SRLG-caused failure in the appropriate time frame. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Oct 21 11:13: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 LAA11763 for ; Thu, 21 Oct 2004 11:13:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKepV-0005fL-Qv for rtgwg-web-archive@ietf.org; Thu, 21 Oct 2004 11:26:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeXs-0006Fs-Sv; Thu, 21 Oct 2004 11:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeOE-0002Nb-2R for rtgwg@megatron.ietf.org; Thu, 21 Oct 2004 10:58:07 -0400 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 KAA10177 for ; Thu, 21 Oct 2004 10:58:03 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeao-0005GK-IP for rtgwg@ietf.org; Thu, 21 Oct 2004 11:11:10 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 21 Oct 2004 17:13:06 +0200 X-BrightmailFiltered: true 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 i9LEvSSf018929; Thu, 21 Oct 2004 16:57:28 +0200 (MEST) Received: from mshand-w2k02.cisco.com (dhcp-rea-gp250-64-103-64-218.cisco.com [64.103.64.218]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA12566; Thu, 21 Oct 2004 15:57:27 +0100 (BST) Message-Id: <4.3.2.7.2.20041021154941.02bcf2c8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Oct 2004 15:57:20 +0100 To: Alia Atlas From: mike shand In-Reply-To: <5.1.0.14.2.20041020115915.02546ef0@pop.avici.com> References: <1098283324.15751.132.camel@pcobo> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable Cc: rtgwg@ietf.org, Pierre Francois Subject: Re: ordered SPFs 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: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable At 12:10 20/10/2004 -0400, Alia Atlas wrote: >Olivier & Mike, > >I agree that what you are describing works for a node failure if the node= =20 >is the root for the RSPT. > >My question/confusion is what is actually done for a node failure. Mike=20 >seems to indicate that a separate RSPT is computed for each end connected= =20 >to each down link. The RSPT must be computed on the topology before=20 >any of the failures occurred. Then I guess that a node takes its furthest= =20 >hop-count to use as its position. Yes. If the arrival of a second (or subsequent) LSP causes you to increase= =20 your delay, then you do so, but if it would cause you to decrease it you=20 keep the existing delay. Note that if you have already made a change with=20 no delay, this can only have affected destinations which would not be=20 affected by the subsequent LSP. There is an assumption that all the LSPs concerning the failure arrive=20 within the first delay period. If this is not the case, then even link=20 failure loop protection cannot work. i.e. if some router somewhere doesn't= =20 receive an LSP until after the other routers around it have already waited= =20 their delay, there will be de-synchronization. Mike >Alia > >At 10:42 AM 10/20/2004, Olivier Bonaventure wrote: >>Alia, >> > >> > I was taking another look at the Ordered SPF idea and what you've= written >> > in draft-bryant-shand-lf-conv-frmwk-00.txt and have a few=20 >> comments/questions. >> > >> > First, I'd picked up the idea (looking through emails I'm not sure=20 >> where :) >> > that you'd calculate a reverse spanning tree from each router connected= to >> > the failure and wait based on the minimum hops. It sounds like you= are >> > actually calculating from the failed component itself. For a >> > point-to-point link failure, I don't think it matters, but for a node= or >> > broadcast link failure, it definitely does. I think that you may need= the >> > same thing when computing for a new link coming up. More details, >> > particularly on the ECMP cases would be useful. >> >>Pierre Francois and I have worked on the problem of ordering the updates >>of the FIBs in the routers in an IP network after link and router >>failures. We have proposed in a paper under submission a formal proof >>that such an ordering is possible for link up, link down and changes in >>the IGP weights events. >> >>First, the two directions of each link are considered independently for >>the ordering. This is because a single router cannot use both X->Y and >>Y->X to send packets. It will have at most one direction of each link in >>its own SPT. >> >>In the case of link down or metric increase events, the ordering of the >>FIB updates should be along the RSPT centered on the directed link. A >>router can only update its FIB once all of its children in the RSPT have >>updated their FIB. draft-bryant-shand-lf-conv-frmwk-00.txt uses this >>ordering. >> >>In the case of link up or metric decrease events, the ordering of the >>FIB updates is different. A router can only update its FIB once its >>parents on the RSPT centered on the new directed link have updated their >>FIB. >> >>A similar ordering can be defined for the router failures and similarly >>for the router up events. For a router down a router should update its >>FIB only once its children in the RPST centered on the failing router >>have all updated their FIBs. For a router up event, a router should >>update its FIB only when its parents in the RSPT centered on the >>upcoming router have all updated their FIB. A consequence is that the >>upcoming router must be the first to update its FIB. >> >>We have a formal proof for those orderings in our submitted paper but it >>would be too long for this email. >> >>Best regards, >> >> >>Olivier Bonaventure and Pierre Fran=E7ois >> >>-- >>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 _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Oct 21 11:39:39 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 LAA14262 for ; Thu, 21 Oct 2004 11:39:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKfF7-0006Fh-1y for rtgwg-web-archive@ietf.org; Thu, 21 Oct 2004 11:52:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeuw-0000mG-DA; Thu, 21 Oct 2004 11:31:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKepf-0005fT-RX for rtgwg@megatron.ietf.org; Thu, 21 Oct 2004 11:26:27 -0400 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 LAA12991 for ; Thu, 21 Oct 2004 11:26:25 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKf2I-0005wD-EX for rtgwg@ietf.org; Thu, 21 Oct 2004 11:39:31 -0400 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 i9LFPhni012066; Thu, 21 Oct 2004 11:25:43 -0400 Message-Id: <5.1.0.14.2.20041021111720.025854f8@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Oct 2004 11:25:48 -0400 To: mike shand From: Alia Atlas In-Reply-To: <4.3.2.7.2.20041021154941.02bcf2c8@jaws.cisco.com> References: <5.1.0.14.2.20041020115915.02546ef0@pop.avici.com> <1098283324.15751.132.camel@pcobo> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: rtgwg@ietf.org, Pierre Francois Subject: Re: ordered SPFs 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 Mike, At 10:57 AM 10/21/2004, mike shand wrote: >At 12:10 20/10/2004 -0400, Alia Atlas wrote: >>Olivier & Mike, >> >>I agree that what you are describing works for a node failure if the node >>is the root for the RSPT. >> >>My question/confusion is what is actually done for a node failure. Mike >>seems to indicate that a separate RSPT is computed for each end connected >>to each down link. The RSPT must be computed on the topology before >>any of the failures occurred. Then I guess that a node takes its >>furthest hop-count to use as its position. > >Yes. If the arrival of a second (or subsequent) LSP causes you to increase >your delay, then you do so, but if it would cause you to decrease it you >keep the existing delay. Note that if you have already made a change with >no delay, this can only have affected destinations which would not be >affected by the subsequent LSP. That doesn't make sense to me. The further away (in hopCount) one is, the shorter the delay, right, b/c you are removing the dependency. In the ECMP cases, it seems entirely possible that one will want to decrease the delay. I'm thinking of the case where there's a broadcast link that fails. Otherwise, there's a race condition that depends on when the LSPs are received. Also, why would a change made with no delay have affected only destinations that wouldn't be affected by the subsequent LSP? I'm clearly missing something here. >There is an assumption that all the LSPs concerning the failure arrive >within the first delay period. If this is not the case, then even link >failure loop protection cannot work. i.e. if some router somewhere doesn't >receive an LSP until after the other routers around it have already waited >their delay, there will be de-synchronization. Sure. There's definitely a required information gathering delay. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Oct 21 11:49:07 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 LAA15273 for ; Thu, 21 Oct 2004 11:49:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKfOE-0006TJ-G4 for rtgwg-web-archive@ietf.org; Thu, 21 Oct 2004 12:02:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKf4C-0004b1-Jw; Thu, 21 Oct 2004 11:41:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKewt-0001c1-6d for rtgwg@megatron.ietf.org; Thu, 21 Oct 2004 11:33:55 -0400 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 LAA13773 for ; Thu, 21 Oct 2004 11:33:52 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKf9W-00067S-3o for rtgwg@ietf.org; Thu, 21 Oct 2004 11:46:59 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 21 Oct 2004 17:48:57 +0200 X-BrightmailFiltered: true 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 i9LFXISf028328; Thu, 21 Oct 2004 17:33:19 +0200 (MEST) Received: from mshand-w2k02.cisco.com (dhcp-rea-gp250-64-103-64-218.cisco.com [64.103.64.218]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA14070; Thu, 21 Oct 2004 16:33:18 +0100 (BST) Message-Id: <4.3.2.7.2.20041021163242.02466008@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Oct 2004 16:33:18 +0100 To: Alia Atlas From: mike shand In-Reply-To: <5.1.0.14.2.20041021111720.025854f8@pop.avici.com> References: <4.3.2.7.2.20041021154941.02bcf2c8@jaws.cisco.com> <5.1.0.14.2.20041020115915.02546ef0@pop.avici.com> <1098283324.15751.132.camel@pcobo> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: rtgwg@ietf.org, Pierre Francois Subject: Re: ordered SPFs 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: cf4fa59384e76e63313391b70cd0dd25 At 11:25 21/10/2004 -0400, Alia Atlas wrote: >I'm thinking of the case where there's a broadcast link that >fails. Otherwise, there's a race condition that depends on when the LSPs >are received. Could you give an example? Mike _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Oct 21 13:18: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 NAA24779 for ; Thu, 21 Oct 2004 13:18:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgmv-0000ID-NG for rtgwg-web-archive@ietf.org; Thu, 21 Oct 2004 13:31:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgKf-0001Le-I9; Thu, 21 Oct 2004 13:02:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgFJ-0007VL-Nv for rtgwg@megatron.ietf.org; Thu, 21 Oct 2004 12:57:01 -0400 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 MAA22769 for ; Thu, 21 Oct 2004 12:56:58 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgRq-0008Ao-Oy for rtgwg@ietf.org; Thu, 21 Oct 2004 13:10:06 -0400 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 i9LGu8ni007184; Thu, 21 Oct 2004 12:56:08 -0400 Message-Id: <5.1.0.14.2.20041021124809.02583228@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Oct 2004 12:56:11 -0400 To: mike shand From: Alia Atlas In-Reply-To: <4.3.2.7.2.20041021163242.02466008@jaws.cisco.com> References: <5.1.0.14.2.20041021111720.025854f8@pop.avici.com> <4.3.2.7.2.20041021154941.02bcf2c8@jaws.cisco.com> <5.1.0.14.2.20041020115915.02546ef0@pop.avici.com> <1098283324.15751.132.camel@pcobo> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: rtgwg@ietf.org, Pierre Francois Subject: Re: ordered SPFs 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: 386e0819b1192672467565a524848168 At 11:33 AM 10/21/2004, mike shand wrote: >At 11:25 21/10/2004 -0400, Alia Atlas wrote: >>I'm thinking of the case where there's a broadcast link that >>fails. Otherwise, there's a race condition that depends on when the LSPs >>are received. > >Could you give an example? I'm working on it. Basically, I'm assuming that arbitrary failures of connectivity can happen inside a broadcast link due to layer-2 equipment. Could you give an example where the correct behavior is to increase the delay in the event of a failure? I believe that the correct behavior would be the other way (for a failure case), because of the need to remove dependencies; also, all the nodes upstream of the one whose hopCount was increased would also have increased hopCounts, so reducing the delay is appropriate. The example that I have so far is rather contrived and assumes arbitrary (including 1-way) failure at layer-2. It is as follows: 50 ----[ I ] | | | 10 | | | 3 3 | [ S ]----[ H ]---[ G ] | | | 3 | 12 | [ F ] | | | 3 | | | | [ A ] [ B ] | | 5 | | 5 |----------------| | | | | | 5 | 5 | [ C ] [ E ] | | |----[ D ]----| 10 Consider the above topology where D is the destination for the traffic under consideration. A partial failure occurs on the broadcast link between A, B and C, as could occur due to a layer-2 switch. After the failure, the following connections exist: A to C, A to E, B to A, B to E, C to E, E to A, E to B, E to C Before the failure, S had equal-cost paths to D via A and via H. As a result of this failure, 3 LSPs would be sent out: LSP 1 from A: reports connection to B is down LSP 2 from B: reports connection to C is down LSP 3 from C: reports connections to A and B are down The following are the hopCounts from doing RSPTs on A, B and C based on the topology before the failure. Node | hopCount | hopCount | max from | hopCount | | from A | from B | A & B | from C | ------+-----------+----------+----------+----------+ A | 0 | 1 | 1 | 1 B | 1 | 0 | 1 | 1 C | 1 | 1 | 1 | 0 D | 2 | 2 | 2 | 1 E | 1 | 1 | 1 | 1 F | 2 | 1 | 2 | 2 G | 3 | 2 | 3 | 3 H | 4 | 3 | 4 | 4 S | 1 | 4 | 4 | 5 I | 2 | 5 | 5 | 6 Assume that LSP 1 arrives before LSP 2 or LSP 3. In that case, H and S would use the same delay and thereby cause a micro-loop. Does this match with what you are saying? I realize that the Ordered SPFs works most of the time; I'm trying to understand the corner cases (however improbable) better. Thanks, Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Oct 21 14:29: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 OAA02801 for ; Thu, 21 Oct 2004 14:29:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhsz-0002Uo-VU for rtgwg-web-archive@ietf.org; Thu, 21 Oct 2004 14:42:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhMl-0001ok-2N; Thu, 21 Oct 2004 14:08:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhEJ-0005rC-NN for rtgwg@megatron.ietf.org; Thu, 21 Oct 2004 14:00:03 -0400 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 OAA29538 for ; Thu, 21 Oct 2004 14:00:01 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhQx-0001aX-84 for rtgwg@ietf.org; Thu, 21 Oct 2004 14:13:08 -0400 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 i9LHxKni023206; Thu, 21 Oct 2004 13:59:20 -0400 Message-Id: <5.1.0.14.2.20041021135731.0258eb38@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Oct 2004 13:59:22 -0400 To: mike shand , rtorvi@avici.com From: Alia Atlas In-Reply-To: <4.3.2.7.2.20041021163242.02466008@jaws.cisco.com> References: <5.1.0.14.2.20041021111720.025854f8@pop.avici.com> <4.3.2.7.2.20041021154941.02bcf2c8@jaws.cisco.com> <5.1.0.14.2.20041020115915.02546ef0@pop.avici.com> <1098283324.15751.132.camel@pcobo> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: rtgwg@ietf.org, Pierre Francois Subject: Re: ordered SPFs 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Mike, Here are a couple other questions about ordered SPFs. First, how does this interact/work with OSPF Virtual Links? Second, how does this interact with different areas? Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 22 01:35: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 BAA16018 for ; Fri, 22 Oct 2004 01:35:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKsIR-0006Ms-SA for rtgwg-web-archive@ietf.org; Fri, 22 Oct 2004 01:49:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKs44-0007mX-JW; Fri, 22 Oct 2004 01:34:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKrpi-0003cv-Ed for rtgwg@megatron.ietf.org; Fri, 22 Oct 2004 01:19:22 -0400 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 BAA15133 for ; Fri, 22 Oct 2004 01:19:21 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKs2R-000673-Ks for rtgwg@ietf.org; Fri, 22 Oct 2004 01:32:32 -0400 Received: from aatlas-lt.avici.com ([10.2.103.13]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i9M5IWni021173; Fri, 22 Oct 2004 01:18:33 -0400 Message-Id: <5.1.0.14.2.20041022011635.024a96e0@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Oct 2004 01:18:38 -0400 To: mike shand , rtorvi@avici.com, rtgwg@ietf.org, Pierre Francois From: Alia Atlas In-Reply-To: <5.1.0.14.2.20041021135731.0258eb38@pop.avici.com> References: <4.3.2.7.2.20041021163242.02466008@jaws.cisco.com> <5.1.0.14.2.20041021111720.025854f8@pop.avici.com> <4.3.2.7.2.20041021154941.02bcf2c8@jaws.cisco.com> <5.1.0.14.2.20041020115915.02546ef0@pop.avici.com> <1098283324.15751.132.camel@pcobo> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: Re: ordered SPFs 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: e5ba305d0e64821bf3d8bc5d3bb07228 Mike, To clarify a bit further on the inter-area issue, does this handle the case where the cost of a route advertised into the area changes so that a different ABR is selected? What if the cost to the different ABR changes semi-simultaneously? Alia At 01:59 PM 10/21/2004, Alia Atlas wrote: >Mike, > >Here are a couple other questions about ordered SPFs. > >First, how does this interact/work with OSPF Virtual Links? >Second, how does this interact with different areas? > >Alia > > >_______________________________________________ >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 Oct 22 08:00: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 IAA26322 for ; Fri, 22 Oct 2004 08:00:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKyIz-0004ZZ-P2 for rtgwg-web-archive@ietf.org; Fri, 22 Oct 2004 08:14:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKy2I-0002oC-RF; Fri, 22 Oct 2004 07:56:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKxw4-0000WY-Mz for rtgwg@megatron.ietf.org; Fri, 22 Oct 2004 07:50:21 -0400 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 HAA25747 for ; Fri, 22 Oct 2004 07:50:18 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKy8q-0004OZ-Bf for rtgwg@ietf.org; Fri, 22 Oct 2004 08:03:33 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 22 Oct 2004 14:05:35 +0200 X-BrightmailFiltered: true 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 i9MBncSf028726; Fri, 22 Oct 2004 13:49:39 +0200 (MEST) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4282.cisco.com [10.61.80.185]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA17953; Fri, 22 Oct 2004 12:49:37 +0100 (BST) Message-Id: <4.3.2.7.2.20041022124548.022e1518@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Oct 2004 12:49:37 +0100 To: Alia Atlas From: mike shand In-Reply-To: <5.1.0.14.2.20041022011635.024a96e0@pop.avici.com> References: <5.1.0.14.2.20041021135731.0258eb38@pop.avici.com> <4.3.2.7.2.20041021163242.02466008@jaws.cisco.com> <5.1.0.14.2.20041021111720.025854f8@pop.avici.com> <4.3.2.7.2.20041021154941.02bcf2c8@jaws.cisco.com> <5.1.0.14.2.20041020115915.02546ef0@pop.avici.com> <1098283324.15751.132.camel@pcobo> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: rtorvi@avici.com, Pierre Francois , rtgwg@ietf.org Subject: Re: ordered SPFs 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: 769a46790fb42fbb0b0cc700c82f7081 At 01:18 22/10/2004 -0400, Alia Atlas wrote: >Mike, > >To clarify a bit further on the inter-area issue, does this handle the >case where the cost of a route advertised into the area changes so that a >different ABR is selected? I hadn't thought about that, but off hand I would say that you can model this scenario as if you have two (or more) ABRs (say A and B) each of which has a "link" to the external route X. So the scenario you describe is equivalent to a failure (or cost change) of the AX or BX link. As such, the normal mechanisms should handle it. But it would require special casing to for the code to make this interpretation. > What if the cost to the different ABR changes semi-simultaneously? I think that is a case of the generalized SRLG isn't it? Mike >Alia > >At 01:59 PM 10/21/2004, Alia Atlas wrote: >>Mike, >> >>Here are a couple other questions about ordered SPFs. >> >>First, how does this interact/work with OSPF Virtual Links? >>Second, how does this interact with different areas? >> >>Alia >> >> >>_______________________________________________ >>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 Oct 22 08: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 IAA26742 for ; Fri, 22 Oct 2004 08:08:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKyQA-0004fs-Qm for rtgwg-web-archive@ietf.org; Fri, 22 Oct 2004 08:21:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKyBU-0005cb-C7; Fri, 22 Oct 2004 08:06:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKy8u-0004sk-2O for rtgwg@megatron.ietf.org; Fri, 22 Oct 2004 08:03:36 -0400 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 IAA26480 for ; Fri, 22 Oct 2004 08:03:34 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKyLg-0004c0-E6 for rtgwg@ietf.org; Fri, 22 Oct 2004 08:16:49 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 22 Oct 2004 14:18:53 +0200 X-BrightmailFiltered: true 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 i9MC2vSf001596; Fri, 22 Oct 2004 14:02:58 +0200 (MEST) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4282.cisco.com [10.61.80.185]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA18301; Fri, 22 Oct 2004 13:02:54 +0100 (BST) Message-Id: <4.3.2.7.2.20041022085104.022e1518@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Oct 2004 13:02:34 +0100 To: Alia Atlas From: mike shand In-Reply-To: <5.1.0.14.2.20041021124809.02583228@pop.avici.com> References: <4.3.2.7.2.20041021163242.02466008@jaws.cisco.com> <5.1.0.14.2.20041021111720.025854f8@pop.avici.com> <4.3.2.7.2.20041021154941.02bcf2c8@jaws.cisco.com> <5.1.0.14.2.20041020115915.02546ef0@pop.avici.com> <1098283324.15751.132.camel@pcobo> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: rtgwg@ietf.org, Pierre Francois Subject: Re: ordered SPFs 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: 848ed35f2a4fc0638fa89629cb640f48 Alia, You are assuming I think, that the broadcast "link" is actually made up of a full mesh of pt-pt links, and what you are describing is a failure of 3 of those links simultaneously (don't forget the reverse connectivity check), breaking connectivity of the triangle ABC. As such, this is neither node failure nor single link failure, but probably comes in the category of unrelated SRLG, so it is not surprising that an incorrect ordering may occur (I haven't analyzed it yet to be sure, but it seems likely). However, if the broadcast link were represented as it normally would be as a pseudonode (or the OSPF equivalent), then the situation would be rather different, and would depend on which router was DR. What you describe would cause the loss of adjacencies between AB,AC and BC. If E were DR, there would be no change in the LSPs, since A,B & C's links to and from the pseudonode would still be intact. In IS-IS (I don't know for sure about OSPF), there would be no break in connectivity either, since if (for example) A needed to send a packet to C it would send it to the DR(E), which would in turn send it to C. This is how IS-IS deals with partial adjacency formation on a LAN. If A (or B or C) were DR, then all sorts of interesting possibilities arise. If (for example) B had the next highest priority/mac address to A, then when B lost its adjacency to A it would elect itself as a second DR. The consequences are probably too horrible to imagine. The bottom line is that the broadcast link protocols do not handle this sort of non-transitive broadcast medium failure at all well. Indeed they were not designed to. See the following extract from clause 6.7 of ISO/IEC 10589 c) The following events are "very low probability", which means performance will be impacted unless they are extremely rare, on the order of less than one event per four years 1) Delivery of NPDUs with undetected data corruption; and 2) Nontransitive connectivity, i.e. where system A can receive transmissions from systems B and C, but system B cannot receive transmissions from system C. SO now going back to your analysis of the pt-pt link case. I think you may have misunderstood how the reverse SPF is used. Remember that it is ONLY the portion of the RSPF which crosses the link under consideration which is interesting. So I think this gives the following values, for delay (which is horizon hop count - hop count) Node | delay | delay | max from | delay | | from A | from B | A & B | from C | ------+-----------+----------+----------+----------+ A | 0 | 0 | 0 | 5 B | 3 | 0 | 3 | 5 C | 0 | 1 | 1 | 0 D | 0 | 0 | 0 | 0 E | 0 | 0 | 0 | 0 F | 2 | 0 | 2 | 4 G | 1 | 0 | 1 | 3 H | 0 | 0 | 0 | 2 S | 0 | 0 | 0 | 0 I | 0 | 0 | 0 | 1 I don't THINK there is a conflict here, so despite the link failure not being "related" (in the sense of all applying to the same node), at least in this case I think it doesn't cause a problem. But these things are somewhat tricky to evaluate by hand, and my simulator doesn't (yet :-) deal with such "unrelated" failures. So it is possible I have missed something here. I'll try to do a proper analysis when I get time. Mike At 12:56 21/10/2004 -0400, Alia Atlas wrote: >At 11:33 AM 10/21/2004, mike shand wrote: >>At 11:25 21/10/2004 -0400, Alia Atlas wrote: >>>I'm thinking of the case where there's a broadcast link that >>>fails. Otherwise, there's a race condition that depends on when the >>>LSPs are received. >> >>Could you give an example? > >I'm working on it. Basically, I'm assuming that arbitrary failures of >connectivity can happen inside a broadcast link due to layer-2 equipment. > >Could you give an example where the correct behavior is to increase the >delay in the event of a failure? > >I believe that the correct behavior would be the other way (for a failure >case), because of the need to remove dependencies; also, all the nodes >upstream of the one whose hopCount was increased would also have increased >hopCounts, so reducing the delay is appropriate. > >The example that I have so far is rather contrived and assumes arbitrary >(including 1-way) failure at layer-2. It is as follows: > > 50 > ----[ I ] > | | > | 10 | > | | 3 3 > | [ S ]----[ H ]---[ G ] > | | | 3 > | 12 | [ F ] > | | | 3 > | | | > | [ A ] [ B ] > | | 5 | > | 5 |----------------| > | | | > | | 5 | 5 > | [ C ] [ E ] > | | > |----[ D ]----| 10 > > >Consider the above topology where D is the destination for the traffic >under consideration. A partial failure occurs on the broadcast link >between A, B and C, as could occur due to a layer-2 switch. After the >failure, the following connections exist: > A to C, A to E, > B to A, B to E, > C to E, > E to A, E to B, E to C > >Before the failure, S had equal-cost paths to D via A and via H. > >As a result of this failure, 3 LSPs would be sent out: > LSP 1 from A: reports connection to B is down > LSP 2 from B: reports connection to C is down > LSP 3 from C: reports connections to A and B are down > >The following are the hopCounts from doing RSPTs on A, B and C based >on the topology before the failure. > >Node | hopCount | hopCount | max from | hopCount | > | from A | from B | A & B | from C | >------+-----------+----------+----------+----------+ > A | 0 | 1 | 1 | 1 > B | 1 | 0 | 1 | 1 > C | 1 | 1 | 1 | 0 > D | 2 | 2 | 2 | 1 > E | 1 | 1 | 1 | 1 > F | 2 | 1 | 2 | 2 > G | 3 | 2 | 3 | 3 > H | 4 | 3 | 4 | 4 > S | 1 | 4 | 4 | 5 > I | 2 | 5 | 5 | 6 > >Assume that LSP 1 arrives before LSP 2 or LSP 3. > >In that case, H and S would use the same delay and thereby cause a micro-loop. > >Does this match with what you are saying? > >I realize that the Ordered SPFs works most of the time; I'm trying to >understand the corner cases (however improbable) better. > >Thanks, >Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 22 09:02:51 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 JAA00586 for ; Fri, 22 Oct 2004 09:02:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKzH5-0005jB-BO for rtgwg-web-archive@ietf.org; Fri, 22 Oct 2004 09:16:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKz0k-0007BL-NX; Fri, 22 Oct 2004 08:59:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKyu2-0004SL-Kh for rtgwg@megatron.ietf.org; Fri, 22 Oct 2004 08:52:18 -0400 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 IAA29638 for ; Fri, 22 Oct 2004 08:52:16 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKz6m-0005Su-3O for rtgwg@ietf.org; Fri, 22 Oct 2004 09:05:32 -0400 Received: from aatlas-lt.avici.com ([10.2.103.13]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i9MCpPni015504; Fri, 22 Oct 2004 08:51:25 -0400 Message-Id: <5.1.0.14.2.20041022084220.0250a830@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Oct 2004 08:51:28 -0400 To: mike shand From: Alia Atlas In-Reply-To: <4.3.2.7.2.20041022124548.022e1518@jaws.cisco.com> References: <5.1.0.14.2.20041022011635.024a96e0@pop.avici.com> <5.1.0.14.2.20041021135731.0258eb38@pop.avici.com> <4.3.2.7.2.20041021163242.02466008@jaws.cisco.com> <5.1.0.14.2.20041021111720.025854f8@pop.avici.com> <4.3.2.7.2.20041021154941.02bcf2c8@jaws.cisco.com> <5.1.0.14.2.20041020115915.02546ef0@pop.avici.com> <1098283324.15751.132.camel@pcobo> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: rtorvi@avici.com, Pierre Francois , rtgwg@ietf.org Subject: Re: ordered SPFs 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: 21c69d3cfc2dd19218717dbe1d974352 At 07:49 AM 10/22/2004, mike shand wrote: >At 01:18 22/10/2004 -0400, Alia Atlas wrote: >>To clarify a bit further on the inter-area issue, does this handle the >>case where the cost of a route advertised into the area changes so that a >>different ABR is selected? > >I hadn't thought about that, but off hand I would say that you can model >this scenario as if you have two (or more) ABRs (say A and B) each of >which has a "link" to the external route X. So the scenario you describe >is equivalent to a failure (or cost change) of the AX or BX link. As such, >the normal mechanisms should handle it. But it would require special >casing to for the code to make this interpretation. Such would be necessary to prevent micro-loops for inter-area routes; those matter too :-) I don't think that the distance to the prefix matters, so the same trick could work for inter-AS routes, where what changes is whether there is connectivity. >> What if the cost to the different ABR changes semi-simultaneously? > >I think that is a case of the generalized SRLG isn't it? Well, the key is that the costs could only increase or decrease together, due to a single link or node failure, so if one does the fake node trick, then you get the correct RSPT for ordering. >>>First, how does this interact/work with OSPF Virtual Links? Virtual Links seem to present much more of a problem. Only the routers connected to the virtual link knows the current length of it in hops. All the other routers would probably assume it was a single hop. Any thoughts on that? Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 22 09:22: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 JAA02000 for ; Fri, 22 Oct 2004 09:22:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKzZi-00063L-Sk for rtgwg-web-archive@ietf.org; Fri, 22 Oct 2004 09:35:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKzGm-0004t2-3b; Fri, 22 Oct 2004 09:15:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKzCg-0003Kj-Mv for rtgwg@megatron.ietf.org; Fri, 22 Oct 2004 09:11:34 -0400 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 JAA01162 for ; Fri, 22 Oct 2004 09:11:32 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKzPU-0005r6-2U for rtgwg@ietf.org; Fri, 22 Oct 2004 09:24:48 -0400 Received: from aatlas-lt.avici.com ([10.2.103.13]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i9MDApni019813; Fri, 22 Oct 2004 09:10:54 -0400 Message-Id: <5.1.0.14.2.20041022085152.025abb10@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Oct 2004 09:10:54 -0400 To: mike shand From: Alia Atlas In-Reply-To: <4.3.2.7.2.20041022085104.022e1518@jaws.cisco.com> References: <5.1.0.14.2.20041021124809.02583228@pop.avici.com> <4.3.2.7.2.20041021163242.02466008@jaws.cisco.com> <5.1.0.14.2.20041021111720.025854f8@pop.avici.com> <4.3.2.7.2.20041021154941.02bcf2c8@jaws.cisco.com> <5.1.0.14.2.20041020115915.02546ef0@pop.avici.com> <1098283324.15751.132.camel@pcobo> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: rtgwg@ietf.org, Pierre Francois Subject: Re: ordered SPFs 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: 1a1bf7677bfe77d8af1ebe0e91045c5b Mike, At 08:02 AM 10/22/2004, mike shand wrote: > You are assuming I think, that the broadcast "link" is actually > made up of a full mesh of pt-pt links, and what you are describing is a > failure of 3 of those links simultaneously (don't forget the reverse > connectivity check), breaking connectivity of the triangle ABC. As such, > this is neither node failure nor single link failure, but probably comes > in the category of unrelated SRLG, so it is not surprising that an > incorrect ordering may occur (I haven't analyzed it yet to be sure, but > it seems likely). Granted. I said it was very contrived. Could you please send me an example where you believe it is correct to increase the delay (but not decrease it)? That is the part that I am objecting to. For this to matter in a scenario, it seems that one needs both ECMP, so that the traffic is flowing across more than one link, and to have not computed the RSPT from the node which merges the paths. Clearly, you believe you have such a scenario where the proper behavior is to increase delay, but not decrease it. Could you please send me that such a topology? Do you have such an example? Could you explain why you believe it is safe to increase the delay but not decrease it? > However, if the broadcast link were represented as it normally > would be as a pseudonode (or the OSPF equivalent), then the situation > would be rather different, and would depend on which router was DR. What > you describe would cause the loss of adjacencies between AB,AC and BC. Yes, that was the idea :-) > If E were DR, there would be no change in the LSPs, since A,B & > C's links to and from the pseudonode would still be intact. In IS-IS (I > don't know for sure about OSPF), there would be no break in connectivity > either, since if (for example) A needed to send a packet to C it would > send it to the DR(E), which would in turn send it to C. This is how IS-IS > deals with partial adjacency formation on a LAN. I put E in to be the DR. I believe that in OSPF, A, B and C would report the different connectivity, regardless of who was the DR. I can certainly double-check. >SO now going back to your analysis of the pt-pt link case. I think you may >have misunderstood how the reverse SPF is used. Remember that it is ONLY >the portion of the RSPF which crosses the link under consideration which >is interesting. It's only that portion which matters b/c it's only that traffic which is affected, sure. >So I think this gives the following values, for delay (which is horizon >hop count - hop count) > >Node | delay | delay | max from | delay | > | from A | from B | A & B | from C | >------+-----------+----------+----------+----------+ > A | 0 | 0 | 0 | 5 > B | 3 | 0 | 3 | 5 > C | 0 | 1 | 1 | 0 > D | 0 | 0 | 0 | 0 > E | 0 | 0 | 0 | 0 > F | 2 | 0 | 2 | 4 > G | 1 | 0 | 1 | 3 > H | 0 | 0 | 0 | 2 > S | 0 | 0 | 0 | 0 > I | 0 | 0 | 0 | 1 This can't be correct. I is dependent on S to reach D via the broadcast link. >I don't THINK there is a conflict here, so despite the link failure not >being "related" (in the sense of all applying to the same node), at least >in this case I think it doesn't cause a problem. The topology tried to have H and S on different unconnected branches of the RSPT for the first LSP/LSA and then have them on a connected branch for the second. >But these things are somewhat tricky to evaluate by hand, and my simulator >doesn't (yet :-) deal with such "unrelated" failures. So it is possible I >have missed something here. > >I'll try to do a proper analysis when I get time. I'm not focused on this particular example, but on trying to understand your rationale for believing it is acceptable to increase the delay and not decrease it. Intuitively, that doesn't make sense to me because what you are doing is not removing a dependency as early as was required. That original dependency doesn't go away. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 22 09:50: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 JAA04360 for ; Fri, 22 Oct 2004 09:50:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL015-0006fl-50 for rtgwg-web-archive@ietf.org; Fri, 22 Oct 2004 10:03:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKzjN-0006ag-6H; Fri, 22 Oct 2004 09:45:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKzeh-0003kJ-KT for rtgwg@megatron.ietf.org; Fri, 22 Oct 2004 09:40:31 -0400 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 JAA03466 for ; Fri, 22 Oct 2004 09:40:28 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKzrR-0006Q2-Tp for rtgwg@ietf.org; Fri, 22 Oct 2004 09:53:44 -0400 Received: from aatlas-lt.avici.com ([10.2.103.13]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i9MDcPni025074; Fri, 22 Oct 2004 09:38:25 -0400 Message-Id: <5.1.0.14.2.20041022093404.025c2008@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Oct 2004 09:38:28 -0400 To: mike shand From: Alia Atlas In-Reply-To: <4.3.2.7.2.20041022085104.022e1518@jaws.cisco.com> References: <5.1.0.14.2.20041021124809.02583228@pop.avici.com> <4.3.2.7.2.20041021163242.02466008@jaws.cisco.com> <5.1.0.14.2.20041021111720.025854f8@pop.avici.com> <4.3.2.7.2.20041021154941.02bcf2c8@jaws.cisco.com> <5.1.0.14.2.20041020115915.02546ef0@pop.avici.com> <1098283324.15751.132.camel@pcobo> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: rtgwg@ietf.org, Pierre Francois Subject: Re: ordered SPFs 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 At 08:02 AM 10/22/2004, mike shand wrote: >SO now going back to your analysis of the pt-pt link case. I think you may >have misunderstood how the reverse SPF is used. Remember that it is ONLY >the portion of the RSPF which crosses the link under consideration which >is interesting. If I understand this correctly, what you are saying is that you do an RSPF for each end of the link and take the results from the one whose first hop is across the link which just failed. This is how you resolve the multiple RSPFs required for a single link failure. If multiple link failures are reported in the same LSP/LSA, then how do you decide which of the RSPFs to use? Do you take the maximum hopCount of all RSPFs which go across a failed link? If additional link failures are reported in a different LSP/LSA, then how do you decide which of the RSPFs to use (among the one selected for this LSP/LSA and the current one)? Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 22 12:04: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 MAA16654 for ; Fri, 22 Oct 2004 12:04:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL26g-0001BB-Ee for rtgwg-web-archive@ietf.org; Fri, 22 Oct 2004 12:17:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1mW-0000kp-UL; Fri, 22 Oct 2004 11:56:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1gS-0006nH-40 for rtgwg@megatron.ietf.org; Fri, 22 Oct 2004 11:50:28 -0400 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 LAA15734 for ; Fri, 22 Oct 2004 11:50:24 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1tF-0000tr-Ka for rtgwg@ietf.org; Fri, 22 Oct 2004 12:03:42 -0400 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 i9MFmini024864; Fri, 22 Oct 2004 11:48:45 -0400 Message-Id: <5.1.0.14.2.20041022103939.025e0008@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Oct 2004 11:48:50 -0400 To: mike shand , rtgwg@ietf.org, Pierre Francois From: Alia Atlas In-Reply-To: <5.1.0.14.2.20041022093404.025c2008@pop.avici.com> References: <4.3.2.7.2.20041022085104.022e1518@jaws.cisco.com> <5.1.0.14.2.20041021124809.02583228@pop.avici.com> <4.3.2.7.2.20041021163242.02466008@jaws.cisco.com> <5.1.0.14.2.20041021111720.025854f8@pop.avici.com> <4.3.2.7.2.20041021154941.02bcf2c8@jaws.cisco.com> <5.1.0.14.2.20041020115915.02546ef0@pop.avici.com> <1098283324.15751.132.camel@pcobo> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: Re: ordered SPFs 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 At 09:38 AM 10/22/2004, Alia Atlas wrote: >At 08:02 AM 10/22/2004, mike shand wrote: >>SO now going back to your analysis of the pt-pt link case. I think you >>may have misunderstood how the reverse SPF is used. Remember that it is >>ONLY the portion of the RSPF which crosses the link under consideration >>which is interesting. Are you saying that you only take the branch of the RSPT that goes across the failed link? Presumably this is to reduce the set of affected nodes, which makes sense. Looking at the following ECMP example, I think we may be arguing the same thing. 50 [ I ]-----------------------| | | 5 | | | 2 2 | [ S ]----[ A ]----[ B ] | | | 2 | | [ C ] | | 15 | 2 | | [ E ] | | | | | | 2 | | 5 10 | | [ H ]----[ G ]----[ F ] | | | | 5 | | | [ D ]--------------| In the above topology, D is the destination and G is the node which fails. Before the failure, S has two equal-cost paths to D, via H-G-D or via A-B-C-E-F-G-D. According to the Ordered SPFs idea, when G fails, each router will do three reverse spanning trees (based on distance), from each of H, F and D, and only take the branch that goes across the particular failed link (H-G, F-G and D-G). Assume that S hears about the H-G failure first. S will compute its hopCount as 1; the maxHorizon is 2. So the delay is 1. Then S hears about the F-G failure. Now, S will compute its hopCount as 5 and the maxHorizon is 6. So the delay is 1. I was thinking of computing the delay essentially based on the final hopCount and the final maxHorizon. Instead, I think you are taking the delay based on each hopCount and maxHorizon, for each failed link, and then taking the max. Sorry for being confused; I do think this needs substantially more description. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 22 13:09:21 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 NAA21144 for ; Fri, 22 Oct 2004 13:09:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL37g-0002Ne-QV for rtgwg-web-archive@ietf.org; Fri, 22 Oct 2004 13:22:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2p1-0006Pm-8B; Fri, 22 Oct 2004 13:03:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2ha-0004BJ-OM for rtgwg@megatron.ietf.org; Fri, 22 Oct 2004 12:55:42 -0400 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 MAA20234 for ; Fri, 22 Oct 2004 12:55:38 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2uO-00029a-HW for rtgwg@ietf.org; Fri, 22 Oct 2004 13:08:57 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 22 Oct 2004 19:11:02 +0200 X-BrightmailFiltered: true 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 i9MGt4Sf007990; Fri, 22 Oct 2004 18:55:04 +0200 (MEST) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4142.cisco.com [10.61.80.45]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA00475; Fri, 22 Oct 2004 17:55:03 +0100 (BST) Message-Id: <4.3.2.7.2.20041022173730.02e7fe90@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Oct 2004 17:54:56 +0100 To: Alia Atlas From: mike shand In-Reply-To: <5.1.0.14.2.20041022103939.025e0008@pop.avici.com> References: <5.1.0.14.2.20041022093404.025c2008@pop.avici.com> <4.3.2.7.2.20041022085104.022e1518@jaws.cisco.com> <5.1.0.14.2.20041021124809.02583228@pop.avici.com> <4.3.2.7.2.20041021163242.02466008@jaws.cisco.com> <5.1.0.14.2.20041021111720.025854f8@pop.avici.com> <4.3.2.7.2.20041021154941.02bcf2c8@jaws.cisco.com> <5.1.0.14.2.20041020115915.02546ef0@pop.avici.com> <1098283324.15751.132.camel@pcobo> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Pierre Francois , rtgwg@ietf.org Subject: Re: ordered SPFs 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: 10d3e4e3c32e363f129e380e644649be At 11:48 22/10/2004 -0400, Alia Atlas wrote: >At 09:38 AM 10/22/2004, Alia Atlas wrote: >>At 08:02 AM 10/22/2004, mike shand wrote: >>>SO now going back to your analysis of the pt-pt link case. I think you >>>may have misunderstood how the reverse SPF is used. Remember that it is >>>ONLY the portion of the RSPF which crosses the link under consideration >>>which is interesting. > >Are you saying that you only take the branch of the RSPT that goes across >the failed link? Presumably this is to reduce the set of affected nodes, >which makes sense. Yes, exactly. >Looking at the following ECMP example, I think we may be arguing the same >thing. > > 50 > [ I ]-----------------------| > | | > 5 | | > | 2 2 | > [ S ]----[ A ]----[ B ] | > | | 2 | > | [ C ] | > | 15 | 2 | > | [ E ] | > | | | > | | 2 | > | 5 10 | | > [ H ]----[ G ]----[ F ] | > | | > | 5 | > | | > [ D ]--------------| > >In the above topology, D is the destination and G is the node which >fails. Before the failure, S has two equal-cost paths to D, via H-G-D >or via A-B-C-E-F-G-D. According to the Ordered SPFs idea, when G >fails, each router will do three reverse spanning trees (based on >distance), from each of H, F and D, and only take the branch that goes >across the particular failed link (H-G, F-G and D-G). > >Assume that S hears about the H-G failure first. S will compute its >hopCount as 1; the maxHorizon is 2. So the delay is 1. Yes. >Then S hears about the F-G failure. Now, S will compute its hopCount >as 5 and the maxHorizon is 6. So the delay is 1. Yes. I agree. >I was thinking of computing the delay essentially based on the final >hopCount and the final maxHorizon. Instead, I think you are taking the >delay based on each hopCount and maxHorizon, for each failed link, and >then taking the max. Yes. That is correct. I think this explains both our confusions! >Sorry for being confused; I do think this needs substantially more >description. The whole thing is confusing at the best of times.! Sorry I haven't been able to give this much time this week. Mike >Alia > > >_______________________________________________ >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 Oct 22 13:58: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 NAA24977 for ; Fri, 22 Oct 2004 13:58:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3tb-0003JM-DX for rtgwg-web-archive@ietf.org; Fri, 22 Oct 2004 14:12:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3eS-0005Xp-N8; Fri, 22 Oct 2004 13:56:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3VX-0003WS-0a for rtgwg@megatron.ietf.org; Fri, 22 Oct 2004 13:47:20 -0400 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 NAA24153 for ; Fri, 22 Oct 2004 13:47:16 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3iL-00033m-55 for rtgwg@ietf.org; Fri, 22 Oct 2004 14:00:34 -0400 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 i9MHjIni019282; Fri, 22 Oct 2004 13:45:18 -0400 Message-Id: <5.1.0.14.2.20041022134301.024b9340@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Oct 2004 13:45:26 -0400 To: mike shand From: Alia Atlas In-Reply-To: <4.3.2.7.2.20041022173730.02e7fe90@jaws.cisco.com> References: <5.1.0.14.2.20041022103939.025e0008@pop.avici.com> <5.1.0.14.2.20041022093404.025c2008@pop.avici.com> <4.3.2.7.2.20041022085104.022e1518@jaws.cisco.com> <5.1.0.14.2.20041021124809.02583228@pop.avici.com> <4.3.2.7.2.20041021163242.02466008@jaws.cisco.com> <5.1.0.14.2.20041021111720.025854f8@pop.avici.com> <4.3.2.7.2.20041021154941.02bcf2c8@jaws.cisco.com> <5.1.0.14.2.20041020115915.02546ef0@pop.avici.com> <1098283324.15751.132.camel@pcobo> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Pierre Francois , rtgwg@ietf.org Subject: Re: ordered SPFs 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: e5ba305d0e64821bf3d8bc5d3bb07228 At 12:54 PM 10/22/2004, mike shand wrote: >>I was thinking of computing the delay essentially based on the final >>hopCount and the final maxHorizon. Instead, I think you are taking the >>delay based on each hopCount and maxHorizon, for each failed link, and >>then taking the max. > >Yes. That is correct. I think this explains both our confusions! Well, a combo of that and my not realizing you were pruning the RSPT. I knew it had to be an ECMP case that caused the issue, but without the pruning, I couldn't find a way to have the different updates matter. >>Sorry for being confused; I do think this needs substantially more >>description. > > The whole thing is confusing at the best of times.! > >Sorry I haven't been able to give this much time this week. It's a busy week for everyone :-) As you can tell, I think the ordered SPFs is a very interesting idea. The question is how it works in practice with all the extra details. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 22 18:17: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 SAA01917 for ; Fri, 22 Oct 2004 18:17:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7w3-0005YF-Mi for rtgwg-web-archive@ietf.org; Fri, 22 Oct 2004 18:31:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6up-0006vb-1D; Fri, 22 Oct 2004 17:25:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6Fk-0004D2-FI for rtgwg@megatron.ietf.org; Fri, 22 Oct 2004 16:43:12 -0400 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 QAA12066 for ; Fri, 22 Oct 2004 16:43:08 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL6SX-0007g8-So for rtgwg@ietf.org; Fri, 22 Oct 2004 16:56:29 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL6Fb-000AD7-96; Fri, 22 Oct 2004 20:43:03 +0000 Date: Fri, 22 Oct 2004 13:43:01 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <539252185.20041022134301@psg.com> To: mike shand In-Reply-To: <4.3.2.7.2.20041022173730.02e7fe90@jaws.cisco.com> References: <5.1.0.14.2.20041022093404.025c2008@pop.avici.com> <4.3.2.7.2.20041022085104.022e1518@jaws.cisco.com> <5.1.0.14.2.20041021124809.02583228@pop.avici.com> <4.3.2.7.2.20041021163242.02466008@jaws.cisco.com> <5.1.0.14.2.20041021111720.025854f8@pop.avici.com> <4.3.2.7.2.20041021154941.02bcf2c8@jaws.cisco.com> <5.1.0.14.2.20041020115915.02546ef0@pop.avici.com> <1098283324.15751.132.camel@pcobo> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> <5.1.0.14.2.20041020003446.024abfc8@pop.avici.com> <4.3.2.7.2.20041022173730.02e7fe90@jaws.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Alia Atlas , rtgwg@ietf.org, Pierre Francois Subject: Re: ordered SPFs 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: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit >>Sorry for being confused; I do think this needs substantially more >>description. > The whole thing is confusing at the best of times.! > Sorry I haven't been able to give this much time this week. Mike- I think at this point it would be very useful to see a detailed description of the method from you guys. Do you think you could do this before DC (I could put the draft on the WG web-site and you'd submit it after the meeting)? Regards. Alex _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 22 19:21: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 TAA12662 for ; Fri, 22 Oct 2004 19:21:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8vd-0000Oy-4f for rtgwg-web-archive@ietf.org; Fri, 22 Oct 2004 19:34:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8Wu-00063Y-Ks; Fri, 22 Oct 2004 19:09:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8GT-0001fX-B7 for rtgwg@megatron.ietf.org; Fri, 22 Oct 2004 18:52:05 -0400 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 SAA07430 for ; Fri, 22 Oct 2004 18:52:03 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8TN-0007De-0D for rtgwg@ietf.org; Fri, 22 Oct 2004 19:05:26 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL8GR-00067l-1b for rtgwg@ietf.org; Fri, 22 Oct 2004 22:52:03 +0000 Date: Fri, 22 Oct 2004 15:52:02 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <4410194549.20041022155202@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: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: Agenda for IETF61 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: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Folks- We're going to have a WG meeting in DC. At this point, we will certainly have the following items on the agenda: - Basic IP FRR spec: review of recent changes - Micro-loop prevention discussion If you would like to present something else, please send me an e-mail. -- 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 Oct 26 21:51: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 VAA20036 for ; Tue, 26 Oct 2004 21:51:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMdCY-0000oh-MI for rtgwg-web-archive@ietf.org; Tue, 26 Oct 2004 22:06:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMcxc-00080f-SK; Tue, 26 Oct 2004 21:50:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMcxC-0007io-Ps for rtgwg@megatron.ietf.org; Tue, 26 Oct 2004 21:50:22 -0400 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 VAA19915 for ; Tue, 26 Oct 2004 21:50:18 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMdAs-0000lk-W3 for rtgwg@ietf.org; Tue, 26 Oct 2004 22:04:34 -0400 Received: from aatlas-lt.avici.com ([10.2.103.94]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i9R1nani026738 for ; Tue, 26 Oct 2004 21:49:37 -0400 Message-Id: <5.1.0.14.2.20041026214046.025625d0@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Oct 2004 21:49:42 -0400 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: 36c793b20164cfe75332aa66ddb21196 Subject: Fwd: I-D ACTION:draft-atlas-ip-local-protect-uturn-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: 1676547e4f33b5e63227e9c02bd359e3 I've revised the U-turn alternates draft. The major changes are as follows: a) Introduced the option for explicitly marking U-turn traffic. This may simplify some hardware implementations, allows handling of more broadcast link cases, allows correct handling of traffic exiting a TE tunnel via PHP (if needed), and provides a method where only traffic that is explicitly requested to be sent to the alternate will be. b) Added example algorithm for computing u-turn alternates. Worst-case is N additional SPFs, where N is the number of neighbors that could be U-turn alternates. This should also clarify reason for the alternate selection procedure. There is a brief discussion on considering SRLGs. Thanks, Alia >To: i-d-announce@ietf.org >From: Internet-Drafts@ietf.org >Date: Tue, 26 Oct 2004 16:33:39 -0400 >Subject: I-D ACTION:draft-atlas-ip-local-protect-uturn-01.txt >X-BeenThere: i-d-announce@ietf.org >X-Mailman-Version: 2.1.5 >Reply-To: internet-drafts@ietf.org >List-Id: i-d-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: i-d-announce-bounces@ietf.org >X-Avici-MailScanner: Found to be clean, Found to be clean >X-Avici-MailScanner-SpamCheck: not spam, SpamAssassin (score=-100.08, > required 5, AV_BSPAMST2 2.00, AWL 1.64, BAYES_00 -4.90, > MIME_BOUND_NEXTPART 0.90, NO_REAL_NAME 1.19, SARE_HEAD_XBEEN -0.91, > USER_IN_WHITELIST -100.00) >X-MailScanner-From: i-d-announce-bounces@ietf.org >X-Avici-MailScanner-Information: Please contact the ISP for more information > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : U-turn Alternates for IP/LDP Local Protection > Author(s) : A. Atlas > Filename : draft-atlas-ip-local-protect-uturn-01.txt > Pages : 27 > Date : 2004-10-26 > >This document defines and describes the use of u-turn alternates to > provide local protection for IP unicast and/or LDP traffic in the > event of a single link or node failure. When a topology change > occurs, a router S pre-computes for each prefix an alternate next-hop > that can be used if the primary next-hop fails. An acceptable > alternate can be either a loop-free alternate or a U-turn alternate. > A U-turn alternate uses a neighbor, whose primary next-hop to the > prefix is router S itself and which has itself a loop-free > node-protecting alternate, which thus does not go through router S to > reach the destination prefix. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-atlas-ip-local-protect-uturn-01.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the >message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-atlas-ip-local-protect-uturn-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-atlas-ip-local-protect-uturn-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-10-26160927.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-atlas-ip-local-protect-uturn-01.txt > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Tue Oct 26 23:01: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 XAA24835 for ; Tue, 26 Oct 2004 23:01:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMeHt-0002Lo-PM for rtgwg-web-archive@ietf.org; Tue, 26 Oct 2004 23:15:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMdxW-0002tO-7W; Tue, 26 Oct 2004 22:54:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMdve-0001xT-HT for rtgwg@megatron.ietf.org; Tue, 26 Oct 2004 22:52:50 -0400 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 WAA23600 for ; Tue, 26 Oct 2004 22:52:47 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMe9Q-0001yA-Td for rtgwg@ietf.org; Tue, 26 Oct 2004 23:07:05 -0400 Received: from aatlas-lt.avici.com ([10.2.103.91]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i9R2qBni003056 for ; Tue, 26 Oct 2004 22:52:13 -0400 Message-Id: <5.1.0.14.2.20041026224853.025bce70@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Oct 2004 22:52:14 -0400 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: 3e15cc4fdc61d7bce84032741d11c8e5 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Hi Mike & Stewart, 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. Alia _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Oct 28 08:27: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 IAA06955 for ; Thu, 28 Oct 2004 08:27:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN9ay-000895-9N for rtgwg-web-archive@ietf.org; Thu, 28 Oct 2004 08:41:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN9Jl-0008BS-Fp; Thu, 28 Oct 2004 08:23:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN9Fy-0007Tn-Lv for rtgwg@megatron.ietf.org; Thu, 28 Oct 2004 08:19:56 -0400 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 IAA06540 for ; Thu, 28 Oct 2004 08:19:54 -0400 (EDT) Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN9U2-00080h-WC for rtgwg@ietf.org; Thu, 28 Oct 2004 08:34:27 -0400 Received: from sehan002fe.han.telia.se ([131.115.18.155]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Oct 2004 14:19:49 +0200 Received: from YBDH014427.teliasonera.com ([131.116.232.154]) by sehan002fe.han.telia.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Oct 2004 14:19:49 +0200 Message-Id: <6.0.1.1.0.20041028140936.0427deb8@tmspop.telia.se> X-Sender: ther45@tmspop.telia.se X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 28 Oct 2004 14:19:48 +0200 To: Alia Atlas , rtgwg@ietf.org From: Thomas Eriksson In-Reply-To: <5.1.0.14.2.20041026214046.025625d0@pop.avici.com> References: <5.1.0.14.2.20041026214046.025625d0@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 28 Oct 2004 12:19:49.0433 (UTC) FILETIME=[6B72B290:01C4BCE8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-uturn-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: 1ac7cc0a4cd376402b85bc1961a86ac2 Alia, we have talked briefly at the IETF a couple of times. I am interested in the IP fast reroute concept and hope that we can use it in our network some time in the future. I have a concern however. It is regarding the complexity of designing and keeping the topology so that uturn or even better, loop-free approach gives 100% coverage. Is my feeling correct that you need to keep a very dense topology to reach the 100% goal? Thomas _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Oct 28 12:44: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 MAA15537 for ; Thu, 28 Oct 2004 12:44:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNDbq-0002Z9-7s for rtgwg-web-archive@ietf.org; Thu, 28 Oct 2004 12:58:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCeb-0006MY-Pt; Thu, 28 Oct 2004 11:57:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBcr-0003ID-9i for rtgwg@megatron.ietf.org; Thu, 28 Oct 2004 10:51:41 -0400 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 KAA20052 for ; Thu, 28 Oct 2004 10:51:40 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNBqx-000308-0z for rtgwg@ietf.org; Thu, 28 Oct 2004 11:06:15 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i9SEosK4025641; Thu, 28 Oct 2004 10:50:54 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA02601; Thu, 28 Oct 2004 10:50:54 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Thu, 28 Oct 2004 10:50:54 -0400 Message-ID: <5551AD75D2C0BC459A85A2CEFAE4F800013061@usvissfp01.win.marconi.com> From: "Naidu, Venkata" To: "'Thomas Eriksson'" , rtgwg@ietf.org Date: Thu, 28 Oct 2004 10:50:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Alia Atlas Subject: RE: Fwd: I-D ACTION:draft-atlas-ip-local-protect-uturn-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: 9ed51c9d1356100bce94f1ae4ec616a9 -> Alia, we have talked briefly at the IETF a couple of times. -> I am interested -> in the IP fast reroute concept and hope that we can use it -> in our network -> some time in the future. I have a concern however. It is -> regarding the -> complexity of designing and keeping the topology so that -> uturn or even -> better, loop-free approach gives 100% coverage. Is my -> feeling correct that -> you need to keep a very dense topology to reach the 100% goal? Good question. 100% coverage is specific to number of failures. If an algorithm/approach is designed to cover 100% coverage for 1-failure may not cover 100% for 2-failures (simultaneous failures), even if the same topology is sufficient to cover 2-failures. For example, 1-failure 100% coverage topology for any V vertices would need at least E edges. E-1 edges are enough for a connected graph. So, E is still O(V), which is sparse. So, sparse topology is sufficient for 1-failure 100% coverage. In the real world, these types of topologies are very common. Look at token ring, sonet rings etc. All these ring topologies cover 1-failure very well. Because, graph is still connected if a node/link fails in a ring. Coming to k-failure (simultaneous) 100% coverage topology, the graph becomes dense and dense. More over, such graphs should have very particular properties, such as t-spanners. It is a very interesting research topic to find out when the topology becomes sparse to dense (i.e., E=O(V) to O(VV)). As the number of failures increase by one, the number of edges increase exponentially. So 2-failure 100% coverage would need a dense graph, IMO. Venkata. _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Oct 28 15:54:59 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 PAA28465 for ; Thu, 28 Oct 2004 15:54:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNGaX-00081Y-0n for rtgwg-web-archive@ietf.org; Thu, 28 Oct 2004 16:09:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CND3s-0003EY-42; Thu, 28 Oct 2004 12:23:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCc4-00049f-6R for rtgwg@megatron.ietf.org; Thu, 28 Oct 2004 11:54:56 -0400 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 LAA04685 for ; Thu, 28 Oct 2004 11:54:53 -0400 (EDT) Received: from doc.fokus.fraunhofer.de ([193.175.133.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNCq8-0007P6-Ir for rtgwg@ietf.org; Thu, 28 Oct 2004 12:09:29 -0400 Received: by doc.fokus.fraunhofer.de (Postfix, from userid 122) id 8FA472CE8E; Thu, 28 Oct 2004 17:54:51 +0200 (CEST) Date: Thu, 28 Oct 2004 17:54:51 +0200 From: Christoph Reichert To: rtgwg@ietf.org Message-ID: <20041028155451.GA4596@fokus.fraunhofer.de> References: <5.1.0.14.2.20041026214046.025625d0@pop.avici.com> <6.0.1.1.0.20041028140936.0427deb8@tmspop.telia.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.1.1.0.20041028140936.0427deb8@tmspop.telia.se> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Thomas Eriksson Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-uturn-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: 3e15cc4fdc61d7bce84032741d11c8e5 Hello, I just recently started lurking on this list. Sorry for referring just to a paper, but you might be interested in: C. Reichert, T. Magedanz, "Topologies for Resilient IP Networks", Sept., 2004 http://www.fokus.fraunhofer.de/research/cc/ngni/employees/christoph.reichert/pubs/topologies.pdf It's mainly pure graph theory, but we describe topologies in which every link and node can be protected by what we called "O2 routing" (out-degree 2), which is basically the same as IPFRR. Our conclusion is that this approach restricts topology design, but this restrictions do not hurt very much. The required density is modest, I would say. However, depending on the algorithm used, 100% coverage depends not only on the topology, but also on the link weights. We developed several algorithm, and from this experience, I am quite sure that the loop-free approach requires a special metric to achieve 100% coverage. chris On Thu, Oct 28, 2004 at 02:19:48PM +0200, Thomas Eriksson wrote: > Alia, we have talked briefly at the IETF a couple of times. I am interested > in the IP fast reroute concept and hope that we can use it in our network > some time in the future. I have a concern however. It is regarding the > complexity of designing and keeping the topology so that uturn or even > better, loop-free approach gives 100% coverage. Is my feeling correct that > you need to keep a very dense topology to reach the 100% goal? > > Thomas > > > _______________________________________________ > Rtgwg mailing list > Rtgwg@ietf.org > https://www1.ietf.org/mailman/listinfo/rtgwg -- Dipl.-Inform. Christoph Reichert Fraunhofer FOKUS email: reichert@fokus.fraunhofer.de Kaiserin-Augusta-Allee 31 tel: ++49-30-3463-7171 D-10589 Berlin ============================================ CoNEXT 2005 (Toulouse, France) in coopeartion with ACM Sigcomm. Submit your manuscript until May 1st! www.co-next.net _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Oct 28 19:03:51 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 TAA05554 for ; Thu, 28 Oct 2004 19:03:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNJXL-0001wI-IV for rtgwg-web-archive@ietf.org; Thu, 28 Oct 2004 19:18:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGT4-0002oF-2h; Thu, 28 Oct 2004 16:01:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNDyi-0007Zq-Dq for rtgwg@megatron.ietf.org; Thu, 28 Oct 2004 13:22:26 -0400 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 NAA24764 for ; Thu, 28 Oct 2004 13:22:21 -0400 (EDT) Received: from relay00.pair.com ([209.68.1.20] helo=relay.pair.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CNECo-0005g8-Ix for rtgwg@ietf.org; Thu, 28 Oct 2004 13:36:59 -0400 Received: (qmail 82104 invoked from network); 28 Oct 2004 17:22:15 -0000 Received: from 69.37.59.162.adsl.snet.net (HELO workhorse.faster-light.net) (69.37.59.162) by relay00.pair.com with SMTP; 28 Oct 2004 17:22:15 -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 i9SHLxhI004566; Thu, 28 Oct 2004 13:22:01 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200410281722.i9SHLxhI004566@workhorse.faster-light.net> To: "Naidu, Venkata" In-reply-to: Your message of "Thu, 28 Oct 2004 10:50:53 EDT." <5551AD75D2C0BC459A85A2CEFAE4F800013061@usvissfp01.win.marconi.com> Date: Thu, 28 Oct 2004 13:21:59 -0400 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Alia Atlas , "'Thomas Eriksson'" , rtgwg@ietf.org Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-uturn-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: 67c1ea29f88502ef6a32ccec927970f0 In message <5551AD75D2C0BC459A85A2CEFAE4F800013061@usvissfp01.win.marconi.com> "Naidu, Venkata" writes: > > -> Alia, we have talked briefly at the IETF a couple of times. > -> I am interested > -> in the IP fast reroute concept and hope that we can use it > -> in our network > -> some time in the future. I have a concern however. It is > -> regarding the > -> complexity of designing and keeping the topology so that > -> uturn or even > -> better, loop-free approach gives 100% coverage. Is my > -> feeling correct that > -> you need to keep a very dense topology to reach the 100% goal? > > Good question. 100% coverage is specific to number of > failures. If an algorithm/approach is designed to > cover 100% coverage for 1-failure may not cover 100% > for 2-failures (simultaneous failures), even if the same > topology is sufficient to cover 2-failures. > > For example, 1-failure 100% coverage topology for any > V vertices would need at least E edges. E-1 edges are > enough for a connected graph. So, E is still O(V), which > is sparse. So, sparse topology is sufficient for 1-failure > 100% coverage. In the real world, these types of topologies > are very common. Look at token ring, sonet rings etc. All > these ring topologies cover 1-failure very well. Because, > graph is still connected if a node/link fails in a ring. > > Coming to k-failure (simultaneous) 100% coverage topology, > the graph becomes dense and dense. More over, such graphs > should have very particular properties, such as t-spanners. > > It is a very interesting research topic to find out when > the topology becomes sparse to dense (i.e., E=O(V) to O(VV)). > As the number of failures increase by one, the number of > edges increase exponentially. So 2-failure 100% coverage > would need a dense graph, IMO. > > Venkata. Venkata, A more practical way of looking at the operational problem is to look at single failures plus any correlated failures that are likely to occur. For example: Node protection can be thought of as a simultaneious failure of all edges that terminate at a given node. Links (edges) that travel over a common length of fiber (DWM) may be considered to have a high probablitity of correlated failure. Links that rely on other common equipment or resources including power may experience correlated failure. Whether to consider the probablilty of failure of any given reasource as significant enough is up to the operator. In some cases fiber along the same physical path can fail. Classic examples, are fiber on the same bridge that collapsed, on both sides of the same railroad track, fiber in gas pipes dug up be a contractor digging up the wrong unused gas pipes, along the same (San Deigo) earthquake fault. The operator needs to decide if any case is sufficiently probable. Many causes of correlated failure are so small that they need not be considered. For example, redundant power is not supposed to fail. In the late 1980s the FAA lost connectivity on the eastern corridor when power failed when a backup generator used by both NYNEX and AT&T failed (same building) and their circuits through NYC from two different carrier failed simultaneously due to power. In the mid-1990s a rat exploded in a San Jose power transfer switch and took out grid and backup power. These are low probability but not zero. Same with fiber on the same earthquake fault line. FRR provides fast transient failover, not the only failover. The question is then economic, not technical. At what point is the probablility of a given correlated failure small enough that the risk of revenue loss due to violating an SLA or the potential customer ill will great enough to justify the cost of proecting against that particular failure. If the risk is that a correlated failure will result in under 1 second failover or a few seconds to failover rather than under 50 msec and the probablility of occurance is very low and the cost to provide protection is high, then not protecting against the low probablility correlated failure is a justifiable risk. There are many ways that a provider can do this analysis. A first order (which I think was the original question) is to just consider the minimal topology changes needed to cover single failures. Based solely on probablility estimates and a chosen probablility threshhold, a better approximation includes these "likely" correlated failures by including SRLG in the analysis and make sure it is supported in the recovery mechanism. These analysis can be done knowing just the topology and the set of SRLG that need to be considered (if it is not the null set) and therefore a vendor can do this for the provider given that information. Only the provider can determine the true risk by estimating the revenue loss if a given correlated failure is unprotected, the probability of that failure, and the cost of the candidate remedies. That would allow a more thorough cost vs risk analysis. The important thing to remember is that the risk in question is the risk of not having protection during the convergence transient (which should be sub second to a few seconds). Curtis ps - Or you can declare SRLG (or SRG?) to be a non-goal. _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Oct 28 21:42:13 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 VAA13736 for ; Thu, 28 Oct 2004 21:42:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNM0c-0005u3-PL for rtgwg-web-archive@ietf.org; Thu, 28 Oct 2004 21:56:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNJD4-00067a-34; Thu, 28 Oct 2004 18:57:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGOE-0002A5-Mz; Thu, 28 Oct 2004 15:56:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28906; Thu, 28 Oct 2004 15:56:53 -0400 (EDT) Message-Id: <200410281956.PAA28906@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 28 Oct 2004 15:56:53 -0400 Cc: rtgwg@ietf.org Subject: I-D ACTION:draft-ietf-rtgwg-ipfrr-framework-02.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.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group Working Group of the IETF. Title : IP Fast Reroute Framework Author(s) : M. Shand Filename : draft-ietf-rtgwg-ipfrr-framework-02.txt Pages : 13 Date : 2004-10-28 This document provides a framework for the development of IP fast-reroute mechanisms which provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS Fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. An essential part of such mechanisms is the prevention of packet loss caused by the loops which normally occur during the re-convergence of the network following a failure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-ipfrr-framework-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rtgwg-ipfrr-framework-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rtgwg-ipfrr-framework-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28155218.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rtgwg-ipfrr-framework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rtgwg-ipfrr-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28155218.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg --NextPart-- From rtgwg-bounces@ietf.org Thu Oct 28 22:34: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 WAA24426 for ; Thu, 28 Oct 2004 22:34:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNMpV-0000Ht-Dg for rtgwg-web-archive@ietf.org; Thu, 28 Oct 2004 22:49:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNKEJ-00041f-QY; Thu, 28 Oct 2004 20:02:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNIqZ-00062Q-Fj for rtgwg@megatron.ietf.org; Thu, 28 Oct 2004 18:34:19 -0400 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 SAA01012 for ; Thu, 28 Oct 2004 18:34:15 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNJ4d-0000al-Tf for rtgwg@ietf.org; Thu, 28 Oct 2004 18:48:55 -0400 Received: from aatlas-lt.avici.com ([10.2.103.74]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i9SMXQni023386; Thu, 28 Oct 2004 18:33:27 -0400 Message-Id: <5.1.0.14.2.20041028182916.01d9a360@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Oct 2004 18:33:27 -0400 To: Thomas Eriksson From: Alia Atlas In-Reply-To: <6.0.1.1.0.20041028140936.0427deb8@tmspop.telia.se> References: <5.1.0.14.2.20041026214046.025625d0@pop.avici.com> <5.1.0.14.2.20041026214046.025625d0@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information X-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: rtgwg@ietf.org Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-uturn-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: 69a74e02bbee44ab4f8eafdbcedd94a1 Thomas, My impression from the networks that I have analyzed is that most are very close to 100% (average 98%) for coverage with u-turn and loop-free alternates. For a few, I have explored the changes necessary to bring the coverage to 100%; it has been a relatively minor modification. For instance, the modification may be a link that was already planned, a slight modification to a metric, or the like. Clearly, this is topology dependent, but I think that a topology need not be substantially more dense than they are today. The purpose of u-turn alternates is to bring the coverage and network engineering into that area. I am more than happy to analyze any topologies and report back the results. These don't even have to be real topologies :-) Alia At 08:19 AM 10/28/2004, Thomas Eriksson wrote: >Alia, we have talked briefly at the IETF a couple of times. I am >interested in the IP fast reroute concept and hope that we can use it in >our network some time in the future. I have a concern however. It is >regarding the complexity of designing and keeping the topology so that >uturn or even better, loop-free approach gives 100% coverage. Is my >feeling correct that you need to keep a very dense topology to reach the >100% goal? > >Thomas _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Thu Oct 28 22:53: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 WAA27940 for ; Thu, 28 Oct 2004 22:53:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNN7s-0001SQ-Ml for rtgwg-web-archive@ietf.org; Thu, 28 Oct 2004 23:08:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNM68-0002Tv-AE; Thu, 28 Oct 2004 22:02:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNJLg-0002V5-RW for rtgwg@megatron.ietf.org; Thu, 28 Oct 2004 19:06:28 -0400 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 TAA05894 for ; Thu, 28 Oct 2004 19:06:26 -0400 (EDT) Received: from gateway.avici.com ([208.246.215.5] helo=mailhost.avici.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNJZq-00020S-Un for rtgwg@ietf.org; Thu, 28 Oct 2004 19:21:07 -0400 Received: from aatlas-lt.avici.com ([10.2.103.74]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id i9SN5bni029208; Thu, 28 Oct 2004 19:05:37 -0400 Message-Id: <5.1.0.14.2.20041028185521.027595b8@pop.avici.com> X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Oct 2004 19:05:40 -0400 To: curtis@faster-light.net From: Alia Atlas In-Reply-To: <200410281722.i9SHLxhI004566@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-Avici-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "'Thomas Eriksson'" , "Naidu, Venkata" , rtgwg@ietf.org Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-uturn-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: 0ddefe323dd869ab027dbfff7eff0465 There are other examples for SRLGs that may be of substantial interest. For example, multiple L3 interfaces may fail simultaneously, because they use the same physical port or line-card. It would be interesting to discuss what set of SRLGs need to be considered for protection. Similar to looking for node-protection, SRLG-protection might be significantly less common in current networks. Just as a node failure can cause forwarding loops when only a link-protecting alternate is available, an SRLG failure can cause forwarding loops when the available alternate doesn't offer SRLG protection. Naturally, computing SRLG protection is more expensive; at the very least for loop-free alternates, one has to drag the list of SRLGs traversed along the paths computed for a router's neighbors. I am concerned that we don't go down a path which won't handle correlated failures (even if they aren't handled in the initial considerations). Alia At 01:21 PM 10/28/2004, Curtis Villamizar wrote: >For example: > > Node protection can be thought of as a simultaneious failure of all > edges that terminate at a given node. > > Links (edges) that travel over a common length of fiber (DWM) may be > considered to have a high probablitity of correlated failure. > > Links that rely on other common equipment or resources including > power may experience correlated failure. Whether to consider the > probablilty of failure of any given reasource as significant enough > is up to the operator. > > In some cases fiber along the same physical path can fail. Classic > examples, are fiber on the same bridge that collapsed, on both sides > of the same railroad track, fiber in gas pipes dug up be a > contractor digging up the wrong unused gas pipes, along the same > (San Deigo) earthquake fault. The operator needs to decide if any > case is sufficiently probable. _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From rtgwg-bounces@ietf.org Fri Oct 29 02:13: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 CAA25133 for ; Fri, 29 Oct 2004 02:13:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNQEq-00068I-Da for rtgwg-web-archive@ietf.org; Fri, 29 Oct 2004 02:27:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNPrQ-0007fg-DV; Fri, 29 Oct 2004 02:03:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNPp8-0004Wi-6j for rtgwg@megatron.ietf.org; Fri, 29 Oct 2004 02:01:18 -0400 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 CAA13354 for ; Fri, 29 Oct 2004 02:01:16 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNQ3K-0005rh-3x for rtgwg@ietf.org; Fri, 29 Oct 2004 02:15:59 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9T607606282; Fri, 29 Oct 2004 09:00:16 +0300 Date: Fri, 29 Oct 2004 09:00:07 +0300 (EEST) From: Pekka Savola To: Alia Atlas In-Reply-To: <5.1.0.14.2.20041028182916.01d9a360@pop.avici.com> Message-ID: References: <5.1.0.14.2.20041026214046.025625d0@pop.avici.com> <5.1.0.14.2.20041026214046.025625d0@pop.avici.com> <5.1.0.14.2.20041028182916.01d9a360@pop.avici.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Thomas Eriksson , rtgwg@ietf.org Subject: Re: Fwd: I-D ACTION:draft-atlas-ip-local-protect-uturn-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: 52e1467c2184c31006318542db5614d5 On Thu, 28 Oct 2004, Alia Atlas wrote: > My impression from the networks that I have analyzed is that most are very > close to 100% (average 98%) for coverage with u-turn and loop-free > alternates. For a few, I have explored the changes necessary to bring the > coverage to 100%; it has been a relatively minor modification. For instance, > the modification may be a link that was already planned, a slight > modification to a metric, or the like. > > Clearly, this is topology dependent, but I think that a topology need not be > substantially more dense than they are today. > > The purpose of u-turn alternates is to bring the coverage and network > engineering into that area. > > I am more than happy to analyze any topologies and report back the results. > These don't even have to be real topologies :-) Have such topologies been formally described? Or, with (sufficient number of) examples of topologies which are not supported, and the changes required to make them so? It would be useful for the operators to be able to figure out how their topology would act like? If we don't get 100% coverage, this exercise needs to be done sooner or later, and (IMHO) written in an RFC. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg