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

Marc Binderberger <marc@sniff.de> Sat, 01 June 2013 20:35 UTC

Return-Path: <marc@sniff.de>
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 8A88C21F9D69; Sat, 1 Jun 2013 13:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 rJSUnIb61GXI; Sat, 1 Jun 2013 13:35:09 -0700 (PDT)
Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD8121F9D8A; Sat, 1 Jun 2013 13:35:08 -0700 (PDT)
Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 48BE22AA0F; Sat, 1 Jun 2013 20:35:05 +0000 (GMT)
Date: Sat, 01 Jun 2013 22:34:55 +0200
From: Marc Binderberger <marc@sniff.de>
To: Jeffrey Haas <jhaas@pfrc.org>, Sam Aldrin <aldrin.ietf@gmail.com>, Santiago Alvarez <saalvare@cisco.com>, Binny Jeshan <binnyjeshan@gmail.com>
Message-ID: <20130601223455119054.8703c711@sniff.de>
In-Reply-To: <20130510172441.GB12732@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: GyazMail version 1.5.15
Cc: "mpls@ietf.org" <mpls@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "pwe3@ietf.org" <pwe3@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: Sat, 01 Jun 2013 20:35:09 -0000

Hello everyone,

my apologies for the late reply. Too many things at once :-)


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.


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 :-)

To quickly explain the problem again: RFC5880 and the Poll sequence 
described therein implicitly assume that the peer can accept any timer 
value. Thus the Poll sequence is a simple P-bit, F-bit sequence. With 
hardware-based implementations we may see a more granular timer support 
and the peer can _not_ accept the new interval proposed. More 
negotiations would be required to find a commonly supported timer value 
(which exists when following the draft's minimum set of values). 
Appendix B describes the procedure we propose.


Regards, Marc



On Fri, 10 May 2013 13:24:41 -0400, Jeffrey Haas wrote:
> On Mon, Dec 03, 2012 at 11:53:47AM -0800, Sam Aldrin wrote:
>> I echo what Santiago had said in his email. Good to have an 
>> informational document and do not support the idea of standardizing 
>> the intervals.
> 
> Speaking as chair, while I'm not in favor of have a standardized set of
> intervals (the fights such a document would create would be epic), I am
> highly supportive of such a document having informational status.
> 
> As a suggestion, there may be two actual documents in such a case: 
> - An informational document covering the intervals.
> - A short document, potentially on the standards track, covering the
>   procedure by which timers can negotiate to such an interval.  This may be
>   worth standardizing.  (This is covered by Appendix B.)
> 
> -- Jeff