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
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Gregory Mirsky
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Santiago Alvarez (saalvare)
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Sam Aldrin
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Marc Binderberger
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Binny Jeshan
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Binny Jeshan
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Jeffrey Haas
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Nobo Akiya (nobo)
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Marc Binderberger
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Nobo Akiya (nobo)
- Re: [mpls] Commenst on draft-akiya-bfd-intervals-… Jeffrey Haas