From marc@sniff.de Sat Jun 1 13:35:09 2013 Return-Path: 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 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, 1 Jun 2013 22:34:55 +0200 From: Marc Binderberger To: Jeffrey Haas , Sam Aldrin , Santiago Alvarez (saalvare) , Binny Jeshan Message-ID: <20130601223455119054.8703c711@sniff.de> In-Reply-To: <20130510172441.GB12732@pfrc> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> <20130510172441.GB12732@pfrc> Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 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" , "rtg-bfd@ietf.org" , "pwe3@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobo@cisco.com Sat Jun 1 19:27:19 2013 Return-Path: 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 A457111E80A2; Sat, 1 Jun 2013 19:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 e3pgLw3WhRkd; Sat, 1 Jun 2013 19:27:14 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A468411E80EF; Sat, 1 Jun 2013 19:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3581; q=dns/txt; s=iport; t=1370140034; x=1371349634; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cN6KhN/xqsWvX1FY3eNkN8pixJJLwqmKMF3XBxLtDok=; b=UNUi1+nS1FxU4DaOI9KqEYChSQDsarYCopOAP2wO306C4HlGCezddvCS ngL5QLtvJbjO77mjnbPm/r9lb0F9Z010kAVIsPJB+Q6VX9K4Q+3B5eeIx ItV3roR3P8zA4HtTKsNI293IemeLR/62NVUlDYRj9f8UtT1SF+M/82gXF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFADisqlGtJV2d/2dsb2JhbABZgmghML8DfxZ0giMBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCIgFAQu5JwSNWguBETEHBoJxYQOofoMPgXE2 X-IronPort-AV: E=Sophos;i="4.87,786,1363132800"; d="scan'208";a="217474187" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 02 Jun 2013 02:27:14 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r522RD3P029063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 2 Jun 2013 02:27:13 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Sat, 1 Jun 2013 21:27:13 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , Jeffrey Haas , "Sam Aldrin" , "Santiago Alvarez (saalvare)" , Binny Jeshan Subject: RE: [mpls] Commenst on draft-akiya-bfd-intervals-03 Thread-Topic: [mpls] Commenst on draft-akiya-bfd-intervals-03 Thread-Index: Ac3Rh3XM5+9UcfrcQ2S8rX469rwQOQAAVMZQAAy8rAAAAN+FAAAAiuEAAAAzaYAfAr3RgARZDheAAAEjodA= Date: Sun, 2 Jun 2013 02:27:13 +0000 Message-ID: References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> <20130510172441.GB12732@pfrc> <20130601223455119054.8703c711@sniff.de> In-Reply-To: <20130601223455119054.8703c711@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.188] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" , "pwe3@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 02:27:19 -0000 Hello Marc, et al, Before going into "timer negotiation deep dive", it'll be beneficial to def= ine the contents of the informational draft. In addition to set of interval= s specified, the document can also describe usefulness in implementation su= pporting multiples of specified intervals. Such implementations will be abl= e to support large set of intervals, and even larger set when jitter consid= ered. I think the result will be very useful to anybody implementing/operat= ing HW BFD. Once we converge on that, then perhaps we can take up the discu= ssion of whether we need additional standard track draft or not, and with w= hat contents. Regards, Nobo > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Marc Binderberger > Sent: Saturday, June 01, 2013 4:35 PM > To: Jeffrey Haas; Sam Aldrin; Santiago Alvarez (saalvare); Binny Jeshan > Cc: mpls@ietf.org; rtg-bfd@ietf.org; pwe3@ietf.org > Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 >=20 > Hello everyone, >=20 > my apologies for the late reply. Too many things at once :-) >=20 >=20 > It looks like we agree towards an "informal" document. This may be partia= lly > 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. >=20 >=20 > 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 deepe= r > 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 :-) >=20 > 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. >=20 >=20 > Regards, Marc >=20 >=20 >=20 > 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 ma= y be > > worth standardizing. (This is covered by Appendix B.) > > > > -- Jeff > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From jhaas@slice.pfrc.org Sun Jun 2 05:21:35 2013 Return-Path: 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 BFB5521F9F23 for ; Sun, 2 Jun 2013 05:21:35 -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 OhA9GufP-WTl for ; Sun, 2 Jun 2013 05:21:30 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B803B21F9F1E for ; Sun, 2 Jun 2013 05:21:30 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7C8D1C21A; Sun, 2 Jun 2013 08:21:29 -0400 (EDT) Date: Sun, 2 Jun 2013 08:21:29 -0400 From: Jeffrey Haas To: Shahram Davari Subject: Re: The "version" topic (was: Reserved discriminators?) Message-ID: <20130602122129.GH10807@pfrc> References: <20211F91F544D247976D84C5D778A4C303454E@SG70YWXCHMBA05.zap.alcatel-lucent.com> <47ECC683-FFD9-4C42-8AB6-712865ED4AEE@sniff.de> <20211F91F544D247976D84C5D778A4C3034B6D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <170A1D80-4FC4-419F-97BF-C2932161282D@sniff.de> <20211F91F544D247976D84C5D778A4C3034D1D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <92DCCC04-A14C-46C5-9C64-AB3F0B389729@sniff.de> <4A6CE49E6084B141B15C0713B8993F281BE0B20F@SJEXCHMB12.corp.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BE0B20F@SJEXCHMB12.corp.ad.broadcom.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Jeff Haas \(jhaas@juniper.net\)" , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 12:21:36 -0000 [With my chair hat on] On Tue, May 28, 2013 at 06:51:54PM +0000, Shahram Davari wrote: > Before going any further I suggest whoever is proposing this to write a > requirements drafts so that we can better evaluate what is needed and why > it is required. The next step after that is to evaluate the solutions. May > be just a single flag in the header is all that is required or may be a > new version is needed. Any significant changes to the protocol warranting a new version will almost certainly have to be driven from a well understood set of requirements. If documenting those requirements results in a draft, that's great. One of the details that must be covered in such requirements is something very fundamental to BFD: What information are you trying to signal at millisecond granularity that you're expecting to be acted upon in the course of one or two packets? -- Jeff From jhaas@slice.pfrc.org Sun Jun 2 05:48:18 2013 Return-Path: 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 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, 2 Jun 2013 08:48:08 -0400 From: Jeffrey Haas To: Marc Binderberger Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 Message-ID: <20130602124808.GK10807@pfrc> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <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" , Santiago Alvarez , "pwe3@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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From jhaas@slice.pfrc.org Sun Jun 2 05:52:17 2013 Return-Path: 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 EB2B721F9017 for ; Sun, 2 Jun 2013 05:52: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 pAcHTp93xEjW for ; Sun, 2 Jun 2013 05:52:12 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CD57D21F86F0 for ; Sun, 2 Jun 2013 05:52:11 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 82AD5C21A; Sun, 2 Jun 2013 08:52:11 -0400 (EDT) Date: Sun, 2 Jun 2013 08:52:11 -0400 From: Jeffrey Haas To: Jeffrey Haas Subject: Re: The "version" topic (was: Reserved discriminators?) Message-ID: <20130602125211.GL10807@pfrc> References: <47ECC683-FFD9-4C42-8AB6-712865ED4AEE@sniff.de> <20211F91F544D247976D84C5D778A4C3034B6D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <170A1D80-4FC4-419F-97BF-C2932161282D@sniff.de> <20211F91F544D247976D84C5D778A4C3034D1D@SG70YWXCHMBA05.zap.alcatel-lucent.com> <92DCCC04-A14C-46C5-9C64-AB3F0B389729@sniff.de> <4A6CE49E6084B141B15C0713B8993F281BE0B20F@SJEXCHMB12.corp.ad.broadcom.com> <20130602122129.GH10807@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130602122129.GH10807@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Jeff Haas \(jhaas@juniper.net\)" , "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 12:52:18 -0000 [And now, speaking as an individual contributor.] On Sun, Jun 02, 2013 at 08:21:29AM -0400, Jeffrey Haas wrote: > One of the details that must be covered in such requirements is something > very fundamental to BFD: > What information are you trying to signal at millisecond granularity that > you're expecting to be acted upon in the course of one or two packets? And let us recall that at some points of a BFD session's life that not everything is that fast. I.e. Down and Init. -- Jeff From lokeshnb1@gmail.com Thu Jun 6 03:22:52 2013 Return-Path: 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 DB54B21F994A for ; Thu, 6 Jun 2013 03:22:49 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 7+youkFWCnDr for ; Thu, 6 Jun 2013 03:22:47 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7204521F9942 for ; Thu, 6 Jun 2013 03:22:47 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id wc20so4311667obb.4 for ; Thu, 06 Jun 2013 03:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lWJxHEYM5qeEx9lCJqzbvI9qlxv6sewryaUU4k2YOJA=; b=bQjp16IQFheUUJjPfO+DeXC4l2Acry9oIdsg/04Ixf22SGRTwY9a4qOeAkoz64QrSG xlZqVmHeWd0mYFJf3zVVlAPNGBM0repf7KAXnybs2HnR+s4c2I+qqfc2Y9Ji/Bi0FXui TXNO8h4VFQQM1vPrkhhEcKyeXMzmKzUGUXoGk+KB2Asj5sDUFUFPQm3sCxpX2e4XPFwU KbGkZx+LAFWl5RncyqUfGIPKkm4zYjPm87HUb0bxQi6UiKugggP5OcF+o7aCoeX2r8jm ZJGbIzQrjPrjb90HSImbj/BZZtMM9v73Ue9xz9u4hmi7y9scuOUzPglc1ewacTCWYpF6 41CA== MIME-Version: 1.0 X-Received: by 10.60.33.102 with SMTP id q6mr18130345oei.111.1370514167000; Thu, 06 Jun 2013 03:22:47 -0700 (PDT) Received: by 10.76.152.231 with HTTP; Thu, 6 Jun 2013 03:22:46 -0700 (PDT) Date: Thu, 6 Jun 2013 15:52:46 +0530 Message-ID: Subject: network interface BFD configuration issues. From: Lokesh B To: "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=089e01182bf615866604de79b2b5 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 10:22:53 -0000 --089e01182bf615866604de79b2b5 Content-Type: text/plain; charset=ISO-8859-1 Hi All, I know that BFD can be enabled/disabled per network interface. Major vendors allow configuration of BFD parameters like Min/Max Tx and Rx values per interface. Also routing applications can specify their own BFD parameters while creating bfd session. which values to select for BFD operation in this case? should we go for the minimum of each specified parameter?. Also as interface can be configured with its own BFD parameters, should we treat them as default parameters in case application creating a BFD session on that interface does not specify them? Highly appreciate the answers. Regards and Thanks -Lokesh. --089e01182bf615866604de79b2b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,

I know that BFD c= an be enabled/disabled per network interface. Major vendors allow configura= tion of BFD parameters like Min/Max Tx and Rx values per interface. Also ro= uting applications can specify their own BFD parameters while creating bfd = session. which values to select for BFD operation in this case? should we g= o for the minimum of each specified parameter?.
Also as interface can be configured with its own BFD parameters, shou= ld we treat them as default parameters in case application creating a BFD s= ession on that interface does not specify them?
Highly appreciate = the answers.

