From nobody Sun May 4 03:02:55 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0811A0161 for ; Sun, 4 May 2014 03:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzQGsntmwBgv for ; Sun, 4 May 2014 03:02:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 69D871A005B for ; Sun, 4 May 2014 03:02:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGJ55413; Sun, 04 May 2014 10:02:47 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 4 May 2014 11:01:19 +0100 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 4 May 2014 11:02:46 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.13]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Sun, 4 May 2014 18:02:43 +0800 From: Mach Chen To: "Carlos Pignataro (cpignata)" , Jeff Haas Subject: RE: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Topic: BFD charter update proposal [was: RE: Working Group adoption for Seamless BFD (requires re-charter)] Thread-Index: Ac9hA9W0xBfhI23hQ/SR7/pOFp9nKwAyXcvwABYf3TAAH+vSAAAJaMWAASz94uA= Date: Sun, 4 May 2014 10:02:42 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7A6875@eusaamb103.ericsson.se> <20140428134830.GB1256@pfrc> <3A2576B3-8E92-4E63-B3E3-46DEA08A5726@cisco.com> In-Reply-To: <3A2576B3-8E92-4E63-B3E3-46DEA08A5726@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/9K7ACQQBy_ENRKEGLhVYl_N-gWE Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 04 May 2014 10:02:53 -0000 Hi Carlos, Jeff and all, I am OK with either Seamless or Stateless, a little preference to Stateless= although it cannot totally reflect the whole characteristics of S-BFD, it = does shows a very important characteristic of S-BFD.=20 Best regards, Mach > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Carlos Pigna= taro > (cpignata) > Sent: Tuesday, April 29, 2014 2:18 AM > To: Jeff Haas > Cc: rtg-bfd@ietf.org > Subject: Re: BFD charter update proposal [was: RE: Working Group adoption= for > Seamless BFD (requires re-charter)] >=20 > Hi Jeff, >=20 > On Apr 28, 2014, at 9:48 AM, Jeffrey Haas wrote: >=20 > > [Not specifically speaking as a chair here...] > > > > On Sun, Apr 27, 2014 at 02:47:37PM +0000, Nobo Akiya (nobo) wrote: > >> Here's consolidated charter text proposal. > >> > >> > >> Attempt #2 > >> > >> Define a mechanism to perform single-ended path (ex: continuity) verif= ication > based on the BFD specification; allow such mechanism to seamlessly work b= oth > proactively and on-demand; allow the mechanism to maintain multiple sessi= ons > to a target entity. In doing this work, the WG will work closely with at = least the > following other WGs: ISIS, OSPF, SPRING. > > > > So... what exactly does seamless mean here? What seams were you > > seeing that you were trying to remove? > > > > FWIW, I think the charter discussion is moving along well, but I've > > never quite groked the context for "seamless" for the proposal. > > "Stateless" BFD, I can see quite well. > > >=20 > Like others have said, we had some renaming discussions. Now it would be = a > good time to converge. Some of the (not perfect, but perfect is the enemy= of > good and progress here) more technical qualifiers are "Stateless", "Refle= ctor", > "Responder", "Mesh Group", "Asymmetric". These focus on the behavior of t= he > responder mostly. Descriptive ones are also possible like "Easy", "Simple= ", > "Seamless", etc. >=20 > Frankly I am not concerned about which name -- other than we should be > consistent. >=20 > Net-net: I support your proposal of "Stateless" and a %s/Seamless/Statele= ss/g. It > also keeps the same abbrev of S-BFD. What do others think? >=20 > Thanks, >=20 > Carlos. >=20 > > -- Jeff From nobody Mon May 5 13:03:27 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710EB1A01AF for ; Mon, 5 May 2014 13:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaZGf_VPFKma for ; Mon, 5 May 2014 13:03:25 -0700 (PDT) Received: from ironport2.idirect.net (ironport2.dmz.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCC41A0196 for ; Mon, 5 May 2014 13:03:24 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport2.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="4.97,991,1389762000"; d="scan'208";a="1397914" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport2.idirect.net with ESMTP; 05 May 2014 16:03:20 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Mon, 5 May 2014 16:03:20 -0400 From: "Snyder, Brian" To: "rtg-bfd@ietf.org" Subject: FW: New Version Notification for draft-snyder-bfd-proxy-connections-monitored-links-00.txt Thread-Topic: New Version Notification for draft-snyder-bfd-proxy-connections-monitored-links-00.txt Thread-Index: AQHPaJkWaoE5fYWylUqnpHbXTZ0qW5syYXkQ Date: Mon, 5 May 2014 20:03:19 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7342FA3281@VAUS-MBX03.idirect.net> References: <20140505193415.20998.63258.idtracker@ietfa.amsl.com> In-Reply-To: <20140505193415.20998.63258.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/g41uOTQCzPfACiXUKpE3AEhuBx0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 05 May 2014 20:03:26 -0000 Hello all, Nobo and I have been working on publishing a new informational RFC related= to proxying BFD via monitored links. This is written as a generalized sol= ution for all monitored links, but with satellite use case as the primary e= xample. Additionally, prior to writing this document, I have actually code= d up a proof of concept which has been proven to work in the stated use cas= e. If anyone would care to review and comment it would be most appreciated. Thanks, Brian & Nobo -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, May 05, 2014 3:34 PM To: Nobo Akiya; Snyder, Brian; Nobo Akiya; Snyder, Brian Subject: New Version Notification for draft-snyder-bfd-proxy-connections-mo= nitored-links-00.txt A new version of I-D, draft-snyder-bfd-proxy-connections-monitored-links-00= .txt has been successfully submitted by Brian Snyder and posted to the IETF repo= sitory. Name: draft-snyder-bfd-proxy-connections-monitored-links Revision: 00 Title: BFD Proxy for Connections over Monitored Links Document date: 2014-05-05 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-snyder-bfd-proxy-= connections-monitored-links-00.txt Status: https://datatracker.ietf.org/doc/draft-snyder-bfd-proxy-con= nections-monitored-links/ Htmlized: http://tools.ietf.org/html/draft-snyder-bfd-proxy-connectio= ns-monitored-links-00 Abstract: This document describes a Bidirectional Forwarding Detection (BFD) proxy mechanism to allow intermediate networking equipment (ex: Satellite HUB/Modem) to intercept BFD packets and to generate BFD packets to relay the health of connection monitored links. Note that this is an informational document that does not propose any changes to the BFD protocol. = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon May 5 19:24:16 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE7B1A049A for ; Mon, 5 May 2014 19:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StUoIsS6tXib for ; Mon, 5 May 2014 19:24:12 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 378FD1A0207 for ; Mon, 5 May 2014 19:24:12 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 0F2D72AA0F; Tue, 6 May 2014 02:24:04 +0000 (GMT) Date: Mon, 5 May 2014 19:24:04 -0700 From: Marc Binderberger To: MALLIK MUDIGONDA (mmudigon) Message-ID: <20140505192404062506.fcd0c154@sniff.de> In-Reply-To: References: Subject: Re: New version notification for draft-akiya-bfd-seamless-base-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/lOa_eyv0ggR-6ho6ubiTyCnvQsQ Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 06 May 2014 02:24:14 -0000 Hello Mallik and authors, reading the new draft version, here some first feedback: (1) You are fairly detailed in sections 9.2.2 and 9.3 what to copy over from the received into the responder packet but it does not mention what the reflector is doing with the P/F flags. I assume it needs to copy them into the reflected packet? Sure, you say in 9.5 "The Poll sequence MUST operate in accordance with [RFC5880]." but details are missing. (2) What I'm still wondering: why do you want to change the RFC5880 state machine? I would assume that if you want to re-use code/hw on the Initiator side then that's the last thing to change. And you don't need to: * Initiator sends out the usual Down/Init/Up as per RFC5880 * Reflector simply copies the state into the reply packet (or overwrites the state field with AdminDown) Play it through - it works ;-) More important there is a subtle difference of simply going to "Up" state when receiving "Up" packets and filling the packet path with Down, then Init, then Up. (3) Nitpick: section 9.1.1 says "The notation on each arc represents the state of the remote system" - there is no state of the remote system, the reflector is stateless ;-) (4) Section 11 "Scaling Aspects". The "total number of BFD sessions in a network" - why would this be a relevant number? This is not RSVP-based TE tunnels where some core nodes may indeed come close to the N * (N - 1) number of RSVP tunnel state for an any-any mesh. But a BFD session is just a bit of traffic in the forwarding plane for most routers, only sender/receiver take a hit. True, there is still the factor of about "2" per single router. I would propose keeping the first paragraph of 11 but remove the rest. Have to re-read your draft for the other parts, especially the D-bit ;-) Regards, Marc On Thu, 17 Apr 2014 12:50:12 +0000, MALLIK MUDIGONDA (mmudigon) wrote: > Hello BFD WG Members, > > We have published a new version of Seamless BFD draft, > draft-akiya-bfd-seamless-base-03. Several sections have been updated for > improving readability. It also has a few technical changes as well. Please > review the draft and get back to us with your comments. > > Thanks > > Regards > Mallik From nobody Tue May 6 09:03:04 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EC31A0864 for ; Tue, 6 May 2014 09:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCdysIJO4TdS for ; Tue, 6 May 2014 09:02:55 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB081A02B8 for ; Tue, 6 May 2014 09:02:55 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6E0F5C2A7; Tue, 6 May 2014 12:02:51 -0400 (EDT) Date: Tue, 6 May 2014 12:02:51 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: Working Group adoption for Seamless BFD (requires re-charter) Message-ID: <20140506160251.GA17758@pfrc> References: <20140421203314.GF8955@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140421203314.GF8955@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/PKPZndnFdGN9Oh3KOghqcD_W5-E X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 06 May 2014 16:02:59 -0000 [apologies for top-posting] Working Group, The poll of the mailing list for support for re-chartering to include the S-BFD work showed very nice support for the proposal. This includes both chartering for the work and also for using the base and use case documents as the initial seeds for the work. In a separate thread, we seem to have somewhat converged on possible re-chartering text: : Define a mechanism to perform single-ended path (i.e. continuity) : verification based on the BFD specification; allow such mechanism to work : both proactively and on-demand, without prominent initial delay; allow the : mechanism to maintain multiple sessions to a target entity and between the : same pair of network entities. In doing this work, the WG will work closely : with at least the following other WGs: ISIS, OSPF, SPRING. While I feel "single-ended" isn't *quite* there, it's still much clearer than seamless, in my opinion. Sender-initiated? (And "soft", also proposed, had a nicer "marketing" feel to it.) Ah well, choosing names has always been a hard thing. This note is to give the authors a few additional days to finalize the name we'll take to the IESG as part of the charter work. (I.e. draft-ietf-bfd-s-something.) I have threatened Nobo that if a second rename happens, the feature will be renamed "Fred". -- Jeff On Mon, Apr 21, 2014 at 04:33:14PM -0400, Jeffrey Haas wrote: > Working Group, > > >From our last in-person IETF meeting in Vancouver, the S-BFD authors were > going to put additional work into their use cases and base protocol document > prior to requesting Working Group adoption. That work has since been done > and, IMO, the quality of the documents has nicely improved. > > But, being IETF work, we'd like to carry out further work on the proposal in > the openness of the WG. Thus, I'd like to request the Working Group to > consider whether we'll want to adopt the Seamless BFD (S-BFD) documents. > Note that this work is currently outside the scope of our charter and would > require a re-charter. Once we have a sense of the group for the interest in > this task we'll propose the charter update in support of the drafts. > > The following two documents are current and describe the work: > > http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ > > Given the scope of this feature, I would like to particularly remind the > Working Group to focus on its security aspects. > > The following three documents are slightly stale as a result of the > revisions in the base and use cases draft and will require an update. > However, they provide a sense of how the S-BFD mechanisms might be used. > > Note in particular that the SR work will require coordination with the > SPRING Working Group. > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ > > Finally, there is known future work targeting the distribution of the > necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts have > been authored on the topic at this time, but work on them is expected. > > This begins a two week poll on whether the WG would like to adopt S-BFD as a > chartered task. This poll ends on May 6. > > As part of your response, please indicate if you have specific concerns > about individual drafts being part of this work. > > Since Nobo is a contributor to this work, I will be taking the part of the > shepherding chair. > > -- Jeff From nobody Tue May 6 09:29:32 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B852B1A019C for ; Tue, 6 May 2014 09:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azI4YUk-Prgf for ; Tue, 6 May 2014 09:29:29 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0641A017E for ; Tue, 6 May 2014 09:29:29 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 539EAC251; Tue, 6 May 2014 12:29:25 -0400 (EDT) Date: Tue, 6 May 2014 12:29:25 -0400 From: Jeffrey Haas To: "Snyder, Brian" Subject: Re: FW: New Version Notification for draft-snyder-bfd-proxy-connections-monitored-links-00.txt Message-ID: <20140506162925.GB17758@pfrc> References: <20140505193415.20998.63258.idtracker@ietfa.amsl.com> <84585478AABBBF4B9DF597FC0F84AF7342FA3281@VAUS-MBX03.idirect.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7342FA3281@VAUS-MBX03.idirect.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/E5ILES2nidYSAolUvnlnAYbnI8o Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 06 May 2014 16:29:30 -0000 Brian, On Mon, May 05, 2014 at 08:03:19PM +0000, Snyder, Brian wrote: > Nobo and I have been working on publishing a new informational RFC > related to proxying BFD via monitored links. This is written as a > generalized solution for all monitored links, but with satellite use case > as the primary example. Additionally, prior to writing this document, I > have actually coded up a proof of concept which has been proven to work in > the stated use case. > > If anyone would care to review and comment it would be most appreciated. Thank you for bringing this to the Working Group's attention. The proposal makes no changes to the BFD protocol from an endpoint's perspective, so there is no specific requirement for BFD standards work. Were you looking for this draft to be adopted within the WG? If so, it'd require a minor re-chartering. I did have two bits of technical feedback on the draft: 1. The security considerations already discuss the need for the proxy to be involved in the security. IMO, citing GTSM as a security mechanism is probably not sufficient in such satellite networks without assurance that the link itself is encrypted. While I'd presume that would be an inherent requirement of such networks, that's not stated. :-) 2. I wonder if such networks have the equivalent of LAG using multiple radios. If so, what do you expect to be the implications on BFD on LAG? -- Jeff From nobody Tue May 6 10:14:36 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9FC1A0196 for ; Tue, 6 May 2014 10:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5szELcjXcVWu for ; Tue, 6 May 2014 10:14:31 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7AF1A019C for ; Tue, 6 May 2014 10:14:31 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id ib6so1352200vcb.19 for ; Tue, 06 May 2014 10:14:27 -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=L+L945h8pn/zvMEODShIXFki8rISwpGhge5iYESmecM=; b=vfo6bzTOQX6G1umR/00D/CIM/9ZXits2tMD8x9y2NWkvmZ0A70D1QSxAMAQvM8siqj MUCei8BickLyBP3g9rS0kn43cZhRr6EhjXH3P5Dx+fLaG3t6eAr1vJ11HG/WUOVPPm3N 8ApA/rPpV3LQJTrWmCf8tV5TGZoQLqdu+Ro5n/GmzdvTUouSXABZPsc0lMj2HW9lyUl6 Ki3Uc2WrTWtQfLcQrVWwIcGK+VxKhL7rp0q5trKqdgPWTY/xjj8plv/oHJUm8eDrSgUi ysRZUTf8lJWUtuimLyjUQWKjOgQykwLx6sbB3FiooO8nRcKGfEqviuWc9rAUb2fBz4+G nXbQ== MIME-Version: 1.0 X-Received: by 10.52.228.134 with SMTP id si6mr23779023vdc.5.1399396467457; Tue, 06 May 2014 10:14:27 -0700 (PDT) Received: by 10.52.241.43 with HTTP; Tue, 6 May 2014 10:14:27 -0700 (PDT) In-Reply-To: <20140506160251.GA17758@pfrc> References: <20140421203314.GF8955@pfrc> <20140506160251.GA17758@pfrc> Date: Tue, 6 May 2014 13:14:27 -0400 Message-ID: Subject: Re: Working Group adoption for Seamless BFD (requires re-charter) From: Pablo Frank To: Jeffrey Haas Content-Type: multipart/alternative; boundary=089e0111e01057c24c04f8be614e Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/n3vji9eXZlQtjLqJHGLgk8he2aE Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 06 May 2014 17:14:35 -0000 --089e0111e01057c24c04f8be614e Content-Type: text/plain; charset=UTF-8 Ah well, if you're looking for "marketing" names: - Simple BFD - Speedy BFD - Swift BFD - Er, Sexy BFD? More seriously though, it seems like what you've really done is define a new Synchronous mode to augment the existing Asynchronous and Demand modes. So, um. Synchronous-BFD? regards, Pablo On Tue, May 6, 2014 at 12:02 PM, Jeffrey Haas wrote: > [apologies for top-posting] > > Working Group, > > The poll of the mailing list for support for re-chartering to include the > S-BFD work showed very nice support for the proposal. This includes both > chartering for the work and also for using the base and use case documents > as the initial seeds for the work. > > In a separate thread, we seem to have somewhat converged on possible > re-chartering text: > > : Define a mechanism to perform single-ended path (i.e. continuity) > : verification based on the BFD specification; allow such mechanism to work > : both proactively and on-demand, without prominent initial delay; allow > the > : mechanism to maintain multiple sessions to a target entity and between > the > : same pair of network entities. In doing this work, the WG will work > closely > : with at least the following other WGs: ISIS, OSPF, SPRING. > > While I feel "single-ended" isn't *quite* there, it's still much clearer > than seamless, in my opinion. Sender-initiated? (And "soft", also > proposed, had a nicer "marketing" feel to it.) > > Ah well, choosing names has always been a hard thing. > > This note is to give the authors a few additional days to finalize the name > we'll take to the IESG as part of the charter work. > (I.e. draft-ietf-bfd-s-something.) I have threatened Nobo that if a second > rename happens, the feature will be renamed "Fred". > > -- Jeff > > On Mon, Apr 21, 2014 at 04:33:14PM -0400, Jeffrey Haas wrote: > > Working Group, > > > > >From our last in-person IETF meeting in Vancouver, the S-BFD authors > were > > going to put additional work into their use cases and base protocol > document > > prior to requesting Working Group adoption. That work has since been > done > > and, IMO, the quality of the documents has nicely improved. > > > > But, being IETF work, we'd like to carry out further work on the > proposal in > > the openness of the WG. Thus, I'd like to request the Working Group to > > consider whether we'll want to adopt the Seamless BFD (S-BFD) documents. > > Note that this work is currently outside the scope of our charter and > would > > require a re-charter. Once we have a sense of the group for the > interest in > > this task we'll propose the charter update in support of the drafts. > > > > The following two documents are current and describe the work: > > > > http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ > > > > Given the scope of this feature, I would like to particularly remind the > > Working Group to focus on its security aspects. > > > > The following three documents are slightly stale as a result of the > > revisions in the base and use cases draft and will require an update. > > However, they provide a sense of how the S-BFD mechanisms might be used. > > > > Note in particular that the SR work will require coordination with the > > SPRING Working Group. > > > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ > > > > Finally, there is known future work targeting the distribution of the > > necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts > have > > been authored on the topic at this time, but work on them is expected. > > > > This begins a two week poll on whether the WG would like to adopt S-BFD > as a > > chartered task. This poll ends on May 6. > > > > As part of your response, please indicate if you have specific concerns > > about individual drafts being part of this work. > > > > Since Nobo is a contributor to this work, I will be taking the part of > the > > shepherding chair. > > > > -- Jeff > > --089e0111e01057c24c04f8be614e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah well, if you're looking for "marketing" n= ames:
- Simple BFD
- Speedy BFD
-= Swift BFD
- Er, Sexy BFD?

More seriously though, it seems like what you've really done is define = a new Synchronous mode to augment the existing Asynchronous and Demand mode= s. =C2=A0So, um. Synchronous-BFD?

rega= rds,
Pablo



On Tue, May 6, 2014 at 12:02 PM, Jeffre= y Haas <jhaas@pfrc.org> wrote:
[apologies for top-posting]

Working Group,

The poll of the mailing list for support for re-chartering to include the S-BFD work showed very nice support for the proposal. =C2=A0This includes b= oth
chartering for the work and also for using the base and use case documents<= br> as the initial seeds for the work.

In a separate thread, we seem to have somewhat converged on possible
re-chartering text:

: Define a mechanism to perform single-ended path (i.e. continuity)
: verification based on the BFD specification; allow such mechanism to work=
: both proactively and on-demand, without prominent initial delay; allow th= e
: mechanism to maintain multiple sessions to a target entity and between th= e
: same pair of network entities. In doing this work, the WG will work close= ly
: with at least the following other WGs: ISIS, OSPF, SPRING.

While I feel "single-ended" isn't *quite* there, it's sti= ll much clearer
than seamless, in my opinion. =C2=A0Sender-initiated? =C2=A0(And "soft= ", also
proposed, had a nicer "marketing" feel to it.)

Ah well, choosing names has always been a hard thing.

This note is to give the authors a few additional days to finalize the name=
we'll take to the IESG as part of the charter work.
(I.e. draft-ietf-bfd-s-something.) =C2=A0I have threatened Nobo that if a s= econd
rename happens, the feature will be renamed "Fred".

-- Jeff

On Mon, Apr 21, 2014 at 04:33:14PM -0400, Jeffrey Haas wrote:
> Working Group,
>
> >From our last in-person IETF meeting in Vancouver, the S-BFD autho= rs were
> going to put additional work into their use cases and base protocol do= cument
> prior to requesting Working Group adoption. =C2=A0That work has since = been done
> and, IMO, the quality of the documents has nicely improved.
>
> But, being IETF work, we'd like to carry out further work on the p= roposal in
> the openness of the WG. =C2=A0Thus, I'd like to request the Workin= g Group to
> consider whether we'll want to adopt the Seamless BFD (S-BFD) docu= ments.
> Note that this work is currently outside the scope of our charter and = would
> require a re-charter. =C2=A0Once we have a sense of the group for the = interest in
> this task we'll propose the charter update in support of the draft= s.
>
> The following two documents are current and describe the work:
>
> http://datatracker.ietf.org/doc/draft-aldrin-bf= d-seamless-use-case/
> http://datatracker.ietf.org/doc/draft-akiya-bfd-seam= less-base/
>
> Given the scope of this feature, I would like to particularly remind t= he
> Working Group to focus on its security aspects.
>
> The following three documents are slightly stale as a result of the > revisions in the base and use cases draft and will require an update.<= br> > However, they provide a sense of how the S-BFD mechanisms might be use= d.
>
> Note in particular that the SR work will require coordination with the=
> SPRING Working Group.
>
> http://datatracker.ietf.org/doc/draft-akiya= -bfd-seamless-alert-discrim/
> http://datatracker.ietf.org/doc/draft-akiya-bfd-seamle= ss-ip/
> http://datatracker.ietf.org/doc/draft-akiya-bfd-seamle= ss-sr/
>
> Finally, there is known future work targeting the distribution of the<= br> > necessary S-BFD bootstrapping information in OSPF and ISIS. =C2=A0No d= rafts have
> been authored on the topic at this time, but work on them is expected.=
>
> This begins a two week poll on whether the WG would like to adopt S-BF= D as a
> chartered task. =C2=A0This poll ends on May 6.
>
> As part of your response, please indicate if you have specific concern= s
> about individual drafts being part of this work.
>
> Since Nobo is a contributor to this work, I will be taking the part of= the
> shepherding chair.
>
> -- Jeff


--089e0111e01057c24c04f8be614e-- From nobody Tue May 6 10:45:37 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFBC1A0298 for ; Tue, 6 May 2014 10:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3miniNMx7SWC for ; Tue, 6 May 2014 10:45:31 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E2F1A0196 for ; Tue, 6 May 2014 10:45:30 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 115D32AA0F; Tue, 6 May 2014 17:45:22 +0000 (GMT) Date: Tue, 6 May 2014 10:45:23 -0700 From: Marc Binderberger To: Jeffrey Haas Message-ID: <20140506104523642324.744147db@sniff.de> In-Reply-To: <20140506160251.GA17758@pfrc> References: <20140421203314.GF8955@pfrc> <20140506160251.GA17758@pfrc> Subject: Re: Working Group adoption for Seamless BFD (requires re-charter) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/eOXwDhlEzSeFwNoMDD-iE-XegY4 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 06 May 2014 17:45:34 -0000 Hello Jeff et al., > While I feel "single-ended" isn't *quite* there, it's still much clearer > than seamless, in my opinion. Sender-initiated? (And "soft", also > proposed, had a nicer "marketing" feel to it.) > > Ah well, choosing names has always been a hard thing. indeed :-) Sender-initiated is a nice one too. It actually gets the idea that the session is under control of the Initiator (or Sender). Less "marketing", more descriptive. Old-fashion in these loud marketing days, I know ... :-) Marc On Tue, 6 May 2014 12:02:51 -0400, Jeffrey Haas wrote: > [apologies for top-posting] > > Working Group, > > The poll of the mailing list for support for re-chartering to include the > S-BFD work showed very nice support for the proposal. This includes both > chartering for the work and also for using the base and use case documents > as the initial seeds for the work. > > In a separate thread, we seem to have somewhat converged on possible > re-chartering text: > > : Define a mechanism to perform single-ended path (i.e. continuity) > : verification based on the BFD specification; allow such mechanism to work > : both proactively and on-demand, without prominent initial delay; allow the > : mechanism to maintain multiple sessions to a target entity and between the > : same pair of network entities. In doing this work, the WG will work > closely > : with at least the following other WGs: ISIS, OSPF, SPRING. > > While I feel "single-ended" isn't *quite* there, it's still much clearer > than seamless, in my opinion. Sender-initiated? (And "soft", also > proposed, had a nicer "marketing" feel to it.) > > Ah well, choosing names has always been a hard thing. > > This note is to give the authors a few additional days to finalize the name > we'll take to the IESG as part of the charter work. > (I.e. draft-ietf-bfd-s-something.) I have threatened Nobo that if a second > rename happens, the feature will be renamed "Fred". > > -- Jeff > > On Mon, Apr 21, 2014 at 04:33:14PM -0400, Jeffrey Haas wrote: >> Working Group, >> >>> From our last in-person IETF meeting in Vancouver, the S-BFD authors were >> going to put additional work into their use cases and base protocol >> document >> prior to requesting Working Group adoption. That work has since been done >> and, IMO, the quality of the documents has nicely improved. >> >> But, being IETF work, we'd like to carry out further work on the proposal >> in >> the openness of the WG. Thus, I'd like to request the Working Group to >> consider whether we'll want to adopt the Seamless BFD (S-BFD) documents. >> Note that this work is currently outside the scope of our charter and would >> require a re-charter. Once we have a sense of the group for the interest >> in >> this task we'll propose the charter update in support of the drafts. >> >> The following two documents are current and describe the work: >> >> http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ >> http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ >> >> Given the scope of this feature, I would like to particularly remind the >> Working Group to focus on its security aspects. >> >> The following three documents are slightly stale as a result of the >> revisions in the base and use cases draft and will require an update. >> However, they provide a sense of how the S-BFD mechanisms might be used. >> >> Note in particular that the SR work will require coordination with the >> SPRING Working Group. >> >> http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ >> http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ >> http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ >> >> Finally, there is known future work targeting the distribution of the >> necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts have >> been authored on the topic at this time, but work on them is expected. >> >> This begins a two week poll on whether the WG would like to adopt S-BFD as >> a >> chartered task. This poll ends on May 6. >> >> As part of your response, please indicate if you have specific concerns >> about individual drafts being part of this work. >> >> Since Nobo is a contributor to this work, I will be taking the part of the >> shepherding chair. >> >> -- Jeff > From nobody Tue May 6 11:14:04 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566901A0196 for ; Tue, 6 May 2014 11:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jiJBWs_wBXv for ; Tue, 6 May 2014 11:14:00 -0700 (PDT) Received: from ironport2.idirect.net (ironport2.dmz.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id AA0751A0192 for ; Tue, 6 May 2014 11:14:00 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport2.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.128; receiver=ironport2.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="4.97,998,1389762000"; d="scan'208";a="1403776" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport2.idirect.net with ESMTP; 06 May 2014 14:13:56 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Tue, 6 May 2014 14:13:56 -0400 From: "Snyder, Brian" To: Jeffrey Haas Subject: RE: FW: New Version Notification for draft-snyder-bfd-proxy-connections-monitored-links-00.txt Thread-Topic: FW: New Version Notification for draft-snyder-bfd-proxy-connections-monitored-links-00.txt Thread-Index: AQHPaJkWaoE5fYWylUqnpHbXTZ0qW5syYXkQgAGhEoD//9iOoA== Date: Tue, 6 May 2014 18:13:55 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7342FA4514@VAUS-MBX03.idirect.net> References: <20140505193415.20998.63258.idtracker@ietfa.amsl.com> <84585478AABBBF4B9DF597FC0F84AF7342FA3281@VAUS-MBX03.idirect.net> <20140506162925.GB17758@pfrc> In-Reply-To: <20140506162925.GB17758@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ispLyX7Iz9iU915MlKL_ga7O6Z8 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 06 May 2014 18:14:02 -0000 Jeff, Answers embedded.... Thanks for engaging.... Regards, Brian -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 Sent: Tuesday, May 06, 2014 12:29 PM To: Snyder, Brian Cc: rtg-bfd@ietf.org Subject: Re: FW: New Version Notification for draft-snyder-bfd-proxy-connec= tions-monitored-links-00.txt Brian, On Mon, May 05, 2014 at 08:03:19PM +0000, Snyder, Brian wrote: > Nobo and I have been working on publishing a new informational RFC=20 > related to proxying BFD via monitored links. This is written as a=20 > generalized solution for all monitored links, but with satellite use=20 > case as the primary example. Additionally, prior to writing this=20 > document, I have actually coded up a proof of concept which has been=20 > proven to work in the stated use case. >=20 > If anyone would care to review and comment it would be most appreciated. Thank you for bringing this to the Working Group's attention. The proposal= makes no changes to the BFD protocol from an endpoint's perspective, so th= ere is no specific requirement for BFD standards work. =20 Were you looking for this draft to be adopted within the WG? If so, it'd r= equire a minor re-chartering. [BS] - I had discussed this with Nobo a while back when I was starting the = project and he suggested there might be interest in an informational RFC. = I would like it to be adopted by a WG, though honestly, I'm not 100% sure= if it relates more to the BFD or the MANET group (I sent the notification = to both). Is that what you mean by 're-chartering'? Forgive me, but this i= s my first experience attempting to do something like this, so not sure... The novelty of this idea is that one would think DLEP was a better match to= my problem set, but after studying both, it turns out BFD (with a proxy) i= s actually much more suited to solve my problem.... Hence my confusion abo= ut the best WG to publish this too. I did have two bits of technical feedback on the draft: 1. The security considerations already discuss the need for the proxy to be= involved in the security. IMO, citing GTSM as a security mechanism is pro= bably not sufficient in such satellite networks without assurance that the = link itself is encrypted. While I'd presume that would be an inherent requ= irement of such networks, that's not stated. :-) [BS] - Fair enough. And yes, most sat networks do utilize RF link encrypti= on (some even use TRANSEC). It's optional (of course) - but I can make it = that clearer that it's an option/expectation for security needs. 2. I wonder if such networks have the equivalent of LAG using multiple radi= os. If so, what do you expect to be the implications on BFD on LAG? [BS] - The lag to geo sync satellites is ~ 260ms one way. The implication = I am making though is the proxy equipment is on the respective LAN sides (s= at hub and remotes) so the propogation RF LAG is not noticeable to the BFD = routing endpoints. -- Jeff From nobody Tue May 6 11:15:34 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408AA1A0196 for ; Tue, 6 May 2014 11:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtbtDZRbikrO for ; Tue, 6 May 2014 11:15:30 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC021A0192 for ; Tue, 6 May 2014 11:15:30 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id D3AC92AA0F; Tue, 6 May 2014 18:15:24 +0000 (GMT) Date: Tue, 6 May 2014 11:15:25 -0700 From: Marc Binderberger To: Pablo Frank Message-ID: <20140506111525438148.bb5a544d@sniff.de> In-Reply-To: References: <20140421203314.GF8955@pfrc> <20140506160251.GA17758@pfrc> Subject: Re: Working Group adoption for Seamless BFD (requires re-charter) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/-ooB8V4XASCKjL_L79-I4JIFu3I Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 06 May 2014 18:15:32 -0000 Maybe we should overcome our engineer limits and go for "S-BFD" _without_ any meaning? Just imagine a dynamically drawn "S" for the Logo ;-) Staying within the limits: Scallop in technical use means a loop or a curve, I think. And that's what we do, we send the packets on a round course. So Scallop-BFD ? ... doesn't sound "sexy" though :-) Okay, back to serious work, ahem. Marc On Tue, 6 May 2014 13:14:27 -0400, Pablo Frank wrote: > Ah well, if you're looking for "marketing" names: > - Simple BFD > - Speedy BFD > - Swift BFD > - Er, Sexy BFD? > > More seriously though, it seems like what you've really done is define a > new Synchronous mode to augment the existing Asynchronous and Demand > modes. So, um. Synchronous-BFD? > > regards, > Pablo > > > > On Tue, May 6, 2014 at 12:02 PM, Jeffrey Haas wrote: >> [apologies for top-posting] >> >> Working Group, >> >> The poll of the mailing list for support for re-chartering to include the >> S-BFD work showed very nice support for the proposal. This includes both >> chartering for the work and also for using the base and use case documents >> as the initial seeds for the work. >> >> In a separate thread, we seem to have somewhat converged on possible >> re-chartering text: >> >> : Define a mechanism to perform single-ended path (i.e. continuity) >> : verification based on the BFD specification; allow such mechanism to work >> : both proactively and on-demand, without prominent initial delay; allow >> the >> : mechanism to maintain multiple sessions to a target entity and between >> the >> : same pair of network entities. In doing this work, the WG will work >> closely >> : with at least the following other WGs: ISIS, OSPF, SPRING. >> >> While I feel "single-ended" isn't *quite* there, it's still much clearer >> than seamless, in my opinion. Sender-initiated? (And "soft", also >> proposed, had a nicer "marketing" feel to it.) >> >> Ah well, choosing names has always been a hard thing. >> >> This note is to give the authors a few additional days to finalize the name >> we'll take to the IESG as part of the charter work. >> (I.e. draft-ietf-bfd-s-something.) I have threatened Nobo that if a second >> rename happens, the feature will be renamed "Fred". >> >> -- Jeff >> >> On Mon, Apr 21, 2014 at 04:33:14PM -0400, Jeffrey Haas wrote: >>> Working Group, >>> >>> >From our last in-person IETF meeting in Vancouver, the S-BFD authors >> were >>> going to put additional work into their use cases and base protocol >> document >>> prior to requesting Working Group adoption. That work has since been >> done >>> and, IMO, the quality of the documents has nicely improved. >>> >>> But, being IETF work, we'd like to carry out further work on the >> proposal in >>> the openness of the WG. Thus, I'd like to request the Working Group to >>> consider whether we'll want to adopt the Seamless BFD (S-BFD) documents. >>> Note that this work is currently outside the scope of our charter and >> would >>> require a re-charter. Once we have a sense of the group for the >> interest in >>> this task we'll propose the charter update in support of the drafts. >>> >>> The following two documents are current and describe the work: >>> >>> http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ >>> http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ >>> >>> Given the scope of this feature, I would like to particularly remind the >>> Working Group to focus on its security aspects. >>> >>> The following three documents are slightly stale as a result of the >>> revisions in the base and use cases draft and will require an update. >>> However, they provide a sense of how the S-BFD mechanisms might be used. >>> >>> Note in particular that the SR work will require coordination with the >>> SPRING Working Group. >>> >>> http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/ >>> http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ >>> http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ >>> >>> Finally, there is known future work targeting the distribution of the >>> necessary S-BFD bootstrapping information in OSPF and ISIS. No drafts >> have >>> been authored on the topic at this time, but work on them is expected. >>> >>> This begins a two week poll on whether the WG would like to adopt S-BFD >> as a >>> chartered task. This poll ends on May 6. >>> >>> As part of your response, please indicate if you have specific concerns >>> about individual drafts being part of this work. >>> >>> Since Nobo is a contributor to this work, I will be taking the part of >> the >>> shepherding chair. >>> >>> -- Jeff >> > From nobody Tue May 6 11:43:53 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D3C1A01BB for ; Tue, 6 May 2014 11:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.152 X-Spam-Level: X-Spam-Status: No, score=-110.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjTf2d0mQBwa for ; Tue, 6 May 2014 11:43:51 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 125501A0234 for ; Tue, 6 May 2014 11:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6195; q=dns/txt; s=iport; t=1399401827; x=1400611427; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Sw74gm9uTbrVgeAOw+J9+0XVa0dyt6YXOIM8hCWQhcI=; b=C3vElSjJUjnmN19XyXRPAoJQt5cJStZrVyBDCsQM+zTZxRJsXc01BboD o3/0tXVQ/O9BLsJ/2zYs/hYWRFD4vRF7fnp5rizTyrfbQYE+CNG+k5agD Ow/sMrgyQyX7qjhh/OnuY+EA7XXCSeZqGTW8Z6tADTRY2KV1jQuc66ooP o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAQtaVOtJA2F/2dsb2JhbABZgmUhT1jEY4EgFnSCJQEBAQQ6NAEKDAQCAQgRBAEBAQoUCQcyFAkIAgQBDQUIiDkBDM4xF41vMjEHBoMkgRUEmnORP4M0gi8 X-IronPort-AV: E=Sophos;i="4.97,998,1389744000"; d="scan'208";a="41496017" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP; 06 May 2014 18:43:46 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s46Ihkvt013650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 May 2014 18:43:46 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Tue, 6 May 2014 13:43:46 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , Pablo Frank Subject: RE: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaDzsd8RqfWJjUqW3c8k2YnCwZs0IdOAgAAUAYCAABEJgP//rdhQ Date: Tue, 6 May 2014 18:43:45 +0000 Message-ID: References: <20140421203314.GF8955@pfrc> <20140506160251.GA17758@pfrc> <20140506111525438148.bb5a544d@sniff.de> In-Reply-To: <20140506111525438148.bb5a544d@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/MeZd4yB1TrTaqJCk-_wzmlffnfQ Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 06 May 2014 18:43:53 -0000 Uh lah lah, Scallop! Certainly not "sexy" but catchy and you know I love fish (and shell fish) := ) "synchronous" suggested by Pablo is not bad (thanks Pabrlo!), as well as ot= hers suggested by others. My thoughts, let us proceed with "seamless" since ... - There hasn't been a proposal that fits perfectly. - "seamless" is not bad and at least has a reason for the naming (mentioned= previously). - There are already couple of documents folks are working on, using the nam= e "seamless". - If name changes to X, then "Fred" is the only choice if we need to change= it again from X (my agreement with Jeff :)). With that said, floor is still open. If one can propose a good name and we = can have consensus, I'm ok with renaming. -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc > Binderberger > Sent: Tuesday, May 06, 2014 2:15 PM > To: Pablo Frank > Cc: rtg-bfd@ietf.org > Subject: Re: Working Group adoption for Seamless BFD (requires re-charter= ) >=20 >=20 > Maybe we should overcome our engineer limits and go for "S-BFD" > _without_ any meaning? Just imagine a dynamically drawn "S" for the > Logo ;-) >=20 > Staying within the limits: Scallop in technical use means a loop or a cur= ve, I > think. And that's what we do, we send the packets on a round course. So > Scallop-BFD ? ... doesn't sound "sexy" though :-) >=20 > Okay, back to serious work, ahem. >=20 > Marc >=20 >=20 >=20 >=20 > On Tue, 6 May 2014 13:14:27 -0400, Pablo Frank wrote: > > Ah well, if you're looking for "marketing" names: > > - Simple BFD > > - Speedy BFD > > - Swift BFD > > - Er, Sexy BFD? > > > > More seriously though, it seems like what you've really done is define > > a new Synchronous mode to augment the existing Asynchronous and > Demand > > modes. So, um. Synchronous-BFD? > > > > regards, > > Pablo > > > > > > > > On Tue, May 6, 2014 at 12:02 PM, Jeffrey Haas wrote: > >> [apologies for top-posting] > >> > >> Working Group, > >> > >> The poll of the mailing list for support for re-chartering to include > >> the S-BFD work showed very nice support for the proposal. This > >> includes both chartering for the work and also for using the base and > >> use case documents as the initial seeds for the work. > >> > >> In a separate thread, we seem to have somewhat converged on possible > >> re-chartering text: > >> > >> : Define a mechanism to perform single-ended path (i.e. continuity) > >> : verification based on the BFD specification; allow such mechanism > >> to work > >> : both proactively and on-demand, without prominent initial delay; > >> allow the > >> : mechanism to maintain multiple sessions to a target entity and > >> between the > >> : same pair of network entities. In doing this work, the WG will work > >> closely > >> : with at least the following other WGs: ISIS, OSPF, SPRING. > >> > >> While I feel "single-ended" isn't *quite* there, it's still much > >> clearer than seamless, in my opinion. Sender-initiated? (And > >> "soft", also proposed, had a nicer "marketing" feel to it.) > >> > >> Ah well, choosing names has always been a hard thing. > >> > >> This note is to give the authors a few additional days to finalize > >> the name we'll take to the IESG as part of the charter work. > >> (I.e. draft-ietf-bfd-s-something.) I have threatened Nobo that if a > >> second rename happens, the feature will be renamed "Fred". > >> > >> -- Jeff > >> > >> On Mon, Apr 21, 2014 at 04:33:14PM -0400, Jeffrey Haas wrote: > >>> Working Group, > >>> > >>> >From our last in-person IETF meeting in Vancouver, the S-BFD > >>> >authors > >> were > >>> going to put additional work into their use cases and base protocol > >> document > >>> prior to requesting Working Group adoption. That work has since > >>> been > >> done > >>> and, IMO, the quality of the documents has nicely improved. > >>> > >>> But, being IETF work, we'd like to carry out further work on the > >> proposal in > >>> the openness of the WG. Thus, I'd like to request the Working Group > >>> to consider whether we'll want to adopt the Seamless BFD (S-BFD) > documents. > >>> Note that this work is currently outside the scope of our charter > >>> and > >> would > >>> require a re-charter. Once we have a sense of the group for the > >> interest in > >>> this task we'll propose the charter update in support of the drafts. > >>> > >>> The following two documents are current and describe the work: > >>> > >>> http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ > >>> http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-base/ > >>> > >>> Given the scope of this feature, I would like to particularly remind > >>> the Working Group to focus on its security aspects. > >>> > >>> The following three documents are slightly stale as a result of the > >>> revisions in the base and use cases draft and will require an update. > >>> However, they provide a sense of how the S-BFD mechanisms might be > used. > >>> > >>> Note in particular that the SR work will require coordination with > >>> the SPRING Working Group. > >>> > >>> http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discr > >>> im/ http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > >>> http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-sr/ > >>> > >>> Finally, there is known future work targeting the distribution of > >>> the necessary S-BFD bootstrapping information in OSPF and ISIS. No > >>> drafts > >> have > >>> been authored on the topic at this time, but work on them is expected= . > >>> > >>> This begins a two week poll on whether the WG would like to adopt > >>> S-BFD > >> as a > >>> chartered task. This poll ends on May 6. > >>> > >>> As part of your response, please indicate if you have specific > >>> concerns about individual drafts being part of this work. > >>> > >>> Since Nobo is a contributor to this work, I will be taking the part > >>> of > >> the > >>> shepherding chair. > >>> > >>> -- Jeff > >> > > From nobody Tue May 6 12:01:34 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816AC1A0196 for ; Tue, 6 May 2014 12:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.152 X-Spam-Level: X-Spam-Status: No, score=-110.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFIYUfvm3k8Y for ; Tue, 6 May 2014 12:01:31 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 83A101A02F8 for ; Tue, 6 May 2014 12:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1616; q=dns/txt; s=iport; t=1399402886; x=1400612486; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IXViZQEMiGaR/OdT8oIhgBUl5cKaAUKoFw49urqr2cY=; b=FCI3STsuQjFdh5/SYYnUfbhlsWsZZ9RKlK0aQMIwwFHnSkBTQHzfFctO 9KyGJIT6szIC1fyz6f2zuHkzR3LGun45BqbmriAFUdlFZFVK2fdlZloGZ dj23S43wdiPzYAo2P+V1l9pieBof95FppHSiOYKrR4TkKI03lnSj6v1LK c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAIwwaVOtJA2F/2dsb2JhbABZgmUhgSfEY4EgFnSCJQEBAQMBOj0CBQsCAQgiFBAyHAkCBAENDYgxCAHOOheJMYRwMQeDKoEVAQOsMoF1gT+CLw X-IronPort-AV: E=Sophos;i="4.97,998,1389744000"; d="scan'208";a="41500066" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP; 06 May 2014 19:01:20 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s46J1Jb8026787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 May 2014 19:01:19 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Tue, 6 May 2014 14:01:19 -0500 From: "Nobo Akiya (nobo)" To: "Snyder, Brian" , Jeffrey Haas Subject: RE: FW: New Version Notification for draft-snyder-bfd-proxy-connections-monitored-links-00.txt Thread-Topic: FW: New Version Notification for draft-snyder-bfd-proxy-connections-monitored-links-00.txt Thread-Index: AQHPaJkAIoW6FeSubkyTbj2TSLnbl5syvL2AgAFWkoCAAB0ygP//tjJw Date: Tue, 6 May 2014 19:01:18 +0000 Message-ID: References: <20140505193415.20998.63258.idtracker@ietfa.amsl.com> <84585478AABBBF4B9DF597FC0F84AF7342FA3281@VAUS-MBX03.idirect.net> <20140506162925.GB17758@pfrc> <84585478AABBBF4B9DF597FC0F84AF7342FA4514@VAUS-MBX03.idirect.net> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7342FA4514@VAUS-MBX03.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/M7FnhE1dnieSEXwp4N00quisZtM Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 06 May 2014 19:01:32 -0000 Hi Jeff, Brian, all, > Thank you for bringing this to the Working Group's attention. The propos= al > makes no changes to the BFD protocol from an endpoint's perspective, so > there is no specific requirement for BFD standards work. >=20 > Were you looking for this draft to be adopted within the WG? If so, it'd > require a minor re-chartering. >=20 > [BS] - I had discussed this with Nobo a while back when I was starting th= e > project and he suggested there might be interest in an informational RFC.= I > would like it to be adopted by a WG, though honestly, I'm not 100% sure i= f it > relates more to the BFD or the MANET group (I sent the notification to bo= th). > Is that what you mean by 're-chartering'? Forgive me, but this is my firs= t > experience attempting to do something like this, so not sure... > The novelty of this idea is that one would think DLEP was a better match = to > my problem set, but after studying both, it turns out BFD (with a proxy) = is > actually much more suited to solve my problem.... Hence my confusion > about the best WG to publish this too. Initial direction of this BFD proxy was scoped only for Satellite, and targ= eted to the MANET WG. But a short chat with AD revealed that better directi= on may be to write this up as a generic BFD technique and share it with the= MANET WG. Although the document is more interesting from MANET angle, I th= ink pursuing this as a BFD document makes better sense. So yes, minor re-ch= arter will be needed by the BFD WG if the document can generate sufficient = interests. -Nobo From nobody Wed May 7 09:59:45 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E791A01B1 for ; Wed, 7 May 2014 09:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.152 X-Spam-Level: X-Spam-Status: No, score=-110.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6CmyGZmqKBF for ; Wed, 7 May 2014 09:59:43 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id E70A11A01AF for ; Wed, 7 May 2014 09:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4070; q=dns/txt; s=iport; t=1399481979; x=1400691579; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4QfB2zHDuDp0e/3hngbre13D6CCBweTJ03GWc5dbfWU=; b=EQUp7uqB8xjMcV6WCW41mL32VE/XEAxcqRMrInzzYwRX3v6apeHqpdAm 61G74Up1rQgEDYGg4BXoMDQki6ews+M5+hyGzU7iJxbRL68XKNc2JuAm9 kVzuowzZ37OZTEOckCGWaJGr6IwLRU9hWhE3m7XGIKsHSGjTvQn/Vxx8g E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAN9lalOtJV2c/2dsb2JhbABagmUhgSfFGgGBGhZ0giUBAQEDATo9AgwEAgEIEQQBAQEKFAkHMhQJCAIEAQ0FCIgxCAHQBheOITEHBoMkgRUBA6wygzSCLw X-IronPort-AV: E=Sophos;i="4.97,1004,1389744000"; d="scan'208";a="41823916" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 07 May 2014 16:59:37 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s47GxbVf031301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 16:59:37 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 7 May 2014 11:59:37 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , "MALLIK MUDIGONDA (mmudigon)" Subject: RE: New version notification for draft-akiya-bfd-seamless-base-03.txt Thread-Topic: New version notification for draft-akiya-bfd-seamless-base-03.txt Thread-Index: AQHPWjuSIo9hc5e0sES09J7I8hmrpZszQ9oAgAIcNkA= Date: Wed, 7 May 2014 16:59:35 +0000 Message-ID: References: <20140505192404062506.fcd0c154@sniff.de> In-Reply-To: <20140505192404062506.fcd0c154@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Y3nEIbnEbv1e2z4tl6IWEu99CHw Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 07 May 2014 16:59:44 -0000 Hi Marc, Please see inline. > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc > Binderberger > Sent: Monday, May 05, 2014 10:24 PM > To: MALLIK MUDIGONDA (mmudigon) > Cc: rtg-bfd@ietf.org > Subject: Re: New version notification for draft-akiya-bfd-seamless-base- > 03.txt >=20 > Hello Mallik and authors, >=20 > reading the new draft version, here some first feedback: Thanks for the first feedback! Look forward to seeing more :) >=20 > (1) You are fairly detailed in sections 9.2.2 and 9.3 what to copy over f= rom > the received into the responder packet but it does not mention what the > reflector is doing with the P/F flags. I assume it needs to copy them int= o the > reflected packet? P bit should be followed with F bit from the other side, in both directions= . So P/F bits aren't copied from received packet to transmitted packet at t= he reflector session. >=20 > Sure, you say in 9.5 "The Poll sequence MUST operate in accordance with > [RFC5880]." but details are missing. Agree, entire section 9 can benefit from a bit of restructuring. >=20 >=20 > (2) What I'm still wondering: why do you want to change the RFC5880 state > machine? I would assume that if you want to re-use code/hw on the > Initiator > side then that's the last thing to change. And you don't need to: >=20 > * Initiator sends out the usual Down/Init/Up as per RFC5880 > * Reflector simply copies the state into the reply packet > (or overwrites the state field with AdminDown) >=20 > Play it through - it works ;-) More important there is a subtle differen= ce > of simply going to "Up" state when receiving "Up" packets and filling the > packet path with Down, then Init, then Up. If we strictly look at this from the protocol perspective, there is no need= for the initiator to have INIT state (it doesn't even make sense to have o= ne). ADMINDOWN might still be useful to have, to allow the initiator sessio= n to be enabled/disabled. Thu I think it's correct for the new FSM to be av= ailable for this. We may need to add ADMINDOWN back in though ... thoughts? Now, if we apply the new FSM to existing implementation, I suppose RFC5880 = FSM can be re-used, as long as the implementation properly transitions *thr= ough* INIT state. But I see this as an implementation detail, and should be= left out from the document. >=20 >=20 > (3) Nitpick: section 9.1.1 says "The notation on each arc represents the > state of the remote system" - there is no state of the remote system, the > reflector is stateless ;-) Good catch. Agree that sentence should be rewritten to remove "state of the= remote system" out. >=20 >=20 > (4) Section 11 "Scaling Aspects". The "total number of BFD sessions in a > network" - why would this be a relevant number? This is not RSVP-based TE > tunnels where some core nodes may indeed come close to the N * (N - 1) > number > of RSVP tunnel state for an any-any mesh. But a BFD session is just a bit= of > traffic in the forwarding plane for most routers, only sender/receiver ta= ke a > hit. > True, there is still the factor of about "2" per single router. I would > propose keeping the first paragraph of 11 but remove the rest. You are right, everything below the first paragraph is just a bit noisy. Ye= s I agree that we should only keep the first paragraph of section 11 (i.e. = remove the rest). -Nobo >=20 >=20 > Have to re-read your draft for the other parts, especially the D-bit ;-) >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On Thu, 17 Apr 2014 12:50:12 +0000, MALLIK MUDIGONDA (mmudigon) > wrote: > > Hello BFD WG Members, > > > > We have published a new version of Seamless BFD draft, > > draft-akiya-bfd-seamless-base-03. Several sections have been updated fo= r > > improving readability. It also has a few technical changes as well. Ple= ase > > review the draft and get back to us with your comments. > > > > Thanks > > > > Regards > > Mallik From nobody Wed May 7 13:17:00 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2680D1A0207 for ; Wed, 7 May 2014 13:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QN7DwHagTsdn for ; Wed, 7 May 2014 13:16:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 56E351A039B for ; Wed, 7 May 2014 13:16:53 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3109BC1FA; Wed, 7 May 2014 16:16:49 -0400 (EDT) Date: Wed, 7 May 2014 16:16:49 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: Working Group adoption for Seamless BFD (requires re-charter) Message-ID: <20140507201649.GI17758@pfrc> References: <20140421203314.GF8955@pfrc> <20140506160251.GA17758@pfrc> <20140506111525438148.bb5a544d@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/_pKtMt6c7INz-pA_9DSD2dSQt5o Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 07 May 2014 20:16:59 -0000 On Tue, May 06, 2014 at 06:43:45PM +0000, Nobo Akiya (nobo) wrote: > Uh lah lah, Scallop! > > Certainly not "sexy" but catchy and you know I love fish (and shell fish) :) > > "synchronous" suggested by Pablo is not bad (thanks Pabrlo!), as well as others suggested by others. > > My thoughts, let us proceed with "seamless" since ... > > - There hasn't been a proposal that fits perfectly. > - "seamless" is not bad and at least has a reason for the naming (mentioned previously). > - There are already couple of documents folks are working on, using the name "seamless". > - If name changes to X, then "Fred" is the only choice if we need to change it again from X (my agreement with Jeff :)). > > With that said, floor is still open. If one can propose a good name and we can have consensus, I'm ok with renaming. Ok, I think I've been bullied down as being the outlier. Just make sure to amend the main document with what "seamless" means - see prior discussion. I'll send off the charter request momentarily. -- Jeff From nobody Wed May 7 13:24:33 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E231A03A6 for ; Wed, 7 May 2014 13:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6oyjqPbCu2n for ; Wed, 7 May 2014 13:24:25 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A93BA1A03AA for ; Wed, 7 May 2014 13:24:25 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 85741C1FA; Wed, 7 May 2014 16:24:21 -0400 (EDT) Date: Wed, 7 May 2014 16:24:21 -0400 From: Jeffrey Haas To: "Snyder, Brian" Subject: Re: FW: New Version Notification for draft-snyder-bfd-proxy-connections-monitored-links-00.txt Message-ID: <20140507202421.GJ17758@pfrc> References: <20140505193415.20998.63258.idtracker@ietfa.amsl.com> <84585478AABBBF4B9DF597FC0F84AF7342FA3281@VAUS-MBX03.idirect.net> <20140506162925.GB17758@pfrc> <84585478AABBBF4B9DF597FC0F84AF7342FA4514@VAUS-MBX03.idirect.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7342FA4514@VAUS-MBX03.idirect.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/fXDx4fYaZ6HHyW8ZpboKVyMZRgA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 07 May 2014 20:24:31 -0000 Brian, On Tue, May 06, 2014 at 06:13:55PM +0000, Snyder, Brian wrote: > Were you looking for this draft to be adopted within the WG? If so, it'd require a minor re-chartering. > > [BS] - I had discussed this with Nobo a while back when I was starting the > project and he suggested there might be interest in an informational RFC. > I would like it to be adopted by a WG, though honestly, I'm not 100% sure > if it relates more to the BFD or the MANET group (I sent the notification > to both). Is that what you mean by 're-chartering'? Forgive me, but this > is my first experience attempting to do something like this, so not > sure... Chartering in the IETF WG context is the list of things IETF "management" have agreed we can officially work on. :-) http://datatracker.ietf.org/wg/bfd/charter/ Based on Nobo's feedback elsewhere in the thread, I think it makes sense to hold off on a charter/adoption request until you've had a chance to get this shown around in manet as well. Once you've done that and are wanting to get this adopted by a working group, BFD would be a fine home for the work, I think. > I did have two bits of technical feedback on the draft: > 1. The security considerations already discuss the need for the proxy to be involved in the security. IMO, citing GTSM as a security mechanism is probably not sufficient in such satellite networks without assurance that the link itself is encrypted. While I'd presume that would be an inherent requirement of such networks, that's not stated. :-) > > [BS] - Fair enough. And yes, most sat networks do utilize RF link encryption (some even use TRANSEC). It's optional (of course) - but I can make it that clearer that it's an option/expectation for security needs. The issue is that since BFD is a connectionless protocol, on a RF link there is a greater than normal chance for insertion of malicious traffic when there is no encryption. Since BFD being told that it is down can trigger bad behaviors by its consumers, this is a Bad Thing. :-) A comment on the sensitivity of BFD and the need either for layer 2 encryption to protect against this along with GTSM and/or strong BFD authentication would address the concern. > 2. I wonder if such networks have the equivalent of LAG using multiple radios. If so, what do you expect to be the implications on BFD on LAG? > > [BS] - The lag to geo sync satellites is ~ 260ms one way. The implication I am making though is the proxy equipment is on the respective LAN sides (sat hub and remotes) so the propogation RF LAG is not noticeable to the BFD routing endpoints. Ok, so link bundles are an unlikely feature in this case. Thanks for answering. -- Jeff From nobody Wed May 7 13:30:59 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777FA1A01AC for ; Wed, 7 May 2014 13:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-J3Hb2aVHSX for ; Wed, 7 May 2014 13:30:55 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 915B51A019B for ; Wed, 7 May 2014 13:30:55 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB564.namprd05.prod.outlook.com (10.141.202.150) with Microsoft SMTP Server (TLS) id 15.0.939.12; Wed, 7 May 2014 20:30:44 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0934.000; Wed, 7 May 2014 20:30:44 +0000 From: John E Drake To: Jeffrey Haas , "Nobo Akiya (nobo)" Subject: RE: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaEVlAeQUN48aUWxeYkIHlSU/ZszzgGAgAAUAYCAABEJgIAAB+qAgAGsVoCAAAOj8A== Date: Wed, 7 May 2014 20:30:44 +0000 Message-ID: <3807ec8a825e499fa664d52ab76e0b2c@BLUPR05MB562.namprd05.prod.outlook.com> References: <20140421203314.GF8955@pfrc> <20140506160251.GA17758@pfrc> <20140506111525438148.bb5a544d@sniff.de> <20140507201649.GI17758@pfrc> In-Reply-To: <20140507201649.GI17758@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(24454002)(51704005)(377454003)(13464003)(74502001)(2656002)(87936001)(31966008)(4396001)(99286001)(74662001)(54356999)(76176999)(77096999)(83322001)(19580405001)(19580395003)(21056001)(74316001)(99396002)(50986999)(81542001)(79102001)(20776003)(77982001)(86362001)(92566001)(85852003)(83072002)(66066001)(561944002)(80022001)(64706001)(81342001)(76576001)(46102001)(101416001)(76482001)(33646001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB564; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/6zOZ8IpFIaYjS6lyx_1rWKELqZs Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 07 May 2014 20:30:57 -0000 seam*less (of a fabric or surface) smooth and without seams or obvious joins. "seamless stockings" smooth and continuous, with no apparent gaps or spaces between one part and= the next. "the seamless integration of footage from different sources" Yours Irrespectively, John > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Wednesday, May 07, 2014 1:17 PM > To: Nobo Akiya (nobo) > Cc: rtg-bfd@ietf.org > Subject: Re: Working Group adoption for Seamless BFD (requires re-charter= ) >=20 > On Tue, May 06, 2014 at 06:43:45PM +0000, Nobo Akiya (nobo) wrote: > > Uh lah lah, Scallop! > > > > Certainly not "sexy" but catchy and you know I love fish (and shell > > fish) :) > > > > "synchronous" suggested by Pablo is not bad (thanks Pabrlo!), as well a= s > others suggested by others. > > > > My thoughts, let us proceed with "seamless" since ... > > > > - There hasn't been a proposal that fits perfectly. > > - "seamless" is not bad and at least has a reason for the naming (menti= oned > previously). > > - There are already couple of documents folks are working on, using the > name "seamless". > > - If name changes to X, then "Fred" is the only choice if we need to ch= ange it > again from X (my agreement with Jeff :)). > > > > With that said, floor is still open. If one can propose a good name and= we can > have consensus, I'm ok with renaming. >=20 > Ok, I think I've been bullied down as being the outlier. Just make sure = to > amend the main document with what "seamless" means - see prior discussion= . >=20 > I'll send off the charter request momentarily. >=20 > -- Jeff From nobody Wed May 7 13:52:40 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF9C1A02F1 for ; Wed, 7 May 2014 13:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNgtd8E3M4iE for ; Wed, 7 May 2014 13:52:35 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 84BC11A0383 for ; Wed, 7 May 2014 13:52:35 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3D9A5C1FA; Wed, 7 May 2014 16:52:31 -0400 (EDT) Date: Wed, 7 May 2014 16:52:31 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org, Adrian Farrel Subject: Proposed BFD Charter -08 Message-ID: <20140507205231.GM17758@pfrc> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/hgEVRymm_x4pzM0NPA0O0sQHoMU Cc: mpls-chairs@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 07 May 2014 20:52:37 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Working Group, The following charter is proposed to be -08. The existing charter is here: http://datatracker.ietf.org/doc/charter-ietf-bfd/ Changes: Update to reflect that there are still MIBs that are in-charter that aren't done, in particular the bfd mpls MIB. The authentication MIB extension is still covered by 2b. Remove the charter item for MPLS-TP. I believe this work is done, but am copying the MPLS chairs to confirm. Remove BFD on LAG. While there had been some discussion about providing for bootstrapping mechanisms for it, they have failed to gain traction several times. Thus, I think we're done on this. Add the S-BFD charter item. Proposed milestones for S-BFD work: Use Case document: November 2014 S-BFD base: March 2015 S-BFD for IP: July 2015 S-BFD for SR: July 2015 S-BFD alert discriminator: July 2015 Please provide comments ASAP. Since I don't really expect any of this to be controversial, the intent is for our AD to take this to the next telechat which takes place next week. -- Jeff ---------------------------8<----- cut here ---->8--------------------------- The BFD Working Group is chartered to standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware. - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course). - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. The working group is currently chartered to complete the following work items: 1. Develop the MIB modules for BFD and submit them to the IESG for publication as a Proposed Standard. 2a. Provide a generic keying-based cryptographic authentication mechanism for the BFD protocol in discussion with the KARP working group. This mechanism will support authentication through a key identifier for the BFD session's Security Association rather than specifying new authentication extensions. 2b. Provide extensions to the BFD MIB in support of the generic keying- based cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks. 4. Provide an informational document to recommend standardized timers and timer operations for BFD when used in different applications. 5. Define a mechanism to perform single-ended path (i.e. continuity) verification based on the BFD specification. Allow such a mechanism to work both proactively and on-demand, without prominent initial delay. Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG will work closely with at least the following other WGs: ISIS, OSPF, SPRING. The working group will maintain a relationship with the KARP and MPLS working groups, and will communicate with the IEEE with respect to BFD over LAGs. --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="diff-07-08.txt" commit 85577b8dd7f7d7b98d65507cc4473e39df18dcb3 Author: Jeffrey Haas Date: Wed May 7 16:40:37 2014 -0400 Proposed -08 diff --git a/bfd-charter.txt b/bfd-charter.txt index 12f6950..0d691d8 100644 --- a/bfd-charter.txt +++ b/bfd-charter.txt @@ -35,9 +35,9 @@ Important characteristics of BFD include: forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. -The working group is chartered to complete the following work items: +The working group is currently chartered to complete the following work items: -1. Develop the MIB module for BFD and submit it to the IESG for +1. Develop the MIB modules for BFD and submit them to the IESG for publication as a Proposed Standard. 2a. Provide a generic keying-based cryptographic authentication @@ -57,16 +57,16 @@ the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks. -4. Assist the MPLS working group in the standardization of the BFD -protocol for MPLS-TP. The preferred solution will be interoperable with -the current BFD specification. - -5. Provide one or more mechanisms to run BFD over Link Aggregation Group -Interfaces. - -6. Provide an informational document to recommend standardized timers +4. Provide an informational document to recommend standardized timers and timer operations for BFD when used in different applications. +5. Define a mechanism to perform single-ended path (i.e. continuity) +verification based on the BFD specification. Allow such a mechanism to work +both proactively and on-demand, without prominent initial delay. Allow the +mechanism to maintain multiple sessions to a target entity and between the same +pair of network entities. In doing this work, the WG will work closely with at +least the following other WGs: ISIS, OSPF, SPRING. + The working group will maintain a relationship with the KARP and MPLS working groups, and will communicate with the IEEE with respect to BFD over LAGs. --45Z9DzgjV8m4Oswq-- From nobody Wed May 7 13:56:07 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF1C1A02F1 for ; Wed, 7 May 2014 13:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuL8nVuHujCh for ; Wed, 7 May 2014 13:56:00 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id AAF8B1A01C0 for ; Wed, 7 May 2014 13:56:00 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-a3-536a4ed53011 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id EC.30.07420.5DE4A635; Wed, 7 May 2014 17:18:45 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Wed, 7 May 2014 16:55:52 -0400 From: Gregory Mirsky To: Jeffrey Haas , "rtg-bfd@ietf.org" , Adrian Farrel Subject: RE: Proposed BFD Charter -08 Thread-Topic: Proposed BFD Charter -08 Thread-Index: AQHPajZJxY7nehyzmE2XKLUUfBayn5s1mJwQ Date: Wed, 7 May 2014 20:55:51 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7ABB64@eusaamb103.ericsson.se> References: <20140507205231.GM17758@pfrc> In-Reply-To: <20140507205231.GM17758@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyuXRPiO5Vv6xgg73nFS1+9Nxgtth/8C2r xfdLS1gsPv/ZxujA4rFkyU8mjxWbVzJ6XO7dyurx5fJntgCWKC6blNSczLLUIn27BK6MmXvP MRXs0KiYcPYFUwPjB4UuRk4OCQETid9/XrJB2GISF+6tB7K5OIQEjjJKTNoxiRnCWcYo8fbx IkaQKjYBI4kXG3vYQWwRgXyJ+ccms4LYzAK2EneeXAOrERZQldjzbwsbRI2axJNJ3xkhbCOJ P5engNWzCKhIrH+wEGwOr4CvxJOZf8BqhAQ0JTY0XGLqYuTg4BTQkli0nRkkzAh03PdTa5gg VolL3HoynwniaAGJJXvOM0PYohIvH/9jhbCVJCYtPQd1mo7Egt2f2CBsbYllC18zQ6wVlDg5 8wnLBEaxWUjGzkLSMgtJyywkLQsYWVYxcpQWp5blphsZbGIERtMxCTbdHYx7XloeYhTgYFTi 4VVgyQoWYk0sK67MPcQozcGiJM5b8CU2WEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjxqOO EUvie/4VuS60zLNX2JqetSmtTO27wNLiNRbM2d9DVU9bl5RoHOEuNyrINKsJX1GW+qj/RPIZ Dxe7qxzzP/Ly1KeZnJhacigovPegkSFPzSKN+R2T7jk2CfZv++LaFvz2V8iDg9PqunyMfzQV GfesMon7p7levUZ3/m9xF72p7C8fmiixFGckGmoxFxUnAgCaPOTzhwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ENRolvqTH0pRFDua40SpitdWbPc Cc: "mpls-chairs@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 07 May 2014 20:56:03 -0000 Hi Jeff, I think there will be use of S-BFD for MPLS as well. Can we add it with Jul= y 2015 target? Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Wednesday, May 07, 2014 1:53 PM To: rtg-bfd@ietf.org; Adrian Farrel Cc: mpls-chairs@tools.ietf.org Subject: Proposed BFD Charter -08 Working Group, The following charter is proposed to be -08. The existing charter is here: http://datatracker.ietf.org/doc/charter-ietf-bfd/ Changes: Update to reflect that there are still MIBs that are in-charter that aren't= done, in particular the bfd mpls MIB. The authentication MIB extension is= still covered by 2b. Remove the charter item for MPLS-TP. I believe this work is done, but am c= opying the MPLS chairs to confirm. Remove BFD on LAG. While there had been some discussion about providing fo= r bootstrapping mechanisms for it, they have failed to gain traction severa= l times. Thus, I think we're done on this. Add the S-BFD charter item. Proposed milestones for S-BFD work: Use Case document: November 2014 S-BFD base: March 2015 S-BFD for IP: July 2015 S-BFD for SR: July 2015 S-BFD alert discriminator: July 2015 Please provide comments ASAP. Since I don't really expect any of this to b= e controversial, the intent is for our AD to take this to the next telechat= which takes place next week. -- Jeff ---------------------------8<----- cut here ---->8-------------------------= -- The BFD Working Group is chartered to standardize and support the bidirecti= onal forwarding detection protocol (BFD) and its extensions. A core goal o= f the working group is to standardize BFD in the context of IP routing, or = protocols such as MPLS that are based on IP routing, in a way that will enc= ourage multiple, inter-operable vendor implementations. =20 The Working Group will also provide advice and guidance on BFD to other wor= king groups or standards bodies as requested. BFD is a protocol intended to detect faults in the bidirectional path betwe= en two forwarding engines, including physical interfaces, subinterfaces, da= ta link(s), and to the extent possible the forwarding engines themselves, w= ith potentially very low latency. It operates independently of media, data = protocols, and routing protocols. An additional goal is to provide a single= mechanism that can be used for liveness detection over any media, at any p= rotocol layer, with a wide range of detection times and overhead, to avoid = a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware. - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course). - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. The working group is currently chartered to complete the following work ite= ms: 1. Develop the MIB modules for BFD and submit them to the IESG for publicat= ion as a Proposed Standard. 2a. Provide a generic keying-based cryptographic authentication mechanism f= or the BFD protocol in discussion with the KARP working group. This mechan= ism will support authentication through a key identifier for the BFD sessi= on's Security Association rather than specifying new authentication extensi= ons. =20 2b. Provide extensions to the BFD MIB in support of the generic keying- bas= ed cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol us= ing HMAC-SHA-256 (possibly truncated to a smaller integrity check value but= not beyond commonly accepted lengths to ensure security) using the generic= keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to- mu= ltipoint links and networks. 4. Provide an informational document to recommend standardized timers and t= imer operations for BFD when used in different applications. 5. Define a mechanism to perform single-ended path (i.e. continuity) verifi= cation based on the BFD specification. Allow such a mechanism to work both= proactively and on-demand, without prominent initial delay. Allow the mec= hanism to maintain multiple sessions to a target entity and between the sam= e pair of network entities. In doing this work, the WG will work closely wi= th at least the following other WGs: ISIS, OSPF, SPRING. The working group will maintain a relationship with the KARP and MPLS worki= ng groups, and will communicate with the IEEE with respect to BFD over LAGs= . From nobody Wed May 7 13:57:48 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7A91A01C0 for ; Wed, 7 May 2014 13:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bG5vGiq5nN0 for ; Wed, 7 May 2014 13:57:45 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2351A01A0 for ; Wed, 7 May 2014 13:57:45 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F3A6CC1E4; Wed, 7 May 2014 16:57:40 -0400 (EDT) Date: Wed, 7 May 2014 16:57:40 -0400 From: Jeffrey Haas To: Gregory Mirsky Subject: Re: Proposed BFD Charter -08 Message-ID: <20140507205740.GO17758@pfrc> References: <20140507205231.GM17758@pfrc> <7347100B5761DC41A166AC17F22DF1121B7ABB64@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7ABB64@eusaamb103.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/FnZjzR64MYozdSprG_aXk_ddLUo Cc: "rtg-bfd@ietf.org" , "mpls-chairs@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 07 May 2014 20:57:46 -0000 On Wed, May 07, 2014 at 08:55:51PM +0000, Gregory Mirsky wrote: > I think there will be use of S-BFD for MPLS as well. Can we add it with July 2015 target? It seemed likely, but there was no I-D in the tracker that I noticed for it. Adding milestones is trivial and doesn't have to be part of the charter process. Let's add it once the document exists. :-) (As our AD points out, getting milestones actually *done* is the harder thing.) -- Jeff From nobody Wed May 7 14:14:58 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A9D1A039C for ; Wed, 7 May 2014 14:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWnvyt8x7tZl for ; Wed, 7 May 2014 14:14:55 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id B72111A01A0 for ; Wed, 7 May 2014 14:14:54 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s47LEkGE016536; Wed, 7 May 2014 22:14:46 +0100 Received: from 950129200 ([190.112.53.202]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s47LEhXe016519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 May 2014 22:14:45 +0100 From: "Adrian Farrel" To: "'Jeffrey Haas'" , "'Gregory Mirsky'" References: <20140507205231.GM17758@pfrc> <7347100B5761DC41A166AC17F22DF1121B7ABB64@eusaamb103.ericsson.se> <20140507205740.GO17758@pfrc> In-Reply-To: <20140507205740.GO17758@pfrc> Subject: RE: Proposed BFD Charter -08 Date: Wed, 7 May 2014 22:14:37 +0100 Message-ID: <01f701cf6a39$5b958740$12c095c0$@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: AQE2IyGcA8PXTHfjDyNLU+rJIn9RWQI5TLR7Ab86r1+cSGevcA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20680.002 X-TM-AS-Result: No--17.250-10.0-31-10 X-imss-scan-details: No--17.250-10.0-31-10 X-TMASE-MatchedRID: zGP2F0O7j/vDBNgbKIiiTMAmcZEx8XHJusAd8fYg+ZAk4mHxl56uocLm p4jPUF8tgvRaVUNx1oCHxElsCp/L5qTQXj+P7SBGmlaAItiONP1Aq6/y5AEOOvgnJH5vm2+gI3V 2O8NUcFpofWsbbIQfcHRadcEjXiEA2vHXB5YKlQWRfvUfL+585m79evoIpeI3uu0N7j6PSiPHP6 6OOSvGlcvtru+GnDoIgDLqnrRlXrY3zuRrgWxGGP7E6GNqs6ceavP8b9lJtWr6C0ePs7A07QKmA RN5PTKc Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/i4SFxWDwLlb1yaaueAFPsS-TztU Cc: rtg-bfd@ietf.org, mpls-chairs@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 07 May 2014 21:14:57 -0000 Hi, Millstones are easy to add and change. The chairs can just do it and I tick the box. Just focus on the charter text itself. A > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: 07 May 2014 21:58 > To: Gregory Mirsky > Cc: Jeffrey Haas; rtg-bfd@ietf.org; Adrian Farrel; mpls-chairs@tools.ietf.org > Subject: Re: Proposed BFD Charter -08 > > On Wed, May 07, 2014 at 08:55:51PM +0000, Gregory Mirsky wrote: > > I think there will be use of S-BFD for MPLS as well. Can we add it with July 2015 > target? > > It seemed likely, but there was no I-D in the tracker that I noticed for it. > Adding milestones is trivial and doesn't have to be part of the charter > process. Let's add it once the document exists. :-) > > (As our AD points out, getting milestones actually *done* is the harder > thing.) > > -- Jeff From nobody Wed May 7 14:51:19 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FC91A03A6 for ; Wed, 7 May 2014 14:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oavyyyGyi6Nr for ; Wed, 7 May 2014 14:51:15 -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 8585D1A0362 for ; Wed, 7 May 2014 14:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=523; q=dns/txt; s=iport; t=1399499471; x=1400709071; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DgwyA6hekl5VYlL/bH8OY0+oAhvcmHphMxDPEcmeDuw=; b=mKRHL+L0wIaKa2nCP3FqMIHQbpfiUY/LMqkYe2GEDCigI1e5iyZMkBwq 8U/Siuh5YGiaPsItOdNOBak7jHvnIlnL+Cp2T2of1cmy+NUbwce8Z5Hk3 WxlUFMIyacox+/23HU/yJm5YhhqTNqOE3q2pQt0hgmv3VBrwjs5yUYNkX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAN+palOtJA2G/2dsb2JhbABagmUhgSfFHwGBHBZ0giYBAQQ6PxACAQgiFBAyJQIEAQ0NiDkB0BcXjiExB4MqgRUBA6wygzSCLw X-IronPort-AV: E=Sophos;i="4.97,1006,1389744000"; d="scan'208";a="322959833" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP; 07 May 2014 21:51:11 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s47LpAVj023336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 21:51:11 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Wed, 7 May 2014 16:51:10 -0500 From: "Nobo Akiya (nobo)" To: John E Drake , Jeffrey Haas Subject: RE: Working Group adoption for Seamless BFD (requires re-charter) Thread-Topic: Working Group adoption for Seamless BFD (requires re-charter) Thread-Index: AQHPXaDzsd8RqfWJjUqW3c8k2YnCwZs0IdOAgAAUAYCAABEJgP//rdhQgAIGaICAAAPjAP//wafQ Date: Wed, 7 May 2014 21:51:09 +0000 Message-ID: References: <20140421203314.GF8955@pfrc> <20140506160251.GA17758@pfrc> <20140506111525438148.bb5a544d@sniff.de> <20140507201649.GI17758@pfrc> <3807ec8a825e499fa664d52ab76e0b2c@BLUPR05MB562.namprd05.prod.outlook.com> In-Reply-To: <3807ec8a825e499fa664d52ab76e0b2c@BLUPR05MB562.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/OfytitIzPSnUyGpYjmA97Soth7U Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 07 May 2014 21:51:17 -0000 Hi Jeff, John, [from Jeff] > > Ok, I think I've been bullied down as being the outlier. Just make > > sure to amend the main document with what "seamless" means - see prior > discussion. Sounds good. We'll add texts in draft-ietf...-01. [from John] > smooth and continuous, with no apparent gaps or spaces between one part > and the next. > "the seamless integration of footage from different sources" "smooth and continuous" may fit nicely into the texts to add, thanks for th= e suggestion! -Nobo From nobody Wed May 7 14:59:28 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158371A03F4 for ; Wed, 7 May 2014 14:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5szhzwn7z_xb for ; Wed, 7 May 2014 14:59:25 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 047CB1A03F2 for ; Wed, 7 May 2014 14:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=442; q=dns/txt; s=iport; t=1399499961; x=1400709561; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=epcAcx3c5j6/i7ZqifQkDhe4qj4Z0pbGj0IUkpdWGO0=; b=O/RqaRL34jAwUjXdbBrN1JDO4EHah4rvMIykrHbBAtmOf9w8WmKbgYq4 LCF+I7Nmg4Ly5PNEoiho1TFhY/oBXNTNoY6iZKEkVfmb6PiCkUyQQD30u myzh3cPjydXIyUExTwSdFY0Hat9VWeQGEleL/PBuSFTdQRUA001EUUDxB o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAIWralOtJA2H/2dsb2JhbABagmUhgSfFHwGBHRZ0giUBAQEDATo4BwULAgEIDhQUEDIlAgQBDQ2IMQgB0BYXjiExB4MqgRUBA6wygzSCLw X-IronPort-AV: E=Sophos;i="4.97,1006,1389744000"; d="scan'208";a="323242102" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 07 May 2014 21:59:19 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s47LxI4O012101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 21:59:19 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Wed, 7 May 2014 16:59:18 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas , "rtg-bfd@ietf.org" , Adrian Farrel Subject: RE: Proposed BFD Charter -08 Thread-Topic: Proposed BFD Charter -08 Thread-Index: AQHPajZKrNkBG6cvPUKlD7GUmERsC5s1qTzg Date: Wed, 7 May 2014 21:59:17 +0000 Message-ID: References: <20140507205231.GM17758@pfrc> In-Reply-To: <20140507205231.GM17758@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/tq8LSxCfR3m2R33YdAq5yf0MnPU Cc: "mpls-chairs@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 07 May 2014 21:59:26 -0000 Thanks for proposing the new charter Jeff. One comment on the last sentence of the charter. > The working group will maintain a relationship with the KARP and MPLS > working groups, and will communicate with the IEEE with respect to BFD > over LAGs. I believe the latter portion of the sentence (i.e. ", and will communicate = ....") can also be removed, since we've removed the BFD on LAG from current= charter item. -Nobo From nobody Wed May 7 18:26:54 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1FD1A0453 for ; Wed, 7 May 2014 18:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8UL9EO0RY_x for ; Wed, 7 May 2014 18:26:32 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 776D51A044D for ; Wed, 7 May 2014 18:26:31 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 3CEA12AA0F; Thu, 8 May 2014 01:26:25 +0000 (GMT) Date: Wed, 7 May 2014 18:26:23 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) Message-ID: <20140507182623711086.aef91e5c@sniff.de> In-Reply-To: References: <20140505192404062506.fcd0c154@sniff.de> Subject: RE: New version notification for draft-akiya-bfd-seamless-base-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/OShfN_XEVygjhLNtQpszLSNRTTk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 May 2014 01:26:35 -0000 Hello Nobo, thanks for the reply! > P bit should be followed with F bit from the other side, in both=20 > directions. So P/F bits aren't copied from received packet to transmitted= =20 > packet at the reflector session. ah okay, the reflector sees "P" and sets "F" when sending the reflected=20 packet? Good idea. > If we strictly look at this from the protocol perspective, there is no ne= ed=20 > for the initiator to have INIT state agree, a minimal FSM can do without. > (it doesn't even make sense to have one). disagree, it can serve a purpose. Effectively the same it does for async BF= D,=20 that you are not jumping immediately into Up state again on receiving an "U= p"=20 packet. You first need to confirm the Down, which for S-BFD means you see= =20 your own Down first before. You are "flushing out" all Up packets in the pa= th. Otherwise you may see flaps, depending on the interruption. Which of course= =20 you can cure with holddown timers in your implementation - but why not usin= g=20 this nice (?) behaviour of the existing FSM? > We may need to add ADMINDOWN back in though ...=20 > thoughts? maybe not necessary but useful, yes. > Now, if we apply the new FSM to existing implementation, I suppose RFC588= 0=20 > FSM can be re-used, as long as the implementation properly transitions=20 > *through* INIT state. But I see this as an implementation detail, and=20 > should be left out from the document. my point is that a new FSM means "work" on the Initiator side. If this is= =20 complete new code or just a modification - speculation, it depends on the= =20 code/hw. Preferably (for me) there would be no change on the Initiator side= =20 and all changes on the Reflector side, which needs to be implemented "from= =20 scratch" anyway. Well, see below. =46rom a formal point of view ... I don't mind a new FSM but we should then= =20 stop referring to RFC5880. Actually the D-flag is the same story, the new= =20 state variable does not make it compatible to RFC5880 (*) IMHO. Depends on what you want: you can write a "new" BFD for the Initiator with= =20 some references to or copies from RFC5880, e.g. C-Bit and Poll sequence I= =20 guess can be borrowed 1:1. There is nothing wrong with it, it may be actual= ly=20 more honest and avoids rules that only serve the compatibility, not the=20 functionality. You can define a new FSM, you can use the place of the D-bit= =20 for your R-eflector bit etc.. The other extreme would be to re-use the existing packet engine (I/O, FSM,= =20 5880 rules). Running existing BFD 5880/5881 against a simple reflector does= =20 work (tested, yes :-) , so I guess this would work for your more elaborate= =20 reflector as well. And if it doesn't work, then see above, go with a clean= =20 new definition.=20 I say "packet engine" because that part matters for IETF, for the interop.= =20 The code e.g. selecting a discriminator will likely change as you have new= =20 requirements for S-BFD. But that code is largely "implementation specific"= =20 and outside the scope of most documents. Regards, Marc (*): it is a nice structure for the implementor though. Wrap "if (!sbf) { .= ..=20 }" around existing Demand code and add "if (sbfd) { ... }" for the S-BFD=20 D-flag code. But that was not why several people including me had a bad=20 feeling. On Wed, 7 May 2014 16:59:35 +0000, Nobo Akiya (nobo) wrote: > Hi Marc, >=20 > Please see inline. >=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc >> Binderberger >> Sent: Monday, May 05, 2014 10:24 PM >> To: MALLIK MUDIGONDA (mmudigon) >> Cc: rtg-bfd@ietf.org >> Subject: Re: New version notification for draft-akiya-bfd-seamless-base- >> 03.txt >>=20 >> Hello Mallik and authors, >>=20 >> reading the new draft version, here some first feedback: >=20 > Thanks for the first feedback! > Look forward to seeing more :) >=20 >>=20 >> (1) You are fairly detailed in sections 9.2.2 and 9.3 what to copy over= =20 >> from >> the received into the responder packet but it does not mention what the >> reflector is doing with the P/F flags. I assume it needs to copy them in= to=20 >> the >> reflected packet? >=20 > P bit should be followed with F bit from the other side, in both=20 > directions. So P/F bits aren't copied from received packet to transmitted= =20 > packet at the reflector session. >=20 >>=20 >> Sure, you say in 9.5 "The Poll sequence MUST operate in accordance with >> [RFC5880]." but details are missing. >=20 > Agree, entire section 9 can benefit from a bit of restructuring. >=20 >>=20 >>=20 >> (2) What I'm still wondering: why do you want to change the RFC5880 stat= e >> machine? I would assume that if you want to re-use code/hw on the >> Initiator >> side then that's the last thing to change. And you don't need to: >>=20 >> * Initiator sends out the usual Down/Init/Up as per RFC5880 >> * Reflector simply copies the state into the reply packet >> (or overwrites the state field with AdminDown) >>=20 >> Play it through - it works ;-) More important there is a subtle differe= nce >> of simply going to "Up" state when receiving "Up" packets and filling th= e >> packet path with Down, then Init, then Up. >=20 > If we strictly look at this from the protocol perspective, there is no ne= ed=20 > for the initiator to have INIT state (it doesn't even make sense to have= =20 > one). ADMINDOWN might still be useful to have, to allow the initiator=20 > session to be enabled/disabled. Thu I think it's correct for the new FSM = to=20 > be available for this. We may need to add ADMINDOWN back in though ...=20 > thoughts? >=20 > Now, if we apply the new FSM to existing implementation, I suppose RFC588= 0=20 > FSM can be re-used, as long as the implementation properly transitions=20 > *through* INIT state. But I see this as an implementation detail, and=20 > should be left out from the document. >=20 >>=20 >>=20 >> (3) Nitpick: section 9.1.1 says "The notation on each arc represents the >> state of the remote system" - there is no state of the remote system, th= e >> reflector is stateless ;-) >=20 > Good catch. Agree that sentence should be rewritten to remove "state of t= he=20 > remote system" out. >=20 >>=20 >>=20 >> (4) Section 11 "Scaling Aspects". The "total number of BFD sessions in a >> network" - why would this be a relevant number? This is not RSVP-based T= E >> tunnels where some core nodes may indeed come close to the N * (N - 1) >> number >> of RSVP tunnel state for an any-any mesh. But a BFD session is just a bi= t=20 >> of >> traffic in the forwarding plane for most routers, only sender/receiver= =20 >> take a >> hit. >> True, there is still the factor of about "2" per single router. I would >> propose keeping the first paragraph of 11 but remove the rest. >=20 > You are right, everything below the first paragraph is just a bit noisy.= =20 > Yes I agree that we should only keep the first paragraph of section 11=20 > (i.e. remove the rest). >=20 > -Nobo >=20 >>=20 >>=20 >> Have to re-read your draft for the other parts, especially the D-bit ;-) >>=20 >>=20 >> Regards, Marc >>=20 >>=20 >>=20 >> On Thu, 17 Apr 2014 12:50:12 +0000, MALLIK MUDIGONDA (mmudigon) >> wrote: >>> Hello BFD WG Members, >>>=20 >>> We have published a new version of Seamless BFD draft, >>> draft-akiya-bfd-seamless-base-03. Several sections have been updated fo= r >>> improving readability. It also has a few technical changes as well. Ple= ase >>> review the draft and get back to us with your comments. >>>=20 >>> Thanks >>>=20 >>> Regards >>> Mallik >=20 From nobody Wed May 7 22:23:28 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654731A0236 for ; Wed, 7 May 2014 22:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM2WeS7Pwtcd for ; Wed, 7 May 2014 22:23:24 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id B16B31A0224 for ; Wed, 7 May 2014 22:23:24 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s485NJ0w011278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 8 May 2014 00:23:20 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s485NJhQ009642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 8 May 2014 01:23:19 -0400 Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 8 May 2014 01:23:19 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.212]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Thu, 8 May 2014 13:23:16 +0800 From: "Bhatia, Manav (Manav)" To: "rtg-bfd@ietf.org" Subject: FW: New Version Notification for draft-bhatia-ospf-sbfd-discriminator-00.txt Thread-Topic: New Version Notification for draft-bhatia-ospf-sbfd-discriminator-00.txt Thread-Index: AQHPan0m4AxUBVsCPECyOD7ltRkXOJs2I7CA Date: Thu, 8 May 2014 05:23:15 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E601FFE@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/_uvTCRHF7ASu1Uze8_vsq0fPohs X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 May 2014 05:23:26 -0000 SGksDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgZHJhZnQgdGhhdCB1c2VzIE9TUEYgdG8gZGlzdHJp YnV0ZSBTLUJGRCBkaXNjcmltaW5hdG9ycyBmb3IgdGhlIGNsaWVudHMgdG8gdXNlLg0KDQpQbGVh c2UgcmV2aWV3IGFuZCBwcm92aWRlIGNvbW1lbnRzIG9uIHRoZSBkcmFmdC4NCg0KQ2hlZXJzLCBN YW5hdg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFRodXJz ZGF5LCBNYXkgMDgsIDIwMTQgMTA6NTAgQU0NClRvOiBTYW0gQWxkcmluOyBDYXJsb3MgUGlnbmF0 YXJvOyBCaGF0aWEsIE1hbmF2IChNYW5hdik7IENhcmxvcyBQaWduYXRhcm87IFJhbmdhbmF0aGEs IFRyaWxvayAoVHJpbG9rKTsgU2FtIEFsZHJpbjsgUmFuZ2FuYXRoYSwgVHJpbG9rIChUcmlsb2sp OyBCaGF0aWEsIE1hbmF2IChNYW5hdikNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtYmhhdGlhLW9zcGYtc2JmZC1kaXNjcmltaW5hdG9yLTAwLnR4dA0KDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1iaGF0aWEtb3NwZi1zYmZkLWRpc2NyaW1pbmF0b3It MDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1hbmF2IEJoYXRpYSBh bmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtYmhhdGlh LW9zcGYtc2JmZC1kaXNjcmltaW5hdG9yDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJT1NQRiBleHRl bnNpb25zIHRvIGFkdmVydGlzZSBTLUJGRCBUYXJnZXQgRGlzY3JpbWluYXRvcg0KRG9jdW1lbnQg ZGF0ZToJMjAxNC0wNS0wOA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJ Ng0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWJoYXRpYS1vc3BmLXNiZmQtZGlzY3JpbWluYXRvci0wMC50eHQNClN0YXR1czogICAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iaGF0aWEtb3NwZi1zYmZk LWRpc2NyaW1pbmF0b3IvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYmhhdGlhLW9zcGYtc2JmZC1kaXNjcmltaW5hdG9yLTAwDQoNCg0KQWJzdHJhY3Q6 DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgT1NQRiBSb3V0ZXIgSW5mb3JtYXRpb24g KFJJKSBUTFYgdGhhdA0KICAgYWxsb3dzIE9TUEYgcm91dGVycyB0byBmbG9vZCB0aGUgUy1CRkQg ZGlzY3JpbWluYXRvciB2YWx1ZXMNCiAgIGFzc29jaWF0ZWQgd2l0aCBhIHRhcmdldCBuZXR3b3Jr IGlkZW50aWZpZXIuICBUaGlzIG1lY2hhbmlzbSBpcw0KICAgYXBwbGljYWJsZSB0byBib3RoIE9T UEZ2MiBhbmQgT1NQRnYzLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu May 8 07:49:06 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79591A0071; Thu, 8 May 2014 07:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9T8y0xZd6LB; Thu, 8 May 2014 07:49:00 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 6036A1A006A; Thu, 8 May 2014 07:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2024; q=dns/txt; s=iport; t=1399560536; x=1400770136; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ttERCvLBkJBQW9LmCO6lx0VS7jBmGMcZXSyoVV8Nstw=; b=UIkzk02tHHLyS+8RBVvcbX0JDAQ0i4HtcyRwWMM/gPwhVgPI7e5psFCr VfaZadUfH5XyK0a9Ea3FD19UsqIdQdNTG7YgzjfiC2qtv+1tOJbTFFBrc AWzO9+8ryPjRprrp+VpzwVNdYfr/appi4jNkkw/mxRJvdtXt09go9PH6M I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAICYa1OtJV2d/2dsb2JhbABZgwZPWIJnwnoBGXoWdIIlAQEBBCMRQw4EAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBAESCAGIOA2rO6RSF4EqjHc4BoJuNoEVBJp0kT+DNm2BQg X-IronPort-AV: E=Sophos;i="4.97,1010,1389744000"; d="scan'208";a="42125819" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP; 08 May 2014 14:48:55 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s48EmtqD023535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 May 2014 14:48:55 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Thu, 8 May 2014 09:48:55 -0500 From: "Les Ginsberg (ginsberg)" To: "isis-wg@ietf.org" , "rtg-bfd@ietf.org" Subject: FW: New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Topic: New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Index: AQHPasw+ft5/3BK2OUCTWOWP0ceEqZs2wwSA Date: Thu, 8 May 2014 14:48:54 +0000 Message-ID: References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> In-Reply-To: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.96.8] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/q-IzSOkFdCHgAJLzTyk45hwmtAM X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 May 2014 14:49:02 -0000 RllJIC0gdGhpcyBuZXcgZHJhZnQgZGVzY3JpYmVzIGhvdyB0byBhZHZlcnRpc2UgUy1CRkQgRGlz Y3JpbWluYXRvcnMgdXNpbmcgSVMtSVMuDQoNCkNvbW1lbnRzIGFyZSB3ZWxjb21lZC4NCg0KICAg IExlcw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVGh1 cnNkYXksIE1heSAwOCwgMjAxNCA3OjQ2IEFNDQpUbzogTWFjaCBDaGVuOyBOb2JvIEFraXlhIChu b2JvKTsgTWFjaCBDaGVuOyBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKTsgTm9ibyBBa2l5YSAobm9i byk7IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWdpbnNiZXJnLWlzaXMtc2JmZC1kaXNjcmltaW5hdG9yLTAwLnR4dA0K DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1naW5zYmVyZy1pc2lzLXNiZmQtZGlzY3Jp bWluYXRvci0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTGVzIEdp bnNiZXJnIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFm dC1naW5zYmVyZy1pc2lzLXNiZmQtZGlzY3JpbWluYXRvcg0KUmV2aXNpb246CTAwDQpUaXRsZToJ CUFkdmVydGlzaW5nIFMtQkZEIERpc2NyaW1pbmF0b3JzIGluIElTLUlTDQpEb2N1bWVudCBkYXRl OgkyMDE0LTA1LTA4DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk1DQpV Ukw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt Z2luc2JlcmctaXNpcy1zYmZkLWRpc2NyaW1pbmF0b3ItMDAudHh0DQpTdGF0dXM6ICAgICAgICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2luc2JlcmctaXNpcy1zYmZk LWRpc2NyaW1pbmF0b3IvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtZ2luc2JlcmctaXNpcy1zYmZkLWRpc2NyaW1pbmF0b3ItMDANCg0KDQpBYnN0cmFj dDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG1lYW5zIG9mIGFkdmVydGlzaW5nIG9uZSBv ciBtb3JlIFMtQkZEDQogICBEaXNjcmltaW5hdG9ycyB1c2luZyB0aGUgSVMtSVMgUm91dGVyIENh cGFiaWxpdHkgVExWLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu May 8 12:25:43 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265ED1A00DD; Thu, 8 May 2014 12:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HqhGXeuGU01; Thu, 8 May 2014 12:25:39 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2498D1A00C3; Thu, 8 May 2014 12:25:39 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8CB47C2A8; Thu, 8 May 2014 15:25:34 -0400 (EDT) Date: Thu, 8 May 2014 15:25:34 -0400 From: Jeffrey Haas To: "Les Ginsberg (ginsberg)" Subject: Re: FW: New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Message-ID: <20140508192534.GA24787@pfrc> References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/FmUlGxtC67CysLIkjFAWhTrtwjg Cc: "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 May 2014 19:25:40 -0000 On Thu, May 08, 2014 at 02:48:54PM +0000, Les Ginsberg (ginsberg) wrote: > FYI - this new draft describes how to advertise S-BFD Discriminators using IS-IS. So, the discriminators are intended to be box-wide? I would have expected from some of the use cases that they'd be bound in some cases to specific interfaces. -- Jeff From nobody Thu May 8 13:10:59 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37ACE1A0067; Thu, 8 May 2014 13:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSGbLkiy1xgV; Thu, 8 May 2014 13:10:53 -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 F04E31A0139; Thu, 8 May 2014 13:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1320; q=dns/txt; s=iport; t=1399579836; x=1400789436; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wUJM1wgz5x5ji16o5Ts1V6ulsjlEyQXtAHE+NqIiFmY=; b=WMOXN/k5Wb8/yaQv+/7Wzwj9KqPaTTkQnsazFd6bbKKohWOMoS1Uo9Y2 7LFBQMYkQ9/DSs0qpsQywwCAgSJr5mxV0est7HBSFjjHmgrhXD9V8y9V4 fE6RmFl2g1IkLkkxpE9Cc2vIWp1GwopQOCLiqiRYdenNqB0rxGu+MxAJ8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAPDja1OtJV2a/2dsb2JhbABZgwaBJ8ViAYEUFnSCJQEBAQQ6PQIMBAIBCA4DBAEBAQoUCQcyFAgBCAIEDgUIiDnQUBeNeyYxBwaDJIEVAQOsM4F3gT+BbkE X-IronPort-AV: E=Sophos;i="4.97,1013,1389744000"; d="scan'208";a="323472554" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 08 May 2014 20:10:36 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s48KAa4c017862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 May 2014 20:10:36 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Thu, 8 May 2014 15:10:35 -0500 From: "Les Ginsberg (ginsberg)" To: Jeffrey Haas Subject: RE: FW: New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Topic: FW: New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Index: AQHPasw+ft5/3BK2OUCTWOWP0ceEqZs2wwSAgAChxQD//7dn8A== Date: Thu, 8 May 2014 20:10:35 +0000 Message-ID: References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <20140508192534.GA24787@pfrc> In-Reply-To: <20140508192534.GA24787@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.163.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2y8tF-vuRX9eoBcO6JCOMQaDHbY Cc: "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 May 2014 20:10:55 -0000 Jeff - How S-BFD Discriminators get used is a subject that no doubt the BFD WG wil= l discuss at length in the near future. However, the additional information= that may be required to differentiate how - when multiple discriminators a= re advertised by a node - each discriminator should be used is out of scope= for the IGP advertisement. This gets into the area of application informat= ion which has to be defined/standardized elsewhere and does not belong in t= he IGP advertisements. So the deliberate intent here as far as the IGP adve= rtisement is to limit it to simply a list of assigned discriminators - noth= ing more. Les > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Thursday, May 08, 2014 12:26 PM > To: Les Ginsberg (ginsberg) > Cc: isis-wg@ietf.org; rtg-bfd@ietf.org > Subject: Re: FW: New Version Notification for draft-ginsberg-isis-sbfd- > discriminator-00.txt >=20 > On Thu, May 08, 2014 at 02:48:54PM +0000, Les Ginsberg (ginsberg) wrote: > > FYI - this new draft describes how to advertise S-BFD Discriminators us= ing > IS-IS. >=20 > So, the discriminators are intended to be box-wide? >=20 > I would have expected from some of the use cases that they'd be bound in > some cases to specific interfaces. >=20 > -- Jeff From nobody Thu May 8 13:26:45 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0831A00D3; Thu, 8 May 2014 13:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qSw_GTKoQiu; Thu, 8 May 2014 13:26:39 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 211131A0095; Thu, 8 May 2014 13:26:39 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id g10so2711287pdj.24 for ; Thu, 08 May 2014 13:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=SxasjPsYxmdpph+d4ZIbSN8OP0+QY4Lz1iTG6Zn6Hc4=; b=0uqK6okOu9SsZCam/ugEjVWEIGI+hUpANukBu8vBFoVUmOMJc6UgOwxAbu7goNShPY dNvcpbeehfgcxkTnE3MgNVl8aD33F44a6Np3/Ma4vTnZQ4rclxt+gpD/1VUu+vq5ah3Z HOxDZQP8Z2gvbVrsMCBvt3SrLpsRx+aa7+tn2Kh/wbWnWMUi9DTnAk2sIQHFNA4g3Tqx FIFrSZd4sRKMkrXil1QA0+65oopXyRAlVkfPxddS0MM2aVxy3HSkNbOfXBO0gOaL4r75 QnBPCRu2DfCVF42Xgdp/XnS7Oh6jMsqeHOsUoqbXHV08dNz6ipI3rtnZTIUZGzXEGcDN aEuQ== X-Received: by 10.66.140.104 with SMTP id rf8mr11487183pab.107.1399580794540; Thu, 08 May 2014 13:26:34 -0700 (PDT) Received: from [10.25.35.113] (mobile-166-137-185-110.mycingular.net. [166.137.185.110]) by mx.google.com with ESMTPSA id px10sm8620027pac.41.2014.05.08.13.26.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 May 2014 13:26:33 -0700 (PDT) References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <20140508192534.GA24787@pfrc> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D201) From: Sam Aldrin Subject: Re: [Isis-wg] FW: New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Date: Thu, 8 May 2014 13:26:30 -0700 To: "Les Ginsberg (ginsberg)" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/8wr6YpOriu9FN5UXioRaGbImiT8 Cc: "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 May 2014 20:26:40 -0000 Hi Jeff, We have had very lengthy discussions on this. As Les said, we could discuss a= s part of BFD effort. In fact I am looking forward to such discussion :D Cheers Sam Sent from my iPhone > On May 8, 2014, at 1:10 PM, "Les Ginsberg (ginsberg)" = wrote: >=20 > Jeff - >=20 > How S-BFD Discriminators get used is a subject that no doubt the BFD WG wi= ll discuss at length in the near future. However, the additional information= that may be required to differentiate how - when multiple discriminators ar= e advertised by a node - each discriminator should be used is out of scope f= or the IGP advertisement. This gets into the area of application information= which has to be defined/standardized elsewhere and does not belong in the I= GP advertisements. So the deliberate intent here as far as the IGP advertise= ment is to limit it to simply a list of assigned discriminators - nothing mo= re. >=20 > Les >=20 >> -----Original Message----- >> From: Jeffrey Haas [mailto:jhaas@pfrc.org] >> Sent: Thursday, May 08, 2014 12:26 PM >> To: Les Ginsberg (ginsberg) >> Cc: isis-wg@ietf.org; rtg-bfd@ietf.org >> Subject: Re: FW: New Version Notification for draft-ginsberg-isis-sbfd- >> discriminator-00.txt >>=20 >>> On Thu, May 08, 2014 at 02:48:54PM +0000, Les Ginsberg (ginsberg) wrote:= >>> FYI - this new draft describes how to advertise S-BFD Discriminators usi= ng >> IS-IS. >>=20 >> So, the discriminators are intended to be box-wide? >>=20 >> I would have expected from some of the use cases that they'd be bound in >> some cases to specific interfaces. >>=20 >> -- Jeff >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Thu May 8 13:27:28 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C901A010D; Thu, 8 May 2014 13:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F9idPAmRLEF; Thu, 8 May 2014 13:27:17 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F0B5A1A0067; Thu, 8 May 2014 13:27:16 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 60523C2A8; Thu, 8 May 2014 16:27:12 -0400 (EDT) Date: Thu, 8 May 2014 16:27:12 -0400 From: Jeffrey Haas To: "Les Ginsberg (ginsberg)" Subject: Re: FW: New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Message-ID: <20140508202712.GF3935@pfrc> References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <20140508192534.GA24787@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/N-K6PtdfHQhEMhm1tlLCAuZeDm0 Cc: "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 May 2014 20:27:25 -0000 Les, On Thu, May 08, 2014 at 08:10:35PM +0000, Les Ginsberg (ginsberg) wrote: > How S-BFD Discriminators get used is a subject that no doubt the BFD WG > will discuss at length in the near future. However, the additional > information that may be required to differentiate how - when multiple > discriminators are advertised by a node - each discriminator should be > used is out of scope for the IGP advertisement. This gets into the area of > application information which has to be defined/standardized elsewhere and > does not belong in the IGP advertisements. So the deliberate intent here > as far as the IGP advertisement is to limit it to simply a list of > assigned discriminators - nothing more. I don't buy the argument, even though the underlying reasoning may not be your responsibility. :-) IGPs distribute node and link reachability. The underlying mechanism that is being used isn't even binding the information so much to the node as it is to protocol plumbing. If the feature is intended to be node-addressable or potentially link-addressable is very much relevant to how the feature is developed and used. If we're not to the point of answering those two very basic questions, then the IGP drafts are premature. And almost certainly, squatting on a code point even tentatively is premature. I strongly suggest moving it to TBD in the next version of the draft. That said, I suspect the use cases will shake out very shortly and hopefully the point will be moot in -01. -- Jeff From nobody Thu May 8 13:28:21 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E7E1A0139; Thu, 8 May 2014 13:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uxo2KvcvcjMb; Thu, 8 May 2014 13:28:18 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4407A1A0135; Thu, 8 May 2014 13:28:17 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C14EBC2A8; Thu, 8 May 2014 16:28:12 -0400 (EDT) Date: Thu, 8 May 2014 16:28:12 -0400 From: Jeffrey Haas To: Sam Aldrin Subject: Re: [Isis-wg] FW: New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Message-ID: <20140508202812.GG3935@pfrc> References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <20140508192534.GA24787@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/VYo7PXtAkH8pgNFMcnGTmcTqqSU Cc: "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 May 2014 20:28:19 -0000 Sam, On Thu, May 08, 2014 at 01:26:30PM -0700, Sam Aldrin wrote: > We have had very lengthy discussions on this. As Les said, we could discuss as part of BFD effort. In fact I am looking forward to such discussion :D Fire away. The re-chartering for S-BFD is in progress and the whole purpose was to help move such discussion into the daylight of the working group. -- Jeff From nobody Thu May 8 13:40:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E38D1A0095; Thu, 8 May 2014 13:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrwJigJFKgJL; Thu, 8 May 2014 13:40:45 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 027C91A0067; Thu, 8 May 2014 13:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3398; q=dns/txt; s=iport; t=1399581640; x=1400791240; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wlRPM7y+WowjN6UMUejYOpaU4xbJrGE/cMhIk7Ij2tM=; b=f3cIfab2yh5NTt2BEu/6oN6dnDf/GcQg90XFvf5mdP8cbgy5nhZ7jGF5 +sGbqFFjcG/41OR0n5nEj0Ncbvv6+wnV0th+Gefq9myEmExnLmcRBFXt+ ZgMdD/PDXO0qOb84zNrPUNYeeBT8W8xIMZqCzyHXxREgDy02Yf6/THs90 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAHHra1OtJA2N/2dsb2JhbABZgwaBJ8ViAYEUFnSCJQEBAQQ6PQIMBAIBCA4DBAEBAQoUCQcyFAgBCAIEDgUIiDnQXheNeyYxBwaDJIEVAQOsM4F3gT+BbkE X-IronPort-AV: E=Sophos;i="4.97,1013,1389744000"; d="scan'208";a="323473381" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP; 08 May 2014 20:40:23 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s48KeMh6030031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 May 2014 20:40:22 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Thu, 8 May 2014 15:40:22 -0500 From: "Les Ginsberg (ginsberg)" To: Jeffrey Haas Subject: RE: FW: New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Topic: FW: New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Index: AQHPasw+ft5/3BK2OUCTWOWP0ceEqZs2wwSAgAChxQD//7dn8IAAWdIA//+seMA= Date: Thu, 8 May 2014 20:40:22 +0000 Message-ID: References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <20140508192534.GA24787@pfrc> <20140508202712.GF3935@pfrc> In-Reply-To: <20140508202712.GF3935@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.163.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/uEw54XwaKsOcI3UE_9TZXP-rhTo Cc: "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 May 2014 20:40:47 -0000 Jeff - The issue of IGPs advertising application information has been much discuss= ed over the last few years. Using IGP flooding for distributing application= info is "appealing" because IGP flooding has been proven to be both effici= ent and reliable. But it compromises the basic function of the protocol by = overloading the link state database with "non-routing information". In the case of IS-IS, the means to support using the IGP to advertise appli= cation info was addressed via GENINFO (RFC 6823) and MI (RFC 6822). So if S= -BFD use cases ever evolve into something complex enough to require a full = fledged set of application specific info and you think IGP flooding is your= best vehicle for advertising you can then follow the guidelines defined in= those two RFCs - which will include writing an S-BFD application RFC, obta= ining an application ID codepoint from IANA, and using a separate instance = of the protocol to advertise whatever you want.=20 For the base protocols, all we intend to support is advertisement of the as= signed discrominators - nothing more. This is sufficient to support use cas= es that the IGPs themselves may find valuable - but is certainly not suffic= ient to support other possible use cases - nor is it intended to be. If your argument is that the advertisement MUST support all possible S-BFD = use cases then we should simply not do this at all in the IGPs. Les > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Thursday, May 08, 2014 1:27 PM > To: Les Ginsberg (ginsberg) > Cc: Jeffrey Haas; isis-wg@ietf.org; rtg-bfd@ietf.org > Subject: Re: FW: New Version Notification for draft-ginsberg-isis-sbfd- > discriminator-00.txt >=20 > Les, >=20 > On Thu, May 08, 2014 at 08:10:35PM +0000, Les Ginsberg (ginsberg) wrote: > > How S-BFD Discriminators get used is a subject that no doubt the BFD WG > > will discuss at length in the near future. However, the additional > > information that may be required to differentiate how - when multiple > > discriminators are advertised by a node - each discriminator should be > > used is out of scope for the IGP advertisement. This gets into the area= of > > application information which has to be defined/standardized elsewhere > and > > does not belong in the IGP advertisements. So the deliberate intent her= e > > as far as the IGP advertisement is to limit it to simply a list of > > assigned discriminators - nothing more. >=20 > I don't buy the argument, even though the underlying reasoning may not be > your responsibility. :-) >=20 > IGPs distribute node and link reachability. The underlying mechanism tha= t > is being used isn't even binding the information so much to the node as i= t > is to protocol plumbing. >=20 > If the feature is intended to be node-addressable or potentially > link-addressable is very much relevant to how the feature is developed an= d > used. If we're not to the point of answering those two very basic > questions, then the IGP drafts are premature. And almost certainly, > squatting on a code point even tentatively is premature. I strongly sugg= est > moving it to TBD in the next version of the draft. >=20 > That said, I suspect the use cases will shake out very shortly and hopefu= lly > the point will be moot in -01. >=20 > -- Jeff From nobody Thu May 8 16:27:54 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A551A019D; Thu, 8 May 2014 16:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTCbh4NVRc86; Thu, 8 May 2014 16:27:50 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED4D1A01AA; Thu, 8 May 2014 16:27:50 -0700 (PDT) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s48NRenS027927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 May 2014 19:27:41 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s48NRenS027927 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1399591661; bh=T5ucse/n7k6dDg8syZ9vw2yBw9E=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=hH1A1KYoF7F9SFuHTWuhez7wFXFs4lpzvPCPB4h/d7ZCwwnwL4IB2TTKkougsd0bJ K4OvZDeU6a5F6bGTK5YzrNt0WlHpMh0Bc9bgIA6Zr27AwiAAmZZVwhUwLCLSAPnX0B 2PJSO+WRDCWRICeQFFi4D+WqBep4G/rl7tF0mWH0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s48NRenS027927 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd56.lss.emc.com (RSA Interceptor); Thu, 8 May 2014 19:27:26 -0400 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s48NRPuZ014550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 May 2014 19:27:25 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Thu, 8 May 2014 19:27:24 -0400 From: "Black, David" To: "tnadeau@lucidvision.com" , "zali@cisco.com" , "nobo@cisco.com" , "General Area Review Team (gen-art@ietf.org)" Date: Thu, 8 May 2014 19:27:22 -0400 Subject: Gen-ART review of draft-ietf-bfd-mib-19 Thread-Topic: Gen-ART review of draft-ietf-bfd-mib-19 Thread-Index: Ac9rFRAh6CyzL/x0TJK0L4NYxtDalw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C55B006@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/SAbeUZKnvpPbm-Ol7e1viYDE_y0 Cc: "rtg-bfd@ietf.org" , "ietf@ietf.org" , "Black, David" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 08 May 2014 23:27:53 -0000 Additional text has been added to the -19 version to address this remaining topic. The -19 version is Ready. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Monday, April 28, 2014 10:20 AM > To: tnadeau@lucidvision.com; zali@cisco.com; nobo@cisco.com; General Area > Review Team (gen-art@ietf.org) > Cc: rtg-bfd@ietf.org; ietf@ietf.org; Black, David > Subject: RE: Gen-ART review of draft-ietf-bfd-mib-18 >=20 > The -18 version of this draft responds to all of the comments in the > Gen-ART review of -17, including the request for coordination w/the > OPS area, although I wasn't exactly expecting that to occur on the > main IETF list. >=20 > The -18 version is ready with one small nit - The following text has > been added to the introduction: >=20 > This memo does not define a compliance requirement for a system that > only implements BFD version 0. This is a reflection of a considered > and deliberate decision by the BFD WG. >=20 > An explanation of the rationale for that decision would help - I suggest > adding the following text and a suitable reference to the end of the text > above: >=20 > because the BFD version 0 protocol may deadlock and hence SHOULD NOT > be used, as explained further in [RFCxxxx]. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Black, David > > Sent: Wednesday, April 16, 2014 7:31 PM > > To: tnadeau@lucidvision.com; zali@cisco.com; nobo@cisco.com; General Ar= ea > > Review Team (gen-art@ietf.org) > > Cc: rtg-bfd@ietf.org; ietf@ietf.org; Black, David > > Subject: Gen-ART review of draft-ietf-bfd-mib-17 > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at > > > > . > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > Document: draft-ietf-bfd-mib-17 > > Reviewer: David L. Black > > Review Date: April 16, 2014 > > IETF LC End Date: April 28, 2014 > > > > Summary: This draft is on the right track, but has open issues > > described in the review. > > > > This draft is a MIB module for the BFD protocol, which is an important = low- > > level routing protocol. The draft is reasonable for a MIB draft; one n= eeds > > to go read the protocol documents to understand how the protocol works,= and > > significant portions of the text are derived from the usual MIB > "boilerplate" > > as one would expect. The "Brief Description of MIB Objects" is indeed > > brief, but reasonable. The shepherd writeup indicates that there are > > multiple implementations. > > > > Major issues: > > > > This MIB contains many writable objects, so the authors should > > take note of the IESG statement on writable MIB modules: > > > > http://www.ietf.org/iesg/statement/writable-mib-module.html > > > > I did not see this mentioned in the shepherd writeup. If the OPS Area > > has not been consulted, I strongly suggest doing so during IETF Last > > Call, e.g., starting with Benoit Claise (AD). > > > > Minor issues: > > > > The security considerations section includes considerations for > > unauthorized modification of bfdSessAdminStatus and bfdSessOperStatus, > > but omits the corresponding considerations for bfdAdminStatus and > > bfdSessNotificationsEnable. Both of the latter objects are global, > > so significant damage can be inflicted via these objects with a > > small number of unauthorized modifications, so they need to be > > included in the first list of sensitive objects. > > > > I suggest that the authors recheck the entire MIB to ensure that > > every object or table that should be included in the security > > considerations section is appropriately included. > > > > Also, as a General Variable, would bfdSessNotificationsEnable be better > > named bfdNotificationsEnable, as it's not in the BFD Session Table? > > > > I did not see a compliance requirement for a system that only > > implements BFD protocol version 0. That absence should at least be > > mentioned somewhere. For example, if this reflects a considered and > > deliberate decision by the WG, that should be mentioned in the > > introduction. > > > > Nits/editorial comments: > > > > In the security considerations for authentication-related objects: > > > > OLD > > In order for these sensitive information > > from being improperly accessed, implementers MAY wish to disallow > > access to these objects. > > NEW > > In order to prevent this sensitive information > > from being improperly accessed, implementers MAY disallow > > access to these objects. > > > > idnits 2.13.01 found a truly minor nit that should be corrected when > > the draft is next revised: > > > > =3D=3D Outdated reference: A later version (-05) exists of > > draft-ietf-bfd-tc-mib-04 > > > > it also generated a warning that probably does not reflect an actual > problem: > > > > -- The document seems to lack a disclaimer for pre-RFC5378 work, but = may > > have content which was first submitted before 10 November 2008. I= f you > > have contacted all the original authors and they are all willing t= o > grant > > the BCP78 rights to the IETF Trust, then this is fine, and you can > ignore > > this comment. If not, you may need to add the pre-RFC5378 disclai= mer. > > (See the Legal Provisions document at > > http://trustee.ietf.org/license-info for more information.) > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293= -7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- From nobody Fri May 9 01:02:28 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00B91A0208 for ; Fri, 9 May 2014 01:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB1s3HA0n3Ja for ; Fri, 9 May 2014 01:02:25 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7774F1A0206 for ; Fri, 9 May 2014 01:02:25 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id wp18so4444847obc.31 for ; Fri, 09 May 2014 01:02:20 -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=jmOp5AzRcoJsRxsIi30oH313F+GFOgIl0P++Fjy2ZA0=; b=rOb5j0G5DqKqNbTfkqSJSoYeumHYoQ1ibm4TMiSi5+D7Uoca0SbrhAFlqbM1JMp9yC zjajHx4XUGp3vxO731ZeGaJF2dWRr/kzppjjBEu2Kmajjqsd4NrfLItVNK1LxXmvK18d 6SdzVbgzM2rbtKwLultiZ8aNy8ZYm1QwpCv89P+8FCPkPmRyhIuxTkica7suHdjzXSRG 945OKViDnLcvmmSQLIxCAYAzFUNJ+xjKlqggSmneG9zK5EJFm6EVqT2gl8xRRX8cXIse 2PHLDj2yBAQ+Dbk0AiMF5cJXJI3vf+AUzT1nu7WpeasxlqpmVr6k9ScIEP/8yDLn0NKb dH1A== MIME-Version: 1.0 X-Received: by 10.60.51.39 with SMTP id h7mr11099156oeo.52.1399622540727; Fri, 09 May 2014 01:02:20 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Fri, 9 May 2014 01:02:20 -0700 (PDT) Date: Fri, 9 May 2014 13:32:20 +0530 Message-ID: Subject: Problem with BFD with ECMP From: Manav Bhatia To: "rtg-bfd@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/FGIlPQLprYgP5SGc0LWQ9pQDOZ0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 08:02:27 -0000 Hi, There is a problem with how BFD/S-BFD works. Sec 3.2 draft-aldrin-bfd-seamless-use-case-01 explains how we can use S-BFD to quickly validate the data plane before pushing the data out. There is a potential issue here. Assume I send an S-BFD ping and I get a pong back.I believe that the path is up and i start sending traffic towards the Reflector, brimming with confidence, since i believe the data plane is up. Assume that there is ECMP happening in the network somewhere that splits the traffic to paths p1 and p2. Its possible that the S-BFD packet gets hashed to the path p1, while the data traffic that i send gets hashed to path p2. If path p2 is down (or is congested and drops packets), then i drop all traffic -- or some, in case of congestion. This however is unexpected since i always get 100% response for my S-BFD ping packets. I understand that if path p2 is down (because of an issue in one of the nodes/links in the path), the ECMP path will not contain p2, since the routing protocols will naturally remove this from the ECMP list. So, its only while the network is reconverging (which should only last for a few secs) that we will see this. Is my understanding correct? If yes, then is the scenario where S-BFD and data traffic following different paths something that we want to look at fixing (either here or some other WG)? This problem has already been solved in the MPLS context with the Entropy label. I am talking specifically about non-MPLS networks. Cheers, Manav From nobody Fri May 9 01:45:36 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809301A018C for ; Fri, 9 May 2014 01:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ul_X5-clx_3R for ; Fri, 9 May 2014 01:45:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 44DBB1A0041 for ; Fri, 9 May 2014 01:45:33 -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.7-GA FastPath queued) with ESMTP id BDZ05307; Fri, 09 May 2014 08:45:27 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 9 May 2014 09:44:01 +0100 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 9 May 2014 09:45:24 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.13]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Fri, 9 May 2014 16:45:20 +0800 From: Mach Chen To: Manav Bhatia , "rtg-bfd@ietf.org" Subject: RE: Problem with BFD with ECMP Thread-Topic: Problem with BFD with ECMP Thread-Index: AQHPa10IhjVo3W+OVkS1+tg2JllM3Js37L9w Date: Fri, 9 May 2014 08:45:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/0cwsH4qvjpsMd8o8evE2bhEu8-o X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 08:45:35 -0000 SGkgTWFuYXYsDQoNClRoZSBpc3N1ZSB5b3UgcmFpc2VkIGlzIHZhbGlkLCBidXQgdGhpcyBpc3N1 ZSBzaG91bGQgbm90IGJlIHNwZWNpZmljIHRvIFMtQkZEIG9ubHksIGl0J3MgYSBjb21tb24gaXNz dWUuIA0KDQpBbmQgSU1ITywgaW4gdGhlIHB1cmUgSVAgc2NlbmFyaW8sIHNpbmNlIHRoZSBoYXNo IGlzIG5vcm1hbGx5IGJhc2VkIG9uIHRoZSBmb3VyL2ZpdmUtdHVwbGUsIGlmIEJGRCBhbmQgdGhl IGRhdGEgaGF2ZSB0aGUgc2FtZSBJUCBoZWFkZXIsIHRoZSBoYXNoIHJlc3VsdCBzaG91bGQgYmUg dGhlIHNhbWUuIFVubGVzcyB5b3UgdXNlIHMtYmZkIHRvIGRldGVjdCBhIHNlZ21lbnQgb2YgdGhl IHBhdGgsIG1lYW5zIHRoZSBkZXN0aW5hdGlvbiBvZiB0aGUgUy1CRkQgd2lsbCBiZSBkaWZmZXJl bnQgZnJvbSB0aGUgdXNlciBkYXRhLiBUaGVuIHlvdSBkZXNjcmliZWQgc2l0dWF0aW9uIHdpbGwg aGFwcGVuLg0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE1hbmF2IEJoYXRpYQ0KPiBTZW50OiBGcmlkYXksIE1heSAwOSwgMjAxNCA0 OjAyIFBNDQo+IFRvOiBydGctYmZkQGlldGYub3JnDQo+IFN1YmplY3Q6IFByb2JsZW0gd2l0aCBC RkQgd2l0aCBFQ01QDQo+IA0KPiBIaSwNCj4gDQo+IFRoZXJlIGlzIGEgcHJvYmxlbSB3aXRoIGhv dyBCRkQvUy1CRkQgd29ya3MuDQo+IA0KPiBTZWMgMy4yIGRyYWZ0LWFsZHJpbi1iZmQtc2VhbWxl c3MtdXNlLWNhc2UtMDEgZXhwbGFpbnMgaG93IHdlIGNhbiB1c2UgUy1CRkQgdG8NCj4gcXVpY2ts eSB2YWxpZGF0ZSB0aGUgZGF0YSBwbGFuZSBiZWZvcmUgcHVzaGluZyB0aGUgZGF0YSBvdXQuDQo+ IA0KPiBUaGVyZSBpcyBhIHBvdGVudGlhbCBpc3N1ZSBoZXJlLg0KPiANCj4gQXNzdW1lIEkgc2Vu ZCBhbiBTLUJGRCBwaW5nIGFuZCBJIGdldCBhIHBvbmcgYmFjay5JIGJlbGlldmUgdGhhdCB0aGUg cGF0aCBpcyB1cA0KPiBhbmQgaSBzdGFydCBzZW5kaW5nIHRyYWZmaWMgdG93YXJkcyB0aGUgUmVm bGVjdG9yLCBicmltbWluZyB3aXRoIGNvbmZpZGVuY2UsIHNpbmNlIGkNCj4gYmVsaWV2ZSB0aGUg ZGF0YSBwbGFuZSBpcyB1cC4NCj4gDQo+IEFzc3VtZSB0aGF0IHRoZXJlIGlzIEVDTVAgaGFwcGVu aW5nIGluIHRoZSBuZXR3b3JrIHNvbWV3aGVyZSB0aGF0IHNwbGl0cyB0aGUNCj4gdHJhZmZpYyB0 byBwYXRocyBwMSBhbmQgcDIuDQo+IA0KPiBJdHMgcG9zc2libGUgdGhhdCB0aGUgUy1CRkQgcGFj a2V0IGdldHMgaGFzaGVkIHRvIHRoZSBwYXRoIHAxLCB3aGlsZSB0aGUgZGF0YQ0KPiB0cmFmZmlj IHRoYXQgaSBzZW5kIGdldHMgaGFzaGVkIHRvIHBhdGggcDIuDQo+IA0KPiBJZiBwYXRoIHAyIGlz IGRvd24gKG9yIGlzIGNvbmdlc3RlZCBhbmQgZHJvcHMgcGFja2V0cyksIHRoZW4gaSBkcm9wIGFs bCB0cmFmZmljIC0tIG9yDQo+IHNvbWUsIGluIGNhc2Ugb2YgY29uZ2VzdGlvbi4gVGhpcyBob3dl dmVyIGlzIHVuZXhwZWN0ZWQgc2luY2UgaSBhbHdheXMgZ2V0IDEwMCUNCj4gcmVzcG9uc2UgZm9y IG15IFMtQkZEIHBpbmcgcGFja2V0cy4NCj4gDQo+IEkgdW5kZXJzdGFuZCB0aGF0IGlmIHBhdGgg cDIgaXMgZG93biAoYmVjYXVzZSBvZiBhbiBpc3N1ZSBpbiBvbmUgb2YgdGhlDQo+IG5vZGVzL2xp bmtzIGluIHRoZSBwYXRoKSwgdGhlIEVDTVAgcGF0aCB3aWxsIG5vdCBjb250YWluIHAyLCBzaW5j ZSB0aGUgcm91dGluZw0KPiBwcm90b2NvbHMgd2lsbCBuYXR1cmFsbHkgcmVtb3ZlIHRoaXMgZnJv bSB0aGUgRUNNUCBsaXN0Lg0KPiBTbywgaXRzIG9ubHkgd2hpbGUgdGhlIG5ldHdvcmsgaXMgcmVj b252ZXJnaW5nICh3aGljaCBzaG91bGQgb25seSBsYXN0IGZvciBhIGZldw0KPiBzZWNzKSB0aGF0 IHdlIHdpbGwgc2VlIHRoaXMuDQo+IA0KPiBJcyBteSB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/DQo+ IA0KPiBJZiB5ZXMsIHRoZW4gaXMgdGhlIHNjZW5hcmlvIHdoZXJlIFMtQkZEIGFuZCBkYXRhIHRy YWZmaWMgZm9sbG93aW5nIGRpZmZlcmVudCBwYXRocw0KPiBzb21ldGhpbmcgdGhhdCB3ZSB3YW50 IHRvIGxvb2sgYXQgZml4aW5nIChlaXRoZXIgaGVyZSBvciBzb21lIG90aGVyIFdHKT8gVGhpcw0K PiBwcm9ibGVtIGhhcyBhbHJlYWR5IGJlZW4gc29sdmVkIGluIHRoZSBNUExTIGNvbnRleHQgd2l0 aCB0aGUgRW50cm9weSBsYWJlbC4gSQ0KPiBhbSB0YWxraW5nIHNwZWNpZmljYWxseSBhYm91dCBu b24tTVBMUyBuZXR3b3Jrcy4NCj4gDQo+IENoZWVycywgTWFuYXYNCg0K From nobody Fri May 9 01:58:28 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0211A0041 for ; Fri, 9 May 2014 01:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mf-gE7C2-4Ch for ; Fri, 9 May 2014 01:58:23 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 25FBC1A0238 for ; Fri, 9 May 2014 01:58:23 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id wm4so4352239obc.26 for ; Fri, 09 May 2014 01:58:18 -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=v7hnYIE12NP0PyWixl9TCdfSPM/qH7qluxHX9HS8+tY=; b=R5WZ6gs82fgXrQLOAl3NgKl4xPjzQ6EXOFUTOiOvqGkkbbS2VhtqZwbyvsZb+mccNP Fe5VuicGYACT7KcHMXNBLYWctU7ORgJt8mQxBQSXw2ghnafhDC70r8evWi+d7gtgYMeF WV+nxi4xF3eXqQYm863y9jxsYMc4yABsaB/ITnRXtsnUItrZX0IFdF7Bn9hnQe3XmE9e zgSDce5l7V9lutkG0XsKbqmpLTAeeZxa/IVYnOhAP+s+Z81KjLqLH+pYREYpIy6EaBb8 +oT3UliOT66NzI2LIHrbqrkVJROQaVEofkDubPIVc0KPgDUH4JwSE++0/zNXE5MZCqvF bkDA== MIME-Version: 1.0 X-Received: by 10.60.51.39 with SMTP id h7mr11452221oeo.52.1399625898278; Fri, 09 May 2014 01:58:18 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Fri, 9 May 2014 01:58:18 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 May 2014 14:28:18 +0530 Message-ID: Subject: Re: Problem with BFD with ECMP From: Manav Bhatia To: Mach Chen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/R8KFX9sxh7fyzDV1ZTnltCbBS1o Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 08:58:26 -0000 Hi Mac, > The issue you raised is valid, but this issue should not be specific to S-BFD only, it's a common issue. Yes. Thats why i said BFD/S-BFD. I just took S-BFD as an example, since thats what i was looking at. > > And IMHO, in the pure IP scenario, since the hash is normally > based on the four/five-tuple, if BFD and the data have the same IP > header, the hash result should be the same. Unless you use s-bfd to No, thats the point. The hash with 5 tuple will be different since S-BFD headers will have a different protocol number, source port number and destination port number than the data traffic thats we're sending. Since these fields are different the hash may or may not be the same as that of the BFD/S-BFD packet. My point is this: How do i ensure that in an IP only network, my data traffic always follows the same path as the OAM packet that i had sent to verify the data plane? Will it work if i encapsulate both the OAM and the data traffic inside a GRE tunnel so that both use the same hashing fields? I may want to do this for certain flows where i want a very deterministic behavior. Cheers, Manav > detect a segment of the path, means the destination of the S-BFD will > be different from the user data. Then you described situation will happen. > > Best regards, > Mach > >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Manav Bhatia >> Sent: Friday, May 09, 2014 4:02 PM >> To: rtg-bfd@ietf.org >> Subject: Problem with BFD with ECMP >> >> Hi, >> >> There is a problem with how BFD/S-BFD works. >> >> Sec 3.2 draft-aldrin-bfd-seamless-use-case-01 explains how we can use S-BFD to >> quickly validate the data plane before pushing the data out. >> >> There is a potential issue here. >> >> Assume I send an S-BFD ping and I get a pong back.I believe that the path is up >> and i start sending traffic towards the Reflector, brimming with confidence, since i >> believe the data plane is up. >> >> Assume that there is ECMP happening in the network somewhere that splits the >> traffic to paths p1 and p2. >> >> Its possible that the S-BFD packet gets hashed to the path p1, while the data >> traffic that i send gets hashed to path p2. >> >> If path p2 is down (or is congested and drops packets), then i drop all traffic -- or >> some, in case of congestion. This however is unexpected since i always get 100% >> response for my S-BFD ping packets. >> >> I understand that if path p2 is down (because of an issue in one of the >> nodes/links in the path), the ECMP path will not contain p2, since the routing >> protocols will naturally remove this from the ECMP list. >> So, its only while the network is reconverging (which should only last for a few >> secs) that we will see this. >> >> Is my understanding correct? >> >> If yes, then is the scenario where S-BFD and data traffic following different paths >> something that we want to look at fixing (either here or some other WG)? This >> problem has already been solved in the MPLS context with the Entropy label. I >> am talking specifically about non-MPLS networks. >> >> Cheers, Manav > From nobody Fri May 9 03:00:57 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DDA1A023F for ; Fri, 9 May 2014 03:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwxQpMVqop7f for ; Fri, 9 May 2014 03:00:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7B11A0238 for ; Fri, 9 May 2014 03:00:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGO29022; Fri, 09 May 2014 10:00:49 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 9 May 2014 10:59:05 +0100 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 9 May 2014 11:00:47 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.13]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Fri, 9 May 2014 18:00:42 +0800 From: Mach Chen To: Manav Bhatia Subject: RE: Problem with BFD with ECMP Thread-Topic: Problem with BFD with ECMP Thread-Index: AQHPa10IhjVo3W+OVkS1+tg2JllM3Js37L9w//+ADgCAAJX4UA== Date: Fri, 9 May 2014 10:00:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/VofFsFLNiqr2migjjVndHeQLLmI Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 10:00:56 -0000 SGkgTWFuYXYsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFuYXYg QmhhdGlhIFttYWlsdG86bWFuYXZiaGF0aWFAZ21haWwuY29tXQ0KPiBTZW50OiBGcmlkYXksIE1h eSAwOSwgMjAxNCA0OjU4IFBNDQo+IFRvOiBNYWNoIENoZW4NCj4gQ2M6IHJ0Zy1iZmRAaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFByb2JsZW0gd2l0aCBCRkQgd2l0aCBFQ01QDQo+IA0KPiBIaSBN YWMsDQo+IA0KPiA+IFRoZSBpc3N1ZSB5b3UgcmFpc2VkIGlzIHZhbGlkLCBidXQgdGhpcyBpc3N1 ZSBzaG91bGQgbm90IGJlIHNwZWNpZmljIHRvIFMtQkZEIG9ubHksDQo+IGl0J3MgYSBjb21tb24g aXNzdWUuDQo+IA0KPiBZZXMuIFRoYXRzIHdoeSBpIHNhaWQgQkZEL1MtQkZELiBJIGp1c3QgdG9v ayBTLUJGRCBhcyBhbiBleGFtcGxlLCBzaW5jZSB0aGF0cyB3aGF0DQo+IGkgd2FzIGxvb2tpbmcg YXQuDQo+IA0KPiA+DQo+ID4gQW5kIElNSE8sIGluIHRoZSBwdXJlIElQIHNjZW5hcmlvLCBzaW5j ZSB0aGUgaGFzaCBpcyBub3JtYWxseSBiYXNlZCBvbg0KPiA+IHRoZSBmb3VyL2ZpdmUtdHVwbGUs IGlmIEJGRCBhbmQgdGhlIGRhdGEgaGF2ZSB0aGUgc2FtZSBJUCBoZWFkZXIsIHRoZQ0KPiA+IGhh c2ggcmVzdWx0IHNob3VsZCBiZSB0aGUgc2FtZS4gVW5sZXNzIHlvdSB1c2Ugcy1iZmQgdG8NCj4g DQo+IE5vLCB0aGF0cyB0aGUgcG9pbnQuIFRoZSBoYXNoIHdpdGggNSB0dXBsZSB3aWxsIGJlIGRp ZmZlcmVudCBzaW5jZSBTLUJGRCBoZWFkZXJzDQo+IHdpbGwgaGF2ZSBhIGRpZmZlcmVudCBwcm90 b2NvbCBudW1iZXIsIHNvdXJjZSBwb3J0IG51bWJlciBhbmQgZGVzdGluYXRpb24gcG9ydA0KPiBu dW1iZXIgdGhhbiB0aGUgZGF0YSB0cmFmZmljIHRoYXRzIHdlJ3JlIHNlbmRpbmcuIFNpbmNlIHRo ZXNlIGZpZWxkcyBhcmUgZGlmZmVyZW50DQo+IHRoZSBoYXNoIG1heSBvciBtYXkgbm90IGJlIHRo ZSBzYW1lIGFzIHRoYXQgb2YgdGhlIEJGRC9TLUJGRCBwYWNrZXQuDQoNClllcywgaW5kZWVkLg0K DQo+IA0KPiBNeSBwb2ludCBpcyB0aGlzOg0KPiANCj4gSG93IGRvIGkgZW5zdXJlIHRoYXQgaW4g YW4gSVAgb25seSBuZXR3b3JrLCBteSBkYXRhIHRyYWZmaWMgYWx3YXlzIGZvbGxvd3MgdGhlDQo+ IHNhbWUgcGF0aCBhcyB0aGUgT0FNIHBhY2tldCB0aGF0IGkgaGFkIHNlbnQgdG8gdmVyaWZ5IHRo ZSBkYXRhIHBsYW5lPw0KDQpJdCdzIGFsd2F5cyBkZXNpcmVkLCBidXQgaXQncyBoYXJkLCBhbmQg bW9zdCBvZiB0aW1lLCBubyBwZXJmZWN0IHNvbHV0aW9uLiANCg0KPiANCj4gV2lsbCBpdCB3b3Jr IGlmIGkgZW5jYXBzdWxhdGUgYm90aCB0aGUgT0FNIGFuZCB0aGUgZGF0YSB0cmFmZmljIGluc2lk ZSBhIEdSRSB0dW5uZWwNCj4gc28gdGhhdCBib3RoIHVzZSB0aGUgc2FtZSBoYXNoaW5nIGZpZWxk cz8gSSBtYXkgd2FudCB0byBkbyB0aGlzIGZvciBjZXJ0YWluIGZsb3dzDQo+IHdoZXJlIGkgd2Fu dCBhIHZlcnkgZGV0ZXJtaW5pc3RpYyBiZWhhdmlvci4NCg0KWWVzLCB1c2UgYSB0dW5uZWwgdG8g ZW5jYXBzdWxhdGUgYm90aCB0aGUgT0FNIGFuZCB0aGUgZGF0YSB0cmFmZmljIGlzIGEgY2FuZGlk YXRlLiBCdXQgZm9yIGEgZGVwbG95ZWQgbmV0d29yaywgc3VjaCBjaGFuZ2VzIG1heSBub3QgYWNj ZXB0ZWQsIHlvdSBjYW5ub3QgY2hhbmdlIHRoZSBleGlzdGluZyBkZXBsb3ltZW50IG1vZGVsLiAN Cg0KQmVzdCByZWdhcmRzLA0KTWFjaA0KDQo+IA0KPiBDaGVlcnMsIE1hbmF2DQo+IA0KPiA+ICBk ZXRlY3QgYSBzZWdtZW50IG9mIHRoZSBwYXRoLCBtZWFucyB0aGUgZGVzdGluYXRpb24gb2YgdGhl IFMtQkZEIHdpbGwNCj4gPiBiZSBkaWZmZXJlbnQgZnJvbSB0aGUgdXNlciBkYXRhLiBUaGVuIHlv dSBkZXNjcmliZWQgc2l0dWF0aW9uIHdpbGwgaGFwcGVuLg0KPiA+DQo+ID4gQmVzdCByZWdhcmRz LA0KPiA+IE1hY2gNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBG cm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgTWFuYXYNCj4gPj4gQmhhdGlhDQo+ID4+IFNlbnQ6IEZyaWRheSwgTWF5IDA5LCAyMDE0IDQ6 MDIgUE0NCj4gPj4gVG86IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUHJvYmxlbSB3 aXRoIEJGRCB3aXRoIEVDTVANCj4gPj4NCj4gPj4gSGksDQo+ID4+DQo+ID4+IFRoZXJlIGlzIGEg cHJvYmxlbSB3aXRoIGhvdyBCRkQvUy1CRkQgd29ya3MuDQo+ID4+DQo+ID4+IFNlYyAzLjIgZHJh ZnQtYWxkcmluLWJmZC1zZWFtbGVzcy11c2UtY2FzZS0wMSBleHBsYWlucyBob3cgd2UgY2FuIHVz ZQ0KPiA+PiBTLUJGRCB0byBxdWlja2x5IHZhbGlkYXRlIHRoZSBkYXRhIHBsYW5lIGJlZm9yZSBw dXNoaW5nIHRoZSBkYXRhIG91dC4NCj4gPj4NCj4gPj4gVGhlcmUgaXMgYSBwb3RlbnRpYWwgaXNz dWUgaGVyZS4NCj4gPj4NCj4gPj4gQXNzdW1lIEkgc2VuZCBhbiBTLUJGRCBwaW5nIGFuZCBJIGdl dCBhIHBvbmcgYmFjay5JIGJlbGlldmUgdGhhdCB0aGUNCj4gPj4gcGF0aCBpcyB1cCBhbmQgaSBz dGFydCBzZW5kaW5nIHRyYWZmaWMgdG93YXJkcyB0aGUgUmVmbGVjdG9yLA0KPiA+PiBicmltbWlu ZyB3aXRoIGNvbmZpZGVuY2UsIHNpbmNlIGkgYmVsaWV2ZSB0aGUgZGF0YSBwbGFuZSBpcyB1cC4N Cj4gPj4NCj4gPj4gQXNzdW1lIHRoYXQgdGhlcmUgaXMgRUNNUCBoYXBwZW5pbmcgaW4gdGhlIG5l dHdvcmsgc29tZXdoZXJlIHRoYXQNCj4gPj4gc3BsaXRzIHRoZSB0cmFmZmljIHRvIHBhdGhzIHAx IGFuZCBwMi4NCj4gPj4NCj4gPj4gSXRzIHBvc3NpYmxlIHRoYXQgdGhlIFMtQkZEIHBhY2tldCBn ZXRzIGhhc2hlZCB0byB0aGUgcGF0aCBwMSwgd2hpbGUNCj4gPj4gdGhlIGRhdGEgdHJhZmZpYyB0 aGF0IGkgc2VuZCBnZXRzIGhhc2hlZCB0byBwYXRoIHAyLg0KPiA+Pg0KPiA+PiBJZiBwYXRoIHAy IGlzIGRvd24gKG9yIGlzIGNvbmdlc3RlZCBhbmQgZHJvcHMgcGFja2V0cyksIHRoZW4gaSBkcm9w DQo+ID4+IGFsbCB0cmFmZmljIC0tIG9yIHNvbWUsIGluIGNhc2Ugb2YgY29uZ2VzdGlvbi4gVGhp cyBob3dldmVyIGlzDQo+ID4+IHVuZXhwZWN0ZWQgc2luY2UgaSBhbHdheXMgZ2V0IDEwMCUgcmVz cG9uc2UgZm9yIG15IFMtQkZEIHBpbmcgcGFja2V0cy4NCj4gPj4NCj4gPj4gSSB1bmRlcnN0YW5k IHRoYXQgaWYgcGF0aCBwMiBpcyBkb3duIChiZWNhdXNlIG9mIGFuIGlzc3VlIGluIG9uZSBvZg0K PiA+PiB0aGUgbm9kZXMvbGlua3MgaW4gdGhlIHBhdGgpLCB0aGUgRUNNUCBwYXRoIHdpbGwgbm90 IGNvbnRhaW4gcDIsDQo+ID4+IHNpbmNlIHRoZSByb3V0aW5nIHByb3RvY29scyB3aWxsIG5hdHVy YWxseSByZW1vdmUgdGhpcyBmcm9tIHRoZSBFQ01QIGxpc3QuDQo+ID4+IFNvLCBpdHMgb25seSB3 aGlsZSB0aGUgbmV0d29yayBpcyByZWNvbnZlcmdpbmcgKHdoaWNoIHNob3VsZCBvbmx5DQo+ID4+ IGxhc3QgZm9yIGEgZmV3DQo+ID4+IHNlY3MpIHRoYXQgd2Ugd2lsbCBzZWUgdGhpcy4NCj4gPj4N Cj4gPj4gSXMgbXkgdW5kZXJzdGFuZGluZyBjb3JyZWN0Pw0KPiA+Pg0KPiA+PiBJZiB5ZXMsIHRo ZW4gaXMgdGhlIHNjZW5hcmlvIHdoZXJlIFMtQkZEIGFuZCBkYXRhIHRyYWZmaWMgZm9sbG93aW5n DQo+ID4+IGRpZmZlcmVudCBwYXRocyBzb21ldGhpbmcgdGhhdCB3ZSB3YW50IHRvIGxvb2sgYXQg Zml4aW5nIChlaXRoZXIgaGVyZQ0KPiA+PiBvciBzb21lIG90aGVyIFdHKT8gVGhpcyBwcm9ibGVt IGhhcyBhbHJlYWR5IGJlZW4gc29sdmVkIGluIHRoZSBNUExTDQo+ID4+IGNvbnRleHQgd2l0aCB0 aGUgRW50cm9weSBsYWJlbC4gSSBhbSB0YWxraW5nIHNwZWNpZmljYWxseSBhYm91dCBub24tTVBM Uw0KPiBuZXR3b3Jrcy4NCj4gPj4NCj4gPj4gQ2hlZXJzLCBNYW5hdg0KPiA+DQo= From nobody Fri May 9 03:12:18 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D291A024F for ; Fri, 9 May 2014 03:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcCEfxqnTQQC for ; Fri, 9 May 2014 03:12:13 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id DEEDD1A023A for ; Fri, 9 May 2014 03:12:12 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id i7so4668578oag.9 for ; Fri, 09 May 2014 03:12:08 -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=eq8Dhi/lRUg5BKTtHWXkS0X+sCZv/eIVoM0pVe2ma8U=; b=NiQ++IuFdIpM5rK8fdH9A95y87osyh+rR67OXqDBh0llMWnOSPaPhThOSP3VTAzJ83 /ZOpTPtthODDZcebYrlOG2C52EiAITKujk0+w9SEhZXvNouG5r0pCvIM0e/4K9DM6GPL fSVsMVdYQuWcLevHagW7RMQwdIZH68NSu3NDQ+PhgYUw4Gj3aMpMMH0sBdNLJFGdQ/KH f1aJRztEl0B7Se3TVx75bo9d5iQmwW7kBUBtFOQHn5tyzqmrDUvEJPd6z7rgc2GV6Qn9 uxUeXlI03YSlQrwCCsS0HSESk4yyieM+vHHcK+/6Fp+6YFBeZTuRfPloBB95ZUeL0c+N KICw== MIME-Version: 1.0 X-Received: by 10.182.99.198 with SMTP id es6mr11341423obb.69.1399630328057; Fri, 09 May 2014 03:12:08 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Fri, 9 May 2014 03:12:07 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 May 2014 15:42:07 +0530 Message-ID: Subject: Re: Problem with BFD with ECMP From: Manav Bhatia To: Mach Chen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/COXPQksGlHsF9mCktWFHp-6x5dk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 10:12:15 -0000 Hi Mach, >> My point is this: >> >> How do i ensure that in an IP only network, my data traffic always follows the >> same path as the OAM packet that i had sent to verify the data plane? > > It's always desired, but it's hard, and most of time, no perfect solution. Sure the question is: Do we want to fix this? > >> >> Will it work if i encapsulate both the OAM and the data traffic inside a GRE tunnel >> so that both use the same hashing fields? I may want to do this for certain flows >> where i want a very deterministic behavior. > > Yes, use a tunnel to encapsulate both the OAM and the data traffic is a candidate. > But for a deployed network, such changes may not accepted, you cannot change the > existing deployment model. We can look at the solution space later. The first thing is -- Do we want to solve this issue? I would wager that its something that we would want to solve. Just want to hear what others think about this. Cheers, Manav > > Best regards, > Mach > >> >> Cheers, Manav >> >> > detect a segment of the path, means the destination of the S-BFD will >> > be different from the user data. Then you described situation will happen. >> > >> > Best regards, >> > Mach >> > >> >> -----Original Message----- >> >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Manav >> >> Bhatia >> >> Sent: Friday, May 09, 2014 4:02 PM >> >> To: rtg-bfd@ietf.org >> >> Subject: Problem with BFD with ECMP >> >> >> >> Hi, >> >> >> >> There is a problem with how BFD/S-BFD works. >> >> >> >> Sec 3.2 draft-aldrin-bfd-seamless-use-case-01 explains how we can use >> >> S-BFD to quickly validate the data plane before pushing the data out. >> >> >> >> There is a potential issue here. >> >> >> >> Assume I send an S-BFD ping and I get a pong back.I believe that the >> >> path is up and i start sending traffic towards the Reflector, >> >> brimming with confidence, since i believe the data plane is up. >> >> >> >> Assume that there is ECMP happening in the network somewhere that >> >> splits the traffic to paths p1 and p2. >> >> >> >> Its possible that the S-BFD packet gets hashed to the path p1, while >> >> the data traffic that i send gets hashed to path p2. >> >> >> >> If path p2 is down (or is congested and drops packets), then i drop >> >> all traffic -- or some, in case of congestion. This however is >> >> unexpected since i always get 100% response for my S-BFD ping packets. >> >> >> >> I understand that if path p2 is down (because of an issue in one of >> >> the nodes/links in the path), the ECMP path will not contain p2, >> >> since the routing protocols will naturally remove this from the ECMP list. >> >> So, its only while the network is reconverging (which should only >> >> last for a few >> >> secs) that we will see this. >> >> >> >> Is my understanding correct? >> >> >> >> If yes, then is the scenario where S-BFD and data traffic following >> >> different paths something that we want to look at fixing (either here >> >> or some other WG)? This problem has already been solved in the MPLS >> >> context with the Entropy label. I am talking specifically about non-MPLS >> networks. >> >> >> >> Cheers, Manav >> > From nobody Fri May 9 03:52:58 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9871A024B for ; Fri, 9 May 2014 03:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-mnUU7yYog2 for ; Fri, 9 May 2014 03:52:54 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id CFD791A0243 for ; Fri, 9 May 2014 03:52:53 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.54.72]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CC4211800905; Fri, 9 May 2014 12:52:45 +0200 (CEST) Message-ID: <536CB377.9010302@pi.nu> Date: Fri, 09 May 2014 12:52:39 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Manav Bhatia , Mach Chen Subject: Re: Problem with BFD with ECMP References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/TJqHk6JDo3D5LWuBpJ37hAXbLrc Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 10:52:56 -0000 Mach and Manav, I guess that the answer to this type of question is somewhere around "Is it worth doing?". If we see an easy way to fix it and we are pretty sure that it will be deployed, then let us go ahead and do it. If the fix is shady and no one really want it, then just leave it. No in those terms where are we? /Loa On 2014-05-09 12:12, Manav Bhatia wrote: > Hi Mach, > >>> My point is this: >>> >>> How do i ensure that in an IP only network, my data traffic always follows the >>> same path as the OAM packet that i had sent to verify the data plane? >> >> It's always desired, but it's hard, and most of time, no perfect solution. > > Sure the question is: Do we want to fix this? > >> >>> >>> Will it work if i encapsulate both the OAM and the data traffic inside a GRE tunnel >>> so that both use the same hashing fields? I may want to do this for certain flows >>> where i want a very deterministic behavior. >> >> Yes, use a tunnel to encapsulate both the OAM and the data traffic is a candidate. >> But for a deployed network, such changes may not accepted, you cannot change the >> existing deployment model. > > We can look at the solution space later. > > The first thing is -- Do we want to solve this issue? I would wager > that its something that we would want to solve. Just want to hear what > others think about this. > > Cheers, Manav > >> >> Best regards, >> Mach >> >>> >>> Cheers, Manav >>> >>>> detect a segment of the path, means the destination of the S-BFD will >>>> be different from the user data. Then you described situation will happen. >>>> >>>> Best regards, >>>> Mach >>>> >>>>> -----Original Message----- >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Manav >>>>> Bhatia >>>>> Sent: Friday, May 09, 2014 4:02 PM >>>>> To: rtg-bfd@ietf.org >>>>> Subject: Problem with BFD with ECMP >>>>> >>>>> Hi, >>>>> >>>>> There is a problem with how BFD/S-BFD works. >>>>> >>>>> Sec 3.2 draft-aldrin-bfd-seamless-use-case-01 explains how we can use >>>>> S-BFD to quickly validate the data plane before pushing the data out. >>>>> >>>>> There is a potential issue here. >>>>> >>>>> Assume I send an S-BFD ping and I get a pong back.I believe that the >>>>> path is up and i start sending traffic towards the Reflector, >>>>> brimming with confidence, since i believe the data plane is up. >>>>> >>>>> Assume that there is ECMP happening in the network somewhere that >>>>> splits the traffic to paths p1 and p2. >>>>> >>>>> Its possible that the S-BFD packet gets hashed to the path p1, while >>>>> the data traffic that i send gets hashed to path p2. >>>>> >>>>> If path p2 is down (or is congested and drops packets), then i drop >>>>> all traffic -- or some, in case of congestion. This however is >>>>> unexpected since i always get 100% response for my S-BFD ping packets. >>>>> >>>>> I understand that if path p2 is down (because of an issue in one of >>>>> the nodes/links in the path), the ECMP path will not contain p2, >>>>> since the routing protocols will naturally remove this from the ECMP list. >>>>> So, its only while the network is reconverging (which should only >>>>> last for a few >>>>> secs) that we will see this. >>>>> >>>>> Is my understanding correct? >>>>> >>>>> If yes, then is the scenario where S-BFD and data traffic following >>>>> different paths something that we want to look at fixing (either here >>>>> or some other WG)? This problem has already been solved in the MPLS >>>>> context with the Entropy label. I am talking specifically about non-MPLS >>> networks. >>>>> >>>>> Cheers, Manav >>>> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri May 9 05:36:57 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8701A0286 for ; Fri, 9 May 2014 05:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhUEIRgjqyMX for ; Fri, 9 May 2014 05:36:51 -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 C15781A029A for ; Fri, 9 May 2014 05:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6438; q=dns/txt; s=iport; t=1399639006; x=1400848606; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1QJEMMCwss/YJIz7xNNN2ToDDLS73BPKMBgqNd3RU6U=; b=L0688SSCyyp1Xmn/eqnZQ4MlyvDmsomMgvfIBhj+X5XGciCPETcJiN/k xB8CukFbstYNFXDiCUFzDNmME7LLKN0POXAmq410qEIH9WnF5aB02lHuA p+UnfQC3TixZCT6/1YTgxHJFFBBXE37zm2KffPcnut/PCKT4YHeYJ9/kj 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAIPLbFOtJA2M/2dsb2JhbABZgmUhgSeCZ8JeARl/FnSCJQEBAQQjETcODAICAgEIEQQBAQECAgYdAwICAhkXFAEICAIEAQ0FCBOIJgGsQKRsFwSBJogHhD8RAR8WGwcGgm82gRUErEmDNoFvBxcGHA X-IronPort-AV: E=Sophos;i="4.97,1018,1389744000"; d="scan'208";a="323447235" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP; 09 May 2014 12:36:45 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s49Cajgm006651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 12:36:45 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Fri, 9 May 2014 07:36:45 -0500 From: "Nobo Akiya (nobo)" To: Loa Andersson , Manav Bhatia , Mach Chen Subject: RE: Problem with BFD with ECMP Thread-Topic: Problem with BFD with ECMP Thread-Index: AQHPa10Hnz/g8sNPJkCrTO5TJTaw35s4QxqAgAADoQCAABFvAIAAAzGAgAALU4D//8Z6YA== Date: Fri, 9 May 2014 12:36:44 +0000 Message-ID: References: <536CB377.9010302@pi.nu> In-Reply-To: <536CB377.9010302@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/YrTiGvg1e0Sbb-FYzpyaZ3qPAhY Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 12:36:54 -0000 SGkgTWFuYXYsIE1hY2gsIExvYSwNCg0KT24gc29tZSBkYXRhIHBsYW5lcyAoZXg6IE1QTFMgd2l0 aCBFbnRyb3B5IExhYmVsKSwgaXQncyBsZXNzIGRpZmZpY3VsdCB0byB1c2UgT0FNIHBhY2tldHMg dG8gW2xpa2VseV0gZXhlcmNpc2Ugc3BlY2lmaWMgRUNNUCBwYXRocyBhcyBsb25nIGFzIHRoZXJl IGFyZSB3YXlzIHRvIGRpc2NvdmVyIHRoZSBlbnRyb3BpZXMuDQoNCk9uIHNvbWUgb3RoZXJzIChl eDogSVAgbmV0d29yayksIGl0J3MgbW9yZSBkaWZmaWN1bHQgYW5kIEkgZnVsbHkgYWdyZWUgd2l0 aCB3aGF0IExvYSBzYWlkLg0KDQotTm9ibw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBMb2ENCj4gQW5kZXJzc29uDQo+IFNlbnQ6IEZyaWRheSwgTWF5IDA5LCAyMDE0IDY6 NTMgQU0NCj4gVG86IE1hbmF2IEJoYXRpYTsgTWFjaCBDaGVuDQo+IENjOiBydGctYmZkQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBQcm9ibGVtIHdpdGggQkZEIHdpdGggRUNNUA0KPiANCj4gTWFj aCBhbmQgTWFuYXYsDQo+IA0KPiBJIGd1ZXNzIHRoYXQgdGhlIGFuc3dlciB0byB0aGlzIHR5cGUg b2YgcXVlc3Rpb24gaXMgc29tZXdoZXJlIGFyb3VuZCAiSXMgaXQNCj4gd29ydGggZG9pbmc/Ii4g SWYgd2Ugc2VlIGFuIGVhc3kgd2F5IHRvIGZpeCBpdCBhbmQgd2UgYXJlIHByZXR0eSBzdXJlIHRo YXQgaXQNCj4gd2lsbCBiZSBkZXBsb3llZCwgdGhlbiBsZXQgdXMgZ28gYWhlYWQgYW5kIGRvIGl0 LiBJZiB0aGUgZml4IGlzIHNoYWR5IGFuZCBubw0KPiBvbmUgcmVhbGx5IHdhbnQgaXQsIHRoZW4g anVzdCBsZWF2ZSBpdC4NCj4gDQo+IE5vIGluIHRob3NlIHRlcm1zIHdoZXJlIGFyZSB3ZT8NCj4g DQo+IC9Mb2ENCj4gDQo+IE9uIDIwMTQtMDUtMDkgMTI6MTIsIE1hbmF2IEJoYXRpYSB3cm90ZToN Cj4gPiBIaSBNYWNoLA0KPiA+DQo+ID4+PiBNeSBwb2ludCBpcyB0aGlzOg0KPiA+Pj4NCj4gPj4+ IEhvdyBkbyBpIGVuc3VyZSB0aGF0IGluIGFuIElQIG9ubHkgbmV0d29yaywgbXkgZGF0YSB0cmFm ZmljIGFsd2F5cw0KPiA+Pj4gZm9sbG93cyB0aGUgc2FtZSBwYXRoIGFzIHRoZSBPQU0gcGFja2V0 IHRoYXQgaSBoYWQgc2VudCB0byB2ZXJpZnkgdGhlDQo+IGRhdGEgcGxhbmU/DQo+ID4+DQo+ID4+ IEl0J3MgYWx3YXlzIGRlc2lyZWQsIGJ1dCBpdCdzIGhhcmQsIGFuZCBtb3N0IG9mIHRpbWUsIG5v IHBlcmZlY3Qgc29sdXRpb24uDQo+ID4NCj4gPiBTdXJlIHRoZSBxdWVzdGlvbiBpczogRG8gd2Ug d2FudCB0byBmaXggdGhpcz8NCj4gPg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IFdpbGwgaXQgd29yayBp ZiBpIGVuY2Fwc3VsYXRlIGJvdGggdGhlIE9BTSBhbmQgdGhlIGRhdGEgdHJhZmZpYw0KPiA+Pj4g aW5zaWRlIGEgR1JFIHR1bm5lbCBzbyB0aGF0IGJvdGggdXNlIHRoZSBzYW1lIGhhc2hpbmcgZmll bGRzPyBJIG1heQ0KPiA+Pj4gd2FudCB0byBkbyB0aGlzIGZvciBjZXJ0YWluIGZsb3dzIHdoZXJl IGkgd2FudCBhIHZlcnkgZGV0ZXJtaW5pc3RpYw0KPiBiZWhhdmlvci4NCj4gPj4NCj4gPj4gWWVz LCB1c2UgYSB0dW5uZWwgdG8gZW5jYXBzdWxhdGUgYm90aCB0aGUgT0FNIGFuZCB0aGUgZGF0YSB0 cmFmZmljIGlzIGENCj4gY2FuZGlkYXRlLg0KPiA+PiBCdXQgZm9yIGEgZGVwbG95ZWQgbmV0d29y aywgc3VjaCBjaGFuZ2VzIG1heSBub3QgYWNjZXB0ZWQsIHlvdSBjYW5ub3QNCj4gPj4gY2hhbmdl IHRoZSBleGlzdGluZyBkZXBsb3ltZW50IG1vZGVsLg0KPiA+DQo+ID4gV2UgY2FuIGxvb2sgYXQg dGhlIHNvbHV0aW9uIHNwYWNlIGxhdGVyLg0KPiA+DQo+ID4gVGhlIGZpcnN0IHRoaW5nIGlzIC0t IERvIHdlIHdhbnQgdG8gc29sdmUgdGhpcyBpc3N1ZT8gSSB3b3VsZCB3YWdlcg0KPiA+IHRoYXQg aXRzIHNvbWV0aGluZyB0aGF0IHdlIHdvdWxkIHdhbnQgdG8gc29sdmUuIEp1c3Qgd2FudCB0byBo ZWFyIHdoYXQNCj4gPiBvdGhlcnMgdGhpbmsgYWJvdXQgdGhpcy4NCj4gPg0KPiA+IENoZWVycywg TWFuYXYNCj4gPg0KPiA+Pg0KPiA+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+IE1hY2gNCj4gPj4NCj4g Pj4+DQo+ID4+PiBDaGVlcnMsIE1hbmF2DQo+ID4+Pg0KPiA+Pj4+ICAgZGV0ZWN0IGEgc2VnbWVu dCBvZiB0aGUgcGF0aCwgbWVhbnMgdGhlIGRlc3RpbmF0aW9uIG9mIHRoZSBTLUJGRA0KPiA+Pj4+ IHdpbGwgYmUgZGlmZmVyZW50IGZyb20gdGhlIHVzZXIgZGF0YS4gVGhlbiB5b3UgZGVzY3JpYmVk IHNpdHVhdGlvbiB3aWxsDQo+IGhhcHBlbi4NCj4gPj4+Pg0KPiA+Pj4+IEJlc3QgcmVnYXJkcywN Cj4gPj4+PiBNYWNoDQo+ID4+Pj4NCj4gPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPj4+Pj4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE1hbmF2DQo+ID4+Pj4+IEJoYXRpYQ0KPiA+Pj4+PiBTZW50OiBGcmlkYXks IE1heSAwOSwgMjAxNCA0OjAyIFBNDQo+ID4+Pj4+IFRvOiBydGctYmZkQGlldGYub3JnDQo+ID4+ Pj4+IFN1YmplY3Q6IFByb2JsZW0gd2l0aCBCRkQgd2l0aCBFQ01QDQo+ID4+Pj4+DQo+ID4+Pj4+ IEhpLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGVyZSBpcyBhIHByb2JsZW0gd2l0aCBob3cgQkZEL1Mt QkZEIHdvcmtzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBTZWMgMy4yIGRyYWZ0LWFsZHJpbi1iZmQtc2Vh bWxlc3MtdXNlLWNhc2UtMDEgZXhwbGFpbnMgaG93IHdlIGNhbg0KPiA+Pj4+PiB1c2UgUy1CRkQg dG8gcXVpY2tseSB2YWxpZGF0ZSB0aGUgZGF0YSBwbGFuZSBiZWZvcmUgcHVzaGluZyB0aGUgZGF0 YQ0KPiBvdXQuDQo+ID4+Pj4+DQo+ID4+Pj4+IFRoZXJlIGlzIGEgcG90ZW50aWFsIGlzc3VlIGhl cmUuDQo+ID4+Pj4+DQo+ID4+Pj4+IEFzc3VtZSBJIHNlbmQgYW4gUy1CRkQgcGluZyBhbmQgSSBn ZXQgYSBwb25nIGJhY2suSSBiZWxpZXZlIHRoYXQNCj4gPj4+Pj4gdGhlIHBhdGggaXMgdXAgYW5k IGkgc3RhcnQgc2VuZGluZyB0cmFmZmljIHRvd2FyZHMgdGhlIFJlZmxlY3RvciwNCj4gPj4+Pj4g YnJpbW1pbmcgd2l0aCBjb25maWRlbmNlLCBzaW5jZSBpIGJlbGlldmUgdGhlIGRhdGEgcGxhbmUg aXMgdXAuDQo+ID4+Pj4+DQo+ID4+Pj4+IEFzc3VtZSB0aGF0IHRoZXJlIGlzIEVDTVAgaGFwcGVu aW5nIGluIHRoZSBuZXR3b3JrIHNvbWV3aGVyZQ0KPiB0aGF0DQo+ID4+Pj4+IHNwbGl0cyB0aGUg dHJhZmZpYyB0byBwYXRocyBwMSBhbmQgcDIuDQo+ID4+Pj4+DQo+ID4+Pj4+IEl0cyBwb3NzaWJs ZSB0aGF0IHRoZSBTLUJGRCBwYWNrZXQgZ2V0cyBoYXNoZWQgdG8gdGhlIHBhdGggcDEsDQo+ID4+ Pj4+IHdoaWxlIHRoZSBkYXRhIHRyYWZmaWMgdGhhdCBpIHNlbmQgZ2V0cyBoYXNoZWQgdG8gcGF0 aCBwMi4NCj4gPj4+Pj4NCj4gPj4+Pj4gSWYgcGF0aCBwMiBpcyBkb3duIChvciBpcyBjb25nZXN0 ZWQgYW5kIGRyb3BzIHBhY2tldHMpLCB0aGVuIGkNCj4gPj4+Pj4gZHJvcCBhbGwgdHJhZmZpYyAt LSBvciBzb21lLCBpbiBjYXNlIG9mIGNvbmdlc3Rpb24uIFRoaXMgaG93ZXZlcg0KPiA+Pj4+PiBp cyB1bmV4cGVjdGVkIHNpbmNlIGkgYWx3YXlzIGdldCAxMDAlIHJlc3BvbnNlIGZvciBteSBTLUJG RCBwaW5nDQo+IHBhY2tldHMuDQo+ID4+Pj4+DQo+ID4+Pj4+IEkgdW5kZXJzdGFuZCB0aGF0IGlm IHBhdGggcDIgaXMgZG93biAoYmVjYXVzZSBvZiBhbiBpc3N1ZSBpbiBvbmUNCj4gPj4+Pj4gb2Yg dGhlIG5vZGVzL2xpbmtzIGluIHRoZSBwYXRoKSwgdGhlIEVDTVAgcGF0aCB3aWxsIG5vdCBjb250 YWluDQo+ID4+Pj4+IHAyLCBzaW5jZSB0aGUgcm91dGluZyBwcm90b2NvbHMgd2lsbCBuYXR1cmFs bHkgcmVtb3ZlIHRoaXMgZnJvbSB0aGUNCj4gRUNNUCBsaXN0Lg0KPiA+Pj4+PiBTbywgaXRzIG9u bHkgd2hpbGUgdGhlIG5ldHdvcmsgaXMgcmVjb252ZXJnaW5nICh3aGljaCBzaG91bGQgb25seQ0K PiA+Pj4+PiBsYXN0IGZvciBhIGZldw0KPiA+Pj4+PiBzZWNzKSB0aGF0IHdlIHdpbGwgc2VlIHRo aXMuDQo+ID4+Pj4+DQo+ID4+Pj4+IElzIG15IHVuZGVyc3RhbmRpbmcgY29ycmVjdD8NCj4gPj4+ Pj4NCj4gPj4+Pj4gSWYgeWVzLCB0aGVuIGlzIHRoZSBzY2VuYXJpbyB3aGVyZSBTLUJGRCBhbmQg ZGF0YSB0cmFmZmljDQo+ID4+Pj4+IGZvbGxvd2luZyBkaWZmZXJlbnQgcGF0aHMgc29tZXRoaW5n IHRoYXQgd2Ugd2FudCB0byBsb29rIGF0IGZpeGluZw0KPiA+Pj4+PiAoZWl0aGVyIGhlcmUgb3Ig c29tZSBvdGhlciBXRyk/IFRoaXMgcHJvYmxlbSBoYXMgYWxyZWFkeSBiZWVuDQo+ID4+Pj4+IHNv bHZlZCBpbiB0aGUgTVBMUyBjb250ZXh0IHdpdGggdGhlIEVudHJvcHkgbGFiZWwuIEkgYW0gdGFs a2luZw0KPiA+Pj4+PiBzcGVjaWZpY2FsbHkgYWJvdXQgbm9uLU1QTFMNCj4gPj4+IG5ldHdvcmtz Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBDaGVlcnMsIE1hbmF2DQo+ID4+Pj4NCj4gPg0KPiANCj4gLS0N Cj4gDQo+IA0KPiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxv YUBtYWlsMDEuaHVhd2VpLmNvbQ0KPiBTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAg ICAgICAgICAgIGxvYUBwaS5udQ0KPiBIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAg ICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg0K From nobody Fri May 9 06:27:01 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA3A1A0085 for ; Fri, 9 May 2014 06:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GI-Qzhl5nFyE for ; Fri, 9 May 2014 06:26:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 87D5E1A0068 for ; Fri, 9 May 2014 06:26:56 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B145DC09E; Fri, 9 May 2014 09:26:51 -0400 (EDT) Date: Fri, 9 May 2014 09:26:51 -0400 From: Jeffrey Haas To: Loa Andersson Subject: Re: Problem with BFD with ECMP Message-ID: <20140509132651.GE13387@pfrc> References: <536CB377.9010302@pi.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <536CB377.9010302@pi.nu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/iJfReOCcqL5pENpCA3SFoeNrnzQ Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 13:26:57 -0000 On Fri, May 09, 2014 at 12:52:39PM +0200, Loa Andersson wrote: > I guess that the answer to this type of question is somewhere around > "Is it worth doing?". If we see an easy way to fix it and we are pretty > sure that it will be deployed, then let us go ahead and do it. If the > fix is shady and no one really want it, then just leave it. > > No in those terms where are we? We are in the same state of Doom that we have been in for years. :-) ECMP is a well known but not well specified bit of Internet architecture. In some cases, it's a vendor differentiated feature and may differ depending on platform, line card(s) and software revision. Addressing the this in a general fashion would require some mechanism that permitted exposing an algebra that documents traffic hashing on a hop by hop basis, where hops may also include internals of a given device. While I suspect such an effort is, I believe, mathematically tractable, I don't believe such a proposal would be well received. In my opinion, I think we must proceed with an understanding that this situation is status quo. This means mechanisms that intend to probe reachability have to contain a reasonable level of internal mistrust. "I can see the far end, this path *might* work." -- Jeff From nobody Fri May 9 06:55:14 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6544A1A02A0 for ; Fri, 9 May 2014 06:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fj8VDF4oL33d for ; Fri, 9 May 2014 06:55:09 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0013.outbound.protection.outlook.com [213.199.154.13]) by ietfa.amsl.com (Postfix) with ESMTP id BC83C1A00BE for ; Fri, 9 May 2014 06:55:06 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB611.eurprd03.prod.outlook.com (10.242.109.28) with Microsoft SMTP Server (TLS) id 15.0.934.12; Fri, 9 May 2014 13:55:00 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0939.000; Fri, 9 May 2014 13:55:00 +0000 From: Alexander Vainshtein To: Jeffrey Haas , Loa Andersson Subject: Re: Problem with BFD with ECMP Thread-Topic: Problem with BFD with ECMP Thread-Index: AQHPa45E5P5Xbs4mnkKLbDbrBlplmA== Date: Fri, 9 May 2014 13:54:59 +0000 Message-ID: <9033228c0a68442b91c1f99135b3a5b3@AM3PR03MB612.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [95.35.61.247] x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(24454002)(51704005)(479174003)(2656002)(19580405001)(83322001)(21056001)(19580395003)(81542001)(79102001)(33646001)(77096999)(81342001)(83072002)(54356999)(77982001)(561944002)(50986999)(16236675002)(85852003)(99396002)(86362001)(74502001)(46102001)(20776003)(101416001)(66066001)(74662001)(76576001)(4396001)(87936001)(80022001)(19625215002)(74316001)(64706001)(76482001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB611; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: ecitele.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; Content-Type: multipart/alternative; boundary="_000_9033228c0a68442b91c1f99135b3a5b3AM3PR03MB612eurprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/fBxvRZS2rs15RJxxy96OMdv8xdE Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 13:55:12 -0000 --_000_9033228c0a68442b91c1f99135b3a5b3AM3PR03MB612eurprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBjb25jdXIgd2l0aCBKZWZmLg0KDQoNCg0KTXkgMmMNCg0KDQoNClRodW1iIHR5cGVkIG9uIG15 IExHLA0KU2FzaGENCg0KLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tDQpGcm9tOiBKZWZm cmV5IEhhYXMNCkRhdGU6IDA5LzA1LzIwMTQgMTY6MjcNClRvOiBMb2EgQW5kZXJzc29uOw0KQ2M6 IHJ0Zy1iZmRAaWV0Zi5vcmc7DQpTdWJqZWN0OlJlOiBQcm9ibGVtIHdpdGggQkZEIHdpdGggRUNN UA0KDQpPbiBGcmksIE1heSAwOSwgMjAxNCBhdCAxMjo1MjozOVBNICswMjAwLCBMb2EgQW5kZXJz c29uIHdyb3RlOg0KPiBJIGd1ZXNzIHRoYXQgdGhlIGFuc3dlciB0byB0aGlzIHR5cGUgb2YgcXVl c3Rpb24gaXMgc29tZXdoZXJlIGFyb3VuZA0KPiAiSXMgaXQgd29ydGggZG9pbmc/Ii4gSWYgd2Ug c2VlIGFuIGVhc3kgd2F5IHRvIGZpeCBpdCBhbmQgd2UgYXJlIHByZXR0eQ0KPiBzdXJlIHRoYXQg aXQgd2lsbCBiZSBkZXBsb3llZCwgdGhlbiBsZXQgdXMgZ28gYWhlYWQgYW5kIGRvIGl0LiBJZiB0 aGUNCj4gZml4IGlzIHNoYWR5IGFuZCBubyBvbmUgcmVhbGx5IHdhbnQgaXQsIHRoZW4ganVzdCBs ZWF2ZSBpdC4NCj4NCj4gTm8gaW4gdGhvc2UgdGVybXMgd2hlcmUgYXJlIHdlPw0KDQpXZSBhcmUg aW4gdGhlIHNhbWUgc3RhdGUgb2YgRG9vbSB0aGF0IHdlIGhhdmUgYmVlbiBpbiBmb3IgeWVhcnMu IDotKQ0KDQpFQ01QIGlzIGEgd2VsbCBrbm93biBidXQgbm90IHdlbGwgc3BlY2lmaWVkIGJpdCBv ZiBJbnRlcm5ldCBhcmNoaXRlY3R1cmUuDQpJbiBzb21lIGNhc2VzLCBpdCdzIGEgdmVuZG9yIGRp ZmZlcmVudGlhdGVkIGZlYXR1cmUgYW5kIG1heSBkaWZmZXIgZGVwZW5kaW5nDQpvbiBwbGF0Zm9y bSwgbGluZSBjYXJkKHMpIGFuZCBzb2Z0d2FyZSByZXZpc2lvbi4NCg0KQWRkcmVzc2luZyB0aGUg dGhpcyBpbiBhIGdlbmVyYWwgZmFzaGlvbiB3b3VsZCByZXF1aXJlIHNvbWUgbWVjaGFuaXNtIHRo YXQNCnBlcm1pdHRlZCBleHBvc2luZyBhbiBhbGdlYnJhIHRoYXQgZG9jdW1lbnRzIHRyYWZmaWMg aGFzaGluZyBvbiBhIGhvcCBieSBob3ANCmJhc2lzLCB3aGVyZSBob3BzIG1heSBhbHNvIGluY2x1 ZGUgaW50ZXJuYWxzIG9mIGEgZ2l2ZW4gZGV2aWNlLg0KDQpXaGlsZSBJIHN1c3BlY3Qgc3VjaCBh biBlZmZvcnQgaXMsIEkgYmVsaWV2ZSwgIG1hdGhlbWF0aWNhbGx5IHRyYWN0YWJsZSwgSQ0KZG9u J3QgYmVsaWV2ZSBzdWNoIGEgcHJvcG9zYWwgd291bGQgYmUgd2VsbCByZWNlaXZlZC4NCg0KSW4g bXkgb3BpbmlvbiwgSSB0aGluayB3ZSBtdXN0IHByb2NlZWQgd2l0aCBhbiB1bmRlcnN0YW5kaW5n IHRoYXQgdGhpcw0Kc2l0dWF0aW9uIGlzIHN0YXR1cyBxdW8uICBUaGlzIG1lYW5zIG1lY2hhbmlz bXMgdGhhdCBpbnRlbmQgdG8gcHJvYmUNCnJlYWNoYWJpbGl0eSBoYXZlIHRvIGNvbnRhaW4gYSBy ZWFzb25hYmxlIGxldmVsIG9mIGludGVybmFsIG1pc3RydXN0LiAiSSBjYW4NCnNlZSB0aGUgZmFy IGVuZCwgdGhpcyBwYXRoICptaWdodCogd29yay4iDQoNCi0tIEplZmYNCg0K --_000_9033228c0a68442b91c1f99135b3a5b3AM3PR03MB612eurprd03pro_ Content-Type: text/html; charset="utf-8" Content-ID: <4D8E560AFDFBDF448F063A6271617A17@ECI365.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8c3R5bGU+PCEtLSAuRW1haWxRdW90ZSB7 IG1hcmdpbi1sZWZ0OiAxcHQ7IHBhZGRpbmctbGVmdDogNHB0OyBib3JkZXItbGVmdDogIzgwMDAw MCAycHggc29saWQ7IH0gLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5Pg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMHB0OyI+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206 MDsiPkkgY29uY3VyIHdpdGggSmVmZi48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdp bi1ib3R0b206MDsiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJv dHRvbTowOyI+TXkgMmM8L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206 MDsiPiZuYnNwOzwvcD4NCjxkZXYzX2pqeT5UaHVtYiB0eXBlZCBvbiBteSBMRyw8YnI+DQpTYXNo YTwvZGV2M19qank+PGJyPg0KPGJyPg0KLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tPGJy Pg0KPGI+RnJvbTombmJzcDs8L2I+SmVmZnJleSBIYWFzPGpoYWFzQHBmcmMub3JnPjxicj4NCjxi PkRhdGU6Jm5ic3A7PC9iPjA5LzA1LzIwMTQgMTY6Mjc8YnI+DQo8Yj5UbzombmJzcDs8L2I+TG9h IEFuZGVyc3Nvbjs8YnI+DQo8Yj5DYzombmJzcDs8L2I+cnRnLWJmZEBpZXRmLm9yZzs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj5SZTogUHJvYmxlbSB3aXRoIEJGRCB3aXRoIEVDTVA8YnI+DQo8YnI+DQo8 IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQgLS0+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPk9uIEZyaSwgTWF5IDA5LCAy MDE0IGF0IDEyOjUyOjM5UE0gJiM0MzswMjAwLCBMb2EgQW5kZXJzc29uIHdyb3RlOjxicj4NCiZn dDsgSSBndWVzcyB0aGF0IHRoZSBhbnN3ZXIgdG8gdGhpcyB0eXBlIG9mIHF1ZXN0aW9uIGlzIHNv bWV3aGVyZSBhcm91bmQ8YnI+DQomZ3Q7ICZxdW90O0lzIGl0IHdvcnRoIGRvaW5nPyZxdW90Oy4g SWYgd2Ugc2VlIGFuIGVhc3kgd2F5IHRvIGZpeCBpdCBhbmQgd2UgYXJlIHByZXR0eTxicj4NCiZn dDsgc3VyZSB0aGF0IGl0IHdpbGwgYmUgZGVwbG95ZWQsIHRoZW4gbGV0IHVzIGdvIGFoZWFkIGFu ZCBkbyBpdC4gSWYgdGhlPGJyPg0KJmd0OyBmaXggaXMgc2hhZHkgYW5kIG5vIG9uZSByZWFsbHkg d2FudCBpdCwgdGhlbiBqdXN0IGxlYXZlIGl0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBObyBpbiB0 aG9zZSB0ZXJtcyB3aGVyZSBhcmUgd2U/PGJyPg0KPGJyPg0KV2UgYXJlIGluIHRoZSBzYW1lIHN0 YXRlIG9mIERvb20gdGhhdCB3ZSBoYXZlIGJlZW4gaW4gZm9yIHllYXJzLiA6LSk8YnI+DQo8YnI+ DQpFQ01QIGlzIGEgd2VsbCBrbm93biBidXQgbm90IHdlbGwgc3BlY2lmaWVkIGJpdCBvZiBJbnRl cm5ldCBhcmNoaXRlY3R1cmUuPGJyPg0KSW4gc29tZSBjYXNlcywgaXQncyBhIHZlbmRvciBkaWZm ZXJlbnRpYXRlZCBmZWF0dXJlIGFuZCBtYXkgZGlmZmVyIGRlcGVuZGluZzxicj4NCm9uIHBsYXRm b3JtLCBsaW5lIGNhcmQocykgYW5kIHNvZnR3YXJlIHJldmlzaW9uLiZuYnNwOyA8YnI+DQo8YnI+ DQpBZGRyZXNzaW5nIHRoZSB0aGlzIGluIGEgZ2VuZXJhbCBmYXNoaW9uIHdvdWxkIHJlcXVpcmUg c29tZSBtZWNoYW5pc20gdGhhdDxicj4NCnBlcm1pdHRlZCBleHBvc2luZyBhbiBhbGdlYnJhIHRo YXQgZG9jdW1lbnRzIHRyYWZmaWMgaGFzaGluZyBvbiBhIGhvcCBieSBob3A8YnI+DQpiYXNpcywg d2hlcmUgaG9wcyBtYXkgYWxzbyBpbmNsdWRlIGludGVybmFscyBvZiBhIGdpdmVuIGRldmljZS48 YnI+DQo8YnI+DQpXaGlsZSBJIHN1c3BlY3Qgc3VjaCBhbiBlZmZvcnQgaXMsIEkgYmVsaWV2ZSwg Jm5ic3A7bWF0aGVtYXRpY2FsbHkgdHJhY3RhYmxlLCBJPGJyPg0KZG9uJ3QgYmVsaWV2ZSBzdWNo IGEgcHJvcG9zYWwgd291bGQgYmUgd2VsbCByZWNlaXZlZC48YnI+DQo8YnI+DQpJbiBteSBvcGlu aW9uLCBJIHRoaW5rIHdlIG11c3QgcHJvY2VlZCB3aXRoIGFuIHVuZGVyc3RhbmRpbmcgdGhhdCB0 aGlzPGJyPg0Kc2l0dWF0aW9uIGlzIHN0YXR1cyBxdW8uICZuYnNwO1RoaXMgbWVhbnMgbWVjaGFu aXNtcyB0aGF0IGludGVuZCB0byBwcm9iZTxicj4NCnJlYWNoYWJpbGl0eSBoYXZlIHRvIGNvbnRh aW4gYSByZWFzb25hYmxlIGxldmVsIG9mIGludGVybmFsIG1pc3RydXN0LiAmcXVvdDtJIGNhbjxi cj4NCnNlZSB0aGUgZmFyIGVuZCwgdGhpcyBwYXRoICptaWdodCogd29yay4mcXVvdDs8YnI+DQo8 YnI+DQotLSBKZWZmPGJyPg0KPGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_9033228c0a68442b91c1f99135b3a5b3AM3PR03MB612eurprd03pro_-- From nobody Fri May 9 07:31:24 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2571A02CD for ; Fri, 9 May 2014 07:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdNGfUDjcuNu for ; Fri, 9 May 2014 07:31:15 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBDF1A02B6 for ; Fri, 9 May 2014 07:31:12 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-60-536c978c8670 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id CC.42.07420.C879C635; Fri, 9 May 2014 10:53:33 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Fri, 9 May 2014 10:31:05 -0400 From: Gregory Mirsky To: Manav Bhatia , "rtg-bfd@ietf.org" Subject: RE: Problem with BFD with ECMP Thread-Topic: Problem with BFD with ECMP Thread-Index: AQHPa10FR1gHtZZKvUKBKUPQtfY0Zps4TM9w Date: Fri, 9 May 2014 14:31:04 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7ACA47@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyuXRPiG7v9JxggzPdUhaXJ7WxW3z+s43R gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mp48Xorc0GDREXzvLvsDYwbxLsYOTkkBEwk ume+YIGwxSQu3FvP1sXIxSEkcJRRovNXJxOEs4xRYu+pDUwgVWwCRhIvNvawdzFycIgIBEp8 fBsOEhYWUJd4Pv8tG4gtIqAhsW1GEyuEbSTReXYpmM0ioCLx+twqsDG8Ar4SBxZcZAexhQQC JP783A4W5wQauaPvNjOIzQh00PdTa8DizALiEreezGeCOFRAYsme88wQtqjEy8f/WCFsJYk5 r68xg5zGLKApsX6XPkSrosSU7ofsEGsFJU7OfMIygVF0FpKpsxA6ZiHpmIWkYwEjyypGjtLi 1LLcdCODTYzASDgmwaa7g3HPS8tDjAIcjEo8vAtCs4OFWBPLiitzDzFKc7AoifMWfIkNFhJI TyxJzU5NLUgtii8qzUktPsTIxMEp1cBYuKeT+55LYdnvDzq6d5Ktep9x3JxRcP72Mg3xUwkT HqtOOXXny8JzE8WKwl+pF888KyqRmF6890nlpJLUky0/6uXVNC8Hi1YIvaj/7l+ZJMF3+XvB tP9CCzyufOaOur87/X0/84F3k+c++Ti3LNv8xTyuF33b4hI2uLusznNa7bCVbZeFDXeEEktx RqKhFnNRcSIAV6IVmWUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/euEyBDGD0JZSx-nQE2YFboQufDk X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 14:31:17 -0000 SGkgTWFuYXYsIGV0LiBhbCwNCkkgYmVsaWV2ZSB0aGF0IHdlIGNhbm5vdCBzYXkgdGhhdCBFQ01Q IHNjZW5hcmlvIHlvdSd2ZSBkZXNjcmliZWQsIGkuZS4gRUNNUCBjb252ZXJnZW5jZSwgYmVlbiBz b2x2ZWQgaW4gTVBMUyBieSBhcHBsaWNhdGlvbiBvZiBFTEkvRUwuIEFzIGluIGNhc2Ugb2YgSVAg bmV0d29yaywgY29udmVyZ2VuY2Ugb2YgTVBMUyBuZXR3b3JrIGNvbnN0cmFpbmVkIGJ5IHRpbWUg Zm9yIGZhdWx0IGRldGVjdGlvbiBhbmQgcmUtaGFzaGluZyBhdmFpbGFibGUgcGF0aHMgaW4gYSBG SUIvTEZJQi4gRHVyaW5nIHRoYXQgcGVyaW9kIE1QTFMgcGFja2V0cyB3aWxsIGJlIGRyb3BwZWQg b24gcDIuIEFmdGVyIHRoYXQgcmV0dXJuIHBhdGggcDIgdGhhdCBjYXJyaWVkIGZsb3cgd2l0aCBF TCBMMSB3aWxsIGJlY29tZSBwMicgYW5kIHBhY2tldHMgd2l0aCBMMSB3aWxsIGdldCB0byB0aGUg ZGVzdGluYXRpb24uIFdvdWxkIHlvdSBhZ3JlZT8NCg0KCVJlZ2FyZHMsDQoJCUdyZWcNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYW5hdiBCaGF0aWENClNlbnQ6IEZyaWRheSwg TWF5IDA5LCAyMDE0IDE6MDIgQU0NClRvOiBydGctYmZkQGlldGYub3JnDQpTdWJqZWN0OiBQcm9i bGVtIHdpdGggQkZEIHdpdGggRUNNUA0KDQpIaSwNCg0KVGhlcmUgaXMgYSBwcm9ibGVtIHdpdGgg aG93IEJGRC9TLUJGRCB3b3Jrcy4NCg0KU2VjIDMuMiBkcmFmdC1hbGRyaW4tYmZkLXNlYW1sZXNz LXVzZS1jYXNlLTAxIGV4cGxhaW5zIGhvdyB3ZSBjYW4gdXNlIFMtQkZEIHRvIHF1aWNrbHkgdmFs aWRhdGUgdGhlIGRhdGEgcGxhbmUgYmVmb3JlIHB1c2hpbmcgdGhlIGRhdGEgb3V0Lg0KDQpUaGVy ZSBpcyBhIHBvdGVudGlhbCBpc3N1ZSBoZXJlLg0KDQpBc3N1bWUgSSBzZW5kIGFuIFMtQkZEIHBp bmcgYW5kIEkgZ2V0IGEgcG9uZyBiYWNrLkkgYmVsaWV2ZSB0aGF0IHRoZSBwYXRoIGlzIHVwIGFu ZCBpIHN0YXJ0IHNlbmRpbmcgdHJhZmZpYyB0b3dhcmRzIHRoZSBSZWZsZWN0b3IsIGJyaW1taW5n IHdpdGggY29uZmlkZW5jZSwgc2luY2UgaSBiZWxpZXZlIHRoZSBkYXRhIHBsYW5lIGlzIHVwLg0K DQpBc3N1bWUgdGhhdCB0aGVyZSBpcyBFQ01QIGhhcHBlbmluZyBpbiB0aGUgbmV0d29yayBzb21l d2hlcmUgdGhhdCBzcGxpdHMgdGhlIHRyYWZmaWMgdG8gcGF0aHMgcDEgYW5kIHAyLg0KDQpJdHMg cG9zc2libGUgdGhhdCB0aGUgUy1CRkQgcGFja2V0IGdldHMgaGFzaGVkIHRvIHRoZSBwYXRoIHAx LCB3aGlsZSB0aGUgZGF0YSB0cmFmZmljIHRoYXQgaSBzZW5kIGdldHMgaGFzaGVkIHRvIHBhdGgg cDIuDQoNCklmIHBhdGggcDIgaXMgZG93biAob3IgaXMgY29uZ2VzdGVkIGFuZCBkcm9wcyBwYWNr ZXRzKSwgdGhlbiBpIGRyb3AgYWxsIHRyYWZmaWMgLS0gb3Igc29tZSwgaW4gY2FzZSBvZiBjb25n ZXN0aW9uLiBUaGlzIGhvd2V2ZXIgaXMgdW5leHBlY3RlZCBzaW5jZSBpIGFsd2F5cyBnZXQgMTAw JSByZXNwb25zZSBmb3IgbXkgUy1CRkQgcGluZyBwYWNrZXRzLg0KDQpJIHVuZGVyc3RhbmQgdGhh dCBpZiBwYXRoIHAyIGlzIGRvd24gKGJlY2F1c2Ugb2YgYW4gaXNzdWUgaW4gb25lIG9mIHRoZSBu b2Rlcy9saW5rcyBpbiB0aGUgcGF0aCksIHRoZSBFQ01QIHBhdGggd2lsbCBub3QgY29udGFpbiBw Miwgc2luY2UgdGhlIHJvdXRpbmcgcHJvdG9jb2xzIHdpbGwgbmF0dXJhbGx5IHJlbW92ZSB0aGlz IGZyb20gdGhlIEVDTVAgbGlzdC4NClNvLCBpdHMgb25seSB3aGlsZSB0aGUgbmV0d29yayBpcyBy ZWNvbnZlcmdpbmcgKHdoaWNoIHNob3VsZCBvbmx5IGxhc3QgZm9yIGEgZmV3IHNlY3MpIHRoYXQg d2Ugd2lsbCBzZWUgdGhpcy4NCg0KSXMgbXkgdW5kZXJzdGFuZGluZyBjb3JyZWN0Pw0KDQpJZiB5 ZXMsIHRoZW4gaXMgdGhlIHNjZW5hcmlvIHdoZXJlIFMtQkZEIGFuZCBkYXRhIHRyYWZmaWMgZm9s bG93aW5nIGRpZmZlcmVudCBwYXRocyBzb21ldGhpbmcgdGhhdCB3ZSB3YW50IHRvIGxvb2sgYXQg Zml4aW5nIChlaXRoZXIgaGVyZSBvciBzb21lIG90aGVyIFdHKT8gVGhpcyBwcm9ibGVtIGhhcyBh bHJlYWR5IGJlZW4gc29sdmVkIGluIHRoZSBNUExTIGNvbnRleHQgd2l0aCB0aGUgRW50cm9weSBs YWJlbC4gSSBhbSB0YWxraW5nIHNwZWNpZmljYWxseSBhYm91dCBub24tTVBMUyBuZXR3b3Jrcy4N Cg0KQ2hlZXJzLCBNYW5hdg0KDQo= From nobody Fri May 9 07:47:08 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2511A001A for ; Fri, 9 May 2014 07:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoNon8qgPrbF for ; Fri, 9 May 2014 07:47:03 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD2D1A0010 for ; Fri, 9 May 2014 07:47:03 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-8a-536c98d5af63 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E1.14.02831.5D89C635; Fri, 9 May 2014 10:59:01 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Fri, 9 May 2014 10:46:58 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , Loa Andersson , "Manav Bhatia" , Mach Chen Subject: RE: Problem with BFD with ECMP Thread-Topic: Problem with BFD with ECMP Thread-Index: AQHPa10FR1gHtZZKvUKBKUPQtfY0Zps4MleAgAADoACAABFwAIAAAzCAgAALU4CAAB0VAP//3u0Q Date: Fri, 9 May 2014 14:46:57 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7ACA78@eusaamb103.ericsson.se> References: <536CB377.9010302@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyuXRPiO7VGTnBBis2mVj8mzuH2eLCWmGL y5Pa2C1md8RbfP6zjdGB1WPK742sHjtn3WX3aDnyltVjyZKfTB6zprexBbBGcdmkpOZklqUW 6dslcGV8OvKJtWCWTcXPne+YGhivWHUxcnJICJhIdH7sYISwxSQu3FvPBmILCRxllFh8o7aL kQvIXsYo0fbwFjtIgk3ASOLFxh52kISIQD+jxMyvi1lAEswCmhJNJz6DFQkLqEs8n/8WbJKI gIbEthlNrBB2lETP3idgcRYBFYmzv7rB6nkFfCUWti1hgth2hVni0IpJYA2cQInbd36AnccI dN73U2uYIJaJS9x6Mp8J4mwBiSV7zjND2KISLx//Y4WwlSTmvL4GFOcAO279Ln2IVkWJKd0P ofYKSpyc+YRlAqPYLCRTZyF0zELSMQtJxwJGllWMHKXFqWW56UaGmxiB0XVMgs1xB+OCT5aH GAU4GJV4eBeEZgcLsSaWFVfmHmKU5mBREudN/xQbLCSQnliSmp2aWpBaFF9UmpNafIiRiYNT qoExmrdx19fvP3KPPolk+P1YTNr68oEK403L5X+6em0we9ozS6IsRDJ8+pmuO7w6i745mH/O 73RaU/hNaXrLygfMdz/xVr1Xyvh8+eLxX7ZeeSuE+Ru69G9uruT82fTs3rKbSf9kduWUZavM irz34WJvNTMLQ6W8ktLfk9fYZr1mlWJ7WLvUeddWJZbijERDLeai4kQAEy0KY48CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/m2Mjm8IUoqoXl9Icnw__tRxnyzU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 14:47:05 -0000 SGkgTm9ibywgZXQuIGFsLA0KSSdtIG5vdCBzdXJlIHRoYXQgRUxJL0VMIHdhcyBpbnRlbmRlZCB0 byBwaW4gYSBmbG93IHRvIHRoZSBwYXJ0aWN1bGFyIEVDTVAgcGF0aC4gTXkgdW5kZXJzdGFuZGlu ZyBvZiBFTCBpcyB0aGF0IGl0IG1ha2VzIGVhc2llciB0byBkaXN0cmlidXRlIGZsb3dzLCBlLmcu IGJ5IGFzc2lnbmluZyBFTCBsYWJlbHMgZnJvbSBsYWJlbCByYW5nZSBOIGxhYmVscyB3aWRlLCBb TSwgTStOXSB3aGVuIHRoZXJlIGFyZSBOIGF2YWlsYWJsZSBwYXRocyBpbiBhbiBFQ01QLiBJIGJl bGlldmUgdGhhdCB0aGVyZSBpcyBubyBleHBlY3RhdGlvbiB0byBwcmVkaWN0IHdpdGggYW55IGxl dmVsIG9mIGNlcnRhaW50eSB3aGljaCBwYXJ0aWN1bGFyIHBhdGggYSBmbG93IHdpbGwgZm9sbG93 IGJ1dCBvbmx5IGV4cGVjdGF0aW9uIHRoYXQgZmxvdyB3aXRoIEVMIE0rMiB3aWxsIHRha2UgZGlm ZmVyZW50IHBhdGggd2l0aCBmbG93IHRhZ2dlZCBieSBFTCBNKzMuIENlcnRhaW50eSBpcyByZXF1 aXJlZCB0aG91Z2ggd2hlbiBFQ01QIGlzIHZpZXdlZCBhcyBhIGxpbmssIGUuZy4gbWljcm8tQkZE Lg0KDQoJUmVnYXJkcywNCgkJR3JlZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IE5vYm8gQWtpeWEgKG5vYm8pDQpTZW50OiBGcmlkYXksIE1heSAwOSwgMjAxNCA1OjM3IEFNDQpU bzogTG9hIEFuZGVyc3NvbjsgTWFuYXYgQmhhdGlhOyBNYWNoIENoZW4NCkNjOiBydGctYmZkQGll dGYub3JnDQpTdWJqZWN0OiBSRTogUHJvYmxlbSB3aXRoIEJGRCB3aXRoIEVDTVANCg0KSGkgTWFu YXYsIE1hY2gsIExvYSwNCg0KT24gc29tZSBkYXRhIHBsYW5lcyAoZXg6IE1QTFMgd2l0aCBFbnRy b3B5IExhYmVsKSwgaXQncyBsZXNzIGRpZmZpY3VsdCB0byB1c2UgT0FNIHBhY2tldHMgdG8gW2xp a2VseV0gZXhlcmNpc2Ugc3BlY2lmaWMgRUNNUCBwYXRocyBhcyBsb25nIGFzIHRoZXJlIGFyZSB3 YXlzIHRvIGRpc2NvdmVyIHRoZSBlbnRyb3BpZXMuDQoNCk9uIHNvbWUgb3RoZXJzIChleDogSVAg bmV0d29yayksIGl0J3MgbW9yZSBkaWZmaWN1bHQgYW5kIEkgZnVsbHkgYWdyZWUgd2l0aCB3aGF0 IExvYSBzYWlkLg0KDQotTm9ibw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBMb2EgDQo+IEFuZGVyc3Nvbg0KPiBTZW50OiBGcmlkYXksIE1heSAwOSwgMjAxNCA2OjUzIEFN DQo+IFRvOiBNYW5hdiBCaGF0aWE7IE1hY2ggQ2hlbg0KPiBDYzogcnRnLWJmZEBpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogUHJvYmxlbSB3aXRoIEJGRCB3aXRoIEVDTVANCj4gDQo+IE1hY2ggYW5k IE1hbmF2LA0KPiANCj4gSSBndWVzcyB0aGF0IHRoZSBhbnN3ZXIgdG8gdGhpcyB0eXBlIG9mIHF1 ZXN0aW9uIGlzIHNvbWV3aGVyZSBhcm91bmQgDQo+ICJJcyBpdCB3b3J0aCBkb2luZz8iLiBJZiB3 ZSBzZWUgYW4gZWFzeSB3YXkgdG8gZml4IGl0IGFuZCB3ZSBhcmUgDQo+IHByZXR0eSBzdXJlIHRo YXQgaXQgd2lsbCBiZSBkZXBsb3llZCwgdGhlbiBsZXQgdXMgZ28gYWhlYWQgYW5kIGRvIGl0LiAN Cj4gSWYgdGhlIGZpeCBpcyBzaGFkeSBhbmQgbm8gb25lIHJlYWxseSB3YW50IGl0LCB0aGVuIGp1 c3QgbGVhdmUgaXQuDQo+IA0KPiBObyBpbiB0aG9zZSB0ZXJtcyB3aGVyZSBhcmUgd2U/DQo+IA0K PiAvTG9hDQo+IA0KPiBPbiAyMDE0LTA1LTA5IDEyOjEyLCBNYW5hdiBCaGF0aWEgd3JvdGU6DQo+ ID4gSGkgTWFjaCwNCj4gPg0KPiA+Pj4gTXkgcG9pbnQgaXMgdGhpczoNCj4gPj4+DQo+ID4+PiBI b3cgZG8gaSBlbnN1cmUgdGhhdCBpbiBhbiBJUCBvbmx5IG5ldHdvcmssIG15IGRhdGEgdHJhZmZp YyBhbHdheXMgDQo+ID4+PiBmb2xsb3dzIHRoZSBzYW1lIHBhdGggYXMgdGhlIE9BTSBwYWNrZXQg dGhhdCBpIGhhZCBzZW50IHRvIHZlcmlmeSANCj4gPj4+IHRoZQ0KPiBkYXRhIHBsYW5lPw0KPiA+ Pg0KPiA+PiBJdCdzIGFsd2F5cyBkZXNpcmVkLCBidXQgaXQncyBoYXJkLCBhbmQgbW9zdCBvZiB0 aW1lLCBubyBwZXJmZWN0IHNvbHV0aW9uLg0KPiA+DQo+ID4gU3VyZSB0aGUgcXVlc3Rpb24gaXM6 IERvIHdlIHdhbnQgdG8gZml4IHRoaXM/DQo+ID4NCj4gPj4NCj4gPj4+DQo+ID4+PiBXaWxsIGl0 IHdvcmsgaWYgaSBlbmNhcHN1bGF0ZSBib3RoIHRoZSBPQU0gYW5kIHRoZSBkYXRhIHRyYWZmaWMg DQo+ID4+PiBpbnNpZGUgYSBHUkUgdHVubmVsIHNvIHRoYXQgYm90aCB1c2UgdGhlIHNhbWUgaGFz aGluZyBmaWVsZHM/IEkgDQo+ID4+PiBtYXkgd2FudCB0byBkbyB0aGlzIGZvciBjZXJ0YWluIGZs b3dzIHdoZXJlIGkgd2FudCBhIHZlcnkgDQo+ID4+PiBkZXRlcm1pbmlzdGljDQo+IGJlaGF2aW9y Lg0KPiA+Pg0KPiA+PiBZZXMsIHVzZSBhIHR1bm5lbCB0byBlbmNhcHN1bGF0ZSBib3RoIHRoZSBP QU0gYW5kIHRoZSBkYXRhIHRyYWZmaWMgDQo+ID4+IGlzIGENCj4gY2FuZGlkYXRlLg0KPiA+PiBC dXQgZm9yIGEgZGVwbG95ZWQgbmV0d29yaywgc3VjaCBjaGFuZ2VzIG1heSBub3QgYWNjZXB0ZWQs IHlvdSANCj4gPj4gY2Fubm90IGNoYW5nZSB0aGUgZXhpc3RpbmcgZGVwbG95bWVudCBtb2RlbC4N Cj4gPg0KPiA+IFdlIGNhbiBsb29rIGF0IHRoZSBzb2x1dGlvbiBzcGFjZSBsYXRlci4NCj4gPg0K PiA+IFRoZSBmaXJzdCB0aGluZyBpcyAtLSBEbyB3ZSB3YW50IHRvIHNvbHZlIHRoaXMgaXNzdWU/ IEkgd291bGQgd2FnZXIgDQo+ID4gdGhhdCBpdHMgc29tZXRoaW5nIHRoYXQgd2Ugd291bGQgd2Fu dCB0byBzb2x2ZS4gSnVzdCB3YW50IHRvIGhlYXIgDQo+ID4gd2hhdCBvdGhlcnMgdGhpbmsgYWJv dXQgdGhpcy4NCj4gPg0KPiA+IENoZWVycywgTWFuYXYNCj4gPg0KPiA+Pg0KPiA+PiBCZXN0IHJl Z2FyZHMsDQo+ID4+IE1hY2gNCj4gPj4NCj4gPj4+DQo+ID4+PiBDaGVlcnMsIE1hbmF2DQo+ID4+ Pg0KPiA+Pj4+ICAgZGV0ZWN0IGEgc2VnbWVudCBvZiB0aGUgcGF0aCwgbWVhbnMgdGhlIGRlc3Rp bmF0aW9uIG9mIHRoZSANCj4gPj4+PiBTLUJGRCB3aWxsIGJlIGRpZmZlcmVudCBmcm9tIHRoZSB1 c2VyIGRhdGEuIFRoZW4geW91IGRlc2NyaWJlZCANCj4gPj4+PiBzaXR1YXRpb24gd2lsbA0KPiBo YXBwZW4uDQo+ID4+Pj4NCj4gPj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+Pj4gTWFjaA0KPiA+Pj4+ DQo+ID4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+IEZyb206IFJ0Zy1i ZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANCj4gPj4+ Pj4gTWFuYXYgQmhhdGlhDQo+ID4+Pj4+IFNlbnQ6IEZyaWRheSwgTWF5IDA5LCAyMDE0IDQ6MDIg UE0NCj4gPj4+Pj4gVG86IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gPj4+Pj4gU3ViamVjdDogUHJvYmxl bSB3aXRoIEJGRCB3aXRoIEVDTVANCj4gPj4+Pj4NCj4gPj4+Pj4gSGksDQo+ID4+Pj4+DQo+ID4+ Pj4+IFRoZXJlIGlzIGEgcHJvYmxlbSB3aXRoIGhvdyBCRkQvUy1CRkQgd29ya3MuDQo+ID4+Pj4+ DQo+ID4+Pj4+IFNlYyAzLjIgZHJhZnQtYWxkcmluLWJmZC1zZWFtbGVzcy11c2UtY2FzZS0wMSBl eHBsYWlucyBob3cgd2UgDQo+ID4+Pj4+IGNhbiB1c2UgUy1CRkQgdG8gcXVpY2tseSB2YWxpZGF0 ZSB0aGUgZGF0YSBwbGFuZSBiZWZvcmUgcHVzaGluZyANCj4gPj4+Pj4gdGhlIGRhdGENCj4gb3V0 Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGVyZSBpcyBhIHBvdGVudGlhbCBpc3N1ZSBoZXJlLg0KPiA+ Pj4+Pg0KPiA+Pj4+PiBBc3N1bWUgSSBzZW5kIGFuIFMtQkZEIHBpbmcgYW5kIEkgZ2V0IGEgcG9u ZyBiYWNrLkkgYmVsaWV2ZSB0aGF0IA0KPiA+Pj4+PiB0aGUgcGF0aCBpcyB1cCBhbmQgaSBzdGFy dCBzZW5kaW5nIHRyYWZmaWMgdG93YXJkcyB0aGUgDQo+ID4+Pj4+IFJlZmxlY3RvciwgYnJpbW1p bmcgd2l0aCBjb25maWRlbmNlLCBzaW5jZSBpIGJlbGlldmUgdGhlIGRhdGEgcGxhbmUgaXMgdXAu DQo+ID4+Pj4+DQo+ID4+Pj4+IEFzc3VtZSB0aGF0IHRoZXJlIGlzIEVDTVAgaGFwcGVuaW5nIGlu IHRoZSBuZXR3b3JrIHNvbWV3aGVyZQ0KPiB0aGF0DQo+ID4+Pj4+IHNwbGl0cyB0aGUgdHJhZmZp YyB0byBwYXRocyBwMSBhbmQgcDIuDQo+ID4+Pj4+DQo+ID4+Pj4+IEl0cyBwb3NzaWJsZSB0aGF0 IHRoZSBTLUJGRCBwYWNrZXQgZ2V0cyBoYXNoZWQgdG8gdGhlIHBhdGggcDEsIA0KPiA+Pj4+PiB3 aGlsZSB0aGUgZGF0YSB0cmFmZmljIHRoYXQgaSBzZW5kIGdldHMgaGFzaGVkIHRvIHBhdGggcDIu DQo+ID4+Pj4+DQo+ID4+Pj4+IElmIHBhdGggcDIgaXMgZG93biAob3IgaXMgY29uZ2VzdGVkIGFu ZCBkcm9wcyBwYWNrZXRzKSwgdGhlbiBpIA0KPiA+Pj4+PiBkcm9wIGFsbCB0cmFmZmljIC0tIG9y IHNvbWUsIGluIGNhc2Ugb2YgY29uZ2VzdGlvbi4gVGhpcyBob3dldmVyIA0KPiA+Pj4+PiBpcyB1 bmV4cGVjdGVkIHNpbmNlIGkgYWx3YXlzIGdldCAxMDAlIHJlc3BvbnNlIGZvciBteSBTLUJGRCBw aW5nDQo+IHBhY2tldHMuDQo+ID4+Pj4+DQo+ID4+Pj4+IEkgdW5kZXJzdGFuZCB0aGF0IGlmIHBh dGggcDIgaXMgZG93biAoYmVjYXVzZSBvZiBhbiBpc3N1ZSBpbiBvbmUgDQo+ID4+Pj4+IG9mIHRo ZSBub2Rlcy9saW5rcyBpbiB0aGUgcGF0aCksIHRoZSBFQ01QIHBhdGggd2lsbCBub3QgY29udGFp biANCj4gPj4+Pj4gcDIsIHNpbmNlIHRoZSByb3V0aW5nIHByb3RvY29scyB3aWxsIG5hdHVyYWxs eSByZW1vdmUgdGhpcyBmcm9tIA0KPiA+Pj4+PiB0aGUNCj4gRUNNUCBsaXN0Lg0KPiA+Pj4+PiBT bywgaXRzIG9ubHkgd2hpbGUgdGhlIG5ldHdvcmsgaXMgcmVjb252ZXJnaW5nICh3aGljaCBzaG91 bGQgDQo+ID4+Pj4+IG9ubHkgbGFzdCBmb3IgYSBmZXcNCj4gPj4+Pj4gc2VjcykgdGhhdCB3ZSB3 aWxsIHNlZSB0aGlzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJcyBteSB1bmRlcnN0YW5kaW5nIGNvcnJl Y3Q/DQo+ID4+Pj4+DQo+ID4+Pj4+IElmIHllcywgdGhlbiBpcyB0aGUgc2NlbmFyaW8gd2hlcmUg Uy1CRkQgYW5kIGRhdGEgdHJhZmZpYyANCj4gPj4+Pj4gZm9sbG93aW5nIGRpZmZlcmVudCBwYXRo cyBzb21ldGhpbmcgdGhhdCB3ZSB3YW50IHRvIGxvb2sgYXQgDQo+ID4+Pj4+IGZpeGluZyAoZWl0 aGVyIGhlcmUgb3Igc29tZSBvdGhlciBXRyk/IFRoaXMgcHJvYmxlbSBoYXMgYWxyZWFkeSANCj4g Pj4+Pj4gYmVlbiBzb2x2ZWQgaW4gdGhlIE1QTFMgY29udGV4dCB3aXRoIHRoZSBFbnRyb3B5IGxh YmVsLiBJIGFtIA0KPiA+Pj4+PiB0YWxraW5nIHNwZWNpZmljYWxseSBhYm91dCBub24tTVBMUw0K PiA+Pj4gbmV0d29ya3MuDQo+ID4+Pj4+DQo+ID4+Pj4+IENoZWVycywgTWFuYXYNCj4gPj4+Pg0K PiA+DQo+IA0KPiAtLQ0KPiANCj4gDQo+IExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAg ICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+IFNlbmlvciBNUExTIEV4cGVydCAg ICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51DQo+IEh1YXdlaSBUZWNobm9sb2dpZXMg KGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KDQo= From nobody Fri May 9 07:55:05 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BAC1A0021 for ; Fri, 9 May 2014 07:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6FqBk4dEGXf for ; Fri, 9 May 2014 07:55:00 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id B59DA1A0008 for ; Fri, 9 May 2014 07:55:00 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id kq14so4459571pab.38 for ; Fri, 09 May 2014 07:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SDbto5Uyf2vem8VULwU+9Nr95FFrHsWjHc3Mpp/ctH8=; b=FhbjzIAn8n5MglUviDSoh+gmo25mNUTYH6WpmF8ge+Fy/o2/IKXxxGbSNLyVliQwQ+ 1IkUwx6mU+CbIR8KgY3FlwwYp+RsDZs93QDL7JrZ1pozuJSBz6c/4brOPgkDyP5uIwmm BetLYnV0NKuXp+mK8x6IHIuSgZmdS3gt4BkKQHgcivfvH3N+yfhIee7xJzuEMVAje9S0 +/5m2Cr5nGfinH9KIOSThzIq81XORnyj5HStkq2Dq2QX0PFxFl/8y2cwjsxT3yFzt3WJ qbj4vft/D1vuiTQXtKQMqUrKXuuo0kryDX0R3q4Dn/PqaG8mdkXcD206L8niFP47W5SD BzCQ== X-Received: by 10.66.171.206 with SMTP id aw14mr21600980pac.48.1399647295020; Fri, 09 May 2014 07:54:55 -0700 (PDT) Received: from [192.168.1.7] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id bu1sm8007485pbb.54.2014.05.09.07.54.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 May 2014 07:54:52 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Problem with BFD with ECMP From: Sam Aldrin In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7ACA78@eusaamb103.ericsson.se> Date: Fri, 9 May 2014 07:54:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <945DB47F-1095-45E8-811A-63B6E8ED7A76@gmail.com> References: <536CB377.9010302@pi.nu> <7347100B5761DC41A166AC17F22DF1121B7ACA78@eusaamb103.ericsson.se> To: Gregory Mirsky X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/xrbAZyWA9xQvf_1pTy7rJ7kvoTo Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 14:55:03 -0000 Hi folks, As Greg said, EL/ELI cannot predict which packet takes which path. It is = only used to distribute flows of data packets, with an assumption that = hashing will occur to utilize load balanced paths. MPLS OAM cannot predict this either. That is why, as a vendor, one = implements various tools like trace, path trace etc. I see it no different to non-MPLS networks either. As far as sec 3.2 of the use case document is concerned, S-BFD is not = replacing other OAM tools. It still performs cc checks. Solving ECMP issue is a never ending and don=92t see one either, unless = load balancing is standardized and all intermediate nodes confirmed to = that, IMHO. Till that time we have to play hash tag=92s. :D cheers -sam On May 9, 2014, at 7:46 AM, Gregory Mirsky = wrote: > Hi Nobo, et. al, > I'm not sure that ELI/EL was intended to pin a flow to the particular = ECMP path. My understanding of EL is that it makes easier to distribute = flows, e.g. by assigning EL labels from label range N labels wide, [M, = M+N] when there are N available paths in an ECMP. I believe that there = is no expectation to predict with any level of certainty which = particular path a flow will follow but only expectation that flow with = EL M+2 will take different path with flow tagged by EL M+3. Certainty is = required though when ECMP is viewed as a link, e.g. micro-BFD. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo = Akiya (nobo) > Sent: Friday, May 09, 2014 5:37 AM > To: Loa Andersson; Manav Bhatia; Mach Chen > Cc: rtg-bfd@ietf.org > Subject: RE: Problem with BFD with ECMP >=20 > Hi Manav, Mach, Loa, >=20 > On some data planes (ex: MPLS with Entropy Label), it's less difficult = to use OAM packets to [likely] exercise specific ECMP paths as long as = there are ways to discover the entropies. >=20 > On some others (ex: IP network), it's more difficult and I fully agree = with what Loa said. >=20 > -Nobo >=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Loa=20 >> Andersson >> Sent: Friday, May 09, 2014 6:53 AM >> To: Manav Bhatia; Mach Chen >> Cc: rtg-bfd@ietf.org >> Subject: Re: Problem with BFD with ECMP >>=20 >> Mach and Manav, >>=20 >> I guess that the answer to this type of question is somewhere around=20= >> "Is it worth doing?". If we see an easy way to fix it and we are=20 >> pretty sure that it will be deployed, then let us go ahead and do it.=20= >> If the fix is shady and no one really want it, then just leave it. >>=20 >> No in those terms where are we? >>=20 >> /Loa >>=20 >> On 2014-05-09 12:12, Manav Bhatia wrote: >>> Hi Mach, >>>=20 >>>>> My point is this: >>>>>=20 >>>>> How do i ensure that in an IP only network, my data traffic always=20= >>>>> follows the same path as the OAM packet that i had sent to verify=20= >>>>> the >> data plane? >>>>=20 >>>> It's always desired, but it's hard, and most of time, no perfect = solution. >>>=20 >>> Sure the question is: Do we want to fix this? >>>=20 >>>>=20 >>>>>=20 >>>>> Will it work if i encapsulate both the OAM and the data traffic=20 >>>>> inside a GRE tunnel so that both use the same hashing fields? I=20 >>>>> may want to do this for certain flows where i want a very=20 >>>>> deterministic >> behavior. >>>>=20 >>>> Yes, use a tunnel to encapsulate both the OAM and the data traffic=20= >>>> is a >> candidate. >>>> But for a deployed network, such changes may not accepted, you=20 >>>> cannot change the existing deployment model. >>>=20 >>> We can look at the solution space later. >>>=20 >>> The first thing is -- Do we want to solve this issue? I would wager=20= >>> that its something that we would want to solve. Just want to hear=20 >>> what others think about this. >>>=20 >>> Cheers, Manav >>>=20 >>>>=20 >>>> Best regards, >>>> Mach >>>>=20 >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>>> detect a segment of the path, means the destination of the=20 >>>>>> S-BFD will be different from the user data. Then you described=20 >>>>>> situation will >> happen. >>>>>>=20 >>>>>> Best regards, >>>>>> Mach >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 >>>>>>> Manav Bhatia >>>>>>> Sent: Friday, May 09, 2014 4:02 PM >>>>>>> To: rtg-bfd@ietf.org >>>>>>> Subject: Problem with BFD with ECMP >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> There is a problem with how BFD/S-BFD works. >>>>>>>=20 >>>>>>> Sec 3.2 draft-aldrin-bfd-seamless-use-case-01 explains how we=20 >>>>>>> can use S-BFD to quickly validate the data plane before pushing=20= >>>>>>> the data >> out. >>>>>>>=20 >>>>>>> There is a potential issue here. >>>>>>>=20 >>>>>>> Assume I send an S-BFD ping and I get a pong back.I believe that=20= >>>>>>> the path is up and i start sending traffic towards the=20 >>>>>>> Reflector, brimming with confidence, since i believe the data = plane is up. >>>>>>>=20 >>>>>>> Assume that there is ECMP happening in the network somewhere >> that >>>>>>> splits the traffic to paths p1 and p2. >>>>>>>=20 >>>>>>> Its possible that the S-BFD packet gets hashed to the path p1,=20= >>>>>>> while the data traffic that i send gets hashed to path p2. >>>>>>>=20 >>>>>>> If path p2 is down (or is congested and drops packets), then i=20= >>>>>>> drop all traffic -- or some, in case of congestion. This however=20= >>>>>>> is unexpected since i always get 100% response for my S-BFD ping >> packets. >>>>>>>=20 >>>>>>> I understand that if path p2 is down (because of an issue in one=20= >>>>>>> of the nodes/links in the path), the ECMP path will not contain=20= >>>>>>> p2, since the routing protocols will naturally remove this from=20= >>>>>>> the >> ECMP list. >>>>>>> So, its only while the network is reconverging (which should=20 >>>>>>> only last for a few >>>>>>> secs) that we will see this. >>>>>>>=20 >>>>>>> Is my understanding correct? >>>>>>>=20 >>>>>>> If yes, then is the scenario where S-BFD and data traffic=20 >>>>>>> following different paths something that we want to look at=20 >>>>>>> fixing (either here or some other WG)? This problem has already=20= >>>>>>> been solved in the MPLS context with the Entropy label. I am=20 >>>>>>> talking specifically about non-MPLS >>>>> networks. >>>>>>>=20 >>>>>>> Cheers, Manav >>>>>>=20 >>>=20 >>=20 >> -- >>=20 >>=20 >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 From nobody Fri May 9 08:05:43 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB511A0024 for ; Fri, 9 May 2014 08:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iserdvXFSxl for ; Fri, 9 May 2014 08:05:34 -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 EF9601A0010 for ; Fri, 9 May 2014 08:05:22 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id wm4so5005594obc.32 for ; Fri, 09 May 2014 08:05:18 -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:content-transfer-encoding; bh=FndBmYybJU63ia2/HQDvAAJrHGFaMIOEt1R4+f0gQdQ=; b=LHD6r559+kU8vRuh9BE1b3/dKsCEsJQ33iAwGxMhwUxfnukstzPrwdrRVhDp42BzDA gRu31MPkNCyTDAaMR9WM2gVUrPDFsHYgJZFyHBNXhXbeR8ACWXhAXkskKApFkxKJNjJc PKY475kB5ZtXhtxjCykrit9cnWu4gAb3eb500nKfTXGoM7SN1KNFEKgsij9RQ7fEiKNv 0UvGwnQrxUbBJhYUN9oONyDg30HaYoZiZNs5MRAS2/DEy0bpv2iRHHf8yhZpWOWJ6YMf 9rWuzYTyRXHGOSRf1ABTpVSPkXmEDs3cwTroQPzaS92wGcUsSyJwrP2RFvpnuJ/CrlIW Rn3Q== MIME-Version: 1.0 X-Received: by 10.60.44.243 with SMTP id h19mr2984533oem.46.1399647917913; Fri, 09 May 2014 08:05:17 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Fri, 9 May 2014 08:05:17 -0700 (PDT) In-Reply-To: <945DB47F-1095-45E8-811A-63B6E8ED7A76@gmail.com> References: <536CB377.9010302@pi.nu> <7347100B5761DC41A166AC17F22DF1121B7ACA78@eusaamb103.ericsson.se> <945DB47F-1095-45E8-811A-63B6E8ED7A76@gmail.com> Date: Fri, 9 May 2014 20:35:17 +0530 Message-ID: Subject: Re: Problem with BFD with ECMP From: Manav Bhatia To: Sam Aldrin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/p1fF_2Y6wlZhTJUn6ABJWSSZC1s Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 15:05:37 -0000 Ok, my point about MPLS being more predictable was this: You slap on an EL to an OAM packet and it takes *some* path. Now, you if you slap on the same EL to the data traffic then it would too take the *same* path. So there is some level of determinism, which i stated was missing in pure IP. Cheers, Manav On Fri, May 9, 2014 at 8:24 PM, Sam Aldrin wrote: > Hi folks, > > As Greg said, EL/ELI cannot predict which packet takes which path. It is = only used to distribute flows of data packets, with an assumption that hash= ing will occur to utilize load balanced paths. > MPLS OAM cannot predict this either. That is why, as a vendor, one implem= ents various tools like trace, path trace etc. > I see it no different to non-MPLS networks either. > > As far as sec 3.2 of the use case document is concerned, S-BFD is not rep= lacing other OAM tools. It still performs cc checks. > Solving ECMP issue is a never ending and don=E2=80=99t see one either, un= less load balancing is standardized and all intermediate nodes confirmed to= that, IMHO. > Till that time we have to play hash tag=E2=80=99s. :D > > cheers > -sam > On May 9, 2014, at 7:46 AM, Gregory Mirsky = wrote: > >> Hi Nobo, et. al, >> I'm not sure that ELI/EL was intended to pin a flow to the particular EC= MP path. My understanding of EL is that it makes easier to distribute flows= , e.g. by assigning EL labels from label range N labels wide, [M, M+N] when= there are N available paths in an ECMP. I believe that there is no expecta= tion to predict with any level of certainty which particular path a flow wi= ll follow but only expectation that flow with EL M+2 will take different pa= th with flow tagged by EL M+3. Certainty is required though when ECMP is vi= ewed as a link, e.g. micro-BFD. >> >> Regards, >> Greg >> >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya = (nobo) >> Sent: Friday, May 09, 2014 5:37 AM >> To: Loa Andersson; Manav Bhatia; Mach Chen >> Cc: rtg-bfd@ietf.org >> Subject: RE: Problem with BFD with ECMP >> >> Hi Manav, Mach, Loa, >> >> On some data planes (ex: MPLS with Entropy Label), it's less difficult t= o use OAM packets to [likely] exercise specific ECMP paths as long as there= are ways to discover the entropies. >> >> On some others (ex: IP network), it's more difficult and I fully agree w= ith what Loa said. >> >> -Nobo >> >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Loa >>> Andersson >>> Sent: Friday, May 09, 2014 6:53 AM >>> To: Manav Bhatia; Mach Chen >>> Cc: rtg-bfd@ietf.org >>> Subject: Re: Problem with BFD with ECMP >>> >>> Mach and Manav, >>> >>> I guess that the answer to this type of question is somewhere around >>> "Is it worth doing?". If we see an easy way to fix it and we are >>> pretty sure that it will be deployed, then let us go ahead and do it. >>> If the fix is shady and no one really want it, then just leave it. >>> >>> No in those terms where are we? >>> >>> /Loa >>> >>> On 2014-05-09 12:12, Manav Bhatia wrote: >>>> Hi Mach, >>>> >>>>>> My point is this: >>>>>> >>>>>> How do i ensure that in an IP only network, my data traffic always >>>>>> follows the same path as the OAM packet that i had sent to verify >>>>>> the >>> data plane? >>>>> >>>>> It's always desired, but it's hard, and most of time, no perfect solu= tion. >>>> >>>> Sure the question is: Do we want to fix this? >>>> >>>>> >>>>>> >>>>>> Will it work if i encapsulate both the OAM and the data traffic >>>>>> inside a GRE tunnel so that both use the same hashing fields? I >>>>>> may want to do this for certain flows where i want a very >>>>>> deterministic >>> behavior. >>>>> >>>>> Yes, use a tunnel to encapsulate both the OAM and the data traffic >>>>> is a >>> candidate. >>>>> But for a deployed network, such changes may not accepted, you >>>>> cannot change the existing deployment model. >>>> >>>> We can look at the solution space later. >>>> >>>> The first thing is -- Do we want to solve this issue? I would wager >>>> that its something that we would want to solve. Just want to hear >>>> what others think about this. >>>> >>>> Cheers, Manav >>>> >>>>> >>>>> Best regards, >>>>> Mach >>>>> >>>>>> >>>>>> Cheers, Manav >>>>>> >>>>>>> detect a segment of the path, means the destination of the >>>>>>> S-BFD will be different from the user data. Then you described >>>>>>> situation will >>> happen. >>>>>>> >>>>>>> Best regards, >>>>>>> Mach >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of >>>>>>>> Manav Bhatia >>>>>>>> Sent: Friday, May 09, 2014 4:02 PM >>>>>>>> To: rtg-bfd@ietf.org >>>>>>>> Subject: Problem with BFD with ECMP >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> There is a problem with how BFD/S-BFD works. >>>>>>>> >>>>>>>> Sec 3.2 draft-aldrin-bfd-seamless-use-case-01 explains how we >>>>>>>> can use S-BFD to quickly validate the data plane before pushing >>>>>>>> the data >>> out. >>>>>>>> >>>>>>>> There is a potential issue here. >>>>>>>> >>>>>>>> Assume I send an S-BFD ping and I get a pong back.I believe that >>>>>>>> the path is up and i start sending traffic towards the >>>>>>>> Reflector, brimming with confidence, since i believe the data plan= e is up. >>>>>>>> >>>>>>>> Assume that there is ECMP happening in the network somewhere >>> that >>>>>>>> splits the traffic to paths p1 and p2. >>>>>>>> >>>>>>>> Its possible that the S-BFD packet gets hashed to the path p1, >>>>>>>> while the data traffic that i send gets hashed to path p2. >>>>>>>> >>>>>>>> If path p2 is down (or is congested and drops packets), then i >>>>>>>> drop all traffic -- or some, in case of congestion. This however >>>>>>>> is unexpected since i always get 100% response for my S-BFD ping >>> packets. >>>>>>>> >>>>>>>> I understand that if path p2 is down (because of an issue in one >>>>>>>> of the nodes/links in the path), the ECMP path will not contain >>>>>>>> p2, since the routing protocols will naturally remove this from >>>>>>>> the >>> ECMP list. >>>>>>>> So, its only while the network is reconverging (which should >>>>>>>> only last for a few >>>>>>>> secs) that we will see this. >>>>>>>> >>>>>>>> Is my understanding correct? >>>>>>>> >>>>>>>> If yes, then is the scenario where S-BFD and data traffic >>>>>>>> following different paths something that we want to look at >>>>>>>> fixing (either here or some other WG)? This problem has already >>>>>>>> been solved in the MPLS context with the Entropy label. I am >>>>>>>> talking specifically about non-MPLS >>>>>> networks. >>>>>>>> >>>>>>>> Cheers, Manav >>>>>>> >>>> >>> >>> -- >>> >>> >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> > From nobody Fri May 9 08:09:49 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46F91A002F for ; Fri, 9 May 2014 08:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saBrnSB0Kr8H for ; Fri, 9 May 2014 08:09:34 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 398421A001B for ; Fri, 9 May 2014 08:09:19 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-9e-536c9e0c58ba Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C5.65.02831.C0E9C635; Fri, 9 May 2014 11:21:17 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Fri, 9 May 2014 11:09:13 -0400 From: Gregory Mirsky To: Manav Bhatia , Sam Aldrin Subject: RE: Problem with BFD with ECMP Thread-Topic: Problem with BFD with ECMP Thread-Index: AQHPa10FR1gHtZZKvUKBKUPQtfY0Zps4MleAgAADoACAABFwAIAAAzCAgAALU4CAAB0VAP//3u0QgABHqoCAAALqgP//vSnw Date: Fri, 9 May 2014 15:09:12 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7ACB0A@eusaamb103.ericsson.se> References: <536CB377.9010302@pi.nu> <7347100B5761DC41A166AC17F22DF1121B7ACA78@eusaamb103.ericsson.se> <945DB47F-1095-45E8-811A-63B6E8ED7A76@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLonSpd3Xk6wwbG/zBYTWr8wWvybO4fZ 4sJaYYvLk9rYLWZ3xFt8/rON0YHNY8rvjaweO2fdZfdoOfKW1WPJkp9MHrOmt7EFsEZx2aSk 5mSWpRbp2yVwZcx8e4Wl4FNgxdpDq1kaGJ/4dzFyckgImEgs2rGHCcIWk7hwbz1bFyMXh5DA UUaJO6d3MEI4yxglps+6yQ5SxSZgJPFiYw+YLSLgI/H8xhlWkCJmgR5GiY4nbcwgCWEBdYnn 89+yQRRpSGyb0cQKYedJnLvVzQJiswioSNw7/pERxOYV8JXYu/MJC8S2SawSS2bMBNvAKRAo 8aD1KVgRI9B930+tAbuVWUBc4taT+VB3C0gs2XOeGcIWlXj5+B8rhK0kMef1NaA4B1C9psT6 XfoQrYoSU7ofskPsFZQ4OfMJywRGsVlIps5C6JiFpGMWko4FjCyrGDlKi1PLctONDDcxAiPt mASb4w7GBZ8sDzEKcDAq8fAuCM0OFmJNLCuuzD3EKM3BoiTOm/4pNlhIID2xJDU7NbUgtSi+ qDQntfgQIxMHp1QDo8DifXxTN1sdebXyqGiOjpDZhuMruws7Bfhn2DSGXND7fEUqZ5JFWd26 6quHlWYLvdd8HrUkurR3f5XlP16VRT+i/I/dK9FYUTPfpmDmS5+NOj5Pm6Sar1/ewDFpYx1D bP2XX2uCj+TZ33igkul2K/iZzOxEwUC+VdPlyv7JGXck/2NaFRj4XomlOCPRUIu5qDgRALvj 42CVAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/XI8Dbvi1TsHhBEWnD0Fm4EdOK-I Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 15:09:38 -0000 SGkgTWFuYXYsDQp5ZXMsIHRoZXJlJ3MgcHJvYmxlbSB3aXRoIHNhdGlzZnlpbmcgImluLWJhbmQi IHJlcXVpcmVtZW50IGZvciBJUCBPQU0uIEkgcmVjYWxsIHRoYXQgTm9ibyBhbmQgSSBoYWQgZGlz Y3Vzc2VkIGl0IHRob3VnaCBicmllZmx5IGFuZCBhZ3JlZWQgdGhhdCBpZiAiaW4tYmFuZCIgT0FN IHJlcXVpcmVtZW50IGlzIGluZGVlZCBzdHJvbmcgdGhlbiBoYXNoaW5nIHNob3VsZCBub3QgdXNl IHBvcnQgbnVtYmVycywgZS5nLiBiZSBiYXNlZCBvbiBJUCBTQS9EQS4NCg0KCVJlZ2FyZHMsDQoJ CUdyZWcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hbmF2IEJoYXRpYSBb bWFpbHRvOm1hbmF2YmhhdGlhQGdtYWlsLmNvbV0gDQpTZW50OiBGcmlkYXksIE1heSAwOSwgMjAx NCA4OjA1IEFNDQpUbzogU2FtIEFsZHJpbg0KQ2M6IEdyZWdvcnkgTWlyc2t5OyBOb2JvIEFraXlh IChub2JvKTsgbG9hQHBpLm51OyBNYWNoIENoZW47IHJ0Zy1iZmRAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBQcm9ibGVtIHdpdGggQkZEIHdpdGggRUNNUA0KDQpPaywgbXkgcG9pbnQgYWJvdXQgTVBM UyBiZWluZyBtb3JlIHByZWRpY3RhYmxlIHdhcyB0aGlzOg0KDQpZb3Ugc2xhcCBvbiBhbiBFTCB0 byBhbiBPQU0gcGFja2V0IGFuZCBpdCB0YWtlcyAqc29tZSogcGF0aC4gTm93LCB5b3UgaWYgeW91 IHNsYXAgb24gdGhlIHNhbWUgRUwgdG8gdGhlIGRhdGEgdHJhZmZpYyB0aGVuIGl0IHdvdWxkIHRv byB0YWtlIHRoZSAqc2FtZSogcGF0aC4gU28gdGhlcmUgaXMgc29tZSBsZXZlbCBvZiBkZXRlcm1p bmlzbSwgd2hpY2ggaSBzdGF0ZWQgd2FzIG1pc3NpbmcgaW4gcHVyZSBJUC4NCg0KQ2hlZXJzLCBN YW5hdg0KDQpPbiBGcmksIE1heSA5LCAyMDE0IGF0IDg6MjQgUE0sIFNhbSBBbGRyaW4gPGFsZHJp bi5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+IEhpIGZvbGtzLA0KPg0KPiBBcyBHcmVnIHNhaWQs IEVML0VMSSBjYW5ub3QgcHJlZGljdCB3aGljaCBwYWNrZXQgdGFrZXMgd2hpY2ggcGF0aC4gSXQg aXMgb25seSB1c2VkIHRvIGRpc3RyaWJ1dGUgZmxvd3Mgb2YgZGF0YSBwYWNrZXRzLCB3aXRoIGFu IGFzc3VtcHRpb24gdGhhdCBoYXNoaW5nIHdpbGwgb2NjdXIgdG8gdXRpbGl6ZSBsb2FkIGJhbGFu Y2VkIHBhdGhzLg0KPiBNUExTIE9BTSBjYW5ub3QgcHJlZGljdCB0aGlzIGVpdGhlci4gVGhhdCBp cyB3aHksIGFzIGEgdmVuZG9yLCBvbmUgaW1wbGVtZW50cyB2YXJpb3VzIHRvb2xzIGxpa2UgdHJh Y2UsIHBhdGggdHJhY2UgZXRjLg0KPiBJIHNlZSBpdCBubyBkaWZmZXJlbnQgdG8gbm9uLU1QTFMg bmV0d29ya3MgZWl0aGVyLg0KPg0KPiBBcyBmYXIgYXMgc2VjIDMuMiBvZiB0aGUgdXNlIGNhc2Ug ZG9jdW1lbnQgaXMgY29uY2VybmVkLCBTLUJGRCBpcyBub3QgcmVwbGFjaW5nIG90aGVyIE9BTSB0 b29scy4gSXQgc3RpbGwgcGVyZm9ybXMgY2MgY2hlY2tzLg0KPiBTb2x2aW5nIEVDTVAgaXNzdWUg aXMgYSBuZXZlciBlbmRpbmcgYW5kIGRvbuKAmXQgc2VlIG9uZSBlaXRoZXIsIHVubGVzcyBsb2Fk IGJhbGFuY2luZyBpcyBzdGFuZGFyZGl6ZWQgYW5kIGFsbCBpbnRlcm1lZGlhdGUgbm9kZXMgY29u ZmlybWVkIHRvIHRoYXQsIElNSE8uDQo+IFRpbGwgdGhhdCB0aW1lIHdlIGhhdmUgdG8gcGxheSBo YXNoIHRhZ+KAmXMuIDpEDQo+DQo+IGNoZWVycw0KPiAtc2FtDQo+IE9uIE1heSA5LCAyMDE0LCBh dCA3OjQ2IEFNLCBHcmVnb3J5IE1pcnNreSA8Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPiB3 cm90ZToNCj4NCj4+IEhpIE5vYm8sIGV0LiBhbCwNCj4+IEknbSBub3Qgc3VyZSB0aGF0IEVMSS9F TCB3YXMgaW50ZW5kZWQgdG8gcGluIGEgZmxvdyB0byB0aGUgcGFydGljdWxhciBFQ01QIHBhdGgu IE15IHVuZGVyc3RhbmRpbmcgb2YgRUwgaXMgdGhhdCBpdCBtYWtlcyBlYXNpZXIgdG8gZGlzdHJp YnV0ZSBmbG93cywgZS5nLiBieSBhc3NpZ25pbmcgRUwgbGFiZWxzIGZyb20gbGFiZWwgcmFuZ2Ug TiBsYWJlbHMgd2lkZSwgW00sIE0rTl0gd2hlbiB0aGVyZSBhcmUgTiBhdmFpbGFibGUgcGF0aHMg aW4gYW4gRUNNUC4gSSBiZWxpZXZlIHRoYXQgdGhlcmUgaXMgbm8gZXhwZWN0YXRpb24gdG8gcHJl ZGljdCB3aXRoIGFueSBsZXZlbCBvZiBjZXJ0YWludHkgd2hpY2ggcGFydGljdWxhciBwYXRoIGEg ZmxvdyB3aWxsIGZvbGxvdyBidXQgb25seSBleHBlY3RhdGlvbiB0aGF0IGZsb3cgd2l0aCBFTCBN KzIgd2lsbCB0YWtlIGRpZmZlcmVudCBwYXRoIHdpdGggZmxvdyB0YWdnZWQgYnkgRUwgTSszLiBD ZXJ0YWludHkgaXMgcmVxdWlyZWQgdGhvdWdoIHdoZW4gRUNNUCBpcyB2aWV3ZWQgYXMgYSBsaW5r LCBlLmcuIG1pY3JvLUJGRC4NCj4+DQo+PiAgICAgICBSZWdhcmRzLA0KPj4gICAgICAgICAgICAg ICBHcmVnDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFJ0Zy1i ZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOb2JvIA0K Pj4gQWtpeWEgKG5vYm8pDQo+PiBTZW50OiBGcmlkYXksIE1heSAwOSwgMjAxNCA1OjM3IEFNDQo+ PiBUbzogTG9hIEFuZGVyc3NvbjsgTWFuYXYgQmhhdGlhOyBNYWNoIENoZW4NCj4+IENjOiBydGct YmZkQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSRTogUHJvYmxlbSB3aXRoIEJGRCB3aXRoIEVDTVAN Cj4+DQo+PiBIaSBNYW5hdiwgTWFjaCwgTG9hLA0KPj4NCj4+IE9uIHNvbWUgZGF0YSBwbGFuZXMg KGV4OiBNUExTIHdpdGggRW50cm9weSBMYWJlbCksIGl0J3MgbGVzcyBkaWZmaWN1bHQgdG8gdXNl IE9BTSBwYWNrZXRzIHRvIFtsaWtlbHldIGV4ZXJjaXNlIHNwZWNpZmljIEVDTVAgcGF0aHMgYXMg bG9uZyBhcyB0aGVyZSBhcmUgd2F5cyB0byBkaXNjb3ZlciB0aGUgZW50cm9waWVzLg0KPj4NCj4+ IE9uIHNvbWUgb3RoZXJzIChleDogSVAgbmV0d29yayksIGl0J3MgbW9yZSBkaWZmaWN1bHQgYW5k IEkgZnVsbHkgYWdyZWUgd2l0aCB3aGF0IExvYSBzYWlkLg0KPj4NCj4+IC1Ob2JvDQo+Pg0KPj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0 Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvYSANCj4+PiBBbmRlcnNzb24N Cj4+PiBTZW50OiBGcmlkYXksIE1heSAwOSwgMjAxNCA2OjUzIEFNDQo+Pj4gVG86IE1hbmF2IEJo YXRpYTsgTWFjaCBDaGVuDQo+Pj4gQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBS ZTogUHJvYmxlbSB3aXRoIEJGRCB3aXRoIEVDTVANCj4+Pg0KPj4+IE1hY2ggYW5kIE1hbmF2LA0K Pj4+DQo+Pj4gSSBndWVzcyB0aGF0IHRoZSBhbnN3ZXIgdG8gdGhpcyB0eXBlIG9mIHF1ZXN0aW9u IGlzIHNvbWV3aGVyZSBhcm91bmQgDQo+Pj4gIklzIGl0IHdvcnRoIGRvaW5nPyIuIElmIHdlIHNl ZSBhbiBlYXN5IHdheSB0byBmaXggaXQgYW5kIHdlIGFyZSANCj4+PiBwcmV0dHkgc3VyZSB0aGF0 IGl0IHdpbGwgYmUgZGVwbG95ZWQsIHRoZW4gbGV0IHVzIGdvIGFoZWFkIGFuZCBkbyBpdC4NCj4+ PiBJZiB0aGUgZml4IGlzIHNoYWR5IGFuZCBubyBvbmUgcmVhbGx5IHdhbnQgaXQsIHRoZW4ganVz dCBsZWF2ZSBpdC4NCj4+Pg0KPj4+IE5vIGluIHRob3NlIHRlcm1zIHdoZXJlIGFyZSB3ZT8NCj4+ Pg0KPj4+IC9Mb2ENCj4+Pg0KPj4+IE9uIDIwMTQtMDUtMDkgMTI6MTIsIE1hbmF2IEJoYXRpYSB3 cm90ZToNCj4+Pj4gSGkgTWFjaCwNCj4+Pj4NCj4+Pj4+PiBNeSBwb2ludCBpcyB0aGlzOg0KPj4+ Pj4+DQo+Pj4+Pj4gSG93IGRvIGkgZW5zdXJlIHRoYXQgaW4gYW4gSVAgb25seSBuZXR3b3JrLCBt eSBkYXRhIHRyYWZmaWMgDQo+Pj4+Pj4gYWx3YXlzIGZvbGxvd3MgdGhlIHNhbWUgcGF0aCBhcyB0 aGUgT0FNIHBhY2tldCB0aGF0IGkgaGFkIHNlbnQgdG8gDQo+Pj4+Pj4gdmVyaWZ5IHRoZQ0KPj4+ IGRhdGEgcGxhbmU/DQo+Pj4+Pg0KPj4+Pj4gSXQncyBhbHdheXMgZGVzaXJlZCwgYnV0IGl0J3Mg aGFyZCwgYW5kIG1vc3Qgb2YgdGltZSwgbm8gcGVyZmVjdCBzb2x1dGlvbi4NCj4+Pj4NCj4+Pj4g U3VyZSB0aGUgcXVlc3Rpb24gaXM6IERvIHdlIHdhbnQgdG8gZml4IHRoaXM/DQo+Pj4+DQo+Pj4+ Pg0KPj4+Pj4+DQo+Pj4+Pj4gV2lsbCBpdCB3b3JrIGlmIGkgZW5jYXBzdWxhdGUgYm90aCB0aGUg T0FNIGFuZCB0aGUgZGF0YSB0cmFmZmljIA0KPj4+Pj4+IGluc2lkZSBhIEdSRSB0dW5uZWwgc28g dGhhdCBib3RoIHVzZSB0aGUgc2FtZSBoYXNoaW5nIGZpZWxkcz8gSSANCj4+Pj4+PiBtYXkgd2Fu dCB0byBkbyB0aGlzIGZvciBjZXJ0YWluIGZsb3dzIHdoZXJlIGkgd2FudCBhIHZlcnkgDQo+Pj4+ Pj4gZGV0ZXJtaW5pc3RpYw0KPj4+IGJlaGF2aW9yLg0KPj4+Pj4NCj4+Pj4+IFllcywgdXNlIGEg dHVubmVsIHRvIGVuY2Fwc3VsYXRlIGJvdGggdGhlIE9BTSBhbmQgdGhlIGRhdGEgdHJhZmZpYyAN Cj4+Pj4+IGlzIGENCj4+PiBjYW5kaWRhdGUuDQo+Pj4+PiBCdXQgZm9yIGEgZGVwbG95ZWQgbmV0 d29yaywgc3VjaCBjaGFuZ2VzIG1heSBub3QgYWNjZXB0ZWQsIHlvdSANCj4+Pj4+IGNhbm5vdCBj aGFuZ2UgdGhlIGV4aXN0aW5nIGRlcGxveW1lbnQgbW9kZWwuDQo+Pj4+DQo+Pj4+IFdlIGNhbiBs b29rIGF0IHRoZSBzb2x1dGlvbiBzcGFjZSBsYXRlci4NCj4+Pj4NCj4+Pj4gVGhlIGZpcnN0IHRo aW5nIGlzIC0tIERvIHdlIHdhbnQgdG8gc29sdmUgdGhpcyBpc3N1ZT8gSSB3b3VsZCB3YWdlciAN Cj4+Pj4gdGhhdCBpdHMgc29tZXRoaW5nIHRoYXQgd2Ugd291bGQgd2FudCB0byBzb2x2ZS4gSnVz dCB3YW50IHRvIGhlYXIgDQo+Pj4+IHdoYXQgb3RoZXJzIHRoaW5rIGFib3V0IHRoaXMuDQo+Pj4+ DQo+Pj4+IENoZWVycywgTWFuYXYNCj4+Pj4NCj4+Pj4+DQo+Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+ Pj4+PiBNYWNoDQo+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gQ2hlZXJzLCBNYW5hdg0KPj4+Pj4+DQo+ Pj4+Pj4+ICBkZXRlY3QgYSBzZWdtZW50IG9mIHRoZSBwYXRoLCBtZWFucyB0aGUgZGVzdGluYXRp b24gb2YgdGhlIA0KPj4+Pj4+PiBTLUJGRCB3aWxsIGJlIGRpZmZlcmVudCBmcm9tIHRoZSB1c2Vy IGRhdGEuIFRoZW4geW91IGRlc2NyaWJlZCANCj4+Pj4+Pj4gc2l0dWF0aW9uIHdpbGwNCj4+PiBo YXBwZW4uDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEJlc3QgcmVnYXJkcywNCj4+Pj4+Pj4gTWFjaA0KPj4+ Pj4+Pg0KPj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+IEZyb206 IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiAN Cj4+Pj4+Pj4+IE1hbmF2IEJoYXRpYQ0KPj4+Pj4+Pj4gU2VudDogRnJpZGF5LCBNYXkgMDksIDIw MTQgNDowMiBQTQ0KPj4+Pj4+Pj4gVG86IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4+Pj4+Pj4+IFN1Ympl Y3Q6IFByb2JsZW0gd2l0aCBCRkQgd2l0aCBFQ01QDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gSGksDQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhlcmUgaXMgYSBwcm9ibGVtIHdpdGggaG93IEJGRC9TLUJGRCB3 b3Jrcy4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBTZWMgMy4yIGRyYWZ0LWFsZHJpbi1iZmQtc2VhbWxl c3MtdXNlLWNhc2UtMDEgZXhwbGFpbnMgaG93IHdlIA0KPj4+Pj4+Pj4gY2FuIHVzZSBTLUJGRCB0 byBxdWlja2x5IHZhbGlkYXRlIHRoZSBkYXRhIHBsYW5lIGJlZm9yZSBwdXNoaW5nIA0KPj4+Pj4+ Pj4gdGhlIGRhdGENCj4+PiBvdXQuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhlcmUgaXMgYSBwb3Rl bnRpYWwgaXNzdWUgaGVyZS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBBc3N1bWUgSSBzZW5kIGFuIFMt QkZEIHBpbmcgYW5kIEkgZ2V0IGEgcG9uZyBiYWNrLkkgYmVsaWV2ZSANCj4+Pj4+Pj4+IHRoYXQg dGhlIHBhdGggaXMgdXAgYW5kIGkgc3RhcnQgc2VuZGluZyB0cmFmZmljIHRvd2FyZHMgdGhlIA0K Pj4+Pj4+Pj4gUmVmbGVjdG9yLCBicmltbWluZyB3aXRoIGNvbmZpZGVuY2UsIHNpbmNlIGkgYmVs aWV2ZSB0aGUgZGF0YSBwbGFuZSBpcyB1cC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBBc3N1bWUgdGhh dCB0aGVyZSBpcyBFQ01QIGhhcHBlbmluZyBpbiB0aGUgbmV0d29yayBzb21ld2hlcmUNCj4+PiB0 aGF0DQo+Pj4+Pj4+PiBzcGxpdHMgdGhlIHRyYWZmaWMgdG8gcGF0aHMgcDEgYW5kIHAyLg0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+IEl0cyBwb3NzaWJsZSB0aGF0IHRoZSBTLUJGRCBwYWNrZXQgZ2V0cyBo YXNoZWQgdG8gdGhlIHBhdGggcDEsIA0KPj4+Pj4+Pj4gd2hpbGUgdGhlIGRhdGEgdHJhZmZpYyB0 aGF0IGkgc2VuZCBnZXRzIGhhc2hlZCB0byBwYXRoIHAyLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IElm IHBhdGggcDIgaXMgZG93biAob3IgaXMgY29uZ2VzdGVkIGFuZCBkcm9wcyBwYWNrZXRzKSwgdGhl biBpIA0KPj4+Pj4+Pj4gZHJvcCBhbGwgdHJhZmZpYyAtLSBvciBzb21lLCBpbiBjYXNlIG9mIGNv bmdlc3Rpb24uIFRoaXMgDQo+Pj4+Pj4+PiBob3dldmVyIGlzIHVuZXhwZWN0ZWQgc2luY2UgaSBh bHdheXMgZ2V0IDEwMCUgcmVzcG9uc2UgZm9yIG15IA0KPj4+Pj4+Pj4gUy1CRkQgcGluZw0KPj4+ IHBhY2tldHMuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gSSB1bmRlcnN0YW5kIHRoYXQgaWYgcGF0aCBw MiBpcyBkb3duIChiZWNhdXNlIG9mIGFuIGlzc3VlIGluIA0KPj4+Pj4+Pj4gb25lIG9mIHRoZSBu b2Rlcy9saW5rcyBpbiB0aGUgcGF0aCksIHRoZSBFQ01QIHBhdGggd2lsbCBub3QgDQo+Pj4+Pj4+ PiBjb250YWluIHAyLCBzaW5jZSB0aGUgcm91dGluZyBwcm90b2NvbHMgd2lsbCBuYXR1cmFsbHkg cmVtb3ZlIA0KPj4+Pj4+Pj4gdGhpcyBmcm9tIHRoZQ0KPj4+IEVDTVAgbGlzdC4NCj4+Pj4+Pj4+ IFNvLCBpdHMgb25seSB3aGlsZSB0aGUgbmV0d29yayBpcyByZWNvbnZlcmdpbmcgKHdoaWNoIHNo b3VsZCANCj4+Pj4+Pj4+IG9ubHkgbGFzdCBmb3IgYSBmZXcNCj4+Pj4+Pj4+IHNlY3MpIHRoYXQg d2Ugd2lsbCBzZWUgdGhpcy4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBJcyBteSB1bmRlcnN0YW5kaW5n IGNvcnJlY3Q/DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gSWYgeWVzLCB0aGVuIGlzIHRoZSBzY2VuYXJp byB3aGVyZSBTLUJGRCBhbmQgZGF0YSB0cmFmZmljIA0KPj4+Pj4+Pj4gZm9sbG93aW5nIGRpZmZl cmVudCBwYXRocyBzb21ldGhpbmcgdGhhdCB3ZSB3YW50IHRvIGxvb2sgYXQgDQo+Pj4+Pj4+PiBm aXhpbmcgKGVpdGhlciBoZXJlIG9yIHNvbWUgb3RoZXIgV0cpPyBUaGlzIHByb2JsZW0gaGFzIGFs cmVhZHkgDQo+Pj4+Pj4+PiBiZWVuIHNvbHZlZCBpbiB0aGUgTVBMUyBjb250ZXh0IHdpdGggdGhl IEVudHJvcHkgbGFiZWwuIEkgYW0gDQo+Pj4+Pj4+PiB0YWxraW5nIHNwZWNpZmljYWxseSBhYm91 dCBub24tTVBMUw0KPj4+Pj4+IG5ldHdvcmtzLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IENoZWVycywg TWFuYXYNCj4+Pj4+Pj4NCj4+Pj4NCj4+Pg0KPj4+IC0tDQo+Pj4NCj4+Pg0KPj4+IExvYSBBbmRl cnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29t DQo+Pj4gU2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGku bnUNCj4+PiBIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3 MzkgODEgMjEgNjQNCj4+DQo+DQo= From nobody Fri May 9 08:10:58 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC44C1A02EA for ; Fri, 9 May 2014 08:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq5ZzpcqcCpx for ; Fri, 9 May 2014 08:10:48 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1C25C1A02D4 for ; Fri, 9 May 2014 08:10:34 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id v10so3766415pde.41 for ; Fri, 09 May 2014 08:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uIS25+Zky25XP3F0PakM/aXKe7kxZEwZm03XaenAnlU=; b=RRVTlSD6hdHQS/vU8lKGaUFUBpeAaCaQnHt1XuDtKAZt87jnt+jh3suXeQsYreEOAh IDico20FR9axyCZS/5WY9zjcnJBjPmXh4MwAJBapOtLbw7w3iRuQAasKhV7Nh93ESVYr aL2JZG6P6tWovQ7BDZ5ROo9GoypN7ujR+LNoUXT2tlh2iM6qOtawUCSyoxZ9U08/8+ys 5jK8lvnlRDhB8Dwy7sbHIS8myhxQqDliHJo7+6cvH8mjrkWd7UjN4+7ZdIiZ4Rvv7a9K uIUQgkN6sFnxOri/K3/1OJpsgJY5g/aGiS5VCgvltNGZUYoDmp8LzUq8xskQA4Lcilc0 plrw== X-Received: by 10.67.15.42 with SMTP id fl10mr21759702pad.30.1399648229292; Fri, 09 May 2014 08:10:29 -0700 (PDT) Received: from [192.168.1.7] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id bs17sm9156237pac.28.2014.05.09.08.10.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 May 2014 08:10:28 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Problem with BFD with ECMP From: Sam Aldrin In-Reply-To: Date: Fri, 9 May 2014 08:10:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4D72B947-2BEE-4EDC-BFB1-6BB7B65A93C5@gmail.com> References: <536CB377.9010302@pi.nu> <7347100B5761DC41A166AC17F22DF1121B7ACA78@eusaamb103.ericsson.se> <945DB47F-1095-45E8-811A-63B6E8ED7A76@gmail.com> To: Manav Bhatia X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ISnvLOxZudoIvgFf19UlWCK5zT0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 15:10:56 -0000 Yes and no.=20 What if the man in the middle only performs load balance with 3 label = stack depth + ip HDR + udp port number (EL is beyond 3 lbl stack depth). = The behavior of OAM packet differs from data packet. There is some flexibility in MPLS / MPLS OAM (destn IP addr &&// EL) but = not deterministic though. We don=92t in IP or BFD -sam On May 9, 2014, at 8:05 AM, Manav Bhatia wrote: > Ok, my point about MPLS being more predictable was this: >=20 > You slap on an EL to an OAM packet and it takes *some* path. Now, you > if you slap on the same EL to the data traffic then it would too take > the *same* path. So there is some level of determinism, which i stated > was missing in pure IP. >=20 > Cheers, Manav >=20 > On Fri, May 9, 2014 at 8:24 PM, Sam Aldrin = wrote: >> Hi folks, >>=20 >> As Greg said, EL/ELI cannot predict which packet takes which path. It = is only used to distribute flows of data packets, with an assumption = that hashing will occur to utilize load balanced paths. >> MPLS OAM cannot predict this either. That is why, as a vendor, one = implements various tools like trace, path trace etc. >> I see it no different to non-MPLS networks either. >>=20 >> As far as sec 3.2 of the use case document is concerned, S-BFD is not = replacing other OAM tools. It still performs cc checks. >> Solving ECMP issue is a never ending and don=92t see one either, = unless load balancing is standardized and all intermediate nodes = confirmed to that, IMHO. >> Till that time we have to play hash tag=92s. :D >>=20 >> cheers >> -sam >> On May 9, 2014, at 7:46 AM, Gregory Mirsky = wrote: >>=20 >>> Hi Nobo, et. al, >>> I'm not sure that ELI/EL was intended to pin a flow to the = particular ECMP path. My understanding of EL is that it makes easier to = distribute flows, e.g. by assigning EL labels from label range N labels = wide, [M, M+N] when there are N available paths in an ECMP. I believe = that there is no expectation to predict with any level of certainty = which particular path a flow will follow but only expectation that flow = with EL M+2 will take different path with flow tagged by EL M+3. = Certainty is required though when ECMP is viewed as a link, e.g. = micro-BFD. >>>=20 >>> Regards, >>> Greg >>>=20 >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo = Akiya (nobo) >>> Sent: Friday, May 09, 2014 5:37 AM >>> To: Loa Andersson; Manav Bhatia; Mach Chen >>> Cc: rtg-bfd@ietf.org >>> Subject: RE: Problem with BFD with ECMP >>>=20 >>> Hi Manav, Mach, Loa, >>>=20 >>> On some data planes (ex: MPLS with Entropy Label), it's less = difficult to use OAM packets to [likely] exercise specific ECMP paths as = long as there are ways to discover the entropies. >>>=20 >>> On some others (ex: IP network), it's more difficult and I fully = agree with what Loa said. >>>=20 >>> -Nobo >>>=20 >>>> -----Original Message----- >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Loa >>>> Andersson >>>> Sent: Friday, May 09, 2014 6:53 AM >>>> To: Manav Bhatia; Mach Chen >>>> Cc: rtg-bfd@ietf.org >>>> Subject: Re: Problem with BFD with ECMP >>>>=20 >>>> Mach and Manav, >>>>=20 >>>> I guess that the answer to this type of question is somewhere = around >>>> "Is it worth doing?". If we see an easy way to fix it and we are >>>> pretty sure that it will be deployed, then let us go ahead and do = it. >>>> If the fix is shady and no one really want it, then just leave it. >>>>=20 >>>> No in those terms where are we? >>>>=20 >>>> /Loa >>>>=20 >>>> On 2014-05-09 12:12, Manav Bhatia wrote: >>>>> Hi Mach, >>>>>=20 >>>>>>> My point is this: >>>>>>>=20 >>>>>>> How do i ensure that in an IP only network, my data traffic = always >>>>>>> follows the same path as the OAM packet that i had sent to = verify >>>>>>> the >>>> data plane? >>>>>>=20 >>>>>> It's always desired, but it's hard, and most of time, no perfect = solution. >>>>>=20 >>>>> Sure the question is: Do we want to fix this? >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Will it work if i encapsulate both the OAM and the data traffic >>>>>>> inside a GRE tunnel so that both use the same hashing fields? I >>>>>>> may want to do this for certain flows where i want a very >>>>>>> deterministic >>>> behavior. >>>>>>=20 >>>>>> Yes, use a tunnel to encapsulate both the OAM and the data = traffic >>>>>> is a >>>> candidate. >>>>>> But for a deployed network, such changes may not accepted, you >>>>>> cannot change the existing deployment model. >>>>>=20 >>>>> We can look at the solution space later. >>>>>=20 >>>>> The first thing is -- Do we want to solve this issue? I would = wager >>>>> that its something that we would want to solve. Just want to hear >>>>> what others think about this. >>>>>=20 >>>>> Cheers, Manav >>>>>=20 >>>>>>=20 >>>>>> Best regards, >>>>>> Mach >>>>>>=20 >>>>>>>=20 >>>>>>> Cheers, Manav >>>>>>>=20 >>>>>>>> detect a segment of the path, means the destination of the >>>>>>>> S-BFD will be different from the user data. Then you described >>>>>>>> situation will >>>> happen. >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>> Mach >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of >>>>>>>>> Manav Bhatia >>>>>>>>> Sent: Friday, May 09, 2014 4:02 PM >>>>>>>>> To: rtg-bfd@ietf.org >>>>>>>>> Subject: Problem with BFD with ECMP >>>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> There is a problem with how BFD/S-BFD works. >>>>>>>>>=20 >>>>>>>>> Sec 3.2 draft-aldrin-bfd-seamless-use-case-01 explains how we >>>>>>>>> can use S-BFD to quickly validate the data plane before = pushing >>>>>>>>> the data >>>> out. >>>>>>>>>=20 >>>>>>>>> There is a potential issue here. >>>>>>>>>=20 >>>>>>>>> Assume I send an S-BFD ping and I get a pong back.I believe = that >>>>>>>>> the path is up and i start sending traffic towards the >>>>>>>>> Reflector, brimming with confidence, since i believe the data = plane is up. >>>>>>>>>=20 >>>>>>>>> Assume that there is ECMP happening in the network somewhere >>>> that >>>>>>>>> splits the traffic to paths p1 and p2. >>>>>>>>>=20 >>>>>>>>> Its possible that the S-BFD packet gets hashed to the path p1, >>>>>>>>> while the data traffic that i send gets hashed to path p2. >>>>>>>>>=20 >>>>>>>>> If path p2 is down (or is congested and drops packets), then i >>>>>>>>> drop all traffic -- or some, in case of congestion. This = however >>>>>>>>> is unexpected since i always get 100% response for my S-BFD = ping >>>> packets. >>>>>>>>>=20 >>>>>>>>> I understand that if path p2 is down (because of an issue in = one >>>>>>>>> of the nodes/links in the path), the ECMP path will not = contain >>>>>>>>> p2, since the routing protocols will naturally remove this = from >>>>>>>>> the >>>> ECMP list. >>>>>>>>> So, its only while the network is reconverging (which should >>>>>>>>> only last for a few >>>>>>>>> secs) that we will see this. >>>>>>>>>=20 >>>>>>>>> Is my understanding correct? >>>>>>>>>=20 >>>>>>>>> If yes, then is the scenario where S-BFD and data traffic >>>>>>>>> following different paths something that we want to look at >>>>>>>>> fixing (either here or some other WG)? This problem has = already >>>>>>>>> been solved in the MPLS context with the Entropy label. I am >>>>>>>>> talking specifically about non-MPLS >>>>>>> networks. >>>>>>>>>=20 >>>>>>>>> Cheers, Manav >>>>>>>>=20 >>>>>=20 >>>>=20 >>>> -- >>>>=20 >>>>=20 >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>=20 >>=20 From nobody Fri May 9 09:54:06 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E97B1A02A2 for ; Fri, 9 May 2014 09:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3UaSCeDPi3T for ; Fri, 9 May 2014 09:53:57 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF5B1A0083 for ; Fri, 9 May 2014 09:53:57 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) with Microsoft SMTP Server (TLS) id 15.0.934.12; Fri, 9 May 2014 16:53:50 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0934.000; Fri, 9 May 2014 16:53:50 +0000 From: John E Drake To: Gregory Mirsky , "Nobo Akiya (nobo)" , Loa Andersson , Manav Bhatia , Mach Chen Subject: RE: Problem with BFD with ECMP Thread-Topic: Problem with BFD with ECMP Thread-Index: AQHPa10qii8Co2K1/kyctSJEs2tlIJs370iAgAADoQCAABFvAIAAAzGAgAALU4CAAB0VAIAAJGGAgAAitOA= Date: Fri, 9 May 2014 16:53:49 +0000 Message-ID: <6bca320c5bdd4b828a5318e526d12889@BLUPR05MB562.namprd05.prod.outlook.com> References: <536CB377.9010302@pi.nu> <7347100B5761DC41A166AC17F22DF1121B7ACA78@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7ACA78@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(13464003)(377424004)(252514010)(51704005)(377454003)(199002)(189002)(54356999)(77982001)(64706001)(76176999)(80022001)(50986999)(2656002)(33646001)(81542001)(87936001)(81342001)(21056001)(20776003)(66066001)(77096999)(101416001)(83322001)(46102001)(76482001)(85852003)(86362001)(83072002)(74662001)(19580405001)(4396001)(74502001)(92566001)(31966008)(19580395003)(79102001)(74316001)(99286001)(76576001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB562; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/vUvfDtyOt_yOgHp8JaGEaXF4m0A Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 16:54:02 -0000 R3JlZywNCg0KUkZDIDQzNzkgd2l0aCBOb2JvJ3MgdXBkYXRlcyB3aWxsIHRlbGwgeW91IGEgcmFu Z2Ugb2YgbGFiZWxzIHRoYXQgY2FuIGJlIHVzZWQgdG8gY2F1c2UgYW4gTVBMUyBwYWNrZXQgdG8g dGFrZSBhIHBhcnRpY3VsYXIgRUNNUCBwYXRoLiAgUHV0dGluZyBhbnkgbGFiZWwgZnJvbSB0aGF0 IHJhbmdlIG9uIGEgcGFja2V0IHdpbGwgZm9yY2UgaXQgdG8gdGFrZSB0aGF0IHBhdGguIA0KDQpZ b3VycyBJcnJlc3BlY3RpdmVseSwNCg0KSm9obg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBHcmVnb3J5IE1pcnNreQ0KPiBTZW50OiBGcmlkYXksIE1heSAwOSwgMjAxNCA3 OjQ3IEFNDQo+IFRvOiBOb2JvIEFraXlhIChub2JvKTsgTG9hIEFuZGVyc3NvbjsgTWFuYXYgQmhh dGlhOyBNYWNoIENoZW4NCj4gQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFBy b2JsZW0gd2l0aCBCRkQgd2l0aCBFQ01QDQo+IA0KPiBIaSBOb2JvLCBldC4gYWwsDQo+IEknbSBu b3Qgc3VyZSB0aGF0IEVMSS9FTCB3YXMgaW50ZW5kZWQgdG8gcGluIGEgZmxvdyB0byB0aGUgcGFy dGljdWxhciBFQ01QDQo+IHBhdGguIE15IHVuZGVyc3RhbmRpbmcgb2YgRUwgaXMgdGhhdCBpdCBt YWtlcyBlYXNpZXIgdG8gZGlzdHJpYnV0ZSBmbG93cywgZS5nLiBieQ0KPiBhc3NpZ25pbmcgRUwg bGFiZWxzIGZyb20gbGFiZWwgcmFuZ2UgTiBsYWJlbHMgd2lkZSwgW00sIE0rTl0gd2hlbiB0aGVy ZSBhcmUgTg0KPiBhdmFpbGFibGUgcGF0aHMgaW4gYW4gRUNNUC4gSSBiZWxpZXZlIHRoYXQgdGhl cmUgaXMgbm8gZXhwZWN0YXRpb24gdG8gcHJlZGljdA0KPiB3aXRoIGFueSBsZXZlbCBvZiBjZXJ0 YWludHkgd2hpY2ggcGFydGljdWxhciBwYXRoIGEgZmxvdyB3aWxsIGZvbGxvdyBidXQgb25seQ0K PiBleHBlY3RhdGlvbiB0aGF0IGZsb3cgd2l0aCBFTCBNKzIgd2lsbCB0YWtlIGRpZmZlcmVudCBw YXRoIHdpdGggZmxvdyB0YWdnZWQgYnkNCj4gRUwgTSszLiBDZXJ0YWludHkgaXMgcmVxdWlyZWQg dGhvdWdoIHdoZW4gRUNNUCBpcyB2aWV3ZWQgYXMgYSBsaW5rLCBlLmcuDQo+IG1pY3JvLUJGRC4N Cj4gDQo+IAlSZWdhcmRzLA0KPiAJCUdyZWcNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBOb2JvIEFraXlhDQo+IChub2JvKQ0KPiBTZW50OiBGcmlkYXksIE1heSAwOSwg MjAxNCA1OjM3IEFNDQo+IFRvOiBMb2EgQW5kZXJzc29uOyBNYW5hdiBCaGF0aWE7IE1hY2ggQ2hl bg0KPiBDYzogcnRnLWJmZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogUHJvYmxlbSB3aXRoIEJG RCB3aXRoIEVDTVANCj4gDQo+IEhpIE1hbmF2LCBNYWNoLCBMb2EsDQo+IA0KPiBPbiBzb21lIGRh dGEgcGxhbmVzIChleDogTVBMUyB3aXRoIEVudHJvcHkgTGFiZWwpLCBpdCdzIGxlc3MgZGlmZmlj dWx0IHRvIHVzZQ0KPiBPQU0gcGFja2V0cyB0byBbbGlrZWx5XSBleGVyY2lzZSBzcGVjaWZpYyBF Q01QIHBhdGhzIGFzIGxvbmcgYXMgdGhlcmUgYXJlIHdheXMNCj4gdG8gZGlzY292ZXIgdGhlIGVu dHJvcGllcy4NCj4gDQo+IE9uIHNvbWUgb3RoZXJzIChleDogSVAgbmV0d29yayksIGl0J3MgbW9y ZSBkaWZmaWN1bHQgYW5kIEkgZnVsbHkgYWdyZWUgd2l0aCB3aGF0DQo+IExvYSBzYWlkLg0KPiAN Cj4gLU5vYm8NCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBS dGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTG9h DQo+ID4gQW5kZXJzc29uDQo+ID4gU2VudDogRnJpZGF5LCBNYXkgMDksIDIwMTQgNjo1MyBBTQ0K PiA+IFRvOiBNYW5hdiBCaGF0aWE7IE1hY2ggQ2hlbg0KPiA+IENjOiBydGctYmZkQGlldGYub3Jn DQo+ID4gU3ViamVjdDogUmU6IFByb2JsZW0gd2l0aCBCRkQgd2l0aCBFQ01QDQo+ID4NCj4gPiBN YWNoIGFuZCBNYW5hdiwNCj4gPg0KPiA+IEkgZ3Vlc3MgdGhhdCB0aGUgYW5zd2VyIHRvIHRoaXMg dHlwZSBvZiBxdWVzdGlvbiBpcyBzb21ld2hlcmUgYXJvdW5kDQo+ID4gIklzIGl0IHdvcnRoIGRv aW5nPyIuIElmIHdlIHNlZSBhbiBlYXN5IHdheSB0byBmaXggaXQgYW5kIHdlIGFyZQ0KPiA+IHBy ZXR0eSBzdXJlIHRoYXQgaXQgd2lsbCBiZSBkZXBsb3llZCwgdGhlbiBsZXQgdXMgZ28gYWhlYWQg YW5kIGRvIGl0Lg0KPiA+IElmIHRoZSBmaXggaXMgc2hhZHkgYW5kIG5vIG9uZSByZWFsbHkgd2Fu dCBpdCwgdGhlbiBqdXN0IGxlYXZlIGl0Lg0KPiA+DQo+ID4gTm8gaW4gdGhvc2UgdGVybXMgd2hl cmUgYXJlIHdlPw0KPiA+DQo+ID4gL0xvYQ0KPiA+DQo+ID4gT24gMjAxNC0wNS0wOSAxMjoxMiwg TWFuYXYgQmhhdGlhIHdyb3RlOg0KPiA+ID4gSGkgTWFjaCwNCj4gPiA+DQo+ID4gPj4+IE15IHBv aW50IGlzIHRoaXM6DQo+ID4gPj4+DQo+ID4gPj4+IEhvdyBkbyBpIGVuc3VyZSB0aGF0IGluIGFu IElQIG9ubHkgbmV0d29yaywgbXkgZGF0YSB0cmFmZmljIGFsd2F5cw0KPiA+ID4+PiBmb2xsb3dz IHRoZSBzYW1lIHBhdGggYXMgdGhlIE9BTSBwYWNrZXQgdGhhdCBpIGhhZCBzZW50IHRvIHZlcmlm eQ0KPiA+ID4+PiB0aGUNCj4gPiBkYXRhIHBsYW5lPw0KPiA+ID4+DQo+ID4gPj4gSXQncyBhbHdh eXMgZGVzaXJlZCwgYnV0IGl0J3MgaGFyZCwgYW5kIG1vc3Qgb2YgdGltZSwgbm8gcGVyZmVjdCBz b2x1dGlvbi4NCj4gPiA+DQo+ID4gPiBTdXJlIHRoZSBxdWVzdGlvbiBpczogRG8gd2Ugd2FudCB0 byBmaXggdGhpcz8NCj4gPiA+DQo+ID4gPj4NCj4gPiA+Pj4NCj4gPiA+Pj4gV2lsbCBpdCB3b3Jr IGlmIGkgZW5jYXBzdWxhdGUgYm90aCB0aGUgT0FNIGFuZCB0aGUgZGF0YSB0cmFmZmljDQo+ID4g Pj4+IGluc2lkZSBhIEdSRSB0dW5uZWwgc28gdGhhdCBib3RoIHVzZSB0aGUgc2FtZSBoYXNoaW5n IGZpZWxkcz8gSQ0KPiA+ID4+PiBtYXkgd2FudCB0byBkbyB0aGlzIGZvciBjZXJ0YWluIGZsb3dz IHdoZXJlIGkgd2FudCBhIHZlcnkNCj4gPiA+Pj4gZGV0ZXJtaW5pc3RpYw0KPiA+IGJlaGF2aW9y Lg0KPiA+ID4+DQo+ID4gPj4gWWVzLCB1c2UgYSB0dW5uZWwgdG8gZW5jYXBzdWxhdGUgYm90aCB0 aGUgT0FNIGFuZCB0aGUgZGF0YSB0cmFmZmljDQo+ID4gPj4gaXMgYQ0KPiA+IGNhbmRpZGF0ZS4N Cj4gPiA+PiBCdXQgZm9yIGEgZGVwbG95ZWQgbmV0d29yaywgc3VjaCBjaGFuZ2VzIG1heSBub3Qg YWNjZXB0ZWQsIHlvdQ0KPiA+ID4+IGNhbm5vdCBjaGFuZ2UgdGhlIGV4aXN0aW5nIGRlcGxveW1l bnQgbW9kZWwuDQo+ID4gPg0KPiA+ID4gV2UgY2FuIGxvb2sgYXQgdGhlIHNvbHV0aW9uIHNwYWNl IGxhdGVyLg0KPiA+ID4NCj4gPiA+IFRoZSBmaXJzdCB0aGluZyBpcyAtLSBEbyB3ZSB3YW50IHRv IHNvbHZlIHRoaXMgaXNzdWU/IEkgd291bGQgd2FnZXINCj4gPiA+IHRoYXQgaXRzIHNvbWV0aGlu ZyB0aGF0IHdlIHdvdWxkIHdhbnQgdG8gc29sdmUuIEp1c3Qgd2FudCB0byBoZWFyDQo+ID4gPiB3 aGF0IG90aGVycyB0aGluayBhYm91dCB0aGlzLg0KPiA+ID4NCj4gPiA+IENoZWVycywgTWFuYXYN Cj4gPiA+DQo+ID4gPj4NCj4gPiA+PiBCZXN0IHJlZ2FyZHMsDQo+ID4gPj4gTWFjaA0KPiA+ID4+ DQo+ID4gPj4+DQo+ID4gPj4+IENoZWVycywgTWFuYXYNCj4gPiA+Pj4NCj4gPiA+Pj4+ICAgZGV0 ZWN0IGEgc2VnbWVudCBvZiB0aGUgcGF0aCwgbWVhbnMgdGhlIGRlc3RpbmF0aW9uIG9mIHRoZQ0K PiA+ID4+Pj4gUy1CRkQgd2lsbCBiZSBkaWZmZXJlbnQgZnJvbSB0aGUgdXNlciBkYXRhLiBUaGVu IHlvdSBkZXNjcmliZWQNCj4gPiA+Pj4+IHNpdHVhdGlvbiB3aWxsDQo+ID4gaGFwcGVuLg0KPiA+ ID4+Pj4NCj4gPiA+Pj4+IEJlc3QgcmVnYXJkcywNCj4gPiA+Pj4+IE1hY2gNCj4gPiA+Pj4+DQo+ ID4gPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+Pj4+PiBGcm9tOiBSdGct YmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gPiA+ Pj4+PiBNYW5hdiBCaGF0aWENCj4gPiA+Pj4+PiBTZW50OiBGcmlkYXksIE1heSAwOSwgMjAxNCA0 OjAyIFBNDQo+ID4gPj4+Pj4gVG86IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gPiA+Pj4+PiBTdWJqZWN0 OiBQcm9ibGVtIHdpdGggQkZEIHdpdGggRUNNUA0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gSGksDQo+ ID4gPj4+Pj4NCj4gPiA+Pj4+PiBUaGVyZSBpcyBhIHByb2JsZW0gd2l0aCBob3cgQkZEL1MtQkZE IHdvcmtzLg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gU2VjIDMuMiBkcmFmdC1hbGRyaW4tYmZkLXNl YW1sZXNzLXVzZS1jYXNlLTAxIGV4cGxhaW5zIGhvdyB3ZQ0KPiA+ID4+Pj4+IGNhbiB1c2UgUy1C RkQgdG8gcXVpY2tseSB2YWxpZGF0ZSB0aGUgZGF0YSBwbGFuZSBiZWZvcmUgcHVzaGluZw0KPiA+ ID4+Pj4+IHRoZSBkYXRhDQo+ID4gb3V0Lg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gVGhlcmUgaXMg YSBwb3RlbnRpYWwgaXNzdWUgaGVyZS4NCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+IEFzc3VtZSBJIHNl bmQgYW4gUy1CRkQgcGluZyBhbmQgSSBnZXQgYSBwb25nIGJhY2suSSBiZWxpZXZlIHRoYXQNCj4g PiA+Pj4+PiB0aGUgcGF0aCBpcyB1cCBhbmQgaSBzdGFydCBzZW5kaW5nIHRyYWZmaWMgdG93YXJk cyB0aGUNCj4gPiA+Pj4+PiBSZWZsZWN0b3IsIGJyaW1taW5nIHdpdGggY29uZmlkZW5jZSwgc2lu Y2UgaSBiZWxpZXZlIHRoZSBkYXRhIHBsYW5lIGlzDQo+IHVwLg0KPiA+ID4+Pj4+DQo+ID4gPj4+ Pj4gQXNzdW1lIHRoYXQgdGhlcmUgaXMgRUNNUCBoYXBwZW5pbmcgaW4gdGhlIG5ldHdvcmsgc29t ZXdoZXJlDQo+ID4gdGhhdA0KPiA+ID4+Pj4+IHNwbGl0cyB0aGUgdHJhZmZpYyB0byBwYXRocyBw MSBhbmQgcDIuDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBJdHMgcG9zc2libGUgdGhhdCB0aGUgUy1C RkQgcGFja2V0IGdldHMgaGFzaGVkIHRvIHRoZSBwYXRoIHAxLA0KPiA+ID4+Pj4+IHdoaWxlIHRo ZSBkYXRhIHRyYWZmaWMgdGhhdCBpIHNlbmQgZ2V0cyBoYXNoZWQgdG8gcGF0aCBwMi4NCj4gPiA+ Pj4+Pg0KPiA+ID4+Pj4+IElmIHBhdGggcDIgaXMgZG93biAob3IgaXMgY29uZ2VzdGVkIGFuZCBk cm9wcyBwYWNrZXRzKSwgdGhlbiBpDQo+ID4gPj4+Pj4gZHJvcCBhbGwgdHJhZmZpYyAtLSBvciBz b21lLCBpbiBjYXNlIG9mIGNvbmdlc3Rpb24uIFRoaXMgaG93ZXZlcg0KPiA+ID4+Pj4+IGlzIHVu ZXhwZWN0ZWQgc2luY2UgaSBhbHdheXMgZ2V0IDEwMCUgcmVzcG9uc2UgZm9yIG15IFMtQkZEIHBp bmcNCj4gPiBwYWNrZXRzLg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gSSB1bmRlcnN0YW5kIHRoYXQg aWYgcGF0aCBwMiBpcyBkb3duIChiZWNhdXNlIG9mIGFuIGlzc3VlIGluIG9uZQ0KPiA+ID4+Pj4+ IG9mIHRoZSBub2Rlcy9saW5rcyBpbiB0aGUgcGF0aCksIHRoZSBFQ01QIHBhdGggd2lsbCBub3Qg Y29udGFpbg0KPiA+ID4+Pj4+IHAyLCBzaW5jZSB0aGUgcm91dGluZyBwcm90b2NvbHMgd2lsbCBu YXR1cmFsbHkgcmVtb3ZlIHRoaXMgZnJvbQ0KPiA+ID4+Pj4+IHRoZQ0KPiA+IEVDTVAgbGlzdC4N Cj4gPiA+Pj4+PiBTbywgaXRzIG9ubHkgd2hpbGUgdGhlIG5ldHdvcmsgaXMgcmVjb252ZXJnaW5n ICh3aGljaCBzaG91bGQNCj4gPiA+Pj4+PiBvbmx5IGxhc3QgZm9yIGEgZmV3DQo+ID4gPj4+Pj4g c2VjcykgdGhhdCB3ZSB3aWxsIHNlZSB0aGlzLg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gSXMgbXkg dW5kZXJzdGFuZGluZyBjb3JyZWN0Pw0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gSWYgeWVzLCB0aGVu IGlzIHRoZSBzY2VuYXJpbyB3aGVyZSBTLUJGRCBhbmQgZGF0YSB0cmFmZmljDQo+ID4gPj4+Pj4g Zm9sbG93aW5nIGRpZmZlcmVudCBwYXRocyBzb21ldGhpbmcgdGhhdCB3ZSB3YW50IHRvIGxvb2sg YXQNCj4gPiA+Pj4+PiBmaXhpbmcgKGVpdGhlciBoZXJlIG9yIHNvbWUgb3RoZXIgV0cpPyBUaGlz IHByb2JsZW0gaGFzIGFscmVhZHkNCj4gPiA+Pj4+PiBiZWVuIHNvbHZlZCBpbiB0aGUgTVBMUyBj b250ZXh0IHdpdGggdGhlIEVudHJvcHkgbGFiZWwuIEkgYW0NCj4gPiA+Pj4+PiB0YWxraW5nIHNw ZWNpZmljYWxseSBhYm91dCBub24tTVBMUw0KPiA+ID4+PiBuZXR3b3Jrcy4NCj4gPiA+Pj4+Pg0K PiA+ID4+Pj4+IENoZWVycywgTWFuYXYNCj4gPiA+Pj4+DQo+ID4gPg0KPiA+DQo+ID4gLS0NCj4g Pg0KPiA+DQo+ID4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBs b2FAbWFpbDAxLmh1YXdlaS5jb20NCj4gPiBTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAg ICAgICAgICAgICAgIGxvYUBwaS5udQ0KPiA+IEh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRh bnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KDQo= From nobody Fri May 9 10:28:46 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513C51A0012 for ; Fri, 9 May 2014 10:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCJCbtf0ysxY for ; Fri, 9 May 2014 10:28:43 -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 2142D1A0066 for ; Fri, 9 May 2014 10:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11746; q=dns/txt; s=iport; t=1399656518; x=1400866118; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Uw3hbHh1lEknIV6YbO7ytm9eLw3BL+Nlk9ZCAPMVEzI=; b=UWhL/vCHz+UUT3HrlRaoARCAJBXli0xClh0z5Zk5vWl2P7PmD9zeF3qX WNmmwvGX6vBR32/UCHyqxk/8QAI8ikBRWxCRPYX/g2zadOMhHTvqBdCVV oENbRW7nrl3VJKvyUNaHtGmoS6NDxUnPudW79UwJY+V69Pj4WmiPHDzO1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFADsPbVOtJA2B/2dsb2JhbABZgmUhgSeCZ8JlARl/FnSCJQEBAQMBIxE3DgwCAgIBCBEEAQEBAgIGHQMCAgIZFxQBCAgCBAENBQgTiB4IAaxVpE8XBIEmiAeEPxEBHxYbBwaCbzaBFQSsSYM2gW8HFwYc X-IronPort-AV: E=Sophos;i="4.97,1019,1389744000"; d="scan'208";a="323737549" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP; 09 May 2014 17:28:37 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s49HSbci009123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 17:28:37 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Fri, 9 May 2014 12:28:37 -0500 From: "Nobo Akiya (nobo)" To: John E Drake , Gregory Mirsky , Loa Andersson , Manav Bhatia , Mach Chen Subject: RE: Problem with BFD with ECMP Thread-Topic: Problem with BFD with ECMP Thread-Index: AQHPa10Hnz/g8sNPJkCrTO5TJTaw35s4QxqAgAADoQCAABFvAIAAAzGAgAALU4D//8Z6YIAAevyAgAAjc4D//6+oIA== Date: Fri, 9 May 2014 17:28:36 +0000 Message-ID: References: <536CB377.9010302@pi.nu> <7347100B5761DC41A166AC17F22DF1121B7ACA78@eusaamb103.ericsson.se> <6bca320c5bdd4b828a5318e526d12889@BLUPR05MB562.namprd05.prod.outlook.com> In-Reply-To: <6bca320c5bdd4b828a5318e526d12889@BLUPR05MB562.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/6gHlt4iXZx0BI-JZh3TzdbUJE6c Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 17:28:45 -0000 SGkgSm9obiwgR3JlZywNCg0KW0pvaG4gd3JvdGVdDQo+IFJGQyA0Mzc5IHdpdGggTm9ibydzIHVw ZGF0ZXMgd2lsbCB0ZWxsIHlvdSBhIHJhbmdlIG9mIGxhYmVscyB0aGF0IGNhbiBiZSB1c2VkDQo+ IHRvIGNhdXNlIGFuIE1QTFMgcGFja2V0IHRvIHRha2UgYSBwYXJ0aWN1bGFyIEVDTVAgcGF0aC4g IFB1dHRpbmcgYW55IGxhYmVsDQo+IGZyb20gdGhhdCByYW5nZSBvbiBhIHBhY2tldCB3aWxsIGZv cmNlIGl0IHRvIHRha2UgdGhhdCBwYXRoLg0KDQpDb3JyZWN0LiBPbmUgd291bGQgc3RpbGwgd2Fu dCB0byBydW4gTFNQIHRyZWUvcGF0aCB0cmFjZSAoUkZDNDM3OSArIG11bHRpcGF0aCBpbmZvIGZv ciBFTCkgZXZlcnkgbm93IGFuZCB0aGVuIHRvIHJlZnJlc2ggdGhlIChwYXRocyArIEVMcyksIGJ1 dCB0aGF0J3MgdGhlIGludGVudC4gQW5kIHdlIGlmIGNvdWxkIHVzZSBTLUJGRCBmb3IgaW4tYmFu ZCBtb25pdG9yaW5nIG9mIGV2ZXJ5IHBhdGhzLCB0aGF0J3MgYSBmYWlybHkgZ29vZCBjb3ZlcmFn ZSAobm90IHBlcmZlY3QsIGJ1dCBmYWlybHkgZ29vZCkgZm9yIE1QTFMuDQoNCltHcmVnIHdyb3Rl XQ0KPiA+IEknbSBub3Qgc3VyZSB0aGF0IEVMSS9FTCB3YXMgaW50ZW5kZWQgdG8gcGluIGEgZmxv dyB0byB0aGUgcGFydGljdWxhcg0KPiA+IEVDTVAgcGF0aC4gTXkgdW5kZXJzdGFuZGluZyBvZiBF TCBpcyB0aGF0IGl0IG1ha2VzIGVhc2llciB0bw0KPiA+IGRpc3RyaWJ1dGUgZmxvd3MsIGUuZy4g YnkgYXNzaWduaW5nIEVMIGxhYmVscyBmcm9tIGxhYmVsIHJhbmdlIE4NCj4gPiBsYWJlbHMgd2lk ZSwgW00sIE0rTl0gd2hlbiB0aGVyZSBhcmUgTiBhdmFpbGFibGUgcGF0aHMgaW4gYW4gRUNNUC4g SQ0KPiA+IGJlbGlldmUgdGhhdCB0aGVyZSBpcyBubyBleHBlY3RhdGlvbiB0byBwcmVkaWN0IHdp dGggYW55IGxldmVsIG9mDQo+ID4gY2VydGFpbnR5IHdoaWNoIHBhcnRpY3VsYXIgcGF0aCBhIGZs b3cgd2lsbCBmb2xsb3cgYnV0IG9ubHkNCj4gPiBleHBlY3RhdGlvbiB0aGF0IGZsb3cgd2l0aCBF TCBNKzIgd2lsbCB0YWtlIGRpZmZlcmVudCBwYXRoIHdpdGggZmxvdw0KPiB0YWdnZWQgYnkgRUwg TSszLiBDZXJ0YWludHkgaXMgcmVxdWlyZWQgdGhvdWdoIHdoZW4gRUNNUCBpcyB2aWV3ZWQgYXMg YQ0KPiBsaW5rLCBlLmcuDQo+ID4gbWljcm8tQkZELg0KDQpJZiBwb3NzaWJsZSwgSSBkbyBwcmVm ZXIgZW5kLXRvLWVuZCB0ZXN0cyBhcyB0aGF0IGlzIGVhc2llciB0byBwcm92aWRlIGNvbmZpZGVu Y2UgdGhhdCB0aGluZ3MgYXJlIHdvcmtpbmcgZW5kLXRvLWVuZC4gTVBMUywgdGhhdCdzIGRvLWFi bGUuIElQIC4uLiB2ZXJ5IHRyaWNreSBhcyBvdGhlciBtZW50aW9uZWQuIFNvIHdoYXQgeW91IGFy ZSBwcm9wb3NpbmcgbG9va3MgdmVyeSBpbnRlcmVzdGluZyBmcm9tIHRoYXQgYW5nbGUuDQoNCi1O b2JvDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm9obiBFIERyYWtl IFttYWlsdG86amRyYWtlQGp1bmlwZXIubmV0XQ0KPiBTZW50OiBGcmlkYXksIE1heSAwOSwgMjAx NCAxMjo1NCBQTQ0KPiBUbzogR3JlZ29yeSBNaXJza3k7IE5vYm8gQWtpeWEgKG5vYm8pOyBMb2Eg QW5kZXJzc29uOyBNYW5hdiBCaGF0aWE7IE1hY2gNCj4gQ2hlbg0KPiBDYzogcnRnLWJmZEBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSRTogUHJvYmxlbSB3aXRoIEJGRCB3aXRoIEVDTVANCj4gDQo+IEdy ZWcsDQo+IA0KPiBSRkMgNDM3OSB3aXRoIE5vYm8ncyB1cGRhdGVzIHdpbGwgdGVsbCB5b3UgYSBy YW5nZSBvZiBsYWJlbHMgdGhhdCBjYW4gYmUgdXNlZA0KPiB0byBjYXVzZSBhbiBNUExTIHBhY2tl dCB0byB0YWtlIGEgcGFydGljdWxhciBFQ01QIHBhdGguICBQdXR0aW5nIGFueSBsYWJlbA0KPiBm cm9tIHRoYXQgcmFuZ2Ugb24gYSBwYWNrZXQgd2lsbCBmb3JjZSBpdCB0byB0YWtlIHRoYXQgcGF0 aC4NCj4gDQo+IFlvdXJzIElycmVzcGVjdGl2ZWx5LA0KPiANCj4gSm9obg0KPiANCj4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZk LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHcmVnb3J5DQo+ID4gTWlyc2t5DQo+ID4g U2VudDogRnJpZGF5LCBNYXkgMDksIDIwMTQgNzo0NyBBTQ0KPiA+IFRvOiBOb2JvIEFraXlhIChu b2JvKTsgTG9hIEFuZGVyc3NvbjsgTWFuYXYgQmhhdGlhOyBNYWNoIENoZW4NCj4gPiBDYzogcnRn LWJmZEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBQcm9ibGVtIHdpdGggQkZEIHdpdGggRUNN UA0KPiA+DQo+ID4gSGkgTm9ibywgZXQuIGFsLA0KPiA+IEknbSBub3Qgc3VyZSB0aGF0IEVMSS9F TCB3YXMgaW50ZW5kZWQgdG8gcGluIGEgZmxvdyB0byB0aGUgcGFydGljdWxhcg0KPiA+IEVDTVAg cGF0aC4gTXkgdW5kZXJzdGFuZGluZyBvZiBFTCBpcyB0aGF0IGl0IG1ha2VzIGVhc2llciB0bw0K PiA+IGRpc3RyaWJ1dGUgZmxvd3MsIGUuZy4gYnkgYXNzaWduaW5nIEVMIGxhYmVscyBmcm9tIGxh YmVsIHJhbmdlIE4NCj4gPiBsYWJlbHMgd2lkZSwgW00sIE0rTl0gd2hlbiB0aGVyZSBhcmUgTiBh dmFpbGFibGUgcGF0aHMgaW4gYW4gRUNNUC4gSQ0KPiA+IGJlbGlldmUgdGhhdCB0aGVyZSBpcyBu byBleHBlY3RhdGlvbiB0byBwcmVkaWN0IHdpdGggYW55IGxldmVsIG9mDQo+ID4gY2VydGFpbnR5 IHdoaWNoIHBhcnRpY3VsYXIgcGF0aCBhIGZsb3cgd2lsbCBmb2xsb3cgYnV0IG9ubHkNCj4gPiBl eHBlY3RhdGlvbiB0aGF0IGZsb3cgd2l0aCBFTCBNKzIgd2lsbCB0YWtlIGRpZmZlcmVudCBwYXRo IHdpdGggZmxvdw0KPiB0YWdnZWQgYnkgRUwgTSszLiBDZXJ0YWludHkgaXMgcmVxdWlyZWQgdGhv dWdoIHdoZW4gRUNNUCBpcyB2aWV3ZWQgYXMgYQ0KPiBsaW5rLCBlLmcuDQo+ID4gbWljcm8tQkZE Lg0KPiA+DQo+ID4gCVJlZ2FyZHMsDQo+ID4gCQlHcmVnDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOb2JvDQo+ID4gQWtpeWENCj4gPiAobm9ibykNCj4gPiBT ZW50OiBGcmlkYXksIE1heSAwOSwgMjAxNCA1OjM3IEFNDQo+ID4gVG86IExvYSBBbmRlcnNzb247 IE1hbmF2IEJoYXRpYTsgTWFjaCBDaGVuDQo+ID4gQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gPiBT dWJqZWN0OiBSRTogUHJvYmxlbSB3aXRoIEJGRCB3aXRoIEVDTVANCj4gPg0KPiA+IEhpIE1hbmF2 LCBNYWNoLCBMb2EsDQo+ID4NCj4gPiBPbiBzb21lIGRhdGEgcGxhbmVzIChleDogTVBMUyB3aXRo IEVudHJvcHkgTGFiZWwpLCBpdCdzIGxlc3MgZGlmZmljdWx0DQo+ID4gdG8gdXNlIE9BTSBwYWNr ZXRzIHRvIFtsaWtlbHldIGV4ZXJjaXNlIHNwZWNpZmljIEVDTVAgcGF0aHMgYXMgbG9uZyBhcw0K PiA+IHRoZXJlIGFyZSB3YXlzIHRvIGRpc2NvdmVyIHRoZSBlbnRyb3BpZXMuDQo+ID4NCj4gPiBP biBzb21lIG90aGVycyAoZXg6IElQIG5ldHdvcmspLCBpdCdzIG1vcmUgZGlmZmljdWx0IGFuZCBJ IGZ1bGx5IGFncmVlDQo+ID4gd2l0aCB3aGF0IExvYSBzYWlkLg0KPiA+DQo+ID4gLU5vYm8NCj4g Pg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IFJ0Zy1iZmQg W21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMb2ENCj4gPiA+ IEFuZGVyc3Nvbg0KPiA+ID4gU2VudDogRnJpZGF5LCBNYXkgMDksIDIwMTQgNjo1MyBBTQ0KPiA+ ID4gVG86IE1hbmF2IEJoYXRpYTsgTWFjaCBDaGVuDQo+ID4gPiBDYzogcnRnLWJmZEBpZXRmLm9y Zw0KPiA+ID4gU3ViamVjdDogUmU6IFByb2JsZW0gd2l0aCBCRkQgd2l0aCBFQ01QDQo+ID4gPg0K PiA+ID4gTWFjaCBhbmQgTWFuYXYsDQo+ID4gPg0KPiA+ID4gSSBndWVzcyB0aGF0IHRoZSBhbnN3 ZXIgdG8gdGhpcyB0eXBlIG9mIHF1ZXN0aW9uIGlzIHNvbWV3aGVyZSBhcm91bmQNCj4gPiA+ICJJ cyBpdCB3b3J0aCBkb2luZz8iLiBJZiB3ZSBzZWUgYW4gZWFzeSB3YXkgdG8gZml4IGl0IGFuZCB3 ZSBhcmUNCj4gPiA+IHByZXR0eSBzdXJlIHRoYXQgaXQgd2lsbCBiZSBkZXBsb3llZCwgdGhlbiBs ZXQgdXMgZ28gYWhlYWQgYW5kIGRvIGl0Lg0KPiA+ID4gSWYgdGhlIGZpeCBpcyBzaGFkeSBhbmQg bm8gb25lIHJlYWxseSB3YW50IGl0LCB0aGVuIGp1c3QgbGVhdmUgaXQuDQo+ID4gPg0KPiA+ID4g Tm8gaW4gdGhvc2UgdGVybXMgd2hlcmUgYXJlIHdlPw0KPiA+ID4NCj4gPiA+IC9Mb2ENCj4gPiA+ DQo+ID4gPiBPbiAyMDE0LTA1LTA5IDEyOjEyLCBNYW5hdiBCaGF0aWEgd3JvdGU6DQo+ID4gPiA+ IEhpIE1hY2gsDQo+ID4gPiA+DQo+ID4gPiA+Pj4gTXkgcG9pbnQgaXMgdGhpczoNCj4gPiA+ID4+ Pg0KPiA+ID4gPj4+IEhvdyBkbyBpIGVuc3VyZSB0aGF0IGluIGFuIElQIG9ubHkgbmV0d29yaywg bXkgZGF0YSB0cmFmZmljDQo+ID4gPiA+Pj4gYWx3YXlzIGZvbGxvd3MgdGhlIHNhbWUgcGF0aCBh cyB0aGUgT0FNIHBhY2tldCB0aGF0IGkgaGFkIHNlbnQNCj4gPiA+ID4+PiB0byB2ZXJpZnkgdGhl DQo+ID4gPiBkYXRhIHBsYW5lPw0KPiA+ID4gPj4NCj4gPiA+ID4+IEl0J3MgYWx3YXlzIGRlc2ly ZWQsIGJ1dCBpdCdzIGhhcmQsIGFuZCBtb3N0IG9mIHRpbWUsIG5vIHBlcmZlY3Qgc29sdXRpb24u DQo+ID4gPiA+DQo+ID4gPiA+IFN1cmUgdGhlIHF1ZXN0aW9uIGlzOiBEbyB3ZSB3YW50IHRvIGZp eCB0aGlzPw0KPiA+ID4gPg0KPiA+ID4gPj4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IFdpbGwgaXQg d29yayBpZiBpIGVuY2Fwc3VsYXRlIGJvdGggdGhlIE9BTSBhbmQgdGhlIGRhdGEgdHJhZmZpYw0K PiA+ID4gPj4+IGluc2lkZSBhIEdSRSB0dW5uZWwgc28gdGhhdCBib3RoIHVzZSB0aGUgc2FtZSBo YXNoaW5nIGZpZWxkcz8gSQ0KPiA+ID4gPj4+IG1heSB3YW50IHRvIGRvIHRoaXMgZm9yIGNlcnRh aW4gZmxvd3Mgd2hlcmUgaSB3YW50IGEgdmVyeQ0KPiA+ID4gPj4+IGRldGVybWluaXN0aWMNCj4g PiA+IGJlaGF2aW9yLg0KPiA+ID4gPj4NCj4gPiA+ID4+IFllcywgdXNlIGEgdHVubmVsIHRvIGVu Y2Fwc3VsYXRlIGJvdGggdGhlIE9BTSBhbmQgdGhlIGRhdGENCj4gPiA+ID4+IHRyYWZmaWMgaXMg YQ0KPiA+ID4gY2FuZGlkYXRlLg0KPiA+ID4gPj4gQnV0IGZvciBhIGRlcGxveWVkIG5ldHdvcmss IHN1Y2ggY2hhbmdlcyBtYXkgbm90IGFjY2VwdGVkLCB5b3UNCj4gPiA+ID4+IGNhbm5vdCBjaGFu Z2UgdGhlIGV4aXN0aW5nIGRlcGxveW1lbnQgbW9kZWwuDQo+ID4gPiA+DQo+ID4gPiA+IFdlIGNh biBsb29rIGF0IHRoZSBzb2x1dGlvbiBzcGFjZSBsYXRlci4NCj4gPiA+ID4NCj4gPiA+ID4gVGhl IGZpcnN0IHRoaW5nIGlzIC0tIERvIHdlIHdhbnQgdG8gc29sdmUgdGhpcyBpc3N1ZT8gSSB3b3Vs ZA0KPiA+ID4gPiB3YWdlciB0aGF0IGl0cyBzb21ldGhpbmcgdGhhdCB3ZSB3b3VsZCB3YW50IHRv IHNvbHZlLiBKdXN0IHdhbnQgdG8NCj4gPiA+ID4gaGVhciB3aGF0IG90aGVycyB0aGluayBhYm91 dCB0aGlzLg0KPiA+ID4gPg0KPiA+ID4gPiBDaGVlcnMsIE1hbmF2DQo+ID4gPiA+DQo+ID4gPiA+ Pg0KPiA+ID4gPj4gQmVzdCByZWdhcmRzLA0KPiA+ID4gPj4gTWFjaA0KPiA+ID4gPj4NCj4gPiA+ ID4+Pg0KPiA+ID4gPj4+IENoZWVycywgTWFuYXYNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+PiAgIGRl dGVjdCBhIHNlZ21lbnQgb2YgdGhlIHBhdGgsIG1lYW5zIHRoZSBkZXN0aW5hdGlvbiBvZiB0aGUN Cj4gPiA+ID4+Pj4gUy1CRkQgd2lsbCBiZSBkaWZmZXJlbnQgZnJvbSB0aGUgdXNlciBkYXRhLiBU aGVuIHlvdSBkZXNjcmliZWQNCj4gPiA+ID4+Pj4gc2l0dWF0aW9uIHdpbGwNCj4gPiA+IGhhcHBl bi4NCj4gPiA+ID4+Pj4NCj4gPiA+ID4+Pj4gQmVzdCByZWdhcmRzLA0KPiA+ID4gPj4+PiBNYWNo DQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ ID4gPj4+Pj4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mDQo+ID4gPiA+Pj4+PiBNYW5hdiBCaGF0aWENCj4gPiA+ID4+Pj4+IFNlbnQ6 IEZyaWRheSwgTWF5IDA5LCAyMDE0IDQ6MDIgUE0NCj4gPiA+ID4+Pj4+IFRvOiBydGctYmZkQGll dGYub3JnDQo+ID4gPiA+Pj4+PiBTdWJqZWN0OiBQcm9ibGVtIHdpdGggQkZEIHdpdGggRUNNUA0K PiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+IEhpLA0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+IFRo ZXJlIGlzIGEgcHJvYmxlbSB3aXRoIGhvdyBCRkQvUy1CRkQgd29ya3MuDQo+ID4gPiA+Pj4+Pg0K PiA+ID4gPj4+Pj4gU2VjIDMuMiBkcmFmdC1hbGRyaW4tYmZkLXNlYW1sZXNzLXVzZS1jYXNlLTAx IGV4cGxhaW5zIGhvdyB3ZQ0KPiA+ID4gPj4+Pj4gY2FuIHVzZSBTLUJGRCB0byBxdWlja2x5IHZh bGlkYXRlIHRoZSBkYXRhIHBsYW5lIGJlZm9yZQ0KPiA+ID4gPj4+Pj4gcHVzaGluZyB0aGUgZGF0 YQ0KPiA+ID4gb3V0Lg0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+IFRoZXJlIGlzIGEgcG90ZW50 aWFsIGlzc3VlIGhlcmUuDQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4gQXNzdW1lIEkgc2VuZCBh biBTLUJGRCBwaW5nIGFuZCBJIGdldCBhIHBvbmcgYmFjay5JIGJlbGlldmUNCj4gPiA+ID4+Pj4+ IHRoYXQgdGhlIHBhdGggaXMgdXAgYW5kIGkgc3RhcnQgc2VuZGluZyB0cmFmZmljIHRvd2FyZHMg dGhlDQo+ID4gPiA+Pj4+PiBSZWZsZWN0b3IsIGJyaW1taW5nIHdpdGggY29uZmlkZW5jZSwgc2lu Y2UgaSBiZWxpZXZlIHRoZSBkYXRhDQo+ID4gPiA+Pj4+PiBwbGFuZSBpcw0KPiA+IHVwLg0KPiA+ ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+IEFzc3VtZSB0aGF0IHRoZXJlIGlzIEVDTVAgaGFwcGVuaW5n IGluIHRoZSBuZXR3b3JrIHNvbWV3aGVyZQ0KPiA+ID4gdGhhdA0KPiA+ID4gPj4+Pj4gc3BsaXRz IHRoZSB0cmFmZmljIHRvIHBhdGhzIHAxIGFuZCBwMi4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+ PiBJdHMgcG9zc2libGUgdGhhdCB0aGUgUy1CRkQgcGFja2V0IGdldHMgaGFzaGVkIHRvIHRoZSBw YXRoIHAxLA0KPiA+ID4gPj4+Pj4gd2hpbGUgdGhlIGRhdGEgdHJhZmZpYyB0aGF0IGkgc2VuZCBn ZXRzIGhhc2hlZCB0byBwYXRoIHAyLg0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+IElmIHBhdGgg cDIgaXMgZG93biAob3IgaXMgY29uZ2VzdGVkIGFuZCBkcm9wcyBwYWNrZXRzKSwgdGhlbiBpDQo+ ID4gPiA+Pj4+PiBkcm9wIGFsbCB0cmFmZmljIC0tIG9yIHNvbWUsIGluIGNhc2Ugb2YgY29uZ2Vz dGlvbi4gVGhpcw0KPiA+ID4gPj4+Pj4gaG93ZXZlciBpcyB1bmV4cGVjdGVkIHNpbmNlIGkgYWx3 YXlzIGdldCAxMDAlIHJlc3BvbnNlIGZvciBteQ0KPiA+ID4gPj4+Pj4gUy1CRkQgcGluZw0KPiA+ ID4gcGFja2V0cy4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+PiBJIHVuZGVyc3RhbmQgdGhhdCBp ZiBwYXRoIHAyIGlzIGRvd24gKGJlY2F1c2Ugb2YgYW4gaXNzdWUgaW4NCj4gPiA+ID4+Pj4+IG9u ZSBvZiB0aGUgbm9kZXMvbGlua3MgaW4gdGhlIHBhdGgpLCB0aGUgRUNNUCBwYXRoIHdpbGwgbm90 DQo+ID4gPiA+Pj4+PiBjb250YWluIHAyLCBzaW5jZSB0aGUgcm91dGluZyBwcm90b2NvbHMgd2ls bCBuYXR1cmFsbHkgcmVtb3ZlDQo+ID4gPiA+Pj4+PiB0aGlzIGZyb20gdGhlDQo+ID4gPiBFQ01Q IGxpc3QuDQo+ID4gPiA+Pj4+PiBTbywgaXRzIG9ubHkgd2hpbGUgdGhlIG5ldHdvcmsgaXMgcmVj b252ZXJnaW5nICh3aGljaCBzaG91bGQNCj4gPiA+ID4+Pj4+IG9ubHkgbGFzdCBmb3IgYSBmZXcN Cj4gPiA+ID4+Pj4+IHNlY3MpIHRoYXQgd2Ugd2lsbCBzZWUgdGhpcy4NCj4gPiA+ID4+Pj4+DQo+ ID4gPiA+Pj4+PiBJcyBteSB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/DQo+ID4gPiA+Pj4+Pg0KPiA+ ID4gPj4+Pj4gSWYgeWVzLCB0aGVuIGlzIHRoZSBzY2VuYXJpbyB3aGVyZSBTLUJGRCBhbmQgZGF0 YSB0cmFmZmljDQo+ID4gPiA+Pj4+PiBmb2xsb3dpbmcgZGlmZmVyZW50IHBhdGhzIHNvbWV0aGlu ZyB0aGF0IHdlIHdhbnQgdG8gbG9vayBhdA0KPiA+ID4gPj4+Pj4gZml4aW5nIChlaXRoZXIgaGVy ZSBvciBzb21lIG90aGVyIFdHKT8gVGhpcyBwcm9ibGVtIGhhcw0KPiA+ID4gPj4+Pj4gYWxyZWFk eSBiZWVuIHNvbHZlZCBpbiB0aGUgTVBMUyBjb250ZXh0IHdpdGggdGhlIEVudHJvcHkNCj4gPiA+ ID4+Pj4+IGxhYmVsLiBJIGFtIHRhbGtpbmcgc3BlY2lmaWNhbGx5IGFib3V0IG5vbi1NUExTDQo+ ID4gPiA+Pj4gbmV0d29ya3MuDQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4gQ2hlZXJzLCBNYW5h dg0KPiA+ID4gPj4+Pg0KPiA+ID4gPg0KPiA+ID4NCj4gPiA+IC0tDQo+ID4gPg0KPiA+ID4NCj4g PiA+IExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWww MS5odWF3ZWkuY29tDQo+ID4gPiBTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAg ICAgICAgIGxvYUBwaS5udQ0KPiA+ID4gSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkg ICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQoNCg== From nobody Fri May 9 10:57:09 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882BE1A008A for ; Fri, 9 May 2014 10:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSOdBDKbEOEf for ; Fri, 9 May 2014 10:57:05 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BD29D1A0061 for ; Fri, 9 May 2014 10:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9243; q=dns/txt; s=iport; t=1399658221; x=1400867821; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KirqTmw4oOBV9paC/zcT5KYFJdRWhJK9RTCz/9fvGWw=; b=U7tm/Z2Bh3RCQu1rqI9NBezDuYfQju8HK75m382oBFoTaXsQR6SJiYQD PpOs9eTn3gyJ1uYEE8+1cDL/fjDbqO4lkDvolufrp1TGhaEjjZkertYAo Uqftv51Z2ZajOdkBZ6ozelbqayY8nRm0XomrlglKcnpuxrjhN9Rx4iNOY 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAE0WbVOtJA2D/2dsb2JhbABZgwaBJ8VMAYEZFnSCJQEBAQQOVwYODAICAgEIEQQBAQEnBxsGERQJCAIEAQ0FG4gSAxHKdA2GHxcEiS2DCoE1CgcBUAcGhDoEhUuECY4BgXKNHoVkgzaBbQIHFwYc X-IronPort-AV: E=Sophos;i="4.97,1019,1389744000"; d="scan'208";a="323708749" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP; 09 May 2014 17:56:50 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s49HunkL013611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 17:56:49 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 9 May 2014 12:56:49 -0500 From: "George Swallow (swallow)" To: Manav Bhatia , Sam Aldrin Subject: Re: Problem with BFD with ECMP Thread-Topic: Problem with BFD with ECMP Thread-Index: AQHPa3TYqgxrmVdW8kSgckV2Ifzfyps4g5MAgAAkYoCAAAI1gIAAAuqA///s2wA= Date: Fri, 9 May 2014 17:56:49 +0000 Message-ID: References: <536CB377.9010302@pi.nu> <7347100B5761DC41A166AC17F22DF1121B7ACA78@eusaamb103.ericsson.se> <945DB47F-1095-45E8-811A-63B6E8ED7A76@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.56.165] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2A1BBF1CC5C627439B5880F3AC4E3475@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/trSfjuvCbF_hukXg5TVYRVDlli0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 17:57:08 -0000 Manav - Wish it were true. But take a look at this from 6790: ---------------- 4.3. Transit LSR Transit LSRs MAY operate with no change in forwarding behavior. The following are suggestions for optimizations that improve load balancing, reduce the amount of packet data processed, and/or enhance backward compatibility. If a transit LSR recognizes the ELI, it MAY choose to load balance solely on the following label (the EL); otherwise, it SHOULD use as much of the whole label stack as feasible as keys for the load- balancing function. In any case, reserved labels MUST NOT be used as keys for the load-balancing function. Some transit LSRs look beyond the label stack for better load- balancing information. This is a simple, backward-compatible approach in networks where some ingress LSRs impose ELs and others don't. However, this is of limited incremental value if an EL is indeed present and requires more packet processing from the LSR. A transit LSR MAY choose to parse the label stack for the presence of the ELI and look beyond the label stack only if it does not find it, thus retaining the old behavior when needed, yet avoiding unnecessary work if not needed. ------------------ Even if all transits routers implement EL and use it in their hash, implementers are free to take stuff from elsewhere in the label stack and/or IP header. So you are not guaranteed to get the same path for OAM and data. You can only be guaranteed with the above assumptions if A) The label stack for the OAM and data are identical B) The IP headers are identical C) The UDP ports are not used in the hash by any of the transit routers D) None of the transit routers use stuff (like URLs) further into the packet in the hash George On 5/9/14 11:05 AM, "Manav Bhatia" wrote: >Ok, my point about MPLS being more predictable was this: > >You slap on an EL to an OAM packet and it takes *some* path. Now, you >if you slap on the same EL to the data traffic then it would too take >the *same* path. So there is some level of determinism, which i stated >was missing in pure IP. > >Cheers, Manav > >On Fri, May 9, 2014 at 8:24 PM, Sam Aldrin wrote: >> Hi folks, >> >> As Greg said, EL/ELI cannot predict which packet takes which path. It >>is only used to distribute flows of data packets, with an assumption >>that hashing will occur to utilize load balanced paths. >> MPLS OAM cannot predict this either. That is why, as a vendor, one >>implements various tools like trace, path trace etc. >> I see it no different to non-MPLS networks either. >> >> As far as sec 3.2 of the use case document is concerned, S-BFD is not >>replacing other OAM tools. It still performs cc checks. >> Solving ECMP issue is a never ending and don=B9t see one either, unless >>load balancing is standardized and all intermediate nodes confirmed to >>that, IMHO. >> Till that time we have to play hash tag=B9s. :D >> >> cheers >> -sam >> On May 9, 2014, at 7:46 AM, Gregory Mirsky >> wrote: >> >>> Hi Nobo, et. al, >>> I'm not sure that ELI/EL was intended to pin a flow to the particular >>>ECMP path. My understanding of EL is that it makes easier to distribute >>>flows, e.g. by assigning EL labels from label range N labels wide, [M, >>>M+N] when there are N available paths in an ECMP. I believe that there >>>is no expectation to predict with any level of certainty which >>>particular path a flow will follow but only expectation that flow with >>>EL M+2 will take different path with flow tagged by EL M+3. Certainty >>>is required though when ECMP is viewed as a link, e.g. micro-BFD. >>> >>> Regards, >>> Greg >>> >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo >>>Akiya (nobo) >>> Sent: Friday, May 09, 2014 5:37 AM >>> To: Loa Andersson; Manav Bhatia; Mach Chen >>> Cc: rtg-bfd@ietf.org >>> Subject: RE: Problem with BFD with ECMP >>> >>> Hi Manav, Mach, Loa, >>> >>> On some data planes (ex: MPLS with Entropy Label), it's less difficult >>>to use OAM packets to [likely] exercise specific ECMP paths as long as >>>there are ways to discover the entropies. >>> >>> On some others (ex: IP network), it's more difficult and I fully agree >>>with what Loa said. >>> >>> -Nobo >>> >>>> -----Original Message----- >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Loa >>>> Andersson >>>> Sent: Friday, May 09, 2014 6:53 AM >>>> To: Manav Bhatia; Mach Chen >>>> Cc: rtg-bfd@ietf.org >>>> Subject: Re: Problem with BFD with ECMP >>>> >>>> Mach and Manav, >>>> >>>> I guess that the answer to this type of question is somewhere around >>>> "Is it worth doing?". If we see an easy way to fix it and we are >>>> pretty sure that it will be deployed, then let us go ahead and do it. >>>> If the fix is shady and no one really want it, then just leave it. >>>> >>>> No in those terms where are we? >>>> >>>> /Loa >>>> >>>> On 2014-05-09 12:12, Manav Bhatia wrote: >>>>> Hi Mach, >>>>> >>>>>>> My point is this: >>>>>>> >>>>>>> How do i ensure that in an IP only network, my data traffic always >>>>>>> follows the same path as the OAM packet that i had sent to verify >>>>>>> the >>>> data plane? >>>>>> >>>>>> It's always desired, but it's hard, and most of time, no perfect >>>>>>solution. >>>>> >>>>> Sure the question is: Do we want to fix this? >>>>> >>>>>> >>>>>>> >>>>>>> Will it work if i encapsulate both the OAM and the data traffic >>>>>>> inside a GRE tunnel so that both use the same hashing fields? I >>>>>>> may want to do this for certain flows where i want a very >>>>>>> deterministic >>>> behavior. >>>>>> >>>>>> Yes, use a tunnel to encapsulate both the OAM and the data traffic >>>>>> is a >>>> candidate. >>>>>> But for a deployed network, such changes may not accepted, you >>>>>> cannot change the existing deployment model. >>>>> >>>>> We can look at the solution space later. >>>>> >>>>> The first thing is -- Do we want to solve this issue? I would wager >>>>> that its something that we would want to solve. Just want to hear >>>>> what others think about this. >>>>> >>>>> Cheers, Manav >>>>> >>>>>> >>>>>> Best regards, >>>>>> Mach >>>>>> >>>>>>> >>>>>>> Cheers, Manav >>>>>>> >>>>>>>> detect a segment of the path, means the destination of the >>>>>>>> S-BFD will be different from the user data. Then you described >>>>>>>> situation will >>>> happen. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Mach >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of >>>>>>>>> Manav Bhatia >>>>>>>>> Sent: Friday, May 09, 2014 4:02 PM >>>>>>>>> To: rtg-bfd@ietf.org >>>>>>>>> Subject: Problem with BFD with ECMP >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> There is a problem with how BFD/S-BFD works. >>>>>>>>> >>>>>>>>> Sec 3.2 draft-aldrin-bfd-seamless-use-case-01 explains how we >>>>>>>>> can use S-BFD to quickly validate the data plane before pushing >>>>>>>>> the data >>>> out. >>>>>>>>> >>>>>>>>> There is a potential issue here. >>>>>>>>> >>>>>>>>> Assume I send an S-BFD ping and I get a pong back.I believe that >>>>>>>>> the path is up and i start sending traffic towards the >>>>>>>>> Reflector, brimming with confidence, since i believe the data >>>>>>>>>plane is up. >>>>>>>>> >>>>>>>>> Assume that there is ECMP happening in the network somewhere >>>> that >>>>>>>>> splits the traffic to paths p1 and p2. >>>>>>>>> >>>>>>>>> Its possible that the S-BFD packet gets hashed to the path p1, >>>>>>>>> while the data traffic that i send gets hashed to path p2. >>>>>>>>> >>>>>>>>> If path p2 is down (or is congested and drops packets), then i >>>>>>>>> drop all traffic -- or some, in case of congestion. This however >>>>>>>>> is unexpected since i always get 100% response for my S-BFD ping >>>> packets. >>>>>>>>> >>>>>>>>> I understand that if path p2 is down (because of an issue in one >>>>>>>>> of the nodes/links in the path), the ECMP path will not contain >>>>>>>>> p2, since the routing protocols will naturally remove this from >>>>>>>>> the >>>> ECMP list. >>>>>>>>> So, its only while the network is reconverging (which should >>>>>>>>> only last for a few >>>>>>>>> secs) that we will see this. >>>>>>>>> >>>>>>>>> Is my understanding correct? >>>>>>>>> >>>>>>>>> If yes, then is the scenario where S-BFD and data traffic >>>>>>>>> following different paths something that we want to look at >>>>>>>>> fixing (either here or some other WG)? This problem has already >>>>>>>>> been solved in the MPLS context with the Entropy label. I am >>>>>>>>> talking specifically about non-MPLS >>>>>>> networks. >>>>>>>>> >>>>>>>>> Cheers, Manav >>>>>>>> >>>>> >>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> >> > From nobody Fri May 9 11:02:15 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1E21A008A for ; Fri, 9 May 2014 11:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JI_TYGtMHR_K for ; Fri, 9 May 2014 11:02:11 -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 4C3DF1A0007 for ; Fri, 9 May 2014 11:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7157; q=dns/txt; s=iport; t=1399658526; x=1400868126; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2SYY6Eo4kyqOXLyKLkyDD6p25INKgLTJ/ptpbt6RaoY=; b=ZqNDag7tTFSLKh4lqSI2Iw6k6C+1P7MqxlrXFT+1sIVOcSoRM/+90u9G 5uwAbCQc9h4WCNeCOh7XnoHteiruR+9hiDCr/3uWdIHAnxO3oUMany94L Z5oSu4CTSMD9aKtW17ps4GAycJOSTKdfMUHVwevUZZOJp8nT9NJfq8GiT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFALEXbVOtJA2K/2dsb2JhbABZgwaBJ8VMAYEZFnSCJQEBAQQ6MQ4MAgICAQgRBAEBAR4JBxsXFAkIAgQBDQUbiCbRHhcEiS2EPxEBUAcGhDoElU+DeJMCgzaBbwcXBhw X-IronPort-AV: E=Sophos;i="4.97,1019,1389744000"; d="scan'208";a="323523989" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP; 09 May 2014 18:02:05 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s49I25Bm026899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 18:02:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Fri, 9 May 2014 13:02:03 -0500 From: "George Swallow (swallow)" To: John E Drake , Gregory Mirsky , "Nobo Akiya (nobo)" , "Loa Andersson" , Manav Bhatia , Mach Chen Subject: Re: Problem with BFD with ECMP Thread-Topic: Problem with BFD with ECMP Thread-Index: AQHPa3TYqgxrmVdW8kSgckV2Ifzfyps4g5MAgAAkYoCAACNygP//0ACA Date: Fri, 9 May 2014 18:02:03 +0000 Message-ID: References: <536CB377.9010302@pi.nu> <7347100B5761DC41A166AC17F22DF1121B7ACA78@eusaamb103.ericsson.se> <6bca320c5bdd4b828a5318e526d12889@BLUPR05MB562.namprd05.prod.outlook.com> In-Reply-To: <6bca320c5bdd4b828a5318e526d12889@BLUPR05MB562.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.56.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <7004C4767C05E643A318C3AFCD8013EA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Ev4XgJCSG3IgSFEiaZJg1LhGOaM Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 18:02:13 -0000 John - Small point. Most hash functions that I've looked at take bits from various places to include in the hash. More low order bits are used that high order. =20 As a result what you get back from LSP Ping is much more like a "set of labels" than a "label range". Most likely you would see only small sets of successive labels, if you got any at all. George On 5/9/14 12:53 PM, "John E Drake" wrote: >Greg, > >RFC 4379 with Nobo's updates will tell you a range of labels that can be >used to cause an MPLS packet to take a particular ECMP path. Putting any >label from that range on a packet will force it to take that path. > >Yours Irrespectively, > >John > >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory >>Mirsky >> Sent: Friday, May 09, 2014 7:47 AM >> To: Nobo Akiya (nobo); Loa Andersson; Manav Bhatia; Mach Chen >> Cc: rtg-bfd@ietf.org >> Subject: RE: Problem with BFD with ECMP >>=20 >> Hi Nobo, et. al, >> I'm not sure that ELI/EL was intended to pin a flow to the particular >>ECMP >> path. My understanding of EL is that it makes easier to distribute >>flows, e.g. by >> assigning EL labels from label range N labels wide, [M, M+N] when there >>are N >> available paths in an ECMP. I believe that there is no expectation to >>predict >> with any level of certainty which particular path a flow will follow >>but only >> expectation that flow with EL M+2 will take different path with flow >>tagged by >> EL M+3. Certainty is required though when ECMP is viewed as a link, e.g. >> micro-BFD. >>=20 >> Regards, >> Greg >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya >> (nobo) >> Sent: Friday, May 09, 2014 5:37 AM >> To: Loa Andersson; Manav Bhatia; Mach Chen >> Cc: rtg-bfd@ietf.org >> Subject: RE: Problem with BFD with ECMP >>=20 >> Hi Manav, Mach, Loa, >>=20 >> On some data planes (ex: MPLS with Entropy Label), it's less difficult >>to use >> OAM packets to [likely] exercise specific ECMP paths as long as there >>are ways >> to discover the entropies. >>=20 >> On some others (ex: IP network), it's more difficult and I fully agree >>with what >> Loa said. >>=20 >> -Nobo >>=20 >> > -----Original Message----- >> > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Loa >> > Andersson >> > Sent: Friday, May 09, 2014 6:53 AM >> > To: Manav Bhatia; Mach Chen >> > Cc: rtg-bfd@ietf.org >> > Subject: Re: Problem with BFD with ECMP >> > >> > Mach and Manav, >> > >> > I guess that the answer to this type of question is somewhere around >> > "Is it worth doing?". If we see an easy way to fix it and we are >> > pretty sure that it will be deployed, then let us go ahead and do it. >> > If the fix is shady and no one really want it, then just leave it. >> > >> > No in those terms where are we? >> > >> > /Loa >> > >> > On 2014-05-09 12:12, Manav Bhatia wrote: >> > > Hi Mach, >> > > >> > >>> My point is this: >> > >>> >> > >>> How do i ensure that in an IP only network, my data traffic always >> > >>> follows the same path as the OAM packet that i had sent to verify >> > >>> the >> > data plane? >> > >> >> > >> It's always desired, but it's hard, and most of time, no perfect >>solution. >> > > >> > > Sure the question is: Do we want to fix this? >> > > >> > >> >> > >>> >> > >>> Will it work if i encapsulate both the OAM and the data traffic >> > >>> inside a GRE tunnel so that both use the same hashing fields? I >> > >>> may want to do this for certain flows where i want a very >> > >>> deterministic >> > behavior. >> > >> >> > >> Yes, use a tunnel to encapsulate both the OAM and the data traffic >> > >> is a >> > candidate. >> > >> But for a deployed network, such changes may not accepted, you >> > >> cannot change the existing deployment model. >> > > >> > > We can look at the solution space later. >> > > >> > > The first thing is -- Do we want to solve this issue? I would wager >> > > that its something that we would want to solve. Just want to hear >> > > what others think about this. >> > > >> > > Cheers, Manav >> > > >> > >> >> > >> Best regards, >> > >> Mach >> > >> >> > >>> >> > >>> Cheers, Manav >> > >>> >> > >>>> detect a segment of the path, means the destination of the >> > >>>> S-BFD will be different from the user data. Then you described >> > >>>> situation will >> > happen. >> > >>>> >> > >>>> Best regards, >> > >>>> Mach >> > >>>> >> > >>>>> -----Original Message----- >> > >>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of >> > >>>>> Manav Bhatia >> > >>>>> Sent: Friday, May 09, 2014 4:02 PM >> > >>>>> To: rtg-bfd@ietf.org >> > >>>>> Subject: Problem with BFD with ECMP >> > >>>>> >> > >>>>> Hi, >> > >>>>> >> > >>>>> There is a problem with how BFD/S-BFD works. >> > >>>>> >> > >>>>> Sec 3.2 draft-aldrin-bfd-seamless-use-case-01 explains how we >> > >>>>> can use S-BFD to quickly validate the data plane before pushing >> > >>>>> the data >> > out. >> > >>>>> >> > >>>>> There is a potential issue here. >> > >>>>> >> > >>>>> Assume I send an S-BFD ping and I get a pong back.I believe that >> > >>>>> the path is up and i start sending traffic towards the >> > >>>>> Reflector, brimming with confidence, since i believe the data >>plane is >> up. >> > >>>>> >> > >>>>> Assume that there is ECMP happening in the network somewhere >> > that >> > >>>>> splits the traffic to paths p1 and p2. >> > >>>>> >> > >>>>> Its possible that the S-BFD packet gets hashed to the path p1, >> > >>>>> while the data traffic that i send gets hashed to path p2. >> > >>>>> >> > >>>>> If path p2 is down (or is congested and drops packets), then i >> > >>>>> drop all traffic -- or some, in case of congestion. This however >> > >>>>> is unexpected since i always get 100% response for my S-BFD ping >> > packets. >> > >>>>> >> > >>>>> I understand that if path p2 is down (because of an issue in one >> > >>>>> of the nodes/links in the path), the ECMP path will not contain >> > >>>>> p2, since the routing protocols will naturally remove this from >> > >>>>> the >> > ECMP list. >> > >>>>> So, its only while the network is reconverging (which should >> > >>>>> only last for a few >> > >>>>> secs) that we will see this. >> > >>>>> >> > >>>>> Is my understanding correct? >> > >>>>> >> > >>>>> If yes, then is the scenario where S-BFD and data traffic >> > >>>>> following different paths something that we want to look at >> > >>>>> fixing (either here or some other WG)? This problem has already >> > >>>>> been solved in the MPLS context with the Entropy label. I am >> > >>>>> talking specifically about non-MPLS >> > >>> networks. >> > >>>>> >> > >>>>> Cheers, Manav >> > >>>> >> > > >> > >> > -- >> > >> > >> > Loa Andersson email: loa@mail01.huawei.com >> > Senior MPLS Expert loa@pi.nu >> > Huawei Technologies (consultant) phone: +46 739 81 21 64 > From nobody Fri May 9 11:13:32 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48AF1A0338 for ; Fri, 9 May 2014 11:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAzx4g5t6BmT for ; Fri, 9 May 2014 11:13:28 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 520DE1A032D for ; Fri, 9 May 2014 11:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10542; q=dns/txt; s=iport; t=1399659203; x=1400868803; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6OxgU1zfGJm/zu/WM76bGEC99PmNNeE8bHslSNF3Fo8=; b=kfIubhjWQwHf8oYRtH4PyXdMTvVGk0MVGMrTqBRKbI7lmDzRasoj2K82 ZmPk9A84WuS69S6MSkoXhlj2IcLkXE0pjLREfYlp/zi02169lJs0vp42P 6tDTNfpSw2lHoZ37c1mPxW09d94nQrgmpqQ5OVh+Ph0H6TYcdIbxEFh9Q Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFADwabVOtJA2D/2dsb2JhbABZgmUhgSfFTAGBGRZ0giUBAQEDAQ5XBg4MAgICAQgRBAEBAQodBxsGERQJCAIEAQ0FCBOIEgMJCAHKdg2GHxcEiS2DCoE1CgcBHzEHBoMlgRUEiVSOAY8QhWSDNoFtAgcXBhw X-IronPort-AV: E=Sophos;i="4.97,1019,1389744000"; d="scan'208";a="323741396" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-6.cisco.com with ESMTP; 09 May 2014 18:13:23 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s49IDMZ5022992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 18:13:22 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Fri, 9 May 2014 13:13:22 -0500 From: "Nobo Akiya (nobo)" To: "George Swallow (swallow)" , Manav Bhatia , Sam Aldrin Subject: RE: Problem with BFD with ECMP Thread-Topic: Problem with BFD with ECMP Thread-Index: AQHPa10Hnz/g8sNPJkCrTO5TJTaw35s4QxqAgAADoQCAABFvAIAAAzGAgAALU4D//8Z6YIAAevyAgAACNYCAAALrgIAAL+2A//+u78A= Date: Fri, 9 May 2014 18:13:21 +0000 Message-ID: References: <536CB377.9010302@pi.nu> <7347100B5761DC41A166AC17F22DF1121B7ACA78@eusaamb103.ericsson.se> <945DB47F-1095-45E8-811A-63B6E8ED7A76@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.75] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/CP2wLn6uqMq29P0AbFOKRUio62c Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 18:13:31 -0000 I also would like to point out draft-ietf-mpls-forwarding-09 Section 2.4.5.1 2. If an ELI label is found, then if the LSR supports entropy label, the EL label field in the next label entry (the EL) SHOULD be used and label entries below that label SHOULD NOT be used and the MPLS payload SHOULD NOT be used. See below this list for reasons. Hopefully vendors implementing EL will seriously consider above "SHOULD". -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of George > Swallow (swallow) > Sent: Friday, May 09, 2014 1:57 PM > To: Manav Bhatia; Sam Aldrin > Cc: rtg-bfd@ietf.org > Subject: Re: Problem with BFD with ECMP >=20 > Manav - >=20 > Wish it were true. But take a look at this from 6790: >=20 > ---------------- > 4.3. Transit LSR >=20 > Transit LSRs MAY operate with no change in forwarding behavior. The > following are suggestions for optimizations that improve load > balancing, reduce the amount of packet data processed, and/or enhance > backward compatibility. >=20 > If a transit LSR recognizes the ELI, it MAY choose to load balance > solely on the following label (the EL); otherwise, it SHOULD use as > much of the whole label stack as feasible as keys for the load- > balancing function. In any case, reserved labels MUST NOT be used as > keys for the load-balancing function. >=20 > Some transit LSRs look beyond the label stack for better load- > balancing information. This is a simple, backward-compatible > approach in networks where some ingress LSRs impose ELs and others > don't. However, this is of limited incremental value if an EL is > indeed present and requires more packet processing from the LSR. A > transit LSR MAY choose to parse the label stack for the presence of > the ELI and look beyond the label stack only if it does not find it, > thus retaining the old behavior when needed, yet avoiding unnecessary > work if not needed. >=20 > ------------------ >=20 > Even if all transits routers implement EL and use it in their hash, > implementers are free to take stuff from elsewhere in the label stack > and/or IP header. So you are not guaranteed to get the same path for OAM > and data. You can only be guaranteed with the above assumptions if >=20 > A) The label stack for the OAM and data are identical > B) The IP headers are identical > C) The UDP ports are not used in the hash by any of the transit routers > D) None of the transit routers use stuff (like URLs) further into the pac= ket in > the hash >=20 > George >=20 > On 5/9/14 11:05 AM, "Manav Bhatia" wrote: >=20 > >Ok, my point about MPLS being more predictable was this: > > > >You slap on an EL to an OAM packet and it takes *some* path. Now, you > >if you slap on the same EL to the data traffic then it would too take > >the *same* path. So there is some level of determinism, which i stated > >was missing in pure IP. > > > >Cheers, Manav > > > >On Fri, May 9, 2014 at 8:24 PM, Sam Aldrin wrote= : > >> Hi folks, > >> > >> As Greg said, EL/ELI cannot predict which packet takes which path. It > >>is only used to distribute flows of data packets, with an assumption > >>that hashing will occur to utilize load balanced paths. > >> MPLS OAM cannot predict this either. That is why, as a vendor, one > >>implements various tools like trace, path trace etc. > >> I see it no different to non-MPLS networks either. > >> > >> As far as sec 3.2 of the use case document is concerned, S-BFD is not > >>replacing other OAM tools. It still performs cc checks. > >> Solving ECMP issue is a never ending and don=B9t see one either, unles= s > >>load balancing is standardized and all intermediate nodes confirmed to > >>that, IMHO. > >> Till that time we have to play hash tag=B9s. :D > >> > >> cheers > >> -sam > >> On May 9, 2014, at 7:46 AM, Gregory Mirsky > >> wrote: > >> > >>> Hi Nobo, et. al, > >>> I'm not sure that ELI/EL was intended to pin a flow to the > >>>particular ECMP path. My understanding of EL is that it makes easier > >>>to distribute flows, e.g. by assigning EL labels from label range N > >>>labels wide, [M, > >>>M+N] when there are N available paths in an ECMP. I believe that > >>>M+there > >>>is no expectation to predict with any level of certainty which > >>>particular path a flow will follow but only expectation that flow > >>>with EL M+2 will take different path with flow tagged by EL M+3. > >>>Certainty is required though when ECMP is viewed as a link, e.g. micro= - > BFD. > >>> > >>> Regards, > >>> Greg > >>> > >>> -----Original Message----- > >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > >>>Akiya (nobo) > >>> Sent: Friday, May 09, 2014 5:37 AM > >>> To: Loa Andersson; Manav Bhatia; Mach Chen > >>> Cc: rtg-bfd@ietf.org > >>> Subject: RE: Problem with BFD with ECMP > >>> > >>> Hi Manav, Mach, Loa, > >>> > >>> On some data planes (ex: MPLS with Entropy Label), it's less > >>>difficult to use OAM packets to [likely] exercise specific ECMP paths > >>>as long as there are ways to discover the entropies. > >>> > >>> On some others (ex: IP network), it's more difficult and I fully > >>>agree with what Loa said. > >>> > >>> -Nobo > >>> > >>>> -----Original Message----- > >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Loa > >>>> Andersson > >>>> Sent: Friday, May 09, 2014 6:53 AM > >>>> To: Manav Bhatia; Mach Chen > >>>> Cc: rtg-bfd@ietf.org > >>>> Subject: Re: Problem with BFD with ECMP > >>>> > >>>> Mach and Manav, > >>>> > >>>> I guess that the answer to this type of question is somewhere > >>>> around "Is it worth doing?". If we see an easy way to fix it and we > >>>> are pretty sure that it will be deployed, then let us go ahead and d= o it. > >>>> If the fix is shady and no one really want it, then just leave it. > >>>> > >>>> No in those terms where are we? > >>>> > >>>> /Loa > >>>> > >>>> On 2014-05-09 12:12, Manav Bhatia wrote: > >>>>> Hi Mach, > >>>>> > >>>>>>> My point is this: > >>>>>>> > >>>>>>> How do i ensure that in an IP only network, my data traffic > >>>>>>> always follows the same path as the OAM packet that i had sent > >>>>>>> to verify the > >>>> data plane? > >>>>>> > >>>>>> It's always desired, but it's hard, and most of time, no perfect > >>>>>>solution. > >>>>> > >>>>> Sure the question is: Do we want to fix this? > >>>>> > >>>>>> > >>>>>>> > >>>>>>> Will it work if i encapsulate both the OAM and the data traffic > >>>>>>> inside a GRE tunnel so that both use the same hashing fields? I > >>>>>>> may want to do this for certain flows where i want a very > >>>>>>> deterministic > >>>> behavior. > >>>>>> > >>>>>> Yes, use a tunnel to encapsulate both the OAM and the data > >>>>>> traffic is a > >>>> candidate. > >>>>>> But for a deployed network, such changes may not accepted, you > >>>>>> cannot change the existing deployment model. > >>>>> > >>>>> We can look at the solution space later. > >>>>> > >>>>> The first thing is -- Do we want to solve this issue? I would > >>>>> wager that its something that we would want to solve. Just want to > >>>>> hear what others think about this. > >>>>> > >>>>> Cheers, Manav > >>>>> > >>>>>> > >>>>>> Best regards, > >>>>>> Mach > >>>>>> > >>>>>>> > >>>>>>> Cheers, Manav > >>>>>>> > >>>>>>>> detect a segment of the path, means the destination of the > >>>>>>>> S-BFD will be different from the user data. Then you described > >>>>>>>> situation will > >>>> happen. > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Mach > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > >>>>>>>>> Manav Bhatia > >>>>>>>>> Sent: Friday, May 09, 2014 4:02 PM > >>>>>>>>> To: rtg-bfd@ietf.org > >>>>>>>>> Subject: Problem with BFD with ECMP > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> There is a problem with how BFD/S-BFD works. > >>>>>>>>> > >>>>>>>>> Sec 3.2 draft-aldrin-bfd-seamless-use-case-01 explains how we > >>>>>>>>> can use S-BFD to quickly validate the data plane before > >>>>>>>>> pushing the data > >>>> out. > >>>>>>>>> > >>>>>>>>> There is a potential issue here. > >>>>>>>>> > >>>>>>>>> Assume I send an S-BFD ping and I get a pong back.I believe > >>>>>>>>>that the path is up and i start sending traffic towards the > >>>>>>>>>Reflector, brimming with confidence, since i believe the data > >>>>>>>>>plane is up. > >>>>>>>>> > >>>>>>>>> Assume that there is ECMP happening in the network > somewhere > >>>> that > >>>>>>>>> splits the traffic to paths p1 and p2. > >>>>>>>>> > >>>>>>>>> Its possible that the S-BFD packet gets hashed to the path p1, > >>>>>>>>> while the data traffic that i send gets hashed to path p2. > >>>>>>>>> > >>>>>>>>> If path p2 is down (or is congested and drops packets), then i > >>>>>>>>> drop all traffic -- or some, in case of congestion. This > >>>>>>>>> however is unexpected since i always get 100% response for my > >>>>>>>>> S-BFD ping > >>>> packets. > >>>>>>>>> > >>>>>>>>> I understand that if path p2 is down (because of an issue in > >>>>>>>>> one of the nodes/links in the path), the ECMP path will not > >>>>>>>>> contain p2, since the routing protocols will naturally remove > >>>>>>>>> this from the > >>>> ECMP list. > >>>>>>>>> So, its only while the network is reconverging (which should > >>>>>>>>> only last for a few > >>>>>>>>> secs) that we will see this. > >>>>>>>>> > >>>>>>>>> Is my understanding correct? > >>>>>>>>> > >>>>>>>>> If yes, then is the scenario where S-BFD and data traffic > >>>>>>>>> following different paths something that we want to look at > >>>>>>>>> fixing (either here or some other WG)? This problem has > >>>>>>>>> already been solved in the MPLS context with the Entropy > >>>>>>>>> label. I am talking specifically about non-MPLS > >>>>>>> networks. > >>>>>>>>> > >>>>>>>>> Cheers, Manav > >>>>>>>> > >>>>> > >>>> > >>>> -- > >>>> > >>>> > >>>> Loa Andersson email: loa@mail01.huawei.com > >>>> Senior MPLS Expert loa@pi.nu > >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 > >>> > >> > > From nobody Fri May 9 11:16:49 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F71C1A032E for ; Fri, 9 May 2014 11:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFN-Oiib72_C for ; Fri, 9 May 2014 11:16:44 -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 154AA1A02FA for ; Fri, 9 May 2014 11:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15002; q=dns/txt; s=iport; t=1399659399; x=1400868999; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UI0BbKW0W5HXmCr6WPoOfScN8eczS0YqyqDFpjA6QdI=; b=E2RfdmuV3nQtAUgWVmSHc9+Xl2pZyv4SE2DAJ0X1MiKPy+w1AR8QbRDV U2dCPj8OgZ7IVl8hr9JWITY1mRH5W1qefqaZnSuaFwa48L0WOGewx2nnx iEzeZn67zscB4qNfWkXI0xaVBjowZQSJLcNgCP51B5NqizT1RbT7X1Apu w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFALMabVOtJV2d/2dsb2JhbABZgwaBJ4JnwmUBGYEAFnSCJQEBAQMBDiYxBg4FBwICAgEIEQQBAQEEIwUCAhkGERQJCAIEAQ0FG4gSAwkIkD2cFgaeHw2GHxcEgSCIDYMKgTUKBwE1GwcGgmmBUQSXVYFyjR6FZIM2gW0CBxcGHA X-IronPort-AV: E=Sophos;i="4.97,1019,1389744000"; d="scan'208";a="323748497" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 09 May 2014 18:16:38 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s49IGcJb032727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 18:16:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 9 May 2014 13:16:37 -0500 From: "George Swallow (swallow)" To: "Nobo Akiya (nobo)" , Manav Bhatia , Sam Aldrin Subject: Re: Problem with BFD with ECMP Thread-Topic: Problem with BFD with ECMP Thread-Index: AQHPa3TYqgxrmVdW8kSgckV2Ifzfyps4g5MAgAAkYoCAAAI1gIAAAuqA///s2wCAAEexgP//vdgA Date: Fri, 9 May 2014 18:16:37 +0000 Message-ID: References: <536CB377.9010302@pi.nu> <7347100B5761DC41A166AC17F22DF1121B7ACA78@eusaamb103.ericsson.se> <945DB47F-1095-45E8-811A-63B6E8ED7A76@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.56.165] Content-Type: text/plain; charset="euc-kr" Content-ID: <5E543385DA4DB74A94D4951D249CAB3E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Fmz6X8tZNc_EhoJV9CqBc0nAseo Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 18:16:46 -0000 PiBIb3BlZnVsbHkgdmVuZG9ycyBpbXBsZW1lbnRpbmcgRUwgd2lsbCBzZXJpb3VzbHkgY29uc2lk ZXIgYWJvdmUgIlNIT1VMRCIuDQoNCg0KQWdyZWVkIQ0KDQpHZW9yZ2UNCg0KT24gNS85LzE0IDI6 MTMgUE0sICJOb2JvIEFraXlhIChub2JvKSIgPG5vYm9AY2lzY28uY29tPiB3cm90ZToNCg0KPkkg YWxzbyB3b3VsZCBsaWtlIHRvIHBvaW50IG91dA0KPg0KPmRyYWZ0LWlldGYtbXBscy1mb3J3YXJk aW5nLTA5DQo+U2VjdGlvbiAyLjQuNS4xDQo+DQo+ICAgMi4gIElmIGFuIEVMSSBsYWJlbCBpcyBm b3VuZCwgdGhlbiBpZiB0aGUgTFNSIHN1cHBvcnRzIGVudHJvcHkgbGFiZWwsDQo+ICAgICAgIHRo ZSBFTCBsYWJlbCBmaWVsZCBpbiB0aGUgbmV4dCBsYWJlbCBlbnRyeSAodGhlIEVMKSBTSE9VTEQg YmUNCj4gICAgICAgdXNlZCBhbmQgbGFiZWwgZW50cmllcyBiZWxvdyB0aGF0IGxhYmVsIFNIT1VM RCBOT1QgYmUgdXNlZCBhbmQNCj4gICAgICAgdGhlIE1QTFMgcGF5bG9hZCBTSE9VTEQgTk9UIGJl IHVzZWQuICBTZWUgYmVsb3cgdGhpcyBsaXN0IGZvcg0KPiAgICAgICByZWFzb25zLg0KPg0KPkhv cGVmdWxseSB2ZW5kb3JzIGltcGxlbWVudGluZyBFTCB3aWxsIHNlcmlvdXNseSBjb25zaWRlciBh Ym92ZSAiU0hPVUxEIi4NCj4NCj4tTm9ibw0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+IEZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBHZW9yZ2UNCj4+IFN3YWxsb3cgKHN3YWxsb3cpDQo+PiBTZW50OiBGcmlkYXks IE1heSAwOSwgMjAxNCAxOjU3IFBNDQo+PiBUbzogTWFuYXYgQmhhdGlhOyBTYW0gQWxkcmluDQo+ PiBDYzogcnRnLWJmZEBpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFByb2JsZW0gd2l0aCBCRkQg d2l0aCBFQ01QDQo+PiANCj4+IE1hbmF2IC0NCj4+IA0KPj4gV2lzaCBpdCB3ZXJlIHRydWUuICBC dXQgdGFrZSBhIGxvb2sgYXQgdGhpcyBmcm9tIDY3OTA6DQo+PiANCj4+IC0tLS0tLS0tLS0tLS0t LS0NCj4+IDQuMy4gIFRyYW5zaXQgTFNSDQo+PiANCj4+ICAgIFRyYW5zaXQgTFNScyBNQVkgb3Bl cmF0ZSB3aXRoIG5vIGNoYW5nZSBpbiBmb3J3YXJkaW5nIGJlaGF2aW9yLiAgVGhlDQo+PiAgICBm b2xsb3dpbmcgYXJlIHN1Z2dlc3Rpb25zIGZvciBvcHRpbWl6YXRpb25zIHRoYXQgaW1wcm92ZSBs b2FkDQo+PiAgICBiYWxhbmNpbmcsIHJlZHVjZSB0aGUgYW1vdW50IG9mIHBhY2tldCBkYXRhIHBy b2Nlc3NlZCwgYW5kL29yIGVuaGFuY2UNCj4+ICAgIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkuDQo+ PiANCj4+ICAgIElmIGEgdHJhbnNpdCBMU1IgcmVjb2duaXplcyB0aGUgRUxJLCBpdCBNQVkgY2hv b3NlIHRvIGxvYWQgYmFsYW5jZQ0KPj4gICAgc29sZWx5IG9uIHRoZSBmb2xsb3dpbmcgbGFiZWwg KHRoZSBFTCk7IG90aGVyd2lzZSwgaXQgU0hPVUxEIHVzZSBhcw0KPj4gICAgbXVjaCBvZiB0aGUg d2hvbGUgbGFiZWwgc3RhY2sgYXMgZmVhc2libGUgYXMga2V5cyBmb3IgdGhlIGxvYWQtDQo+PiAg ICBiYWxhbmNpbmcgZnVuY3Rpb24uICBJbiBhbnkgY2FzZSwgcmVzZXJ2ZWQgbGFiZWxzIE1VU1Qg Tk9UIGJlIHVzZWQgYXMNCj4+ICAgIGtleXMgZm9yIHRoZSBsb2FkLWJhbGFuY2luZyBmdW5jdGlv bi4NCj4+IA0KPj4gICAgU29tZSB0cmFuc2l0IExTUnMgbG9vayBiZXlvbmQgdGhlIGxhYmVsIHN0 YWNrIGZvciBiZXR0ZXIgbG9hZC0NCj4+ICAgIGJhbGFuY2luZyBpbmZvcm1hdGlvbi4gIFRoaXMg aXMgYSBzaW1wbGUsIGJhY2t3YXJkLWNvbXBhdGlibGUNCj4+ICAgIGFwcHJvYWNoIGluIG5ldHdv cmtzIHdoZXJlIHNvbWUgaW5ncmVzcyBMU1JzIGltcG9zZSBFTHMgYW5kIG90aGVycw0KPj4gICAg ZG9uJ3QuICBIb3dldmVyLCB0aGlzIGlzIG9mIGxpbWl0ZWQgaW5jcmVtZW50YWwgdmFsdWUgaWYg YW4gRUwgaXMNCj4+ICAgIGluZGVlZCBwcmVzZW50IGFuZCByZXF1aXJlcyBtb3JlIHBhY2tldCBw cm9jZXNzaW5nIGZyb20gdGhlIExTUi4gIEENCj4+ICAgIHRyYW5zaXQgTFNSIE1BWSBjaG9vc2Ug dG8gcGFyc2UgdGhlIGxhYmVsIHN0YWNrIGZvciB0aGUgcHJlc2VuY2Ugb2YNCj4+ICAgIHRoZSBF TEkgYW5kIGxvb2sgYmV5b25kIHRoZSBsYWJlbCBzdGFjayBvbmx5IGlmIGl0IGRvZXMgbm90IGZp bmQgaXQsDQo+PiAgICB0aHVzIHJldGFpbmluZyB0aGUgb2xkIGJlaGF2aW9yIHdoZW4gbmVlZGVk LCB5ZXQgYXZvaWRpbmcgdW5uZWNlc3NhcnkNCj4+ICAgIHdvcmsgaWYgbm90IG5lZWRlZC4NCj4+ IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiANCj4+IEV2ZW4gaWYgYWxsIHRyYW5zaXRzIHJv dXRlcnMgaW1wbGVtZW50IEVMIGFuZCB1c2UgaXQgaW4gdGhlaXIgaGFzaCwNCj4+IGltcGxlbWVu dGVycyBhcmUgZnJlZSB0byB0YWtlIHN0dWZmIGZyb20gZWxzZXdoZXJlIGluIHRoZSBsYWJlbCBz dGFjaw0KPj4gYW5kL29yIElQIGhlYWRlci4gIFNvIHlvdSBhcmUgbm90IGd1YXJhbnRlZWQgdG8g Z2V0IHRoZSBzYW1lIHBhdGggZm9yDQo+Pk9BTQ0KPj4gYW5kIGRhdGEuICBZb3UgY2FuIG9ubHkg YmUgZ3VhcmFudGVlZCB3aXRoIHRoZSBhYm92ZSBhc3N1bXB0aW9ucyBpZg0KPj4gDQo+PiBBKSBU aGUgbGFiZWwgc3RhY2sgZm9yIHRoZSBPQU0gYW5kIGRhdGEgYXJlIGlkZW50aWNhbA0KPj4gQikg VGhlIElQIGhlYWRlcnMgYXJlIGlkZW50aWNhbA0KPj4gQykgVGhlIFVEUCBwb3J0cyBhcmUgbm90 IHVzZWQgaW4gdGhlIGhhc2ggYnkgYW55IG9mIHRoZSB0cmFuc2l0IHJvdXRlcnMNCj4+IEQpIE5v bmUgb2YgdGhlIHRyYW5zaXQgcm91dGVycyB1c2Ugc3R1ZmYgKGxpa2UgVVJMcykgZnVydGhlciBp bnRvIHRoZQ0KPj5wYWNrZXQgaW4NCj4+IHRoZSBoYXNoDQo+PiANCj4+IEdlb3JnZQ0KPj4gDQo+ PiBPbiA1LzkvMTQgMTE6MDUgQU0sICJNYW5hdiBCaGF0aWEiIDxtYW5hdmJoYXRpYUBnbWFpbC5j b20+IHdyb3RlOg0KPj4gDQo+PiA+T2ssIG15IHBvaW50IGFib3V0IE1QTFMgYmVpbmcgbW9yZSBw cmVkaWN0YWJsZSB3YXMgdGhpczoNCj4+ID4NCj4+ID5Zb3Ugc2xhcCBvbiBhbiBFTCB0byBhbiBP QU0gcGFja2V0IGFuZCBpdCB0YWtlcyAqc29tZSogcGF0aC4gTm93LCB5b3UNCj4+ID5pZiB5b3Ug c2xhcCBvbiB0aGUgc2FtZSBFTCB0byB0aGUgZGF0YSB0cmFmZmljIHRoZW4gaXQgd291bGQgdG9v IHRha2UNCj4+ID50aGUgKnNhbWUqIHBhdGguIFNvIHRoZXJlIGlzIHNvbWUgbGV2ZWwgb2YgZGV0 ZXJtaW5pc20sIHdoaWNoIGkgc3RhdGVkDQo+PiA+d2FzIG1pc3NpbmcgaW4gcHVyZSBJUC4NCj4+ ID4NCj4+ID5DaGVlcnMsIE1hbmF2DQo+PiA+DQo+PiA+T24gRnJpLCBNYXkgOSwgMjAxNCBhdCA4 OjI0IFBNLCBTYW0gQWxkcmluIDxhbGRyaW4uaWV0ZkBnbWFpbC5jb20+DQo+Pndyb3RlOg0KPj4g Pj4gSGkgZm9sa3MsDQo+PiA+Pg0KPj4gPj4gQXMgR3JlZyBzYWlkLCBFTC9FTEkgY2Fubm90IHBy ZWRpY3Qgd2hpY2ggcGFja2V0IHRha2VzIHdoaWNoIHBhdGguIEl0DQo+PiA+PmlzIG9ubHkgdXNl ZCB0byBkaXN0cmlidXRlIGZsb3dzIG9mIGRhdGEgcGFja2V0cywgd2l0aCBhbiBhc3N1bXB0aW9u DQo+PiA+PnRoYXQgaGFzaGluZyB3aWxsIG9jY3VyIHRvIHV0aWxpemUgbG9hZCBiYWxhbmNlZCBw YXRocy4NCj4+ID4+IE1QTFMgT0FNIGNhbm5vdCBwcmVkaWN0IHRoaXMgZWl0aGVyLiBUaGF0IGlz IHdoeSwgYXMgYSB2ZW5kb3IsIG9uZQ0KPj4gPj5pbXBsZW1lbnRzIHZhcmlvdXMgdG9vbHMgbGlr ZSB0cmFjZSwgcGF0aCB0cmFjZSBldGMuDQo+PiA+PiBJIHNlZSBpdCBubyBkaWZmZXJlbnQgdG8g bm9uLU1QTFMgbmV0d29ya3MgZWl0aGVyLg0KPj4gPj4NCj4+ID4+IEFzIGZhciBhcyBzZWMgMy4y IG9mIHRoZSB1c2UgY2FzZSBkb2N1bWVudCBpcyBjb25jZXJuZWQsIFMtQkZEIGlzIG5vdA0KPj4g Pj5yZXBsYWNpbmcgb3RoZXIgT0FNIHRvb2xzLiBJdCBzdGlsbCBwZXJmb3JtcyBjYyBjaGVja3Mu DQo+PiA+PiBTb2x2aW5nIEVDTVAgaXNzdWUgaXMgYSBuZXZlciBlbmRpbmcgYW5kIGRvbqn2dCBz ZWUgb25lIGVpdGhlciwgdW5sZXNzDQo+PiA+PmxvYWQgYmFsYW5jaW5nIGlzIHN0YW5kYXJkaXpl ZCBhbmQgYWxsIGludGVybWVkaWF0ZSBub2RlcyBjb25maXJtZWQgdG8NCj4+ID4+dGhhdCwgSU1I Ty4NCj4+ID4+IFRpbGwgdGhhdCB0aW1lIHdlIGhhdmUgdG8gcGxheSBoYXNoIHRhZ6n2cy4gOkQN Cj4+ID4+DQo+PiA+PiBjaGVlcnMNCj4+ID4+IC1zYW0NCj4+ID4+IE9uIE1heSA5LCAyMDE0LCBh dCA3OjQ2IEFNLCBHcmVnb3J5IE1pcnNreQ0KPj4gPj48Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24u Y29tPiB3cm90ZToNCj4+ID4+DQo+PiA+Pj4gSGkgTm9ibywgZXQuIGFsLA0KPj4gPj4+IEknbSBu b3Qgc3VyZSB0aGF0IEVMSS9FTCB3YXMgaW50ZW5kZWQgdG8gcGluIGEgZmxvdyB0byB0aGUNCj4+ ID4+PnBhcnRpY3VsYXIgRUNNUCBwYXRoLiBNeSB1bmRlcnN0YW5kaW5nIG9mIEVMIGlzIHRoYXQg aXQgbWFrZXMgZWFzaWVyDQo+PiA+Pj50byBkaXN0cmlidXRlIGZsb3dzLCBlLmcuIGJ5IGFzc2ln bmluZyBFTCBsYWJlbHMgZnJvbSBsYWJlbCByYW5nZSBODQo+PiA+Pj5sYWJlbHMgd2lkZSwgW00s DQo+PiA+Pj5NK05dIHdoZW4gdGhlcmUgYXJlIE4gYXZhaWxhYmxlIHBhdGhzIGluIGFuIEVDTVAu IEkgYmVsaWV2ZSB0aGF0DQo+PiA+Pj5NK3RoZXJlDQo+PiA+Pj5pcyBubyBleHBlY3RhdGlvbiB0 byBwcmVkaWN0IHdpdGggYW55IGxldmVsIG9mIGNlcnRhaW50eSB3aGljaA0KPj4gPj4+cGFydGlj dWxhciBwYXRoIGEgZmxvdyB3aWxsIGZvbGxvdyBidXQgb25seSBleHBlY3RhdGlvbiB0aGF0IGZs b3cNCj4+ID4+PndpdGggRUwgTSsyIHdpbGwgdGFrZSBkaWZmZXJlbnQgcGF0aCB3aXRoIGZsb3cg dGFnZ2VkIGJ5IEVMIE0rMy4NCj4+ID4+PkNlcnRhaW50eSBpcyByZXF1aXJlZCB0aG91Z2ggd2hl biBFQ01QIGlzIHZpZXdlZCBhcyBhIGxpbmssIGUuZy4NCj4+bWljcm8tDQo+PiBCRkQuDQo+PiA+ Pj4NCj4+ID4+PiAgICAgICBSZWdhcmRzLA0KPj4gPj4+ICAgICAgICAgICAgICAgR3JlZw0KPj4g Pj4+DQo+PiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+PiBGcm9tOiBSdGct YmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTm9ibw0K Pj4gPj4+QWtpeWEgKG5vYm8pDQo+PiA+Pj4gU2VudDogRnJpZGF5LCBNYXkgMDksIDIwMTQgNToz NyBBTQ0KPj4gPj4+IFRvOiBMb2EgQW5kZXJzc29uOyBNYW5hdiBCaGF0aWE7IE1hY2ggQ2hlbg0K Pj4gPj4+IENjOiBydGctYmZkQGlldGYub3JnDQo+PiA+Pj4gU3ViamVjdDogUkU6IFByb2JsZW0g d2l0aCBCRkQgd2l0aCBFQ01QDQo+PiA+Pj4NCj4+ID4+PiBIaSBNYW5hdiwgTWFjaCwgTG9hLA0K Pj4gPj4+DQo+PiA+Pj4gT24gc29tZSBkYXRhIHBsYW5lcyAoZXg6IE1QTFMgd2l0aCBFbnRyb3B5 IExhYmVsKSwgaXQncyBsZXNzDQo+PiA+Pj5kaWZmaWN1bHQgdG8gdXNlIE9BTSBwYWNrZXRzIHRv IFtsaWtlbHldIGV4ZXJjaXNlIHNwZWNpZmljIEVDTVAgcGF0aHMNCj4+ID4+PmFzIGxvbmcgYXMg dGhlcmUgYXJlIHdheXMgdG8gZGlzY292ZXIgdGhlIGVudHJvcGllcy4NCj4+ID4+Pg0KPj4gPj4+ IE9uIHNvbWUgb3RoZXJzIChleDogSVAgbmV0d29yayksIGl0J3MgbW9yZSBkaWZmaWN1bHQgYW5k IEkgZnVsbHkNCj4+ID4+PmFncmVlIHdpdGggd2hhdCBMb2Egc2FpZC4NCj4+ID4+Pg0KPj4gPj4+ IC1Ob2JvDQo+PiA+Pj4NCj4+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ Pj4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIExvYQ0KPj4gPj4+PiBBbmRlcnNzb24NCj4+ID4+Pj4gU2VudDogRnJpZGF5LCBNYXkg MDksIDIwMTQgNjo1MyBBTQ0KPj4gPj4+PiBUbzogTWFuYXYgQmhhdGlhOyBNYWNoIENoZW4NCj4+ ID4+Pj4gQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4+ID4+Pj4gU3ViamVjdDogUmU6IFByb2JsZW0g d2l0aCBCRkQgd2l0aCBFQ01QDQo+PiA+Pj4+DQo+PiA+Pj4+IE1hY2ggYW5kIE1hbmF2LA0KPj4g Pj4+Pg0KPj4gPj4+PiBJIGd1ZXNzIHRoYXQgdGhlIGFuc3dlciB0byB0aGlzIHR5cGUgb2YgcXVl c3Rpb24gaXMgc29tZXdoZXJlDQo+PiA+Pj4+IGFyb3VuZCAiSXMgaXQgd29ydGggZG9pbmc/Ii4g SWYgd2Ugc2VlIGFuIGVhc3kgd2F5IHRvIGZpeCBpdCBhbmQgd2UNCj4+ID4+Pj4gYXJlIHByZXR0 eSBzdXJlIHRoYXQgaXQgd2lsbCBiZSBkZXBsb3llZCwgdGhlbiBsZXQgdXMgZ28gYWhlYWQgYW5k DQo+PmRvIGl0Lg0KPj4gPj4+PiBJZiB0aGUgZml4IGlzIHNoYWR5IGFuZCBubyBvbmUgcmVhbGx5 IHdhbnQgaXQsIHRoZW4ganVzdCBsZWF2ZSBpdC4NCj4+ID4+Pj4NCj4+ID4+Pj4gTm8gaW4gdGhv c2UgdGVybXMgd2hlcmUgYXJlIHdlPw0KPj4gPj4+Pg0KPj4gPj4+PiAvTG9hDQo+PiA+Pj4+DQo+ PiA+Pj4+IE9uIDIwMTQtMDUtMDkgMTI6MTIsIE1hbmF2IEJoYXRpYSB3cm90ZToNCj4+ID4+Pj4+ IEhpIE1hY2gsDQo+PiA+Pj4+Pg0KPj4gPj4+Pj4+PiBNeSBwb2ludCBpcyB0aGlzOg0KPj4gPj4+ Pj4+Pg0KPj4gPj4+Pj4+PiBIb3cgZG8gaSBlbnN1cmUgdGhhdCBpbiBhbiBJUCBvbmx5IG5ldHdv cmssIG15IGRhdGEgdHJhZmZpYw0KPj4gPj4+Pj4+PiBhbHdheXMgZm9sbG93cyB0aGUgc2FtZSBw YXRoIGFzIHRoZSBPQU0gcGFja2V0IHRoYXQgaSBoYWQgc2VudA0KPj4gPj4+Pj4+PiB0byB2ZXJp ZnkgdGhlDQo+PiA+Pj4+IGRhdGEgcGxhbmU/DQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+PiBJdCdzIGFs d2F5cyBkZXNpcmVkLCBidXQgaXQncyBoYXJkLCBhbmQgbW9zdCBvZiB0aW1lLCBubyBwZXJmZWN0 DQo+PiA+Pj4+Pj5zb2x1dGlvbi4NCj4+ID4+Pj4+DQo+PiA+Pj4+PiBTdXJlIHRoZSBxdWVzdGlv biBpczogRG8gd2Ugd2FudCB0byBmaXggdGhpcz8NCj4+ID4+Pj4+DQo+PiA+Pj4+Pj4NCj4+ID4+ Pj4+Pj4NCj4+ID4+Pj4+Pj4gV2lsbCBpdCB3b3JrIGlmIGkgZW5jYXBzdWxhdGUgYm90aCB0aGUg T0FNIGFuZCB0aGUgZGF0YSB0cmFmZmljDQo+PiA+Pj4+Pj4+IGluc2lkZSBhIEdSRSB0dW5uZWwg c28gdGhhdCBib3RoIHVzZSB0aGUgc2FtZSBoYXNoaW5nIGZpZWxkcz8gSQ0KPj4gPj4+Pj4+PiBt YXkgd2FudCB0byBkbyB0aGlzIGZvciBjZXJ0YWluIGZsb3dzIHdoZXJlIGkgd2FudCBhIHZlcnkN Cj4+ID4+Pj4+Pj4gZGV0ZXJtaW5pc3RpYw0KPj4gPj4+PiBiZWhhdmlvci4NCj4+ID4+Pj4+Pg0K Pj4gPj4+Pj4+IFllcywgdXNlIGEgdHVubmVsIHRvIGVuY2Fwc3VsYXRlIGJvdGggdGhlIE9BTSBh bmQgdGhlIGRhdGENCj4+ID4+Pj4+PiB0cmFmZmljIGlzIGENCj4+ID4+Pj4gY2FuZGlkYXRlLg0K Pj4gPj4+Pj4+IEJ1dCBmb3IgYSBkZXBsb3llZCBuZXR3b3JrLCBzdWNoIGNoYW5nZXMgbWF5IG5v dCBhY2NlcHRlZCwgeW91DQo+PiA+Pj4+Pj4gY2Fubm90IGNoYW5nZSB0aGUgZXhpc3RpbmcgZGVw bG95bWVudCBtb2RlbC4NCj4+ID4+Pj4+DQo+PiA+Pj4+PiBXZSBjYW4gbG9vayBhdCB0aGUgc29s dXRpb24gc3BhY2UgbGF0ZXIuDQo+PiA+Pj4+Pg0KPj4gPj4+Pj4gVGhlIGZpcnN0IHRoaW5nIGlz IC0tIERvIHdlIHdhbnQgdG8gc29sdmUgdGhpcyBpc3N1ZT8gSSB3b3VsZA0KPj4gPj4+Pj4gd2Fn ZXIgdGhhdCBpdHMgc29tZXRoaW5nIHRoYXQgd2Ugd291bGQgd2FudCB0byBzb2x2ZS4gSnVzdCB3 YW50IHRvDQo+PiA+Pj4+PiBoZWFyIHdoYXQgb3RoZXJzIHRoaW5rIGFib3V0IHRoaXMuDQo+PiA+ Pj4+Pg0KPj4gPj4+Pj4gQ2hlZXJzLCBNYW5hdg0KPj4gPj4+Pj4NCj4+ID4+Pj4+Pg0KPj4gPj4+ Pj4+IEJlc3QgcmVnYXJkcywNCj4+ID4+Pj4+PiBNYWNoDQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+Pj4N Cj4+ID4+Pj4+Pj4gQ2hlZXJzLCBNYW5hdg0KPj4gPj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4gIGRldGVj dCBhIHNlZ21lbnQgb2YgdGhlIHBhdGgsIG1lYW5zIHRoZSBkZXN0aW5hdGlvbiBvZiB0aGUNCj4+ ID4+Pj4+Pj4+IFMtQkZEIHdpbGwgYmUgZGlmZmVyZW50IGZyb20gdGhlIHVzZXIgZGF0YS4gVGhl biB5b3UgZGVzY3JpYmVkDQo+PiA+Pj4+Pj4+PiBzaXR1YXRpb24gd2lsbA0KPj4gPj4+PiBoYXBw ZW4uDQo+PiA+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4gQmVzdCByZWdhcmRzLA0KPj4gPj4+Pj4+Pj4g TWFjaA0KPj4gPj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4gPj4+Pj4+Pj4+IEZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZg0KPj4gPj4+Pj4+Pj4+IE1hbmF2IEJoYXRpYQ0KPj4gPj4+Pj4+ Pj4+IFNlbnQ6IEZyaWRheSwgTWF5IDA5LCAyMDE0IDQ6MDIgUE0NCj4+ID4+Pj4+Pj4+PiBUbzog cnRnLWJmZEBpZXRmLm9yZw0KPj4gPj4+Pj4+Pj4+IFN1YmplY3Q6IFByb2JsZW0gd2l0aCBCRkQg d2l0aCBFQ01QDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBIaSwNCj4+ID4+Pj4+Pj4+Pg0K Pj4gPj4+Pj4+Pj4+IFRoZXJlIGlzIGEgcHJvYmxlbSB3aXRoIGhvdyBCRkQvUy1CRkQgd29ya3Mu DQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBTZWMgMy4yIGRyYWZ0LWFsZHJpbi1iZmQtc2Vh bWxlc3MtdXNlLWNhc2UtMDEgZXhwbGFpbnMgaG93IHdlDQo+PiA+Pj4+Pj4+Pj4gY2FuIHVzZSBT LUJGRCB0byBxdWlja2x5IHZhbGlkYXRlIHRoZSBkYXRhIHBsYW5lIGJlZm9yZQ0KPj4gPj4+Pj4+ Pj4+IHB1c2hpbmcgdGhlIGRhdGENCj4+ID4+Pj4gb3V0Lg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+ Pj4+Pj4gVGhlcmUgaXMgYSBwb3RlbnRpYWwgaXNzdWUgaGVyZS4NCj4+ID4+Pj4+Pj4+Pg0KPj4g Pj4+Pj4+Pj4+IEFzc3VtZSBJIHNlbmQgYW4gUy1CRkQgcGluZyBhbmQgSSBnZXQgYSBwb25nIGJh Y2suSSBiZWxpZXZlDQo+PiA+Pj4+Pj4+Pj50aGF0ICB0aGUgcGF0aCBpcyB1cCBhbmQgaSBzdGFy dCBzZW5kaW5nIHRyYWZmaWMgdG93YXJkcyB0aGUNCj4+ID4+Pj4+Pj4+PlJlZmxlY3RvciwgYnJp bW1pbmcgd2l0aCBjb25maWRlbmNlLCBzaW5jZSBpIGJlbGlldmUgdGhlIGRhdGENCj4+ID4+Pj4+ Pj4+PnBsYW5lIGlzIHVwLg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gQXNzdW1lIHRoYXQg dGhlcmUgaXMgRUNNUCBoYXBwZW5pbmcgaW4gdGhlIG5ldHdvcmsNCj4+IHNvbWV3aGVyZQ0KPj4g Pj4+PiB0aGF0DQo+PiA+Pj4+Pj4+Pj4gc3BsaXRzIHRoZSB0cmFmZmljIHRvIHBhdGhzIHAxIGFu ZCBwMi4NCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IEl0cyBwb3NzaWJsZSB0aGF0IHRoZSBT LUJGRCBwYWNrZXQgZ2V0cyBoYXNoZWQgdG8gdGhlIHBhdGggcDEsDQo+PiA+Pj4+Pj4+Pj4gd2hp bGUgdGhlIGRhdGEgdHJhZmZpYyB0aGF0IGkgc2VuZCBnZXRzIGhhc2hlZCB0byBwYXRoIHAyLg0K Pj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gSWYgcGF0aCBwMiBpcyBkb3duIChvciBpcyBjb25n ZXN0ZWQgYW5kIGRyb3BzIHBhY2tldHMpLCB0aGVuIGkNCj4+ID4+Pj4+Pj4+PiBkcm9wIGFsbCB0 cmFmZmljIC0tIG9yIHNvbWUsIGluIGNhc2Ugb2YgY29uZ2VzdGlvbi4gVGhpcw0KPj4gPj4+Pj4+ Pj4+IGhvd2V2ZXIgaXMgdW5leHBlY3RlZCBzaW5jZSBpIGFsd2F5cyBnZXQgMTAwJSByZXNwb25z ZSBmb3IgbXkNCj4+ID4+Pj4+Pj4+PiBTLUJGRCBwaW5nDQo+PiA+Pj4+IHBhY2tldHMuDQo+PiA+ Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBJIHVuZGVyc3RhbmQgdGhhdCBpZiBwYXRoIHAyIGlzIGRv d24gKGJlY2F1c2Ugb2YgYW4gaXNzdWUgaW4NCj4+ID4+Pj4+Pj4+PiBvbmUgb2YgdGhlIG5vZGVz L2xpbmtzIGluIHRoZSBwYXRoKSwgdGhlIEVDTVAgcGF0aCB3aWxsIG5vdA0KPj4gPj4+Pj4+Pj4+ IGNvbnRhaW4gcDIsIHNpbmNlIHRoZSByb3V0aW5nIHByb3RvY29scyB3aWxsIG5hdHVyYWxseSBy ZW1vdmUNCj4+ID4+Pj4+Pj4+PiB0aGlzIGZyb20gdGhlDQo+PiA+Pj4+IEVDTVAgbGlzdC4NCj4+ ID4+Pj4+Pj4+PiBTbywgaXRzIG9ubHkgd2hpbGUgdGhlIG5ldHdvcmsgaXMgcmVjb252ZXJnaW5n ICh3aGljaCBzaG91bGQNCj4+ID4+Pj4+Pj4+PiBvbmx5IGxhc3QgZm9yIGEgZmV3DQo+PiA+Pj4+ Pj4+Pj4gc2VjcykgdGhhdCB3ZSB3aWxsIHNlZSB0aGlzLg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+ Pj4+Pj4gSXMgbXkgdW5kZXJzdGFuZGluZyBjb3JyZWN0Pw0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+ Pj4+Pj4gSWYgeWVzLCB0aGVuIGlzIHRoZSBzY2VuYXJpbyB3aGVyZSBTLUJGRCBhbmQgZGF0YSB0 cmFmZmljDQo+PiA+Pj4+Pj4+Pj4gZm9sbG93aW5nIGRpZmZlcmVudCBwYXRocyBzb21ldGhpbmcg dGhhdCB3ZSB3YW50IHRvIGxvb2sgYXQNCj4+ID4+Pj4+Pj4+PiBmaXhpbmcgKGVpdGhlciBoZXJl IG9yIHNvbWUgb3RoZXIgV0cpPyBUaGlzIHByb2JsZW0gaGFzDQo+PiA+Pj4+Pj4+Pj4gYWxyZWFk eSBiZWVuIHNvbHZlZCBpbiB0aGUgTVBMUyBjb250ZXh0IHdpdGggdGhlIEVudHJvcHkNCj4+ID4+ Pj4+Pj4+PiBsYWJlbC4gSSBhbSB0YWxraW5nIHNwZWNpZmljYWxseSBhYm91dCBub24tTVBMUw0K Pj4gPj4+Pj4+PiBuZXR3b3Jrcy4NCj4+ID4+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4+IENoZWVycywg TWFuYXYNCj4+ID4+Pj4+Pj4+DQo+PiA+Pj4+Pg0KPj4gPj4+Pg0KPj4gPj4+PiAtLQ0KPj4gPj4+ Pg0KPj4gPj4+Pg0KPj4gPj4+PiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAg ZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPj4gPj4+PiBTZW5pb3IgTVBMUyBFeHBlcnQg ICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KPj4gPj4+PiBIdWF3ZWkgVGVjaG5v bG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCj4+ID4+Pg0K Pj4gPj4NCj4+ID4NCj4NCg0K From nobody Fri May 9 12:02:41 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048D31A0312 for ; Fri, 9 May 2014 12:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eH45gfWZOLd for ; Fri, 9 May 2014 12:02:34 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) by ietfa.amsl.com (Postfix) with ESMTP id F26181A030E for ; Fri, 9 May 2014 12:02:33 -0700 (PDT) Received: from BLUPR05MB561.namprd05.prod.outlook.com (10.141.202.139) by BLUPR05MB451.namprd05.prod.outlook.com (10.141.28.26) with Microsoft SMTP Server (TLS) id 15.0.939.12; Fri, 9 May 2014 19:02:28 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB561.namprd05.prod.outlook.com (10.141.202.139) with Microsoft SMTP Server (TLS) id 15.0.934.12; Fri, 9 May 2014 19:02:26 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0934.000; Fri, 9 May 2014 19:02:26 +0000 From: John E Drake To: "Nobo Akiya (nobo)" , Gregory Mirsky , Loa Andersson , Manav Bhatia , Mach Chen Subject: RE: Problem with BFD with ECMP Thread-Topic: Problem with BFD with ECMP Thread-Index: AQHPa10qii8Co2K1/kyctSJEs2tlIJs370iAgAADoQCAABFvAIAAAzGAgAALU4CAAB0VAIAAJGGAgAAitOCAAAp3AIAAGcYw Date: Fri, 9 May 2014 19:02:26 +0000 Message-ID: References: <536CB377.9010302@pi.nu> <7347100B5761DC41A166AC17F22DF1121B7ACA78@eusaamb103.ericsson.se> <6bca320c5bdd4b828a5318e526d12889@BLUPR05MB562.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(13464003)(51704005)(377454003)(83072002)(2656002)(79102001)(87936001)(74502001)(74316001)(101416001)(81342001)(99286001)(76176999)(50986999)(92566001)(54356999)(77096999)(81542001)(74662001)(76482001)(21056001)(76576001)(33646001)(19580395003)(20776003)(83322001)(19580405001)(77982001)(66066001)(46102001)(64706001)(31966008)(4396001)(86362001)(80022001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB561; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/moFZjUvwdkTOWiYzJP60HQqdDcs Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 19:02:39 -0000 U25pcHBlZCwgY29tbWVudCBpbmxpbmUNCg0KWW91cnMgSXJyZXNwZWN0aXZlbHksDQoNCkpvaG4N Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBOb2JvIEFraXlhIChub2Jv KSBbbWFpbHRvOm5vYm9AY2lzY28uY29tXQ0KPiBTZW50OiBGcmlkYXksIE1heSAwOSwgMjAxNCAx MDoyOSBBTQ0KPiBUbzogSm9obiBFIERyYWtlOyBHcmVnb3J5IE1pcnNreTsgTG9hIEFuZGVyc3Nv bjsgTWFuYXYgQmhhdGlhOyBNYWNoIENoZW4NCj4gQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUkU6IFByb2JsZW0gd2l0aCBCRkQgd2l0aCBFQ01QDQo+IA0KPiBIaSBKb2huLCBHcmVn LA0KPiANCj4gW0pvaG4gd3JvdGVdDQo+ID4gUkZDIDQzNzkgd2l0aCBOb2JvJ3MgdXBkYXRlcyB3 aWxsIHRlbGwgeW91IGEgcmFuZ2Ugb2YgbGFiZWxzIHRoYXQgY2FuDQo+ID4gYmUgdXNlZCB0byBj YXVzZSBhbiBNUExTIHBhY2tldCB0byB0YWtlIGEgcGFydGljdWxhciBFQ01QIHBhdGguDQo+ID4g UHV0dGluZyBhbnkgbGFiZWwgZnJvbSB0aGF0IHJhbmdlIG9uIGEgcGFja2V0IHdpbGwgZm9yY2Ug aXQgdG8gdGFrZSB0aGF0IHBhdGguDQo+IA0KPiBDb3JyZWN0LiBPbmUgd291bGQgc3RpbGwgd2Fu dCB0byBydW4gTFNQIHRyZWUvcGF0aCB0cmFjZSAoUkZDNDM3OSArIG11bHRpcGF0aA0KPiBpbmZv IGZvciBFTCkgZXZlcnkgbm93IGFuZCB0aGVuIHRvIHJlZnJlc2ggdGhlIChwYXRocyArIEVMcyks IGJ1dCB0aGF0J3MgdGhlDQo+IGludGVudC4gQW5kIHdlIGlmIGNvdWxkIHVzZSBTLUJGRCBmb3Ig aW4tYmFuZCBtb25pdG9yaW5nIG9mIGV2ZXJ5IHBhdGhzLCB0aGF0J3MNCj4gYSBmYWlybHkgZ29v ZCBjb3ZlcmFnZSAobm90IHBlcmZlY3QsIGJ1dCBmYWlybHkgZ29vZCkgZm9yIE1QTFMuDQo+IA0K DQpbSkRdICBJdCB3YXMgYWx3YXlzIG15IGludGVudGlvbiB0byBkbyBleGFjdGx5IHRoaXMgYnV0 IEkgbmV2ZXIgZ290IGFyb3VuZCB0byB1cGRhdGluZyBSRkMgNDM3OSANCg0K From nobody Fri May 9 16:59:17 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EB11A0126 for ; Fri, 9 May 2014 16:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qpNCyWNTsVa for ; Fri, 9 May 2014 16:59:10 -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 22C071A011E for ; Fri, 9 May 2014 16:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9730; q=dns/txt; s=iport; t=1399679945; x=1400889545; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=99CaEXWVvd2NrmCcg2S2AV6jDaXlRMRUfQnhF0BRl2o=; b=mDZZ6W9h/FtZzSOXVzFF/Kxpy9tzjrCPuGrdLQL+l5/u8i4AL3OpSgWk YqhYysLdrLZU3R+QcifEC7W9syuj2r5OK5Nu+Ldph0iVD2Mj9tcMZeT5B bK9HOmTHQadD34TJp0C2smtNq6Wl0cWTUzsRfbtP/z4trAE7u1CNrVXv1 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAKtqbVOtJA2M/2dsb2JhbABZgmUhgSfFVAGBGRZ0giUBAQEDATo9AgwEAgEIEQQBAQEKFAkHMhQJCAIEDgUIiDEIAdErF41wEQEfMQcGgyWBFQEDrEmDNoF2OQ X-IronPort-AV: E=Sophos;i="4.97,1021,1389744000"; d="scan'208";a="323830701" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-3.cisco.com with ESMTP; 09 May 2014 23:59:04 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s49Nx49E025235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 23:59:04 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Fri, 9 May 2014 18:59:04 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger Subject: RE: New version notification for draft-akiya-bfd-seamless-base-03.txt Thread-Topic: New version notification for draft-akiya-bfd-seamless-base-03.txt Thread-Index: AQHPWjuSIo9hc5e0sES09J7I8hmrpZszQ9oAgAIcNkCAAPhVgIACr81g Date: Fri, 9 May 2014 23:59:03 +0000 Message-ID: References: <20140505192404062506.fcd0c154@sniff.de> <20140507182623711086.aef91e5c@sniff.de> In-Reply-To: <20140507182623711086.aef91e5c@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.243.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/1Z_zBn5iThvMPJucZzL2oB2vsEo Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 23:59:13 -0000 Hi Marc, Thanks for the reply as well! Please see in-line. > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Wednesday, May 07, 2014 9:26 PM > To: Nobo Akiya (nobo) > Cc: MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org > Subject: RE: New version notification for draft-akiya-bfd-seamless-base- > 03.txt >=20 > Hello Nobo, >=20 > thanks for the reply! >=20 >=20 > > P bit should be followed with F bit from the other side, in both > > directions. So P/F bits aren't copied from received packet to > > transmitted packet at the reflector session. >=20 > ah okay, the reflector sees "P" and sets "F" when sending the reflected > packet? Good idea. >=20 >=20 > > If we strictly look at this from the protocol perspective, there is no = need > > for the initiator to have INIT state >=20 > agree, a minimal FSM can do without. >=20 > > (it doesn't even make sense to have one). >=20 > disagree, it can serve a purpose. Effectively the same it does for async = BFD, > that you are not jumping immediately into Up state again on receiving an > "Up" > packet. You first need to confirm the Down, which for S-BFD means you see > your own Down first before. You are "flushing out" all Up packets in the = path. >=20 > Otherwise you may see flaps, depending on the interruption. Which of > course > you can cure with holddown timers in your implementation - but why not > using > this nice (?) behaviour of the existing FSM? I can imagine a persistent initiator session, which initiator state will be= useful (whether INIT is included or not). I can also imagine a module that throws out an S-BFD packet once (when need= ed) and then goes on to do something else, which initiator state is really = useless (getting a response back in timely manner is all it cares about). I can also imagine variants on how I want the initiator to behave. Perhaps the draft should focus less on the initiator side entirely and focu= s mostly on standardizing the reflector session behavior. >=20 >=20 > > We may need to add ADMINDOWN back in though ... > > thoughts? >=20 > maybe not necessary but useful, yes. >=20 >=20 > > Now, if we apply the new FSM to existing implementation, I suppose > RFC5880 > > FSM can be re-used, as long as the implementation properly transitions > > *through* INIT state. But I see this as an implementation detail, and > > should be left out from the document. >=20 > my point is that a new FSM means "work" on the Initiator side. If this is > complete new code or just a modification - speculation, it depends on the > code/hw. Preferably (for me) there would be no change on the Initiator si= de > and all changes on the Reflector side, which needs to be implemented > "from > scratch" anyway. Well, see below. >=20 >=20 > From a formal point of view ... I don't mind a new FSM but we should then > stop referring to RFC5880. Actually the D-flag is the same story, the new > state variable does not make it compatible to RFC5880 (*) IMHO. Not necessary. bfd-multipoint extends RFC5880 by introducing new state vari= ables and new procedures. >=20 > Depends on what you want: you can write a "new" BFD for the Initiator wit= h > some references to or copies from RFC5880, e.g. C-Bit and Poll sequence I > guess can be borrowed 1:1. There is nothing wrong with it, it may be actu= ally > more honest and avoids rules that only serve the compatibility, not the > functionality. You can define a new FSM, you can use the place of the D-b= it > for your R-eflector bit etc.. >=20 > The other extreme would be to re-use the existing packet engine (I/O, FSM= , > 5880 rules). Running existing BFD 5880/5881 against a simple reflector do= es > work (tested, yes :-) , so I guess this would work for your more elaborat= e > reflector as well. And if it doesn't work, then see above, go with a clea= n > new definition. > I say "packet engine" because that part matters for IETF, for the interop= . > The code e.g. selecting a discriminator will likely change as you have ne= w > requirements for S-BFD. But that code is largely "implementation specific= " > and outside the scope of most documents. As I read this email, I'm getting more convinced that S-BFD reflector is wh= at needs to be standardized. How initiator behaves really doesn't matter, a= s long as it sends packets to reflectors according to what we define as the= standard of reflector behavior. >=20 >=20 > Regards, Marc >=20 > (*): it is a nice structure for the implementor though. Wrap "if (!sbf) {= ... > }" around existing Demand code and add "if (sbfd) { ... }" for the S-BFD > D-flag code. But that was not why several people including me had a bad > feeling. Perhaps a portion of existing BFD code can be reused when initiator is used= as a persistent session, and I'm sure that will happen. But S-BFD also req= uires no bootstrapping, no need for sedated bring-up sequence, no need to "= bring down the session gracefully/ungracefully" - just stop when you want t= o, etc. And obviously initiator doesn't necessary have to be a persistent s= ession like today. -Nobo >=20 >=20 >=20 > On Wed, 7 May 2014 16:59:35 +0000, Nobo Akiya (nobo) wrote: > > Hi Marc, > > > > Please see inline. > > > >> -----Original Message----- > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc > >> Binderberger > >> Sent: Monday, May 05, 2014 10:24 PM > >> To: MALLIK MUDIGONDA (mmudigon) > >> Cc: rtg-bfd@ietf.org > >> Subject: Re: New version notification for draft-akiya-bfd-seamless-bas= e- > >> 03.txt > >> > >> Hello Mallik and authors, > >> > >> reading the new draft version, here some first feedback: > > > > Thanks for the first feedback! > > Look forward to seeing more :) > > > >> > >> (1) You are fairly detailed in sections 9.2.2 and 9.3 what to copy ove= r > >> from > >> the received into the responder packet but it does not mention what th= e > >> reflector is doing with the P/F flags. I assume it needs to copy them = into > >> the > >> reflected packet? > > > > P bit should be followed with F bit from the other side, in both > > directions. So P/F bits aren't copied from received packet to transmitt= ed > > packet at the reflector session. > > > >> > >> Sure, you say in 9.5 "The Poll sequence MUST operate in accordance wit= h > >> [RFC5880]." but details are missing. > > > > Agree, entire section 9 can benefit from a bit of restructuring. > > > >> > >> > >> (2) What I'm still wondering: why do you want to change the RFC5880 > state > >> machine? I would assume that if you want to re-use code/hw on the > >> Initiator > >> side then that's the last thing to change. And you don't need to: > >> > >> * Initiator sends out the usual Down/Init/Up as per RFC5880 > >> * Reflector simply copies the state into the reply packet > >> (or overwrites the state field with AdminDown) > >> > >> Play it through - it works ;-) More important there is a subtle diffe= rence > >> of simply going to "Up" state when receiving "Up" packets and filling = the > >> packet path with Down, then Init, then Up. > > > > If we strictly look at this from the protocol perspective, there is no = need > > for the initiator to have INIT state (it doesn't even make sense to hav= e > > one). ADMINDOWN might still be useful to have, to allow the initiator > > session to be enabled/disabled. Thu I think it's correct for the new FS= M to > > be available for this. We may need to add ADMINDOWN back in though ... > > thoughts? > > > > Now, if we apply the new FSM to existing implementation, I suppose > RFC5880 > > FSM can be re-used, as long as the implementation properly transitions > > *through* INIT state. But I see this as an implementation detail, and > > should be left out from the document. > > > >> > >> > >> (3) Nitpick: section 9.1.1 says "The notation on each arc represents t= he > >> state of the remote system" - there is no state of the remote system, = the > >> reflector is stateless ;-) > > > > Good catch. Agree that sentence should be rewritten to remove "state of > the > > remote system" out. > > > >> > >> > >> (4) Section 11 "Scaling Aspects". The "total number of BFD sessions in= a > >> network" - why would this be a relevant number? This is not RSVP-based > TE > >> tunnels where some core nodes may indeed come close to the N * (N - 1) > >> number > >> of RSVP tunnel state for an any-any mesh. But a BFD session is just a = bit > >> of > >> traffic in the forwarding plane for most routers, only sender/receiver > >> take a > >> hit. > >> True, there is still the factor of about "2" per single router. I woul= d > >> propose keeping the first paragraph of 11 but remove the rest. > > > > You are right, everything below the first paragraph is just a bit noisy= . > > Yes I agree that we should only keep the first paragraph of section 11 > > (i.e. remove the rest). > > > > -Nobo > > > >> > >> > >> Have to re-read your draft for the other parts, especially the D-bit ;= -) > >> > >> > >> Regards, Marc > >> > >> > >> > >> On Thu, 17 Apr 2014 12:50:12 +0000, MALLIK MUDIGONDA (mmudigon) > >> wrote: > >>> Hello BFD WG Members, > >>> > >>> We have published a new version of Seamless BFD draft, > >>> draft-akiya-bfd-seamless-base-03. Several sections have been updated > for > >>> improving readability. It also has a few technical changes as well. P= lease > >>> review the draft and get back to us with your comments. > >>> > >>> Thanks > >>> > >>> Regards > >>> Mallik > > From nobody Fri May 9 17:08:26 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC4C1A0130 for ; Fri, 9 May 2014 17:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJ4QAacesYwx for ; Fri, 9 May 2014 17:08:21 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2C51A012B for ; Fri, 9 May 2014 17:08:21 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id vb8so5736072obc.0 for ; Fri, 09 May 2014 17:08:16 -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:content-transfer-encoding; bh=6w6vvv9uVUMdp2UEhqPdIujd7AGtUYdl/l0vCSg2vH0=; b=naIy2jQNbxMAL8zW3KOJ7ZOQzZR+XX+u2dhGzj5n3TOyNh82nnukIDKXoFkTOeF39+ Q/oJYHxzvNTK1cWTVpv+8tCSnPdwUCpDZ/23VCK3z34SPXoEj4wpwvW5RzenjDk70js7 UrOk+/pxVr7Bs47k2Wy9WCLN4nRJjKlNCajLBsezI8Jz/pp7bckPib9Mvf5mzUTAz2Tp 3IfBidHZTvXxcmB14P3MxXIEGdiYmrShI6n/loPqJhqMF642mwRHICSbC97422XCBoHw 4jYg4N5CfCCU03pfUYcJalCtccAr8Nqom0D/uFg9cE98Yfbj0P0ZV5aasVup/2Kw/adn ObCw== MIME-Version: 1.0 X-Received: by 10.60.96.165 with SMTP id dt5mr17104389oeb.72.1399680495963; Fri, 09 May 2014 17:08:15 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Fri, 9 May 2014 17:08:15 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7ACB0A@eusaamb103.ericsson.se> References: <536CB377.9010302@pi.nu> <7347100B5761DC41A166AC17F22DF1121B7ACA78@eusaamb103.ericsson.se> <945DB47F-1095-45E8-811A-63B6E8ED7A76@gmail.com> <7347100B5761DC41A166AC17F22DF1121B7ACB0A@eusaamb103.ericsson.se> Date: Sat, 10 May 2014 05:38:15 +0530 Message-ID: Subject: Re: Problem with BFD with ECMP From: Manav Bhatia To: Gregory Mirsky Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/XAAnhD8z98A35PInDB3yh7qyj-A Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 10 May 2014 00:08:23 -0000 Hi Greg, This is very difficult to mandate since in most cases we would like to spread the traffic flows across multiple ECMP paths. Its only in certain very specific cases where we would want the data to strictly follow the IP OAM (S-BFD/BFD) packet. This i was wondering could be possibly be achieved by encapsulating the S-BFD and the data packet inside an IP-in-IP or a GRE header. This way the 5 tuple hash computation would yield the same result for the OAM and the data packets. Cheers, Manav On Fri, May 9, 2014 at 8:39 PM, Gregory Mirsky wrote: > Hi Manav, > yes, there's problem with satisfying "in-band" requirement for IP OAM. I = recall that Nobo and I had discussed it though briefly and agreed that if "= in-band" OAM requirement is indeed strong then hashing should not use port = numbers, e.g. be based on IP SA/DA. > > Regards, > Greg > > -----Original Message----- > From: Manav Bhatia [mailto:manavbhatia@gmail.com] > Sent: Friday, May 09, 2014 8:05 AM > To: Sam Aldrin > Cc: Gregory Mirsky; Nobo Akiya (nobo); loa@pi.nu; Mach Chen; rtg-bfd@ietf= .org > Subject: Re: Problem with BFD with ECMP > > Ok, my point about MPLS being more predictable was this: > > You slap on an EL to an OAM packet and it takes *some* path. Now, you if = you slap on the same EL to the data traffic then it would too take the *sam= e* path. So there is some level of determinism, which i stated was missing = in pure IP. > > Cheers, Manav > > On Fri, May 9, 2014 at 8:24 PM, Sam Aldrin wrote: >> Hi folks, >> >> As Greg said, EL/ELI cannot predict which packet takes which path. It is= only used to distribute flows of data packets, with an assumption that has= hing will occur to utilize load balanced paths. >> MPLS OAM cannot predict this either. That is why, as a vendor, one imple= ments various tools like trace, path trace etc. >> I see it no different to non-MPLS networks either. >> >> As far as sec 3.2 of the use case document is concerned, S-BFD is not re= placing other OAM tools. It still performs cc checks. >> Solving ECMP issue is a never ending and don=E2=80=99t see one either, u= nless load balancing is standardized and all intermediate nodes confirmed t= o that, IMHO. >> Till that time we have to play hash tag=E2=80=99s. :D >> >> cheers >> -sam >> On May 9, 2014, at 7:46 AM, Gregory Mirsky = wrote: >> >>> Hi Nobo, et. al, >>> I'm not sure that ELI/EL was intended to pin a flow to the particular E= CMP path. My understanding of EL is that it makes easier to distribute flow= s, e.g. by assigning EL labels from label range N labels wide, [M, M+N] whe= n there are N available paths in an ECMP. I believe that there is no expect= ation to predict with any level of certainty which particular path a flow w= ill follow but only expectation that flow with EL M+2 will take different p= ath with flow tagged by EL M+3. Certainty is required though when ECMP is v= iewed as a link, e.g. micro-BFD. >>> >>> Regards, >>> Greg >>> >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo >>> Akiya (nobo) >>> Sent: Friday, May 09, 2014 5:37 AM >>> To: Loa Andersson; Manav Bhatia; Mach Chen >>> Cc: rtg-bfd@ietf.org >>> Subject: RE: Problem with BFD with ECMP >>> >>> Hi Manav, Mach, Loa, >>> >>> On some data planes (ex: MPLS with Entropy Label), it's less difficult = to use OAM packets to [likely] exercise specific ECMP paths as long as ther= e are ways to discover the entropies. >>> >>> On some others (ex: IP network), it's more difficult and I fully agree = with what Loa said. >>> >>> -Nobo >>> >>>> -----Original Message----- >>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Loa >>>> Andersson >>>> Sent: Friday, May 09, 2014 6:53 AM >>>> To: Manav Bhatia; Mach Chen >>>> Cc: rtg-bfd@ietf.org >>>> Subject: Re: Problem with BFD with ECMP >>>> >>>> Mach and Manav, >>>> >>>> I guess that the answer to this type of question is somewhere around >>>> "Is it worth doing?". If we see an easy way to fix it and we are >>>> pretty sure that it will be deployed, then let us go ahead and do it. >>>> If the fix is shady and no one really want it, then just leave it. >>>> >>>> No in those terms where are we? >>>> >>>> /Loa >>>> >>>> On 2014-05-09 12:12, Manav Bhatia wrote: >>>>> Hi Mach, >>>>> >>>>>>> My point is this: >>>>>>> >>>>>>> How do i ensure that in an IP only network, my data traffic >>>>>>> always follows the same path as the OAM packet that i had sent to >>>>>>> verify the >>>> data plane? >>>>>> >>>>>> It's always desired, but it's hard, and most of time, no perfect sol= ution. >>>>> >>>>> Sure the question is: Do we want to fix this? >>>>> >>>>>> >>>>>>> >>>>>>> Will it work if i encapsulate both the OAM and the data traffic >>>>>>> inside a GRE tunnel so that both use the same hashing fields? I >>>>>>> may want to do this for certain flows where i want a very >>>>>>> deterministic >>>> behavior. >>>>>> >>>>>> Yes, use a tunnel to encapsulate both the OAM and the data traffic >>>>>> is a >>>> candidate. >>>>>> But for a deployed network, such changes may not accepted, you >>>>>> cannot change the existing deployment model. >>>>> >>>>> We can look at the solution space later. >>>>> >>>>> The first thing is -- Do we want to solve this issue? I would wager >>>>> that its something that we would want to solve. Just want to hear >>>>> what others think about this. >>>>> >>>>> Cheers, Manav >>>>> >>>>>> >>>>>> Best regards, >>>>>> Mach >>>>>> >>>>>>> >>>>>>> Cheers, Manav >>>>>>> >>>>>>>> detect a segment of the path, means the destination of the >>>>>>>> S-BFD will be different from the user data. Then you described >>>>>>>> situation will >>>> happen. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Mach >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of >>>>>>>>> Manav Bhatia >>>>>>>>> Sent: Friday, May 09, 2014 4:02 PM >>>>>>>>> To: rtg-bfd@ietf.org >>>>>>>>> Subject: Problem with BFD with ECMP >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> There is a problem with how BFD/S-BFD works. >>>>>>>>> >>>>>>>>> Sec 3.2 draft-aldrin-bfd-seamless-use-case-01 explains how we >>>>>>>>> can use S-BFD to quickly validate the data plane before pushing >>>>>>>>> the data >>>> out. >>>>>>>>> >>>>>>>>> There is a potential issue here. >>>>>>>>> >>>>>>>>> Assume I send an S-BFD ping and I get a pong back.I believe >>>>>>>>> that the path is up and i start sending traffic towards the >>>>>>>>> Reflector, brimming with confidence, since i believe the data pla= ne is up. >>>>>>>>> >>>>>>>>> Assume that there is ECMP happening in the network somewhere >>>> that >>>>>>>>> splits the traffic to paths p1 and p2. >>>>>>>>> >>>>>>>>> Its possible that the S-BFD packet gets hashed to the path p1, >>>>>>>>> while the data traffic that i send gets hashed to path p2. >>>>>>>>> >>>>>>>>> If path p2 is down (or is congested and drops packets), then i >>>>>>>>> drop all traffic -- or some, in case of congestion. This >>>>>>>>> however is unexpected since i always get 100% response for my >>>>>>>>> S-BFD ping >>>> packets. >>>>>>>>> >>>>>>>>> I understand that if path p2 is down (because of an issue in >>>>>>>>> one of the nodes/links in the path), the ECMP path will not >>>>>>>>> contain p2, since the routing protocols will naturally remove >>>>>>>>> this from the >>>> ECMP list. >>>>>>>>> So, its only while the network is reconverging (which should >>>>>>>>> only last for a few >>>>>>>>> secs) that we will see this. >>>>>>>>> >>>>>>>>> Is my understanding correct? >>>>>>>>> >>>>>>>>> If yes, then is the scenario where S-BFD and data traffic >>>>>>>>> following different paths something that we want to look at >>>>>>>>> fixing (either here or some other WG)? This problem has already >>>>>>>>> been solved in the MPLS context with the Entropy label. I am >>>>>>>>> talking specifically about non-MPLS >>>>>>> networks. >>>>>>>>> >>>>>>>>> Cheers, Manav >>>>>>>> >>>>> >>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> >> From nobody Fri May 9 19:04:49 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC9C1A0171 for ; Fri, 9 May 2014 19:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SArEE3sOqYlk for ; Fri, 9 May 2014 19:04:42 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id BC94D1A0168 for ; Fri, 9 May 2014 19:04:41 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-b8-536d3a11a670 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 25.20.07420.11A3D635; Fri, 9 May 2014 22:26:57 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Fri, 9 May 2014 22:04:35 -0400 From: Gregory Mirsky To: Manav Bhatia Subject: RE: Problem with BFD with ECMP Thread-Topic: Problem with BFD with ECMP Thread-Index: AQHPa10FR1gHtZZKvUKBKUPQtfY0Zps4MleAgAADoACAABFwAIAAAzCAgAALU4CAAB0VAP//3u0QgABHqoCAAALqgP//vSnwgADai4D//9oUgA== Date: Sat, 10 May 2014 02:04:34 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7ACF65@eusaamb103.ericsson.se> References: <536CB377.9010302@pi.nu> <7347100B5761DC41A166AC17F22DF1121B7ACA78@eusaamb103.ericsson.se> <945DB47F-1095-45E8-811A-63B6E8ED7A76@gmail.com> <7347100B5761DC41A166AC17F22DF1121B7ACB0A@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZXLonVlfQKjfY4ONiJYsJrV8YLf7NncNs cWGtsMXlSW3sFrM74i0+/9nG6MDmMeX3RlaPnbPusnu0HHnL6rFkyU8mj1nT29gCWKO4bFJS czLLUov07RK4Ml7828pe0JJesfrETMYGxg0pXYwcHBICJhLvdmh1MXICmWISF+6tZ+ti5OIQ EjjKKHGo9xQjhLOMUaL7zC8mkCo2ASOJFxt72EFsEQENidb3B5hBipgFNjFKfLzUwQqSEBZQ l3g+/y0bTNG2GU2sEHadxLTDXYwgNouAqsSOu7/B4rwCvhJ71y9lhtg2l03i7tofYAlOgUCJ njefwBoYge77fmoN2BXMAuISt57MZ4K4W0BiyZ7zzBC2qMTLx/9YIWwliTmvrzGDvMksoCmx fpc+RKuixJTuh+wQewUlTs58wjKBUWwWkqmzEDpmIemYhaRjASPLKkaO0uLUstx0I4NNjMA4 OybBpruDcc9Ly0OMAhyMSjy8CstzgoVYE8uKK3MPMUpzsCiJ8xZ8iQ0WEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwKg5h3edopq9OMOz4vpF5r6Jkjy8diePnZ913vvyWv7Zlk/3VnTUGV5P uK9zdd2xdR9FqisEvptWzM2Ljbi6NEesrL34pdr1KW1zSxb9VeTg/FPw8tm0762rthS8nbB3 /QE1BQ6OqelsxWxK7+49CYjPV3iz8Iem2IHiOf8KmRYYTUu4syUy+JISS3FGoqEWc1FxIgA2 M1y7lAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/_5T9k5hZmVN95XSmOTPlvutHAjg Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 10 May 2014 02:04:45 -0000 SGkgTWFuYXYsDQpJIGFncmVlIHRoYXQgZm9yIGNvbnRpbnVpdHkgY2hlY2ssIHdoaWNoIHdoYXQg KFMtKUJGRCBpcywgImluLWJhbmQiIGRvZXNuJ3Qgc2VlbSB0byBiZSByZWFsbHkgcmVxdWlyZWQu IFBlcmhhcHMgdGhhdCBpcyBiZWNhdXNlIElQIGlzIGNvbm5lY3Rpb25sZXNzIGFuZCBpcyBub3Qg dmlld2VkIGFzIHRyYW5zcG9ydCBsYXllciB1bmxpa2UsIGZvciBleGFtcGxlLCBNUExTLVRQLiBC dXQgSSBiZWxpZXZlIHRoYXQgdGhlcmUgYXJlIG90aGVyIElQIE9BTSBtZWNoYW5pc21zIHRoYXQg d291bGQgaGF2ZSBtdWNoIHN0cm9uZ2VyIG5lZWQgdG8ga2VlcCBpbi1iYW5kIHdpdGggSVAgcGFy dGljdWxhciBzZXJ2aWNlIG9yIGJlIGFibGUgdG8gcGluIGl0cyBwYXRoLiBUaGVzZSwgSSB0aGlu aywgYXJlIElQIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IE9BTS4gV2hpbGUgcGFzc2l2ZSBQTSBu YXRpdmVseSBpcyBpbi1iYW5kIGFzIG1lYXN1cmVtZW50cyBwZXJmb3JtZWQgb24gZGF0YSB0cmFm ZmljIGl0c2VsZiwgYWN0aXZlIFBNLCBmb3IgZXhhbXBsZSBUV0FNUCwgd291bGQgaGF2ZSB0aGUg c2FtZSBpc3N1ZSB3aXRoIEVDTVAgc2VnbWVudHMgYXMgd2UncmUgZGlzY3Vzc2luZy4gQnV0IHF1 ZXN0aW9uIG9mIGFjdGl2ZSBQTSBPQU0gaXMgbW9yZSBpbiBzY29wZSBvZiBJUFBNIGFuZCBMTUFQ IFdHcy4gQXMgZm9yIEJGRCwgSSB0aGluayB0aGF0IHVubGVzcyB0aGVyZSdzIHJlcXVpcmVtZW50 IHRvIHVzZSBpdCBmb3IgY29ubmVjdGl2aXR5IHZlcmlmaWNhdGlvbiBpbiBhZGRpdGlvbiB0byBj b250aW51aXR5IGNoZWNraW5nIHBhc3Npbmcgb3ZlciBkaXZlcnNlIEVDTVAgbWVtYmVyIHNlZ21l bnRzIHNlZW1zIE9LIHRvIG1lLg0KDQoJUmVnYXJkcywNCgkJR3JlZw0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFuYXYgQmhhdGlhIFttYWlsdG86bWFuYXZiaGF0aWFAZ21h aWwuY29tXSANClNlbnQ6IEZyaWRheSwgTWF5IDA5LCAyMDE0IDU6MDggUE0NClRvOiBHcmVnb3J5 IE1pcnNreQ0KQ2M6IFNhbSBBbGRyaW47IE5vYm8gQWtpeWEgKG5vYm8pOyBsb2FAcGkubnU7IE1h Y2ggQ2hlbjsgcnRnLWJmZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFByb2JsZW0gd2l0aCBCRkQg d2l0aCBFQ01QDQoNCkhpIEdyZWcsDQoNClRoaXMgaXMgdmVyeSBkaWZmaWN1bHQgdG8gbWFuZGF0 ZSBzaW5jZSBpbiBtb3N0IGNhc2VzIHdlIHdvdWxkIGxpa2UgdG8gc3ByZWFkIHRoZSB0cmFmZmlj IGZsb3dzIGFjcm9zcyBtdWx0aXBsZSBFQ01QIHBhdGhzLiBJdHMgb25seSBpbiBjZXJ0YWluIHZl cnkgc3BlY2lmaWMgY2FzZXMgd2hlcmUgd2Ugd291bGQgd2FudCB0aGUgZGF0YSB0byBzdHJpY3Rs eSBmb2xsb3cgdGhlIElQIE9BTSAoUy1CRkQvQkZEKSBwYWNrZXQuIFRoaXMgaSB3YXMgd29uZGVy aW5nIGNvdWxkIGJlIHBvc3NpYmx5IGJlIGFjaGlldmVkIGJ5IGVuY2Fwc3VsYXRpbmcgdGhlIFMt QkZEIGFuZCB0aGUgZGF0YSBwYWNrZXQgaW5zaWRlIGFuIElQLWluLUlQIG9yIGEgR1JFIGhlYWRl ci4gVGhpcyB3YXkgdGhlIDUgdHVwbGUgaGFzaCBjb21wdXRhdGlvbiB3b3VsZCB5aWVsZCB0aGUg c2FtZSByZXN1bHQgZm9yIHRoZSBPQU0gYW5kIHRoZSBkYXRhIHBhY2tldHMuDQoNCkNoZWVycywg TWFuYXYNCg0KT24gRnJpLCBNYXkgOSwgMjAxNCBhdCA4OjM5IFBNLCBHcmVnb3J5IE1pcnNreSA8 Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gSGkgTWFuYXYsDQo+IHllcywg dGhlcmUncyBwcm9ibGVtIHdpdGggc2F0aXNmeWluZyAiaW4tYmFuZCIgcmVxdWlyZW1lbnQgZm9y IElQIE9BTS4gSSByZWNhbGwgdGhhdCBOb2JvIGFuZCBJIGhhZCBkaXNjdXNzZWQgaXQgdGhvdWdo IGJyaWVmbHkgYW5kIGFncmVlZCB0aGF0IGlmICJpbi1iYW5kIiBPQU0gcmVxdWlyZW1lbnQgaXMg aW5kZWVkIHN0cm9uZyB0aGVuIGhhc2hpbmcgc2hvdWxkIG5vdCB1c2UgcG9ydCBudW1iZXJzLCBl LmcuIGJlIGJhc2VkIG9uIElQIFNBL0RBLg0KPg0KPiAgICAgICAgIFJlZ2FyZHMsDQo+ICAgICAg ICAgICAgICAgICBHcmVnDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IE1hbmF2IEJoYXRpYSBbbWFpbHRvOm1hbmF2YmhhdGlhQGdtYWlsLmNvbV0NCj4gU2VudDogRnJp ZGF5LCBNYXkgMDksIDIwMTQgODowNSBBTQ0KPiBUbzogU2FtIEFsZHJpbg0KPiBDYzogR3JlZ29y eSBNaXJza3k7IE5vYm8gQWtpeWEgKG5vYm8pOyBsb2FAcGkubnU7IE1hY2ggQ2hlbjsgDQo+IHJ0 Zy1iZmRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFByb2JsZW0gd2l0aCBCRkQgd2l0aCBFQ01Q DQo+DQo+IE9rLCBteSBwb2ludCBhYm91dCBNUExTIGJlaW5nIG1vcmUgcHJlZGljdGFibGUgd2Fz IHRoaXM6DQo+DQo+IFlvdSBzbGFwIG9uIGFuIEVMIHRvIGFuIE9BTSBwYWNrZXQgYW5kIGl0IHRh a2VzICpzb21lKiBwYXRoLiBOb3csIHlvdSBpZiB5b3Ugc2xhcCBvbiB0aGUgc2FtZSBFTCB0byB0 aGUgZGF0YSB0cmFmZmljIHRoZW4gaXQgd291bGQgdG9vIHRha2UgdGhlICpzYW1lKiBwYXRoLiBT byB0aGVyZSBpcyBzb21lIGxldmVsIG9mIGRldGVybWluaXNtLCB3aGljaCBpIHN0YXRlZCB3YXMg bWlzc2luZyBpbiBwdXJlIElQLg0KPg0KPiBDaGVlcnMsIE1hbmF2DQo+DQo+IE9uIEZyaSwgTWF5 IDksIDIwMTQgYXQgODoyNCBQTSwgU2FtIEFsZHJpbiA8YWxkcmluLmlldGZAZ21haWwuY29tPiB3 cm90ZToNCj4+IEhpIGZvbGtzLA0KPj4NCj4+IEFzIEdyZWcgc2FpZCwgRUwvRUxJIGNhbm5vdCBw cmVkaWN0IHdoaWNoIHBhY2tldCB0YWtlcyB3aGljaCBwYXRoLiBJdCBpcyBvbmx5IHVzZWQgdG8g ZGlzdHJpYnV0ZSBmbG93cyBvZiBkYXRhIHBhY2tldHMsIHdpdGggYW4gYXNzdW1wdGlvbiB0aGF0 IGhhc2hpbmcgd2lsbCBvY2N1ciB0byB1dGlsaXplIGxvYWQgYmFsYW5jZWQgcGF0aHMuDQo+PiBN UExTIE9BTSBjYW5ub3QgcHJlZGljdCB0aGlzIGVpdGhlci4gVGhhdCBpcyB3aHksIGFzIGEgdmVu ZG9yLCBvbmUgaW1wbGVtZW50cyB2YXJpb3VzIHRvb2xzIGxpa2UgdHJhY2UsIHBhdGggdHJhY2Ug ZXRjLg0KPj4gSSBzZWUgaXQgbm8gZGlmZmVyZW50IHRvIG5vbi1NUExTIG5ldHdvcmtzIGVpdGhl ci4NCj4+DQo+PiBBcyBmYXIgYXMgc2VjIDMuMiBvZiB0aGUgdXNlIGNhc2UgZG9jdW1lbnQgaXMg Y29uY2VybmVkLCBTLUJGRCBpcyBub3QgcmVwbGFjaW5nIG90aGVyIE9BTSB0b29scy4gSXQgc3Rp bGwgcGVyZm9ybXMgY2MgY2hlY2tzLg0KPj4gU29sdmluZyBFQ01QIGlzc3VlIGlzIGEgbmV2ZXIg ZW5kaW5nIGFuZCBkb27igJl0IHNlZSBvbmUgZWl0aGVyLCB1bmxlc3MgbG9hZCBiYWxhbmNpbmcg aXMgc3RhbmRhcmRpemVkIGFuZCBhbGwgaW50ZXJtZWRpYXRlIG5vZGVzIGNvbmZpcm1lZCB0byB0 aGF0LCBJTUhPLg0KPj4gVGlsbCB0aGF0IHRpbWUgd2UgaGF2ZSB0byBwbGF5IGhhc2ggdGFn4oCZ cy4gOkQNCj4+DQo+PiBjaGVlcnMNCj4+IC1zYW0NCj4+IE9uIE1heSA5LCAyMDE0LCBhdCA3OjQ2 IEFNLCBHcmVnb3J5IE1pcnNreSA8Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPiB3cm90ZToN Cj4+DQo+Pj4gSGkgTm9ibywgZXQuIGFsLA0KPj4+IEknbSBub3Qgc3VyZSB0aGF0IEVMSS9FTCB3 YXMgaW50ZW5kZWQgdG8gcGluIGEgZmxvdyB0byB0aGUgcGFydGljdWxhciBFQ01QIHBhdGguIE15 IHVuZGVyc3RhbmRpbmcgb2YgRUwgaXMgdGhhdCBpdCBtYWtlcyBlYXNpZXIgdG8gZGlzdHJpYnV0 ZSBmbG93cywgZS5nLiBieSBhc3NpZ25pbmcgRUwgbGFiZWxzIGZyb20gbGFiZWwgcmFuZ2UgTiBs YWJlbHMgd2lkZSwgW00sIE0rTl0gd2hlbiB0aGVyZSBhcmUgTiBhdmFpbGFibGUgcGF0aHMgaW4g YW4gRUNNUC4gSSBiZWxpZXZlIHRoYXQgdGhlcmUgaXMgbm8gZXhwZWN0YXRpb24gdG8gcHJlZGlj dCB3aXRoIGFueSBsZXZlbCBvZiBjZXJ0YWludHkgd2hpY2ggcGFydGljdWxhciBwYXRoIGEgZmxv dyB3aWxsIGZvbGxvdyBidXQgb25seSBleHBlY3RhdGlvbiB0aGF0IGZsb3cgd2l0aCBFTCBNKzIg d2lsbCB0YWtlIGRpZmZlcmVudCBwYXRoIHdpdGggZmxvdyB0YWdnZWQgYnkgRUwgTSszLiBDZXJ0 YWludHkgaXMgcmVxdWlyZWQgdGhvdWdoIHdoZW4gRUNNUCBpcyB2aWV3ZWQgYXMgYSBsaW5rLCBl LmcuIG1pY3JvLUJGRC4NCj4+Pg0KPj4+ICAgICAgIFJlZ2FyZHMsDQo+Pj4gICAgICAgICAgICAg ICBHcmVnDQo+Pj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IFJ0 Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOb2Jv IA0KPj4+IEFraXlhIChub2JvKQ0KPj4+IFNlbnQ6IEZyaWRheSwgTWF5IDA5LCAyMDE0IDU6Mzcg QU0NCj4+PiBUbzogTG9hIEFuZGVyc3NvbjsgTWFuYXYgQmhhdGlhOyBNYWNoIENoZW4NCj4+PiBD YzogcnRnLWJmZEBpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJFOiBQcm9ibGVtIHdpdGggQkZEIHdp dGggRUNNUA0KPj4+DQo+Pj4gSGkgTWFuYXYsIE1hY2gsIExvYSwNCj4+Pg0KPj4+IE9uIHNvbWUg ZGF0YSBwbGFuZXMgKGV4OiBNUExTIHdpdGggRW50cm9weSBMYWJlbCksIGl0J3MgbGVzcyBkaWZm aWN1bHQgdG8gdXNlIE9BTSBwYWNrZXRzIHRvIFtsaWtlbHldIGV4ZXJjaXNlIHNwZWNpZmljIEVD TVAgcGF0aHMgYXMgbG9uZyBhcyB0aGVyZSBhcmUgd2F5cyB0byBkaXNjb3ZlciB0aGUgZW50cm9w aWVzLg0KPj4+DQo+Pj4gT24gc29tZSBvdGhlcnMgKGV4OiBJUCBuZXR3b3JrKSwgaXQncyBtb3Jl IGRpZmZpY3VsdCBhbmQgSSBmdWxseSBhZ3JlZSB3aXRoIHdoYXQgTG9hIHNhaWQuDQo+Pj4NCj4+ PiAtTm9ibw0KPj4+DQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206 IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBM b2EgDQo+Pj4+IEFuZGVyc3Nvbg0KPj4+PiBTZW50OiBGcmlkYXksIE1heSAwOSwgMjAxNCA2OjUz IEFNDQo+Pj4+IFRvOiBNYW5hdiBCaGF0aWE7IE1hY2ggQ2hlbg0KPj4+PiBDYzogcnRnLWJmZEBp ZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBSZTogUHJvYmxlbSB3aXRoIEJGRCB3aXRoIEVDTVANCj4+ Pj4NCj4+Pj4gTWFjaCBhbmQgTWFuYXYsDQo+Pj4+DQo+Pj4+IEkgZ3Vlc3MgdGhhdCB0aGUgYW5z d2VyIHRvIHRoaXMgdHlwZSBvZiBxdWVzdGlvbiBpcyBzb21ld2hlcmUgDQo+Pj4+IGFyb3VuZCAi SXMgaXQgd29ydGggZG9pbmc/Ii4gSWYgd2Ugc2VlIGFuIGVhc3kgd2F5IHRvIGZpeCBpdCBhbmQg d2UgDQo+Pj4+IGFyZSBwcmV0dHkgc3VyZSB0aGF0IGl0IHdpbGwgYmUgZGVwbG95ZWQsIHRoZW4g bGV0IHVzIGdvIGFoZWFkIGFuZCBkbyBpdC4NCj4+Pj4gSWYgdGhlIGZpeCBpcyBzaGFkeSBhbmQg bm8gb25lIHJlYWxseSB3YW50IGl0LCB0aGVuIGp1c3QgbGVhdmUgaXQuDQo+Pj4+DQo+Pj4+IE5v IGluIHRob3NlIHRlcm1zIHdoZXJlIGFyZSB3ZT8NCj4+Pj4NCj4+Pj4gL0xvYQ0KPj4+Pg0KPj4+ PiBPbiAyMDE0LTA1LTA5IDEyOjEyLCBNYW5hdiBCaGF0aWEgd3JvdGU6DQo+Pj4+PiBIaSBNYWNo LA0KPj4+Pj4NCj4+Pj4+Pj4gTXkgcG9pbnQgaXMgdGhpczoNCj4+Pj4+Pj4NCj4+Pj4+Pj4gSG93 IGRvIGkgZW5zdXJlIHRoYXQgaW4gYW4gSVAgb25seSBuZXR3b3JrLCBteSBkYXRhIHRyYWZmaWMg DQo+Pj4+Pj4+IGFsd2F5cyBmb2xsb3dzIHRoZSBzYW1lIHBhdGggYXMgdGhlIE9BTSBwYWNrZXQg dGhhdCBpIGhhZCBzZW50IA0KPj4+Pj4+PiB0byB2ZXJpZnkgdGhlDQo+Pj4+IGRhdGEgcGxhbmU/ DQo+Pj4+Pj4NCj4+Pj4+PiBJdCdzIGFsd2F5cyBkZXNpcmVkLCBidXQgaXQncyBoYXJkLCBhbmQg bW9zdCBvZiB0aW1lLCBubyBwZXJmZWN0IHNvbHV0aW9uLg0KPj4+Pj4NCj4+Pj4+IFN1cmUgdGhl IHF1ZXN0aW9uIGlzOiBEbyB3ZSB3YW50IHRvIGZpeCB0aGlzPw0KPj4+Pj4NCj4+Pj4+Pg0KPj4+ Pj4+Pg0KPj4+Pj4+PiBXaWxsIGl0IHdvcmsgaWYgaSBlbmNhcHN1bGF0ZSBib3RoIHRoZSBPQU0g YW5kIHRoZSBkYXRhIHRyYWZmaWMgDQo+Pj4+Pj4+IGluc2lkZSBhIEdSRSB0dW5uZWwgc28gdGhh dCBib3RoIHVzZSB0aGUgc2FtZSBoYXNoaW5nIGZpZWxkcz8gSSANCj4+Pj4+Pj4gbWF5IHdhbnQg dG8gZG8gdGhpcyBmb3IgY2VydGFpbiBmbG93cyB3aGVyZSBpIHdhbnQgYSB2ZXJ5IA0KPj4+Pj4+ PiBkZXRlcm1pbmlzdGljDQo+Pj4+IGJlaGF2aW9yLg0KPj4+Pj4+DQo+Pj4+Pj4gWWVzLCB1c2Ug YSB0dW5uZWwgdG8gZW5jYXBzdWxhdGUgYm90aCB0aGUgT0FNIGFuZCB0aGUgZGF0YSANCj4+Pj4+ PiB0cmFmZmljIGlzIGENCj4+Pj4gY2FuZGlkYXRlLg0KPj4+Pj4+IEJ1dCBmb3IgYSBkZXBsb3ll ZCBuZXR3b3JrLCBzdWNoIGNoYW5nZXMgbWF5IG5vdCBhY2NlcHRlZCwgeW91IA0KPj4+Pj4+IGNh bm5vdCBjaGFuZ2UgdGhlIGV4aXN0aW5nIGRlcGxveW1lbnQgbW9kZWwuDQo+Pj4+Pg0KPj4+Pj4g V2UgY2FuIGxvb2sgYXQgdGhlIHNvbHV0aW9uIHNwYWNlIGxhdGVyLg0KPj4+Pj4NCj4+Pj4+IFRo ZSBmaXJzdCB0aGluZyBpcyAtLSBEbyB3ZSB3YW50IHRvIHNvbHZlIHRoaXMgaXNzdWU/IEkgd291 bGQgDQo+Pj4+PiB3YWdlciB0aGF0IGl0cyBzb21ldGhpbmcgdGhhdCB3ZSB3b3VsZCB3YW50IHRv IHNvbHZlLiBKdXN0IHdhbnQgdG8gDQo+Pj4+PiBoZWFyIHdoYXQgb3RoZXJzIHRoaW5rIGFib3V0 IHRoaXMuDQo+Pj4+Pg0KPj4+Pj4gQ2hlZXJzLCBNYW5hdg0KPj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+ IEJlc3QgcmVnYXJkcywNCj4+Pj4+PiBNYWNoDQo+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQ2hl ZXJzLCBNYW5hdg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gIGRldGVjdCBhIHNlZ21lbnQgb2YgdGhlIHBh dGgsIG1lYW5zIHRoZSBkZXN0aW5hdGlvbiBvZiB0aGUgDQo+Pj4+Pj4+PiBTLUJGRCB3aWxsIGJl IGRpZmZlcmVudCBmcm9tIHRoZSB1c2VyIGRhdGEuIFRoZW4geW91IGRlc2NyaWJlZCANCj4+Pj4+ Pj4+IHNpdHVhdGlvbiB3aWxsDQo+Pj4+IGhhcHBlbi4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBCZXN0 IHJlZ2FyZHMsDQo+Pj4+Pj4+PiBNYWNoDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KPj4+Pj4+Pj4+IE1hbmF2IEJoYXRpYQ0K Pj4+Pj4+Pj4+IFNlbnQ6IEZyaWRheSwgTWF5IDA5LCAyMDE0IDQ6MDIgUE0NCj4+Pj4+Pj4+PiBU bzogcnRnLWJmZEBpZXRmLm9yZw0KPj4+Pj4+Pj4+IFN1YmplY3Q6IFByb2JsZW0gd2l0aCBCRkQg d2l0aCBFQ01QDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBIaSwNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ IFRoZXJlIGlzIGEgcHJvYmxlbSB3aXRoIGhvdyBCRkQvUy1CRkQgd29ya3MuDQo+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+PiBTZWMgMy4yIGRyYWZ0LWFsZHJpbi1iZmQtc2VhbWxlc3MtdXNlLWNhc2UtMDEg ZXhwbGFpbnMgaG93IHdlIA0KPj4+Pj4+Pj4+IGNhbiB1c2UgUy1CRkQgdG8gcXVpY2tseSB2YWxp ZGF0ZSB0aGUgZGF0YSBwbGFuZSBiZWZvcmUgDQo+Pj4+Pj4+Pj4gcHVzaGluZyB0aGUgZGF0YQ0K Pj4+PiBvdXQuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBUaGVyZSBpcyBhIHBvdGVudGlhbCBpc3N1 ZSBoZXJlLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQXNzdW1lIEkgc2VuZCBhbiBTLUJGRCBwaW5n IGFuZCBJIGdldCBhIHBvbmcgYmFjay5JIGJlbGlldmUgDQo+Pj4+Pj4+Pj4gdGhhdCB0aGUgcGF0 aCBpcyB1cCBhbmQgaSBzdGFydCBzZW5kaW5nIHRyYWZmaWMgdG93YXJkcyB0aGUgDQo+Pj4+Pj4+ Pj4gUmVmbGVjdG9yLCBicmltbWluZyB3aXRoIGNvbmZpZGVuY2UsIHNpbmNlIGkgYmVsaWV2ZSB0 aGUgZGF0YSBwbGFuZSBpcyB1cC4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEFzc3VtZSB0aGF0IHRo ZXJlIGlzIEVDTVAgaGFwcGVuaW5nIGluIHRoZSBuZXR3b3JrIHNvbWV3aGVyZQ0KPj4+PiB0aGF0 DQo+Pj4+Pj4+Pj4gc3BsaXRzIHRoZSB0cmFmZmljIHRvIHBhdGhzIHAxIGFuZCBwMi4NCj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+IEl0cyBwb3NzaWJsZSB0aGF0IHRoZSBTLUJGRCBwYWNrZXQgZ2V0cyBo YXNoZWQgdG8gdGhlIHBhdGggcDEsIA0KPj4+Pj4+Pj4+IHdoaWxlIHRoZSBkYXRhIHRyYWZmaWMg dGhhdCBpIHNlbmQgZ2V0cyBoYXNoZWQgdG8gcGF0aCBwMi4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ IElmIHBhdGggcDIgaXMgZG93biAob3IgaXMgY29uZ2VzdGVkIGFuZCBkcm9wcyBwYWNrZXRzKSwg dGhlbiBpIA0KPj4+Pj4+Pj4+IGRyb3AgYWxsIHRyYWZmaWMgLS0gb3Igc29tZSwgaW4gY2FzZSBv ZiBjb25nZXN0aW9uLiBUaGlzIA0KPj4+Pj4+Pj4+IGhvd2V2ZXIgaXMgdW5leHBlY3RlZCBzaW5j ZSBpIGFsd2F5cyBnZXQgMTAwJSByZXNwb25zZSBmb3IgbXkgDQo+Pj4+Pj4+Pj4gUy1CRkQgcGlu Zw0KPj4+PiBwYWNrZXRzLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gSSB1bmRlcnN0YW5kIHRoYXQg aWYgcGF0aCBwMiBpcyBkb3duIChiZWNhdXNlIG9mIGFuIGlzc3VlIGluIA0KPj4+Pj4+Pj4+IG9u ZSBvZiB0aGUgbm9kZXMvbGlua3MgaW4gdGhlIHBhdGgpLCB0aGUgRUNNUCBwYXRoIHdpbGwgbm90 IA0KPj4+Pj4+Pj4+IGNvbnRhaW4gcDIsIHNpbmNlIHRoZSByb3V0aW5nIHByb3RvY29scyB3aWxs IG5hdHVyYWxseSByZW1vdmUgDQo+Pj4+Pj4+Pj4gdGhpcyBmcm9tIHRoZQ0KPj4+PiBFQ01QIGxp c3QuDQo+Pj4+Pj4+Pj4gU28sIGl0cyBvbmx5IHdoaWxlIHRoZSBuZXR3b3JrIGlzIHJlY29udmVy Z2luZyAod2hpY2ggc2hvdWxkIA0KPj4+Pj4+Pj4+IG9ubHkgbGFzdCBmb3IgYSBmZXcNCj4+Pj4+ Pj4+PiBzZWNzKSB0aGF0IHdlIHdpbGwgc2VlIHRoaXMuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBJ cyBteSB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBJZiB5ZXMs IHRoZW4gaXMgdGhlIHNjZW5hcmlvIHdoZXJlIFMtQkZEIGFuZCBkYXRhIHRyYWZmaWMgDQo+Pj4+ Pj4+Pj4gZm9sbG93aW5nIGRpZmZlcmVudCBwYXRocyBzb21ldGhpbmcgdGhhdCB3ZSB3YW50IHRv IGxvb2sgYXQgDQo+Pj4+Pj4+Pj4gZml4aW5nIChlaXRoZXIgaGVyZSBvciBzb21lIG90aGVyIFdH KT8gVGhpcyBwcm9ibGVtIGhhcyANCj4+Pj4+Pj4+PiBhbHJlYWR5IGJlZW4gc29sdmVkIGluIHRo ZSBNUExTIGNvbnRleHQgd2l0aCB0aGUgRW50cm9weSANCj4+Pj4+Pj4+PiBsYWJlbC4gSSBhbSB0 YWxraW5nIHNwZWNpZmljYWxseSBhYm91dCBub24tTVBMUw0KPj4+Pj4+PiBuZXR3b3Jrcy4NCj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IENoZWVycywgTWFuYXYNCj4+Pj4+Pj4+DQo+Pj4+Pg0KPj4+Pg0K Pj4+PiAtLQ0KPj4+Pg0KPj4+Pg0KPj4+PiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAg ICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPj4+PiBTZW5pb3IgTVBMUyBFeHBl cnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KPj4+PiBIdWF3ZWkgVGVjaG5v bG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCj4+Pg0KPj4N Cg== From nobody Sun May 11 11:36:33 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5081A0338; Sun, 11 May 2014 11:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jfxKDkXMU4T; Sun, 11 May 2014 11:36:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3134B1A0339; Sun, 11 May 2014 11:36:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-mib-20.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140511183629.6123.11716.idtracker@ietfa.amsl.com> Date: Sun, 11 May 2014 11:36:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/AOPwiasAXp8SKdam-EwDdnABgWo Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 18:36:32 -0000 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 : BFD Management Information Base Authors : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-mib-20.txt Pages : 38 Date : 2014-05-11 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-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-mib-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 12 07:22:41 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D19E1A0729 for ; Mon, 12 May 2014 07:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs6mwLJ574Cn for ; Mon, 12 May 2014 07:22:28 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D49FB1A0718 for ; Mon, 12 May 2014 07:22:23 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E28B9C1F9; Mon, 12 May 2014 10:22:17 -0400 (EDT) Date: Mon, 12 May 2014 10:22:17 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Final stretch for the MIBs (was Re:[internet-drafts@ietf.org: New Version Notification - draft-ietf-bfd-mib-20.txt]) Message-ID: <20140512142217.GO13387@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/hx9sHHvZ6s4PhDjysh0QXEGaArk X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 14:22:31 -0000 Both the BFD MIB and the BFD TC MIB have gotten updates to address final nits found during security, operations and mib-doctors reviews. Thanks to all who've contributed to that. As a (hopefully correct) brief summary of the functional change, the bfdAdminStatus (and related session status) objects have been extended to not only have the enabled/disabled semantic that is common to SNMP writable MIBs, but also add a down and adminDown state as well. This accommodates an issue Bert Wijnen noted indirectly as part of the mib-doctor review wherein our operational state (which matches protocol machinery) didn't have a way to get into the forced down or admindown states. Implementors of BFD at the CLI level will recognize the semantics corresponding to disabling the session or forcing it down - the distinction being down typically causes dependent clients to treat BFD as going down vs. admindown letting dependent clients dissociate from the session. The MIBs (and hopefully the charter) appear headed to the upcoming IESG telechat. Thanks to Tom Nadeau and Nobo Akiya for managing to handle the last minute edits in MIB-land in spite of nasty pressures from their day jobs. -- Jeff ----- Forwarded message from internet-drafts@ietf.org ----- Date: Sun, 11 May 2014 11:36:29 -0700 From: internet-drafts@ietf.org To: bfd-chairs@tools.ietf.org, draft-ietf-bfd-mib@tools.ietf.org, adrian@olddog.co.uk Subject: New Version Notification - draft-ietf-bfd-mib-20.txt A new version (-20) has been submitted for draft-ietf-bfd-mib: http://www.ietf.org/internet-drafts/draft-ietf-bfd-mib-20.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mib/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-mib-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. ----- End forwarded message ----- From nobody Mon May 12 12:12:05 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645261A0779 for ; Mon, 12 May 2014 12:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBvfrd-eOUpa for ; Mon, 12 May 2014 12:11:11 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id ED1A31A076E for ; Mon, 12 May 2014 12:11:10 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E21FFC1F9; Mon, 12 May 2014 15:11:04 -0400 (EDT) Date: Mon, 12 May 2014 15:11:04 -0400 From: Jeffrey Haas To: "Keyur Patel (keyupate)" Subject: Re: [RTG-DIR] RTG-DIR Review: draft-ietf-bfd-mib-19.txt Message-ID: <20140512191104.GQ13387@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/vQVmnHBNLFk3TdZDsHVh5nFXElA X-Mailman-Approved-At: Mon, 12 May 2014 12:12:02 -0700 Cc: "Black, David \(david.black@emc.com\)" , Tero Kivinen , Randy Presuhn , "draft-ietf-bfd-mib.all@tools.ietf.org" , Alia Atlas , Christer Holmberg , "rtg-bfd@ietf.org" , "Bert Wijnen \(IETF\) \(bertietf@bwijnen.net\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 19:11:15 -0000 Keyur, Thanks for the review. Please check the recently published -20 and see if your comments are otherwise addressed. There's overlap with the mib-doctors review. Further comments below: On Mon, May 12, 2014 at 07:05:07PM +0000, Keyur Patel (keyupate) wrote: > Hello, > > > > I have been selected as the Routing Directorate reviewer for this draft. > > The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. > > For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html > > > > Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. > > > Document: draft-ietf-bfd-mib-19.txt > > Reviewer: Keyur Patel > > Review date: 11-May-14 > > IETF LC End Date: 28-April-14 > > > Summary: > > This document is basically ready for publication, but has nits that should be considered > prior to publication. > > Major Issues: > No major issues found. > > Minor Issues: > 1 minor issue found. > > Section 6: It says: > "bfdAdminStatus - Improper change of bfdAdminStatus, from > enabled(1) to disabled(2), can cause significant disruption of the > connectivity to those portions of the Internet reached via all the > applicable remote BFD peers." I believe this is addressed in -20. > > I am not sure if bfdAdminStatus has a significant impact on security.Maybe the current text can be augmented to clarify any specific case that authors have in mind? > > Nits: > > Section 4.2: s/pair of nodes/pair of systems. This one may be arguable since BFD in the context in question may be between devices that are components rather than full-fledged systems. > > Section 4.5: It says: > "The BFD Session IP Mapping Table maps, given bfdSessInterface,..." > change to: > "The BFD Session IP Mapping Table maps a given bfdSessInterface,..." We'll leave this one to the RFC editor since they also audit for grammar style compliance. > Section 5: s/up/Up, s/down/Down, s/adminDown/AdminDown > Section 6: s/up/Up, s/down/Down, s/adminDown/AdminDown These are correct in their current form based on MIB styling for such things. I know it offends OO coders. :-) -- Jeff From nobody Mon May 12 12:12:20 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CC11A0772 for ; Mon, 12 May 2014 12:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAVZdkBWZc-Q for ; Mon, 12 May 2014 12:05:15 -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 1E4E71A0771 for ; Mon, 12 May 2014 12:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13700; q=dns/txt; s=iport; t=1399921509; x=1401131109; h=from:to:cc:subject:date:message-id:mime-version; bh=EN5a4Q/02GgHfd8+sC7JAPfumVpA/Xv0EJuYpeUdayg=; b=meOjFYheQXNbI4EULq63E/URpSPFvQkZsk9KKjDuBgTRJ5uQttSmjekP CtLrJSxxLL1HgBPQjySkn57au1HjhukDHXJXvin9JTr8q03QQssqi55EW yUYyBy5OpsWJbCbxCf+TREbqoj9qbfei1uzeDuE9emsRojk2MoaPiq8NG 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQIAD8acVOtJV2b/2dsb2JhbABZgkJET1irTAEFAQWaFoEbFnSCLHkSARYGZCcEAQ0OiDgNzzsXhVaIaxGERwSZSJMHgzZtgUI X-IronPort-AV: E=Sophos;i="4.97,1037,1389744000"; d="scan'208,217";a="324300293" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 12 May 2014 19:05:08 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4CJ58ra006120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 May 2014 19:05:08 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.72]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 12 May 2014 14:05:08 -0500 From: "Keyur Patel (keyupate)" To: Thomas Nadeau , Randy Presuhn , Jeffrey Haas , "Black, David (david.black@emc.com)" , Tero Kivinen , Christer Holmberg , "Bert Wijnen (IETF) (bertietf@bwijnen.net)" , Adrian Farrel , Alia Atlas Subject: [RTG-DIR] RTG-DIR Review: draft-ietf-bfd-mib-19.txt Thread-Topic: [RTG-DIR] RTG-DIR Review: draft-ietf-bfd-mib-19.txt Thread-Index: AQHPbhUWTzKZcfNa2U+foQEByQQWGA== Date: Mon, 12 May 2014 19:05:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.125] Content-Type: multipart/alternative; boundary="_000_CF966BBE71D57keyupateciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/lpMY4rt526icoWhEsTaQYTk60pU X-Mailman-Approved-At: Mon, 12 May 2014 12:12:07 -0700 Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-mib.all@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 19:05:17 -0000 --_000_CF966BBE71D57keyupateciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related draf= ts as they pass through IETF last call and IESG review. The purpose of the = review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.i= etf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-bfd-mib-19.txt Reviewer: Keyur Patel Review date: 11-May-14 IETF LC End Date: 28-April-14 Summary: This document is basically ready for publication, but has nits that should = be considered prior to publication. Major Issues: No major issues found. Minor Issues: 1 minor issue found. Section 6: It says: "bfdAdminStatus - Improper change of bfdAdminStatus, from enabled(1) to disabled(2), can cause significant disruption of the connectivity to those portions of the Internet reached via all the applicable remote BFD peers." I am not sure if bfdAdminStatus has a significant impact on security.Maybe = the current text can be augmented to clarify any specific case that authors= have in mind? Nits: Section 4.2: s/pair of nodes/pair of systems. Section 4.5: It says: "The BFD Session IP Mapping Table maps, given bfdSessInterface,..." change to: "The BFD Session IP Mapping Table maps a given bfdSessInterface,..." Section 5: s/up/Up, s/down/Down, s/adminDown/AdminDown Section 6: s/up/Up, s/down/Down, s/adminDown/AdminDown Regards, Keyur --_000_CF966BBE71D57keyupateciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <49E27B4135ADBB4295EB52F55B7CB663@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hello,<= /span>

 <= /span>

I have = been selected as the Routing Directorate reviewer for this draft.

The Rou= ting Directorate seeks to review all routing or routing-related drafts as t= hey pass through IETF last call and IESG review. The purpose of the review = is to provide assistance to the Routing ADs.

For mor= e information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

 <= /span>

Althoug= h these comments are primarily for the use of the Routing ADs, it would be = helpful if you could consider them along with any other IETF Last Call comm= ents that you receive, and strive to resolve them through discussion or by updating the draft.


Documen= t: draft-ietf-bfd-mib-19.txt

Reviewe= r: Keyur Patel

Review = date: 11-May-14

IETF LC= End Date: 28-April-14


Summary:

This document i= s basically ready for publication, but has nits that should be considered
prior to public= ation.

Major Issues:
No major issues= found.

Minor Issues:
1 minor issue f= ound.

Secti= on 6: It says:

"= ;bfdAdminStatus - Improper change of bfdAdminStatus, from=

 = ;     enabled(1) to disabled(2), can cause significant disruption= of the

 = ;     connectivity to those portions of the Internet reached via = all the

 = ;     applicable remote BFD peers."


I am no= t sure if bfdAdminStatus has a significant impact on security.Maybe the cur= rent text can be augmented to clarify any specific case that authors have i= n mind?


Nits:

Section 4.2: s/pair of nodes/pair of systems.

Secti= on 4.5: It says:

"= ;The BFD Session IP Mapping Table maps, given bfdSessInterface,..."

chang= e to:

"= ;The BFD Session IP Mapping Table maps a given bfdSessInterface,..."

 = ;

Secti= on 5: s/up/Up, s/down/Down, s/adminDown/AdminDown

Secti= on 6: s/up/Up, s/down/Down, s/adminDown/AdminDown


Regar= ds,

Keyur=

 <= /span>

--_000_CF966BBE71D57keyupateciscocom_-- From nobody Tue May 13 15:16:03 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA021A01E5 for ; Tue, 13 May 2014 15:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NQeHFbxbfXf; Tue, 13 May 2014 15:15:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE0E1A01A5; Tue, 13 May 2014 15:15:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: rtg-bfd@ietf.org, bfd-chairs@tools.ietf.org Subject: State changed: charter-ietf-bfd-07-01 X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140513221554.2753.40521.idtracker@ietfa.amsl.com> Date: Tue, 13 May 2014 15:15:54 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/NtKj9zmUDWin7Jr_U8RvmkEO2no X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 22:15:56 -0000 State changed to IESG review. URL: http://datatracker.ietf.org/doc/charter-ietf-bfd/ From nobody Wed May 14 06:18:57 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C154A1A0295; Wed, 14 May 2014 06:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LN_mv0MdbCMH; Wed, 14 May 2014 06:18:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E0D1A028A; Wed, 14 May 2014 06:18:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-tc-mib-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140514131850.18364.15642.idtracker@ietfa.amsl.com> Date: Wed, 14 May 2014 06:18:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/9R1YLPL6BcW5-Q8DFK9IMv6JuQo Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 13:18:54 -0000 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 : Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management Authors : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-tc-mib-08.txt Pages : 12 Date : 2014-05-14 Abstract: This draft defines two Management Information Base (MIB) modules that contain 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-tc-mib-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 14 06:38:26 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1964A1A008A for ; Wed, 14 May 2014 06:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj0XE68IcmWS for ; Wed, 14 May 2014 06:38:21 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F02191A0092 for ; Wed, 14 May 2014 06:38:20 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6259FC26A; Wed, 14 May 2014 09:38:14 -0400 (EDT) Date: Wed, 14 May 2014 09:38:14 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: S-BFD bump Message-ID: <20140514133814.GH16861@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/NUn2OCFOB9NXCga59203nZyIrqg X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 14 May 2014 13:38:24 -0000 The requested re-charter to include S-BFD work is on its way to the IESG telechat scheduled at the end of this month. In the mean-time, I'd like to encourage the working group to continue review on the base and use cases drafts. S-BFD authors, please also spend some effort on the other drafts now that you know adoption is likely on the way. Once charter work is complete, we'll move to adopt drafts that are in good shape and have group consensus. -- Jeff From nobody Wed May 14 07:09:21 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2211A0099; Wed, 14 May 2014 07:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okwQ3dxWigIc; Wed, 14 May 2014 07:07:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) by ietfa.amsl.com (Postfix) with ESMTP id AAE721A0092; Wed, 14 May 2014 07:07:53 -0700 (PDT) Received: from BY2PRD0510HT002.namprd05.prod.outlook.com (10.255.84.37) by BL2PR05MB146.namprd05.prod.outlook.com (10.242.198.21) with Microsoft SMTP Server (TLS) id 15.0.939.12; Wed, 14 May 2014 14:07:45 +0000 Received: from [172.29.4.101] (66.129.239.16) by pod51010.outlook.com (10.255.84.37) with Microsoft SMTP Server (TLS) id 14.16.459.0; Wed, 14 May 2014 14:07:44 +0000 Subject: Re: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: Date: Wed, 14 May 2014 16:07:42 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> To: Les Ginsberg X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.239.16] X-Forefront-PRVS: 0211965D06 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(69234005)(189002)(377454003)(377424004)(13464003)(24454002)(199002)(81542001)(4396001)(81342001)(50226001)(88136002)(21056001)(50466002)(23726002)(50986999)(76176999)(99396002)(93916002)(62966002)(74502001)(87936001)(102836001)(83072002)(77982001)(46102001)(83322001)(19580405001)(92566001)(83716003)(36756003)(15975445006)(87286001)(77096999)(77156001)(20776003)(76482001)(79102001)(46406003)(66066001)(64706001)(85852003)(15202345003)(92726001)(82746002)(89996001)(33656001)(86362001)(19580395003)(74662001)(31966008)(97756001)(101416001)(47776003)(80022001)(579124002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR05MB146; H:BY2PRD0510HT002.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=hannes@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/lcMSHH_aDnns1F7YoDZYme2GxF0 X-Mailman-Approved-At: Wed, 14 May 2014 07:09:16 -0700 Cc: "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 14 May 2014 14:07:57 -0000 hi les, making the S-BFD discriminator a sole node-property feels a bit coarse for my taste. i'd rather carry this in a IP prefix advertisement, such that i have more granular control *what* (particular links/loopback = etc.) gets BFD-tested. also i'd would like that the receiver gets some idea = what address family (v4/v6) a S-BFD is related to. /hannes On May 8, 2014, at 4:48 PM, Les Ginsberg (ginsberg) wrote: > FYI - this new draft describes how to advertise S-BFD Discriminators = using IS-IS. >=20 > Comments are welcomed. >=20 > Les >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Thursday, May 08, 2014 7:46 AM > To: Mach Chen; Nobo Akiya (nobo); Mach Chen; Les Ginsberg (ginsberg); = Nobo Akiya (nobo); Les Ginsberg (ginsberg) > Subject: New Version Notification for = draft-ginsberg-isis-sbfd-discriminator-00.txt >=20 >=20 > A new version of I-D, draft-ginsberg-isis-sbfd-discriminator-00.txt > has been successfully submitted by Les Ginsberg and posted to the > IETF repository. >=20 > Name: draft-ginsberg-isis-sbfd-discriminator > Revision: 00 > Title: Advertising S-BFD Discriminators in IS-IS > Document date: 2014-05-08 > Group: Individual Submission > Pages: 5 > URL: = http://www.ietf.org/internet-drafts/draft-ginsberg-isis-sbfd-discriminator= -00.txt > Status: = https://datatracker.ietf.org/doc/draft-ginsberg-isis-sbfd-discriminator/ > Htmlized: = http://tools.ietf.org/html/draft-ginsberg-isis-sbfd-discriminator-00 >=20 >=20 > Abstract: > This document defines a means of advertising one or more S-BFD > Discriminators using the IS-IS Router Capability TLV. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Wed May 14 08:23:19 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FEA1A00C3; Wed, 14 May 2014 08:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xhe_Ojmac_6q; Wed, 14 May 2014 08:23:01 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id A27DF1A00B8; Wed, 14 May 2014 08:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3448; q=dns/txt; s=iport; t=1400080975; x=1401290575; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/jjW+/SqFlSmpVUfK+H6NbqYnPEvbOUS4lUTTpruSPc=; b=gARCcWQo2nkI8voa5dIMZOMhFNkIQ4xiM8MZ5UdWM5yOpjkuN76Ll8or X/3HDIy0U05m73rywKE3nBirjcb+FMwmUosh442BvvKj7WORIbKqv0/Zm f6ymLi1gYiBIqCy02VAJBjPZ9/a0j8DOqSwwqnNcGgK+4rxcQoE2c/Dw5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAKyJc1OtJV2Q/2dsb2JhbABZgwZPWL40hzsBgSMWdIIlAQEBBAEBATc0CQIMBAIBCBEEAQEBChQJBycLFAkIAgQOBQgBiDgN0RQXjh0xBwaDJYEVBJsOkVeBd4E/gjA X-IronPort-AV: E=Sophos;i="4.97,1052,1389744000"; d="scan'208";a="43790502" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP; 14 May 2014 15:22:54 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4EFMsvg028581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 15:22:54 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 14 May 2014 10:22:54 -0500 From: "Les Ginsberg (ginsberg)" To: Hannes Gredler Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Topic: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Index: AQHPasw+ft5/3BK2OUCTWOWP0ceEqZs2wwSAgAm28wD//73D8A== Date: Wed, 14 May 2014 15:22:54 +0000 Message-ID: References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> In-Reply-To: <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.97.183] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/cS9R7s-DfQh75Ghfk9j1NX6ut_A Cc: "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 14 May 2014 15:23:09 -0000 Hannes - Thanx for the comments. I don't see how your proposal solves the problem you are attempting to addr= ess. The sender of the S-BFD packet has no control over what interface is u= sed to receive the packet on the target node. Associating it with a prefix = will not help in that regard.=20 Further, the potential use of multiple S-BFD discriminator values by a give= n node gets into an application area that we have deliberately avoided. One= can imagine that S-BFD may want to use different discriminator values for = much more than just different address families - in which case the mapping = between a given discriminator and a given usage will not be addressed simpl= y by associating the discriminator with an IPv4/IPv6 address. Such cases wi= ll no doubt be discussed within BFD WG as part of the S-BFD work - but at t= his point we really want to keep the IGP advertisements out of this area. Les > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Wednesday, May 14, 2014 7:08 AM > To: Les Ginsberg (ginsberg) > Cc: isis-wg@ietf.org; rtg-bfd@ietf.org > Subject: Re: [Isis-wg] New Version Notification for draft-ginsberg-isis-s= bfd- > discriminator-00.txt >=20 > hi les, >=20 > making the S-BFD discriminator a sole node-property feels a bit coarse > for my taste. i'd rather carry this in a IP prefix advertisement, > such that i have more granular control *what* (particular links/loopback > etc.) > gets BFD-tested. also i'd would like that the receiver gets some idea wha= t > address family (v4/v6) a S-BFD is related to. >=20 > /hannes >=20 > On May 8, 2014, at 4:48 PM, Les Ginsberg (ginsberg) wrote: >=20 > > FYI - this new draft describes how to advertise S-BFD Discriminators us= ing > IS-IS. > > > > Comments are welcomed. > > > > Les > > > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Thursday, May 08, 2014 7:46 AM > > To: Mach Chen; Nobo Akiya (nobo); Mach Chen; Les Ginsberg (ginsberg); > Nobo Akiya (nobo); Les Ginsberg (ginsberg) > > Subject: New Version Notification for draft-ginsberg-isis-sbfd- > discriminator-00.txt > > > > > > A new version of I-D, draft-ginsberg-isis-sbfd-discriminator-00.txt > > has been successfully submitted by Les Ginsberg and posted to the > > IETF repository. > > > > Name: draft-ginsberg-isis-sbfd-discriminator > > Revision: 00 > > Title: Advertising S-BFD Discriminators in IS-IS > > Document date: 2014-05-08 > > Group: Individual Submission > > Pages: 5 > > URL: http://www.ietf.org/internet-drafts/draft-ginsberg-isis= -sbfd- > discriminator-00.txt > > Status: https://datatracker.ietf.org/doc/draft-ginsberg-isis-sb= fd- > discriminator/ > > Htmlized: http://tools.ietf.org/html/draft-ginsberg-isis-sbfd- > discriminator-00 > > > > > > Abstract: > > This document defines a means of advertising one or more S-BFD > > Discriminators using the IS-IS Router Capability TLV. > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Wed May 14 08:32:14 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F951A029E; Wed, 14 May 2014 08:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq6jHbk3J0A5; Wed, 14 May 2014 08:27:10 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0096.outbound.protection.outlook.com [65.55.169.96]) by ietfa.amsl.com (Postfix) with ESMTP id 147621A00E5; Wed, 14 May 2014 08:27:09 -0700 (PDT) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) by BL2PR05MB162.namprd05.prod.outlook.com (10.242.198.19) with Microsoft SMTP Server (TLS) id 15.0.944.11; Wed, 14 May 2014 15:26:55 +0000 Received: from [172.29.4.101] (66.129.239.16) by pod51010.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.459.0; Wed, 14 May 2014 15:26:55 +0000 Subject: Re: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: Date: Wed, 14 May 2014 17:26:52 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> To: "Les Ginsberg (ginsberg)" X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.239.16] X-Forefront-PRVS: 0211965D06 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377424004)(24454002)(13464003)(377454003)(189002)(199002)(51704005)(69234005)(64706001)(77156001)(83322001)(19580405001)(85852003)(102836001)(19580395003)(50466002)(79102001)(81542001)(83072002)(23726002)(62966002)(82746002)(46406003)(81342001)(101416001)(92566001)(36756003)(21056001)(86362001)(15975445006)(97756001)(74502001)(15202345003)(92726001)(80022001)(77096999)(77982001)(83716003)(66066001)(99396002)(57306001)(74662001)(76176999)(4396001)(20776003)(88136002)(87936001)(47776003)(46102001)(31966008)(87286001)(93916002)(33656001)(89996001)(76482001)(50226001)(561944003)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR05MB162; H:BL2PRD0510HT001.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=hannes@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/U7HM91ydfiTQe0C6TXXd-ez8hJ0 X-Mailman-Approved-At: Wed, 14 May 2014 08:32:13 -0700 Cc: "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 14 May 2014 15:27:12 -0000 On May 14, 2014, at 5:22 PM, Les Ginsberg (ginsberg) wrote: > Hannes - >=20 > Thanx for the comments. > I don't see how your proposal solves the problem you are attempting to = address. The sender of the S-BFD packet has no control over what = interface is used to receive the packet on the target node. Associating = it with a prefix will not help in that regard.=20 well it would help first endpoint discovery and pinning down BFD traffic = to particular line card. > Further, the potential use of multiple S-BFD discriminator values by a = given node gets into an application area that we have deliberately = avoided. One can imagine that S-BFD may want to use different = discriminator values for much more than just different address families = - in which case the mapping between a given discriminator and a given = usage will not be addressed simply by associating the discriminator with = an IPv4/IPv6 address. Such cases will no doubt be discussed within BFD = WG as part of the S-BFD work - but at this point we really want to keep = the IGP advertisements out of this area. >=20 i am just saying 1 discriminator seems overly restrictive to me and having support for more-than 1 would be a good idea to start with; >> -----Original Message----- >> From: Hannes Gredler [mailto:hannes@juniper.net] >> Sent: Wednesday, May 14, 2014 7:08 AM >> To: Les Ginsberg (ginsberg) >> Cc: isis-wg@ietf.org; rtg-bfd@ietf.org >> Subject: Re: [Isis-wg] New Version Notification for = draft-ginsberg-isis-sbfd- >> discriminator-00.txt >>=20 >> hi les, >>=20 >> making the S-BFD discriminator a sole node-property feels a bit = coarse >> for my taste. i'd rather carry this in a IP prefix advertisement, >> such that i have more granular control *what* (particular = links/loopback >> etc.) >> gets BFD-tested. also i'd would like that the receiver gets some idea = what >> address family (v4/v6) a S-BFD is related to. >>=20 >> /hannes >>=20 >> On May 8, 2014, at 4:48 PM, Les Ginsberg (ginsberg) wrote: >>=20 >>> FYI - this new draft describes how to advertise S-BFD Discriminators = using >> IS-IS. >>>=20 >>> Comments are welcomed. >>>=20 >>> Les >>>=20 >>>=20 >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Thursday, May 08, 2014 7:46 AM >>> To: Mach Chen; Nobo Akiya (nobo); Mach Chen; Les Ginsberg = (ginsberg); >> Nobo Akiya (nobo); Les Ginsberg (ginsberg) >>> Subject: New Version Notification for draft-ginsberg-isis-sbfd- >> discriminator-00.txt >>>=20 >>>=20 >>> A new version of I-D, draft-ginsberg-isis-sbfd-discriminator-00.txt >>> has been successfully submitted by Les Ginsberg and posted to the >>> IETF repository. >>>=20 >>> Name: draft-ginsberg-isis-sbfd-discriminator >>> Revision: 00 >>> Title: Advertising S-BFD Discriminators in IS-IS >>> Document date: 2014-05-08 >>> Group: Individual Submission >>> Pages: 5 >>> URL: = http://www.ietf.org/internet-drafts/draft-ginsberg-isis-sbfd- >> discriminator-00.txt >>> Status: = https://datatracker.ietf.org/doc/draft-ginsberg-isis-sbfd- >> discriminator/ >>> Htmlized: http://tools.ietf.org/html/draft-ginsberg-isis-sbfd- >> discriminator-00 >>>=20 >>>=20 >>> Abstract: >>> This document defines a means of advertising one or more S-BFD >>> Discriminators using the IS-IS Router Capability TLV. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>> _______________________________________________ >>> Isis-wg mailing list >>> Isis-wg@ietf.org >>> https://www.ietf.org/mailman/listinfo/isis-wg >=20 From nobody Wed May 14 08:36:58 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDEE1A02AC; Wed, 14 May 2014 08:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gthcfl-1MEyp; Wed, 14 May 2014 08:36:55 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8694E1A02D5; Wed, 14 May 2014 08:36:48 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E668EC26A; Wed, 14 May 2014 11:36:41 -0400 (EDT) Date: Wed, 14 May 2014 11:36:41 -0400 From: Jeffrey Haas To: Hannes Gredler Subject: Re: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Message-ID: <20140514153641.GC13993@pfrc> References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/n01jh5nfu3uax_-WcIeFxVhBKyE Cc: "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 14 May 2014 15:36:56 -0000 On Wed, May 14, 2014 at 05:26:52PM +0200, Hannes Gredler wrote: > On May 14, 2014, at 5:22 PM, Les Ginsberg (ginsberg) wrote: > > Thanx for the comments. > > I don't see how your proposal solves the problem you are attempting to address. The sender of the S-BFD packet has no control over what interface is used to receive the packet on the target node. Associating it with a prefix will not help in that regard. > > well it would help first endpoint discovery and pinning down BFD traffic to particular line card. Indeed. In the SPRING related case (or even some MPLS scenarios), traffic may be heavily steered to a given interface. This interface may not even be to a router, but may be an ingress for a SFC device and that ingress is critical for the execution of the chain. -- Jeff From nobody Wed May 14 08:40:45 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2FC1A0110; Wed, 14 May 2014 08:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwhizRwaYY3Q; Wed, 14 May 2014 08:40:40 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7359C1A00B8; Wed, 14 May 2014 08:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4920; q=dns/txt; s=iport; t=1400082034; x=1401291634; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yRMfxIX08KoPTJo5c9F4E/Q5LR4oHyySDYjZKLfUdEo=; b=UY1uoBIidOeu3wn+ZK6QD5+zTqJ8+mjsHaVEiboEEM+IuwB9KYuOhzZ0 wzetkv2cPNnUwpHlnspRkVdmNPum7nUy6LOUg7CowQdqDLqociaMjZZpI JuAu0ao5uwT1v8Xhk0PLFa9EMqpLCgvwS+qtB110BF7hT1GLT4d2CsC7j g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAHONc1OtJV2U/2dsb2JhbABZgwZPWL40hzsBgSMWdIIlAQEBAwEBAQE3NAkCDAQCAQgRBAEBAQoUCQcnCxQJCAIEDgUIAYgwCA3RDxeOHTEHBoMlgRUEmw6RV4F3gT+CMA X-IronPort-AV: E=Sophos;i="4.97,1053,1389744000"; d="scan'208";a="43789578" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP; 14 May 2014 15:40:33 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s4EFeXhg028511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 15:40:33 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 14 May 2014 10:40:33 -0500 From: "Les Ginsberg (ginsberg)" To: Hannes Gredler Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Topic: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Index: AQHPasw+ft5/3BK2OUCTWOWP0ceEqZs2wwSAgAm28wD//73D8IAAWFsA//+udDA= Date: Wed, 14 May 2014 15:40:31 +0000 Message-ID: References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> In-Reply-To: <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.97.183] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/O6Z9NqUM-a1Znff7LXmDR5o0qDk Cc: "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 14 May 2014 15:40:42 -0000 Hannes - > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Wednesday, May 14, 2014 8:27 AM > To: Les Ginsberg (ginsberg) > Cc: isis-wg@ietf.org; rtg-bfd@ietf.org > Subject: Re: [Isis-wg] New Version Notification for draft-ginsberg-isis-s= bfd- > discriminator-00.txt >=20 >=20 > On May 14, 2014, at 5:22 PM, Les Ginsberg (ginsberg) wrote: >=20 > > Hannes - > > > > Thanx for the comments. > > I don't see how your proposal solves the problem you are attempting to > address. The sender of the S-BFD packet has no control over what interfac= e > is used to receive the packet on the target node. Associating it with a p= refix > will not help in that regard. >=20 > well it would help first endpoint discovery and pinning down BFD traffic = to > particular line card. As I stated, the sender does not control the path to the reflector (S-BFD i= s not just single-hop). So we do not have the ability to control what line = card will receive the packet simply by associating an S-BFD discriminator w= ith a prefix advertisement. >=20 > > Further, the potential use of multiple S-BFD discriminator values by a > given node gets into an application area that we have deliberately avoide= d. > One can imagine that S-BFD may want to use different discriminator values > for much more than just different address families - in which case the > mapping between a given discriminator and a given usage will not be > addressed simply by associating the discriminator with an IPv4/IPv6 > address. Such cases will no doubt be discussed within BFD WG as part of t= he > S-BFD work - but at this point we really want to keep the IGP > advertisements out of this area. > > >=20 > i am just saying 1 discriminator seems overly restrictive to me and > having support for more-than 1 would be a good idea to start with; The draft allows the advertisement of multiple discriminators. How those di= scriminators get mapped to particular use cases is out of scope. From Secti= on 2: "When multiple S-BFD discriminators are advertised how a given discriminator is mapped to a specific use case is out of scope for this document." Les >=20 >=20 > >> -----Original Message----- > >> From: Hannes Gredler [mailto:hannes@juniper.net] > >> Sent: Wednesday, May 14, 2014 7:08 AM > >> To: Les Ginsberg (ginsberg) > >> Cc: isis-wg@ietf.org; rtg-bfd@ietf.org > >> Subject: Re: [Isis-wg] New Version Notification for draft-ginsberg-isi= s- > sbfd- > >> discriminator-00.txt > >> > >> hi les, > >> > >> making the S-BFD discriminator a sole node-property feels a bit coarse > >> for my taste. i'd rather carry this in a IP prefix advertisement, > >> such that i have more granular control *what* (particular links/loopba= ck > >> etc.) > >> gets BFD-tested. also i'd would like that the receiver gets some idea = what > >> address family (v4/v6) a S-BFD is related to. > >> > >> /hannes > >> > >> On May 8, 2014, at 4:48 PM, Les Ginsberg (ginsberg) wrote: > >> > >>> FYI - this new draft describes how to advertise S-BFD Discriminators > using > >> IS-IS. > >>> > >>> Comments are welcomed. > >>> > >>> Les > >>> > >>> > >>> -----Original Message----- > >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >>> Sent: Thursday, May 08, 2014 7:46 AM > >>> To: Mach Chen; Nobo Akiya (nobo); Mach Chen; Les Ginsberg (ginsberg); > >> Nobo Akiya (nobo); Les Ginsberg (ginsberg) > >>> Subject: New Version Notification for draft-ginsberg-isis-sbfd- > >> discriminator-00.txt > >>> > >>> > >>> A new version of I-D, draft-ginsberg-isis-sbfd-discriminator-00.txt > >>> has been successfully submitted by Les Ginsberg and posted to the > >>> IETF repository. > >>> > >>> Name: draft-ginsberg-isis-sbfd-discriminator > >>> Revision: 00 > >>> Title: Advertising S-BFD Discriminators in IS-IS > >>> Document date: 2014-05-08 > >>> Group: Individual Submission > >>> Pages: 5 > >>> URL: http://www.ietf.org/internet-drafts/draft-ginsberg-is= is-sbfd- > >> discriminator-00.txt > >>> Status: https://datatracker.ietf.org/doc/draft-ginsberg-isis-= sbfd- > >> discriminator/ > >>> Htmlized: http://tools.ietf.org/html/draft-ginsberg-isis-sbfd- > >> discriminator-00 > >>> > >>> > >>> Abstract: > >>> This document defines a means of advertising one or more S-BFD > >>> Discriminators using the IS-IS Router Capability TLV. > >>> > >>> > >>> > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of > >> submission > >>> until the htmlized version and diff are available at tools.ietf.org. > >>> > >>> The IETF Secretariat > >>> > >>> _______________________________________________ > >>> Isis-wg mailing list > >>> Isis-wg@ietf.org > >>> https://www.ietf.org/mailman/listinfo/isis-wg > > From nobody Wed May 14 08:40:55 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7611A02AC for ; Wed, 14 May 2014 08:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_tKU5TvVgiR for ; Wed, 14 May 2014 08:40:47 -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 735CC1A02E1 for ; Wed, 14 May 2014 08:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=665; q=dns/txt; s=iport; t=1400082041; x=1401291641; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=nszE2fWcUD9km5+KT9NLPuEvP2XK4axD9rmtHs3CTwo=; b=AcTG/e3TL+GsmHwY3dpQ2fJqmvOcJ8p5nVAG1gg3CpOD67ONVcHrYnAV +ws5hp4VfmC4014q/m1kj9+09LMDYykykU9jqbPhhQ2atsA5ltPEp8wqM vo4SnckzoNVvQYv8sirqQHyDv9HtMCnLucNCAIjJruErWWgDhAhvNHipe M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFADGNc1OtJV2a/2dsb2JhbABZAYJkIU9YxW8BgSMWdIIlAQEBBDpLBAIBCBEEAQELFAkHMhQHAQEFAwIEEwgBiDgBDNEPF44dMwUGgyWBFQSsZYM2bYFD X-IronPort-AV: E=Sophos;i="4.97,1053,1389744000"; d="scan'208";a="324883514" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 14 May 2014 15:40:40 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4EFeemB020315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 14 May 2014 15:40:40 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 14 May 2014 10:40:40 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: FW: YANG Advice and Editing Session at the next IETF meeting Thread-Topic: YANG Advice and Editing Session at the next IETF meeting Thread-Index: AQJemqlFCRGuNovK+JtC2MqxA5ciq5ogt5awgAEgcRA= Date: Wed, 14 May 2014 15:40:40 +0000 Message-ID: References: <5372944D.5010509@cisco.com> <003701cf6ef6$941d92d0$bc58b870$@olddog.co.uk> In-Reply-To: <003701cf6ef6$941d92d0$bc58b870$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/UMErPChOoq_9VFYEn04i-T9r_1M X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 14 May 2014 15:40:52 -0000 You may have already received this in other list you are subscribed to ... In case you have started any YANG work, below may be beneficial. -Nobo > -----Original Message----- > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Benoit Claise > Sent: 13 May 2014 22:53 > To: undisclosed-recipients: > Subject: YANG Advice and Editing Session at the next IETF meeting >=20 > [Sorry for the potential cross-posting] >=20 > http://www.ietf.org/meeting/90/tutorials/yang-session.html > Let me stress that this should be an interactive session, and not a=20 > tutorial. > So come with your (plan to create) YANG modules. >=20 > Regards, Benoit From nobody Wed May 14 08:48:51 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0C51A0103; Wed, 14 May 2014 08:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.152 X-Spam-Level: X-Spam-Status: No, score=-110.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhWfgqVNDsj5; Wed, 14 May 2014 08:48:50 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 001021A02C0; Wed, 14 May 2014 08:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1456; q=dns/txt; s=iport; t=1400082497; x=1401292097; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zff8cwTPn/qtJJ6ZWSXoufGMe+vkrTvJzn3S4IqlUrI=; b=L8iwUTv1QVdaTpx63NCQ5U9w6cZwisXcJBF9rrVAgR6YxAeZ/5weDUBL +JoiKcyOExHFtKK6B3g7qDxh9f2kJy2YijrERYuLmm6JKST/ZVRm40Tac ofLYlsMczyvzJhlqlH9rXU2eVOqvqoRAsDmNoYaitlecS1sD56Ijd4eWk w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAP6Pc1OtJA2L/2dsb2JhbABZgmUhgSfFbwGBIxZ0giUBAQEDATo9AgULAgEIDgoKFBAyJQIEAQ0NiDEIAdERF44dMQeDK4EVAQOsZYF3gT+CMA X-IronPort-AV: E=Sophos;i="4.97,1053,1389744000"; d="scan'208";a="43794591" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-2.cisco.com with ESMTP; 14 May 2014 15:48:10 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s4EFmAol004839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 15:48:10 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Wed, 14 May 2014 10:48:10 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas , Hannes Gredler Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Topic: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Index: AQHPasw+3TfBhqItW0CgAHCwI2S40Zs3F30AgAliegCAABUCAIAAARwAgAACvoD//61T8A== Date: Wed, 14 May 2014 15:48:10 +0000 Message-ID: References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> <20140514153641.GC13993@pfrc> In-Reply-To: <20140514153641.GC13993@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/8Ni0xhE0jOrLYEnRnXZiGcm1KS4 Cc: "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 14 May 2014 15:48:51 -0000 Hi Jeff, > On Wed, May 14, 2014 at 05:26:52PM +0200, Hannes Gredler wrote: > > On May 14, 2014, at 5:22 PM, Les Ginsberg (ginsberg) wrote: > > > Thanx for the comments. > > > I don't see how your proposal solves the problem you are attempting t= o > address. The sender of the S-BFD packet has no control over what interfac= e > is used to receive the packet on the target node. Associating it with a p= refix > will not help in that regard. > > > > well it would help first endpoint discovery and pinning down BFD traffi= c to > particular line card. >=20 > Indeed. In the SPRING related case (or even some MPLS scenarios), traffi= c > may be heavily steered to a given interface. This interface may not even= be > to a router, but may be an ingress for a SFC device and that ingress is c= ritical > for the execution of the chain. In those cases, one should be sending S-BFD packet in-band, which would go = through the specific interface/LC to reach the reflector session on the tar= get node (i.e. outage will be detected regardless of the discriminator used= ). So having separate reflector discriminator won't be adding further benef= it. Flip side is, if a reflector is hosted on LC 1 and traffic engineered tunne= l is terminating on LC2, then outage of LC1 can cause the "no S-BFD respons= e" on the tunnel terminating on LC2. However, I would think this is a limit= ation with implementation. =20 -Nobo From nobody Wed May 14 08:54:24 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89A71A00B8 for ; Wed, 14 May 2014 08:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.152 X-Spam-Level: X-Spam-Status: No, score=-110.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4rBBPJ04Sl9 for ; Wed, 14 May 2014 08:54:20 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 099DA1A00B6 for ; Wed, 14 May 2014 08:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=746; q=dns/txt; s=iport; t=1400082853; x=1401292453; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=v/FSZeMCeHeoQsUb98ABI7rWTISkm76xPRG8Ac0JMW0=; b=GdKkuD95UpToyAzQXh6JMb428KmGCl51Rhd9fgsbIxot5PLbFkV7Rmlz 3EUEPX30nafnDqNDFHPWIREa931nLnULmQ9Bi8T2UMHP3VtEzKj8x7NAi +7KFLi0tP4Ix0j0lhDRyU0Isr4RCszmvwDC19J4+aP5xrX2R9bHzMQhrk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFACSRc1OtJV2T/2dsb2JhbABZgmUhgSfFbwGBIxZ0giUBAQEDATpECwIBCA4UFBAyJQIEARqIMQgB0RMXjh04gyuBFQEDrGWDNoIw X-IronPort-AV: E=Sophos;i="4.97,1053,1389744000"; d="scan'208";a="43796618" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP; 14 May 2014 15:54:13 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s4EFsCtn002961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 15:54:13 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Wed, 14 May 2014 10:54:12 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: S-BFD bump Thread-Topic: S-BFD bump Thread-Index: AQHPb3nJA+qbja4a5k2LRKlJeU2ydJtAOQEg Date: Wed, 14 May 2014 15:54:12 +0000 Message-ID: References: <20140514133814.GH16861@pfrc> In-Reply-To: <20140514133814.GH16861@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/uIHCwxaotdbuuSZdF-SPPn7jBe0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 14 May 2014 15:54:22 -0000 Thanks Jeff, > S-BFD authors, please also spend some effort on the other drafts now that > you know adoption is likely on the way. As for S-BFD base, there are several pending changes to address comments re= ceived from Les, Jeff, John, Marc. We will get to those once -03 is publish= ed as ietf-00. As for S-BFD-ip/S-BFD-sr, let me discuss with authors on how we should posi= tion these drafts. As for S-BFD-alert-discrim, this is an interesting one and should further g= et discussed, most likely along with "how do we do S-BFD on control-plane-l= ess environment raised by Ignas earlier". If somebody wants to start a thre= ad for this topic, great. Otherwise let's take this up once other drafts se= ttle a bit. -Nobo From nobody Wed May 14 08:58:18 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3C21A008F; Wed, 14 May 2014 08:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYYRPw7LNYcJ; Wed, 14 May 2014 08:58:14 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0616.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:616]) by ietfa.amsl.com (Postfix) with ESMTP id DE6E91A00C3; Wed, 14 May 2014 08:58:13 -0700 (PDT) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) by BN1PR05MB517.namprd05.prod.outlook.com (10.141.65.142) with Microsoft SMTP Server (TLS) id 15.0.944.11; Wed, 14 May 2014 15:57:44 +0000 Received: from juniper.net (66.129.239.16) by pod51010.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.459.0; Wed, 14 May 2014 15:57:44 +0000 Date: Wed, 14 May 2014 17:57:39 +0200 From: Hannes Gredler To: "Nobo Akiya (nobo)" Subject: Re: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Message-ID: <20140514155739.GA14148@juniper.net> References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> <20140514153641.GC13993@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [66.129.239.16] X-Forefront-PRVS: 0211965D06 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(24454002)(377454003)(51704005)(83072002)(81542001)(31966008)(50466002)(50986999)(83322001)(85852003)(33656001)(71816001)(76176999)(561944003)(81342001)(74502001)(36756003)(83506001)(64706001)(46406003)(46102001)(74662001)(87936001)(47776003)(99396002)(92726001)(77982001)(86362001)(80022001)(66066001)(20776003)(92566001)(21056001)(4396001)(97756001)(23726002)(79102001)(76482001)(101416001)(54356999)(102836001)(33026002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB517; H:BL2PRD0510HT005.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=hannes@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/XsovCNTIiMlCrfchevITJGz6Bds Cc: "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 14 May 2014 15:58:16 -0000 On Wed, May 14, 2014 at 03:48:10PM +0000, Nobo Akiya (nobo) wrote: | Hi Jeff, | | > On Wed, May 14, 2014 at 05:26:52PM +0200, Hannes Gredler wrote: | > > On May 14, 2014, at 5:22 PM, Les Ginsberg (ginsberg) wrote: | > > > Thanx for the comments. | > > > I don't see how your proposal solves the problem you are attempting to | > address. The sender of the S-BFD packet has no control over what interface | > is used to receive the packet on the target node. Associating it with a prefix | > will not help in that regard. | > > | > > well it would help first endpoint discovery and pinning down BFD traffic to | > particular line card. | > | > Indeed. In the SPRING related case (or even some MPLS scenarios), traffic | > may be heavily steered to a given interface. This interface may not even be | > to a router, but may be an ingress for a SFC device and that ingress is critical | > for the execution of the chain. | | In those cases, one should be sending S-BFD packet in-band, which would go through the specific interface/LC to reach the reflector session on the target node (i.e. outage will be detected regardless of the discriminator used). So having separate reflector discriminator won't be adding further benefit. | | Flip side is, if a reflector is hosted on LC 1 and traffic engineered tunnel is terminating on LC2, then outage of LC1 can cause the "no S-BFD response" on the tunnel terminating on LC2. However, I would think this is a limitation with implementation. what about AF discovery ? - how would a receiver know what AF a S-BFD session to bring up with ? From nobody Wed May 14 09:15:58 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAB51A02DB; Wed, 14 May 2014 09:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHYFWJexeHCq; Wed, 14 May 2014 09:15:51 -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 C58171A02D1; Wed, 14 May 2014 09:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2308; q=dns/txt; s=iport; t=1400084145; x=1401293745; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vALBYOMgAgdCALd2WcFvi6W+Zyvw3V3y8THB/n+8Xa4=; b=EaiE2GrxtL98cXNi8U8IHBsT1nBYzxANlS/m0CB4IyWDT8yz3Y4FSFOH cqwg6MnJCD3bvyz+QTYPluvH7ugo+Wr5SuiGG0BfKchpLDMmPGedBGugS m8s6jUbdi+k7GV1jqjD3yZ0T0QJdWkyFiNJUzzzj47O30nhGSQ+YFCRQC 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAGyVc1OtJV2P/2dsb2JhbABZgmUhgSfFbwGBIxZ0giUBAQEEOj0CDAQCAQgRBAEBAQoUCQcyFAkIAgQOBQiIOQHRHBeOHTEHBoMlgRUBA6xlgXeBP4Iw X-IronPort-AV: E=Sophos;i="4.97,1053,1389744000"; d="scan'208";a="324892528" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP; 14 May 2014 16:15:45 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s4EGFia2021463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 16:15:44 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.03.0123.003; Wed, 14 May 2014 11:15:44 -0500 From: "Nobo Akiya (nobo)" To: Hannes Gredler Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Topic: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Index: AQHPasw+3TfBhqItW0CgAHCwI2S40Zs3F30AgAliegCAABUCAIAAARwAgAACvoD//61T8IAAWImA//+vVVA= Date: Wed, 14 May 2014 16:15:43 +0000 Message-ID: References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> <20140514153641.GC13993@pfrc> <20140514155739.GA14148@juniper.net> In-Reply-To: <20140514155739.GA14148@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/lYr1RrV6e7Us3yNYdnRqC4TbAQ4 Cc: "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 14 May 2014 16:15:55 -0000 Hi Hannes, Please see in-line. > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Wednesday, May 14, 2014 11:58 AM > To: Nobo Akiya (nobo) > Cc: Jeffrey Haas; Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf= .org > Subject: Re: [Isis-wg] New Version Notification for draft-ginsberg-isis-s= bfd- > discriminator-00.txt >=20 > On Wed, May 14, 2014 at 03:48:10PM +0000, Nobo Akiya (nobo) wrote: > | Hi Jeff, > | > | > On Wed, May 14, 2014 at 05:26:52PM +0200, Hannes Gredler wrote: > | > > On May 14, 2014, at 5:22 PM, Les Ginsberg (ginsberg) wrote: > | > > > Thanx for the comments. > | > > > I don't see how your proposal solves the problem you are > | > > > attempting to > | > address. The sender of the S-BFD packet has no control over what > | > interface is used to receive the packet on the target node. > | > Associating it with a prefix will not help in that regard. > | > > > | > > well it would help first endpoint discovery and pinning down BFD > | > > traffic to > | > particular line card. > | > > | > Indeed. In the SPRING related case (or even some MPLS scenarios), > | > traffic may be heavily steered to a given interface. This interface > | > may not even be to a router, but may be an ingress for a SFC device > | > and that ingress is critical for the execution of the chain. > | > | In those cases, one should be sending S-BFD packet in-band, which would > go through the specific interface/LC to reach the reflector session on th= e > target node (i.e. outage will be detected regardless of the discriminator > used). So having separate reflector discriminator won't be adding further > benefit. > | > | Flip side is, if a reflector is hosted on LC 1 and traffic engineered t= unnel is > terminating on LC2, then outage of LC1 can cause the "no S-BFD response" > on the tunnel terminating on LC2. However, I would think this is a limita= tion > with implementation. >=20 > what about AF discovery ? - how would a receiver know what AF a S-BFD > session to bring up with ? I was under the impression that IP header (i.e version) can distinguish the= AF if implementations required demux'ing received S-BFD packet based on AF= . If I missed your point/question, do clarify. -Nobo From nobody Wed May 14 09:23:18 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B891D1A02E1; Wed, 14 May 2014 09:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-zoU64MVKxx; Wed, 14 May 2014 09:23:10 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0098.outbound.protection.outlook.com [207.46.100.98]) by ietfa.amsl.com (Postfix) with ESMTP id D777D1A02D1; Wed, 14 May 2014 09:23:08 -0700 (PDT) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) by BL2PR05MB066.namprd05.prod.outlook.com (10.255.232.19) with Microsoft SMTP Server (TLS) id 15.0.944.11; Wed, 14 May 2014 16:23:00 +0000 Received: from [172.29.4.101] (66.129.239.16) by pod51010.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.459.0; Wed, 14 May 2014 16:23:00 +0000 Subject: Re: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: Date: Wed, 14 May 2014 18:22:57 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <7F0CA0C7-CFD2-4B51-BA0A-A7F167B05B42@juniper.net> References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> <20140514153641.GC13993@pfrc> <20140514155739.GA14148@juniper.net> To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.239.16] X-Forefront-PRVS: 0211965D06 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(13464003)(24454002)(377454003)(199002)(189002)(19580395003)(87286001)(87936001)(21056001)(83072002)(92566001)(89996001)(20776003)(82746002)(76176999)(50466002)(4396001)(19580405001)(97756001)(66066001)(81342001)(80022001)(85852003)(64706001)(50226001)(47776003)(83322001)(99396002)(88136002)(50986999)(81542001)(77096999)(36756003)(83716003)(33656001)(101416001)(79102001)(92726001)(62966002)(46406003)(46102001)(57306001)(74502001)(77156001)(76482001)(23726002)(86362001)(15975445006)(93916002)(74662001)(31966008)(102836001)(77982001)(561944003); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR05MB066; H:BL2PRD0510HT004.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=hannes@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Ucl_yLSEj_7BlDldHQPEywOKsjc Cc: "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 14 May 2014 16:23:12 -0000 nobo, assume that the advertising node only supports BFD4 and the receiving node does support only BFD6. -=20 how to detect such a condition ? /hannes On May 14, 2014, at 6:15 PM, Nobo Akiya (nobo) wrote: > Hi Hannes, >=20 > Please see in-line. >=20 >> -----Original Message----- >> From: Hannes Gredler [mailto:hannes@juniper.net] >> Sent: Wednesday, May 14, 2014 11:58 AM >> To: Nobo Akiya (nobo) >> Cc: Jeffrey Haas; Les Ginsberg (ginsberg); rtg-bfd@ietf.org; = isis-wg@ietf.org >> Subject: Re: [Isis-wg] New Version Notification for = draft-ginsberg-isis-sbfd- >> discriminator-00.txt >>=20 >> On Wed, May 14, 2014 at 03:48:10PM +0000, Nobo Akiya (nobo) wrote: >> | Hi Jeff, >> | >> | > On Wed, May 14, 2014 at 05:26:52PM +0200, Hannes Gredler wrote: >> | > > On May 14, 2014, at 5:22 PM, Les Ginsberg (ginsberg) wrote: >> | > > > Thanx for the comments. >> | > > > I don't see how your proposal solves the problem you are >> | > > > attempting to >> | > address. The sender of the S-BFD packet has no control over what >> | > interface is used to receive the packet on the target node. >> | > Associating it with a prefix will not help in that regard. >> | > > >> | > > well it would help first endpoint discovery and pinning down = BFD >> | > > traffic to >> | > particular line card. >> | > >> | > Indeed. In the SPRING related case (or even some MPLS = scenarios), >> | > traffic may be heavily steered to a given interface. This = interface >> | > may not even be to a router, but may be an ingress for a SFC = device >> | > and that ingress is critical for the execution of the chain. >> | >> | In those cases, one should be sending S-BFD packet in-band, which = would >> go through the specific interface/LC to reach the reflector session = on the >> target node (i.e. outage will be detected regardless of the = discriminator >> used). So having separate reflector discriminator won't be adding = further >> benefit. >> | >> | Flip side is, if a reflector is hosted on LC 1 and traffic = engineered tunnel is >> terminating on LC2, then outage of LC1 can cause the "no S-BFD = response" >> on the tunnel terminating on LC2. However, I would think this is a = limitation >> with implementation. >>=20 >> what about AF discovery ? - how would a receiver know what AF a S-BFD >> session to bring up with ? >=20 > I was under the impression that IP header (i.e version) can = distinguish the AF if implementations required demux'ing received S-BFD = packet based on AF. If I missed your point/question, do clarify. >=20 > -Nobo >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Wed May 14 10:02:27 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227781A02B2; Wed, 14 May 2014 10:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.152 X-Spam-Level: X-Spam-Status: No, score=-110.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtnhcY5xwVAc; Wed, 14 May 2014 10:02:22 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id B74721A029F; Wed, 14 May 2014 10:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3834; q=dns/txt; s=iport; t=1400086935; x=1401296535; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=48bLEeyNl0uqxbA8H1moYbOcufzP59CkBFvkk7lOqYw=; b=K5qysW/9lc2XAufDbticqz22n97Gq4ZD2N530+JhhzPlJc2lu5WU+irJ vntJDoQEdl0z/rekSpZTrwuZbSLYD7UyFoMs+kEZOZeaFJef9CrUKh0Ve pYv60WrZcUqef4anSyxMKqtuQWHRjgVIwYVZvRyhJSpGr+8PuAhgcegAx I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFACygc1OtJV2Q/2dsb2JhbABZgmUhT1i+NIc7AYEjFnSCJQEBAQMBAQEBNzQJAgUHBAIBCBEEAQEBChQJBycLFAkIAgQOBQiIMQgBDNEdEwSOHTEHBoMlgRUBA6xlgXeBP4Iw X-IronPort-AV: E=Sophos;i="4.97,1053,1389744000"; d="scan'208";a="43809975" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP; 14 May 2014 17:02:11 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4EH2BEN031325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 17:02:11 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 14 May 2014 12:02:11 -0500 From: "Nobo Akiya (nobo)" To: Hannes Gredler Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Topic: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Index: AQHPasw+3TfBhqItW0CgAHCwI2S40Zs3F30AgAliegCAABUCAIAAARwAgAACvoD//61T8IAAWImA//+vVVCAAFe9gP//sQWw Date: Wed, 14 May 2014 17:02:10 +0000 Message-ID: References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> <20140514153641.GC13993@pfrc> <20140514155739.GA14148@juniper.net> <7F0CA0C7-CFD2-4B51-BA0A-A7F167B05B42@juniper.net> In-Reply-To: <7F0CA0C7-CFD2-4B51-BA0A-A7F167B05B42@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ZECLZtuN_qXuUCU-kPNCYjWJlOs Cc: "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 14 May 2014 17:02:24 -0000 Hi Hannes, > assume that the advertising node only supports BFD4 and the receiving > node does support only BFD6. - how to detect such a condition ? Ah I see. You are talking about S-BFD capability. i.e. IPv4 IPv6 MPLSv4 MPLSv6 SR-MPLS SR-IPv6 Etc One doesn't necessary have to solve this via assigning and advertising diff= erent discriminator per "feature" .. you would then have to advertise what = "feature" each discriminator is for, with IANA maintained "feature" value. Other approach is for a node to advertise the capability separate from disc= riminator value. You would also need IANA maintained "feature" value for th= is. Another approach is to not define/advertise the S-BFD capabilities, but rel= y on operators to provision S-BFD for only those "features" which are known= to be supported by relevant network nodes. In summary, S-BFD capability might be something needed, but that doesn't ne= cessary have to be tied to discriminator advertisement. Those are some possibilities that I can think of. Do you have any thoughts = around this? - Nobo >=20 > /hannes >=20 >=20 > On May 14, 2014, at 6:15 PM, Nobo Akiya (nobo) wrote: >=20 > > Hi Hannes, > > > > Please see in-line. > > > >> -----Original Message----- > >> From: Hannes Gredler [mailto:hannes@juniper.net] > >> Sent: Wednesday, May 14, 2014 11:58 AM > >> To: Nobo Akiya (nobo) > >> Cc: Jeffrey Haas; Les Ginsberg (ginsberg); rtg-bfd@ietf.org; > >> isis-wg@ietf.org > >> Subject: Re: [Isis-wg] New Version Notification for > >> draft-ginsberg-isis-sbfd- discriminator-00.txt > >> > >> On Wed, May 14, 2014 at 03:48:10PM +0000, Nobo Akiya (nobo) wrote: > >> | Hi Jeff, > >> | > >> | > On Wed, May 14, 2014 at 05:26:52PM +0200, Hannes Gredler wrote: > >> | > > On May 14, 2014, at 5:22 PM, Les Ginsberg (ginsberg) wrote: > >> | > > > Thanx for the comments. > >> | > > > I don't see how your proposal solves the problem you are > >> | > > > attempting to > >> | > address. The sender of the S-BFD packet has no control over what > >> | > interface is used to receive the packet on the target node. > >> | > Associating it with a prefix will not help in that regard. > >> | > > > >> | > > well it would help first endpoint discovery and pinning down > >> | > > BFD traffic to > >> | > particular line card. > >> | > > >> | > Indeed. In the SPRING related case (or even some MPLS > >> | > scenarios), traffic may be heavily steered to a given interface. > >> | > This interface may not even be to a router, but may be an ingress > >> | > for a SFC device and that ingress is critical for the execution of= the > chain. > >> | > >> | In those cases, one should be sending S-BFD packet in-band, which > >> | would > >> go through the specific interface/LC to reach the reflector session > >> on the target node (i.e. outage will be detected regardless of the > >> discriminator used). So having separate reflector discriminator won't > >> be adding further benefit. > >> | > >> | Flip side is, if a reflector is hosted on LC 1 and traffic > >> | engineered tunnel is > >> terminating on LC2, then outage of LC1 can cause the "no S-BFD > response" > >> on the tunnel terminating on LC2. However, I would think this is a > >> limitation with implementation. > >> > >> what about AF discovery ? - how would a receiver know what AF a S-BFD > >> session to bring up with ? > > > > I was under the impression that IP header (i.e version) can distinguish= the > AF if implementations required demux'ing received S-BFD packet based on > AF. If I missed your point/question, do clarify. > > > > -Nobo > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Thu May 15 02:21:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821171A0442; Thu, 15 May 2014 02:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDaMPbx3eLsT; Thu, 15 May 2014 02:21:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8F51A0441; Thu, 15 May 2014 02:21:45 -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.7-GA FastPath queued) with ESMTP id BEE29839; Thu, 15 May 2014 09:21:37 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 10:20:38 +0100 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 10:21:15 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.13]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Thu, 15 May 2014 17:21:09 +0800 From: Mach Chen To: "Nobo Akiya (nobo)" , Hannes Gredler Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Topic: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Index: AQHPasxAEriQ17fwwkKZMW0VvzcsSJs2PY8AgAliegCAABUCAIAAARwAgAACvoCAAAM2AIAAAqaAgAAFDICAAAIGgIAACvUAgAGVQEA= Date: Thu, 15 May 2014 09:21:08 +0000 Message-ID: References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> <20140514153641.GC13993@pfrc> <20140514155739.GA14148@juniper.net> <7F0CA0C7-CFD2-4B51-BA0A-A7F167B05B42@juniper.net> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/S1LD4phuhnlzMLCCTxBhEBzAA1A Cc: "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 15 May 2014 09:21:48 -0000 Hi Nobo and Hannes, IMHO, the capability issue should not be a S-BFD specific issue, even not B= FD specified issue. It is actually a forwarding capability issue, it is abo= ut whether the target node can process IPv4, IPv6, MPLS, SR encapsulated BF= D packets.=20 Best regards, Mach > -----Original Message----- > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Nobo Akiya (= nobo) > Sent: Thursday, May 15, 2014 1:02 AM > To: Hannes Gredler > Cc: Jeffrey Haas; Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf= .org > Subject: Re: [Isis-wg] New Version Notification for > draft-ginsberg-isis-sbfd-discriminator-00.txt >=20 > Hi Hannes, >=20 > > assume that the advertising node only supports BFD4 and the receiving > > node does support only BFD6. - how to detect such a condition ? >=20 > Ah I see. You are talking about S-BFD capability. >=20 > i.e. >=20 > IPv4 > IPv6 > MPLSv4 > MPLSv6 > SR-MPLS > SR-IPv6 > Etc >=20 > One doesn't necessary have to solve this via assigning and advertising di= fferent > discriminator per "feature" .. you would then have to advertise what "fea= ture" > each discriminator is for, with IANA maintained "feature" value. >=20 > Other approach is for a node to advertise the capability separate from > discriminator value. You would also need IANA maintained "feature" value = for > this. >=20 > Another approach is to not define/advertise the S-BFD capabilities, but r= ely on > operators to provision S-BFD for only those "features" which are known to= be > supported by relevant network nodes. >=20 > In summary, S-BFD capability might be something needed, but that doesn't > necessary have to be tied to discriminator advertisement. >=20 > Those are some possibilities that I can think of. Do you have any thought= s around > this? >=20 > - Nobo >=20 > > > > /hannes > > > > > > On May 14, 2014, at 6:15 PM, Nobo Akiya (nobo) wrote: > > > > > Hi Hannes, > > > > > > Please see in-line. > > > > > >> -----Original Message----- > > >> From: Hannes Gredler [mailto:hannes@juniper.net] > > >> Sent: Wednesday, May 14, 2014 11:58 AM > > >> To: Nobo Akiya (nobo) > > >> Cc: Jeffrey Haas; Les Ginsberg (ginsberg); rtg-bfd@ietf.org; > > >> isis-wg@ietf.org > > >> Subject: Re: [Isis-wg] New Version Notification for > > >> draft-ginsberg-isis-sbfd- discriminator-00.txt > > >> > > >> On Wed, May 14, 2014 at 03:48:10PM +0000, Nobo Akiya (nobo) wrote: > > >> | Hi Jeff, > > >> | > > >> | > On Wed, May 14, 2014 at 05:26:52PM +0200, Hannes Gredler wrote: > > >> | > > On May 14, 2014, at 5:22 PM, Les Ginsberg (ginsberg) wrote: > > >> | > > > Thanx for the comments. > > >> | > > > I don't see how your proposal solves the problem you are > > >> | > > > attempting to > > >> | > address. The sender of the S-BFD packet has no control over > > >> | > what interface is used to receive the packet on the target node. > > >> | > Associating it with a prefix will not help in that regard. > > >> | > > > > >> | > > well it would help first endpoint discovery and pinning down > > >> | > > BFD traffic to > > >> | > particular line card. > > >> | > > > >> | > Indeed. In the SPRING related case (or even some MPLS > > >> | > scenarios), traffic may be heavily steered to a given interface. > > >> | > This interface may not even be to a router, but may be an > > >> | > ingress for a SFC device and that ingress is critical for the > > >> | > execution of the > > chain. > > >> | > > >> | In those cases, one should be sending S-BFD packet in-band, which > > >> | would > > >> go through the specific interface/LC to reach the reflector session > > >> on the target node (i.e. outage will be detected regardless of the > > >> discriminator used). So having separate reflector discriminator > > >> won't be adding further benefit. > > >> | > > >> | Flip side is, if a reflector is hosted on LC 1 and traffic > > >> | engineered tunnel is > > >> terminating on LC2, then outage of LC1 can cause the "no S-BFD > > response" > > >> on the tunnel terminating on LC2. However, I would think this is a > > >> limitation with implementation. > > >> > > >> what about AF discovery ? - how would a receiver know what AF a > > >> S-BFD session to bring up with ? > > > > > > I was under the impression that IP header (i.e version) can > > > distinguish the > > AF if implementations required demux'ing received S-BFD packet based > > on AF. If I missed your point/question, do clarify. > > > > > > -Nobo > > > > > > _______________________________________________ > > > Isis-wg mailing list > > > Isis-wg@ietf.org > > > https://www.ietf.org/mailman/listinfo/isis-wg >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Thu May 15 07:08:36 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3F51A0527; Thu, 15 May 2014 07:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryuu-LWKLQbu; Thu, 15 May 2014 07:08:30 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F651A00BE; Thu, 15 May 2014 07:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=939; q=dns/txt; s=iport; t=1400162863; x=1401372463; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YTzp1eIJglKY4Z+I9MCrgRT8/MGBAW36xNrBrV0Fuvk=; b=JgaeLhDM8irdpfFLOdUTk7URwkanzzPuQL9bfURsBgUxNwOAdG+/2B2w wA0hh2yyRxESUAtIkhb1COWWDe889PKaJMsIGgmQFga0ZwMqR4SnjBkhK /cmyXd0ZhkhTfh5AZbanj7RX/W6CIhN7s4L9Dsb62AaEtMpweat5ZwkEU k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFANLJdFOtJV2P/2dsb2JhbABZgmUhgSfFFwGBEBZ0giUBAQEDATo9AgULAgEIIhQQMiUCBAENDYgxCAHRGReOHTEHgyuBFQEDrGWBd4E/gjA X-IronPort-AV: E=Sophos;i="4.97,1059,1389744000"; d="scan'208";a="325135622" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP; 15 May 2014 14:07:17 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s4FE7GCB010716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 May 2014 14:07:16 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Thu, 15 May 2014 09:07:16 -0500 From: "Nobo Akiya (nobo)" To: Mach Chen , Hannes Gredler Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Topic: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Index: AQHPasw+3TfBhqItW0CgAHCwI2S40Zs3F30AgAliegCAABUCAIAAARwAgAACvoD//61T8IAAWImA//+vVVCAAFe9gP//sQWwAC1upQAAAPyhsA== Date: Thu, 15 May 2014 14:07:15 +0000 Message-ID: References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> <20140514153641.GC13993@pfrc> <20140514155739.GA14148@juniper.net> <7F0CA0C7-CFD2-4B51-BA0A-A7F167B05B42@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/tPaTpjiFESUuXY60vS2_DKxbEhw Cc: "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 15 May 2014 14:08:32 -0000 Hi Mach, Hannes, et al, > IMHO, the capability issue should not be a S-BFD specific issue, even not > BFD specified issue. It is actually a forwarding capability issue, it is = about > whether the target node can process IPv4, IPv6, MPLS, SR encapsulated BFD > packets. I agree Mach, mostly :) I can also see one arguing that forwarding supporting X does not always mea= n S-BFD is supported on X. If we want to address this, then it is an S-BFD = specific issue, and we _may_ want to solve this via introducing S-BFD capab= ility advertisements. With that said, S-BFD discriminator advertisement is one area which the cap= ability problem can be solved, but not necessary a problem that has to be s= olved with S-BFD discriminator advertisement. Rather I don't think the two = should be bundled together. Let us continue the capability discussion separate from the discriminator a= dvertisements? -Nobo =20 From nobody Tue May 20 15:46:08 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4761A03F1; Tue, 20 May 2014 15:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjhgyLBeQdCY; Tue, 20 May 2014 15:45:51 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCE8E1A03F6; Tue, 20 May 2014 15:45:47 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-3b-537b88f76f6f Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 7C.87.11744.7F88B735; Tue, 20 May 2014 18:55:20 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Tue, 20 May 2014 18:45:44 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , Mach Chen , Hannes Gredler Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Topic: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Index: AQHPasw+ft5/3BK2OUCTWOWP0ceEqZs2wwSAgAmmLwCAABUDAIAAARwAgAACvoCAAAM1AIAAAqaAgAAFDYCAAAIFgIAACvUAgAERhQCAAE/xgIAIJyKA Date: Tue, 20 May 2014 22:45:43 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7BFAA3@eusaamb103.ericsson.se> References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> <20140514153641.GC13993@pfrc> <20140514155739.GA14148@juniper.net> <7F0CA0C7-CFD2-4B51-BA0A-A7F167B05B42@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyuXRPrO6Pjupgg5+XhSw2/NnIbtF/7wmb xdFD71ktLqwVtpjdEW/x+c82Rgc2jym/N7J6tBx5y+qxZMlPJo/rTVfZA1iiuGxSUnMyy1KL 9O0SuDK2nrjKWHCQr+L+47vMDYwPuLsYOTkkBEwkZravYYSwxSQu3FvP1sXIxSEkcJRRYta/ TihnOaPE5t/f2UGq2ASMJF5s7AGzRQQKJTqPL2ACKWIWaGKU6O6cBTZKWCBZ4n7DKTaIohSJ 5m9fGEGKRECK2j/OYAJJsAioStx6uRxoEgcHr4CvxIn/4RDbWtkkvh75xQxSwwkUn3O/E2wQ I9B930+tAetlFhCXuPVkPhPE3QISS/acZ4awRSVePv7HCmErSuzrn84OUa8jsWD3JzYIW1ti 2cLXYPW8AoISJ2c+YZnAKDYLydhZSFpmIWmZhaRlASPLKkaO0uLUstx0I8NNjMAYOybB5riD ccEny0OMAhyMSjy8C9Srg4VYE8uKK3MPMUpzsCiJ8+65VhUsJJCeWJKanZpakFoUX1Sak1p8 iJGJg1OqgTH778lN/7/wWPexiQrK287ayudv5KNlJxCp7cw7N6De6Gj5JGku89NTZpz+dtt3 dmRqaq+Myq8ZjHyTJ8wUYDTcN3nb9e+JIrOYJU4YBHK3sPKqvbonYtMqYyvKxhIlnNig9fLW rdbg2uy7zhoVLLUJO06GcVZsjvxr8+2F38F90w+Ft63hVGIpzkg01GIuKk4EAOk38pSSAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/k98DJ57GtxCtPS4zZj-UfuIeeMI Cc: "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 20 May 2014 22:46:00 -0000 Dear All, according to Section 7 of the S-BFD Base document differentiation among add= ress families by S-BFD is optional and mention in connection to separate S-= BFD reflectors to act as per-AF reflectors. Perhaps I've missed that part o= f S-BFD Base discussion but I don't see the benefit of supporting such mode= . BFD control packets been AF-agnostic since RFC 5880 and I think that S-BF= D should maintain that approach. I agree with Mach that discriminators in S-BFD, as well as in BFD, are and = must remain AF blind. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Thursday, May 15, 2014 7:07 AM To: Mach Chen; Hannes Gredler Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbf= d-discriminator-00.txt Hi Mach, Hannes, et al, > IMHO, the capability issue should not be a S-BFD specific issue, even=20 > not BFD specified issue. It is actually a forwarding capability issue,=20 > it is about whether the target node can process IPv4, IPv6, MPLS, SR=20 > encapsulated BFD packets. I agree Mach, mostly :) I can also see one arguing that forwarding supporting X does not always mea= n S-BFD is supported on X. If we want to address this, then it is an S-BFD = specific issue, and we _may_ want to solve this via introducing S-BFD capab= ility advertisements. With that said, S-BFD discriminator advertisement is one area which the cap= ability problem can be solved, but not necessary a problem that has to be s= olved with S-BFD discriminator advertisement. Rather I don't think the two = should be bundled together. Let us continue the capability discussion separate from the discriminator a= dvertisements? -Nobo =20 From nobody Tue May 20 18:18:11 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5DF1A03F6; Tue, 20 May 2014 18:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUStCZViQsG0; Tue, 20 May 2014 18:18:09 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A1B1A03F5; Tue, 20 May 2014 18:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3305; q=dns/txt; s=iport; t=1400635088; x=1401844688; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wlTV2nqSKdI/05rByGrVdKIBeJJX65/hWG9um09piZw=; b=ZmGFPkfpBjVnGnZiIMf28L+X5cSDxhZsX85RReJO1IcpX9MD9bSr54wz cJg57sBKKUnxap4Gx3jWwaeX5LjAZE8WBX4NjslzsVgR5FnDmNBpr4zne 4GqwyRlW68DswXjSVB4K9Gj4PBKc/Z15v3z0CDTc9BmvwY6pbjx25A0J5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0FAKv9e1OtJA2E/2dsb2JhbABZgmUhgSnEJQGBGBZ0giUBAQEEOj0CDAQCAQgRBAEBCxQJBzIUCQgCBAENBQiIOQHUTheOHTEHBoMlgRUBA60IgXiBQIIw X-IronPort-AV: E=Sophos;i="4.98,877,1392163200"; d="scan'208";a="326360151" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP; 21 May 2014 01:18:07 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s4L1I7WF016171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 May 2014 01:18:07 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 20 May 2014 20:18:07 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , Mach Chen , Hannes Gredler Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Topic: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Index: AQHPasw+3TfBhqItW0CgAHCwI2S40Zs3F30AgAliegCAABUCAIAAARwAgAACvoD//61T8IAAWImA//+vVVCAAFe9gP//sQWwAC1upQAAAPyhsAEWkeyAAAVxzVA= Date: Wed, 21 May 2014 01:18:06 +0000 Message-ID: References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> <20140514153641.GC13993@pfrc> <20140514155739.GA14148@juniper.net> <7F0CA0C7-CFD2-4B51-BA0A-A7F167B05B42@juniper.net> <7347100B5761DC41A166AC17F22DF1121B7BFAA3@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7BFAA3@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/MzkMrU_W9ZPeqxVCv0klIy42OSM Cc: "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 21 May 2014 01:18:10 -0000 Hi Greg, That's true, the whole paragraph in the section 7 of S-BFD base document is= just describing some possible implementation techniques. How about we chan= ge the paragraph: [old] Note that incoming BFD control packets destined to BFD target identifier types may be IPv4, IPv6 or MPLS based. For those BFD target identifier types, implementations MAY either allow the same reflector BFD session to handle all incoming BFD control packets in address family agnostic fashion, or setup multiple reflector BFD sessions to handle incoming BFD control packets with different address families. This policy is again a local matter, and is outside the scope of this document. [new] Note that incoming BFD control packets destined to BFD target identifier types may be IPv4, IPv6 or MPLS based. How such packets reach an appropriate reflector BFD session is a local matter, and is outside the scope of this document. -Nobo > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Tuesday, May 20, 2014 6:46 PM > To: Nobo Akiya (nobo); Mach Chen; Hannes Gredler > Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org > Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-s= bfd- > discriminator-00.txt >=20 > Dear All, > according to Section 7 of the S-BFD Base document differentiation among > address families by S-BFD is optional and mention in connection to separa= te > S-BFD reflectors to act as per-AF reflectors. Perhaps I've missed that pa= rt of > S-BFD Base discussion but I don't see the benefit of supporting such mode= . > BFD control packets been AF-agnostic since RFC 5880 and I think that S-BF= D > should maintain that approach. >=20 > I agree with Mach that discriminators in S-BFD, as well as in BFD, are an= d > must remain AF blind. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Thursday, May 15, 2014 7:07 AM > To: Mach Chen; Hannes Gredler > Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org > Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-s= bfd- > discriminator-00.txt >=20 > Hi Mach, Hannes, et al, >=20 > > IMHO, the capability issue should not be a S-BFD specific issue, even > > not BFD specified issue. It is actually a forwarding capability issue, > > it is about whether the target node can process IPv4, IPv6, MPLS, SR > > encapsulated BFD packets. >=20 > I agree Mach, mostly :) >=20 > I can also see one arguing that forwarding supporting X does not always > mean S-BFD is supported on X. If we want to address this, then it is an S= -BFD > specific issue, and we _may_ want to solve this via introducing S-BFD > capability advertisements. >=20 > With that said, S-BFD discriminator advertisement is one area which the > capability problem can be solved, but not necessary a problem that has to > be solved with S-BFD discriminator advertisement. Rather I don't think th= e > two should be bundled together. >=20 > Let us continue the capability discussion separate from the discriminator > advertisements? >=20 > -Nobo >=20 From nobody Tue May 20 18:21:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE7C1A03F5; Tue, 20 May 2014 18:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKseOkfwCvZL; Tue, 20 May 2014 18:21:46 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1491E1A03F0; Tue, 20 May 2014 18:21:46 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-fc-537bad84a2a8 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4A.DA.11744.48DAB735; Tue, 20 May 2014 21:31:17 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Tue, 20 May 2014 21:21:43 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , Mach Chen , Hannes Gredler Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Topic: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Index: AQHPasw+ft5/3BK2OUCTWOWP0ceEqZs2wwSAgAmmLwCAABUDAIAAARwAgAACvoCAAAM1AIAAAqaAgAAFDYCAAAIFgIAACvUAgAERhQCAAE/xgIAIJyKAgABv9QD//72YMA== Date: Wed, 21 May 2014 01:21:42 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7C011B@eusaamb103.ericsson.se> References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> <20140514153641.GC13993@pfrc> <20140514155739.GA14148@juniper.net> <7F0CA0C7-CFD2-4B51-BA0A-A7F167B05B42@juniper.net> <7347100B5761DC41A166AC17F22DF1121B7BFAA3@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyuXRPoG7r2upgg8a5XBYb/mxkt+i/94TN 4uih96wWF9YKW8zuiLf4/GcbowObx5TfG1k9Wo68ZfVYsuQnk8f1pqvsASxRXDYpqTmZZalF +nYJXBn9J9YwFrTJVhzd9pW5gXGfeBcjJ4eEgInEuWUtbBC2mMSFe+vBbCGBo4wSh27ndjFy AdnLGSX+fFzACJJgEzCSeLGxhx3EFhEolOg8voAJpIhZoIlRortzFliRsECyxP2GU2wQRSkS zd++MIIUiQhMYpT492odWIJFQFXiT8dusAZeAV+Jn+dWs0Cs62GX+HDtJ1ARBwcnUOLxUi6Q Gkag876fWsMEYjMLiEvcejKfCeJsAYkle84zQ9iiEi8f/2OFsJUkJi09xwpRryOxYPcnNghb W2LZwtfMEHsFJU7OfMIygVFsFpKxs5C0zELSMgtJywJGllWMHKXFqWW56UaGmxiBEXZMgs1x B+OCT5aHGAU4GJV4eBeoVwcLsSaWFVfmHmKU5mBREufdc60qWEggPbEkNTs1tSC1KL6oNCe1 +BAjEwenVANj0APmF4lRNr+Pdz36cmtbZO52jYcpzncSmQUmvXwm+6rKQk/5Au/yWSHKNj8C DV1r/kY5FFYWRvw4YNRl4HFE3vCSrWh/UQGDrTN3v175muAgo7WK35XPbDKP0F1izij7fcmP PdvnaMWKxkx8pv7tDmfH2dbHwv7bZ16197G8OiNmybRtW3KVWIozEg21mIuKEwEBZznFkQIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/U4Ydsm0a59oFWsxIfocQlM3x0Gw Cc: "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 21 May 2014 01:21:48 -0000 Hi Nobo, I like it. Regards, Greg -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Tuesday, May 20, 2014 6:18 PM To: Gregory Mirsky; Mach Chen; Hannes Gredler Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbf= d-discriminator-00.txt Hi Greg, That's true, the whole paragraph in the section 7 of S-BFD base document is= just describing some possible implementation techniques. How about we chan= ge the paragraph: [old] Note that incoming BFD control packets destined to BFD target identifier types may be IPv4, IPv6 or MPLS based. For those BFD target identifier types, implementations MAY either allow the same reflector BFD session to handle all incoming BFD control packets in address family agnostic fashion, or setup multiple reflector BFD sessions to handle incoming BFD control packets with different address families. This policy is again a local matter, and is outside the scope of this document. [new] Note that incoming BFD control packets destined to BFD target identifier types may be IPv4, IPv6 or MPLS based. How such packets reach an appropriate reflector BFD session is a local matter, and is outside the scope of this document. -Nobo > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Tuesday, May 20, 2014 6:46 PM > To: Nobo Akiya (nobo); Mach Chen; Hannes Gredler > Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org > Subject: RE: [Isis-wg] New Version Notification for=20 > draft-ginsberg-isis-sbfd- discriminator-00.txt >=20 > Dear All, > according to Section 7 of the S-BFD Base document differentiation=20 > among address families by S-BFD is optional and mention in connection=20 > to separate S-BFD reflectors to act as per-AF reflectors. Perhaps I've=20 > missed that part of S-BFD Base discussion but I don't see the benefit of = supporting such mode. > BFD control packets been AF-agnostic since RFC 5880 and I think that=20 > S-BFD should maintain that approach. >=20 > I agree with Mach that discriminators in S-BFD, as well as in BFD, are=20 > and must remain AF blind. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo=20 > Akiya > (nobo) > Sent: Thursday, May 15, 2014 7:07 AM > To: Mach Chen; Hannes Gredler > Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org > Subject: RE: [Isis-wg] New Version Notification for=20 > draft-ginsberg-isis-sbfd- discriminator-00.txt >=20 > Hi Mach, Hannes, et al, >=20 > > IMHO, the capability issue should not be a S-BFD specific issue,=20 > > even not BFD specified issue. It is actually a forwarding capability=20 > > issue, it is about whether the target node can process IPv4, IPv6,=20 > > MPLS, SR encapsulated BFD packets. >=20 > I agree Mach, mostly :) >=20 > I can also see one arguing that forwarding supporting X does not=20 > always mean S-BFD is supported on X. If we want to address this, then=20 > it is an S-BFD specific issue, and we _may_ want to solve this via=20 > introducing S-BFD capability advertisements. >=20 > With that said, S-BFD discriminator advertisement is one area which=20 > the capability problem can be solved, but not necessary a problem that=20 > has to be solved with S-BFD discriminator advertisement. Rather I=20 > don't think the two should be bundled together. >=20 > Let us continue the capability discussion separate from the=20 > discriminator advertisements? >=20 > -Nobo >=20 From nobody Tue May 20 18:24:43 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E751A03F5; Tue, 20 May 2014 18:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC9Ke5dteITk; Tue, 20 May 2014 18:24:40 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2611A03F0; Tue, 20 May 2014 18:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4290; q=dns/txt; s=iport; t=1400635480; x=1401845080; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=r8LRIw+AQx0WKJyuxPMu5QPXwmwrarxhu+m7hMqDkSM=; b=IhsK96CpDFXwgB7HTniZtGkV0AVVW/Q7LvdIzqyvoG2FFl0uTmTWADot qlyYza7OpEIHhinHsTqzHeDrHaY/QHpV4WzARhZf1OnoOanZ2lAtHN7B1 ONZ7xdUBo2uwCklUtg+bSpwlxRXTd2S2Def9dl24Js801GKbTsusX9x2e I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0FAAEAfFOtJA2E/2dsb2JhbABZgmUhgSnEJQGBGBZ0giUBAQEEOj0CDAQCAQgRBAEBCxQJBzIUCQgCBAENBQiIOQHUUheOHTEHBoMlgRUBA60IgXiBQIIw X-IronPort-AV: E=Sophos;i="4.98,877,1392163200"; d="scan'208";a="326556744" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP; 21 May 2014 01:24:39 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s4L1OdP3018371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 May 2014 01:24:39 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Tue, 20 May 2014 20:24:38 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , Mach Chen , Hannes Gredler Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Topic: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Index: AQHPasw+3TfBhqItW0CgAHCwI2S40Zs3F30AgAliegCAABUCAIAAARwAgAACvoD//61T8IAAWImA//+vVVCAAFe9gP//sQWwAC1upQAAAPyhsAEWkeyAAAVxzVAAAADNAAAKbP0A Date: Wed, 21 May 2014 01:24:37 +0000 Message-ID: References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> <20140514153641.GC13993@pfrc> <20140514155739.GA14148@juniper.net> <7F0CA0C7-CFD2-4B51-BA0A-A7F167B05B42@juniper.net> <7347100B5761DC41A166AC17F22DF1121B7BFAA3@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7C011B@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7C011B@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/JkQ1R_7Sg3FpLOixC77yJwuW_zs Cc: "Les Ginsberg \(ginsberg\)" , "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 21 May 2014 01:24:42 -0000 Thanks for prompt response Greg. Will incorporate the text in draft-ietf-...-01. -Nobo > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Tuesday, May 20, 2014 9:22 PM > To: Nobo Akiya (nobo); Mach Chen; Hannes Gredler > Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org > Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-s= bfd- > discriminator-00.txt >=20 > Hi Nobo, > I like it. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Tuesday, May 20, 2014 6:18 PM > To: Gregory Mirsky; Mach Chen; Hannes Gredler > Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org > Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-s= bfd- > discriminator-00.txt >=20 > Hi Greg, >=20 > That's true, the whole paragraph in the section 7 of S-BFD base document = is > just describing some possible implementation techniques. How about we > change the paragraph: >=20 > [old] > Note that incoming BFD control packets destined to BFD target > identifier types may be IPv4, IPv6 or MPLS based. For those BFD > target identifier types, implementations MAY either allow the same > reflector BFD session to handle all incoming BFD control packets in > address family agnostic fashion, or setup multiple reflector BFD > sessions to handle incoming BFD control packets with different > address families. This policy is again a local matter, and is > outside the scope of this document. >=20 > [new] > Note that incoming BFD control packets destined to BFD target > identifier types may be IPv4, IPv6 or MPLS based. How such packets > reach an appropriate reflector BFD session is a local matter, and is > outside the scope of this document. >=20 > -Nobo >=20 > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Tuesday, May 20, 2014 6:46 PM > > To: Nobo Akiya (nobo); Mach Chen; Hannes Gredler > > Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org > > Subject: RE: [Isis-wg] New Version Notification for > > draft-ginsberg-isis-sbfd- discriminator-00.txt > > > > Dear All, > > according to Section 7 of the S-BFD Base document differentiation > > among address families by S-BFD is optional and mention in connection > > to separate S-BFD reflectors to act as per-AF reflectors. Perhaps I've > > missed that part of S-BFD Base discussion but I don't see the benefit o= f > supporting such mode. > > BFD control packets been AF-agnostic since RFC 5880 and I think that > > S-BFD should maintain that approach. > > > > I agree with Mach that discriminators in S-BFD, as well as in BFD, are > > and must remain AF blind. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > > Akiya > > (nobo) > > Sent: Thursday, May 15, 2014 7:07 AM > > To: Mach Chen; Hannes Gredler > > Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org > > Subject: RE: [Isis-wg] New Version Notification for > > draft-ginsberg-isis-sbfd- discriminator-00.txt > > > > Hi Mach, Hannes, et al, > > > > > IMHO, the capability issue should not be a S-BFD specific issue, > > > even not BFD specified issue. It is actually a forwarding capability > > > issue, it is about whether the target node can process IPv4, IPv6, > > > MPLS, SR encapsulated BFD packets. > > > > I agree Mach, mostly :) > > > > I can also see one arguing that forwarding supporting X does not > > always mean S-BFD is supported on X. If we want to address this, then > > it is an S-BFD specific issue, and we _may_ want to solve this via > > introducing S-BFD capability advertisements. > > > > With that said, S-BFD discriminator advertisement is one area which > > the capability problem can be solved, but not necessary a problem that > > has to be solved with S-BFD discriminator advertisement. Rather I > > don't think the two should be bundled together. > > > > Let us continue the capability discussion separate from the > > discriminator advertisements? > > > > -Nobo > > From nobody Wed May 21 06:08:51 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB08A1A03B9 for ; Wed, 21 May 2014 06:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2NtZI3XRfIG for ; Wed, 21 May 2014 06:08:49 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9B31A0360 for ; Wed, 21 May 2014 06:08:49 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 47ABBC26A; Wed, 21 May 2014 09:08:48 -0400 (EDT) Date: Wed, 21 May 2014 09:08:48 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: [mcr+ietf@sandelman.ca: NomCom 2014-2015 Call for Volunteers] Message-ID: <20140521130848.GE5675@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/SWNXDV8Rwrc_-dY43JqakUu15j8 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 21 May 2014 13:08:50 -0000 Please consider volunteering for the Nomcom. -- Jeff (former nomcom volunteer) ----- Forwarded message from Michael Richardson ----- Date: Fri, 16 May 2014 10:24:56 -0400 From: Michael Richardson To: ietf@ietf.org Subject: NomCom 2014-2015 Call for Volunteers {I have to post using my subscribed address. Appologies for duplicates} The IETF nominating committee (nomcom) process for 2014-15 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG (including IETF Chair). Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. Let's break the 200 volunteer mark again this year! The details of the operation of the nomcom can be found in RFC 3777, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are IETF 85(Atlanta), \ 86(Orlando), \ 87(Berlin), *** ANY THREE! 88(Vancouver), / 89(London) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2015 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: To be confirmed IAB: Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler IESG: Pete Resnick (Applications) Ted Lemon (Internet) Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) Jari Arkko (Gen) (names with * have publically indicated they will not serve another term) The primary activity for this nomcom will begin in July 2014 and should be completed in January 2015. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is also a very rewarding experience. It is very important that you be able to attend IETF91 to conduct interviews. Being at IETF90 is useful for training. Being at IETF92 is not essential. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 22, 2013, as follows: To: nomcom-chair-2014@ietf.org Subject: Nomcom 2014-15 Volunteer Please include the following information in the email body: // First/Given Name followed by Last/Family Name // matching how you enter it in the IETF Registration Form) // Typically what goes in the Company field // in the IETF Registration Form [] // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2014/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Michael Richardson mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org ----- End forwarded message ----- From nobody Thu May 22 16:32:31 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56931A024B; Thu, 22 May 2014 16:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6_POudWWByB; Thu, 22 May 2014 16:32:27 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFCA21A0248; Thu, 22 May 2014 16:32:26 -0700 (PDT) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4MNWJoi013113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 May 2014 19:32:22 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s4MNWJoi013113 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1400801542; bh=6EZCnk5+3sgtiHoL/h1BonDZCys=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=kFzycJz+lcRsoJlJUI3sp9uJIDa+cauFoUOU/MBhdFxSU5Tj4bo2as3s2Dbbx37y9 m8m+IZwV246XBivm61LfMTmZfo7fGggVKzI7BqEsukY1YXQ4o3FfqSkunQQ1tfCwhN SKrONHZSHt+OsEvtNZOIYP5HRc2y/1T8UhZs2ngU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s4MNWJoi013113 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd04.lss.emc.com (RSA Interceptor); Thu, 22 May 2014 16:32:06 -0700 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4MNW5LJ015389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 May 2014 19:32:06 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Thu, 22 May 2014 19:32:05 -0400 From: "Black, David" To: "tnadeau@lucidvision.com" , "zali@cisco.com" , "nobo@cisco.com" , "General Area Review Team (gen-art@ietf.org)" Date: Thu, 22 May 2014 19:32:04 -0400 Subject: Gen-ART review of draft-ietf-bfd-mib-20 Thread-Topic: Gen-ART review of draft-ietf-bfd-mib-20 Thread-Index: Ac92Fgm6xi+5RVqyQBG++mFam22lvQ== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C662E05@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public, Resumes Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/c-CcYEFszolKdaOy6iznBU9KLqI Cc: "rtg-bfd@ietf.org" , "Black, David" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 May 2014 23:32:29 -0000 And the -20 version is also ready. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Thursday, May 08, 2014 7:27 PM > To: tnadeau@lucidvision.com; zali@cisco.com; nobo@cisco.com; General Area > Review Team (gen-art@ietf.org) > Cc: rtg-bfd@ietf.org; ietf@ietf.org; Black, David > Subject: Gen-ART review of draft-ietf-bfd-mib-19 >=20 > Additional text has been added to the -19 version to address this remaini= ng > topic. The -19 version is Ready. >=20 > Thanks, > --David >=20 >=20 > > -----Original Message----- > > From: Black, David > > Sent: Monday, April 28, 2014 10:20 AM > > To: tnadeau@lucidvision.com; zali@cisco.com; nobo@cisco.com; General Ar= ea > > Review Team (gen-art@ietf.org) > > Cc: rtg-bfd@ietf.org; ietf@ietf.org; Black, David > > Subject: RE: Gen-ART review of draft-ietf-bfd-mib-18 > > > > The -18 version of this draft responds to all of the comments in the > > Gen-ART review of -17, including the request for coordination w/the > > OPS area, although I wasn't exactly expecting that to occur on the > > main IETF list. > > > > The -18 version is ready with one small nit - The following text has > > been added to the introduction: > > > > This memo does not define a compliance requirement for a system that > > only implements BFD version 0. This is a reflection of a considered > > and deliberate decision by the BFD WG. > > > > An explanation of the rationale for that decision would help - I sugges= t > > adding the following text and a suitable reference to the end of the te= xt > > above: > > > > because the BFD version 0 protocol may deadlock and hence SHOULD NOT > > be used, as explained further in [RFCxxxx]. > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Black, David > > > Sent: Wednesday, April 16, 2014 7:31 PM > > > To: tnadeau@lucidvision.com; zali@cisco.com; nobo@cisco.com; General = Area > > > Review Team (gen-art@ietf.org) > > > Cc: rtg-bfd@ietf.org; ietf@ietf.org; Black, David > > > Subject: Gen-ART review of draft-ietf-bfd-mib-17 > > > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > > Gen-ART, please see the FAQ at > > > > > > . > > > > > > Please resolve these comments along with any other Last Call comments > > > you may receive. > > > > > > Document: draft-ietf-bfd-mib-17 > > > Reviewer: David L. Black > > > Review Date: April 16, 2014 > > > IETF LC End Date: April 28, 2014 > > > > > > Summary: This draft is on the right track, but has open issues > > > described in the review. > > > > > > This draft is a MIB module for the BFD protocol, which is an importan= t > low- > > > level routing protocol. The draft is reasonable for a MIB draft; one > needs > > > to go read the protocol documents to understand how the protocol work= s, > and > > > significant portions of the text are derived from the usual MIB > > "boilerplate" > > > as one would expect. The "Brief Description of MIB Objects" is indee= d > > > brief, but reasonable. The shepherd writeup indicates that there are > > > multiple implementations. > > > > > > Major issues: > > > > > > This MIB contains many writable objects, so the authors should > > > take note of the IESG statement on writable MIB modules: > > > > > > http://www.ietf.org/iesg/statement/writable-mib-module.html > > > > > > I did not see this mentioned in the shepherd writeup. If the OPS Are= a > > > has not been consulted, I strongly suggest doing so during IETF Last > > > Call, e.g., starting with Benoit Claise (AD). > > > > > > Minor issues: > > > > > > The security considerations section includes considerations for > > > unauthorized modification of bfdSessAdminStatus and bfdSessOperStatus= , > > > but omits the corresponding considerations for bfdAdminStatus and > > > bfdSessNotificationsEnable. Both of the latter objects are global, > > > so significant damage can be inflicted via these objects with a > > > small number of unauthorized modifications, so they need to be > > > included in the first list of sensitive objects. > > > > > > I suggest that the authors recheck the entire MIB to ensure that > > > every object or table that should be included in the security > > > considerations section is appropriately included. > > > > > > Also, as a General Variable, would bfdSessNotificationsEnable be bett= er > > > named bfdNotificationsEnable, as it's not in the BFD Session Table? > > > > > > I did not see a compliance requirement for a system that only > > > implements BFD protocol version 0. That absence should at least be > > > mentioned somewhere. For example, if this reflects a considered and > > > deliberate decision by the WG, that should be mentioned in the > > > introduction. > > > > > > Nits/editorial comments: > > > > > > In the security considerations for authentication-related objects: > > > > > > OLD > > > In order for these sensitive information > > > from being improperly accessed, implementers MAY wish to disallow > > > access to these objects. > > > NEW > > > In order to prevent this sensitive information > > > from being improperly accessed, implementers MAY disallow > > > access to these objects. > > > > > > idnits 2.13.01 found a truly minor nit that should be corrected when > > > the draft is next revised: > > > > > > =3D=3D Outdated reference: A later version (-05) exists of > > > draft-ietf-bfd-tc-mib-04 > > > > > > it also generated a warning that probably does not reflect an actual > > problem: > > > > > > -- The document seems to lack a disclaimer for pre-RFC5378 work, bu= t may > > > have content which was first submitted before 10 November 2008. = If > you > > > have contacted all the original authors and they are all willing= to > > grant > > > the BCP78 rights to the IETF Trust, then this is fine, and you c= an > > ignore > > > this comment. If not, you may need to add the pre-RFC5378 > disclaimer. > > > (See the Legal Provisions document at > > > http://trustee.ietf.org/license-info for more information.) > > > > > > Thanks, > > > --David > > > ---------------------------------------------------- > > > David L. Black, Distinguished Engineer > > > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 2= 93-7786 > > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- From nobody Thu May 22 16:34:34 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249561A024B; Thu, 22 May 2014 16:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oczVRa38CFmq; Thu, 22 May 2014 16:34:27 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B749A1A0248; Thu, 22 May 2014 16:34:27 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3EE17C2D8; Thu, 22 May 2014 19:34:26 -0400 (EDT) Date: Thu, 22 May 2014 19:34:26 -0400 From: Jeffrey Haas To: "Black, David" Subject: Re: Gen-ART review of draft-ietf-bfd-mib-20 Message-ID: <20140522233426.GA561@pfrc> References: <8D3D17ACE214DC429325B2B98F3AE712076C662E05@MX15A.corp.emc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C662E05@MX15A.corp.emc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/y48Z8ovtL0qhjZItyb3pA2BGxJY Cc: "zali@cisco.com" , "General Area Review Team \(gen-art@ietf.org\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 22 May 2014 23:34:32 -0000 On Thu, May 22, 2014 at 07:32:04PM -0400, Black, David wrote: > And the -20 version is also ready. Thanks, --David Thank goodness. We were starting to get up into the drat-ietf-idr-bgp4-2^32-1 territory. Thanks for the thorough review, David. -- Jeff (who was probably the unfortunate party responsible for at least 7 spins) From nobody Thu May 22 17:11:27 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8328E1A0295; Thu, 22 May 2014 17:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1GghRwpK6TR; Thu, 22 May 2014 17:11:22 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07E51A0274; Thu, 22 May 2014 17:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=773; q=dns/txt; s=iport; t=1400803880; x=1402013480; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9F0qdbubr3QbwfgguzkKB2UzQ+xJYZn6uaXfG4241eU=; b=XOqu4sTPeWR6jEq9GxVPnUqUHc+hf24QBqh7JGWImCBR/fUEZrhfAsX0 qXVqyaccWW43toBD4fNttKKIRw8Ysk8hGSElY5WXyJQFbjpZu4R1tlwvJ SbBZ1QYALnLZKY/7d7bTiiYfXXsdM7VOKpNCtb+fH95EVQpURSvP6q43/ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAC2RflOtJA2F/2dsb2JhbABZgmUigSrEKwGBBxZ0giUBAQEEOj8MBAIBCA4DBAEBAQoUCQcyFAkIAQEEDgUIiDkB1zgXjh0xBwaDJYEVAQOtF4M4gjA X-IronPort-AV: E=Sophos;i="4.98,890,1392163200"; d="scan'208";a="46444252" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP; 23 May 2014 00:11:17 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s4N0BHQ8030505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 May 2014 00:11:17 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Thu, 22 May 2014 19:11:16 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas , "Black, David" Subject: RE: Gen-ART review of draft-ietf-bfd-mib-20 Thread-Topic: Gen-ART review of draft-ietf-bfd-mib-20 Thread-Index: Ac92Fgm6xi+5RVqyQBG++mFam22lvQAKj1gAAAlPN4A= Date: Fri, 23 May 2014 00:11:15 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE712076C662E05@MX15A.corp.emc.com> <20140522233426.GA561@pfrc> In-Reply-To: <20140522233426.GA561@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/6chApCb6woO97bSmfASU1BuB7PM Cc: "General Area Review Team \(gen-art@ietf.org\)" , "Zafar Ali \(zali\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 23 May 2014 00:11:23 -0000 Thanks for the time spent reviewing this draft again David! -Nobo > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Thursday, May 22, 2014 7:34 PM > To: Black, David > Cc: tnadeau@lucidvision.com; Zafar Ali (zali); Nobo Akiya (nobo); General > Area Review Team (gen-art@ietf.org); rtg-bfd@ietf.org > Subject: Re: Gen-ART review of draft-ietf-bfd-mib-20 >=20 > On Thu, May 22, 2014 at 07:32:04PM -0400, Black, David wrote: > > And the -20 version is also ready. Thanks, --David >=20 > Thank goodness. We were starting to get up into the > drat-ietf-idr-bgp4-2^32-1 territory. >=20 > Thanks for the thorough review, David. >=20 > -- Jeff (who was probably the unfortunate party responsible for at least = 7 > spins) From nobody Thu May 22 18:32:45 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E8C1A02B3 for ; Thu, 22 May 2014 18:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3c_vD0vB8NR2 for ; Thu, 22 May 2014 18:32:43 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94AAB1A02A3 for ; Thu, 22 May 2014 18:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1707; q=dns/txt; s=iport; t=1400808762; x=1402018362; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=M+CWeEEVe+pQeXb+Q3LpEQR7i2baYRhZimTIqpyRwPM=; b=ObdWgX1blthK/OJDZ4NyELQVqXOKVY0dgDLGOeJAofoi8P/U5irRaKhY xdPIb1PjenMP7+NTgalanQHGPkJMFJWja2AgCjMIBPDWR9rxpIe4Bu6eL GGNmfNNDbheEjX5y1bF86weIYd/Sp7MfjbdllpamKnGLk3kE/tMNVnY9a k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAO6jflOtJV2Y/2dsb2JhbABZgmUigSrEKAGBCRZ0gicBBCcTOBkBKhRCJgEEG4g5AaJTtFgXjh2DY4EVBK0XgziCMA X-IronPort-AV: E=Sophos;i="4.98,890,1392163200"; d="scan'208";a="327321515" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 23 May 2014 01:32:41 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s4N1Wf7i016321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 23 May 2014 01:32:41 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Thu, 22 May 2014 20:32:41 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: S-BFD Discriminator Types? Thread-Topic: S-BFD Discriminator Types? Thread-Index: Ac92Jo/4iM/K8nz3QxK1jtunOJIEPA== Date: Fri, 23 May 2014 01:32:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/gVWdddAb4OBfwmGW0H5cTRyz-wY X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 23 May 2014 01:32:45 -0000 Hi [S-]BFDers, As part of next set of changes for the bfd-seamless-base document, I wanted= us to revamp sections 3 and 4 which have become stale.=20 Current texts implies that we create following relationships in the BFD Tar= get Identifier Table. S-BFD Discriminator --> BFD Target Identifier --> BFD Target Identifier Ty= pe This is no longer necessary. Mapping of local S-BFD discriminators to local= entities can be created, but that's an implementation matter. This mapping= does not have to be mandated in the document. Which puts us in: Option #1: Define S-BFD Discriminator Types (renamed from BFD Target Identifier Type),= and define following relationships. S-BFD Discriminator --> S-BFD Discriminator Type. Now, the other question that I have is, do we need to define S-BFD Discrimi= nator Types, and they be IANA maintained? I do realize that there will be s= everal "types" of S-BFD discriminators over time. However, when S-BFD discr= iminators are advertised by applications, then those applications will be a= dvertising what each S-BFD discriminator is for (mapping to specific entity= ). Therefore, the application implies the "type" and the mapping implies th= e "context". If there is going to be any application that will be advertising multiple S= -BFD discriminator "types", then it _is_ beneficial for S-BFD base to defin= e those types. However, I am not finding any such use case at the moment. T= hat means, it is possible for us to clean up sections 3 and 4 even further,= and go with: Option #2: Do not define any BFD Target Identifier Types nor S-BFD Discriminator Types= . Any thoughts on this? -Nobo From nobody Tue May 27 17:46:51 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B48C1A0072; Tue, 27 May 2014 17:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbZCigDAVST6; Tue, 27 May 2014 17:46:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FEF1A02C5; Tue, 27 May 2014 17:46:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG Subject: Stephen Farrell's Block on charter-ietf-bfd-07-02: (with BLOCK) X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140528004621.19460.38085.idtracker@ietfa.amsl.com> Date: Tue, 27 May 2014 17:46:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2_wXOwfCro_QSPtGPmJfWDC0LfU Cc: rtg-bfd@ietf.org, bfd-chairs@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 00:46:26 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-bfd-07-02: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-bfd/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- The text refers to KARP, which is closing. What's the plan then? If its to do the work in BFD that's fine. From nobody Tue May 27 17:50:12 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA11A1A0833; Tue, 27 May 2014 17:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLd92rXLO8Sf; Tue, 27 May 2014 17:50:08 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B79901A02C5; Tue, 27 May 2014 17:50:08 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 625B7C1FB; Tue, 27 May 2014 20:50:05 -0400 (EDT) Date: Tue, 27 May 2014 20:50:05 -0400 From: Jeffrey Haas To: Stephen Farrell Subject: Re: Stephen Farrell's Block on charter-ietf-bfd-07-02: (with BLOCK) Message-ID: <20140528005005.GD19384@pfrc> References: <20140528004621.19460.38085.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140528004621.19460.38085.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Wv2wTbLVFq0Qg3zHnbP_N1w0eas Cc: rtg-bfd@ietf.org, The IESG , bfd-chairs@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 28 May 2014 00:50:09 -0000 On Tue, May 27, 2014 at 05:46:21PM -0700, Stephen Farrell wrote: > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > > The text refers to KARP, which is closing. What's the plan then? > If its to do the work in BFD that's fine. The proposed charter update was submitted prior to the official announcement of KARP closing. With regard to the BFD charter, delete the reference. :-) With regard to the remaining KARP item for BFD, I've volunteered to do the shepherd writeup soon and let the publication process happen as a final work item of KARP. BFD had already adopted work to implement the KARP drafts' work. -- Jeff From nobody Tue May 27 17:56:07 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5A01A02CB; Tue, 27 May 2014 17:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPvApTDXZzKr; Tue, 27 May 2014 17:56:00 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 479BD1A02C5; Tue, 27 May 2014 17:56:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 44FFFBE2F; Wed, 28 May 2014 01:55:56 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vKfkBTPocQH; Wed, 28 May 2014 01:55:55 +0100 (IST) Received: from [192.168.51.186] (scandic812.host.songnetworks.se [212.214.188.42]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E090FBE1C; Wed, 28 May 2014 01:55:44 +0100 (IST) Message-ID: <53853410.9080802@cs.tcd.ie> Date: Wed, 28 May 2014 01:55:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jeffrey Haas Subject: Re: Stephen Farrell's Block on charter-ietf-bfd-07-02: (with BLOCK) References: <20140528004621.19460.38085.idtracker@ietfa.amsl.com> <20140528005005.GD19384@pfrc> In-Reply-To: <20140528005005.GD19384@pfrc> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/W2iVzXFehrhfo9jhKdwJ_iTj47w Cc: rtg-bfd@ietf.org, The IESG , bfd-chairs@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 28 May 2014 00:56:01 -0000 On 28/05/14 01:50, Jeffrey Haas wrote: > On Tue, May 27, 2014 at 05:46:21PM -0700, Stephen Farrell wrote: >> ---------------------------------------------------------------------- >> BLOCK: >> ---------------------------------------------------------------------- >> >> >> The text refers to KARP, which is closing. What's the plan then? >> If its to do the work in BFD that's fine. > > The proposed charter update was submitted prior to the official announcement > of KARP closing. With regard to the BFD charter, delete the reference. :-) > > With regard to the remaining KARP item for BFD, I've volunteered to do the > shepherd writeup soon and let the publication process happen as a final work > item of KARP. > > BFD had already adopted work to implement the KARP drafts' work. I guess the changes are pretty obvious so I've unblocked in the hope those'll be made before approval. S. > > -- Jeff > From nobody Tue May 27 17:56:09 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938311A083E; Tue, 27 May 2014 17:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZIujCEGgkNW; Tue, 27 May 2014 17:56:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1621A02C5; Tue, 27 May 2014 17:56:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG Subject: Stephen Farrell's No Objection on charter-ietf-bfd-07-02: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140528005604.1421.27048.idtracker@ietfa.amsl.com> Date: Tue, 27 May 2014 17:56:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Xno4g6zU1PkHT0iswzvf5Z78gws Cc: rtg-bfd@ietf.org, bfd-chairs@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 00:56:05 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-bfd-07-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-bfd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The text refers to KARP, which is closing. That needs fixing. From nobody Tue May 27 18:12:57 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814001A0862 for ; Tue, 27 May 2014 18:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDth5XKL9qwp for ; Tue, 27 May 2014 18:12:51 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F18361A0857 for ; Tue, 27 May 2014 18:12:50 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id l6so10427972oag.4 for ; Tue, 27 May 2014 18:12:47 -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=7pfH0RoTZB7U+WX2h8X23exc9FQQdCk7fYzBVc/NNQQ=; b=dwSXWz7Qkv0xCXHI+Tr1lFtAndBbdBH01BVIBduT7Ivx+HJ+7m6SZ3eAZNalS20Bir G8fDrq1fTxYcjuQSc757xdEsm+ovdxf7CsEHKAoP8I2MiayTC+aJeBNDst7AJ2JW794F vPeXaoy1WuAov8mSTYI3gvHNAwJ3dXsHFd8MH9ksfjMq12ePsP7EHLwcboYJ1nTySMu7 +pLBNrVb/nI+RInxIMvLzpN2RK+Prc7+OGvsZV6dgunVv2hzhwUeEFmPUc7s7rdojZhV DX9zO+dyz5yEeqdzF38Zsn90hLdAqVJQPlnfCPfp7BaKwmAi1hUOPFB0YtT8X50Sljki 8ynA== MIME-Version: 1.0 X-Received: by 10.60.143.37 with SMTP id sb5mr28256625oeb.38.1401239567270; Tue, 27 May 2014 18:12:47 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Tue, 27 May 2014 18:12:47 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 May 2014 06:42:47 +0530 Message-ID: Subject: Re: S-BFD Discriminator Types? From: Manav Bhatia To: "Nobo Akiya (nobo)" Content-Type: multipart/alternative; boundary=047d7b3a81a0a7565704fa6b8259 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/XQn5TB_CXB8Bn1tcV7zq_0eoPRQ Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 28 May 2014 01:12:54 -0000 --047d7b3a81a0a7565704fa6b8259 Content-Type: text/plain; charset=UTF-8 Hi Nobo, I remember having this discussion with you earlier (when the details had still not been fleshed out) where i was not convinced upon the need to define SFD Discriminator --> BFD Target Identifier --> BFD Target Identifier Type in the draft. I understand that there can be various S-BFD descriminator types. We could have one that identifies a network node. We could potentially have another that defines an application running within a VM context and so on. However, i dont see why we would ever need S-BFD descriminator -> descriminator type mapping for the interop purposes -- afterall whatever gets into an IETF draft is primarily to help interop between different vendors. Wouldnt this be an implementation specific issue? Cheers, Manav On Fri, May 23, 2014 at 7:02 AM, Nobo Akiya (nobo) wrote: > Hi [S-]BFDers, > > As part of next set of changes for the bfd-seamless-base document, I > wanted us to revamp sections 3 and 4 which have become stale. > > Current texts implies that we create following relationships in the BFD > Target Identifier Table. > > S-BFD Discriminator --> BFD Target Identifier --> BFD Target Identifier > Type > > This is no longer necessary. Mapping of local S-BFD discriminators to > local entities can be created, but that's an implementation matter. This > mapping does not have to be mandated in the document. > > Which puts us in: > > > Option #1: > > Define S-BFD Discriminator Types (renamed from BFD Target Identifier > Type), and define following relationships. > > S-BFD Discriminator --> S-BFD Discriminator Type. > > > Now, the other question that I have is, do we need to define S-BFD > Discriminator Types, and they be IANA maintained? I do realize that there > will be several "types" of S-BFD discriminators over time. However, when > S-BFD discriminators are advertised by applications, then those > applications will be advertising what each S-BFD discriminator is for > (mapping to specific entity). Therefore, the application implies the "type" > and the mapping implies the "context". > > If there is going to be any application that will be advertising multiple > S-BFD discriminator "types", then it _is_ beneficial for S-BFD base to > define those types. However, I am not finding any such use case at the > moment. That means, it is possible for us to clean up sections 3 and 4 even > further, and go with: > > > Option #2: > > Do not define any BFD Target Identifier Types nor S-BFD Discriminator > Types. > > > Any thoughts on this? > > -Nobo > > --047d7b3a81a0a7565704fa6b8259 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Nobo,

I remember having this discuss= ion with you earlier (when the details had still not been fleshed out) wher= e i was not convinced upon the need to define SFD=C2=A0Discriminator =C2= =A0--> BFD Target Identifier --> BFD Target Identifier Type in the dr= aft.

I understand t= hat there can be various S-BFD descriminator types. We could have one that = identifies a network node. We could potentially have another that defines a= n application running within a VM context and so on.

However, i dont see why we would ever need S-BFD descrimi= nator -> descriminator type mapping for the interop purposes -- afterall= whatever gets into an IETF draft is primarily to help interop between diff= erent vendors. Wouldnt this be an implementation specific issue?

Cheers, Manav


On Fri, May 23, 2014 at 7:02 AM, Nobo = Akiya (nobo) <nobo@cisco.com> wrote:
Hi [S-]BFDers,

As part of next set of changes for the bfd-seamless-base document, I wanted= us to revamp sections 3 and 4 which have become stale.

Current texts implies that we create following relationships in the BFD Tar= get Identifier Table.

S-BFD Discriminator =C2=A0--> BFD Target Identifier --> BFD Target Id= entifier Type

This is no longer necessary. Mapping of local S-BFD discriminators to local= entities can be created, but that's an implementation matter. This map= ping does not have to be mandated in the document.

Which puts us in:


Option #1:

Define S-BFD Discriminator Types (renamed from BFD Target Identifier Type),= and define following relationships.

S-BFD Discriminator --> S-BFD Discriminator Type.


Now, the other question that I have is, do we need to define S-BFD Discrimi= nator Types, and they be IANA maintained? I do realize that there will be s= everal "types" of S-BFD discriminators over time. However, when S= -BFD discriminators are advertised by applications, then those applications= will be advertising what each S-BFD discriminator is for (mapping to speci= fic entity). Therefore, the application implies the "type" and th= e mapping implies the "context".

If there is going to be any application that will be advertising multiple S= -BFD discriminator "types", then it _is_ beneficial for S-BFD bas= e to define those types. However, I am not finding any such use case at the= moment. That means, it is possible for us to clean up sections 3 and 4 eve= n further, and go with:


Option #2:

Do not define any BFD Target Identifier Types nor S-BFD Discriminator Types= .


Any thoughts on this?

-Nobo


--047d7b3a81a0a7565704fa6b8259-- From nobody Tue May 27 18:15:19 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE041A0864; Tue, 27 May 2014 18:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUbCiySGVEzC; Tue, 27 May 2014 18:15:11 -0700 (PDT) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C9E71A0860; Tue, 27 May 2014 18:15:11 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id o6so10516001oag.31 for ; Tue, 27 May 2014 18:15:07 -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=pkeJZHawJXtit2CBlSeytYqz42gLI8zlsj2sSHSi58s=; b=CF5cFoKBqS12m4Q8/AQa3AkvGXZOlsNF8iG11RNdpbZvCBLQ9m3sUq5p9RgNAQDXf+ 7TvBaTjv2eskr9djcUmsx/NX0gzIczrWWwcPaaGDE3Rz7VgNQk1ALG+bwCgYxhU0hbwB 4ijNGuUTHguAGu3rRePvO2rPnPNGKtict39loeLJpthJwWVQhVL/bb5lRhNLBl/GYpw+ VLU7PWZ2aw4O7KpW8ZKLnwnaStKHNFB+G+Y0y4PvJfILU+uI5VLWjX8A4ke03yF7Sqh7 7/G6y7HlzeF/vPxLN5lqCyR7xorVMS3+9kFjE4OA7KEH6pcbSzwYJZZLANRqk/otxxq2 t/dA== MIME-Version: 1.0 X-Received: by 10.182.165.73 with SMTP id yw9mr37759866obb.39.1401239707630; Tue, 27 May 2014 18:15:07 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Tue, 27 May 2014 18:15:07 -0700 (PDT) In-Reply-To: <20140528005005.GD19384@pfrc> References: <20140528004621.19460.38085.idtracker@ietfa.amsl.com> <20140528005005.GD19384@pfrc> Date: Wed, 28 May 2014 06:45:07 +0530 Message-ID: Subject: Re: Stephen Farrell's Block on charter-ietf-bfd-07-02: (with BLOCK) From: Manav Bhatia To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a11c3164c050e5d04fa6b8b36 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ygBHdVZdQXfXQZB9ZnVO2VR7FTs Cc: "rtg-bfd@ietf.org" , Brian Weis , The IESG , bfd-chairs@tools.ietf.org, Stephen Farrell X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 28 May 2014 01:15:14 -0000 --001a11c3164c050e5d04fa6b8b36 Content-Type: text/plain; charset=UTF-8 BTW, Brian Weis (co-chair KARP) has promised Adrian and me a shepherd review and a writeup before the end of the week, after which we can get going. Cheers, Manav On Wed, May 28, 2014 at 6:20 AM, Jeffrey Haas wrote: > On Tue, May 27, 2014 at 05:46:21PM -0700, Stephen Farrell wrote: > > ---------------------------------------------------------------------- > > BLOCK: > > ---------------------------------------------------------------------- > > > > > > The text refers to KARP, which is closing. What's the plan then? > > If its to do the work in BFD that's fine. > > The proposed charter update was submitted prior to the official > announcement > of KARP closing. With regard to the BFD charter, delete the reference. :-) > > With regard to the remaining KARP item for BFD, I've volunteered to do the > shepherd writeup soon and let the publication process happen as a final > work > item of KARP. > > BFD had already adopted work to implement the KARP drafts' work. > > -- Jeff > > --001a11c3164c050e5d04fa6b8b36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
BTW, Brian Weis (co-chair KARP) has promised Adrian and me= a shepherd review and a writeup before the end of the week, after which we= can get going.

Cheers, Manav


On Wed, May 28, 2014 at 6:20 AM, Jeffrey= Haas <jhaas@pfrc.org> wrote:
On Tue, May 27, 2014 at 05:46:21PM -0700, Stephen Farrell w= rote:
> ----------------------------------------------------------------------=
> BLOCK:
> ----------------------------------------------------------------------=
>
>
> The text refers to KARP, which is closing. What's the plan then? > If its to do the work in BFD that's fine.

The proposed charter update was submitted prior to the official annou= ncement
of KARP closing. =C2=A0With regard to the BFD charter, delete the reference= . :-)

With regard to the remaining KARP item for BFD, I've volunteered to do = the
shepherd writeup soon and let the publication process happen as a final wor= k
item of KARP.

BFD had already adopted work to implement the KARP drafts' work.

-- Jeff


--001a11c3164c050e5d04fa6b8b36-- From nobody Wed May 28 02:26:19 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBE71A0041 for ; Wed, 28 May 2014 02:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULqPjqcgY3Ag for ; Wed, 28 May 2014 02:26:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471F11A0033 for ; Wed, 28 May 2014 02:26:17 -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.7-GA FastPath queued) with ESMTP id BEP93553; Wed, 28 May 2014 09:26:10 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 10:25:32 +0100 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 10:26:00 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.46]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Wed, 28 May 2014 17:25:56 +0800 From: Mach Chen To: "Nobo Akiya (nobo)" , "rtg-bfd@ietf.org" Subject: RE: S-BFD Discriminator Types? Thread-Topic: S-BFD Discriminator Types? Thread-Index: Ac92Jo/4iM/K8nz3QxK1jtunOJIEPAELnukw Date: Wed, 28 May 2014 09:25:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/23_iSK9BqclDJrKiyNor6RbUtK0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 28 May 2014 09:26:18 -0000 Hi Nobo, Regarding the S-BFD identifier types, since the usage of S-BFD Discriminato= r/identifier is to identify a specific S-BFD session, and the purpose of th= e session is up to the application. IMHO, if there is no use case that requ= ires different types, we'd better go with option 2. Best regards, Mach =20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (= nobo) > Sent: Friday, May 23, 2014 9:33 AM > To: rtg-bfd@ietf.org > Subject: S-BFD Discriminator Types? >=20 > Hi [S-]BFDers, >=20 > As part of next set of changes for the bfd-seamless-base document, I want= ed us > to revamp sections 3 and 4 which have become stale. >=20 > Current texts implies that we create following relationships in the BFD T= arget > Identifier Table. >=20 > S-BFD Discriminator --> BFD Target Identifier --> BFD Target Identifier = Type >=20 > This is no longer necessary. Mapping of local S-BFD discriminators to loc= al entities > can be created, but that's an implementation matter. This mapping does no= t have > to be mandated in the document. >=20 > Which puts us in: >=20 >=20 > Option #1: >=20 > Define S-BFD Discriminator Types (renamed from BFD Target Identifier Type= ), and > define following relationships. >=20 > S-BFD Discriminator --> S-BFD Discriminator Type. >=20 >=20 > Now, the other question that I have is, do we need to define S-BFD Discri= minator > Types, and they be IANA maintained? I do realize that there will be sever= al > "types" of S-BFD discriminators over time. However, when S-BFD discrimina= tors > are advertised by applications, then those applications will be advertisi= ng what > each S-BFD discriminator is for (mapping to specific entity). Therefore, = the > application implies the "type" and the mapping implies the "context". >=20 > If there is going to be any application that will be advertising multiple= S-BFD > discriminator "types", then it _is_ beneficial for S-BFD base to define t= hose types. > However, I am not finding any such use case at the moment. That means, it= is > possible for us to clean up sections 3 and 4 even further, and go with: >=20 >=20 > Option #2: >=20 > Do not define any BFD Target Identifier Types nor S-BFD Discriminator Typ= es. >=20 >=20 > Any thoughts on this? >=20 > -Nobo From nobody Wed May 28 05:40:22 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A422F1A00C5; Wed, 28 May 2014 05:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0nDwrr54-Jc; Wed, 28 May 2014 05:13:50 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7431A0099; Wed, 28 May 2014 05:13:49 -0700 (PDT) X-AuditID: c1b4fb25-f79226d000004024-49-5385d2f851d5 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 73.1B.16420.8F2D5835; Wed, 28 May 2014 14:13:45 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.174.1; Wed, 28 May 2014 14:13:44 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 840191101FC; Wed, 28 May 2014 15:13:44 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 819D64E94A; Wed, 28 May 2014 15:13:41 +0300 (EEST) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0FBE24E857; Wed, 28 May 2014 15:13:41 +0300 (EEST) Content-Type: multipart/signed; boundary="Apple-Mail=_659CDC22-A3C1-44F6-9CDF-AF351E72A941"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: [Gen-art] Gen-ART review of draft-ietf-bfd-mib-20 From: Jari Arkko In-Reply-To: Date: Wed, 28 May 2014 15:13:46 +0300 Message-ID: <814822C2-516E-4BB6-955C-A33E1690B211@ericsson.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C662E05@MX15A.corp.emc.com> <20140522233426.GA561@pfrc> To: "Nobo Akiya (nobo)" , "Black, David" X-Mailer: Apple Mail (2.1878.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM+Jvje7PS63BBgf6uCy2Hl7LbnH11WcW i/0H37JazO6It/j8ZxujxcPJl9gtXu/4yu7A7jHl90ZWjyNHZrN4LFnyk8lj65Ml7B6Xe7ey BrBGcdmkpOZklqUW6dslcGVc3LSbteCoYcWPHf8YGxhv6ncxcnJICJhIPN90kwXCFpO4cG89 WxcjF4eQwFFGiWfvu9lAEkICGxgl5h7ggbD3MkocXRIDUbSOUeL976vsEM48RokbpxeBtTML TGGU+HrqM9hcXgEDiXWLjzGC2MICdhKrtz1mBrHZBLQkNi5fALaCU8BX4sGJ1UxdjBwcLAKq EnP3uUHMecUo0bRrAhPEHHuJvnvLmCDOWMEocWapL4gtIuAn8Xj6Sagf5CVmtJ9gh7DVJK6e 28QMUa8icevvWbYJjCKzkN03C8l9IDazgLbEsoWvmSFsA4mnna9YIWxTiddHP0LVWEvM+HWQ DcJWlJjS/ZB9ASP7KkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzAaD245bfqDsbLbxwPMQpw MCrx8C641BIsxJpYVlyZe4hRmoNFSZz3okZ1sJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG mZeph8v/3zywyJNn37WWA2tSHSyDxPu1J5UYrOtbf+aInAejUfKPOxOkdFda5uTVLZxavXU7 l/sfr4W37iXsO/S+y6g2LHePdpR10LZLHirKXeKx75W8try+n74gftEj31zLQ2+Kp3vfP5Tp bXd++t7dt+wYtjPGzPfYqLpw68O/i34fm3X1ohJLcUaioRZzUXEiAN9RDL+3AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ukIVn3_ozO7O-E77iu4qG2b6c2I X-Mailman-Approved-At: Wed, 28 May 2014 05:40:17 -0700 Cc: "General Area Review Team \(gen-art@ietf.org\)" , "Zafar Ali \(zali\)" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 28 May 2014 12:13:53 -0000 --Apple-Mail=_659CDC22-A3C1-44F6-9CDF-AF351E72A941 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 23 May 2014, at 03:11, Nobo Akiya (nobo) wrote: > Thanks for the time spent reviewing this draft again David! +1 I have posted a no-objection position for this document, for tomorrow=92s = IESG call. Jari --Apple-Mail=_659CDC22-A3C1-44F6-9CDF-AF351E72A941 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINaDCCBEUw ggMtoAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVs aWFTb25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4X DTA2MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv 1rLnfub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqT u3TT39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMc CYXRlobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUb Az2oFRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB /wQIMAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRh cC50cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2 MSxvPVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNV HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb 8I+4GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXI v6tPjhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzY FSzz6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67 OzIKXrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3k MXuiNuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OY CMZ9lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAw OjEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDgg VjMwHhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVy YSBHcm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5D uVdWPMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe 1X7/jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF4 6H1ibp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjgh XYpw/+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGj ggFiMIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7ga YqGoIxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0F BgEwMDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7Bgcq hXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20w cAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vv bi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkww DgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUE kUm25PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDC fkDJSgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6b KuTPBH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHn tP+npjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPd OI5GtDYPMIIEqjCCA5KgAwIBAgIQTyXs3vXto5joAjtwrbnc3jANBgkqhkiG9w0BAQUFADA5MREw DwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxMB4X DTEzMDMwNDEzMjUyMVoXDTE2MDMwNDEzMjUxOVowYjERMA8GA1UECgwIRXJpY3Nzb24xEzARBgNV BAMMCkphcmkgQXJra28xEDAOBgNVBAUTB2xtZmphYXIxJjAkBgkqhkiG9w0BCQEWF2phcmkuYXJr a29AZXJpY3Nzb24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhwriyJIY5Bbz yZrfnFAjWFLMNc6O6Z6dw5HqexTVyrUymDobuwcFtGl3n+yc6tYcvzM85LJMotJlOJH4NHEqClEc iMw+gFvN17PXxM2aAPuv1ZUL1wSdQ9dS94zxQEQuh4Myyfy+eqvrEBkzZaDPu4Evz6xsmCYPYSZP t4Bo6zbwQqkRvSQUO659ytmlyiPOiWN6wxEpwwO43LEw12xFrVSOQw3AG8ULW/xHbQvInuyWQdBC ug/1n6IJETsMWSrLFnk888IjABXKkmq42EG6RQ0BWLw8lAQwTju7rsDF9HrcTYBcu9z2u/d4cSgH P9SkRncRm68xrt7bD2RhPf3rkQIDAQABo4IBgzCCAX8wgcAGA1UdHwSBuDCBtTCBsqCBr6CBrIY3 aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vRXJpY3Nzb25OTEluZGl2aWR1YWxDQTAxLmNybIZx bGRhcDovL2xkYXAudHJ1c3QudGVsaWEuY29tL2NuPUVyaWNzc29uJTIwTkwlMjBJbmRpdmlkdWFs JTIwQ0EwMSxvPUVyaWNzc29uP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2Uw IgYDVR0RBBswGYEXamFyaS5hcmtrb0Blcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEw MTAvBggrBgEFBQcCARYjaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0O BBYEFLk/k+8oySkNxYm0GyPaFaKSRQufMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCb MA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAECF65IiGH7GS+EEHre+itv2wv0OQ Z68DWR6G9IqMkBgb8dj6JcfFsu+9p8ID1e1L/0ybeTwz1t4IPhuOuWBPohj5irYiCBJkIokUr09B rWPyxfBrSoZ+uXVWfmZSdp15pWlEnHhuGuJkZ2a0MKrj+OEM9qfQR5Cvdlmx5PvsIhFkAFcZWldI xBwHsEeSoGJbVvvNImiY6M27u6rhuR8HanXVdcW4B8gK489LutxKhyhT9QDFUhmyWk2qYCUJgwM/ w44sLz8tv95jDbJxAR/aOwdwF3fQgj8VB5Xwvdn6B0PhfEcd3Ju4yUz6HE6ELZWG4ruE2haUCOn4 8WStKZ/RPDGCApMwggKPAgEBME0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNz c29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQTyXs3vXto5joAjtwrbnc3jAJBgUrDgMCGgUAoIIBGzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA1MjgxMjEzNDZaMCMG CSqGSIb3DQEJBDEWBBQD1K5ahqOnjY+v0m/pPJzbVNMsfTBcBgkrBgEEAYI3EAQxTzBNMDkxETAP BgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEE8l 7N717aOY6AI7cK253N4wXgYLKoZIhvcNAQkQAgsxT6BNMDkxETAPBgNVBAoMCEVyaWNzc29uMSQw IgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEE8l7N717aOY6AI7cK253N4wDQYJ KoZIhvcNAQEBBQAEggEAT9Chko3BQgaSyRnwwbVsJMlwUqmKqX4J6s3rkUbzgrm3bVFpSXjj33by Xt5vALOTeZBBvCSb6oMynpFST0qBeSVvASNFqV5jl7k5GmpbKs1cjfHdw3rRxAog9D3xl0bByzwO IertwyfL9Fx3ACKuR45O1A4MR+DKKIgCxnO0oDkgbXAosDoIX7aWIImP8dTsqOFxnQpY5se2yIEI lZ79Ixt8xdompYbHeX86mJ8a9KAJGfcdh/mtkz93GS1sIOS0zddo8oYYzmwJ41jp7JhWoowsKSgQ CSKvasef/O3BYp9OZxnDY6WP/Q25CxhvsfhdjUyVuPmCx9qx88ltDyAq7AAAAAAAAA== --Apple-Mail=_659CDC22-A3C1-44F6-9CDF-AF351E72A941-- From nobody Wed May 28 07:44:40 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33DF1A09AC for ; Wed, 28 May 2014 07:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jA89nZaeG7UI for ; Wed, 28 May 2014 07:44:28 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DDBA1A09B0 for ; Wed, 28 May 2014 07:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2942; q=dns/txt; s=iport; t=1401288265; x=1402497865; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7zstvxNGyK5To28dsl6A9fOq0eSlCmIb/4AikDHcz5k=; b=Bg32xlfPW/GacPyUqVL1hFp/8d8a6ZCYAx/q+abZv9MUVVp9P3aEmQXr HFZ4lrwBnWoolONvCwpSwBDZtzEe/PwZp5wWc9IrvHN1OEqjbm47gtNvj XnOVD4vO7eXFZnkB0TYjSGwYp5CLG//RWQK/xIJATMliD0XIeHV+ugl8H w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAJH1hVOtJA2M/2dsb2JhbABPCoJlIoEqwicBgQkWdIIlAQEBBCcTOBMEAgEIEQQBAQsUCQcyFAkIAQEEARIIiDoB1woXiTOEQys4BoMlgRUBA60cgziCLw X-IronPort-AV: E=Sophos;i="4.98,928,1392163200"; d="scan'208";a="47938005" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP; 28 May 2014 14:44:24 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s4SEiOIx009932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 May 2014 14:44:24 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Wed, 28 May 2014 09:44:23 -0500 From: "Nobo Akiya (nobo)" To: Mach Chen , "rtg-bfd@ietf.org" , "Manav Bhatia (manavbhatia@gmail.com)" Subject: RE: S-BFD Discriminator Types? Thread-Topic: S-BFD Discriminator Types? Thread-Index: Ac92Jo/4iM/K8nz3QxK1jtunOJIEPAELnukwAAtpCUA= Date: Wed, 28 May 2014 14:44:23 +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.212.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/5OUkPy5F8Q6bGN9naTBSx2I_PjI X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 28 May 2014 14:44:31 -0000 Hi Manav, Mach, Thanks for providing your thoughts, and I agree. I think we should proceed = with option #2 (i.e. not define IANA maintained S-BFD discriminator types).= If anybody don't think this is the way to go, feel free to chime in and le= t us discuss further. Thanks, Nobo > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com] > Sent: Wednesday, May 28, 2014 5:26 AM > To: Nobo Akiya (nobo); rtg-bfd@ietf.org > Subject: RE: S-BFD Discriminator Types? >=20 > Hi Nobo, >=20 > Regarding the S-BFD identifier types, since the usage of S-BFD > Discriminator/identifier is to identify a specific S-BFD session, and the > purpose of the session is up to the application. IMHO, if there is no use= case > that requires different types, we'd better go with option 2. >=20 > Best regards, > Mach >=20 > > -----Original Message----- > > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > > Akiya (nobo) > > Sent: Friday, May 23, 2014 9:33 AM > > To: rtg-bfd@ietf.org > > Subject: S-BFD Discriminator Types? > > > > Hi [S-]BFDers, > > > > As part of next set of changes for the bfd-seamless-base document, I > > wanted us to revamp sections 3 and 4 which have become stale. > > > > Current texts implies that we create following relationships in the > > BFD Target Identifier Table. > > > > S-BFD Discriminator --> BFD Target Identifier --> BFD Target > > Identifier Type > > > > This is no longer necessary. Mapping of local S-BFD discriminators to > > local entities can be created, but that's an implementation matter. > > This mapping does not have to be mandated in the document. > > > > Which puts us in: > > > > > > Option #1: > > > > Define S-BFD Discriminator Types (renamed from BFD Target Identifier > > Type), and define following relationships. > > > > S-BFD Discriminator --> S-BFD Discriminator Type. > > > > > > Now, the other question that I have is, do we need to define S-BFD > > Discriminator Types, and they be IANA maintained? I do realize that > > there will be several "types" of S-BFD discriminators over time. > > However, when S-BFD discriminators are advertised by applications, > > then those applications will be advertising what each S-BFD > > discriminator is for (mapping to specific entity). Therefore, the appli= cation > implies the "type" and the mapping implies the "context". > > > > If there is going to be any application that will be advertising > > multiple S-BFD discriminator "types", then it _is_ beneficial for S-BFD= base > to define those types. > > However, I am not finding any such use case at the moment. That means, > > it is possible for us to clean up sections 3 and 4 even further, and go= with: > > > > > > Option #2: > > > > Do not define any BFD Target Identifier Types nor S-BFD Discriminator > Types. > > > > > > Any thoughts on this? > > > > -Nobo From nobody Wed May 28 14:28:06 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8262C1A069D; Wed, 28 May 2014 14:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nOlRejWkiYe; Wed, 28 May 2014 14:28:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 906F41A065F; Wed, 28 May 2014 14:28:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: The IESG Subject: Benoit Claise's No Objection on charter-ietf-bfd-07-03: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140528212803.1957.41451.idtracker@ietfa.amsl.com> Date: Wed, 28 May 2014 14:28:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/OtJogdgPTsExjrF1lx5oZBmAjcs Cc: rtg-bfd@ietf.org, bfd-chairs@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 21:28:04 -0000 Benoit Claise has entered the following ballot position for charter-ietf-bfd-07-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-bfd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hopefully, you can now remove: 1. Develop the MIB modules for BFD and submit them to the IESG for publication as Proposed Standards. And the famous milestones are absent. From nobody Wed May 28 16:15:17 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4ED31A0765; Wed, 28 May 2014 16:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vZUx6jLmOZs; Wed, 28 May 2014 16:15:11 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5BD1A0354; Wed, 28 May 2014 16:15:11 -0700 (PDT) Received: from [10.179.187.159] (mobile-198-228-210-060.mycingular.net [198.228.210.60]) by slice.pfrc.org (Postfix) with ESMTPSA id 72004C258; Wed, 28 May 2014 19:15:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Benoit Claise's No Objection on charter-ietf-bfd-07-03: (with COMMENT) From: Jeff Haas X-Mailer: iPhone Mail (11D201) In-Reply-To: <20140528212803.1957.41451.idtracker@ietfa.amsl.com> Date: Wed, 28 May 2014 16:15:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140528212803.1957.41451.idtracker@ietfa.amsl.com> To: Benoit Claise Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/FoLEoRJq58aZjxlT0MPNlvcO5rY Cc: "rtg-bfd@ietf.org" , The IESG , "bfd-chairs@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 28 May 2014 23:15:12 -0000 Benoit, The MPLS MIB is still a remaining work item.=20 At this point we have no further management items but I suspect that S-BFD m= ay eventually produce such work. Whether that is a MIB or a yang module is t= o be determined.=20 Jeff > On May 28, 2014, at 14:28, "Benoit Claise" wrote: >=20 > Benoit Claise has entered the following ballot position for > charter-ietf-bfd-07-03: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/charter-ietf-bfd/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Hopefully, you can now remove: > 1. Develop the MIB modules for BFD and submit them to the IESG for=20 > publication as Proposed Standards. >=20 > And the famous milestones are absent. >=20 From nobody Wed May 28 16:26:53 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DC91A0781; Wed, 28 May 2014 16:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoEoIbXzWJKr; Wed, 28 May 2014 16:26:48 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350371A06D5; Wed, 28 May 2014 16:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1404; q=dns/txt; s=iport; t=1401319605; x=1402529205; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=M/uM4Zi7Ji2zIeL9z6LlNwbpxUedtDJwpdjMyu2P+Ew=; b=JJ/IXGl5p0QTHbzl6fWuV9Y/I9mYsUW+zRIf/5C7GLJ+ndj+gvAxZtkG 1dG+5AHgpuVjb4ZNcYEv8ic9QkTK2fEKA+YmeasUGq5wi/paR1E5j4KDs 1dISAMhWLTHibtTN2Bftl0ngiMUkSSCU2Z6OGbkX+DPLU90MC0tRfDah6 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAB1whlOtJssW/2dsb2JhbABag1nDEAGBJXSCJQEBAQQ4QAEQCw4KCRYPCQMCAQIBRQYNAQUCAQGIPg3YDxeNcBEBUAeEQAEDmXWBPYUujDyDOjuBOQ X-IronPort-AV: E=Sophos;i="4.98,931,1392163200"; d="scan'208";a="66597641" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 28 May 2014 23:26:43 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4SNQgvu022862; Wed, 28 May 2014 23:26:42 GMT Message-ID: <538670B2.5020106@cisco.com> Date: Thu, 29 May 2014 01:26:42 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jeff Haas Subject: Re: Benoit Claise's No Objection on charter-ietf-bfd-07-03: (with COMMENT) References: <20140528212803.1957.41451.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/fZgXq8Qc4OjjLU1VwzaxT2YO-7w Cc: "rtg-bfd@ietf.org" , The IESG , "bfd-chairs@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 28 May 2014 23:26:50 -0000 Hi Jeff, I'm confused. I thought that this entry was related to the two BFD mib modules on tomorrow IESG telechat? So very close to go the RFC editor queue AFAICT Or maybe, you're thinking of something else with this "MPLS MIB"? Regards, B. > Benoit, > > The MPLS MIB is still a remaining work item. > > At this point we have no further management items but I suspect that S-BFD may eventually produce such work. Whether that is a MIB or a yang module is to be determined. > > Jeff > >> On May 28, 2014, at 14:28, "Benoit Claise" wrote: >> >> Benoit Claise has entered the following ballot position for >> charter-ietf-bfd-07-03: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/charter-ietf-bfd/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Hopefully, you can now remove: >> 1. Develop the MIB modules for BFD and submit them to the IESG for >> publication as Proposed Standards. >> >> And the famous milestones are absent. >> > . > From nobody Wed May 28 16:32:18 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29D11A06A7; Wed, 28 May 2014 16:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S__D_3I5K6CG; Wed, 28 May 2014 16:32:13 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 40FDE1A0290; Wed, 28 May 2014 16:32:13 -0700 (PDT) Received: from [10.179.187.159] (mobile-198-228-210-060.mycingular.net [198.228.210.60]) by slice.pfrc.org (Postfix) with ESMTPSA id 8F5A1C2CB; Wed, 28 May 2014 19:32:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Benoit Claise's No Objection on charter-ietf-bfd-07-03: (with COMMENT) From: Jeff Haas X-Mailer: iPhone Mail (11D201) In-Reply-To: <538670B2.5020106@cisco.com> Date: Wed, 28 May 2014 16:32:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <573E524F-68E1-489B-B7C0-28A0072A9392@pfrc.org> References: <20140528212803.1957.41451.idtracker@ietfa.amsl.com> <538670B2.5020106@cisco.com> To: Benoit Claise Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/9-nRA41lifBWmQbl1SUgurP5mg8 Cc: "rtg-bfd@ietf.org" , The IESG , "bfd-chairs@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 28 May 2014 23:32:14 -0000 Benoit, Draft-ietf-bfd-mpls-mib not the base MIB or the TC MIB.=20 Jeff > On May 28, 2014, at 16:26, Benoit Claise wrote: >=20 > Hi Jeff, >=20 > I'm confused. > I thought that this entry was related to the two BFD mib modules on tomorr= ow IESG telechat? So very close to go the RFC editor queue AFAICT > Or maybe, you're thinking of something else with this "MPLS MIB"? >=20 > Regards, B. >> Benoit, >>=20 >> The MPLS MIB is still a remaining work item. >>=20 >> At this point we have no further management items but I suspect that S-BFD= may eventually produce such work. Whether that is a MIB or a yang module is= to be determined. >>=20 >> Jeff >>=20 >>> On May 28, 2014, at 14:28, "Benoit Claise" wrote: >>>=20 >>> Benoit Claise has entered the following ballot position for >>> charter-ietf-bfd-07-03: No Objection >>>=20 >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>>=20 >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/charter-ietf-bfd/ >>>=20 >>>=20 >>>=20 >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>>=20 >>> Hopefully, you can now remove: >>> 1. Develop the MIB modules for BFD and submit them to the IESG for >>> publication as Proposed Standards. >>>=20 >>> And the famous milestones are absent. >> . >>=20 From nobody Wed May 28 16:42:04 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0741A06AC; Wed, 28 May 2014 16:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNvS4F_PSoQc; Wed, 28 May 2014 16:41:57 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181C71A02B9; Wed, 28 May 2014 16:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1713; q=dns/txt; s=iport; t=1401320513; x=1402530113; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=v75DUiOzpETCw356d5vecaR/DSfzLK6qp1WXvjnevV0=; b=iP4IlCiHAtC6ke5H5h1SX2rZzyIqjdQ0j4Zj5Yd+zSmDfxwKJed05vf3 nUKN2nNE/tRqUHAtce25FeBzFrBOdb6rdmp9K+bsFcww6AVbLfDgsX9qP uqt0Ln0rIJt3P+ycTcuCxvqN6FGI/vXjqYuSwx5PGm+K7qz29HSGUK5rZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEABB0hlOtJssW/2dsb2JhbABag1nDEAGBJXSCJQEBAQQ4QRALDgoJJQ8CRgYNAQUCAQGIPg3YAxeNcBEBUAeEQAEDmXWBPYUujDyDOjuBOQ X-IronPort-AV: E=Sophos;i="4.98,931,1392163200"; d="scan'208";a="65953532" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 28 May 2014 23:41:51 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4SNfpUX021108; Wed, 28 May 2014 23:41:51 GMT Message-ID: <5386743F.60401@cisco.com> Date: Thu, 29 May 2014 01:41:51 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jeff Haas Subject: Re: Benoit Claise's No Objection on charter-ietf-bfd-07-03: (with COMMENT) References: <20140528212803.1957.41451.idtracker@ietfa.amsl.com> <538670B2.5020106@cisco.com> <573E524F-68E1-489B-B7C0-28A0072A9392@pfrc.org> In-Reply-To: <573E524F-68E1-489B-B7C0-28A0072A9392@pfrc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/7Ihs53M0cGcX3t_e7MmwELHU40o Cc: "rtg-bfd@ietf.org" , The IESG , "bfd-chairs@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 28 May 2014 23:41:59 -0000 Thanks for the clarification Jeff. Regards, Benoit > Benoit, > > Draft-ietf-bfd-mpls-mib not the base MIB or the TC MIB. > > Jeff > >> On May 28, 2014, at 16:26, Benoit Claise wrote: >> >> Hi Jeff, >> >> I'm confused. >> I thought that this entry was related to the two BFD mib modules on tomorrow IESG telechat? So very close to go the RFC editor queue AFAICT >> Or maybe, you're thinking of something else with this "MPLS MIB"? >> >> Regards, B. >>> Benoit, >>> >>> The MPLS MIB is still a remaining work item. >>> >>> At this point we have no further management items but I suspect that S-BFD may eventually produce such work. Whether that is a MIB or a yang module is to be determined. >>> >>> Jeff >>> >>>> On May 28, 2014, at 14:28, "Benoit Claise" wrote: >>>> >>>> Benoit Claise has entered the following ballot position for >>>> charter-ietf-bfd-07-03: No Objection >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> http://datatracker.ietf.org/doc/charter-ietf-bfd/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> Hopefully, you can now remove: >>>> 1. Develop the MIB modules for BFD and submit them to the IESG for >>>> publication as Proposed Standards. >>>> >>>> And the famous milestones are absent. >>> . >>> > . > From nobody Thu May 29 20:26:24 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713251A031B for ; Thu, 29 May 2014 20:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-4UVT-hSf8p for ; Thu, 29 May 2014 20:26:21 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0A51A02E8 for ; Thu, 29 May 2014 20:26:21 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id wm4so1252224obc.4 for ; Thu, 29 May 2014 20:26:17 -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=aFubKWPI1p6IxAEu665csdfkpDExK86WauLbVxtNdXc=; b=01S98rlf9Pw5cTuMmQwgLOXJD6omegWYABmuxVqDCRRGyyjzPgdLHSq9s8R7Y9+cwb tkZZuaZVAT3B3YnW4j/hD2G5kqWwWRtsVixEeuF6GhkBHSPM++ZxGggItO4QL1YoMcpQ q6EzAg+40H0NV9sXkQgWS9NyV13+5DGsLfmQY6uAdyJdq3NH1z311d1Xjq0PFOx35rkY yNPKO/skGVW5wPmV/7KJCHAjoFIipaOPBqa0GMk7hyUgxnDPV1AvMwN66/UklqwV4zXz QIuoh0dl8PZ9aFIHvYN8r/Uuvgrivwsp0xbyCNC9FKIGTUlkf9oLe0uPlr5tjMh1kmUX 7sAw== MIME-Version: 1.0 X-Received: by 10.60.143.37 with SMTP id sb5mr13531248oeb.38.1401420377342; Thu, 29 May 2014 20:26:17 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Thu, 29 May 2014 20:26:17 -0700 (PDT) Date: Fri, 30 May 2014 08:56:17 +0530 Message-ID: Subject: S-BFD and routable addresses From: Manav Bhatia To: "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a81a0c5c7ec04fa959b5c Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/dlMSRsKp-naYotr4bq4-hCvEaWI X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 30 May 2014 03:26:23 -0000 --047d7b3a81a0c5c7ec04fa959b5c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For some reason the original email didnt make it to BFD mailing list .. -----Original Message----- From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Bhatia, Manav (Manav= ) Sent: Friday, May 30, 2014 8:50 AM To: Acee Lindem; Xuxiaohu Cc: isis-wg@ietf.org; fanpeng@chinamobile.com; Wes George; Joel jaeggli; OSPF List; sunset4@ietf.org; rtg-bfd@ietf.org; lizhenqiang@chinamobile.com Subject: Re: [OSPF] =E7=AD=94=E5=A4=8D: [Isis-wg] =E7=AD=94=E5=A4=8D: =E7= =AD=94=E5=A4=8D: [sunset4] IPv6 router IDs Sorry for joining the party so late .. Those of you following the BFD WG would know that BFD WG is currently being re-chartered to include S-BFD as one of the items that it will be working on. For S-BFD to work, we need to distribute the S-BFD discriminators across the IGP routing domain. How this can be achieved with OSPF has been described in http://tools.ietf.org/id/draft-bhatia-ospf-sbfd-discriminator-00.txt With the help of this draft S-BFD clients will know what S-BFD discriminator to use when talking to the reflector or the S-BFD server. However, it still needs a routable IP address that it can use to set up the S-BFD session. I believe the draft http://tools.ietf.org/html/draft-xu-ospf-ipv6-router-id-00 will help us in getting that information in the IPv6 context. Unfortunately, the above draft uses an inappropriate TLV name and doesn=E2= =80=99t seem to have a use-case that supports the need for such a TLV. I believe we have at least one use case where we need a "routable" IPv6 address. Cheers, Manav > -----Original Message----- > From: OSPF [mailto:ospf-bounces@ietf.org ] On Behalf Of Acee Lindem > Sent: Monday, May 12, 2014 7:10 PM > To: Xuxiaohu > Cc: isis-wg@ietf.org; Wes George; fanpeng@chinamobile.com; Joel > jaeggli; OSPF List; sunset4@ietf.org; lizhenqiang@chinamobile.com > Subject: Re: [OSPF] =E7=AD=94=E5=A4=8D: [Isis-wg] =E7=AD=94=E5=A4=8D: =E7= =AD=94=E5=A4=8D: [sunset4] IPv6 router > IDs > > Hi Xiaohu, > Please include the precise use cases as to WHY this is needed OSPF > draft. > And by precise, I don't mean just listing MPLS applications, I mean > explaining why you need this routable address above and beyond what is > already advertised. At least in the case of OSPF, I'm not convinced. > Thanks, > Acee > > > -----Original Message----- > From: Xuxiaohu > Date: Sunday, May 11, 2014 6:44 PM > To: Ericsson > Cc: Karsten Thomann , Anton Smirnov > , "isis-wg@ietf.org" , > "fanpeng@chinamobile.com" , Wes George > , Joel jaeggli , OSPF - > OSPF > WG List , "sunset4@ietf.org" , > "lizhenqiang@chinamobile.com" > Subject: =E7=AD=94=E5=A4=8D: [Isis-wg] [OSPF] =E7=AD=94=E5=A4=8D: =E7=AD= =94=E5=A4=8D: [sunset4] IPv6 router > IDs > > >Hi Acee, > > > >IMHO, segment routing could work together with the RFC3464 VPN. In > such > >case, the segment routing just replace the role of LDP or RSVP-TE of > >establishing a transport LSP between PE routers. > > > >Best regards, > >Xiaohu _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --047d7b3a81a0c5c7ec04fa959b5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=C2=A0For some reason the original email did= nt make it to BFD mailing list ..=C2=A0

-----Original Message-----
From: OSPF [mailto:ospf-bounces@ie= tf.org] On Behalf Of Bhatia, Manav (Manav)
Sent: Friday, May 30, 2014 8:50 AM
To: Acee Lindem; Xuxiaohu
Cc: isis-wg@ietf.org; fanpeng@chinamobile.com; Wes George; Joel= jaeggli; OSPF List; sunset4@ietf.org; rtg-bfd@ietf.org; lizhenqiang@chinamobile.com
Subject: Re: [OSPF] =E7=AD= =94=E5=A4=8D: [Isis-wg] =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: [sunset4] IPv6 router IDs

=C2=A0

Sorry for joining the party so late ..

=C2=A0

Those of you following the BFD WG would know that BFD WG is currently being re-chartered to include S-BFD as one of the items that i= t will be working on.

=C2=A0

For S-BFD to work, we need to distribute the S-BFD discriminators across the IGP routing domain. How this can be achieved with OSPF has been described in http://tools.ietf.org/id/draft-bhatia-ospf-sbfd-discriminator-0= 0.txt

=C2=A0

With the help of this draft S-BFD clients will know what S-BFD discriminator to use when talking to the reflector or the S-BFD serve= r.

=C2=A0

However, it still needs a routable IP address that it can use to set up the S-BFD session.

=C2=A0

I believe the draft http://tools.ietf.org/html/draft-xu-ospf-ipv6-router-id-00<= /a> will help us in getting that information in the IPv6 context.

=C2=A0

Unfortunately, the above draft uses an inappropriate TLV name and doesn=E2=80=99t seem to have a use-case that supports the need for= such a TLV. I believe we have at least one use case where we need a "routable"= ; IPv6 address.

=C2=A0

Cheers, Manav

=C2=A0

> -----Original Message-----

> From: OSPF [mailto:ospf-bounces@ietf= .org] On Behalf Of Acee Lindem

> Sent: Monday, May 12, 2014 7:10 PM

> To: Xuxiaohu

> Cc: isis-wg@ietf.org; Wes George; fanpeng@chinamobile.com; Joel

> jaeggli; OSPF List; = sunset4@ietf.org; lizhenqiang@chinamobile.com

> Subject: Re: [OSPF] =E7=AD=94=E5=A4=8D: [Isis-wg] =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: [sunset4] IPv6 router

> IDs

>

> Hi Xiaohu,

> Please include the precise use cases as to WHY this is needed OSPF

> draft.

> And by precise, I don't mean just listing MPLS applications, I mean

> explaining why you need this routable address above and beyond what is

> already advertised. At least in the case of OSPF, I'm not convinced.

> Thanks,

> Acee

>

>

> -----Original Message-----

> From: Xuxiaohu <xuxiaohu@huawei.com= >

> Date: Sunday, May 11, 2014 6:44 PM

> To: Ericsson <acee.lindem@eric= sson.com>

> Cc: Karsten Thomann <karsten_= thomann@linfre.de>, Anton Smirnov

> <asmirnov@cisco.com>, "isis-wg@ietf.org" <isis-wg@ietf.org>,

> "fanpeng@chinamobile.com" <fanpeng@chinamobile.com>, Wes George

> <wesley.george@twcable.com>, Joel jaeggli <joelja@bogus.com>, OSPF -

> OSPF

> WG List <ospf@ietf.org>, "sunset4@ietf.org" <sunset4@ietf.org>,

> "lizhenqiang@chinamobile.= com" <lizhenqiang@chinamobile.com>

> Subject: =E7=AD=94=E5=A4=8D: [Isis-wg] [OSPF] =E7=AD=94=E5=A4=8D:=C2=A0 =E7=AD=94=E5=A4=8D:=C2=A0 [sunset4]=C2=A0=C2=A0 IPv6 router

> IDs

>

> >Hi Acee,

> >

> >IMHO, segment routing could work together with the RFC3464 VPN. In

> such

> >case, the segment routing just replace the role of LDP or RSVP-TE of

> >establishing a transport LSP between PE routers.

> >

> >Best regards,

> >Xiaohu

_______________________________________________

OSPF mailing list

OSPF@ietf.org

https://www.ietf.org/mailma= n/listinfo/ospf

--047d7b3a81a0c5c7ec04fa959b5c-- From nobody Fri May 30 05:51:35 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC101A00F9 for ; Fri, 30 May 2014 05:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gy-cO_PgojBo for ; Fri, 30 May 2014 05:51:31 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14B21A0084 for ; Fri, 30 May 2014 05:51:30 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s4UCpOG6007282 for ; Fri, 30 May 2014 13:51:25 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s4UCpJwe007250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 30 May 2014 13:51:24 +0100 From: "Adrian Farrel" To: References: <20140529171320.29323.7853.idtracker@ietfa.amsl.com> In-Reply-To: <20140529171320.29323.7853.idtracker@ietfa.amsl.com> Subject: FW: Internal WG Review: Recharter of Bidirectional Forwarding Detection (bfd) Date: Fri, 30 May 2014 13:51:19 +0100 Message-ID: <01b301cf7c05$dd290f10$977b2d30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFwRIDYOQ03pWsxXfvckQbJJkw1EJwXgX/w Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20724.006 X-TM-AS-Result: No--36.411-10.0-31-10 X-imss-scan-details: No--36.411-10.0-31-10 X-TMASE-MatchedRID: ryAeJtVSyNjau9iF5mAFe1fS8E9vfq82mWGJLfJ2t7djEZl+QzZVx6+2 iUhw8uh4fGkV+Um5v7gTNcrm8YCxBNcUNjoF7YuVWteDSXCrUTQZskwWqoib3GecrqZc3vabfwk x2nDMrPgQeRUZnPFIE+O4G66rOoZwLY9Anvd3RdKq8RUDM9IsXBacPYI/JssKM/dZg2GSzOXx/t Bm0Re7BhkNGM4MD0i4IHnstSOpwtDfCKPGzKbWHWZUc2jtcaSd81qlqotKQQEsugxReYWqZtlLW un1it3QSpjXOKQbxaMuFmR/PrYeltbXCGdxrWNwaHvuNNRsDrLnibXdwxr2RwW3kEiN4kyfb4oH ry62Qe6V6rgo9Nbi/zxYGh2ymkegk7uKPdNpNUsER9Ta+6BEXWGNLTRnb5Yt8JGeRYYBDDqryHX yF9S+fXrUfQkqzKpuHTTodPOvZ9XDIITgRfyIwxfY306nA3boAZn/4A9db2QcQXgzaVXEcr/C8L 6a8Cw8K49Fzr5Q9b/T6Pbc0y3yhixckzzZTLYm3FqOVb7PDEIICu6i14k6HLrfxlRjqBJ3HoT34 BwgRLt7EOLtetPQIgO8TlQ8xKG7VumvLS6q4FBMcRwauwQkhDpA2zZYJjv1T67yhLheQozpZ/qY FE6lwYB8xCvNyhXcLsYvVCvFQ3mXBXaJoB9JZ4MbH85DUZXyseWplitmp0j6C0ePs7A07QKmARN 5PTKc Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/KTDqShPgwGhegDgzZXS-G0mliZE X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 30 May 2014 12:51:33 -0000 Hi, This is the formal review across the IETF of your revised charter. The IESG agreed the charter on Thursday, and barring objection by the = IETF at large, this will be approved at the end of this call for = comments. FWIW I have made one further tiny edit in deliverable #1 s/the MIB modules/further MIB modules/ Cheers, Adrian > -----Original Message----- > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary > Sent: 29 May 2014 18:13 > To: iesg@ietf.org; iab@iab.org; nobo@cisco.com; jhaas@pfrc.org > Subject: Internal WG Review: Recharter of Bidirectional Forwarding = Detection > (bfd) >=20 > A new charter for the Bidirectional Forwarding Detection (bfd) = working > group in the Routing Area of the IETF is being considered. The draft > charter is provided below for your review and comment. >=20 > Review time is one week. >=20 > The IETF Secretariat >=20 > Bidirectional Forwarding Detection (bfd) > -------------------------------------------------- > Current Status: Active Working Group >=20 > Chairs: Nobo Akiya > Jeffrey Haas >=20 > Area Director: Adrian Farrel >=20 > Tech Advisors: Dave Katz > David Ward >=20 > Mailing List > Address: rtg-bfd@ietf.org > To Subscribe: rtg-bfd-request@ietf.org > Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ >=20 > Charter charter-ietf-bfd-07-03: >=20 > The BFD Working Group is chartered to standardize and support the > bidirectional forwarding detection protocol (BFD) and its extensions. = A > core goal of the working group is to standardize BFD in the context of > IP routing, or protocols such as MPLS that are based on IP routing, in = a > way that will encourage multiple, inter-operable vendor = implementations. > The Working Group will also provide advice and guidance on BFD to = other > working groups or standards bodies as requested. >=20 > BFD is a protocol intended to detect faults in the bidirectional path > between two forwarding engines, including physical interfaces, > subinterfaces, data link(s), and to the extent possible the forwarding > engines themselves, with potentially very low latency. It operates > independently of media, data protocols, and routing protocols. An > additional goal is to provide a single mechanism that can be used for > liveness detection over any media, at any protocol layer, with > a wide range of detection times and overhead, to avoid a proliferation > of different methods. >=20 > Important characteristics of BFD include: >=20 > - Simple, fixed-field encoding to facilitate implementations in > hardware. >=20 > - Independence of the data protocol being forwarded between two = systems. > BFD packets are carried as the payload of whatever encapsulating > protocol is appropriate for the medium and network. >=20 > - Path independence: BFD can provide failure detection on any kind of > path between systems, including direct physical links, virtual > circuits, tunnels, MPLS LSPs, multihop routed paths, and > unidirectional links (so long as there is some return path, of > course). >=20 > - Ability to be bootstrapped by any other protocol that automatically > forms peer, neighbor or adjacency relationships to seed BFD endpoint > discovery. >=20 > The working group is currently chartered to complete the following = work items: >=20 > 1. Develop the MIB modules for BFD and submit them to the IESG for > publication as Proposed Standards. >=20 > 2a. Provide a generic keying-based cryptographic authentication > mechanism for the BFD protocol developing the work of the KARP > working group. This mechanism will support authentication through > a key identifier for the BFD session's Security Association rather > than specifying new authentication extensions. >=20 > 2b. Provide extensions to the BFD MIB in support of the generic = keying- > based cryptographic authentication mechanism. >=20 > 2c. Specify cryptographic authentication procedures for the BFD = protocol > using HMAC-SHA-256 (possibly truncated to a smaller integrity check > value but not beyond commonly accepted lengths to ensure security) = using > the generic keying-based cryptographic authentication mechanism. >=20 > 3. Provide an extension to the BFD core protocol in support of = point-to- > multipoint links and networks. >=20 > 4. Provide an informational document to recommend standardized timers > and timer operations for BFD when used in different applications. >=20 > 5. Define a mechanism to perform single-ended path (i.e. continuity) > verification based on the BFD specification. Allow such a mechanism = to > work both proactively and on-demand, without prominent initial delay. > Allow the mechanism to maintain multiple sessions to a target entity = and > between the same pair of network entities. In doing this work, the WG > will work closely with at least the following other WGs: ISIS, OSPF, > SPRING. >=20 > The working group will maintain a relationship with the MPLS working = group. >=20 > Proposed Milestones: >=20 > Done Submit the base protocol specification to the IESG to be > considered as a Proposed Standard > Done Submit BFD encapsulation and usage profile for single-hop = IPv4 > and IPv6 adjacencies to the IESG to be considered as a > Proposed Standard > Done Submit BFD encapsulation and usage profile for MPLS LSPs to > the IESG to be considered as a Proposed Standard > Done Submit BFD encapsulation and usage profile for multi-hop = IPv4 > and IPv6 adjacencies to the IESG to be considered as a > Proposed Standard > Done Submit the BFD MIB to the IESG to be considered as a = Proposed > Standard > Done Submit the BFD over LAG mechanism to the IESG to be = considered > as a Proposed Standard > Jun 2014 Submit the the document on BFD point-to-multipoint support = to > the IESG to be considered as a Proposed Standard > Nov 2014 Submit the BFD MPLS extension MIB to the IESG to be = considered > as a Proposed Standard > Jan 2015 Submit the generic keying based cryptographic authentication > mechanism to the IESG to be considered as a Proposed = Standard > Jan 2015 Submit a BFD MIB extension in support of the generic keying > document to the IESG to be considered as a Proposed Standard > Jan 2015 Submit the cryptographic authentication procedures for BFD = to > the IESG to be considered as a Proposed Standard > Jan 2015 Submit the BFD Common Intervals document to the IESG to be > considered as an Informational RFC From nobody Fri May 30 06:29:00 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691131A6FF3 for ; Fri, 30 May 2014 06:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEIMtp4CuUUQ for ; Fri, 30 May 2014 06:28:57 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A982B1A7001 for ; Fri, 30 May 2014 06:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1496; q=dns/txt; s=iport; t=1401456532; x=1402666132; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=dtlKnrhz+9kZc2hYVa7HCmfL2zAxqrlxyi8yw50QFYA=; b=JnoLhK74JkXpI68f137fcbcRzeEc9etBTijd4X7W0r8i3tq1t9Ux4MR7 t0fLIvgLd5HjehumI2VnUbwDa3ITuTAlZTuP79sci1Cjcr90ENPIF+pqN 5NP6dnKyK2D5Ai038Fl3XO6DD21pOCz78oHX7vhD+9T867JULSF/XGx39 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAD6GiFOtJssW/2dsb2JhbABZhx2/TgGBH3SCJQEBAQMBIxUvCQIGEQsaAgUWCwICCQMCAQIBPAkHDAgBAYg2CLIZhnydcxeBKo0vgnWBSwEDmXqTLIF4gUE X-IronPort-AV: E=Sophos;i="4.98,941,1392163200"; d="scan'208";a="63709109" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 30 May 2014 13:28:50 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4UDSowH013447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 May 2014 13:28:50 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s4UDSnlK015476; Fri, 30 May 2014 14:28:49 +0100 (BST) Message-ID: <53888792.1020101@cisco.com> Date: Fri, 30 May 2014 14:28:50 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, rtg-bfd@ietf.org Subject: Re: FW: Internal WG Review: Recharter of Bidirectional Forwarding Detection (bfd) References: <20140529171320.29323.7853.idtracker@ietfa.amsl.com> <01b301cf7c05$dd290f10$977b2d30$@olddog.co.uk> In-Reply-To: <01b301cf7c05$dd290f10$977b2d30$@olddog.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/fL5kKiDekxUoDdSVH7kpYq_ZghU X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 13:28:58 -0000 Just a couple of pedantic nits that I notice in passing. > > The BFD Working Group is chartered to standardize and support the > bidirectional forwarding detection protocol (BFD) and its extensions. A > core goal of the working group is to standardize BFD in the context of > IP routing, or protocols such as MPLS that are based on IP routing, in a > way that will encourage multiple, inter-operable vendor implementations. Isn't BFD also used to support TRILL (which has no basis on IP)? >> >> Important characteristics of BFD include: >> >> - Simple, fixed-field encoding to facilitate implementations in >> hardware. Well it does have options. Perhaps you just mean hardware efficient encoding. >> >> - Independence of the data protocol being forwarded between two systems. >> BFD packets are carried as the payload of whatever encapsulating >> protocol is appropriate for the medium and network. >> >> - Path independence: BFD can provide failure detection on any kind of Any kind of path is a bit ambitious! >> path between systems, including direct physical links, virtual >> circuits, tunnels, MPLS LSPs, multihop routed paths, and >> unidirectional links (so long as there is some return path, of >> course). >> >> - Ability to be bootstrapped by any other protocol that automatically >> forms peer, neighbor or adjacency relationships to seed BFD endpoint >> discovery. Similarly here "any" is very ambitious. - Stewart From nobody Fri May 30 08:47:17 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880701A0980; Fri, 30 May 2014 08:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j111GWtYtppB; Fri, 30 May 2014 08:47:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 951231A099F; Fri, 30 May 2014 08:47:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-mib-21.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140530154709.2237.31154.idtracker@ietfa.amsl.com> Date: Fri, 30 May 2014 08:47:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/sYHaYR4sw2afjnQhh5EnONpMu-Y Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 15:47:13 -0000 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 : BFD Management Information Base Authors : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-mib-21.txt Pages : 39 Date : 2014-05-30 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-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-mib-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat May 31 13:09:10 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3601A08BD; Thu, 29 May 2014 06:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1O_uOWMzKHF1; Thu, 29 May 2014 06:22:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E61991A08E9; Thu, 29 May 2014 06:22:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG Subject: Kathleen Moriarty's No Objection on charter-ietf-bfd-07-03: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140529132211.16996.53473.idtracker@ietfa.amsl.com> Date: Thu, 29 May 2014 06:22:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/zs35E5CSOWCjKoshRz28yYWoHXA X-Mailman-Approved-At: Sat, 31 May 2014 13:09:06 -0700 Cc: rtg-bfd@ietf.org, bfd-chairs@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:22:13 -0000 Kathleen Moriarty has entered the following ballot position for charter-ietf-bfd-07-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-bfd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This all sounds good. I am wondering what other close relationships are needed besides MPLS with KARP closing for all the crypto related work? There may be something in place already that I am not aware of or key participants helping to facilitate this, so it's really just a question for my understanding. Thanks. From nobody Sat May 31 13:09:15 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9961A090C; Thu, 29 May 2014 06:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzh8rxW34sBn; Thu, 29 May 2014 06:22:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADC61A08BD; Thu, 29 May 2014 06:22:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG Subject: Kathleen Moriarty's No Objection on charter-ietf-bfd-07-03: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140529132217.24351.45203.idtracker@ietfa.amsl.com> Date: Thu, 29 May 2014 06:22:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/v3TE116rfvQ0RVO1_yq_2Y4NKOY X-Mailman-Approved-At: Sat, 31 May 2014 13:09:06 -0700 Cc: rtg-bfd@ietf.org, bfd-chairs@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:22:19 -0000 Kathleen Moriarty has entered the following ballot position for charter-ietf-bfd-07-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-bfd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This all sounds good. I am wondering what other close relationships are needed besides MPLS with KARP closing for all the crypto related work? There may be something in place already that I am not aware of or key participants helping to facilitate this, so it's really just a question for my understanding. Thanks. From nobody Sat May 31 13:09:16 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB521A06CC; Thu, 29 May 2014 16:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aus7qVvViCF4; Thu, 29 May 2014 16:16:54 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F941A030D; Thu, 29 May 2014 16:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5251; q=dns/txt; s=iport; t=1401405410; x=1402615010; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=lZca44rMKv5FE8KEKyCaxxPqjmYypB9ecBwJj4Bc2bc=; b=hLrJKJQIYXgfguQDgqrsTnlnkSKJMS3Lr1PHUFwzGOGumbb3equT77Bg AHTGxGEsm1ObDjJtaBJCKQYFP+kWQjUW0SGVU80NvPrhA0XlAw5gc25gk L2+uUOaWrySowImjVyNGIkaAvAPonAYm2UklXXU4Aqu2BtSwVRwhRy6IY 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAHAIG/h1OtJV2T/2dsb2JhbABWA4MHqz0BAQEBAQEFAZgYAYELFnSCJQEBAQMBeQULCxguITYGE4guAwkI0UUNhhMXhVWGZ4E0EQFAEAcRgxqBFQSKIo1dgXaGbIZKhXODWB2BOQ X-IronPort-AV: E=Sophos; i="4.98,937,1392163200"; d="scan'208,217"; a="48477547" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP; 29 May 2014 23:16:49 +0000 Received: from [10.154.161.87] ([10.154.161.87]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s4TNGlxR027511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 May 2014 23:16:48 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_B8E42B10-36D2-40D2-A5EA-6FC61D1D9129" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Stephen Farrell's Block on charter-ietf-bfd-07-02: (with BLOCK) From: Brian Weis In-Reply-To: Date: Thu, 29 May 2014 16:16:49 -0700 Message-Id: <54465E23-C229-4621-A595-019A3F85D37F@cisco.com> References: <20140528004621.19460.38085.idtracker@ietfa.amsl.com> <20140528005005.GD19384@pfrc> To: Manav Bhatia X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/A-hikxKMu-GECSTwSyuvx-Gq-wI X-Mailman-Approved-At: Sat, 31 May 2014 13:09:07 -0700 Cc: "rtg-bfd@ietf.org" , The IESG , bfd-chairs@tools.ietf.org, Stephen Farrell X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 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, 29 May 2014 23:16:56 -0000 --Apple-Mail=_B8E42B10-36D2-40D2-A5EA-6FC61D1D9129 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am currently doing the shepherd review, and will be working with the = authors to get the draft ready for submission to the IESG. Brian On May 27, 2014, at 6:15 PM, Manav Bhatia wrote: > BTW, Brian Weis (co-chair KARP) has promised Adrian and me a shepherd = review and a writeup before the end of the week, after which we can get = going. >=20 > Cheers, Manav >=20 >=20 > On Wed, May 28, 2014 at 6:20 AM, Jeffrey Haas wrote: > On Tue, May 27, 2014 at 05:46:21PM -0700, Stephen Farrell wrote: > > = ---------------------------------------------------------------------- > > BLOCK: > > = ---------------------------------------------------------------------- > > > > > > The text refers to KARP, which is closing. What's the plan then? > > If its to do the work in BFD that's fine. >=20 > The proposed charter update was submitted prior to the official = announcement > of KARP closing. With regard to the BFD charter, delete the = reference. :-) >=20 > With regard to the remaining KARP item for BFD, I've volunteered to do = the > shepherd writeup soon and let the publication process happen as a = final work > item of KARP. >=20 > BFD had already adopted work to implement the KARP drafts' work. >=20 > -- Jeff >=20 >=20 --=20 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com --Apple-Mail=_B8E42B10-36D2-40D2-A5EA-6FC61D1D9129 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I am = currently doing the shepherd review, and will be working with the = authors to get the draft ready for submission to the = IESG.

Brian

On May 27, 2014, = at 6:15 PM, Manav Bhatia <manavbhatia@gmail.com> = wrote:

BTW, Brian Weis (co-chair KARP) has = promised Adrian and me a shepherd review and a writeup before the end of = the week, after which we can get going.

Cheers, = Manav


On Wed, May 28, 2014 at 6:20 AM, = Jeffrey Haas <jhaas@pfrc.org> wrote:
On Tue, May 27, 2014 at 05:46:21PM -0700, Stephen = Farrell wrote:
> = ----------------------------------------------------------------------
= > BLOCK:
> = ----------------------------------------------------------------------
= >
>
> The text refers to KARP, which is closing. What's the plan = then?
> If its to do the work in BFD that's fine.

The proposed charter update was submitted prior to the official = announcement
of KARP closing.  With regard to the BFD charter, delete the = reference. :-)

With regard to the remaining KARP item for BFD, I've volunteered to do = the
shepherd writeup soon and let the publication process happen as a final = work
item of KARP.

BFD had already adopted work to implement the KARP drafts' work.

-- Jeff



bew@cisco.com

= --Apple-Mail=_B8E42B10-36D2-40D2-A5EA-6FC61D1D9129--