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

Mach Chen <mach.chen@huawei.com> Tue, 12 November 2013 03:19 UTC

Return-Path: <mach.chen@huawei.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 2ECDE21E8085 for <rtg-bfd@ietfa.amsl.com>; Mon, 11 Nov 2013 19:19:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.208
X-Spam-Level:
X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 k+P5-fetwNcg for <rtg-bfd@ietfa.amsl.com>; Mon, 11 Nov 2013 19:19:54 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6754E21E80FC for <rtg-bfd@ietf.org>; Mon, 11 Nov 2013 19:19:50 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAD88362; Tue, 12 Nov 2013 03:19:49 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 03:19:36 +0000
Received: from SZXEML450-HUB.china.huawei.com (10.82.67.193) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 03:19:48 +0000
Received: from szxeml558-mbs.china.huawei.com ([169.254.8.159]) by szxeml450-hub.china.huawei.com ([10.82.67.193]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 10:51:40 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "Nobo Akiya (nobo)" <nobo@cisco.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, Jeffrey Haas <jhaas@pfrc.org>
Subject: RE: WGLC for BFD base MIB and TC - ends November 8
Thread-Topic: WGLC for BFD base MIB and TC - ends November 8
Thread-Index: AQHO3mQ7d29rmKPEbUGsnzhYr0Jy/JogyEJg//+QogCAAIrvcA==
Date: Tue, 12 Nov 2013 02:51:39 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE25CF1E642@szxeml558-mbs.china.huawei.com>
References: <20131024190612.GN17538@pfrc> <DF6057A3-735A-41C6-A6CE-A6D473F3E1B2@cisco.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE25CF1E425@szxeml558-mbs.china.huawei.com> <CECE764681BE964CBE1DFF78F3CDD3941DEE1FAB@xmb-aln-x01.cisco.com>
In-Reply-To: <CECE764681BE964CBE1DFF78F3CDD3941DEE1FAB@xmb-aln-x01.cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.97.72]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "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 03:19:58 -0000

Hi Nobo,

Thanks for your prompt response!

Pls see my reply inline..
> 
> [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.

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.

Best regards,
Mach

> 
> New UDP port is automatically covered by TC MIB as well.
> 
> Thus my preference would be use existing BFD base/TC MIB as is for BFD on LAG.
> 
> -Nobo
> 
> > -----Original Message-----
> > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On
> > Behalf Of Mach Chen
> > Sent: Monday, November 11, 2013 8:18 PM
> > To: Carlos Pignataro (cpignata); Jeffrey Haas
> > Cc: rtg-bfd@ietf.org
> > Subject: RE: WGLC for BFD base MIB and TC - ends November 8
> >
> > Hi Carlos and all,
> >
> > Thanks for doing this, I have one question to the WG. Since the BFD
> > over LAG draft is also in publication process, and there are some
> > implementations and deployment requirements, but the MIB drafts seem
> > lack of supporting the BFD over LAG scenario ( e.g., a variable to
> > describe the dedicated multicast MAC) . Does the WG plan to fix this
> > in these two drafts ? Or there will be a separate document that will
> > cover this in the future?
> >
> > Best regards,
> > Mach
> >
> > > -----Original Message-----
> > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On
> > > Behalf Of Carlos Pignataro (cpignata)
> > > Sent: Monday, November 11, 2013 6:29 AM
> > > To: Jeffrey Haas
> > > Cc: rtg-bfd@ietf.org
> > > Subject: Re: WGLC for BFD base MIB and TC - ends November 8
> > >
> > > BFDers,
> > >
> > > The BFD co-chairs asked me to gauge consensus on this WG Last Call
> > > for
> > > draft-ietf-bfd-mib-14 and draft-ietf-bfd-tc-mib-02. The WGLC ended
> > > this past Friday.
> > >
> > > In my view, there is good support for these two documents, including
> > > from implementors, and consensus to move forward and be sent to the
> > IESG.
> > >
> > > Before that, the following needs to be taken into account:
> > > 1. Fix the Nits identified by idnits [1] [2] 2. Ask the OPS ADs for
> > > a MIB Doctor review [3] ("after the Working Group Last Call and
> > > before the IETF Last Call")
> > >
> > > Thanks,
> > >
> > > - Carlos.
> > >
> > > [1]
> > > http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf
> > > -b
> > > fd-mib-14.txt
> > > [2]
> > > http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf
> > > -b
> > > fd-tc-mib-02.t
> > > xt
> > > [3] http://www.ietf.org/iesg/directorate/mib-doctors.html
> > >
> > >
> > > On Oct 24, 2013, at 3:06 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> > >
> > > > This email is to initiate working group last call on the BFD MIB
> > > > and Textual-Convention documents:
> > > >
> > > > http://tools.ietf.org/html/draft-ietf-bfd-mib-14
> > > > http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-02
> > > >
> > > > The last call will complete on November 8, the end of IETF week.
> > > > Time will be available during the Vancouver IETF BFD session to
> > > > discuss last call comments.
> > > >
> > > > I will be serving as document shepherd (RFC 4858) for this WGLC.
> > > >
> > > > Due to the small nature of the BFD working group and the fact that
> > > > both working group chairs have contributed to the documents, we
> > > > have gotten Carlos Pignataro (cpignata@cisco.com) to volunteer to
> > > > serve as an independent party to gauge working group consensus.
> > > >
> > > > In order to facilitate the transparency of this WGLC, please
> > > > remember to send all comments to the working group mailing list.
> > > >
> > > > As is often the case with MIB documents, implementations typically
> > > > do not exist for the final form of the document.  Typically
> > > > enterprise MIBs are implemented at some point in the document life
> > > > cycle and then later the implementor will revise to match the
> > > > published RFC, including OID code-points assigned by IANA.
> > > > Reviewers examining the MIB against deployed implementations are
> > > > requested to bear in mind implementability of the final document vs.
> > existence proof of the running code.
> > > >
> > > > Finally, note that no IPR polling has been done for these documents.
> > > > MIBs, being IETF data models of things that themselves may have
> > > > IPR, tend not to have IPR against them.  However, if someone is
> > > > aware of IPR against these documents, please state it for the WG.
> > > >
> > > > -- Jeff (for the chairs)