IETF Logo Mail Archive

Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Thu, 06 July 2017 04:04 UTC

Return-Path: <jheitz@cisco.com>
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 526B01243FE for <idr@ietfa.amsl.com>; Wed, 5 Jul 2017 21:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 8QxkcUz2WAKg for <idr@ietfa.amsl.com>; Wed, 5 Jul 2017 21:04:43 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29BEC126DCA for <idr@ietf.org>; Wed, 5 Jul 2017 21:04:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10842; q=dns/txt; s=iport; t=1499313883; x=1500523483; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CyQCXdwS0Va76nQs1BuD4TiOn9twWxIXlgbIvfQppuQ=; b=jYLSmiXiSEZnS2aToq/ek9WSE5/Oz2KnzprY/ZJ11S4SS2P54GOMRL93 qmNtP/etjZnsVZXCzFdZb63+kk8VbIrYx/1Bnp+lBwiv4k1tqGVIA6dtf M8z2h4hDpl3Q7Zh+abSDhMZZ8Upy5A10GrOHZwuC1jyQbq8UtL6gFQKys c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CjAAB2tV1Z/5JdJa1cGQEBAQEBAQEBAQEBBwEBAQEBgm9qY4EQB44CkWiQV4UsghGGHAIagwI/GAECAQEBAQEBAWsohRgBAQEBAyMKTBACAQgOAwQBASgDAgICMBQJCAIEDgUIiUNkr2iCJotGAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYMng0yFBYUggl2CYQWXLIdfApN6ghWJO4ZXlTUBHziBCnUVhVwcgWYBdod2gQ0BAQE
X-IronPort-AV: E=Sophos;i="5.40,315,1496102400"; d="scan'208,217";a="450199195"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2017 04:04:42 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v6644gdU019822 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Jul 2017 04:04:42 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Jul 2017 23:04:41 -0500
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Wed, 5 Jul 2017 23:04:41 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: John Scudder <jgs@juniper.net>
CC: idr wg <idr@ietf.org>
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt
Thread-Index: AQHS9BUunfHRezzCokubhqS6qWLW+qJCmLwAgAADHACAAAV9AIAAEJgAgAAELwCAACXgAIAABdiAgAAGlwCAAAS/gIAAAluAgAADsICAAAI9gIAABIMAgAAG2ACAANELAIAAVbOAgAGER4CAABuWgIAACY6A///raUCAAL0bAP//txnA
Date: Thu, 06 Jul 2017 04:04:41 +0000
Message-ID: <696fbda3aa2b4af9b0fc8f4757e7b541@XCH-ALN-014.cisco.com>
References: <20170703175308.hembxkplaniz66wb@Vurt.local> <m2van9z3jp.wl-randy@psg.com> <CACWOCC8tPVD20SJ60h-=NGbPMG3Fae2a0TY5rMFb=EnN7H-C6Q@mail.gmail.com> <m2o9t1z1hj.wl-randy@psg.com> <CACWOCC_bQitHeR9tHc5tPsXmoSDDLQH764equTAHrP854fYh-A@mail.gmail.com> <BF65C4DC-D2F5-41AF-8454-D43B403E328B@juniper.net> <CACWOCC9cmz7ARnWNowCCEu3Rt_NiyuWgJMZ3pWfmxZ_BO8Ovjw@mail.gmail.com> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <CACWOCC_KTzJLQAJf_j4ZqM1oJSFq9JcyT7aAPLGf3+2Ess7BBA@mail.gmail.com> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net> <CA+b+ERmJRbhwa5Eut4+KwxqmAcaBM3fSvL1-zjrxBfZur6QxjA@mail.gmail.com> <1FD8FAE9-E6BF-4C48-BCD6-12C1012827E2@juniper.net> <CA+b+ER=eYJN1HXa+buCB7kR+Byt0iWH6-a20VJ5DjzbQEJrhKQ@mail.gmail.com> <d9d07382674b4ea5b513a3608b6bd85a@XCH-ALN-014.cisco.com> <F55CBE76-FD1D-462D-993A-F2E88E9F3184@juniper.net>
In-Reply-To: <F55CBE76-FD1D-462D-993A-F2E88E9F3184@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.54.193]
Content-Type: multipart/alternative; boundary="_000_696fbda3aa2b4af9b0fc8f4757e7b541XCHALN014ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jzQyqfTI9T2ppW0mOkWef_-dwFs>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt
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: Thu, 06 Jul 2017 04:04:45 -0000

The reason you need this nexthop address family is to know
which nexthops are unreachable, no?
So that you can send a path other than the best path, no?

I said non-best.

With add-path, you get the non-best up front, so when
connectivity to the best is broken, you already have the alternative.

Thanks,
Jakob.

From: John Scudder [mailto:jgs@juniper.net]
Sent: Wednesday, July 05, 2017 8:21 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt

On Jul 5, 2017, at 5:13 PM, Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>> wrote:

With the nexthop address family, when BGP starts,
before the non-best paths will be sent,
 . the RS has to send all the nexthops,
. the client has to set up all the BFD sessions and
. the client has to send all the nexthop reachability info back to the RS.

If you read the draft carefully you'll see this is not the case. Unreported nexthops are specified as having implicit state "unknown" which is eligible for selection.

--John

v2.23.0 | Report a Bug | By Email