Re: IETF OSPF YANG and BFD Configuration

Greg Mirsky <gregimirsky@gmail.com> Tue, 20 June 2017 17:56 UTC

Return-Path: <gregimirsky@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 75F58129484; Tue, 20 Jun 2017 10:56:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 0S626UVNUs-6; Tue, 20 Jun 2017 10:56:00 -0700 (PDT)
Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (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 E6B37131596; Tue, 20 Jun 2017 10:55:59 -0700 (PDT)
Received: by mail-ot0-x22e.google.com with SMTP id s7so95520212otb.3; Tue, 20 Jun 2017 10:55:59 -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=BENHcUVlEoXJg1Erg+OcNgztKg0R+1/VcaUBHrkPvys=; b=IwzS85eGF7Pig0Xs2Al6ESdSep2G6ERUUwUyV8QpR1Cw+wJO9dFstaTbTnjM+XiAxk HTy1XBOUfjvTGfVwvjD9L+BDXS2Tnq3FWvB+NIxxpFUjhhxC+7nq0zK9qs0sC5+FfM5F /uIsFcLqcWaQzG4BytL7vhfvVcA/z2ejVShZtTdLPDp0uRcJwFhroXwgZLCG77Kr9MJt DLfUt0WhPRZSpK3aLznFIPhsXsDMUM3s+Q08j8lX/eSMcVAxf8akqtOL37XTihayEqwI 7oPz7g2m/Pxi7MO3TpkHw7e1w6b+hfEB+iElzABZrSV0fiH9WFCEZq4yGKFamD9v/FY1 F8PA==
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=BENHcUVlEoXJg1Erg+OcNgztKg0R+1/VcaUBHrkPvys=; b=YbAZysMXEwrN1ApDw9N+4SBhrtPiHd0/os1VlsPQ1X7jtkVC27BSY/BdY31NMxKlu6 G+Zf07y//XK5CpO1W4knQg2WIIyvRI5sJEV7CksuUKxmty7hfKgZi7qCnm+V1h1XMWjQ CL98v5+OWYbSS65KSslsVhnTjtXrUzUS6ZUXylZx3NuqmNnyCGEwi2KS7DXRRICwM80w Ztq3yl8c9PBmPITEZoZgKZcxayl2IjpZI1hnQZ+yzGnQf5V2+mfCPqsibxz5dpMnY+zH bFnCPGe7kAEg6OxSJxwtxJapuNa4WSbk/miNUw6dSQAVZfPfl46Et5quEr8OTfGi96dr NExQ==
X-Gm-Message-State: AKS2vOwFj0znWv6Xrg83GgIvSbj2f/6XS+JEsgW/lT7q8xHmO2w2MiPr SfSNpo9gEJiPoxDJKxNBYcBUpUdgVQ==
X-Received: by 10.157.22.205 with SMTP id s13mr1215827ots.240.1497981359270; Tue, 20 Jun 2017 10:55:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.52.171 with HTTP; Tue, 20 Jun 2017 10:55:58 -0700 (PDT)
In-Reply-To: <20170619185715.GB22146@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>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 20 Jun 2017 12:55:58 -0500
Message-ID: <CA+RyBmWdd4bZ5j=9_HtB6ihuO2Bqgf13Yad68hnVL=hgOEBd+A@mail.gmail.com>
Subject: Re: IETF OSPF YANG and BFD Configuration
To: Jeffrey Haas <jhaas@pfrc.org>
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>
Content-Type: multipart/alternative; boundary="001a1141cae8ccb407055267f65b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/ARHOFan3Tx6Z8FoLsUrPOyovcmU>
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 17:56:04 -0000

Hi Jeff,
I'd like to hear from others who are familiar with implementations of BFD
that supports per protocol single-hop BFD multi-sessions between the same
pair of BFD systems. RFC 5881 does allow per protocol single-hop sessions
on the same interface, logical or physical, between the same pair of
systems. But it is not clear, in my opinion, how BFD does demultiplexing if
Your Discriminator == 0 per protocol (RFC 5881, section 3, last sentence)
if systems use the same IP addresses. And hence the question, Even though
it is allowed to have BFD single-hop sessions per application/protocol on
the same interface between the same pair of systems, is this real,
practical requirement?
Or am I missing the point completely?

Regards,
Greg

On Mon, Jun 19, 2017 at 1:57 PM, Jeffrey Haas <jhaas@pfrc.org>; wrote:

> [Long delayed response.]
>
> Reshad picked up the key points: Some things may make sense in the
> per-client (protocol) users of BFD, some things perhaps do not.  And some
> come down to questions for timer granularity.
>
> The OSPF and ISIS models both make use of BFD simply by providing a boolean
> that says "I'm using BFD or not".
>
> Where we run into some issues are the cases highlighted: when the sessions
> don't share common properties, how should the protocol pick what BFD
> session
> to use?
>
> The current BFD yang model only permits a single IP single-hop session
> to be configured.  (Key is interface/dst-ip)  This means that if different
> parameters *were* desired, the BFD model won't permit it today.  However,
> BFD sessions for many protocols tend not to be configured, but may spring
> forth from protocol state, such as IGP adjacencies.  Thus, it's not
> "configured" - it's solely operational state.  However, the BFD yang model
> doesn't really make good provision for that as an "on".
>
> Where all endpoint state is known a priori, config state makes better
> sense.
>
> To pick the example of Juniper's configuration, if OSPF and eBGP were using
> BFD, both can choose differing timers.  This represents two pieces of
> configuration state for the same endpoints.  Additionally, only one BFD
> session is formed using the most aggressive timers.
>
> I partially point out the situation of multiple timers since there have
> been
> prior list discussions on the situation where clients have different timing
> requirements.  I don't think we handle this operationally in the BFD
> protocol in the cleanest fashion right now - the session will go to Down
> when the aggressive timers fail and there's no clean way to renegotiate to
> the less aggressive timers.
>
> -- Jeff
>
>
>
>
>
>
> On Fri, May 19, 2017 at 02:31:38AM +0000, Reshad Rahman (rrahman) wrote:
> > We started off with the intent of having BFD parameters in the
> applications/protocols which make use of BFD. For timer/multiplier this is
> pretty straight-forward, although the discussion of what to do when not all
> applications have the same BFD parameters for the same session (e.g. Go
> with most aggressive etc). Then we started looking at authentication
> parameters and having BFD authentication parms in OSPF/ISIS etc is not
> intuitive. And what do we do if applications have different BFD
> authentication parms. We concluded that the BFD authentication parms were
> better off in BFD. And once we did that, the timer/multiplier followed....
> >
> > I may not recall all the details/discussons, but I do recall that we
> went back and forth on this and it took some time to make the decision.
> >
> > Regards,
> > Reshad (as individual contributor).
> >
> > From: Mahesh Jethanandani <mjethanandani@gmail.com<mailto:
> mjethanandani@gmail.com>>;
> > Date: Thursday, May 18, 2017 at 5:34 PM
> > To: "Acee Lindem (acee)" <acee@cisco.com<mailto:acee@cisco.com>>
> > Cc: Jeffrey Haas <jhaas@juniper.net<mailto:jhaas@juniper.net>>, OSPF WG
> List <ospf@ietf.org<mailto:ospf@ietf.org>>, "draft-ietf-bfd-yang@ietf.org<;
> mailto:draft-ietf-bfd-yang@ietf.org>" <draft-ietf-bfd-yang@ietf.org<;
> mailto:draft-ietf-bfd-yang@ietf.org>>, "draft-ietf-ospf-yang@ietf.org
> <mailto:draft-ietf-ospf-yang@ietf.org>" <draft-ietf-ospf-yang@ietf.org
> <mailto:draft-ietf-ospf-yang@ietf.org>>, "rtg-bfd@ietf.org<mailto:rtg-
> bfd@ietf.org>"; <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
> > Subject: Re: IETF OSPF YANG and BFD Configuration
> > Resent-From: <alias-bounces@ietf.org<mailto:alias-bounces@ietf.org>>
> > Resent-To: <vero.zheng@huawei.com<mailto:vero.zheng@huawei.com>>,
> Reshad <rrahman@cisco.com<mailto:rrahman@cisco.com>>, <
> mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>, <
> santosh.pallagatti@gmail.com<mailto:santosh.pallagatti@gmail.com>>, <
> gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
> > Resent-Date: Thursday, May 18, 2017 at 5:40 PM
> >
> > Resending with correct BFD WG address.
> >
> > On May 18, 2017, at 2:33 PM, Mahesh Jethanandani <
> mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>> wrote:
> >
> > Agree with Acee's assessment. After much debate, we decided that we
> should leave BFD parameter configuration in the BFD model itself, and have
> any IGP protocol reference the BFD instance in BFD itself. This makes sense
> specially if multiple protocols fate-share the BFD session.
> >
> > Cheers.
> >
> > On May 18, 2017, at 12:27 PM, Acee Lindem (acee) <acee@cisco.com<mailto:
> acee@cisco.com>>; wrote:
> >
> > Hi Jeff,
> >
> > At the OSPF WG Meeting in Chicago, you suggested that we may want to
> provide configuration of BFD parameters within the OSPF model
> (ietf-ospf.yang). We originally did have this configuration. However, after
> much discussion and coordination with the BFD YANG design team, we agreed
> to leave the BFD session parameters in BFD and only enable BFD within the
> OSPF and IS-IS models.
> >
> > We did discuss the fact that vendors (notably Cisco IOS-XR and Juniper
> JUNOS) do allow configuration within the IGPs. However, the consensus was
> to leave the BFD configuration in the BFD model. The heuristics to
> determine what parameters to use when the same BFD endpoint was configured
> with different parameters in different protocols were proprietary and
> somewhat of a hack.
> >
> > I may have not remembered all the details so I'd encourage others to
> chime in.
> >
> > Thanks,
> > Acee
> >
> > Mahesh Jethanandani
> > mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>
> >
> >
> >
> >
> > Mahesh Jethanandani
> > mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>
> >
> >
> >
>