Regards and Thanks
-Lokesh.
--089e01182bf615866604de79b2b5-- From nobo@cisco.com Thu Jun 6 06:46:24 2013 Return-Path: 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 33CFD21F990D for ; Thu, 6 Jun 2013 06:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 GWBeqx8i0jmu for ; Thu, 6 Jun 2013 06:46:18 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4032921F94E1 for ; Thu, 6 Jun 2013 06:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1742; q=dns/txt; s=iport; t=1370526378; x=1371735978; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PyrWckvZoH1Y+YqnJMNtZiRKk6my6ZKsY82UV12/+k4=; b=DXb5yt7gUKECMypzspr7UtGzAkeU07oy7cKYKj605ufAnvVES5/tAVON 74Y3tgl3OGgDv04F5idj7LhUMozdd2PbxZ+ljj0S0Vw4XsHXISVRIkYKX ad0SZLeJKsX89SjBxWuQkDvK6K2EqwIPC4eu0bpaPhVjmLlOOgFA3QcNF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFALaRsFGtJV2c/2dsb2JhbABZgmghv3d4FnSCIwEBAQMBOkQLAgEIEQQBAQsUCQcyFAkIAgQBEgiHfwYBuyaPATiCemEDqH+DD4In X-IronPort-AV: E=Sophos;i="4.87,815,1363132800"; d="scan'208";a="219357324" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 06 Jun 2013 13:46:17 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r56DkHMQ023595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 13:46:17 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 08:46:17 -0500 From: "Nobo Akiya (nobo)" To: Lokesh B , "rtg-bfd@ietf.org" Subject: RE: network interface BFD configuration issues. Thread-Topic: network interface BFD configuration issues. Thread-Index: AQHOYp/STqcB/HOSZEyFQN2gugaVIpkorzLw Date: Thu, 6 Jun 2013 13:46:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:46:24 -0000 Hello Lokesh, > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of Lokesh B > Sent: Thursday, June 06, 2013 6:23 AM > To: rtg-bfd@ietf.org > Subject: network interface BFD configuration issues. >=20 > Hi All, > I know that BFD can be enabled/disabled per network interface. Major > vendors allow configuration of BFD parameters like Min/Max Tx and Rx > values per interface. Also routing applications can specify their own BFD > parameters while creating bfd session. which values to select for BFD > operation in this case? should we go for the minimum of each specified > parameter?. This falls in the area of implementation specifics, thus there are design c= hoices but no right answer. Generically speaking, if multiple applications = request BFD on same target, my personal preference would be to take the val= ues that results in more aggressive detection time. > Also as interface can be configured with its own BFD parameters, should > we treat them as default parameters in case application creating a BFD > session on that interface does not specify them? > Highly appreciate the answers. Either applications have deviating default detection time values, user has = configured deviating detection time values on applications or combination o= f both. Do you want to treat "interface" as a special application that take= s precedence over other applications? Perhaps, perhaps not. It would seem m= ost flexible if one approach was implemented and well documented, but allow= ed a knob to behave in different approaches as well. Probably not the exact answers you were looking for, but I hope this helps. Regards, Nobo >=20 > Regards and Thanks > -Lokesh. From nobo@cisco.com Fri Jun 7 11:18:57 2013 Return-Path: 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 AEE8A21F8FDC for ; Fri, 7 Jun 2013 11:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 EtuSQ74cGBMA for ; Fri, 7 Jun 2013 11:18:44 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id DC1E821F9017 for ; Fri, 7 Jun 2013 11:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3810; q=dns/txt; s=iport; t=1370629124; x=1371838724; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FBqPww5u5n4ITys66hZ3LQouDcgWgCfldEbHfgb3VXI=; b=ehjoxRNtXuvVgwKbR2oGKQ4m9s4Pk+qursVwKnxx9/v6dIqh9NVvpViy ivzWB6MbGiApVRLCgC8GuE1IeBMXSSAAOMejW94lJMokeCH6i0/kFFLPy vBeIz+ZjngRq9OtGqdHlyEUtDdhKbSKTJGroG7T9ohnnaI6ELvS72REwj 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYGAAUjslGtJXHB/2dsb2JhbABZgmghMIM8uzMNcxZtB4IjAQEBBCMRQwIMBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQOBQgBiAQBC6sakVmBJo1hMQcGgkIzYQOYaZAZgw+BaiQZ X-IronPort-AV: E=Sophos;i="4.87,823,1363132800"; d="scan'208";a="217199557" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 07 Jun 2013 18:18:43 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r57IIhAm006708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 7 Jun 2013 18:18:43 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Fri, 7 Jun 2013 13:18:42 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: FW: New Version Notification for draft-akiya-bfd-seamless-base-00.txt Thread-Topic: New Version Notification for draft-akiya-bfd-seamless-base-00.txt Thread-Index: AQHOY6KrQQ5TY8S5t0GEvYBX/GBFCJkqhPpg Date: Fri, 7 Jun 2013 18:18:42 +0000 Message-ID: References: <20130607171553.20405.44045.idtracker@ietfa.amsl.com> In-Reply-To: <20130607171553.20405.44045.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "David Ward \(wardd\)" , "Nagendra Kumar \(naikumar\)" , "Tarek Saad \(tsaad\)" , "Siva Sivabalan \(msiva\)" , "Carlos Pignataro \(cpignata\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 18:18:57 -0000 SGVsbG8gQkZEIFdHIE1lbWJlcnMsDQoNCldlIGhhdmUgcG9zdGVkIGEgbmV3IEJGRCBkcmFmdC4N Cg0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtYmFzZS0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtYmFz ZQ0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ha2l5 YS1iZmQtc2VhbWxlc3MtYmFzZS0wMA0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgc3BlY2lmaWNhdGlv biBkZWZpbmVzIGEgZ2VuZXJpYyBzaW1wbGlmaWVkIG1lY2hhbmlzbSB0byB1c2UNCiAgIEJpZGly ZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgd2l0aCBsYXJnZSBwb3J0aW9ucyBv Zg0KICAgbmVnb3RpYXRpb24gYXNwZWN0cyBlbGltaW5hdGVkLCBhbmQgdG8gYWxsb3cgZnVsbCBh bmQgcGFydGlhbA0KICAgcmVhY2hhYmlsaXR5IHZhbGlkYXRpb25zLiAgRm9yIE1QTFMgYmFzZWQg QkZELCBleHRlbnNpb25zIHRvIHRoZQ0KICAgZ2VuZXJpYyBtZWNoYW5pc20gYXJlIGRlZmluZWQg Zm9yIEJGRCB0byBwZXJmb3JtIGEgbGV2ZWwgb2YgbGFiZWwNCiAgIHZlcmlmaWNhdGlvbnMuDQoN ClNlcGFyYXRlIGRyYWZ0cyBkZXNjcmliaW5nIElQIHByb2NlZHVyZXMgYW5kIFNlZ21lbnQgUm91 dGluZyBwcm9jZWR1cmVzIGZvciBTZWFtbGVzcyBCRkQgaGF2ZSBhbHNvIGJlZW4gcG9zdGVkLg0K DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWFraXlhLWJmZC1zZWFtbGVzcy1pcC0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtaXANCkh0 bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYWtpeWEtYmZk LXNlYW1sZXNzLWlwLTAwDQoNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLXNyLTAwLnR4dA0KU3RhdHVz OiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFraXlhLWJm ZC1zZWFtbGVzcy1zcg0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3Mtc3ItMDANCg0KU2Vla2luZyBjb21tZW50cyBhbmQg ZmVlZGJhY2tzLg0KDQpSZWdhcmRzLA0KU2VhbWxlc3MgQkZEIEF1dGhvcnMNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IEZyaWRheSwgSnVuZSAwNywg MjAxMyAxOjE2IFBNDQo+IFRvOiBEYXZpZCBXYXJkICh3YXJkZCk7IERhdmlkIFdhcmQgKHdhcmRk KTsgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpOw0KPiBOb2JvIEFraXlhIChub2JvKQ0KPiBT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWFraXlhLWJmZC1zZWFt bGVzcy1iYXNlLTAwLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1h a2l5YS1iZmQtc2VhbWxlc3MtYmFzZS0wMC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBOb2JvIEFraXlhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4gcmVwb3NpdG9y eS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UNCj4gUmV2 aXNpb246CSAwMA0KPiBUaXRsZToJCSBTZWFtbGVzcyBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcg RGV0ZWN0aW9uIChCRkQpIHdpdGgNCj4gTVBMUyBMYWJlbCBWZXJpZmljYXRpb24gRXh0ZW5zaW9u DQo+IENyZWF0aW9uIGRhdGU6CSAyMDEzLTA2LTA3DQo+IEdyb3VwOgkJIEluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KPiBOdW1iZXIgb2YgcGFnZXM6IDE1DQo+IFVSTDogICAgICAgICAgICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLQ0K PiBiYXNlLTAwLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWJhc2UNCj4gSHRtbGl6ZWQ6ICAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtYmFz ZS0wMA0KPiANCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5l cyBhIGdlbmVyaWMgc2ltcGxpZmllZCBtZWNoYW5pc20gdG8gdXNlDQo+ICAgIEJpZGlyZWN0aW9u YWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgd2l0aCBsYXJnZSBwb3J0aW9ucyBvZg0KPiAg ICBuZWdvdGlhdGlvbiBhc3BlY3RzIGVsaW1pbmF0ZWQsIGFuZCB0byBhbGxvdyBmdWxsIGFuZCBw YXJ0aWFsDQo+ICAgIHJlYWNoYWJpbGl0eSB2YWxpZGF0aW9ucy4gIEZvciBNUExTIGJhc2VkIEJG RCwgZXh0ZW5zaW9ucyB0byB0aGUNCj4gICAgZ2VuZXJpYyBtZWNoYW5pc20gYXJlIGRlZmluZWQg Zm9yIEJGRCB0byBwZXJmb3JtIGEgbGV2ZWwgb2YgbGFiZWwNCj4gICAgdmVyaWZpY2F0aW9ucy4N Cj4gDQo+IA0KPiANCj4gDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From adrian@olddog.co.uk Sat Jun 8 04:14:13 2013 Return-Path: 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 24AA221F99CF for ; Sat, 8 Jun 2013 04:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 TmcnpAiqzTkM for ; Sat, 8 Jun 2013 04:14:07 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 61D7021F99B6 for ; Sat, 8 Jun 2013 04:13:56 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r58BDr0t004507; Sat, 8 Jun 2013 12:13:53 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r58BDpBP004494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 8 Jun 2013 12:13:52 +0100 From: "Adrian Farrel" To: References: In-Reply-To: Subject: Changing chairs Date: Sat, 8 Jun 2013 12:13:46 +0100 Message-ID: <0bf401ce6439$3f61f1a0$be25d4e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5kOGyI/CszryxhRmSB3pYmp6nA0wAAHRag Content-Language: en-gb Cc: Jeff Haas , "David Ward \(wardd\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 11:14:13 -0000 Hi, After many years as co-chair for BFD leading and driving the technology, Dave Ward has decided to step down to concentrate on his day job and to make way for fresh blood. I'd like to take this opportunity to thank Dave for the effort he put in in this role. Nobo Akiya has kindly agreed to step up to the plate to work with Jeff as the new co-chair. I wish him luck and hope you will all support him in the role. For transparency, please know that Nobo is employed by Cisco. Thanks, Adrian From nobo@cisco.com Sat Jun 8 07:30:32 2013 Return-Path: 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 CC1B021F9A14 for ; Sat, 8 Jun 2013 07:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 g91Nl4xruWeU for ; Sat, 8 Jun 2013 07:30:27 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4525F21F99DE for ; Sat, 8 Jun 2013 07:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1222; q=dns/txt; s=iport; t=1370701827; x=1371911427; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qct9opYcGUyOFaDb/TLUw3gZcmg8Hb6P1KvSAaOfvEw=; b=VhLC2WduN5KTU3bUW+tV0znkeK/1FjhuoWMWpiYJHz5oZmFxdMZI9ESK ZUVEGxHY2zfCvqLRcKU0erD79y/6nYIsJHfBoOifDDeIUAletznJZuqga FqO9ZX6WCB3o0k3r+1APIxI69Q7JFD5LTvvxGbx4vymVsZZOn61WoUgtI w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAFE/s1GtJXG8/2dsb2JhbABagmgheb49eRZ0giMBAQEEOj8MBAIBCBEEAQELFAkHMhQJCAEBBAENBQiIBQG8Do8HMQcGgnlhA6kCgw+CJw X-IronPort-AV: E=Sophos;i="4.87,827,1363132800"; d="scan'208";a="220427549" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 08 Jun 2013 14:30:26 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r58EUQ3J001048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Jun 2013 14:30:26 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Sat, 8 Jun 2013 09:30:26 -0500 From: "Nobo Akiya (nobo)" To: "adrian@olddog.co.uk" , "rtg-bfd@ietf.org" Subject: RE: Changing chairs Thread-Topic: Changing chairs Thread-Index: Ac5kOGyI/CszryxhRmSB3pYmp6nA0wAAHRagAAaAsBA= Date: Sat, 8 Jun 2013 14:30:25 +0000 Message-ID: References: <0bf401ce6439$3f61f1a0$be25d4e0$@olddog.co.uk> In-Reply-To: <0bf401ce6439$3f61f1a0$be25d4e0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.188] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jeff Haas , "David Ward \(wardd\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 14:30:32 -0000 First of all, I'd like to thank Dave for incredible effort and leadership w= ith BFD for past years. Secondly, I'd like to state that I believe BFD has tremendously improved th= e internet and has potential to make even further improvements. I am very excited about taking on this new role and I am very excited about= working with all BFD WG members to push/poll BFD to see where we can go. Best Regards, Nobo > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Saturday, June 08, 2013 7:14 AM > To: rtg-bfd@ietf.org > Cc: David Ward (wardd); Jeff Haas; Nobo Akiya (nobo) > Subject: Changing chairs >=20 > Hi, >=20 > After many years as co-chair for BFD leading and driving the technology, > Dave Ward has decided to step down to concentrate on his day job and to > make way for fresh blood. I'd like to take this opportunity to thank Dave= for > the effort he put in in this role. >=20 > Nobo Akiya has kindly agreed to step up to the plate to work with Jeff as= the > new co-chair. I wish him luck and hope you will all support him in the ro= le. >=20 > For transparency, please know that Nobo is employed by Cisco. >=20 > Thanks, > Adrian From internet-drafts@ietf.org Thu Jun 13 01:21:00 2013 Return-Path: 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 07BB821F99E9; Thu, 13 Jun 2013 01:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 2mR+CxO-875Y; Thu, 13 Jun 2013 01:20:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8F621F9A6E; Thu, 13 Jun 2013 01:20:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-on-lags-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130613082055.10506.67254.idtracker@ietfa.amsl.com> Date: Thu, 13 Jun 2013 01:20:55 -0700 Cc: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 08:21:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : Bidirectional Forwarding Detection (BFD) on Link Aggrega= tion Group (LAG) Interfaces Author(s) : Manav Bhatia Mach(Guoyi) Chen Sami Boutros Marc Binderberger Jeffrey Haas Filename : draft-ietf-bfd-on-lags-01.txt Pages : 11 Date : 2013-06-13 Abstract: This document proposes a mechanism to run BFD on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link. This mechanism allows the verification of member link continuity, either in combination with, or in absence of, LACP. It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of layer 3 bidirectional forwarding. This mechanism utilizes a well-known UDP port distinct from that of single-hop BFD over IP. This new UDP port removes the ambiguity of BFD over LAG packets from BFD over single-hop IP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-on-lags-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-on-lags-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From marc@sniff.de Thu Jun 13 01:42:03 2013 Return-Path: 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 E73AF21F99B2 for ; Thu, 13 Jun 2013 01:42:02 -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 gqfLpJ7JgV8m for ; Thu, 13 Jun 2013 01:42:01 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D32C21F8930 for ; Thu, 13 Jun 2013 01:42:01 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 6758A2AA0F; Thu, 13 Jun 2013 08:41:58 +0000 (GMT) Date: Thu, 13 Jun 2013 10:41:55 +0200 From: Marc Binderberger To: Gregory Mirsky Message-ID: <20130613104155129872.e8a3c595@sniff.de> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B49D4B5@eusaamb103.ericsson.se> References: <20130510221344.9328.58926.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B49CFFD@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B49D4B5@eusaamb103.ericsson.se> Subject: RE: I-D Action: draft-ietf-bfd-on-lags-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 08:42:03 -0000 Hello Gregory & BFD experts, my apology, I forgot to publish the updated version. Happened now https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags We have moved one section into the appendix, following your feedback that the particular section content is more a "best practise" than a standard definition. Section 3 (formerly 3.1) got a bit of a cleanup and we are more explicit now with the MUST/MAY/NOT wording to avoid confusion what we mean. Best regards, Marc On Tue, 21 May 2013 19:04:42 +0000, Gregory Mirsky wrote: > Hi Marc, > thank you for most expedient response. Please find my notes in-lined > and tagged with GIM>>, > > Regards, > Greg > > > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Monday, May 20, 2013 3:54 PM > To: Gregory Mirsky > Cc: rtg-bfd@ietf.org > Subject: Re: I-D Action: draft-ietf-bfd-on-lags-00.txt > > > Hello Greg, > > thanks for your feedback! > > Hmm. It's true that section 3.2 is not necessary to get BFD on lags > flying, it is about details implementors should consider. We are > actually discussing section 3.2 and plan to simplify the text and add > explanations. Couple of days of text smithing, I hope, then we can > extend the discussion to the list. > > GIM>> Absolutely. > > But 3.1 ... if we remove it then we run into interoperability problems: > > (a) first BFD, then LACP up > (in other words: BFD does not depend on LACP but LACP depends on BFD) > (b) first LACP, then BFD up > (in other words: LACP does not depend on BFD but BFD depends on LACP) > (c) LACP and BFD are mutually independent > > (a) and (b) are not interoperable. We had to make a choice. The > consideration from the LAG experts was to use LACP (if enabled) to > organize the LAG before starting BFD, i.e. solution (b). > > GIM>> You're concerned with LAG interoperability, not > interoperability of micro-BFD as fully addressed without Section 3. > Integration of micro-BFD and LACP is implementation issue. > Interoperability or lack of thereof is result of particular > implementation desicions. > Sure, we could have everyone sort it out themselves that the two > allowed ways to influence the LAG > > (A) BFD influences the per-port MAC operational flag > (B) BFD influences the load-balance algorithm > > are not independent from (a)/(b)/(c) above, e.g. (A) and (b)/(c) > cannot be combined. Instead we explicitly mentioned (B) is used, > based on the decision for (b). > > GIM>> I think that IETF document can stop at mapping BFD state > machine to Actor Port states of IEEE 802.1AX. > > This is not BCP or informal, in my opinion. > > > Regarding the language: which aspects do you think are not acceptable > to define a new standard and need to be changed? > > GIM>> No MUST or SHOULD in Section 3. > > > Thanks & Regards, > Marc > > > > On 2013-05-20, at 23:29 , Gregory Mirsky wrote: >> Dear Authors, et al., >> I agree with everything in the latest version of the document but >> inclusion of Section 3. I think that what is discussed in the >> section and use of normative language are outside of the scope of >> BFD WG charter: >> Provide one or more mechanisms to run BFD over Link Aggregation >> Group Interfaces. >> >> Content of the section seems more suitable as Informational or BCP >> with appropriate changes in use and interpretation of RFC 2119 >> language. >> >> Regards, >> Greg >> >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >> Behalf Of internet-drafts@ietf.org >> Sent: Friday, May 10, 2013 3:14 PM >> To: i-d-announce@ietf.org >> Cc: rtg-bfd@ietf.org >> Subject: I-D Action: draft-ietf-bfd-on-lags-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Bidirectional Forwarding Detection >> Working Group of the IETF. >> >> Title : Bidirectional Forwarding Detection (BFD) >> on Link Aggregation Group (LAG) Interfaces >> Author(s) : Manav Bhatia >> Mach(Guoyi) Chen >> Sami Boutros >> Marc Binderberger >> Jeffrey Haas >> Filename : draft-ietf-bfd-on-lags-00.txt >> Pages : 11 >> Date : 2013-05-10 >> >> Abstract: >> This document proposes a mechanism to run BFD on Link Aggregation >> Group (LAG) interfaces. It does so by running an independent >> Asynchronous mode BFD session on every LAG member link. >> >> This mechanism allows the verification of member link continuity, >> either in combination with, or in absence of, LACP. It provides a >> shorter detection time than what LACP offers. The continuity check >> can also cover elements of layer 3 bidirectional forwarding. >> >> This mechanism utilizes a well-known UDP port distinct from that of >> single-hop BFD over IP. This new UDP port removes the ambiguity of >> BFD over LAG packets from BFD over single-hop IP. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-bfd-on-lags-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> > > > From internet-drafts@ietf.org Mon Jun 17 07:57:32 2013 Return-Path: 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 4446221F9CE3; Mon, 17 Jun 2013 07:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 tvuZcWrqQORV; Mon, 17 Jun 2013 07:57:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCC321F9B90; Mon, 17 Jun 2013 07:57:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-mib-13.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130617145727.8909.46149.idtracker@ietfa.amsl.com> Date: Mon, 17 Jun 2013 07:57:27 -0700 Cc: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 14:57:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : BFD Management Information Base Author(s) : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-mib-13.txt Pages : 38 Date : 2013-06-17 Abstract: This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-mib-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-mib-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobo@cisco.com Mon Jun 17 08:01:12 2013 Return-Path: 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 E64A821F9C26; Mon, 17 Jun 2013 08:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 KTsZKc7IqwbJ; Mon, 17 Jun 2013 08:01:05 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E0A6721F92B8; Mon, 17 Jun 2013 08:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2312; q=dns/txt; s=iport; t=1371481265; x=1372690865; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZzsMnCp5joLI7cUKpi1g4j9DzOcoj1pYgAZWSxX3kqI=; b=ci5haTP4lVIbnmHhr8/Xth5qyyEE+lHS+5N2YpIG8Xwhbjwnv220ojlt vB3Tu4dtA5E2L8+I93AS5T0Zc/2Dn/Fel8oDoJSUmRin6t5LND2ffypHR Zlspbr6fckj76g2lVMVyCuULmCcDRhbIW2zOIU8ov6IQRorco/E5A+gNC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAHojv1GtJV2Z/2dsb2JhbABagmghMUMGgn+7aQ1wFnSCIwEBAQQjEUUMBAIBCBEEAQEDAgYdAwICAjAUAQgIAgQBDQUIAQuHegEGBagLkSOBJo1wFhsHBoJGM2EDmGqQGoMPgig X-IronPort-AV: E=Sophos;i="4.87,881,1363132800"; d="scan'208";a="223764994" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 17 Jun 2013 15:01:04 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5HF14tC023604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Jun 2013 15:01:04 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 17 Jun 2013 10:01:04 -0500 From: "Nobo Akiya (nobo)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-mib-13.txt Thread-Topic: I-D Action: draft-ietf-bfd-mib-13.txt Thread-Index: AQHOa2skalLir+Mjc0WhcrVbVBSCnpk5/4BA Date: Mon, 17 Jun 2013 15:01:03 +0000 Message-ID: References: <20130617145727.8909.46149.idtracker@ietfa.amsl.com> In-Reply-To: <20130617145727.8909.46149.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Thomas Nadeau , "rtg-bfd@ietf.org" , "Zafar Ali \(zali\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 15:01:12 -0000 SGVsbG8gQkZEIFdHIE1lbWJlcnMsDQoNCldlIGhhdmUgcm9sbGVkIG91dCAtMTMgb2YgQkZEIE1J Qi4NCg0KQ2hhbmdlcyBhcmUgdmVyeSBtaW5vci4NCg0KKDEpIFBvcnRlZCAtMTIgdG8gWE1MLg0K KDIpIEZpeGVkIHNldmVyYWwgdHlwb3MuDQooMykgQWRkZWQgbWlzc2luZyByZWZlcmVuY2VzLg0K DQpSZWdhcmRzLA0KTm9ibw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IHJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9y Z10gT24NCj4gQmVoYWxmIE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiBTZW50OiBNb25k YXksIEp1bmUgMTcsIDIwMTMgMTA6NTcgQU0NCj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0K PiBDYzogcnRnLWJmZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm LWJmZC1taWItMTMudHh0DQo+IA0KPiANCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+IGRpcmVjdG9yaWVzLg0KPiAg VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5n IERldGVjdGlvbiBXb3JraW5nDQo+IEdyb3VwIG9mIHRoZSBJRVRGLg0KPiANCj4gCVRpdGxlICAg ICAgICAgICA6IEJGRCBNYW5hZ2VtZW50IEluZm9ybWF0aW9uIEJhc2UNCj4gCUF1dGhvcihzKSAg ICAgICA6IFRob21hcyBELiBOYWRlYXUNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBaYWZh ciBBbGkNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBOb2JvIEFraXlhDQo+IAlGaWxlbmFt ZSAgICAgICAgOiBkcmFmdC1pZXRmLWJmZC1taWItMTMudHh0DQo+IAlQYWdlcyAgICAgICAgICAg OiAzOA0KPiAJRGF0ZSAgICAgICAgICAgIDogMjAxMy0wNi0xNw0KPiANCj4gQWJzdHJhY3Q6DQo+ ICAgIFRoaXMgZHJhZnQgZGVmaW5lcyBhIHBvcnRpb24gb2YgdGhlIE1hbmFnZW1lbnQgSW5mb3Jt YXRpb24gQmFzZSAoTUlCKQ0KPiAgICBmb3IgdXNlIHdpdGggbmV0d29yayBtYW5hZ2VtZW50IHBy b3RvY29scyBpbiB0aGUgSW50ZXJuZXQgY29tbXVuaXR5Lg0KPiAgICBJbiBwYXJ0aWN1bGFyLCBp dCBkZXNjcmliZXMgbWFuYWdlZCBvYmplY3RzIGZvciBtb2RlbGluZw0KPiAgICBCaWRpcmVjdGlv bmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIHByb3RvY29sLg0KPiANCj4gDQo+IA0KPiBU aGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1iZmQtbWliDQo+IA0KPiBU aGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZmQtbWliLTEzDQo+IA0KPiBBIGRpZmYgZnJv bSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYmZkLW1pYi0xMw0KPiANCj4gDQo+IEludGVy bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRw Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0K From jhaas@slice.pfrc.org Tue Jun 18 14:05:20 2013 Return-Path: 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 8593411E80F9 for ; Tue, 18 Jun 2013 14:05:20 -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 GjIPOyTZW6cH for ; Tue, 18 Jun 2013 14:05:15 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7493921F9799 for ; Tue, 18 Jun 2013 14:05:15 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 26163C626; Tue, 18 Jun 2013 17:05:15 -0400 (EDT) Date: Tue, 18 Jun 2013 17:05:15 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: [nitinb@juniper.net: Re: IPR declaration for upcoming draft-ietf-bfd-bfd-on-lag] Message-ID: <20130618210515.GI3241@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 21:05:20 -0000 Putting into the list archive: ----- Forwarded message from Nitin Bahadur ----- Date: Fri, 10 May 2013 18:28:10 +0000 From: Nitin Bahadur To: Jeffrey Haas Subject: Re: IPR declaration for upcoming draft-ietf-bfd-bfd-on-lag None that I'm aware of... Thanks Nitin Bahadur On 5/10/13 10:16 AM, "Jeffrey Haas" wrote: >Greetings. > >We should be seeing publication of the BFD on LAGs spec shortly. The BFD >working group had previously agreed to take on this work. As part of >making >this a working group draft, I will be asking each of the authors >associated >with this draft to make a positive statement to the list as to whether >they >are aware of any IPR associated with the draft. > >Please take this opportunity to do the necessary introspection prior to >this >call. > >-- Jeff > ----- End forwarded message ----- From jhaas@slice.pfrc.org Tue Jun 18 14:13:05 2013 Return-Path: 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 DD42221F9AEB for ; Tue, 18 Jun 2013 14:13:05 -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 2vlwcE+LG7q0 for ; Tue, 18 Jun 2013 14:13:01 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C936221F9AE8 for ; Tue, 18 Jun 2013 14:13:01 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8771AC626; Tue, 18 Jun 2013 17:13:01 -0400 (EDT) Date: Tue, 18 Jun 2013 17:13:01 -0400 From: Jeffrey Haas To: manav.bhatia@alcatel-lucent.com, mach@huawei.com, paul.hitchen@bt.com, swallow@cisco.com, liang_tsing@huawei.com, guoliang@gsta.com, jeff.tantsura@ericsson.com Subject: Re: Reminder about Contributor responsibilities regarding IPR; BFD over LAG Message-ID: <20130618211301.GK3241@pfrc> References: <20120220210102.GL6584@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120220210102.GL6584@slice> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 21:13:06 -0000 We could use a few more public acknowledgments as to whether there is any known IPR. -- Jeff On Mon, Feb 20, 2012 at 04:01:02PM -0500, Jeffrey Haas wrote: > Working Group, > > There's been good energy and collaboration on the BFD over LAG discussion. > Since there's been good consensus regarding a new charter item covering that > work, I've requested our AD to have our charter amended. > > This is a good time to point out that part of the reason why there's so much > energy on the topic is a number of vendors support various flavors of > proprietary BFD over LAG and we're in need of an open, interoperable > solution. To that end, let me please remind you of your responsibilities as > IETF Contributors: > > http://www.ietf.org/about/note-well.html > http://tools.ietf.org/html/rfc3979 > etc. > > While it is perhaps early to request IPR disclosure prior to having the work > in a draft-ietf-bfd- document, we're at the point of gaining consensus over > design decisions for what should be in such a draft. To help the WG make an > informed decision about the solution, please gather and publish your IPR > disclosures. > > -- Jeff & Dave From mach.chen@huawei.com Tue Jun 18 17:41:04 2013 Return-Path: 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 C4C1921F93E0 for ; Tue, 18 Jun 2013 17:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 uIIqqc0Wqr95 for ; Tue, 18 Jun 2013 17:41:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5E321F8FA1 for ; Tue, 18 Jun 2013 17:40:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASO87684; Wed, 19 Jun 2013 00:40:57 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 19 Jun 2013 01:40:34 +0100 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 19 Jun 2013 01:40:56 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.243]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.007; Wed, 19 Jun 2013 08:40:49 +0800 From: Mach Chen To: Jeffrey Haas , "manav.bhatia@alcatel-lucent.com" , "paul.hitchen@bt.com" , "swallow@cisco.com" , Wangzuliang , "guoliang@gsta.com" , "jeff.tantsura@ericsson.com" Subject: RE: Reminder about Contributor responsibilities regarding IPR; BFD over LAG Thread-Topic: Reminder about Contributor responsibilities regarding IPR; BFD over LAG Thread-Index: AQHObGjCTnpVkfmbukyCAjrIbeyiJJk8MXSQ Date: Wed, 19 Jun 2013 00:40:49 +0000 Message-ID: References: <20120220210102.GL6584@slice> <20130618211301.GK3241@pfrc> In-Reply-To: <20130618211301.GK3241@pfrc> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 00:41:04 -0000 Hi Jeff, I am not aware of any IPR applies to this draft. Best regards, Mach > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of > Jeffrey Haas > Sent: Wednesday, June 19, 2013 5:13 AM > To: manav.bhatia@alcatel-lucent.com; Mach Chen; paul.hitchen@bt.com; > swallow@cisco.com; Wangzuliang; guoliang@gsta.com; > jeff.tantsura@ericsson.com > Cc: rtg-bfd@ietf.org > Subject: Re: Reminder about Contributor responsibilities regarding IPR; B= FD over > LAG >=20 > We could use a few more public acknowledgments as to whether there is any > known IPR. >=20 > -- Jeff >=20 > On Mon, Feb 20, 2012 at 04:01:02PM -0500, Jeffrey Haas wrote: > > Working Group, > > > > There's been good energy and collaboration on the BFD over LAG discussi= on. > > Since there's been good consensus regarding a new charter item covering= that > > work, I've requested our AD to have our charter amended. > > > > This is a good time to point out that part of the reason why there's so= much > > energy on the topic is a number of vendors support various flavors of > > proprietary BFD over LAG and we're in need of an open, interoperable > > solution. To that end, let me please remind you of your responsibiliti= es as > > IETF Contributors: > > > > http://www.ietf.org/about/note-well.html > > http://tools.ietf.org/html/rfc3979 > > etc. > > > > While it is perhaps early to request IPR disclosure prior to having the= work > > in a draft-ietf-bfd- document, we're at the point of gaining consensus = over > > design decisions for what should be in such a draft. To help the WG ma= ke an > > informed decision about the solution, please gather and publish your IP= R > > disclosures. > > > > -- Jeff & Dave From paul.hitchen@bt.com Wed Jun 19 00:53:54 2013 Return-Path: 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 0F16821F9EE2 for ; Wed, 19 Jun 2013 00:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] 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 U0FCsddDef8R for ; Wed, 19 Jun 2013 00:53:49 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id D5C1121F9CCD for ; Wed, 19 Jun 2013 00:53:48 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 19 Jun 2013 08:53:47 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.53]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Wed, 19 Jun 2013 08:53:47 +0100 From: To: , , , , , , Date: Wed, 19 Jun 2013 08:53:45 +0100 Subject: RE: Reminder about Contributor responsibilities regarding IPR; BFD over LAG Thread-Topic: Reminder about Contributor responsibilities regarding IPR; BFD over LAG Thread-Index: Ac5saJ8enGfUUt7rTyi7SN+/KInJDgAWQ0uQ Message-ID: <4BF3B24B46BEA246BB7D832A32CF7061363BD11BDA@EMV65-UKRD.domain1.systemhost.net> References: <20120220210102.GL6584@slice> <20130618211301.GK3241@pfrc> In-Reply-To: <20130618211301.GK3241@pfrc> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 07:53:54 -0000 Jeff, Not aware of any IPR that applies to this draft. regards, Paul -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 Sent: 18 June 2013 22:13 To: manav.bhatia@alcatel-lucent.com; mach@huawei.com; Hitchen,PS,Paul,TNK2 = R; swallow@cisco.com; liang_tsing@huawei.com; guoliang@gsta.com; jeff.tants= ura@ericsson.com Cc: rtg-bfd@ietf.org Subject: Re: Reminder about Contributor responsibilities regarding IPR; BFD= over LAG We could use a few more public acknowledgments as to whether there is any k= nown IPR. -- Jeff On Mon, Feb 20, 2012 at 04:01:02PM -0500, Jeffrey Haas wrote: > Working Group, >=20 > There's been good energy and collaboration on the BFD over LAG discussion= . > Since there's been good consensus regarding a new charter item=20 > covering that work, I've requested our AD to have our charter amended. >=20 > This is a good time to point out that part of the reason why there's=20 > so much energy on the topic is a number of vendors support various=20 > flavors of proprietary BFD over LAG and we're in need of an open,=20 > interoperable solution. To that end, let me please remind you of your=20 > responsibilities as IETF Contributors: >=20 > http://www.ietf.org/about/note-well.html > http://tools.ietf.org/html/rfc3979 > etc. >=20 > While it is perhaps early to request IPR disclosure prior to having=20 > the work in a draft-ietf-bfd- document, we're at the point of gaining=20 > consensus over design decisions for what should be in such a draft. =20 > To help the WG make an informed decision about the solution, please=20 > gather and publish your IPR disclosures. >=20 > -- Jeff & Dave From wim.henderickx@alcatel-lucent.com Wed Jun 19 03:41:23 2013 Return-Path: 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 ADE6721F9A1B for ; Wed, 19 Jun 2013 03:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 T9FfAxxiHlYz for ; Wed, 19 Jun 2013 03:41:18 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id EFA4D21F99AE for ; Wed, 19 Jun 2013 03:41:17 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r5JAeEac023518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jun 2013 05:40:14 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r5JAe0P5031225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 06:40:10 -0400 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 19 Jun 2013 06:40:01 -0400 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.100]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 19 Jun 2013 12:39:39 +0200 From: "Henderickx, Wim (Wim)" To: "paul.hitchen@bt.com" , "jhaas@pfrc.org" , "Bhatia, Manav (Manav)" , "mach@huawei.com" , "swallow@cisco.com" , "liang_tsing@huawei.com" , "guoliang@gsta.com" , "jeff.tantsura@ericsson.com" Subject: Re: Reminder about Contributor responsibilities regarding IPR; BFD over LAG Thread-Topic: Reminder about Contributor responsibilities regarding IPR; BFD over LAG Thread-Index: AQHObNlMKN552NEKnkWF1RCK8cHQkg== Date: Wed, 19 Jun 2013 10:39:38 +0000 Message-ID: In-Reply-To: <4BF3B24B46BEA246BB7D832A32CF7061363BD11BDA@EMV65-UKRD.domain1.systemhost.net> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <3275006F90BFA346981E39B3C0A46DFC@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 10:41:23 -0000 I am not aware of IPR either. On 19/06/13 00:53, "paul.hitchen@bt.com" wrote: >Jeff, > >Not aware of any IPR that applies to this draft. > >regards, > >Paul > >-----Original Message----- >From: Jeffrey Haas [mailto:jhaas@pfrc.org] >Sent: 18 June 2013 22:13 >To: manav.bhatia@alcatel-lucent.com; mach@huawei.com; >Hitchen,PS,Paul,TNK2 R; swallow@cisco.com; liang_tsing@huawei.com; >guoliang@gsta.com; jeff.tantsura@ericsson.com >Cc: rtg-bfd@ietf.org >Subject: Re: Reminder about Contributor responsibilities regarding IPR; >BFD over LAG > >We could use a few more public acknowledgments as to whether there is any >known IPR. > >-- Jeff > >On Mon, Feb 20, 2012 at 04:01:02PM -0500, Jeffrey Haas wrote: >> Working Group, >>=20 >> There's been good energy and collaboration on the BFD over LAG >>discussion. >> Since there's been good consensus regarding a new charter item >> covering that work, I've requested our AD to have our charter amended. >>=20 >> This is a good time to point out that part of the reason why there's >> so much energy on the topic is a number of vendors support various >> flavors of proprietary BFD over LAG and we're in need of an open, >> interoperable solution. To that end, let me please remind you of your >> responsibilities as IETF Contributors: >>=20 >> http://www.ietf.org/about/note-well.html >> http://tools.ietf.org/html/rfc3979 >> etc. >>=20 >> While it is perhaps early to request IPR disclosure prior to having >> the work in a draft-ietf-bfd- document, we're at the point of gaining >> consensus over design decisions for what should be in such a draft. >> To help the WG make an informed decision about the solution, please >> gather and publish your IPR disclosures. >>=20 >> -- Jeff & Dave From swallow@cisco.com Wed Jun 19 11:34:52 2013 Return-Path: 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 BDC8821F9E92; Wed, 19 Jun 2013 11:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 cGFHWAX7eBiP; Wed, 19 Jun 2013 11:34:47 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C352421F9EA3; Wed, 19 Jun 2013 11:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1683; q=dns/txt; s=iport; t=1371666888; x=1372876488; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=soIAfAo8clleZVoD7iHcVR0/4xpD8/6rgq2+0zBu/oo=; b=KBCOGa7EfNQUdKKqHRKga5BpVlOIOMYFiTXR5kc253b/v32aJ7ig0iER SWilT74PlR+1y5FOrl6Xjt2NwIXXEhJvpC/b2O45gJ1obxUNGAUOYNNzq fFSmsB9mq/kyCg3YhCoV8prqvk2Zoc6y1louz+/2XkezYOOyMb44N91fZ Y=; X-IronPort-AV: E=Sophos;i="4.87,899,1363132800"; d="scan'208";a="224914175" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 19 Jun 2013 18:34:47 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5JIYldw014256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 18:34:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Wed, 19 Jun 2013 13:34:46 -0500 From: "George Swallow (swallow)" To: "Marc Binderberger (mbinderb)" , Jeffrey Haas , "Carlos Pignataro (cpignata)" Subject: Re: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00 Thread-Topic: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00 Thread-Index: AQHOUyJ0KR3owsZ7XUmTbE5E/vEzCJkKAs8AgABMfICAM1KIgA== Date: Wed, 19 Jun 2013 18:34:45 +0000 Message-ID: <2FE467D3673DCE409A84D67EC2F607BB0FAA4D54@xmb-rcd-x10.cisco.com> In-Reply-To: <16E64FE6-0488-4228-8CCB-9D8DB1A637A4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.98.56.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <73BF71FD94C517419AC043EAEDC4514A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 19 Jun 2013 11:49:33 -0700 Cc: "Jeff Haas \(jhaas@juniper.net\)" , "Neil Ketley -X \(nketley - Ensoft Ltd at Cisco\)" , David Ward , "rtg-bfd@ietf.org" , "ipr-announce@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 18:34:52 -0000 Same here. George On 5/17/13 6:50 PM, "Marc Binderberger (mbinderb)" wrote: >Hello Jeff, > >same here, https://datatracker.ietf.org/ipr/2081/ is my understanding of >IPR for this draft. Not aware of any other claims. > > >Regards, Marc > > > >On 2013-05-17, at 20:16 , Carlos Pignataro (cpignata) wrote: > >>=20 >> On May 17, 2013, at 1:17 PM, Jeffrey Haas wrote: >>=20 >>> On Fri, May 17, 2013 at 09:39:30AM -0700, IETF Secretariat wrote: >>>>=20 >>>> Dear Manav Bhatia, Mach Chen, Sami Boutros, Marc Binderberger, >>>>Jeffrey Haas: >>>>=20 >>>> An IPR disclosure that pertains to your Internet-Draft entitled >>>>"Bidirectional >>>> Forwarding Detection (BFD) on Link Aggregation Group (LAG) >>>>Interfaces" (draft- >>>> ietf-bfd-on-lags) was submitted to the IETF Secretariat on 2013-05-15 >>>>and has >>>> been posted on the "IETF Page of Intellectual Property Rights >>>>Disclosures" >>>> (https://datatracker.ietf.org/ipr/2081/). The title of the IPR >>>>disclosure is >>>> "Cisco's Statement of IPR Related to draft-ietf-bfd-on-lags-00.""); >>>=20 >>> FYI: >>> http://www.google.com/patents/US8111611 >>>=20 >>> Sami, Marc, George, Nobo, Neil, Carlos - please acknowledge that this >>> completes your understanding of IPR on this draft and that you're not >>>aware >>> of any other claims. >>>=20 >>=20 >> Cisco has IPR on draft-ietf-bfd-on-lags-00 as disclosed in ID # 2081: >>https://datatracker.ietf.org/ipr/2081/ >>=20 >> I am not aware of any IPR related to the subject matter of this draft. >>=20 >> Thanks, >>=20 >> -- Carlos. >>=20 >>=20 >>> -- Jeff >>>=20 >>=20 > From internet-drafts@ietf.org Wed Jun 19 15:08:04 2013 Return-Path: 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 3A70621F9CD1; Wed, 19 Jun 2013 15:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 O7fOSiMW3Ygx; Wed, 19 Jun 2013 15:08:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C97CD21F9CA4; Wed, 19 Jun 2013 15:08:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-tc-mib-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130619220803.26580.18278.idtracker@ietfa.amsl.com> Date: Wed, 19 Jun 2013 15:08:03 -0700 Cc: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 22:08:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : Definitions of Textual Conventions (TCs) for Bidirection= al Forwarding Detection (BFD) Management Author(s) : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-tc-mib-02.txt Pages : 9 Date : 2013-06-19 Abstract: This draft defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Bidirectional Forwarding Detection (BFD) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD related MIB modules that would otherwise define their own representations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-tc-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-tc-mib-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobo@cisco.com Wed Jun 19 15:11:09 2013 Return-Path: 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 807F621F9BD0 for ; Wed, 19 Jun 2013 15:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 gsqCFh79iJG7 for ; Wed, 19 Jun 2013 15:11:04 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 539B821F9B85 for ; Wed, 19 Jun 2013 15:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2488; q=dns/txt; s=iport; t=1371679864; x=1372889464; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=N87KrLm0hF8ojDJilK8ciz18K1jSFAV9BXyJ/yLXG8s=; b=F5aYgDcvBfhLpZ5xMSbbFXs67l+B4qsIhOxdJJRx03AB4aVR2kmznD33 sxpp6wiWdMeiVnynkDWCfK0V+WPnsNQhZWfdpgY6XZ2Z2GQcSaKJhJzpp oQXb0A890hjFeYClOJOXaHPtsJ07wevf0BTnro4vLjPwEVGXh/CwMAqvM 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIHAN0rwlGtJXG//2dsb2JhbABagmghMUMGgwK8GQ1zFm0HgiMBAQEEIxFFDAQCAQgRBAEBAwIGHQMCAgIwFAEICAIEDgUIAYgFAQYFqkKRPoEmjWsxBwaCRzNhA5hqkBuDD4Io X-IronPort-AV: E=Sophos;i="4.87,900,1363132800"; d="scan'208";a="222030829" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 19 Jun 2013 22:11:03 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5JMB3Of008524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 22:11:03 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 19 Jun 2013 17:11:03 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-tc-mib-02.txt Thread-Topic: I-D Action: draft-ietf-bfd-tc-mib-02.txt Thread-Index: AQHObTmTtKimaIBhE0WX5z/Wht5hFZk9mPrA Date: Wed, 19 Jun 2013 22:11:03 +0000 Message-ID: References: <20130619220803.26580.18278.idtracker@ietfa.amsl.com> In-Reply-To: <20130619220803.26580.18278.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Thomas Nadeau , "Zafar Ali \(zali\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 22:11:09 -0000 SGVsbG8gQkZEIFdHIE1lbWJlcnMsDQoNCk9ubHkgY2hhbmdlcyBhcmU6DQoNCigxKSBQb3J0ZWQg QkZEIFRDIE1JQiAtMDEgdG8gWE1MLg0KKDIpIEZpeGVkIG9uZSB0eXBvLg0KDQpSZWdhcmRzLA0K Tm9ibw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJ0Zy1iZmQtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVo YWxmIE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiBTZW50OiBXZWRuZXNkYXksIEp1bmUg MTksIDIwMTMgNjowOCBQTQ0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IENjOiBydGct YmZkQGlldGYub3JnDQo+IFN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYmZkLXRjLW1p Yi0wMi50eHQNCj4gDQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gZGlyZWN0b3JpZXMuDQo+ICBUaGlzIGRy YWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0 aW9uIFdvcmtpbmcNCj4gR3JvdXAgb2YgdGhlIElFVEYuDQo+IA0KPiAJVGl0bGUgICAgICAgICAg IDogRGVmaW5pdGlvbnMgb2YgVGV4dHVhbCBDb252ZW50aW9ucyAoVENzKSBmb3IgQmlkaXJlY3Rp b25hbA0KPiBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBNYW5hZ2VtZW50DQo+IAlBdXRob3Io cykgICAgICAgOiBUaG9tYXMgRC4gTmFkZWF1DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg WmFmYXIgQWxpDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgTm9ibyBBa2l5YQ0KPiAJRmls ZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1iZmQtdGMtbWliLTAyLnR4dA0KPiAJUGFnZXMgICAg ICAgICAgIDogOQ0KPiAJRGF0ZSAgICAgICAgICAgIDogMjAxMy0wNi0xOQ0KPiANCj4gQWJzdHJh Y3Q6DQo+ICAgIFRoaXMgZHJhZnQgZGVmaW5lcyBhIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gQmFz ZSAoTUlCKSBtb2R1bGUgd2hpY2gNCj4gICAgY29udGFpbnMgVGV4dHVhbCBDb252ZW50aW9ucyB0 byByZXByZXNlbnQgY29tbW9ubHkgdXNlZCBCaWRpcmVjdGlvbmFsDQo+ICAgIEZvcndhcmRpbmcg RGV0ZWN0aW9uIChCRkQpIG1hbmFnZW1lbnQgaW5mb3JtYXRpb24uICBUaGUgaW50ZW50IGlzDQo+ ICAgIHRoYXQgdGhlc2UgVEVYVFVBTCBDT05WRU5USU9OUyAoVENzKSB3aWxsIGJlIGltcG9ydGVk IGFuZCB1c2VkIGluIEJGRA0KPiAgICByZWxhdGVkIE1JQiBtb2R1bGVzIHRoYXQgd291bGQgb3Ro ZXJ3aXNlIGRlZmluZSB0aGVpciBvd24NCj4gICAgcmVwcmVzZW50YXRpb25zLg0KPiANCj4gDQo+ IA0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoN Cj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1iZmQtdGMtbWli DQo+IA0KPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4g aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZmQtdGMtbWliLTAyDQo+IA0K PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYmZkLXRjLW1pYi0wMg0K PiANCj4gDQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3Vz IEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0K From prvs=2883e4235f=gregory.mirsky@ericsson.com Wed Jun 19 18:57:25 2013 Return-Path: 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 C927B21F9FB0 for ; Wed, 19 Jun 2013 18:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 sWm+XutXaeTP for ; Wed, 19 Jun 2013 18:57:19 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id A8D9A21F9F3E for ; Wed, 19 Jun 2013 18:57:19 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-ea-51c2617cc749 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 04.4A.05617.C7162C15; Thu, 20 Jun 2013 03:57:17 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 21:57:16 -0400 From: Gregory Mirsky To: Marc Binderberger Subject: RE: I-D Action: draft-ietf-bfd-on-lags-00.txt Thread-Topic: I-D Action: draft-ietf-bfd-on-lags-00.txt Thread-Index: AQHOTcu+41wx13zJGki3ilKRtslFy5kOnrBwgABigICAJIb6hIAKg35A Date: Thu, 20 Jun 2013 01:57:15 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B4B7CAA@eusaamb103.ericsson.se> References: <20130510221344.9328.58926.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B49CFFD@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B49D4B5@eusaamb103.ericsson.se> <20130613104155129872.e8a3c595@sniff.de> In-Reply-To: <20130613104155129872.e8a3c595@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B4B7CAAeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPiG5t4qFAg49rxS1mX/nPbPH5zzZG ByaPJUt+Mnm0ru5mCWCK4rZJSiwpC85Mz9O3S+DOmLLiBVvBjgWMFZO/PGJtYDzaxtjFyMEh IWAiseh5UhcjJ5ApJnHh3no2EFtI4CijxKR/RRD2ckaJy71KIDabgJHEi4097CC2iICqxN3X hxhBbGYBTYmmE5/B4sICZhITH21hhqgxl9ix/BsThO0msah9KVgNC1Dvpq1nweK8Ar4Sn2e1 A83hAtq1lEliz4o5YEM5BUwlDq7eDXYQI9Bx30+tYYJYJi5x68l8JoijBSSW7DnPDGGLSrx8 /I8VwlaWWPJkPwtEfb7Et72PGCGWCUqcnPmEZQKj6Cwko2YhKZuFpAwiriOxYPcnNghbW2LZ wtfMMPaZA4+ZkMUXMLKvYuQoLU4ty003MtzECIysYxJsjjsYF3yyPMQozcGiJM77/tSuQCGB 9MSS1OzU1ILUovii0pzU4kOMTBycIIJLqoHx0CnJRXbLb0qHy92803hb7tzMDBvz7QoONpNu Sq+dOuu7SLjYJsZpW9ZHutxlPGSRklO8Qa/s+YdVZ6davH2YX6tmaVe9ufrTkYwi24v/fHM4 K5ivuVdoM+bt2/p+xY9tsusy8iV0XigWnL8jMJd75s6T4cVrDLdtDZ33+Z/I5AuGXscTSnW2 KLEUZyQaajEXFScCAAt5hTt/AgAA Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 01:57:26 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B4B7CAAeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marc, et. al, Thank you for making me feel special by excluding from the "BFD experts" li= st ;-) As you probably expected, I have couple comments to the latest version. And= here they are: * Abstract correctly notes that distinct UDP port, to be allocated by= IANA, for micro-BFD will simplify concurrent support of single-hop over LA= G circuit and micro-BFD. I'll add that same can be said about scenario when= micro-BFD to run concurrently with multi-hop BFD over LAG circuit. * In the last paragraph on Introduction native Ethernet failure detec= tion mechanisms listed as 802.1ax and .3ah. I think these should be 802.1ag= and 802.3ah. * Section 3. First sentense in the second paragraph confuses me. Woul= d following be acceptable to authors "BFD can control whether a particular = LAG member link can be used by the load distribution algorithm"? * Same second paragraph in Section 3. I think that "MUST NOT" is too = restrictive since problem might be not in the forwarder but benign mis-conf= iguration. And this MUST NOT negated in the Appendix A for the case when mi= cro-BFD session added after LACP determined the member link being Up. Perha= ps it can be changed to "SHOULD NOT" and further explained that behavior mu= st be consistent across all member links on both nodes. Control of this beh= avior is obviously outside of scope for this document. Regards, Greg -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de] Sent: Thursday, June 13, 2013 1:42 AM To: Gregory Mirsky Cc: rtg-bfd@ietf.org Subject: RE: I-D Action: draft-ietf-bfd-on-lags-00.txt Hello Gregory & BFD experts, my apology, I forgot to publish the updated version. Happened now https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags We have moved one section into the appendix, following your feedback that t= he particular section content is more a "best practise" than a standard def= inition. Section 3 (formerly 3.1) got a bit of a cleanup and we are more ex= plicit now with the MUST/MAY/NOT wording to avoid confusion what we mean. Best regards, Marc On Tue, 21 May 2013 19:04:42 +0000, Gregory Mirsky wrote: > Hi Marc, > thank you for most expedient response. Please find my notes in-lined > and tagged with GIM>>, > > Regards, > Greg > > > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Monday, May 20, 2013 3:54 PM > To: Gregory Mirsky > Cc: rtg-bfd@ietf.org > Subject: Re: I-D Action: draft-ietf-bfd-on-lags-00.txt > > > Hello Greg, > > thanks for your feedback! > > Hmm. It's true that section 3.2 is not necessary to get BFD on lags > flying, it is about details implementors should consider. We are > actually discussing section 3.2 and plan to simplify the text and add > explanations. Couple of days of text smithing, I hope, then we can > extend the discussion to the list. > > GIM>> Absolutely. > > But 3.1 ... if we remove it then we run into interoperability problems: > > (a) first BFD, then LACP up > (in other words: BFD does not depend on LACP but LACP depends on BFD) > (b) first LACP, then BFD up > (in other words: LACP does not depend on BFD but BFD depends on LACP) > (c) LACP and BFD are mutually independent > > (a) and (b) are not interoperable. We had to make a choice. The > consideration from the LAG experts was to use LACP (if enabled) to > organize the LAG before starting BFD, i.e. solution (b). > > GIM>> You're concerned with LAG interoperability, not > interoperability of micro-BFD as fully addressed without Section 3. > Integration of micro-BFD and LACP is implementation issue. > Interoperability or lack of thereof is result of particular > implementation desicions. > Sure, we could have everyone sort it out themselves that the two > allowed ways to influence the LAG > > (A) BFD influences the per-port MAC operational flag > (B) BFD influences the load-balance algorithm > > are not independent from (a)/(b)/(c) above, e.g. (A) and (b)/(c) > cannot be combined. Instead we explicitly mentioned (B) is used, based > on the decision for (b). > > GIM>> I think that IETF document can stop at mapping BFD state > machine to Actor Port states of IEEE 802.1AX. > > This is not BCP or informal, in my opinion. > > > Regarding the language: which aspects do you think are not acceptable > to define a new standard and need to be changed? > > GIM>> No MUST or SHOULD in Section 3. > > > Thanks & Regards, > Marc > > > > On 2013-05-20, at 23:29 , Gregory Mirsky wrote: >> Dear Authors, et al., >> I agree with everything in the latest version of the document but >> inclusion of Section 3. I think that what is discussed in the section >> and use of normative language are outside of the scope of BFD WG >> charter: >> Provide one or more mechanisms to run BFD over Link Aggregation Group >> Interfaces. >> >> Content of the section seems more suitable as Informational or BCP >> with appropriate changes in use and interpretation of RFC 2119 >> language. >> >> Regards, >> Greg >> >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >> Behalf Of internet-drafts@ietf.org >> Sent: Friday, May 10, 2013 3:14 PM >> To: i-d-announce@ietf.org >> Cc: rtg-bfd@ietf.org >> Subject: I-D Action: draft-ietf-bfd-on-lags-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Bidirectional Forwarding Detection >> Working Group of the IETF. >> >> Title : Bidirectional Forwarding Detection (BFD) >> on Link Aggregation Group (LAG) Interfaces >> Author(s) : Manav Bhatia >> Mach(Guoyi) Chen >> Sami Boutros >> Marc Binderberger >> Jeffrey Haas >> Filename : draft-ietf-bfd-on-lags-00.txt >> Pages : 11 >> Date : 2013-05-10 >> >> Abstract: >> This document proposes a mechanism to run BFD on Link Aggregation >> Group (LAG) interfaces. It does so by running an independent >> Asynchronous mode BFD session on every LAG member link. >> >> This mechanism allows the verification of member link continuity, >> either in combination with, or in absence of, LACP. It provides a >> shorter detection time than what LACP offers. The continuity check >> can also cover elements of layer 3 bidirectional forwarding. >> >> This mechanism utilizes a well-known UDP port distinct from that of >> single-hop BFD over IP. This new UDP port removes the ambiguity of >> BFD over LAG packets from BFD over single-hop IP. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-bfd-on-lags-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> > > > --_000_7347100B5761DC41A166AC17F22DF1121B4B7CAAeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Marc, et. al,
Thank you for making me feel special by excluding from the "BFD e= xperts" list ;-)
As you probably expected, I have couple comments to the latest version= . And here they are:
  • Abstract correctly notes that distinct UDP port, to be allocated by IAN= A, for micro-BFD will simplify concurrent support of single-hop over LAG ci= rcuit and micro-BFD. I'll add that same can be said about scenario when mic= ro-BFD to run concurrently with multi-hop BFD over LAG circuit.
  • In the last paragraph on Introducti= on native Ethernet failure detection mechanisms listed as 802.1ax and .3ah.= I think these should be 802.1ag and 802.3ah.
  • Section 3. First sent= ense in the second paragraph confuses me. Would following be acceptable to = authors "BFD can control whether a particular LAG member link can be u= sed by the load distribution algorithm"?
  • Same second paragraph= in Section 3. I think that "MUST NOT" is too restrictive since p= roblem might be not in the forwarder but benign mis-configuration. And this= MUST NOT negated in the Appendix A for the case when micro-BFD session add= ed after LACP determined the member link being Up. Perhaps it can be changed to "SHOULD NOT&quo= t; and further explained that behavior must be consistent across all member= links on both nodes. Control of this behavior is obviously outside of scop= e for this document.
 
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: Marc Binderberger [mailto:marc@sniff.de]
Sent: Thursday, June 13, 2013 1:42 AM
To: Gregory Mirsky
Cc: rtg-bfd@ietf.org
Subject: RE: I-D Action: draft-ietf-bfd-on-lags-00.txt
 
