Re: WGLC for BFD base MIB and TC - ends November 8

Jeffrey Haas <jhaas@pfrc.org> Tue, 12 November 2013 20:25 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 E5BA621E80F0 for <rtg-bfd@ietfa.amsl.com>; Tue, 12 Nov 2013 12:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.218
X-Spam-Level:
X-Spam-Status: No, score=-102.218 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
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 Q2w4VLyOZXHm for <rtg-bfd@ietfa.amsl.com>; Tue, 12 Nov 2013 12:25:15 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 36E2721E8093 for <rtg-bfd@ietf.org>; Tue, 12 Nov 2013 12:25:11 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id D388CC2F0; Tue, 12 Nov 2013 15:25:10 -0500 (EST)
Date: Tue, 12 Nov 2013 15:25:10 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Mach Chen <mach.chen@huawei.com>
Subject: Re: WGLC for BFD base MIB and TC - ends November 8
Message-ID: <20131112202510.GG15347@pfrc>
References: <20131024190612.GN17538@pfrc> <DF6057A3-735A-41C6-A6CE-A6D473F3E1B2@cisco.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE25CF1E425@szxeml558-mbs.china.huawei.com> <CECE764681BE964CBE1DFF78F3CDD3941DEE1FAB@xmb-aln-x01.cisco.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE25CF1E642@szxeml558-mbs.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE25CF1E642@szxeml558-mbs.china.huawei.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "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: Tue, 12 Nov 2013 20:25:21 -0000

Mach,

On Tue, Nov 12, 2013 at 02:51:39AM +0000, Mach Chen wrote:
> > [speaking as contributor to both LAG and MIB documents]
> > 
> > Hi Mach,
> > 
> > My thought on this is that BFD on LAG is a variant of single-hop BFD, thus [LAG
> > member, IP address] is sufficient to uniquely describe an uBFD session. I know of
> > an implementation that is using this approach, and it seems to satisfy user needs.
> > 
> > Certainly there's no OID to describe multicast MAC nor interface MAC, of uBFD
> > session. Benefit of being able to read such OID seems very marginal. Whether
> > anyone ever want to write to such OID (to switch to/from multicast from/to
> > interface MAC?) is also questionable.
> 
> Yes, I agree that it is very marginal. 
> 
> I am not sure whether there will be writing, but there should be reading of such OID.

I spent some time reviewing the BFD MIBs specially with the LAG
cases in mind.  The conclusion I arrived at included the following:
- the *base* MIBs are capable of handling the subsets of behavior that are
  not feature specific to the BFD MPLS MIB or LAG scenarios.  
- the superset of feature elements were largley covered by the port number
  change.
- the one minor element was the mac address.
- As BFD continues to evolve, a single MIB can never address 100% of the use
  cases.

The latter is the main point here, I think.  As you suggest, there's really
only a single object (maybe two) that distinguishes the additional details
of BFD on LAG: Whether we're using the multicast MAC as part of the
procedures and what the MAC is for the session.

> The "multicast MAC or interface MAC" is just the one that came into my mind, I am not sure whether there are some uncovered places. 
> 
> If the "multicast MAC or interface MAC" is the only one need to be considered, IMHO, it's maybe easy to modify the BFD base MIB to fix it.

My suggestion would be that if you find that specific detail interesting, it
is in-charter for the Working Group to add an extension MIB for the base MIB
for the necessary feature-specific objects.

Did you have any interest in authoring that?

-- Jeff