IETF Logo Mail Archive

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

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Tue, 14 March 2017 21:11 UTC

Return-Path: <rajiva@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 CDE5513153A for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 14:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.623
X-Spam-Level:
X-Spam-Status: No, score=-12.623 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 psu5YOL-8lvJ for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 14:11:22 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244F7131547 for <idr@ietf.org>; Tue, 14 Mar 2017 14:11:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3438; q=dns/txt; s=iport; t=1489525882; x=1490735482; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WyPgAFGQUBALJHsNj633KfZfCXkUp3l+tI/NowCP87U=; b=FEARQ13eyFpwIEA2noOI3Jky2416uLJVZJbf/VU+BwUIsfo+wTfMB3V4 3Mjjmz70aR1cCoLXSghjgsv71ZlWcgR5moZDOikLnJXpSTWXBNI1nfwg8 35nOeWlz+eGlpVr5VSoPal8h6C3y4IdbuE/rO4RvV7nkDJv+7ZSEg/bdl 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CjAQBUW8hY/5NdJa1dGQEBAQEBAQEBAQEBBwEBAQEBg1FhgQoHg1mKDZFVlTyCDh8NhXYCGoI+PxgBAgEBAQEBAQFrKIUVAQEBAQIBAQEhEToLBQcEAgEIDgMDAQIBAgImAgICJQsVCAgCBAENBYl4CA6tXIImil0BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUOCBYJqhD6DHC6CMQWGaZVaAYZ1hk2EeJElk0YBHziBBFgVQREBhEUdgWN1hncrgQOBDQEBAQ
X-IronPort-AV: E=Sophos;i="5.36,165,1486425600"; d="scan'208";a="218547241"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2017 21:11:21 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v2ELBLZk017045 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Mar 2017 21:11:21 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 14 Mar 2017 16:11:20 -0500
Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Tue, 14 Mar 2017 16:11:20 -0500
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>, Robert Raszuk <robert@raszuk.net>
CC: idr wg <idr@ietf.org>
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt
Thread-Index: AQHSmnRjZQMhW6yq5kum3Hd4lOeZoKGSjLmAgABQ7oCAAAtWgP//sAtXgAKMygCAAADqAIAABbgA//++dAA=
Date: Tue, 14 Mar 2017 21:11:20 +0000
Message-ID: <C398F5EF-6AF6-492E-8A9A-3533D09DA964@cisco.com>
References: <CA+b+ERmmqtUkJMtfOE9ABFHN0gNdztjOGELmirNgWRnDENrjaA@mail.gmail.com> <58C6751D.60306@foobar.org> <CA+b+ERkxvKzArYf7eefB5UL_kDMVBJERz=Qyi=zOsBm3KivAtg@mail.gmail.com> <CA+b+ERn5o-i-6shdzj_afa8Z1yQO3Ep6HmB=Fv4StSW_ge95Ew@mail.gmail.com> <CA+b+ERkBeBoz0Le4wgqZK1X76=_HKOEUYTWYBd_xnjYoaJgrsw@mail.gmail.com> <CA+b+ERnBL9Q3ep1JrC9HQp3B3AYmiQ8ctTssK1g4L_ueTTRaMQ@mail.gmail.com> <CA+b+ER=cZiBfWj4=+uKeqsWwypGFz3p+Tvx8Q2dD3hFFXSC4=w@mail.gmail.com> <CA+b+ER=f-S118JtY--n-B0P+CB0yvy_rw3JaJpWw02n7prQ=Ww@mail.gmail.com> <20170314204212.GD12864@pfrc.org> <CA+b+ERk3S_eZrE+r7jE7toNmLrm7r4H8cW=64kyhv1UFQruiGw@mail.gmail.com> <20170314210555.GG12864@pfrc.org>
In-Reply-To: <20170314210555.GG12864@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.18.255.108]
Content-Type: text/plain; charset="utf-8"
Content-ID: <F60B42E2DE77C24E86A4A348908B5E3A@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Yk4_CMMCTJXo8AVk0IQ6mrsm3Co>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.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: Tue, 14 Mar 2017 21:11:24 -0000

>    For third party nexthops, you can have persistant bad forwarding.  Normal
>   BGP procedure doesn't help you here.

Agreed. Unless BGP bestpath selection considers (event-driven) NH liveliness check, the blackholing problem would continue.


-- 
Cheers,
Rajiv 

https://tools.ietf.org/html/draft-ietf-idr-bgp-bestpath-selection-criteria-06


-----Original Message-----
From: Idr <idr-bounces@ietf.org> on behalf of Jeffrey Haas <jhaas@pfrc.org>
Date: Tuesday, March 14, 2017 at 5:05 PM
To: "robert@raszuk.net" <robert@raszuk.net>
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt

    On Tue, Mar 14, 2017 at 09:45:28PM +0100, Robert Raszuk wrote:
    > In fact to me this is basic 4271 as you should not use a path (even single
    > path) if you can not validate if the next hop to it is reachable.
    > 
    > I think we all in BGP did not pay that much attention to reachability on
    > multiaccess LANs ​as most peering happens on p2p links where the same
    > problem does not happen.
    
    For first party nexthops, BGP timers can address this to some extent.
    
    BGP timers are too long, hence BFD.
    
    For third party nexthops, you can have persistant bad forwarding.  Normal
    BGP procedure doesn't help you here.
    
    So, we agree that the case isn't given good attention in the core specs.
    
    > > The one "common" use case where this may be of benefit outside of a
    > > route-server environment is BGP "VPNs" that are constructed using IPSEC
    > > tunnels with the network effectively an NBMA subnet.
    > >
    > 
    > ​See all SD-WANs today need more then one path such that they make
    > forwarding decision by probing all alternative overlay links and based on
    > the applied logic switch over to better or lower cost or less delay path.
    > If you give them just single path this is all no longer possible. That is
    > what worries me in this the most if you would like to utlize this new NH
    > NOTIFCATION SAFI for WAN VPNs.
    
    The new SAFI is targeted specifically for the RS case and hasn't received
    specific consideration for other use cases yet.  Feel free to kick off that
    as a topic, although I'd suggest doing so separably from the rs-bfd thread.
    
    -- Jeff
    
    _______________________________________________
    Idr mailing list
    Idr@ietf.org
    https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email