Hello Gregory & BFD experts,
 
my apology, I forgot to publish the updated version. Happened now
 
 
We have moved one section into the appendix, following your feedback t= hat the particular section content is more a "best practise" than= a standard definition. Section 3 (formerly 3.1) got a bit of a cleanup and= we are more explicit now with the MUST/MAY/NOT wording to avoid confusion what we mean.
 
 
Best regards,
Marc
 
 
 
 
On Tue, 21 May 2013 19:04:42 +0000, Gregory Mirsky wrote:
> Hi Marc,
> thank you for most expedient response. Please find my notes in-li= ned
> and tagged with GIM>>,
> 
>     Regards,
>         Greg
>
>
> From: Marc Binderberger [mailto:marc@sniff.de]
> Sent: Monday, May 20, 2013 3:54 PM
> To: Gregory Mirsky
> Cc: rtg-bfd@ietf.org
> Subject: Re: I-D Action: draft-ietf-bfd-on-lags-00.txt
>
>
> Hello Greg,
>
> thanks for your feedback!
>
> Hmm. It's true that section 3.2 is not necessary to get BFD on la= gs
> flying, it is about details implementors should consider. We are =
> actually discussing section 3.2 and plan to simplify the text and= add
> explanations. Couple of days of text smithing, I hope, then we ca= n
> extend the discussion to the list.
>   
>  GIM>> Absolutely.
> 
> But 3.1 ... if we remove it then we run into interoperability pro= blems:
>
> (a) first BFD, then LACP up
> (in other words: BFD does not depend on LACP but LACP depends on = BFD)
> (b) first LACP, then BFD up
> (in other words: LACP does not depend on BFD but BFD depends on L= ACP)
> (c) LACP and BFD are mutually independent
>
> (a) and (b) are not interoperable. We had to make a choice. The <= /div>
> consideration from the LAG experts was to use LACP (if enabled) t= o
> organize the LAG before starting BFD, i.e. solution (b).
> 
> GIM>> You're concerned with LAG interoperability, not
> interoperability of micro-BFD as fully addressed without Section = 3.
> Integration of micro-BFD and LACP is implementation issue.
> Interoperability or lack of thereof is result of particular
> implementation desicions.
> Sure, we could have everyone sort it out themselves that the two =
> allowed ways to influence the LAG
>
> (A) BFD influences the per-port MAC operational flag
> (B) BFD influences the load-balance algorithm
>
> are not independent from (a)/(b)/(c) above, e.g. (A) and (b)/(c) =
> cannot be combined. Instead we explicitly mentioned (B) is used, = based
> on the decision for (b).
> 
> GIM>> I think that IETF document can stop at mapping BFD st= ate
> machine to Actor Port states of IEEE 802.1AX.
>
> This is not BCP or informal, in my opinion.
>
>
> Regarding the language: which aspects do you think are not accept= able
> to define a new standard and need to be changed?
> 
> GIM>> No MUST or SHOULD in Section 3.
>
>
> Thanks & Regards,
> Marc
>
>
>
> On 2013-05-20, at 23:29 , Gregory Mirsky wrote:
>> Dear Authors, et al.,
>> I agree with everything in the latest version of the document= but
>> inclusion of Section 3. I think that what is discussed in the= section
>> and use of normative language are outside of the scope of BFD= WG
>> charter:
>> Provide one or more mechanisms to run BFD over Link Aggregati= on Group
>> Interfaces.
>> 
>> Content of the section seems more suitable as Informational o= r BCP
>> with appropriate changes in use and interpretation of RFC 211= 9
>> language.
>> 
>>         Regards,
>>          &n= bsp;      Greg
>> 
>> -----Original Message-----
>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org<= /font>] On
>> Behalf Of internet-drafts@ietf.org
>> Sent: Friday, May 10, 2013 3:14 PM
>> To: i-d-announce@ietf.org
>> Cc: rtg-bfd@ietf.org
>> Subject: I-D Action: draft-ietf-bfd-on-lags-00.txt
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-D= rafts
>> directories.
>> This draft is a work item of the Bidirectional Forwarding Det= ection
>> Working Group of the IETF.
>> 
>>         Title &n= bsp;         : Bidirectional Forwar= ding Detection (BFD)
>> on Link Aggregation Group (LAG) Interfaces
>>         Author(s)&nbs= p;      : Manav Bhatia
>>          &n= bsp;            = ;    Mach(Guoyi) Chen
>>          &n= bsp;            = ;    Sami Boutros
>>          &n= bsp;            = ;    Marc Binderberger
>>          &n= bsp;            = ;    Jeffrey Haas
>>         Filename = ;       : draft-ietf-bfd-on-lags-00.txt
>>         Pages &n= bsp;         : 11
>>         Date &nb= sp;          : 2013-05-10
>> 
>> Abstract:
>>    This document proposes a mechanism to run B= FD on Link Aggregation
>>    Group (LAG) interfaces.  It does so by= running an independent
>>    Asynchronous mode BFD session on every LAG = member link.
>> 
>>    This mechanism allows the verification of m= ember link continuity,
>>    either in combination with, or in absence o= f, LACP.  It provides a
>>    shorter detection time than what LACP offer= s.  The continuity check
>>    can also cover elements of layer 3 bidirect= ional forwarding.
>> 
>>    This mechanism utilizes a well-known UDP po= rt distinct from that of
>>    single-hop BFD over IP.  This new UDP = port removes the ambiguity of
>>    BFD over LAG packets from BFD over single-h= op IP.
>> 
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> 
>> There's also a htmlized version available at:
>> 
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> 
>> 
>
>
>
 
 --_000_7347100B5761DC41A166AC17F22DF1121B4B7CAAeusaamb103erics_-- From manav.bhatia@alcatel-lucent.com Wed Jun 19 22:09:48 2013 Return-Path: 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 8238E21E80AA for ; Wed, 19 Jun 2013 22:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 JFp-JVt6JFjF for ; Wed, 19 Jun 2013 22:09:41 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id CDBCC21E80A5 for ; Wed, 19 Jun 2013 22:09:40 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r5K59dWa005718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Jun 2013 00:09:40 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r5K59a2p023495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 20 Jun 2013 01:09:39 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 20 Jun 2013 01:09:38 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.102]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Thu, 20 Jun 2013 13:09:36 +0800 From: "Bhatia, Manav (Manav)" To: "rtg-bfd@ietf.org" Subject: Discovering IP address to use for uBFD sessions Thread-Topic: Discovering IP address to use for uBFD sessions Thread-Index: Ac5tdDETAmKspDYfSSikTZOUmS4kEQ== Date: Thu, 20 Jun 2013 05:09:35 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C305CD89@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {21DAE84E-15C6-4876-BBEE-929E5C87EE02} x-cr-hashedpuzzle: a7g= A++A BEhP BPia Bw9B CYOm C/DT Doij D6Mj FApe FFlr Gqkj JJSO JgPi Jo9q J7NI; 1; cgB0AGcALQBiAGYAZABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {21DAE84E-15C6-4876-BBEE-929E5C87EE02}; bQBhAG4AYQB2AC4AYgBoAGEAdABpAGEAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA=; Thu, 20 Jun 2013 05:08:24 GMT; RABpAHMAYwBvAHYAZQByAGkAbgBnACAASQBQACAAYQBkAGQAcgBlAHMAcwAgAHQAbwAgAHUAcwBlACAAZgBvAHIAIAB1AEIARgBEACAAcwBlAHMAcwBpAG8AbgBzAA== x-originating-ip: [135.253.19.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 05:09:48 -0000 Hi, draft-ietf-bfd-on-lags is silent on how the IP address used for micro BFD s= essions is derived/learnt/discovered. It wisely assumes that an out-of-band mechanism exists which arms the route= rs with the knowledge about the remote IP address that it must use to estab= lish the micro BFD session. Some time back few of us wrote a short draft - draft-mmsn-bfd-on-lags-addre= ss-00, that describes how routers can obtain/discover remote IP addresses r= equired for establishing uBFD sessions. I would like the WG members to go through the above draft and discuss wheth= er we need a draft that describes alternate ways to discover remote IP addr= esses or can we all assume that the remote IP addresses MUST be statically = configured.=20 The problem with implicitly assuming that the remote IP addresses MUST be c= onfigured is that as more folks start implementing this, they would stumble= upon this issue and would be left clueless on how the IP addresses have to= be derived. In case the WG decides that its premature to work on an autodi= scovery mechanism, I would still like us to publish a draft that says that = addresses MUST be statically configured and an Appendix where alternate mec= hanisms are listed along with their pros and cons (mostly for the sake of p= osterity). Cheers, Manav From glen.kent@gmail.com Thu Jun 20 10:37:55 2013 Return-Path: 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 A0DA421F9F44 for ; Thu, 20 Jun 2013 10:37:55 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 Vxxr0lhLou+J for ; Thu, 20 Jun 2013 10:37:55 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id EFC4521F9E57 for ; Thu, 20 Jun 2013 10:37:54 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id n9so8395546oag.36 for ; Thu, 20 Jun 2013 10:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VNQWviETuRM5TVRk+L/wHiwnHQh0/HrhOOoZJXNErwU=; b=KJUty6hKvuIcu2nf0nifpH0VALuPXfl0l98z0BWeWDmYgnCVsQr3czJ5vVVb2x/spL /86ctIo6+L7u0oSnXW6ijTygBec77JE35P0kyAhrh5yvFJOwHCObn6rvIlX1FB1dGEHx 4B1neVsJiQpBoxK3/6lVmzhNoRRN+DZskBmmeSEoSiDIPWyIuY16x+1GJzeNecQ3wck7 3LIRIEJ3PjnLkl9xQ4zatZDQqv2fRGRgOQUgn/AYHLBiVp3/HlmZypFS/FxurzxUmytO 1eSm1k2B7b9skRnhs1IPy74IPqCly8k0ggPbKfB18sfTJLSLKCokHs091mpAqkXZ1XYG DMlw== MIME-Version: 1.0 X-Received: by 10.182.205.138 with SMTP id lg10mr1959823obc.6.1371749468282; Thu, 20 Jun 2013 10:31:08 -0700 (PDT) Received: by 10.182.214.68 with HTTP; Thu, 20 Jun 2013 10:31:08 -0700 (PDT) In-Reply-To: <20211F91F544D247976D84C5D778A4C305CD89@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <20211F91F544D247976D84C5D778A4C305CD89@SG70YWXCHMBA05.zap.alcatel-lucent.com> Date: Thu, 20 Jun 2013 23:01:08 +0530 Message-ID: Subject: Re: Discovering IP address to use for uBFD sessions From: Glen Kent To: "Bhatia, Manav (Manav)" Content-Type: multipart/alternative; boundary=001a11c290b8c72b3e04df994f77 Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:37:55 -0000 --001a11c290b8c72b3e04df994f77 Content-Type: text/plain; charset=ISO-8859-1 Hi Manav, We did have a discussion around this more than a year back here: http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01294.html There clearly was interest in pursuing something like this. I agree that we should have some mechanism to discover the remote IP addresses. Glen On Thu, Jun 20, 2013 at 10:39 AM, Bhatia, Manav (Manav) < manav.bhatia@alcatel-lucent.com> wrote: > Hi, > > draft-ietf-bfd-on-lags is silent on how the IP address used for micro BFD > sessions is derived/learnt/discovered. > > It wisely assumes that an out-of-band mechanism exists which arms the > routers with the knowledge about the remote IP address that it must use to > establish the micro BFD session. > > Some time back few of us wrote a short draft - > draft-mmsn-bfd-on-lags-address-00, that describes how routers can > obtain/discover remote IP addresses required for establishing uBFD sessions. > > I would like the WG members to go through the above draft and discuss > whether we need a draft that describes alternate ways to discover remote IP > addresses or can we all assume that the remote IP addresses MUST be > statically configured. > > The problem with implicitly assuming that the remote IP addresses MUST be > configured is that as more folks start implementing this, they would > stumble upon this issue and would be left clueless on how the IP addresses > have to be derived. In case the WG decides that its premature to work on an > autodiscovery mechanism, I would still like us to publish a draft that says > that addresses MUST be statically configured and an Appendix where > alternate mechanisms are listed along with their pros and cons (mostly for > the sake of posterity). > > Cheers, Manav > > > > > --001a11c290b8c72b3e04df994f77 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Manav,

We did have a discussio= n around this more than a year back here:

There clearly was interest in pursuin= g something like this.

I agree that we= should have some mechanism to discover the remote IP addresses.

Glen


On Thu, Jun 20, 2013 at 10:39 AM, Bhatia, Manav (Ma= nav) <manav.bhatia@alcatel-lucent.com> wrote:<= br>
Hi,

draft-ietf-bfd-on-lags is silent on how the IP address used for micro BFD s= essions is derived/learnt/discovered.

It wisely assumes that an out-of-band mechanism exists which arms the route= rs with the knowledge about the remote IP address that it must use to estab= lish the micro BFD session.

Some time back few of us wrote a short draft - draft-mmsn-bfd-on-lags-addre= ss-00, that describes how routers can obtain/discover remote IP addresses r= equired for establishing uBFD sessions.

I would like the WG members to go through the above draft and discuss wheth= er we need a draft that describes alternate ways to discover remote IP addr= esses or can we all assume that the remote IP addresses MUST be statically = configured.

The problem with implicitly assuming that the remote IP addresses MUST be c= onfigured is that as more folks start implementing this, they would stumble= upon this issue and would be left clueless on how the IP addresses have to= be derived. In case the WG decides that its premature to work on an autodi= scovery mechanism, I would still like us to publish a draft that says that = addresses MUST be statically configured and an Appendix where alternate mec= hanisms are listed along with their pros and cons (mostly for the sake of p= osterity).

Cheers, Manav





--001a11c290b8c72b3e04df994f77-- From nobo@cisco.com Fri Jun 21 16:02:57 2013 Return-Path: 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 21B2621F9E5A for ; Fri, 21 Jun 2013 16:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 Tzldzw+jBA-c for ; Fri, 21 Jun 2013 16:02:52 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6CD21F9E5C for ; Fri, 21 Jun 2013 16:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13148; q=dns/txt; s=iport; t=1371855772; x=1373065372; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sl+LK+s44j6jFPLk99Q4sYpQSXzduL6iDCCKLOi+sQc=; b=X82l/qGyJDIVcLvfrqMrdmrAnnvTS/iS40OuZINExHmV5P6hMlGANo4z RF8XrH1ZB5QATGOds9gnbGMto/J3lncfOi7IZkVX7qBrqdsEleYXfKv3V o4X74PCfGpV7kwDexcA5TNHqnc46RmzVNxgpvuU7lRkeFb/ECTEirGaYH c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAJ/axFGtJV2d/2dsb2JhbABbgkUjITFJvzWBAhZ0giMBAQEELUwQAgEIEQQBAQsdBzIUCQgBAQQOBQgBEodzAQu8JI4HEIEBMQYBgwBhA6kHgw+BcTc X-IronPort-AV: E=Sophos;i="4.87,916,1363132800"; d="scan'208,217";a="223018936" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 21 Jun 2013 23:02:51 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5LN2oLi011217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Jun 2013 23:02:50 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 21 Jun 2013 18:02:50 -0500 From: "Nobo Akiya (nobo)" To: Glen Kent , "Bhatia, Manav (Manav)" Subject: RE: Discovering IP address to use for uBFD sessions Thread-Topic: Discovering IP address to use for uBFD sessions Thread-Index: Ac5tdDETAmKspDYfSSikTZOUmS4kEQAkaqcAADJMtMA= Date: Fri, 21 Jun 2013 23:02:49 +0000 Message-ID: References: <20211F91F544D247976D84C5D778A4C305CD89@SG70YWXCHMBA05.zap.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.160] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941B68CE7Bxmbalnx01ciscoc_" MIME-Version: 1.0 Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 23:02:57 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941B68CE7Bxmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Manav, Glen, et al, [hat on] Primary discussion on the thread seemed to have revolved around which disco= very mechanism is preferred (multicast vs. 127/8). There was also a prefere= nce of static configuration approach, to allow for faster implementation. Based on number of responses on the thread, one can argue there was interes= t in auto discovery approach back then. Now that several vendors have implement BFD on LAG, and using static config= uration approach, it would be beneficial to see if there is still significa= nt interest for auto discovery approach or if interest have shifted. Can people (vendors, operators, others) kindly chime in? [hat off] Products that I know has proprietary but very similar to BFD on LAG solutio= n, has static configuration approach, and have been used for years. I have = not seen any auto discovery requests. Thus I personally think static config= uration is an acceptable approach, and my preference is to go with last par= agraph/sentence of Manav's email. Regards, Nobo From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Glen Kent Sent: Thursday, June 20, 2013 1:31 PM To: Bhatia, Manav (Manav) Cc: rtg-bfd@ietf.org Subject: Re: Discovering IP address to use for uBFD sessions Hi Manav, We did have a discussion around this more than a year back here: http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01294.html There clearly was interest in pursuing something like this. I agree that we should have some mechanism to discover the remote IP addres= ses. Glen On Thu, Jun 20, 2013 at 10:39 AM, Bhatia, Manav (Manav) > wrote: Hi, draft-ietf-bfd-on-lags is silent on how the IP address used for micro BFD s= essions is derived/learnt/discovered. It wisely assumes that an out-of-band mechanism exists which arms the route= rs with the knowledge about the remote IP address that it must use to estab= lish the micro BFD session. Some time back few of us wrote a short draft - draft-mmsn-bfd-on-lags-addre= ss-00, that describes how routers can obtain/discover remote IP addresses r= equired for establishing uBFD sessions. I would like the WG members to go through the above draft and discuss wheth= er we need a draft that describes alternate ways to discover remote IP addr= esses or can we all assume that the remote IP addresses MUST be statically = configured. The problem with implicitly assuming that the remote IP addresses MUST be c= onfigured is that as more folks start implementing this, they would stumble= upon this issue and would be left clueless on how the IP addresses have to= be derived. In case the WG decides that its premature to work on an autodi= scovery mechanism, I would still like us to publish a draft that says that = addresses MUST be statically configured and an Appendix where alternate mec= hanisms are listed along with their pros and cons (mostly for the sake of p= osterity). Cheers, Manav --_000_CECE764681BE964CBE1DFF78F3CDD3941B68CE7Bxmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Manav, Glen, et al,=

 <= /p>

