From iesg-secretary@ietf.org Thu Jan 2 09:29: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 7D7EE1AD9AD; Thu, 2 Jan 2014 09:29:55 -0800 (PST) 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 JSCFyYg6umDC; Thu, 2 Jan 2014 09:29:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFDE1AE69B; Thu, 2 Jan 2014 09:29:51 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces' to Proposed Standard (draft-ietf-bfd-on-lags-04.txt) X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140102172951.25073.66484.idtracker@ietfa.amsl.com> Date: Thu, 02 Jan 2014 09:29:51 -0800 Cc: bfd mailing list , bfd chair , RFC Editor 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, 02 Jan 2014 17:29:55 -0000 The IESG has approved the following document: - 'Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces' (draft-ietf-bfd-on-lags-04.txt) as Proposed Standard This document is the product of the Bidirectional Forwarding Detection Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags/ Technical Summary This document defines a mechanism to run BFD on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link. This mechanism allows the verification of member link continuity, either in combination with, or in absence of, LACP. It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of layer 3 bidirectional forwarding. This mechanism utilizes a well-known UDP port distinct from that of single-hop BFD over IP. This new UDP port removes the ambiguity of BFD over LAG packets from BFD over single-hop IP. Working Group Summary The blurred line between L2 and L3 initiated several interesting discussions. Is it a layer violation for BFD operating at layer 3 to make layer 2 decision? How does it interact with LACP? How does it influence LAG member link usability? The desire and need for rapid detection of LAG member link usability, as well as similar solutions already implemented by multiple vendors, resulted in consensus to push this technology forward. The WG was satisfied with very careful wordings of the document to ensure that solution does not tread on IEEE turf. In addition, remote IP address discovery was a controversial topic. There were multiple ideas to do this dynamically, on which the WG couldn't reach consensus. Thus this aspect was taken out into a separate draft.That spin-off draft died, since people lost interest due to statically configuring remote IP address working good enough. Document Quality There are multiple implementations of the protocol. An event was held to interoperate the implementations. The document has been reviewed through the normal WG process. No MIB Doctor, Media Type or other expert review been performed or requested. Personnel Nobo Akiya is the document Shepherd. Adrian Farrel is the responsible AD. From nobo@cisco.com Thu Jan 16 09:59:52 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 809481A1F1F for ; Thu, 16 Jan 2014 09:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 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.538, 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 RW43JSbtBtTN for ; Thu, 16 Jan 2014 09:59:51 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B02F51A16F0 for ; Thu, 16 Jan 2014 09:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=528; q=dns/txt; s=iport; t=1389895180; x=1391104780; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=wtm0DETwu57SB8onx/hslMiAzOm5NLne8o6cwXNEy2o=; b=C1rCKtNJl+bhALjVChaqdrDedjpl3s0KoMTIp8DfHgWk0B5pwipElAvL rcxKcHUtWT/sz7Pk+OmSgaxf5ZPJ25XClUuKg3Pn3IBMZiHL5UZ012AwK WLNBQ0LqA1TA2Ab93kPevB2gOj/LA6yDyV5PtWQyIN4ZdQUfIq9jZzFpM I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAKId2FKtJV2d/2dsb2JhbABZgmohgQ67C4EOFnSCJwEEOjQdASoUQiYBBBsTh2kBmUyrOReOToNcgRQEqjiDLYIq X-IronPort-AV: E=Sophos;i="4.95,668,1384300800"; d="scan'208";a="297811483" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 16 Jan 2014 17:59:39 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0GHxdrG008035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 16 Jan 2014 17:59:39 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; Thu, 16 Jan 2014 11:59:39 -0600 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: No BFD WG Meeting at IETF89 Thread-Topic: No BFD WG Meeting at IETF89 Thread-Index: Ac8S4tIACWkBedh6TAq3HaEHHqbeMg== Date: Thu, 16 Jan 2014 17:59:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.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, 16 Jan 2014 17:59:52 -0000 Hi BFDers, Jeff and I have concluded that BFD WG will not be meeting at IETF89. Part of the reasons being that there hasn't been sufficient discussions on = the mailing list since IETF88. I am aware of several off-list discussions around S-BFD topics (both soluti= ons and use-cases). Going forward, I strongly encourage everyone to have more discussions on th= e mailing list. (Yes I am guilty of some closed discussions myself, and I will be sure to d= o more open discussion) Thank you, Nobo, as co-chair From jhaas@slice.pfrc.org Tue Jan 21 11:09: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 9A6EE1A01C0 for ; Tue, 21 Jan 2014 11:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.535, 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 aRlCKsImx5vt for ; Tue, 21 Jan 2014 11:09:21 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0002D1A0180 for ; Tue, 21 Jan 2014 11:09:20 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id EDE88C17E; Tue, 21 Jan 2014 14:09:20 -0500 (EST) Date: Tue, 21 Jan 2014 14:09:20 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: [rse@rfc-editor.org: Collecting input on future xml2rfc vocabulary] Message-ID: <20140121190920.GE4366@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.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, 21 Jan 2014 19:09:22 -0000 ----- Forwarded message from "Heather Flanagan (RFC Series Editor)" ----- Date: Tue, 21 Jan 2014 10:35:30 -0800 From: "Heather Flanagan (RFC Series Editor)" To: 'Working Group Chairs' Subject: Collecting input on future xml2rfc vocabulary Hello WG Chairs, I would like to enlist your assistance in getting the word out to active authors about current efforts to update the xml2rfc vocabulary and DTD. Some of the best input comes at the point when an author is trying to create a draft and finds themselves wishing that xml2rfc had a particular feature, or behaved in a different way. Now is the best time to collect that information, since the RFC Format Design Team is in the process of recommending a variety of changes to support the new proposed formats for RFCs. Authors should send their suggestions to the rfc-interest@rfc-editor.org mailing list, where they will be discussed and then captured by the design team. The archives of that list (available from ) provide details on what has already been discussed. The Design Team wiki (read-only) has also captured some of the discussion and decisions so far. See: . Thank you for your help, Heather Flanagan RFC Series Editor ----- End forwarded message ----- From nobo@cisco.com Fri Jan 31 15:25: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 75A5D1AC7EE for ; Fri, 31 Jan 2014 15:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 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.535, 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 wAUOXpfmuNmN for ; Fri, 31 Jan 2014 15:25:13 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7521A04F6 for ; Fri, 31 Jan 2014 15:25:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=804; q=dns/txt; s=iport; t=1391210710; x=1392420310; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=l1cWHUjJRNm0Vh+BrSNvXolWKBWnNlINbMlYA9iIsJ4=; b=UR+RbyO3ivmZRkgr0V+g+VT+B32ZAG8in6sFT2woc84jqkLeSmjxNzWD HSjywhx/lj50krKX+mxxbVgq16BhYjYtHCnDkNG7388b9Mq4Ym3JNSeOH tkI6DvwARMJfIac/Ts0hWGc+yXQySfBz9UN6hMk34sHBAfp8tJMrs9Z4m 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAEgw7FKtJXHB/2dsb2JhbABZgmshgQ+9WYEMFnSCJwEEOlEBKhRCJgEEG4d9AZx6sEEXjlGDXIEUBKpLgy2CKg X-IronPort-AV: E=Sophos;i="4.95,760,1384300800"; d="scan'208";a="17102090" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-1.cisco.com with ESMTP; 31 Jan 2014 23:25:08 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0VNP87U018409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 31 Jan 2014 23:25:08 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 31 Jan 2014 17:25:08 -0600 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: S-BFD discriminator for ISIS? Thread-Topic: S-BFD discriminator for ISIS? Thread-Index: Ac8e2U/W07BIR+TVQ0y8Kru37a/QEg== Date: Fri, 31 Jan 2014 23:25:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.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, 31 Jan 2014 23:25:14 -0000 Hi BFDers, So I had a chat with ISIS person. Obviously we need ISIS to advertise S-BFD discriminator. But the question is, how does ISIS choose what discriminator to allocate? Discriminator should be as much unique as possible in the domain, if not gu= aranteed unique. This is to ensure reflector session does not respond to falsely self-termin= ating S-BFD packet. 1. One approach would be to simply have operators configure network wide un= ique 4-byte for each ISIS.=20 2. Another approach would be to compute 4-byte from *local stuff*, and come= up with a conflict resolution mechanism. My initial thought is that (1) is reasonable for immediate needs. But wanted to check with others on the list. Any comments and/or preferences? -Nobo (as individual contributor) From aldrin.ietf@gmail.com Fri Jan 31 17:11:44 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 3D17D1ACCE9 for ; Fri, 31 Jan 2014 17:11:44 -0800 (PST) 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 4W3w2zRArsVO for ; Fri, 31 Jan 2014 17:11:42 -0800 (PST) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id CA1D41A04F9 for ; Fri, 31 Jan 2014 17:11:42 -0800 (PST) Received: by mail-pd0-f177.google.com with SMTP id x10so4852495pdj.8 for ; Fri, 31 Jan 2014 17:11:39 -0800 (PST) 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=oXorcSiJSx0VKpXc1YPCk/ky9WrMKLLJsL7GMRQPFm0=; b=Mnm5Pw/PMo99NxXLgpr9FUfwaOiU6sj42OVgOZBHuhg8i3iJN/8X5/YkJScRhwOnXl 2rGdkxwLpZ/TGyQ9auM0DfyRu6g3kf6EJMnvK8eyyfG2W9tjKQ0V7P/duhs39KrwOK2T Tfc9DlA+yHsZjdn14stOE3r7SM0F2no9J5E+3Xq1RMIwD/io1QC/cokzDPS0bcqMEJag 3rW5ilGy1XwQPbpFdvg7NKHDhDkE6DU/qHJ2LkohRpxl9PcjtM7rVuuRJrZvJaq5rK2t xZ55K0qQle85874e3wZ6yY3x5yrtrZzeER+06n0sbXTkW+hAuJhd9zg4cTIhPdsFu0op uocg== X-Received: by 10.66.189.100 with SMTP id gh4mr23544653pac.25.1391217099185; Fri, 31 Jan 2014 17:11:39 -0800 (PST) Received: from [192.168.1.2] (c-107-3-154-8.hsd1.ca.comcast.net. [107.3.154.8]) by mx.google.com with ESMTPSA id z10sm79682868pas.6.2014.01.31.17.11.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jan 2014 17:11:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: S-BFD discriminator for ISIS? From: Sam Aldrin In-Reply-To: Date: Fri, 31 Jan 2014 17:11:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1827) 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, 01 Feb 2014 01:11:44 -0000 Hi Nobo, Option #1 is a reasonable approach and is the understanding for the = solutions discussed thus far. Eventually support for #2 should be there = as well, but that does take time and discussions to come to a common = solution.=20 Cheers -sam On Jan 31, 2014, at 3:25 PM, Nobo Akiya (nobo) wrote: > Hi BFDers, >=20 > So I had a chat with ISIS person. >=20 > Obviously we need ISIS to advertise S-BFD discriminator. > But the question is, how does ISIS choose what discriminator to = allocate? >=20 > Discriminator should be as much unique as possible in the domain, if = not guaranteed unique. > This is to ensure reflector session does not respond to falsely = self-terminating S-BFD packet. >=20 > 1. One approach would be to simply have operators configure network = wide unique 4-byte for each ISIS.=20 >=20 > 2. Another approach would be to compute 4-byte from *local stuff*, and = come up with a conflict resolution mechanism. >=20 > My initial thought is that (1) is reasonable for immediate needs. > But wanted to check with others on the list. >=20 > Any comments and/or preferences? >=20 > -Nobo > (as individual contributor) >=20 From marc@sniff.de Fri Jan 31 17:39:39 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 72EFE1ACCE3 for ; Fri, 31 Jan 2014 17:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535] 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 1iBsa6BfCxAB for ; Fri, 31 Jan 2014 17:39:37 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2F01ACCE0 for ; Fri, 31 Jan 2014 17:39:37 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id AC8862AA0F; Sat, 1 Feb 2014 01:39:32 +0000 (GMT) Date: Fri, 31 Jan 2014 17:39:33 -0800 From: Marc Binderberger To: Nobo Akiya (nobo) Message-ID: <20140131173933034563.54c393e9@sniff.de> In-Reply-To: References: Subject: Re: S-BFD discriminator for ISIS? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.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, 01 Feb 2014 01:39:39 -0000 Hello Nobo, must have missed some discussions ... > So I had a chat with ISIS person. > > Obviously we need ISIS to advertise S-BFD discriminator. ... but you mean the discriminator of the reflecting node is not identical with the IPv4 address anymore but potentially independent and learned by the other systems, with ISIS as the distribution mechanism? Good! :-) > But the question is, how does ISIS choose what discriminator to allocate? Maybe a nitpick but ISIS should transport the discriminator value of a particular site but should not have knowledge how to choose a discriminator. Just another 32bit number for ISIS to send as TLV. Saying this if ISIS finds a conflict in it's database, i.e. two identical discriminators from different nodes, then raising an alarm would be useful (not necessary though). > 1. One approach would be to simply have operators configure network > wide unique 4-byte for each ISIS. sounds like a working solution to start with. Also it provides a simple answer to an area I think is an implementation detail, outside BFD or even ISIS protocol specification. Regards, Marc > > Discriminator should be as much unique as possible in the domain, if > not guaranteed unique. > This is to ensure reflector session does not respond to falsely > self-terminating S-BFD packet. > > 1. One approach would be to simply have operators configure network > wide unique 4-byte for each ISIS. > > 2. Another approach would be to compute 4-byte from *local stuff*, > and come up with a conflict resolution mechanism. > > My initial thought is that (1) is reasonable for immediate needs. > But wanted to check with others on the list. > > Any comments and/or preferences? > > -Nobo > (as individual contributor) > From nobo@cisco.com Fri Jan 31 18:31:38 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 52F301ACCE3 for ; Fri, 31 Jan 2014 18:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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.535, 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 jsVXHwYN1Tof for ; Fri, 31 Jan 2014 18:31:36 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 970A31ACCDF for ; Fri, 31 Jan 2014 18:31:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3174; q=dns/txt; s=iport; t=1391221893; x=1392431493; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zNLDjwo55yDB5q+HTFLPvAZq6bK8MvWkvFkvGM+aOO8=; b=dew0kDLcagShbKMxlvfPpRArmuXkngZmwZ8WKRWl7BKyFeeAF91BVa9+ UxnUMA/1lGfQjQF57BfP8CGeWUHSBrlDvbex5fCXTm+PPqLy7fGtRMVW/ lLBcOLqPmLXyWKBaoE/WMO4NFAo8SIedYUl5r1+sWxFGA4fPGWiWCLwt2 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACBc7FKtJV2a/2dsb2JhbABPCoJrIYEPvViBDBZ0giUBAQEDATo/EAIBCCIUEDIlAQEEAQ0NE4diCAHNTxeOJisxB4MkgRQBA6pLgy2CKg X-IronPort-AV: E=Sophos;i="4.95,760,1384300800"; d="scan'208";a="301134212" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 01 Feb 2014 02:31:32 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s112VWuu002522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 1 Feb 2014 02:31:32 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([::1]) with mapi id 14.03.0123.003; Fri, 31 Jan 2014 20:31:32 -0600 From: "Nobo Akiya (nobo)" To: Marc Binderberger , "Sam Aldrin (sam.aldrin@gmail.com)" Subject: RE: S-BFD discriminator for ISIS? Thread-Topic: S-BFD discriminator for ISIS? Thread-Index: Ac8e2U/W07BIR+TVQ0y8Kru37a/QEgAR2+2AAAuHwpA= Date: Sat, 1 Feb 2014 02:31:31 +0000 Message-ID: References: <20140131173933034563.54c393e9@sniff.de> In-Reply-To: <20140131173933034563.54c393e9@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.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, 01 Feb 2014 02:31:38 -0000 Thanks for comments Sam and Marc. [combining reply in one] [Sam wrote] > Option #1 is a reasonable approach and is the understanding for the > solutions discussed thus far. Eventually support for #2 should be there a= s > well, but that does take time and discussions to come to a common > solution. That's good to hear that you also think option #1 is reasonable. More comme= nts about option #2 below. [Marc wrote] > > So I had a chat with ISIS person. > > > > Obviously we need ISIS to advertise S-BFD discriminator. >=20 > ... but you mean the discriminator of the reflecting node is not identica= l > with the IPv4 address anymore but potentially independent and learned by > the other systems, with ISIS as the distribution mechanism? >=20 IPv4 address can remain the same, i.e. IPv4 address used as discriminator a= s is. For ISIS network w/ IPv6, we'll need ISIS to distribute system-id (6 = bytes) to discriminator (4 bytes) mapping. > > But the question is, how does ISIS choose what discriminator to allocat= e? >=20 > Maybe a nitpick but ISIS should transport the discriminator value of a > particular site but should not have knowledge how to choose a > discriminator. Just another 32bit number for ISIS to send as TLV. True. It could be outside of ISIS as well, but some entity will have to do = it. >=20 > Saying this if ISIS finds a conflict in it's database, i.e. two identical > discriminators from different nodes, then raising an alarm would be usefu= l > (not necessary though). Exactly. BFD won't be able to detect the conflict but BFD client (ISIS in t= his case) is in better position to identify the conflict. Upon conflict, wh= ich node need to change then, and how to change w/o affecting reflector ses= sion already bouncing packets back. These sort of questions will need to be= answered, when we (WG) think it's wanted/needed. >=20 > > 1. One approach would be to simply have operators configure network > > wide unique 4-byte for each ISIS. >=20 > sounds like a working solution to start with. Also it provides a simple > answer to an area I think is an implementation detail, outside BFD or eve= n > ISIS protocol specification. Good :) If there are other agreements to option #1 (config approach) or arguments a= gainst it, I certainly would like to hear. It will help improve usability o= f S-BFD out in the wild. -Nobo >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 > > > > Discriminator should be as much unique as possible in the domain, if > > not guaranteed unique. > > This is to ensure reflector session does not respond to falsely > > self-terminating S-BFD packet. > > > > 1. One approach would be to simply have operators configure network > > wide unique 4-byte for each ISIS. > > > > 2. Another approach would be to compute 4-byte from *local stuff*, and > > come up with a conflict resolution mechanism. > > > > My initial thought is that (1) is reasonable for immediate needs. > > But wanted to check with others on the list. > > > > Any comments and/or preferences? > > > > -Nobo > > (as individual contributor) > > From marc@sniff.de Fri Jan 31 23:13:25 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 A101D1A0536 for ; Fri, 31 Jan 2014 23:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535] 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 ksM_hU8T4s7b for ; Fri, 31 Jan 2014 23:13:23 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2FE1A0534 for ; Fri, 31 Jan 2014 23:13:22 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 99EE02AA0F; Sat, 1 Feb 2014 07:13:16 +0000 (GMT) Date: Fri, 31 Jan 2014 23:13:18 -0800 From: Marc Binderberger To: Nobo Akiya (nobo) Message-ID: <20140131231318767731.e3c8f834@sniff.de> In-Reply-To: References: <20140131173933034563.54c393e9@sniff.de> Subject: RE: S-BFD discriminator for ISIS? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Cc: "rtg-bfd@ietf.org" , "Sam Aldrin \(sam.aldrin@gmail.com\)" 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, 01 Feb 2014 07:13:25 -0000 Hi Nobo, > IPv4 address can remain the same, i.e. IPv4 address used as > discriminator as is. For ISIS network w/ IPv6, we'll need ISIS to > distribute system-id (6 bytes) to discriminator (4 bytes) mapping. hmm. You know from our private discussions that I personally think using IPv4 addresses as discriminator values is, well, not optimal ;-) But before explaining this I would say having one mechanism that "covers it all" would be a good thing (tm). Like ISIS covers both IPv4 and IPv6, you don't have to learn a new mechanism. So for a network node you would have it's labels and it's discriminator value (or values?). For simplicity of this discussion lets say assigned by an administrator with a full overview. Then ISIS distributes this. Some node X wants to BFD-test the path to node Y? Okay, X has learned via ISIS the necessary information. Generic, I haven't talked anywhere about IPv4 or IPv6 :-) Back to my "not optimal": so far a node was free to choose what discriminator values it wants to use. The BFD peer (in RFC5880 sense) just copied the value back. This freedom of choice has been used to simplify implementations, e.g. only using the lower bits to index into arrays or match in TCAMs. And so far all the standards have abide and not imposed a condition or structure on the discriminator values (except zero). Sure, you can get the Address-as-discriminator scheme working. But why taking this freedom for the implementor away? But I wasn't in Vancouver and may have missed something :-) Regards, Marc On Sat, 1 Feb 2014 02:31:31 +0000, Nobo Akiya (nobo) wrote: > Thanks for comments Sam and Marc. > > [combining reply in one] > > [Sam wrote] >> Option #1 is a reasonable approach and is the understanding for the >> solutions discussed thus far. Eventually support for #2 should be there as >> well, but that does take time and discussions to come to a common >> solution. > > That's good to hear that you also think option #1 is reasonable. More > comments about option #2 below. > > [Marc wrote] >>> So I had a chat with ISIS person. >>> >>> Obviously we need ISIS to advertise S-BFD discriminator. >> >> ... but you mean the discriminator of the reflecting node is not identical >> with the IPv4 address anymore but potentially independent and learned by >> the other systems, with ISIS as the distribution mechanism? >> > > IPv4 address can remain the same, i.e. IPv4 address used as > discriminator as is. For ISIS network w/ IPv6, we'll need ISIS to > distribute system-id (6 bytes) to discriminator (4 bytes) mapping. > >>> But the question is, how does ISIS choose what discriminator to allocate? >> >> Maybe a nitpick but ISIS should transport the discriminator value of a >> particular site but should not have knowledge how to choose a >> discriminator. Just another 32bit number for ISIS to send as TLV. > > True. It could be outside of ISIS as well, but some entity will have > to do it. > >> >> Saying this if ISIS finds a conflict in it's database, i.e. two identical >> discriminators from different nodes, then raising an alarm would be useful >> (not necessary though). > > Exactly. BFD won't be able to detect the conflict but BFD client > (ISIS in this case) is in better position to identify the conflict. > Upon conflict, which node need to change then, and how to change w/o > affecting reflector session already bouncing packets back. These sort > of questions will need to be answered, when we (WG) think it's > wanted/needed. > >> >>> 1. One approach would be to simply have operators configure network >>> wide unique 4-byte for each ISIS. >> >> sounds like a working solution to start with. Also it provides a simple >> answer to an area I think is an implementation detail, outside BFD or even >> ISIS protocol specification. > > Good :) > > If there are other agreements to option #1 (config approach) or > arguments against it, I certainly would like to hear. It will help > improve usability of S-BFD out in the wild. > > -Nobo > >> >> >> Regards, Marc >> >> >> >> >>> >>> Discriminator should be as much unique as possible in the domain, if >>> not guaranteed unique. >>> This is to ensure reflector session does not respond to falsely >>> self-terminating S-BFD packet. >>> >>> 1. One approach would be to simply have operators configure network >>> wide unique 4-byte for each ISIS. >>> >>> 2. Another approach would be to compute 4-byte from *local stuff*, and >>> come up with a conflict resolution mechanism. >>> >>> My initial thought is that (1) is reasonable for immediate needs. >>> But wanted to check with others on the list. >>> >>> Any comments and/or preferences? >>> >>> -Nobo >>> (as individual contributor) >>> >