Discovering IP address to use for uBFD sessions

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Thu, 20 June 2013 05:09 UTC

Return-Path: <manav.bhatia@alcatel-lucent.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 8238E21E80AA for <rtg-bfd@ietfa.amsl.com>; Wed, 19 Jun 2013 22:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 JFp-JVt6JFjF for <rtg-bfd@ietfa.amsl.com>; Wed, 19 Jun 2013 22:09:41 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id CDBCC21E80A5 for <rtg-bfd@ietf.org>; Wed, 19 Jun 2013 22:09:40 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r5K59dWa005718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <rtg-bfd@ietf.org>; Thu, 20 Jun 2013 00:09:40 -0500 (CDT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r5K59a2p023495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <rtg-bfd@ietf.org>; Thu, 20 Jun 2013 01:09:39 -0400
Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 20 Jun 2013 01:09:38 -0400
Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.102]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Thu, 20 Jun 2013 13:09:36 +0800
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Discovering IP address to use for uBFD sessions
Thread-Topic: Discovering IP address to use for uBFD sessions
Thread-Index: Ac5tdDETAmKspDYfSSikTZOUmS4kEQ==
Date: Thu, 20 Jun 2013 05:09:35 +0000
Message-ID: <20211F91F544D247976D84C5D778A4C305CD89@SG70YWXCHMBA05.zap.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-cr-puzzleid: {21DAE84E-15C6-4876-BBEE-929E5C87EE02}
x-cr-hashedpuzzle: a7g= A++A BEhP BPia Bw9B CYOm C/DT Doij D6Mj FApe FFlr Gqkj JJSO JgPi Jo9q J7NI; 1; cgB0AGcALQBiAGYAZABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {21DAE84E-15C6-4876-BBEE-929E5C87EE02}; bQBhAG4AYQB2AC4AYgBoAGEAdABpAGEAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA=; Thu, 20 Jun 2013 05:08:24 GMT; RABpAHMAYwBvAHYAZQByAGkAbgBnACAASQBQACAAYQBkAGQAcgBlAHMAcwAgAHQAbwAgAHUAcwBlACAAZgBvAHIAIAB1AEIARgBEACAAcwBlAHMAcwBpAG8AbgBzAA==
x-originating-ip: [135.253.19.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
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 05:09:48 -0000

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