[hat on]

 <= /p>

Primary discussion on the= thread seemed to have revolved around which discovery mechanism is preferr= ed (multicast vs. 127/8). There was also a preference of static configuration approach, to allow for faster implementation.

 <= /p>

Based on number of respon= ses on the thread, one can argue there was interest in auto discovery appro= ach back then.

 <= /p>

Now that several vendors = have implement BFD on LAG, and using static configuration approach, it woul= d be beneficial to see if there is still significant interest for auto discovery approach or if interest have shifted.=

 <= /p>

Can people (vendors, oper= ators, others) kindly chime in?

 <= /p>

[hat off]

 <= /p>

Products that I know has = proprietary but very similar to BFD on LAG solution, has static configurati= on approach, and have been used for years. I have not seen any auto discovery requests. Thus I personally think static configuration = is an acceptable approach, and my preference is to go with last paragraph/s= entence of Manav’s email.

 <= /p>

Regards,

Nobo

 <= /p>

 <= /p>

From: rtg-bfd-= bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Glen Kent
Sent: Thursday, June 20, 2013 1:31 PM
To: Bhatia, Manav (Manav)
Cc: rtg-bfd@ietf.org
Subject: Re: Discovering IP address to use for uBFD sessions

 

Hi Manav,

 

We did have a discussion around this more than a yea= r back here:

 

