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