Re: IETF OSPF YANG and BFD Configuration

Jeffrey Haas <jhaas@pfrc.org> Tue, 20 June 2017 20:17 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 A0C181315C5; Tue, 20 Jun 2017 13:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 0h3cQc4NfA5D; Tue, 20 Jun 2017 13:17:49 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 186E6128B4E; Tue, 20 Jun 2017 13:17:49 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 1A20D1E37E; Tue, 20 Jun 2017 16:26:40 -0400 (EDT)
Date: Tue, 20 Jun 2017 16:26:39 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, "Acee Lindem (acee)" <acee@cisco.com>, Jeffrey Haas <jhaas@juniper.net>, OSPF WG List <ospf@ietf.org>, "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-yang@ietf.org" <draft-ietf-bfd-yang@ietf.org>, "draft-ietf-ospf-yang@ietf.org" <draft-ietf-ospf-yang@ietf.org>
Subject: Re: IETF OSPF YANG and BFD Configuration
Message-ID: <20170620202639.GF2289@pfrc.org>
References: <D5436DE8.AF5B7%acee@cisco.com> <38DEB571-2918-4464-B18A-71B24221772F@gmail.com> <47325462-2430-4197-AA8D-D3FEF74A834D@gmail.com> <D5438DD9.298FE6%rrahman@cisco.com> <20170619185715.GB22146@pfrc.org> <CA+RyBmWdd4bZ5j=9_HtB6ihuO2Bqgf13Yad68hnVL=hgOEBd+A@mail.gmail.com> <20170620190009.GA2289@pfrc.org> <CA+RyBmVMg0O=i8Nr_0ZMbeJRDdhPZYbxbGoscA2TysJHew4u_Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+RyBmVMg0O=i8Nr_0ZMbeJRDdhPZYbxbGoscA2TysJHew4u_Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/k_IBMRnjmkHOfr5E1Vuhaj5Ugyc>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 20 Jun 2017 20:17:51 -0000

On Tue, Jun 20, 2017 at 02:48:51PM -0500, Greg Mirsky wrote:
> Hi Jeff,
> thank you for the great summary of the discussion, helps me to catch the
> wave.
> I'm skeptical that there's realistic scenario where two BFD systems will be
> requested to run multiple BFD single-hop session between them over the same
> interfaces (logical or physical). I believe that we should try to make
> models future proof but to the level that is reasonable, practical.
> Approach "if we can think of it, then we need to support it" may not be the
> one.
> RE: RFC 5881. I've referred to the following:
> ... any BFD packet from the remote machine with a zero value of Your
> Discriminator MUST be associated with the session bound to the remote
> system, interface, and protocol.
> Unless we add out-band bootstrapping of BFD sessions like with LSP Ping, I
> don't see how received BFD control packet with zero value in Your
> Discriminator may be bound to not just any one of several protocols that
> are trying to run BFD session on the same interface to the same remote
> system but to the right one, the one that corresponds to the protocol on
> whose behalf remote BFD peer sent the control packet. Hence my question Do
> we have implementation(s) that use this and are asking for BFD data model
> to accommodate them? Or we are just doing interesting intellectual exercise?

The constant iteration regarding "intellectual exercise" is getting
irritating.  See prior comments.

This distribution is too large to try to design the actual behavioral
change.  If you feel the need to pursue that thread, please reduce the scope
of the cc: list.  This will be my last reply to this topic on the expanded
distro.

To offer one example of how such a thing could be implemented, BFD
authentication can be used with different parameters for each session.  This
provides the necessary split for demultiplexing.  Such a hack is not unusual
operations trick when running OSPF for (partially) disjoint domains on the
same interface, although I suspect that the hack is no longer necessary with
multi-instance techs.  (This trick goes back to the 1990's.)

-- Jeff