There clearly was interest in pursuing something lik= e this.

 

I agree that we should have some mechanism to discov= er the remote IP addresses.

 

Glen

 

On Thu, Jun 20, 2013 at 10:39 AM, Bhatia, Manav (Man= av) <manav.bhatia@alcatel-lucent.com> wrote:

Hi,

draft-ietf-bfd-on-lags is silent on how the IP address used for micro BFD s= essions is derived/learnt/discovered.

It wisely assumes that an out-of-band mechanism exists which arms the route= rs with the knowledge about the remote IP address that it must use to estab= lish the micro BFD session.

Some time back few of us wrote a short draft - draft-mmsn-bfd-on-lags-addre= ss-00, that describes how routers can obtain/discover remote IP addresses r= equired for establishing uBFD sessions.

I would like the WG members to go through the above draft and discuss wheth= er we need a draft that describes alternate ways to discover remote IP addr= esses or can we all assume that the remote IP addresses MUST be statically = configured.

The problem with implicitly assuming that the remote IP addresses MUST be c= onfigured is that as more folks start implementing this, they would stumble= upon this issue and would be left clueless on how the IP addresses have to= be derived. In case the WG decides that its premature to work on an autodiscovery mechanism, I would still li= ke us to publish a draft that says that addresses MUST be statically config= ured and an Appendix where alternate mechanisms are listed along with their= pros and cons (mostly for the sake of posterity).

