Re: I-D Action: draft-ietf-rtgwg-ordered-fib-07.txt

Saku Ytti <saku@ytti.fi> Sat, 08 September 2012 08:35 UTC

Return-Path: <saku@ytti.fi>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A80321F8680 for <rtgwg@ietfa.amsl.com>; Sat, 8 Sep 2012 01:35:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPNchJw3Xl0W for <rtgwg@ietfa.amsl.com>; Sat, 8 Sep 2012 01:35:29 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE1B21F8671 for <rtgwg@ietf.org>; Sat, 8 Sep 2012 01:35:28 -0700 (PDT)
Received: by iabz21 with SMTP id z21so317801iab.31 for <rtgwg@ietf.org>; Sat, 08 Sep 2012 01:35:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=A0kn2yjIMzTVlsUAhPFULbDAx6oe0ceHPRWJUc0KNIk=; b=HTv64Tlo65TPB6ATiydOu9zBHkZu14xxmJuEhFQZXwK2eSqjg4VJDOqExW0FQXUjur 6Yjrgn4J2FAlUGBcDhS5wLNW/vYraUfyHP6Cpp22xeCBxqexU0CVkdDnlQdQMNrPnRzF pGQSfiTwglvZV4J2Vo5W36Wp4+/VsZqHfQ6L/M7oShPcp4zmcKY6osTm8+UPPDEQ33EA JOu5L+d8X+YaI302/RgQnVZ1XDHF3Q3p6a8RDwpuSQ58sgN9XjtuGL0ioNY7uK0R83sZ MlUvWt5oh7O4V4DOZa4wHRljsSooAGdYcxgOGjMUlvDAp3B03KYV2b93NIYkPI8m/IJd sH2g==
MIME-Version: 1.0
Received: by 10.50.94.195 with SMTP id de3mr1568483igb.68.1347093328001; Sat, 08 Sep 2012 01:35:28 -0700 (PDT)
Received: by 10.64.81.138 with HTTP; Sat, 8 Sep 2012 01:35:27 -0700 (PDT)
In-Reply-To: <20120907174057.6594.46348.idtracker@ietfa.amsl.com>
References: <20120907174057.6594.46348.idtracker@ietfa.amsl.com>
Date: Sat, 08 Sep 2012 11:35:27 +0300
Message-ID: <CAAeewD-DJ6GMp2KdBZmfoK62U=AMbgUg6oeHgNjXfWWSit=kpg@mail.gmail.com>
Subject: Re: I-D Action: draft-ietf-rtgwg-ordered-fib-07.txt
From: Saku Ytti <saku@ytti.fi>
To: rtgwg@ietf.org
Content-Type: text/plain; charset="UTF-8"
X-Gm-Message-State: ALoCoQmrHjfQTGivWRkM8I3mN0VqUxZIQTtEVjVMD05I3K+u3ikhosTbXXOfvpCdAWkoLyH9ZL3c
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Sep 2012 08:35:29 -0000

I'm confused.

'2. Introduction' says this:
---
The mechanisms that are used in the
   failure case are exactly the same as those used for managed changes.
   For simplicity this document makes no further distinction between
   managed and unplanned changes.
---

Does this imply, this is as useful in failure cases as it is in
managed changes?


I understand why it would be useful in managed changes such as metric
changes or artificially delayed interface shut. But I don't understand
how this can do any good in unmanaged change.

Domestically my network is 5ms long, it takes me 10ms on fastest
available modern route engine to calculate SPF change. I flood LSP
immediately before calculating SFP. So before I've finished
calculating SPF on local-to-fault router, furthest domestic node has
already been busy calculating it it for 5ms and is 5ms from finishing
it?
Non-domestic routers would not cause loop,, regardless or not if
they've changed FIB.

Wouldn't I double my delay, in the best scenario? As I'm waiting for
permission to update my FIB and I'm bound by network delay not only to
propagate LSP from up->down but to propagate permissions from
down->up?
So essentially I'm trading short transient loop to significantly
longer packet loss (remember, using the old topology will cause packet
loss, as link is already down).

I'm probably not understanding this right. If this feature should also
provide help in failure cases, would it be possible to have step by
step description for both cases normal and oFIB? In terms of what
happens millisecond to millisecond? (In same topology, where each link
has described millisecond, each router described time to calculate SPF
and each router described time to update FIB after SPF).

Thanks,
On 7 September 2012 20:40,  <internet-drafts@ietf.org> wrote:
>
> 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           : Loop-free convergence using oFIB
>         Author(s)       : Mike Shand
>                           Stewart Bryant
>                           Stefano Previdi
>                           Clarence Filsfils
>                           Pierre Francois
>                           Olivier Bonaventure
>         Filename        : draft-ietf-rtgwg-ordered-fib-07.txt
>         Pages           : 25
>         Date            : 2012-09-07
>
> Abstract:
>    This document describes a mechanism for use in conjunction with link
>    state routing protocols which prevents the transient loops which
>    would otherwise occur during topology changes.  It does this by
>    correctly sequencing the forwarding information base (FIB) updates on
>    the routers.
>
>    This mechanism can be used in the case of non-urgent link or node
>    shutdowns and restarts or link metric changes.  It can also be used
>    in conjunction with a fast re-route mechanism which converts a sudden
>    link or node failure into a non-urgent topology change.  This is
>    possible where a complete repair path is provided for all affected
>    destinations.
>
>    After a non-urgent topology change, each router computes a rank that
>    defines the time at which it can safely update its FIB.  A method for
>    accelerating this loop-free convergence process by the use of
>    completion messages is also described.
>
>    The technology described in this document has been subject to
>    extensive simulation using real network topologies and costs, and
>    pathological convergence behaviour.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ordered-fib
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-rtgwg-ordered-fib-07
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-ordered-fib-07
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



-- 
  ++ytti