Re: Gen-ART review of draft-ietf-bfd-mib-17

Jeffrey Haas <jhaas@pfrc.org> Thu, 17 April 2014 22:15 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0945D1A0100; Thu, 17 Apr 2014 15:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.84
X-Spam-Level:
X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 C1saCmvMvMKx; Thu, 17 Apr 2014 15:15:14 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CF17F1A011D; Thu, 17 Apr 2014 15:15:14 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 37915C2A3; Thu, 17 Apr 2014 18:15:11 -0400 (EDT)
Date: Thu, 17 Apr 2014 18:15:11 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Nobo Akiya (nobo)" <nobo@cisco.com>
Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17
Message-ID: <20140417221511.GC29430@pfrc>
References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> <CECE764681BE964CBE1DFF78F3CDD3941E10B9F3@xmb-aln-x01.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CECE764681BE964CBE1DFF78F3CDD3941E10B9F3@xmb-aln-x01.cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/-kBlc1d8sC1eP-2uIbsFcRqx36E
Cc: "ietf@ietf.org" <ietf@ietf.org>, "Black, David" <david.black@emc.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "Zafar Ali (zali)" <zali@cisco.com>, "General Area Review Team (gen-art@ietf.org)" <gen-art@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Apr 2014 22:15:16 -0000

On Thu, Apr 17, 2014 at 09:18:28PM +0000, Nobo Akiya (nobo) wrote:
> > I did not see a compliance requirement for a system that only implements
> > BFD protocol version 0.  That absence should at least be mentioned
> > somewhere.  For example, if this reflects a considered and deliberate
> > decision by the WG, that should be mentioned in the introduction.
> 
> Good point. If I remember correctly, BFD version 0 had a problem in the state machine that can cause the two ends to fall into a deadlock. It would be, therefore, very bad for anybody to have BFD version 0 deployed out there, and asking for any MIB compliance requirement for such. Consensus on absence of compliance requirement for BFD version 0 was never polled in the WG, but I can say that there shouldn't be any desire for that.

With respect to v0 vs. v1 from a MIB perspective, the only user-visible
detail was the additional state in the state machine.  That means that the
MIB in its current form should be able to accommodate bfd v0.

This does suggest, however, that the TC mib could use a comment in the
DESCRIPTION toward the point that failing(5) is only valid for BFD v0.

A conformance clause indicating that those so foolish as to deploy BFD v0
would better be served by the determinism of a five-year-old child flipping
a coin is probably out of scope for the draft.  But if someone has
sufficiently proscriptive text to add to say "don't do bfd v0" that is
acceptable to the reviewers, I'm fine with that.

-- Jeff