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

Robert Raszuk <robert@raszuk.net> Mon, 13 March 2017 10:45 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 7AEE612954B for <idr@ietfa.amsl.com>; Mon, 13 Mar 2017 03:45:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 hLcA-Yvt4dz9 for <idr@ietfa.amsl.com>; Mon, 13 Mar 2017 03:45:27 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 6C04F1293FD for <idr@ietf.org>; Mon, 13 Mar 2017 03:45:27 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id v125so214540221qkh.2 for <idr@ietf.org>; Mon, 13 Mar 2017 03:45:27 -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=Fbj2vdUUvGRCx0suHoj9Y3cnlsecO7CCuhIRopz3Akc=; b=fRqL6bx260N+rgHshpFeNYW2PquqfkNMkqNAFZimBG3FH/lTIQqmBYnj3TRkNIssqy lS3NHIVnEgCchaQkr+5/+xqWTRgXHLDKeWJWoDx2e4zABjrUFyZ0vopeb4vHimjqpkdQ 4jdsOHFEHD2AUas/PTaCNJpr+CSTiwaXdK46rnuQyV7pKZUBBpGL2YNOYlGjR4xoKSQH jpAV1Yq3SqQ7GjE9kS63NeIckcEvjw+MVOA/3Lh9fW48DD6wF+DCzba4IikuNdYnskAv zotBUCrzpiyGn7m1vgSJnVdULsoaXqGHFjiTlA3suo6o8UdRR8+D0ic1x56Okfr+hRXm HBQw==
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=Fbj2vdUUvGRCx0suHoj9Y3cnlsecO7CCuhIRopz3Akc=; b=qThHCfpqz7dPRz5a5uOcU0ObSg1RVxvmdxHen9sY1Gy6fh/sDc+3zD2mzIRKHdf/ig J3PalSijp7Qhbgco8SdP8HGNkGNW3KU3wvc5EOaHShKgmHgEFF6JeuPOMpwTNsgHXUeY /xRB4tgjV6Q9f+i3cnKNAXBSU9QRH4frhTUHk0LaTh+6/wP6kchDidyTGQ1y/eHqa+q3 6CPupEOsWCepGPDvEWGVn6OGWu7wdO1m0YheOH1nxlbsdlZ6meiraAV9AHdyF0lNb+Cu QbEoy7zzLjzhA4rlydEXlUQ7i1WMyZEyXfeW3tyHUEp4r/A4IUdtY0Tu90PEwpupdskg P+fg==
X-Gm-Message-State: AFeK/H0SgVx+EDOr3TNDzQ3NA+shewJuAXX0fdVRb8IS75yu+K1UEScGNDIKxLdt+aymldfu92ECwMn6ORtEtQ==
X-Received: by 10.55.65.136 with SMTP id o130mr29516845qka.168.1489401926559; Mon, 13 Mar 2017 03:45:26 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.42.181 with HTTP; Mon, 13 Mar 2017 03:45:25 -0700 (PDT)
Received: by 10.140.42.181 with HTTP; Mon, 13 Mar 2017 03:45:25 -0700 (PDT)
In-Reply-To: <CA+b+ER=cZiBfWj4=+uKeqsWwypGFz3p+Tvx8Q2dD3hFFXSC4=w@mail.gmail.com>
References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <m2k27tzs5k.wl-randy@psg.com> <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>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 13 Mar 2017 11:45:25 +0100
X-Google-Sender-Auth: hDHcQDkRdYsV-PkbWECLPGb9jig
Message-ID: <CA+b+ER=f-S118JtY--n-B0P+CB0yvy_rw3JaJpWw02n7prQ=Ww@mail.gmail.com>
To: Nick Hilliard <nick@foobar.org>
Content-Type: multipart/alternative; boundary=001a11488ce4c2b3af054a9a6829
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/84yPL_XmdtrAy1YqstkalNlpEg4>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 13 Mar 2017 10:45:29 -0000

Nick,

I am afraid you have completely missed my point.

I never said clients must not detect other clients liveness before using it
for best path selection and in their local data planes.

I said RS does not need to bothered with that information.

In fact I explicitely said that modern clients will detect health of the
path well beyond local peer's next hop.

Cheers,
R.


On Mar 13, 2017 11:32 AM, "Nick Hilliard" <nick@foobar.org>; wrote:

Robert Raszuk wrote:
> Let's observe that the ultimate objective of this draft (and in fact
> much more) can be achieved by assuring that clients receive more then
> one path to given bgp destinations at normal operation.

This is a fundamental misunderstanding.  The aim of this draft is to
ensure that traffic isn't blackholed if there is a layer 2 incongruity
on the IXP which causes connectivity to be non commutative.

Given the following topology, A's connectivity to RS works fine, and B's
connectivity to RS works fine, but A cannot communicate with B:

>    +-----+    +-----+
>    |     +--> |     |
>    |  A  |    |  B  |
>    |     | <--+     |
>    +-----+    +-----+
>       |           |
>       | +------+  |
>       +-+      +--+
>         |  RS  |
>         |      |
>         +------+

What's needed is some protocol running between A and B to ensure that
they can still talk to each other, i.e. BFD.

No amount of alternative paths will save you in this situation because
the control plane (RS) has connectivity to both data plane routers.

Nick

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr