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

Robert Raszuk <robert@raszuk.net> Thu, 16 March 2017 12:12 UTC

Return-Path: <rraszuk@gmail.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 7CDAC12945E for <idr@ietfa.amsl.com>; Thu, 16 Mar 2017 05:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level:
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 K6ALRuljwpt4 for <idr@ietfa.amsl.com>; Thu, 16 Mar 2017 05:12:50 -0700 (PDT)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 1E3F7129452 for <idr@ietf.org>; Thu, 16 Mar 2017 05:12:50 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id r45so35399186qte.3 for <idr@ietf.org>; Thu, 16 Mar 2017 05:12:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=T9IY911CtWSOk/nRUl8if+4+olpBfHzwYkKvC86pJyo=; b=ieo+j1Gw+CrIpgDr3hRwVaMCsjgVViNBvGr/VC7yzNC51VybNNAj5wSdRlqWlNfqbC RYxOT2yHsYvPsFpgrUa1saChaCwW8GBW6yxY9nkPPaYFczAlRbvGM1UlZqto4KcN84P8 NR1OVdIXkDW+lGwT2uR+BwgHvghOjKVkgapSsDIoGCllGMSf1vfjZZMgKFuPQpBW7YMz fdvIpsDjE8lfPBlajy2RPRgrlZxDf8Iew84SL/FxQizNojDoyvbtYE1sowJLQQZSXEC1 o2Z/GX9ro6QhS7mQ9JjwPiwlOpd8IjUprHpECy9aYxjf0G5yM5REA3R0b0XBVQpBOksr Ox5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=T9IY911CtWSOk/nRUl8if+4+olpBfHzwYkKvC86pJyo=; b=Ww+HGw28rMe0G6bdAHo5VeiB6pVLGB7i4VsYVCjav2YofszymeHF5EAuxhWT+eLmfH f6QHvXruAB8yHyLR8w/473CxD7pM8ZU4Ir3jVqrZyYD121arGmOuABdTNmOZFWrIrYLh 6YhqBRY0wzSui1GFuqdsAurLI5o9283e/qyBBqOmqofg3lN7HUhnHMqbqfkMajEP1xDc ViYVp7/F2I3NK8GoyVbrxdns/4yj4nDukG1soBC7KJaTgHto8M78Dj2/YS2ocKgo0zWY 4efPzITe6G0Ta0k6HnTaoyOnqsnpiBtKh0MCPoTEY1HthvQnwzF66bdNX0EYHkiQMANf 3OnA==
X-Gm-Message-State: AFeK/H0SJ3YH88DvxPvNw0BNCvxIw5hXACNoJPgEi1OvOAvjkMux6VcAMB06j+ew7kR7OoJ/yEy+Gt2SgmKvpg==
X-Received: by 10.200.3.81 with SMTP id w17mr7522332qtg.36.1489666369133; Thu, 16 Mar 2017 05:12:49 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.42.181 with HTTP; Thu, 16 Mar 2017 05:12:48 -0700 (PDT)
In-Reply-To: <20170316100444.GJ2367@Space.Net>
References: <CA+b+ERmWUL-pVwjW8Vq+Vz8UzYDpcVBZxxhtM6WFqhmG+r35WA@mail.gmail.com> <58C95A05.3030107@foobar.org> <20170315195050.GT12864@pfrc.org> <CA+b+ERn-uya3kB-FgXvfFjdK-hPmj-W-mv_T+TnbEAfkzR8Hfg@mail.gmail.com> <20170315212656.GD2367@Space.Net> <CA+b+ER=MnejDq5JNyNUHvf7mV7vkFehbeE65a_5cqFUsTEAzZA@mail.gmail.com> <CACWOCC-gAPbV0fdraHkkjhSo=Tc_YUFWMTOjx311a2XDJZMDmQ@mail.gmail.com> <CA+b+ERmxQkH75tbotT16hsZvqrvMVsX0G_zyY1ofA=kTZZzZ0w@mail.gmail.com> <20170316073753.GE2367@Space.Net> <CA+b+ER=92wsFQefzw=R6myCeSXfhsPiL3UgHiZ0mcMpsHHTwnQ@mail.gmail.com> <20170316100444.GJ2367@Space.Net>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 16 Mar 2017 13:12:48 +0100
X-Google-Sender-Auth: UU_HuE9nwAu66z6sBaUqCLhe5WU
Message-ID: <CA+b+ERkUeX6zd=UmqT_yYyQQf6jbhg9maz76v4pPhkJZNwDyvg@mail.gmail.com>
To: Gert Doering <gert@space.net>
Cc: Job Snijders <job@instituut.net>, idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary=f4030435b7e0c429d8054ad7fa7c
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Bn_Ujc2Wdi4nnRmlj-CcRc6ATRc>
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: Thu, 16 Mar 2017 12:12:51 -0000

>
> Oh, I can, and I can tie other stuff into it (like, static routes).  But
> does *BGP* know, and invalidate its nexthops, if object tracking tells
> it "does not ping anymore"?  Can I tell BGP "please run this automatically
> for all nexthops seen on this interface"?
>

​You can today say run it for all the peers which match a route map. It is
just a little extension to BGP Next Hop Tracking feature (which already
have table of all next hops) to actually also automate tracking next hops.

In fact one customer in the past requested that already .. but I don't know
if this was implemented in IOS already. I am sure folks from C vendor will
tell us :)​


> Manually configuring this for each peer address I *might* receive over the
> RS is operationally insane - 600+ devices on DECIX, with next-hop addresses
> I might not even know about until I receive a route for it, from the RS.
>

​No manual stuff.

All you need is a single knob which will force only /32 next hop for
resolution (already available) + do the tracking for all next hops received
over given eBGP peer. ​

This is why I'm asking for "do we have a document to point vendors so,
> so this magic would be available for me to use"?
>
> Until then, the proposed draft is a good start.
>

​The feature request is one liner stated above. I am not sure if IETF
document is needed for that​. IMHO it is more of topic for Nanog/RIPE.

This is rather very much implementation specific.

Cisco will tell we will extend object + next hop tracking, Juniper will do
nice trick with rib-groups, linux based vendors will recommend to base nh
liveness detection based on arp tracking which is already in all linux
kernels.

The fundamental question is should it be unidirectional (no session
established of any sort between any to any) or we would like to keep the
state associated with tracked object (BFD, symmetric or asymmetric
echo/seamless etc ...).

​r.​