Cheers, Manav



 

--_000_CECE764681BE964CBE1DFF78F3CDD3941B68CE7Bxmbalnx01ciscoc_-- From binnyjeshan@gmail.com Tue Jun 25 00:42:46 2013 Return-Path: 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 0EED021F9BA5 for ; Tue, 25 Jun 2013 00:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 I085kibhyfy6 for ; Tue, 25 Jun 2013 00:42:45 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0B92621F9F76 for ; Tue, 25 Jun 2013 00:42:45 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id lj1so12257661pab.17 for ; Tue, 25 Jun 2013 00:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:cc:from:subject:date:content-type; bh=Nf0q/SkHnp5AOJg9+gb52HqzjDSimNiDYUZnm+CFgao=; b=OLdH8s9gI216r7v60eFPpDCj22RE0/eMkqlfl3tDUAuaTFdZ+gj4SO3cPzoGr9W5sH phf6gdIZLjS4Hr/8kd/VHzIz7ubtBMGNs50onjDWeLBGbqXPu0GSxTP5H0xGMaId9zed nCssKAKDCHVt/xGSsWImkS364bFU0fGI18w3prehjqNEjbyYKGoDOwfxmNpMfSmPaKtS 4l9a4Ea2wmHdLZnOGB92apS0OPwFTGDcDvYtVqA3yFORBjeeirhpMoZ8t/hSHXHfP9lq t+YMgq6FipWh97/ge2J/TCXaZOLtXmCUHn1RhVmVVOFnsxVB/9OiZ6N0AHuiS1qVO5ID F25w== X-Received: by 10.66.121.227 with SMTP id ln3mr8136382pab.203.1372146164748; Tue, 25 Jun 2013 00:42:44 -0700 (PDT) Received: from [223.227.145.162] ([223.227.145.162]) by mx.google.com with ESMTPSA id pm7sm21929502pbb.31.2013.06.25.00.42.33 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 25 Jun 2013 00:42:43 -0700 (PDT) Message-ID: <51c949f3.c786440a.151a.ffff9ca7@mx.google.com> MIME-Version: 1.0 To: "Nobo Akiya (nobo)" , Glen Kent , "Bhatia, Manav (Manav)" From: Binny Jeshan Subject: RE: Discovering IP address to use for uBFD sessions Date: Tue, 25 Jun 2013 13:07:02 +0530 Content-Type: multipart/alternative; boundary="_86C43ACE-6295-4F96-8AA3-6B325B14A1EB_" Cc: "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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 07:42:46 -0000 --_86C43ACE-6295-4F96-8AA3-6B325B14A1EB_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hello all, I too have come across the products and discussions that focused on static = configurations so far, but this one seems interesting looking from simplifi= ed operations point of view. I=20 Personally would be interested in simplified operations of BFD, but I would= be more preferring any out-of-band mechanisms to do that, depending on the= technology where BFD is used can offer to it. One similar way that I remem= ber is LSP Ping BFD bootstrapping done in MPLS. BFD should/preferably-bette= r depend on its higher control plane to give the discovered data to BFD. IMHO, lets continue to work on this. Regards, Binny Aricent, India=20 Sent from Nokia Lumia -----Original Message----- From: "Nobo Akiya (nobo)" Sent: =E2=80=8E22-=E2=80=8E06-=E2=80=8E2013 04:33 AM To: "Glen Kent" ; "Bhatia, Manav (Manav)" Cc: "rtg-bfd@ietf.org" Subject: RE: Discovering IP address to use for uBFD sessions Hello Manav, Glen, et al, =20 [hat on] =20 Primary discussion on the thread seemed to have revolved around which disco= very mechanism is preferred (multicast vs. 127/8). There was also a prefere= nce of static configuration approach, to allow for faster implementation. =20 Based on number of responses on the thread, one can argue there was interes= t in auto discovery approach back then. =20 Now that several vendors have implement BFD on LAG, and using static config= uration approach, it would be beneficial to see if there is still significa= nt interest for auto discovery approach or if interest have shifted. =20 Can people (vendors, operators, others) kindly chime in? =20 [hat off] =20 Products that I know has proprietary but very similar to BFD on LAG solutio= n, has static configuration approach, and have been used for years. I have = not seen any auto discovery requests. Thus I personally think static config= uration is an acceptable approach, and my preference is to go with last par= agraph/sentence of Manav=E2=80=99s email. =20 Regards, Nobo =20 =20 From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Glen Kent Sent: Thursday, June 20, 2013 1:31 PM To: Bhatia, Manav (Manav) Cc: rtg-bfd@ietf.org Subject: Re: Discovering IP address to use for uBFD sessions =20 Hi Manav, =20 We did have a discussion around this more than a year back here: http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01294.html =20 There clearly was interest in pursuing something like this. =20 I agree that we should have some mechanism to discover the remote IP addres= ses. =20 Glen =20 On Thu, Jun 20, 2013 at 10:39 AM, Bhatia, Manav (Manav) wrote: Hi, draft-ietf-bfd-on-lags is silent on how the IP address used for micro BFD s= essions is derived/learnt/discovered. It wisely assumes that an out-of-band mechanism exists which arms the route= rs with the knowledge about the remote IP address that it must use to estab= lish the micro BFD session. Some time back few of us wrote a short draft - draft-mmsn-bfd-on-lags-addre= ss-00, that describes how routers can obtain/discover remote IP addresses r= equired for establishing uBFD sessions. I would like the WG members to go through the above draft and discuss wheth= er we need a draft that describes alternate ways to discover remote IP addr= esses or can we all assume that the remote IP addresses MUST be statically = configured. The problem with implicitly assuming that the remote IP addresses MUST be c= onfigured is that as more folks start implementing this, they would stumble= upon this issue and would be left clueless on how the IP addresses have to= be derived. In case the WG decides that its premature to work on an autodi= scovery mechanism, I would still like us to publish a draft that says that = addresses MUST be statically configured and an Appendix where alternate mec= hanisms are listed along with their pros and cons (mostly for the sake of p= osterity). Cheers, Manav = --_86C43ACE-6295-4F96-8AA3-6B325B14A1EB_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hello all,<= BR>
I too have come across the products and discussions that focused on = static configurations so far, but this one seems interesting looking from s= implified operations point of view. I
Personally would be interested in= simplified operations of BFD, but I would be more preferring any out-of-ba= nd mechanisms to do that, depending on the technology where BFD is used can= offer to it. One similar way that I remember is LSP Ping BFD bootstrapping= done in MPLS. BFD should/preferably-better depend on its higher control pl= ane to give the discovered data to BFD.

