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
- WGLC for BFD base MIB and TC - ends November 8 Jeffrey Haas
- Re: WGLC for BFD base MIB and TC - ends November 8 Srihari Raghavan (srihari)
- Re: WGLC for BFD base MIB and TC - ends November 8 Thomas Nadeau
- Re: WGLC for BFD base MIB and TC - ends November 8 Jeffrey Haas
- Re: WGLC for BFD base MIB and TC - ends November 8 Henderickx, Wim (Wim)
- Re: WGLC for BFD base MIB and TC - ends November 8 Thomas Nadeau
- RE: WGLC for BFD base MIB and TC - ends November 8 Vengada Prasad Govindan (venggovi)
- Re: WGLC for BFD base MIB and TC - ends November 8 Carlos Pignataro (cpignata)
- Re: WGLC for BFD base MIB and TC - ends November 8 Carlos Pignataro (cpignata)
- RE: WGLC for BFD base MIB and TC - ends November 8 Nobo Akiya (nobo)
- RE: WGLC for BFD base MIB and TC - ends November 8 Mach Chen
- RE: WGLC for BFD base MIB and TC - ends November 8 Nobo Akiya (nobo)
- RE: WGLC for BFD base MIB and TC - ends November 8 Mach Chen
- Re: WGLC for BFD base MIB and TC - ends November 8 Jeffrey Haas
- RE: WGLC for BFD base MIB and TC - ends November 8 Mach Chen
- Re: WGLC for BFD base MIB and TC - ends November 8 Jeffrey Haas
- RE: WGLC for BFD base MIB and TC - ends November 8 Mach Chen