IETF Logo Mail Archive

Re: [Idr] comments on draft-ietf-idr-rs-bfd

Job Snijders <job@ntt.net> Tue, 01 August 2017 18:32 UTC

Return-Path: <job@instituut.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461F413226B for <idr@ietfa.amsl.com>; Tue, 1 Aug 2017 11:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_2T8UHyRc_9 for <idr@ietfa.amsl.com>; Tue, 1 Aug 2017 11:32:44 -0700 (PDT)
Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9845D1321F1 for <idr@ietf.org>; Tue, 1 Aug 2017 11:32:44 -0700 (PDT)
Received: by mail-wm0-f52.google.com with SMTP id t201so22469024wmt.0 for <idr@ietf.org>; Tue, 01 Aug 2017 11:32:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=hqhPr2V75AfLWsGIeaEbvc1tlf5TaMB9iofHrlXeMYs=; b=VZp5lryvZEIffx2AKH8tFttC7yrbwhrIrCnU2ypeWZ1qkH4Rw8EJy5eFomSQ3GoaFJ z92MEXHVvxjRMCAWmK6+FkSv2UgdCeMiWu6PWEm3sfskU/23LVtWn5q0j/lW4rGQs9D0 u3vziThEjTuiQpJDmmlh4PTSVpcGR76KlkUMkD9fVgoV/OKIp5gikUNU0hiWo606njVv mBCayVrc4e1DSYlgC/ffCtQUdytbcjYzqhIDl198lCPCbBVw4VV0wA1ziaIlzkAlsGW5 EWT5Lst+dvRpAFFr1DFqwL6huHo3D3lhDaejZIp5QI62gftuQSTG90gcFaFn8tBNf9HK SgpQ==
X-Gm-Message-State: AIVw112X3D7G7OIcd8se48N5Cavr10BMv90+FerW8uoMkvBmQ0hVqNq6 y7JuMMLgpv4h2w7n
X-Received: by 10.80.168.34 with SMTP id j31mr18617672edc.87.1501612362894; Tue, 01 Aug 2017 11:32:42 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:3dc6:a9a2:10ff:6f76]) by smtp.gmail.com with ESMTPSA id w26sm1156071edw.94.2017.08.01.11.32.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 11:32:41 -0700 (PDT)
Date: Tue, 01 Aug 2017 20:32:39 +0200
From: Job Snijders <job@ntt.net>
To: Robert Raszuk <robert@raszuk.net>
Cc: IETF IDR Working Group <idr@ietf.org>
Message-ID: <20170801183239.dxkw7twqn42jgggz@Vurt.local>
References: <59807D1E.4050807@foobar.org> <20170801133109.fdupuhfooudham5d@hanna.meerval.net> <CA+b+ERmoKAoLr_6yAHSyqJKBGANHxVJMF8am0UQqoDhid_+ziw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+b+ERmoKAoLr_6yAHSyqJKBGANHxVJMF8am0UQqoDhid_+ziw@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/WnkJnr5gSv-v850tjAyjydnFD34>
Subject: Re: [Idr] comments on draft-ietf-idr-rs-bfd
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Aug 2017 18:32:46 -0000

Hi Robert,

On Tue, Aug 01, 2017 at 04:50:27PM +0200, Robert Raszuk wrote:
> Not quite ... Nick is correct - next hop reachability are global in
> RS.  Sure each client may have his path in his view but this is not
> what will limit the next hop liveness decision.
> 
> See messages and suggestions from John on how to treat failures
> reported by N clients as something more important then failures of NH
> reachability reported by one or two clients. In both cases they would
> affect entire RS not only those clients views.

This surprises me. If clients A & B report that they can't reach Z, that
doesn't imply anything about whether C can reach Z. In such a scenario
would be somewhat counter-intuitive if the RS prunes all paths with
next-hop Z from C's Loc-RIB, based on a message from client A or B.

I think I would benefit from further elaboration on what the draft's
intentions are in this regard.

Kind regards,

Job

v2.23.0 | Report a Bug | By Email