IMHO, lets continue to work = on this.

Regards, Binny
Aricent, India

Sent from Nokia Lu= mia
From: Nobo Akiya (nobo)<= BR>Sent: =E2=80=8E22-=E2=80=8E06-=E2=80=8E2013 04:33 AM
To: Glen Kent; Bhatia, Manav (Manav)
Cc: rtg-bfd@ietf.org
= Subject: RE: Discovering IP address to use for uBFD sessions

Hello Manav, Glen, et al,<= /P>

 

[hat on]

 

Primary discussion on the thread seemed to h= ave revolved around which discovery mechanism is preferred (multicast vs. 1= 27/8). There was also a preference of static configuration approach, to all= ow for faster implementation.

 

Based on number of responses on the thread, = one can argue there was interest in auto discovery approach back then.=

 

Now that several vendors have implement BFD = on LAG, and using static configuration approach, it would be beneficial to = see if there is still significant interest for auto discovery approach or i= f interest have shifted.

 

Can people (vendors, operators, others) kind= ly chime in?

 

[hat off]

 

Products that I know has proprietary but ver= y similar to BFD on LAG solution, has static configuration approach, and ha= ve been used for years. I have not seen any auto discovery requests. Thus I= personally think static configuration is an acceptable approach, and my pr= eference is to go with last paragraph/sentence of Manav=E2=80=99s email.

 

