Re: Discovering IP address to use for uBFD sessions

Glen Kent <glen.kent@gmail.com> Thu, 20 June 2013 17:37 UTC

Return-Path: <glen.kent@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DA421F9F44 for <rtg-bfd@ietfa.amsl.com>; Thu, 20 Jun 2013 10:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vxxr0lhLou+J for <rtg-bfd@ietfa.amsl.com>; Thu, 20 Jun 2013 10:37:55 -0700 (PDT)
Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id EFC4521F9E57 for <rtg-bfd@ietf.org>; Thu, 20 Jun 2013 10:37:54 -0700 (PDT)
Received: by mail-oa0-f49.google.com with SMTP id n9so8395546oag.36 for <rtg-bfd@ietf.org>; Thu, 20 Jun 2013 10:37:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VNQWviETuRM5TVRk+L/wHiwnHQh0/HrhOOoZJXNErwU=; b=KJUty6hKvuIcu2nf0nifpH0VALuPXfl0l98z0BWeWDmYgnCVsQr3czJ5vVVb2x/spL /86ctIo6+L7u0oSnXW6ijTygBec77JE35P0kyAhrh5yvFJOwHCObn6rvIlX1FB1dGEHx 4B1neVsJiQpBoxK3/6lVmzhNoRRN+DZskBmmeSEoSiDIPWyIuY16x+1GJzeNecQ3wck7 3LIRIEJ3PjnLkl9xQ4zatZDQqv2fRGRgOQUgn/AYHLBiVp3/HlmZypFS/FxurzxUmytO 1eSm1k2B7b9skRnhs1IPy74IPqCly8k0ggPbKfB18sfTJLSLKCokHs091mpAqkXZ1XYG DMlw==
MIME-Version: 1.0
X-Received: by 10.182.205.138 with SMTP id lg10mr1959823obc.6.1371749468282; Thu, 20 Jun 2013 10:31:08 -0700 (PDT)
Received: by 10.182.214.68 with HTTP; Thu, 20 Jun 2013 10:31:08 -0700 (PDT)
In-Reply-To: <20211F91F544D247976D84C5D778A4C305CD89@SG70YWXCHMBA05.zap.alcatel-lucent.com>
References: <20211F91F544D247976D84C5D778A4C305CD89@SG70YWXCHMBA05.zap.alcatel-lucent.com>
Date: Thu, 20 Jun 2013 23:01:08 +0530
Message-ID: <CAPLq3UP5p+ms3e1780ZMemenT4ZVf=4G-VP++dHvNTdtX-zdVQ@mail.gmail.com>
Subject: Re: Discovering IP address to use for uBFD sessions
From: Glen Kent <glen.kent@gmail.com>
To: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="001a11c290b8c72b3e04df994f77"
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jun 2013 17:37:55 -0000

Hi Manav,

We did have a discussion around this more than a year back here:
http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01294.html

There clearly was interest in pursuing something like this.

I agree that we should have some mechanism to discover the remote IP
addresses.

Glen


On Thu, Jun 20, 2013 at 10:39 AM, Bhatia, Manav (Manav) <
manav.bhatia@alcatel-lucent.com> wrote:

> Hi,
>
> draft-ietf-bfd-on-lags is silent on how the IP address used for micro BFD
> sessions is derived/learnt/discovered.
>
> It wisely assumes that an out-of-band mechanism exists which arms the
> routers with the knowledge about the remote IP address that it must use to
> establish the micro BFD session.
>
> Some time back few of us wrote a short draft -
> draft-mmsn-bfd-on-lags-address-00, that describes how routers can
> obtain/discover remote IP addresses required for establishing uBFD sessions.
>
> I would like the WG members to go through the above draft and discuss
> whether we need a draft that describes alternate ways to discover remote IP
> addresses or can we all assume that the remote IP addresses MUST be
> statically configured.
>
> The problem with implicitly assuming that the remote IP addresses MUST be
> configured is that as more folks start implementing this, they would
> stumble upon this issue and would be left clueless on how the IP addresses
> have to be derived. In case the WG decides that its premature to work on an
> autodiscovery mechanism, I would still like us to publish a draft that says
> that addresses MUST be statically configured and an Appendix where
> alternate mechanisms are listed along with their pros and cons (mostly for
> the sake of posterity).
>
> Cheers, Manav
>
>
>
>
>