Re: [mpls] Commenst on draft-akiya-bfd-intervals-03

Jeffrey Haas <jhaas@pfrc.org> Sun, 02 June 2013 12:48 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1BF21F90FD; Sun, 2 Jun 2013 05:48:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level:
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[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 y6tqN3IObXCT; Sun, 2 Jun 2013 05:48:12 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0B84D21F8E8F; Sun, 2 Jun 2013 05:48:12 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 7C8C4C21A; Sun, 2 Jun 2013 08:48:08 -0400 (EDT)
Date: Sun, 02 Jun 2013 08:48:08 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Marc Binderberger <marc@sniff.de>
Message-ID: <20130602124808.GK10807@pfrc>
References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <CC0AACF6-E747-4C99-9ABD-2AAEC437367F@sniff.de> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> <20130510172441.GB12732@pfrc> <20130601223455119054.8703c711@sniff.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20130601223455119054.8703c711@sniff.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "mpls@ietf.org" <mpls@ietf.org>, Santiago Alvarez <saalvare@cisco.com>, "pwe3@ietf.org" <pwe3@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Jun 2013 12:48:18 -0000

On Sat, Jun 01, 2013 at 10:34:55PM +0200, Marc Binderberger wrote:
> It looks like we agree towards an "informal" document. This may be 
> partially due to a misunderstanding, a "standard" document would define 
> a minimum set of to-be-supported intervals, it would not forbid to 
> support additional timer interval values, in my view. Anyway, the goal 
> to improve interoperability can be reached with "informal" too, so I'm 
> fine.

An informational draft on the specific timer values may be of benefit.
One thing to ponder that has standards impact would be whether we'd want to
request an IANA registry to record such "well known values".

> For the split-off of appendix B: I can write a new draft, no problem. 
> The question is to the BFD list though: do you think we should dive 
> deeper into the timer negotiation area?  If everyone thinks the 
> appendix B is "obvious" or "trivial" then there is no point for a new 
> document. If implementors think we better do write down these details 
> and discuss them - then we have a basis for a new draft :-)

I think, given such a document specifying the well known values, that having
a known mechanism supporting converging on those values may be helpful.

My biggest concern for such a proposal is that it would encourage
implementations to *only* support those values rather than providing targets
for scaling certain specific timers.  Consider, for example, a scenario
where a device going into a temporary maintenance mode may want to
significantly reduce its detection interval (say > 3s) for a short period of
time.  If the remote device didn't have that 3s+ value as one of its "magic
numbers", then it may simply drop the session depending on procedure.

These, of course, are just details to consider for the draft.

-- Jeff