IETF Logo Mail Archive

Re: Adoption of draft-vkst-bfd-mpls-mib

Sam Aldrin <aldrin.ietf@gmail.com> Wed, 06 June 2012 00:35 UTC

Return-Path: <aldrin.ietf@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 1B11711E808D for <rtg-bfd@ietfa.amsl.com>; Tue, 5 Jun 2012 17:35:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.068
X-Spam-Level:
X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135]
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 9gKAOYsg0Fvu for <rtg-bfd@ietfa.amsl.com>; Tue, 5 Jun 2012 17:35:40 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8C48D11E808C for <rtg-bfd@ietf.org>; Tue, 5 Jun 2012 17:35:40 -0700 (PDT)
Received: by dacx6 with SMTP id x6so7857007dac.31 for <rtg-bfd@ietf.org>; Tue, 05 Jun 2012 17:35:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=zwc+wdcOkWhJN88ofMwFbe4Oya/trFtQ1/eg6irOuvQ=; b=Fvv6RJgCOHpdRq9vJcXeRu+NWsUGhbnOZYtmdueR+UD/fk0eSAve4P9t0b6Vef+TFF scxSC7+BL4rNLJG4vJtazcvTuFu4NcTuX2HUMtwc2jVljylb+mmUjNHfeMpDm1OgOf6e UMW4Lb6mJ8XWqvKuGGcoGLTowAvvy+flJjF/4Qm/fF6ufUOIsbpuE2ny/TW+LC0BuGiT HS8M/VJiFdePScfx/IrxmFgh7BG2eEYE74j1WiIEgeFYNSTCikPhVDY81tnVBn0AmurV opu4uQrNug6GGVLMQHM2UQ7Oo5XsV56tYgsMac6WhylC1po5dZVWfwiljDh8Wk4JSeOy YArw==
Received: by 10.68.237.202 with SMTP id ve10mr43455859pbc.54.1338942939944; Tue, 05 Jun 2012 17:35:39 -0700 (PDT)
Received: from [199.187.220.60] (dhcp-220-60.meetings.nanog.org. [199.187.220.60]) by mx.google.com with ESMTPS id pb10sm471437pbc.68.2012.06.05.17.35.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jun 2012 17:35:38 -0700 (PDT)
References: <20120601151238.GV4067@pfrc> <FE60A4E52763E84B935532D7D9294FF1355478AEFB@EUSAACMS0715.eamcs.ericsson.se> <C1F7AB81-3232-4A43-A6BC-0FD3879D6874@lucidvision.com>
In-Reply-To: <C1F7AB81-3232-4A43-A6BC-0FD3879D6874@lucidvision.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"
Message-Id: <F99D3C25-4885-41B3-BC2F-CD2B5EA037FE@gmail.com>
X-Mailer: iPad Mail (9B206)
From: Sam Aldrin <aldrin.ietf@gmail.com>
Subject: Re: Adoption of draft-vkst-bfd-mpls-mib
Date: Tue, 05 Jun 2012 17:35:37 -0700
To: Thomas Nadeau <tnadeau@lucidvision.com>
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: Wed, 06 Jun 2012 00:35:41 -0000

Sent from my iPad

On Jun 5, 2012, at 4:55 PM, Thomas Nadeau <tnadeau@lucidvision.com> wrote:

> 
> On Jun 5, 2012:2:35 PM, at 2:35 PM, Gregory Mirsky wrote:
> 
>> Dear Chairs, Authors, et al.,
>> I think that this is needed work but the document needs some modifications:
>> - read-create objects can be modified into read-only as no firm requirement to support SNMP based configuration can be found;
> 
>    Are you asking us to specifically make the MIB read-only?  If so, this would be at least the second request recently (third if you include mine).  However, it might be good to get some guidance from the WG chairs on this direction as making these changes can be potentially significant.
We were asked specifically by the WG chairs, in the Paris WG session, to add read write option to the MIB. AD and MPLS WG chair also provided their comments and felt BFD MIB extension to support TP should have write support.

There are at least three vendors who are requesting write support as well.

To the original comment that there is no requirement for write support for MIB, my answer is, there is no requirement to have just read only either. If there is consensus that, write option shouldnt exist in MIBs, it should be stated so. Otherwise, the confusion will persist every time.

Cheers
Sam
> 
>    --Tom
> 
> 
>> - bfdMplsSessTable lacks object to reflect whether Coordinated or Independent monitoring mode being used per RFC 6428;
>> - bfdMplsSessTmrNegotiate object is non-standard and is not MPLS specific but is expression of local policy set by an operator. The bfdMplsSessTmrNegotiate should be removed from the bfdMplsSessTable table;
>> - list of modes for the bfdMplsSessMode object should include a mode, perhaps referred as bfd, which performs continuity check but does not support RDI functionality (RFC 5884 and RFC 5885);
>> - bfdMplsSessTable needs to reflect addressing used if bfdMplsSessMapType = mep(6) - IP or ICC;
>> - bfdMplsSessTable needs to reflect encapsulation type, IP or ACH/G-ACh, being used.
>> 
>>    Regards,
>>        Greg
>> 
>> -----Original Message-----
>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas
>> Sent: Friday, June 01, 2012 8:13 AM
>> To: rtg-bfd@ietf.org
>> Subject: Adoption of draft-vkst-bfd-mpls-mib
>> 
>> Working Group,
>> 
>> This begins a one week poll for the adoption of http://tools.ietf.org/html/draft-vkst-bfd-mpls-mib
>> as a working group document.
>> 
>> Note that this appears to be currently within the scope of our charter:
>> 
>> : 1. Develop the MIB module for BFD and submit it to the IESG for publication
>> : as a Proposed Standard. 
>> : 
>> : 5. Assist in the standardization of the BFD protocol for MPLS-TP. The
>> : preferred solution will be interoperable with the current BFD specification. 
>> 
>> If our ADs disagree, we'll ask for a formal charter change to pick up this item.
>> 
>> The room discussion regarding this draft during IETF 83 was positive.
>> 
>> -- Jeff
>> 
>

v2.23.0 | Report a Bug | By Email