draft-ietf-rtgwg-microloop-analysis-00.txt]
Srinivas Akkipeddi <akkipeddi@gmail.com> Wed, 03 August 2005 14:23 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0K9K-0008UI-QA; Wed, 03 Aug 2005 10:23:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0K9J-0008TP-5H for rtgwg@megatron.ietf.org; Wed, 03 Aug 2005 10:23:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21249 for <rtgwg@ietf.org>; Wed, 3 Aug 2005 10:23:11 -0400 (EDT)
Received: from rproxy.gmail.com ([64.233.170.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Kfz-0003oi-PP for rtgwg@ietf.org; Wed, 03 Aug 2005 10:57:00 -0400
Received: by rproxy.gmail.com with SMTP id i8so153843rne for <rtgwg@ietf.org>; Wed, 03 Aug 2005 07:23:11 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=B7Xi6X6TpUSLPF/KcG4Oe4WVZ3L8Trkoagf4rDI7isaynQSXh95BUis4JlbEFnYkHLkOFoFm7upMFPp1O8kX5eL6Xtq87EVmvwRsSmrWIS7/tIce21w2ZvYaUxpSpYa23TsLablzknnKFzSoZ135ZlmlIsJlbnFxq2DIwtv4OVQ=
Received: by 10.11.88.52 with SMTP id l52mr3033cwb; Wed, 03 Aug 2005 07:23:10 -0700 (PDT)
Received: by 10.11.116.18 with HTTP; Wed, 3 Aug 2005 07:23:10 -0700 (PDT)
Message-ID: <b67282bd050803072327ed0a2c@mail.gmail.com>
Date: Wed, 03 Aug 2005 10:23:10 -0400
From: Srinivas Akkipeddi <akkipeddi@gmail.com>
To: rtgwg@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: quoted-printable
Subject: draft-ietf-rtgwg-microloop-analysis-00.txt]
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: rtgwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
Sender: rtgwg-bounces@ietf.org
Errors-To: rtgwg-bounces@ietf.org
Alex, In the draft under the IP-FRR section it is mentioned that the affected router where the failure has occured need not hold down the route (install it without any delay) if it does not have any alternate and the new primary next-hops do not satisfy the safety condition, and there's no other neighbor that does, i.e. a type-C situation. I would suggest that this should hold good irrespective of whether a router supports IP-FRR or not. That is not having an alternate is the same as not supporting IP-FRR. Also there should be a discussion about whether the affected router in the above scenario should discard the traffic (which would be the case if it does not install the route since it is Type-c) or to go ahead and perhaps cause a microloop (by installing the route without any additional delay). I would suggest to NOT special case the affected router and in the above scenario, since it is type-C situation, install the route after delay_typeC. Thanks Srinivas Akkipeddi Avici Systems. _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg
- draft-ietf-rtgwg-microloop-analysis-00.txt] Srinivas Akkipeddi