Regards,

Nobo

 

 

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces= @ietf.org] On Behalf Of Glen Kent
Sent: Thursday, June 20,= 2013 1:31 PM
To: Bhatia, Manav (Manav)
Cc: rtg-bfd@iet= f.org
Subject: Re: Discovering IP address to use for uBFD session= s

 

Hi Manav,

 

We did have a discussion around this more than a year = back here:

 

There clearly was interest in pursuing something like = this.

 

I agree that we should have some mechanism to discover= the remote IP addresses.

 

Glen

 

On Thu, Jun 20, 2013 at 10:39 AM, Bhatia, Manav (Manav= ) <ma= nav.bhatia@alcatel-lucent.com> wrote:

Hi,

draft-ietf-bf= d-on-lags is silent on how the IP address used for micro BFD sessions is de= rived/learnt/discovered.

It wisely assumes that an out-of-band mecha= nism exists which arms the routers with the knowledge about the remote IP a= ddress that it must use to establish the micro BFD session.

Some tim= e back few of us wrote a short draft - draft-mmsn-bfd-on-lags-address-00, t= hat describes how routers can obtain/discover remote IP addresses required = for establishing uBFD sessions.

I would like the WG members to go th= rough the above draft and discuss whether we need a draft that describes al= ternate ways to discover remote IP addresses or can we all assume that the = remote IP addresses MUST be statically configured.

The problem with = implicitly assuming that the remote IP addresses MUST be configured is that= as more folks start implementing this, they would stumble upon this issue = and would be left clueless on how the IP addresses have to be derived. In c= ase the WG decides that its premature to work on an autodiscovery mechanism= , I would still like us to publish a draft that says that addresses MUST be= statically configured and an Appendix where alternate mechanisms are liste= d along with their pros and cons (mostly for the sake of posterity).
Cheers, Manav



 

= --_86C43ACE-6295-4F96-8AA3-6B325B14A1EB_-- From internet-drafts@ietf.org Wed Jun 26 10:32:34 2013 Return-Path: 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 C973011E81D7; Wed, 26 Jun 2013 10:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 goazp-O3x9c7; Wed, 26 Jun 2013 10:32:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6848511E8110; Wed, 26 Jun 2013 10:32:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-mib-14.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130626173234.22191.8784.idtracker@ietfa.amsl.com> Date: Wed, 26 Jun 2013 10:32:34 -0700 Cc: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 17:32:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : BFD Management Information Base Author(s) : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-mib-14.txt Pages : 38 Date : 2013-06-26 Abstract: This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-mib-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-mib-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobo@cisco.com Wed Jun 26 10:35:17 2013 Return-Path: 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 80E9A11E811D for ; Wed, 26 Jun 2013 10:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 09bNAwBeHW39 for ; Wed, 26 Jun 2013 10:35:12 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD6911E8110 for ; Wed, 26 Jun 2013 10:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2410; q=dns/txt; s=iport; t=1372268112; x=1373477712; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jLfGMkh1Mb67bPjqrIFPID1uGLWrkqr0LukiNd+HNtA=; b=BCmQg18cSiEDL1kweKaApQ/hrZTUx3SEGFCwaZLqt/6bvWrK7cJjL7k+ 0GklMc12jiljCNB0eK1LeX1P6KKjEn2G1XORhJWJd9++gAhg5Hzedutf1 Z4H68WJzDM/AKm+zP1J5MN2iCyQTVgtVuC1Rb+zcPbSoQnUle/yaYwdKD U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAC8ly1GtJV2d/2dsb2JhbABbgmghMUMGgwa7dw12FnSCIwEBAQQjEVEEAgEIEQQBAQMCBh0DAgICMBQBCAgCBBMIAQuHegEGBahAkUmBJo10OAaCSTNhA5hukByDEYIo X-IronPort-AV: E=Sophos;i="4.87,945,1363132800"; d="scan'208";a="227801854" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 26 Jun 2013 17:35:11 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5QHZBKe017955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Jun 2013 17:35:11 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 12:35:11 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-mib-14.txt Thread-Topic: I-D Action: draft-ietf-bfd-mib-14.txt Thread-Index: AQHOcpMofB9NkBm2vUePN5qqOJCwqZlIQVQg Date: Wed, 26 Jun 2013 17:35:10 +0000 Message-ID: References: <20130626173234.22191.8784.idtracker@ietfa.amsl.com> In-Reply-To: <20130626173234.22191.8784.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 17:35:17 -0000 QWRkcmVzc2VkIG9uZSBjb21tZW50IGZyb20gSUVURi04NC4NCg0KPiAtIGRpc2NyaW1pbmF0b3Jz IG5lZWQgdG8gYmUgTUFYLUFDQ0VTUyByZWFkLWNyZWF0ZSB0byBhY2NvbW1vZGF0ZSANCj4gY29u ZmlndXJlZCAgY2FzZS4gIENvbmZvcm1hbmNlIHN0YXRlbWVudCBuZWVkcyB0byBiZSB1cGRhdGVk IGFwcHJvcHJpYXRlbHkuDQoNCmJmZFNlc3NEaXNjcmltaW5hdG9yIG5vdyBoYXMgcmVhZC1jcmVh dGUgYWNjZXNzLg0KDQpSZWdhcmRzLA0KTm9ibw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IHJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Zy1iZmQtYm91 bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0K PiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMjYsIDIwMTMgMTozMyBQTQ0KPiBUbzogaS1kLWFubm91 bmNlQGlldGYub3JnDQo+IENjOiBydGctYmZkQGlldGYub3JnDQo+IFN1YmplY3Q6IEktRCBBY3Rp b246IGRyYWZ0LWlldGYtYmZkLW1pYi0xNC50eHQNCj4gDQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1E cmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gZGly ZWN0b3JpZXMuDQo+ICBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBCaWRpcmVjdGlv bmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIFdvcmtpbmcNCj4gR3JvdXAgb2YgdGhlIElFVEYuDQo+ IA0KPiAJVGl0bGUgICAgICAgICAgIDogQkZEIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gQmFzZQ0K PiAJQXV0aG9yKHMpICAgICAgIDogVGhvbWFzIEQuIE5hZGVhdQ0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgIFphZmFyIEFsaQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIE5vYm8gQWtp eWENCj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtYmZkLW1pYi0xNC50eHQNCj4gCVBh Z2VzICAgICAgICAgICA6IDM4DQo+IAlEYXRlICAgICAgICAgICAgOiAyMDEzLTA2LTI2DQo+IA0K PiBBYnN0cmFjdDoNCj4gICAgVGhpcyBkcmFmdCBkZWZpbmVzIGEgcG9ydGlvbiBvZiB0aGUgTWFu YWdlbWVudCBJbmZvcm1hdGlvbiBCYXNlIChNSUIpDQo+ICAgIGZvciB1c2Ugd2l0aCBuZXR3b3Jr IG1hbmFnZW1lbnQgcHJvdG9jb2xzIGluIHRoZSBJbnRlcm5ldCBjb21tdW5pdHkuDQo+ICAgIElu IHBhcnRpY3VsYXIsIGl0IGRlc2NyaWJlcyBtYW5hZ2VkIG9iamVjdHMgZm9yIG1vZGVsaW5nDQo+ ICAgIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgcHJvdG9jb2wuDQo+ IA0KPiANCj4gDQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRy YWZ0IGlzOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWJm ZC1taWINCj4gDQo+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0 Og0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC1taWItMTQNCj4g DQo+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4g aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1iZmQtbWliLTE0DQo+ IA0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMg RlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQo= From internet-drafts@ietf.org Thu Jun 27 20:49:23 2013 Return-Path: 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 E59DF11E8133; Thu, 27 Jun 2013 20:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.347 X-Spam-Level: X-Spam-Status: No, score=-102.347 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 qTdJnYHylQwL; Thu, 27 Jun 2013 20:49:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8232811E80BA; Thu, 27 Jun 2013 20:49:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-mpls-mib-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130628034923.29055.92567.idtracker@ietfa.amsl.com> Date: Thu, 27 Jun 2013 20:49:23 -0700 Cc: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 03:49:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : BFD Management Information Base (MIB) extensions for MPL= S and MPLS-TP Networks Author(s) : Sam Aldrin Venkatesan Mahalingam Kannan KV Sampath Thomas D. Nadeau Filename : draft-ietf-bfd-mpls-mib-02.txt Pages : 22 Date : 2013-06-27 Abstract: This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it extends the BFD Management Information Base BFD- STD-MIB and describes the managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol for MPLS and MPLS-TP networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-mpls-mib-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-mpls-mib-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/