IETF Logo Mail Archive

Re: [pim] Some thoughts on draft-mirsky-pim-bfd-p2mp-use-case

Greg Mirsky <gregimirsky@gmail.com> Fri, 22 June 2018 00:22 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4586712E039; Thu, 21 Jun 2018 17:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 jIhs3LFbPVwB; Thu, 21 Jun 2018 17:22:03 -0700 (PDT)
Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 7FB7D12F18C; Thu, 21 Jun 2018 17:22:02 -0700 (PDT)
Received: by mail-lj1-x244.google.com with SMTP id h16-v6so634822ljg.4; Thu, 21 Jun 2018 17:22:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X3fdpHAbVXGZIwmU3Dvb1yNWWLbxaYq9WmWiZC+1GjE=; b=B6SlQvpOAQE4pmdVbNatJ0kKptJ+/URd6nWE004aDYy0gciTARpqd8lucg2GTYYp2g avAECE6LDRxyTrZ4eY/u3DLc9dm0NV6svfrqa54t97dWc7/4WUkkzipilEMIfg3y/Fmo Gu3QlPwpOA9gDtqwlvCXvoNnE+0jVlmA7M2b9KBih2a4kZrwlNa3aAaVMzJ2qSu+r8BY G4nv4i4hB2up3eUAx2dzClMFKRoPMjvRQS0xvzNVxByiOyvbLPJemlbCV1UGk2zN6LBn Z2G5LjNyLmwXEpDSuQMIgwkWtgwSUqET8vWbB3axX4lu5yAAT+5Vk8w7kbFX8eJ+pI6M RJXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X3fdpHAbVXGZIwmU3Dvb1yNWWLbxaYq9WmWiZC+1GjE=; b=uHXJQEbnPvBYRMeS/utj07WkDYP4DVeF3zyBgRRJtE7oHoLVNO4nII7Sg3AJIp/LbI 9eFkH+RjFoNMl0/Rd6SBALO73C78ZUf7tTSObOcKv3LzJQjHUigfrHxJvWcilt3N64J0 0TMbU7eKiUOHhWsX51IvcngO8f4c3gpYQfk+woSgcq4JPn7OWXbTsJ7N9vgyBJl5kkPm 6ptXhHvkoSCPwMP3TLPnVbNa8DH2tghyy82KCOA5BPTWYT7N/gpfxIFZexzcGGbiQwYg Y1oIgnz0yDmnMxlhZ2u9hTQtpTO/LjhkwQEMuwDa9k7SHIDbQyVyoWOXgauQwTsElbmu PX7A==
X-Gm-Message-State: APt69E0NFe0dZZNGLbpP+uvTkBuXKeRtIPr66ZKmvACkFo+c/Oj8/l+X nNQdQNIP1VAVUfclT9ZM96kmirxAcC7yvfBGYGw=
X-Google-Smtp-Source: ADUXVKL1XWS6aRlLDuk3xZqMNhVLUwHtMmGO4OESTFZMUdfK8U/F8O5Q7vakk4F0kehu+ZWB/v1iohmtNLHOLlrk6Fs=
X-Received: by 2002:a2e:c52:: with SMTP id o18-v6mr18379124ljd.72.1529626920625; Thu, 21 Jun 2018 17:22:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 17:21:59 -0700 (PDT)
In-Reply-To: <CAHANBtJMzViBO18tOstON4kQdcBfayyL1Ag9Pjn1A=3Q1QF+pw@mail.gmail.com>
References: <CAHANBtJMzViBO18tOstON4kQdcBfayyL1Ag9Pjn1A=3Q1QF+pw@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 21 Jun 2018 17:21:59 -0700
Message-ID: <CA+RyBmUCLY3YQmVBMWZ9TxDeVtWD4MKmq65f7Ou3cOFzr7uApA@mail.gmail.com>
To: Stig Venaas <stig@venaas.com>
Cc: pim@ietf.org, draft-mirsky-pim-bfd-p2mp-use-case@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003e2aad056f300571"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/lQhn0orTm-yWi0jSxRcqlVeGemU>
Subject: Re: [pim] Some thoughts on draft-mirsky-pim-bfd-p2mp-use-case
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jun 2018 00:22:06 -0000

Hi Stig,
thank you for taking interest in the proposal and the very detailed
questions. Please find my answers in-line tagged GIM>>.

Regards,
Greg

On Thu, Jun 21, 2018 at 1:44 PM, Stig Venaas <stig@venaas.com> wrote:

> Hi
>
> Posting as a WG participant.
>
> This looks useful to me and I believe it would scale better than the
> current use of p2p BFD for pim. Below are some questions I have.
>
> Unidirectional link failures
> I believe in pim we assume that if a link fails in one direction, it
> also fails in the other direction. Several things could go wrong
> otherwise. Is it sufficient to use BFD for discovering unidirectional
> failures? p2mp BFD seems to be only in one direction normally.
>
GIM>> Correct. The referenced in the draft p2mp BFD specification is
explicitly unidirectional and only a tail monitors the state of the head.
draft-ietf-bfd-multipoint-active-tail
<https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/>
defines
several options for the head to conclude whether the tail receives its BFD
control packets.

> However, if we need bidirectional, is it useful to have the head query
> the tails and see if it gets responses from all neighbors?

GIM>> The head to monitor tails? What the benefit would be in the case we
consider in the draft? Other scenarios? That will be interesting to look at.

> What should
> be the behavior if a failure is detected?

GIM>> The new DR will be elected.

> E.g. if a link is
> partitioned (in both directions), it is beneficial to have a DR in
> each partition.
>
GIM>> Interesting, haven't thought about that.

>
> BFD only for DR?
>
GIM>> We've discussed additional extenstion to Hello so that BDR may
bootstrap another p2mp BFD session on the link as its head.

> The draft currently assumes that it is only needed for the DR. Do we
> in pim need to detect other neighbors going down? I believe there are
> such cases. Even if one uses p2mp BFD for all pim routers, I believe
> it will scale better than the current full p2p mesh.
>
> Stig
>

v2.23.0 | Report a Bug | By Email