From nobody Wed Apr 12 07:31:24 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EE2129BCC for ; Wed, 12 Apr 2017 07:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2U7Tg59wjk-1 for ; Wed, 12 Apr 2017 07:31:16 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7448A129BBD for ; Wed, 12 Apr 2017 07:31:06 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id r203so33461538oib.3 for ; Wed, 12 Apr 2017 07:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=BUdsDtZVQMAMu0DeHHvT+yeP0GcHQUgGygpA2RgfHU8=; b=glPfZrthpF6lNvIfxHI1hcmQZhQRZ6dVXdc8f6rfC3iq2qshrhIrgslwXNiIvnelsM ALIgspLgFhxqG1+25ONXp0oCsp/FthvW93KuTlCm/EML5NzSy8rxzOY+2r3qYkss9jC4 da7UTsjdT+T8rzEUlf910kQ3f0GcF/jg/OJU+MbbjrF0wINe2q99/g/nOvw2YSDvLYnr 9arQzPBaa3fp3myJ7VoBqUJTtOzMgmH3U4FK453WqyxrFI633+S8s97Rf1Rw063apZex hDm1Cs1ZFMefWTF8NtVXhugngN1ezYD1d4mcNlhRfEFuXwm+etvx5WZ51GKnEhUpxyoL q8Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BUdsDtZVQMAMu0DeHHvT+yeP0GcHQUgGygpA2RgfHU8=; b=gE6H17sJEry6uihX2AWallWpnkeLYDIF++t5+lS0YNYDWkFZI49r1DHKJPkVWfP8FO CxLz1kpOOXn3xYJfjepZtpGKetTe8S8SFj65pzCJDkqpgErIAxiTGk24iIElL7poSoXl ZzEeDxL7WGq/GkDxVF+iJgFSdHFBxqsgkWyLguS6KOKyGvypxsSvaFgakZwQy7RL9tW4 g0j3xe4gqRevZ+0ID43g2+TXr0UufedTzlwZt4qDJ1AAySf5hEOxH1n8NzrFk8UY0ddN nGuaipKREEa7zDIrbISraS5qgKODHgeQKR2BHEymgIU9smmHlC7/BjDb9kCMsGKBVUNR zCQA== X-Gm-Message-State: AN3rC/5bBYXiu38s4IydpXDW8ZexjfQK2Du2zPct36Rnosy9iW7/66M7VP2q/zvuDcp7iQHE8qvK53oRQwJU/g== X-Received: by 10.157.40.80 with SMTP id h16mr617932otd.90.1492007465638; Wed, 12 Apr 2017 07:31:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.38.239 with HTTP; Wed, 12 Apr 2017 07:31:05 -0700 (PDT) From: Muthu Arul Mozhi Perumal Date: Wed, 12 Apr 2017 20:01:05 +0530 Message-ID: Subject: S-BFD Implementation Status To: rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=001a1141b8fafdde4a054cf90e41 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 12 Apr 2017 14:31:23 -0000 --001a1141b8fafdde4a054cf90e41 Content-Type: text/plain; charset=UTF-8 S-BFD seems to the most appropriate mechanism that the head-end of a SR-TE tunnel can use to detect failure in the absence of local protection in one of the transit nodes.. Do we have any interop report for S-BFD? Or at least known implementations/vendors that support S-BFD? I know Cisco IOS XR supports it, based on publicly available information.. Regards, Muthu --001a1141b8fafdde4a054cf90e41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
S-BFD seems to the most appropriate mec= hanism that the head-end of a SR-TE tunnel can use to detect failure in the= absence of local protection in one of the transit nodes..

Do we have any interop report for S-B= FD? Or at least known implementations/vendors that support S-BFD? I know Ci= sco IOS XR supports it, based on publicly available information..

Regards,
Muthu

--001a1141b8fafdde4a054cf90e41-- From nobody Mon Apr 17 14:16:24 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26B21286CA for ; Mon, 17 Apr 2017 14:16:21 -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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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_03OnoBsQ for ; Mon, 17 Apr 2017 14:16:20 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A68ED127698 for ; Mon, 17 Apr 2017 14:16:20 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 94E7B1E1DA; Mon, 17 Apr 2017 17:23:26 -0400 (EDT) Date: Mon, 17 Apr 2017 17:23:26 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Draft minutes for IETF 98, Chicago Message-ID: <20170417212326.GA18219@pfrc.org> 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: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:16:22 -0000 Working Group, Thank you for your patience for the minutes and action items from the Working Group session in Chicago. The draft minutes are available at the following: https://www.ietf.org/proceedings/98/minutes/minutes-98-bfd-00 Please submit any proposed edits to the minutes by this Friday, April 21. -- Jeff and Reshad From nobody Mon Apr 17 14:28:30 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A71412EC57 for ; Mon, 17 Apr 2017 14:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 jUZ_5v9ycZRj for ; Mon, 17 Apr 2017 14:28:27 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6367C129480 for ; Mon, 17 Apr 2017 14:28:27 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A8E6E1E1DA; Mon, 17 Apr 2017 17:35:33 -0400 (EDT) Date: Mon, 17 Apr 2017 17:35:33 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Cc: "Reshad Rahman (rrahman)" , agarwaso@cisco.com Subject: Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017) Message-ID: <20170417213533.GB18219@pfrc.org> 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: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:28:28 -0000 Working Group, As part of our discussion at the Working Group session at IETF 98 in Chicago, Sonal Agarwal presented "Secure BFD Sequence Numbers" (draft-sonal-bfd-secure-sequence-numbers-00). This work complements a problem space the Security area had asked us to address as part of the work on optimizing BFD authentication, our adopted draft-ietf-bfd-optimizing-authentication. The discussion on the implementation implictions of the optimizing authentication draft was energetic this last IETF. To drive that solution further along, we will need a technology similar to the one in the proposal. This starts a 2 week adoption call for draft-sonal-bfd-secure-sequence-numbers. Please indicate your support or lack of support for the proposal to the mailing list. Note that part of the discussion was that optimizing BFD is not ready to proceed to Last CAll until we've adopted such a proposal and have properly integrated it into the optimization procedures. -- Jeff and Reshad From nobody Mon Apr 17 14:32:44 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70210128792 for ; Mon, 17 Apr 2017 14:32:42 -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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 kKMvB0ebfxsz for ; Mon, 17 Apr 2017 14:32:41 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF2A1242F7 for ; Mon, 17 Apr 2017 14:32:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B6C5F1E1DA; Mon, 17 Apr 2017 17:39:47 -0400 (EDT) Date: Mon, 17 Apr 2017 17:39:47 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Adoption call for draft-ashesh-bfd-stability (ends April 30, 2017) Message-ID: <20170417213947.GC18219@pfrc.org> 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: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:32:42 -0000 Working Group, https://tools.ietf.org/html/draft-ashesh-bfd-stability-05 The authors of BFD Stability (draft-ashesh-bfd-stability), presented their latest changes at IETF 98 in Chicago and have requested working group adoption. Please indicate your support or lack of support to the mailing list. -- Jeff and Reshad From nobody Mon Apr 17 14:34:30 2017 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D22A131569; Mon, 17 Apr 2017 14:34:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , Subject: The BFD WG has placed draft-ashesh-bfd-stability in state "Call For Adoption By WG Issued" X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149246486957.17688.4182906548021777371.idtracker@ietfa.amsl.com> Date: Mon, 17 Apr 2017 14:34:29 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:34:30 -0000 The BFD WG has placed draft-ashesh-bfd-stability in state Call For Adoption By WG Issued (entered by Jeffrey Haas) The document is available at https://datatracker.ietf.org/doc/draft-ashesh-bfd-stability/ From nobody Mon Apr 17 14:35:36 2017 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F23213156C; Mon, 17 Apr 2017 14:35:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , , Subject: The BFD WG has placed draft-sonal-bfd-secure-sequence-numbers in state "Call For Adoption By WG Issued" X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149246493512.17807.12121350614845191152.idtracker@ietfa.amsl.com> Date: Mon, 17 Apr 2017 14:35:35 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:35:35 -0000 The BFD WG has placed draft-sonal-bfd-secure-sequence-numbers in state Call For Adoption By WG Issued (entered by Jeffrey Haas) The document is available at https://datatracker.ietf.org/doc/draft-sonal-bfd-secure-sequence-numbers/ From nobody Mon Apr 17 14:40:43 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2D113154C for ; Mon, 17 Apr 2017 14:40:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Oa4mjdi8fWQa for ; Mon, 17 Apr 2017 14:40:41 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EAB0128BA2 for ; Mon, 17 Apr 2017 14:40:41 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id c198so71143838pfc.1 for ; Mon, 17 Apr 2017 14:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=drx5Y6RJ8GSceDyXxV3Ng8re4/0dhQIxy/qgVDDGsKs=; b=G0Nf8dPdl2ADsmY+umj94MkhsamZBp4IGcrZDpzAf2Jzj1ne2aAN/4YuJuYHsf3N3k KdkitAqoHeCaaOOWT30tBit+YfmGrtAGrC9pTq55Et6p5Vuupy8kveOfqac6c7Tacc7O cbAq8AYk2zN8SeSlzGFmRwxmjBliPiWwOI77hZSQpOI0crHSbQ4q+bxInlLtnG4Ugv5G hxOaLPPWbz1qPxPrmR/7lBqwpEebUFPiHvJNMcMnu/mOw1A9AXQkqQGWE5FpMnlg5iX5 BT2LFBOcaUF1yjj68JMMuVbaXghI+zVGIPFtzLHDALfHWNx6RnorjFvHDkemFGgt4dHG fZTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=drx5Y6RJ8GSceDyXxV3Ng8re4/0dhQIxy/qgVDDGsKs=; b=W4do0FynxETM/UwsjxMl1PUKuc11xsu9iXbJBQ9Q2XC8BwgE3/3f4F+il4p+gUmOcV cZxc6R2PMbN9Ls03Malb9sdEy/sut8l20WjLJYic+Z71HMRQYDod4lKKN8TR4id4FeOG 1AhUOyxyL5X1uEa+GEIY/1G6roFDbMNi8I5my9k/3t4+VYeyV+68BuqFm6AvcxTyxZYK 7gqTHgA/noK8nfgakodZrj7mljhf1s9EzmSIDY0VY84hZ3db8CSX2wcYAoX/7RTk1BOB z7vDSOWPkNjJAGI+Y9Qp8Wg8WBXsXHzuc6TQ4d6MDxFnFE2Eog8vJierAajHe1JD+rpl BO2w== X-Gm-Message-State: AN3rC/7MRBXdPtEBLBE343B4egv3CX7+h0bgIAb65ag64was8FPJiOfA XoI/Aj+EIyzywK6e X-Received: by 10.98.34.5 with SMTP id i5mr13735988pfi.228.1492465240670; Mon, 17 Apr 2017 14:40:40 -0700 (PDT) Received: from [192.168.254.233] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by smtp.gmail.com with ESMTPSA id q1sm12595022pfc.35.2017.04.17.14.40.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 14:40:39 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Mon, 17 Apr 2017 14:40:38 -0700 Subject: Re: Adoption call for draft-ashesh-bfd-stability (ends April 30, 2017) From: Jeff Tantsura To: Jeffrey Haas , Message-ID: Thread-Topic: Adoption call for draft-ashesh-bfd-stability (ends April 30, 2017) References: <20170417213947.GC18219@pfrc.org> In-Reply-To: <20170417213947.GC18219@pfrc.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:40:43 -0000 yes/support Cheers, Jeff On 4/17/17, 14:39, "Rtg-bfd on behalf of Jeffrey Haas" wrote: Working Group, https://tools.ietf.org/html/draft-ashesh-bfd-stability-05 The authors of BFD Stability (draft-ashesh-bfd-stability), presented their latest changes at IETF 98 in Chicago and have requested working group adoption. Please indicate your support or lack of support to the mailing list. -- Jeff and Reshad From nobody Mon Apr 17 15:48:35 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABE813159C for ; Mon, 17 Apr 2017 15:48:35 -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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 2WWVMamjSwtl for ; Mon, 17 Apr 2017 15:48:33 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CD05D126B6D for ; Mon, 17 Apr 2017 15:48:33 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 323821E1DA; Mon, 17 Apr 2017 18:55:40 -0400 (EDT) Date: Mon, 17 Apr 2017 18:55:40 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Adoption call for draft-tanmir-rtgwg-bfd-mc-lag-* (ends April 30, 2017) Message-ID: <20170417225539.GE18219@pfrc.org> 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: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 22:48:35 -0000 Working Group, https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-ip-00 https://datatracker.ietf.org/doc/draft-tanmir-rtgwg-bfd-mc-lag-mpls/ The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for IP and MPLS have requested BFD working group adoption for their drafts. These drafts were previously presented at IETF-96. Please note that IPR has been declare against these drafts. The IPR declaration may be found from the datatracker links. Please indicate your support/lack of support to the mailing list. -- Jeff and Reshad From nobody Mon Apr 17 15:48:49 2017 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F410F13166B; Mon, 17 Apr 2017 15:48:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , Subject: The BFD WG has placed draft-tanmir-rtgwg-bfd-mc-lag-mpls in state "Call For Adoption By WG Issued" X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149246932799.17692.4203757488371172944.idtracker@ietfa.amsl.com> Date: Mon, 17 Apr 2017 15:48:47 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 22:48:48 -0000 The BFD WG has placed draft-tanmir-rtgwg-bfd-mc-lag-mpls in state Call For Adoption By WG Issued (entered by Jeffrey Haas) The document is available at https://datatracker.ietf.org/doc/draft-tanmir-rtgwg-bfd-mc-lag-mpls/ From nobody Mon Apr 17 15:49:28 2017 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 094F41315F0; Mon, 17 Apr 2017 15:49:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , Subject: The BFD WG has placed draft-tanmir-rtgwg-bfd-mc-lag-ip in state "Call For Adoption By WG Issued" X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149246936703.17688.4898133860175934211.idtracker@ietfa.amsl.com> Date: Mon, 17 Apr 2017 15:49:27 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 22:49:27 -0000 The BFD WG has placed draft-tanmir-rtgwg-bfd-mc-lag-ip in state Call For Adoption By WG Issued (entered by Jeffrey Haas) The document is available at https://datatracker.ietf.org/doc/draft-tanmir-rtgwg-bfd-mc-lag-ip/ From nobody Mon Apr 17 16:37:29 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B982129416 for ; Mon, 17 Apr 2017 16:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Uh16x6f0Uf2Y for ; Mon, 17 Apr 2017 16:37:26 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C24124D68 for ; Mon, 17 Apr 2017 16:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1730; q=dns/txt; s=iport; t=1492472246; x=1493681846; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3KDC/ZhItppzaPv7thSCcvklJdHv3lJrjCEElMLU2oc=; b=GoUPNOluHPa3rnf0YAbVUjbiP4Fx5raUAlY33cHnv+GXJozvh4o0kSXp k74i+6Pr1m5nBeRfFsysfVfaIqpDf+F93pENn0bktLkwHyBD1L+x6OB/m AmB/381gvaROm9XupP2uI3g7RB0+6nVlqxYGo/44kVj3oIO4DlNVZ449n 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAgBWUfVY/4cNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1OBbAeDX4oVkT4hlV+CD4YkAhqDaj8YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQECAR0GEToLBQsCAQgOCgICJgICAjAVEAIEDgUbiXQIqxGCJoshAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYELhUeCCAqCY4E8gxuDBi6CMQWWMoZpAZJkgX+FMIo?= =?us-ascii?q?XlAkBHziBBWMVRBEBhGApgUp1iA6BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,217,1488844800"; d="scan'208";a="231924095" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Apr 2017 23:37:25 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v3HNbObo014526 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Apr 2017 23:37:25 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Apr 2017 19:37:24 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Mon, 17 Apr 2017 19:37:24 -0400 From: "Carlos Pignataro (cpignata)" To: Jeff Haas CC: "rtg-bfd@ietf.org" , "Reshad Rahman (rrahman)" , "Sonal Agarwal (agarwaso)" Subject: Re: Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017) Thread-Topic: Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017) Thread-Index: AQHSt8GTnRQLvxEyAUuhxNZeNM1CJaHKequA Date: Mon, 17 Apr 2017 23:37:24 +0000 Message-ID: <96131342-6E92-49B7-A14F-179F1D696E55@cisco.com> References: <20170417213533.GB18219@pfrc.org> In-Reply-To: <20170417213533.GB18219@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.233.250] Content-Type: text/plain; charset="utf-8" Content-ID: <782601522579A947806A91F1A0E0C3D6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 23:37:27 -0000 SmVmZiBhbmQgUmVzaGFkLA0KDQpZZXMsIEkgc3VwcG9ydCBCRkQgV0cgYWRvcHRpb24gb2YgZHJh ZnQtc29uYWwtYmZkLXNlY3VyZS1zZXF1ZW5jZS1udW1iZXJzLTAwLg0KDQpUaGFua3MhDQoNCuKA lCBDYXJsb3MuDQoNCg0KPiBPbiBBcHIgMTcsIDIwMTcsIGF0IDU6MzUgUE0sIEplZmZyZXkgSGFh cyA8amhhYXNAcGZyYy5vcmc+IHdyb3RlOg0KPiANCj4gV29ya2luZyBHcm91cCwNCj4gDQo+IEFz IHBhcnQgb2Ygb3VyIGRpc2N1c3Npb24gYXQgdGhlIFdvcmtpbmcgR3JvdXAgc2Vzc2lvbiBhdCBJ RVRGIDk4IGluDQo+IENoaWNhZ28sIFNvbmFsIEFnYXJ3YWwgcHJlc2VudGVkICJTZWN1cmUgQkZE IFNlcXVlbmNlIE51bWJlcnMiDQo+IChkcmFmdC1zb25hbC1iZmQtc2VjdXJlLXNlcXVlbmNlLW51 bWJlcnMtMDApLiAgVGhpcyB3b3JrIGNvbXBsZW1lbnRzIGENCj4gcHJvYmxlbSBzcGFjZSB0aGUg U2VjdXJpdHkgYXJlYSBoYWQgYXNrZWQgdXMgdG8gYWRkcmVzcyBhcyBwYXJ0IG9mIHRoZSB3b3Jr DQo+IG9uIG9wdGltaXppbmcgQkZEIGF1dGhlbnRpY2F0aW9uLCBvdXIgYWRvcHRlZA0KPiBkcmFm dC1pZXRmLWJmZC1vcHRpbWl6aW5nLWF1dGhlbnRpY2F0aW9uLg0KPiANCj4gVGhlIGRpc2N1c3Np b24gb24gdGhlIGltcGxlbWVudGF0aW9uIGltcGxpY3Rpb25zIG9mIHRoZSBvcHRpbWl6aW5nDQo+ IGF1dGhlbnRpY2F0aW9uIGRyYWZ0IHdhcyBlbmVyZ2V0aWMgdGhpcyBsYXN0IElFVEYuICBUbyBk cml2ZSB0aGF0IHNvbHV0aW9uDQo+IGZ1cnRoZXIgYWxvbmcsIHdlIHdpbGwgbmVlZCBhIHRlY2hu b2xvZ3kgc2ltaWxhciB0byB0aGUgb25lIGluIHRoZSBwcm9wb3NhbC4NCj4gDQo+IFRoaXMgc3Rh cnRzIGEgMiB3ZWVrIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXNvbmFsLWJmZC1zZWN1cmUtc2Vx dWVuY2UtbnVtYmVycy4NCj4gUGxlYXNlIGluZGljYXRlIHlvdXIgc3VwcG9ydCBvciBsYWNrIG9m IHN1cHBvcnQgZm9yIHRoZSBwcm9wb3NhbCB0byB0aGUNCj4gbWFpbGluZyBsaXN0Lg0KPiANCj4g Tm90ZSB0aGF0IHBhcnQgb2YgdGhlIGRpc2N1c3Npb24gd2FzIHRoYXQgb3B0aW1pemluZyBCRkQg aXMgbm90IHJlYWR5IHRvDQo+IHByb2NlZWQgdG8gTGFzdCBDQWxsIHVudGlsIHdlJ3ZlIGFkb3B0 ZWQgc3VjaCBhIHByb3Bvc2FsIGFuZCBoYXZlDQo+IHByb3Blcmx5IGludGVncmF0ZWQgaXQgaW50 byB0aGUgb3B0aW1pemF0aW9uIHByb2NlZHVyZXMuDQo+IA0KPiAtLSBKZWZmIGFuZCBSZXNoYWQN Cj4gDQoNCg== From nobody Mon Apr 17 16:37:47 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F49124D68 for ; Mon, 17 Apr 2017 16:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ReYCXamJbHdG for ; Mon, 17 Apr 2017 16:37:43 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24E012944C for ; Mon, 17 Apr 2017 16:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=736; q=dns/txt; s=iport; t=1492472263; x=1493681863; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=n5awlz5yL8XU8JubNojAMJM2/PDciv0bexBLGskhWKI=; b=YxMVUGTYht9lSwcEhQfOjywfWue82MV4/fQ25wT40r+fA72umAChROYn G8OSQ7nYk3nZsGEC+vnz5JsbnuxNJwGYARXyVE2IUF4Qsi99y5P94y5ow dQYnfxuJz/hAGUIU+rjHBqCxXgBzj42gvUcAGirIYwc1pvngMJaWF2nIQ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAgDaUPVY/5tdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHg1+KFZE+IZVfgg8shXgCGoNqPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBHQYROgsFCwIBCA4KAgImAgICMBUQAgQOBYoPCA6rAIImiyEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYELhUeCCAqCY4E8hiEugjEFnRsBhwOLYYFnGIU?= =?us-ascii?q?wiheUCQEfOIEFYxVEEQGEYIFzdYgOgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,217,1488844800"; d="scan'208";a="237687195" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2017 23:37:42 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v3HNbg6D024222 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Apr 2017 23:37:42 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Apr 2017 19:37:42 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Mon, 17 Apr 2017 19:37:41 -0400 From: "Carlos Pignataro (cpignata)" To: Jeff Haas CC: "rtg-bfd@ietf.org" Subject: Re: Adoption call for draft-ashesh-bfd-stability (ends April 30, 2017) Thread-Topic: Adoption call for draft-ashesh-bfd-stability (ends April 30, 2017) Thread-Index: AQHSt8IqfreeVuZheEmChGc12IHuJaHKer+A Date: Mon, 17 Apr 2017 23:37:41 +0000 Message-ID: References: <20170417213947.GC18219@pfrc.org> In-Reply-To: <20170417213947.GC18219@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.233.250] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 23:37:45 -0000 SmVmZiBhbmQgUmVzaGFkLA0KDQpZZXMuIEkgc3VwcG9ydCBhZG9wdGlvbiBvZiBkcmFmdC1hc2hl c2gtYmZkLXN0YWJpbGl0eS0wNS4NCg0KQmVzdCwNCg0K4oCUIENhcmxvcy4NCg0KPiBPbiBBcHIg MTcsIDIwMTcsIGF0IDU6MzkgUE0sIEplZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5vcmc+IHdyb3Rl Og0KPiANCj4gV29ya2luZyBHcm91cCwNCj4gDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1hc2hlc2gtYmZkLXN0YWJpbGl0eS0wNQ0KPiANCj4gVGhlIGF1dGhvcnMgb2YgQkZE IFN0YWJpbGl0eSAoZHJhZnQtYXNoZXNoLWJmZC1zdGFiaWxpdHkpLCBwcmVzZW50ZWQgdGhlaXIN Cj4gbGF0ZXN0IGNoYW5nZXMgYXQgSUVURiA5OCBpbiBDaGljYWdvIGFuZCBoYXZlIHJlcXVlc3Rl ZCB3b3JraW5nIGdyb3VwDQo+IGFkb3B0aW9uLg0KPiANCj4gUGxlYXNlIGluZGljYXRlIHlvdXIg c3VwcG9ydCBvciBsYWNrIG9mIHN1cHBvcnQgdG8gdGhlIG1haWxpbmcgbGlzdC4NCj4gDQo+IC0t IEplZmYgYW5kIFJlc2hhZA0KPiANCg0K From nobody Mon Apr 17 16:39:49 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8EA129462 for ; Mon, 17 Apr 2017 16:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 v88G8YYFdx-a for ; Mon, 17 Apr 2017 16:39:45 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D0C1242F7 for ; Mon, 17 Apr 2017 16:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11212; q=dns/txt; s=iport; t=1492472385; x=1493681985; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wsQXwrwL1BYf07QZohACq1Rho6k4fM5PUYE1uxkzF/g=; b=loLnDKiiQdB3feYBhVMm1iuRtMZq9p0WD8LRA9NEAl9clC89ime3adFg gJszDuAiPzoBHPDoFDiMiWWQTE6lT/gWErEbedPAOBpS0IMvF6N5M2yW4 1Icq4DD/qb67nL7GNtXDJ5Ow3vLLjoXouS8aTdt2doZ3feUn4zzMh95fJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DDAgAXUfVY/4ENJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHg1+KFZE+kEyFNIIPLoV2AhqDaj8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFgYdBksLEAIBCA4xAwICAjAUEQIEDgUbiXwOAqp+giaLIQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFhlKBXSsKgmOBPIJtEAIBgyEugjEFnRsBhwOLYYF/hTCKF5Q?= =?us-ascii?q?JAR84fQhjFUQRAYRUDBCBY3WIDoENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,217,1488844800"; d="scan'208,217";a="232229519" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Apr 2017 23:39:44 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v3HNdh2m016851 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Apr 2017 23:39:44 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Apr 2017 19:39:43 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Mon, 17 Apr 2017 19:39:43 -0400 From: "Carlos Pignataro (cpignata)" To: Jeff Haas CC: "rtg-bfd@ietf.org" Subject: Re: Adoption call for draft-tanmir-rtgwg-bfd-mc-lag-* (ends April 30, 2017) Thread-Topic: Adoption call for draft-tanmir-rtgwg-bfd-mc-lag-* (ends April 30, 2017) Thread-Index: AQHSt8zDNKRTrWqs+kOJ3Tq8NFHE3qHKezoA Date: Mon, 17 Apr 2017 23:39:43 +0000 Message-ID: References: <20170417225539.GE18219@pfrc.org> In-Reply-To: <20170417225539.GE18219@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.233.250] Content-Type: multipart/alternative; boundary="_000_B14F6006540C459091DF4F434F571AC2ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 23:39:47 -0000 --_000_B14F6006540C459091DF4F434F571AC2ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmVmZiBhbmQgUmVzaGFkLA0KDQpJIGRvIG5vdCBzdXBwb3J0IGFkb3B0aW9uIG9mIGVpdGhlciBk cmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1pcC0wMSBvciBkcmFmdC10YW5taXItcnRnd2ct YmZkLW1jLWxhZy1tcGxzLTAxLg0KDQpUaGUgb3ZlcmFsbCBwcm9ibGVtIGFuZCBwcm9wb3NlZCBz b2x1dGlvbiBkaWQgbm90IHNlZW0gdG8gaGF2ZSByZWNlaXZlZCBtdWNoIGRpc2N1c3Npb24uIEkg d2FzIG9ubHkgYWJsZSB0byBmaW5kIG9uZSBlbWFpbCB0aHJlYWQgb24gdGhlIGxpc3QsIG92ZXIg YSB5ZWFyIGFnby4NCg0KUmVnYXJkaW5nIHRoZSBwcm9ibGVtIHN0YXRlbWVudCwgaXTigJlzIHN0 cmFuZ2UgdGhhdCB0aGVyZeKAmXMgbm8gbm9ybWF0aXZlIGRlZmluaXRpb24gb3IgYW55dGhpbmcg dG8gTUctTEFH4oCmIGZ1cnRoZXIsIHRoZSBtZWV0aW5nIG5vdGVzIGZyb20gSUVURjk2IHNheSB0 aGluZ3MgbGlrZToNCiAgICAgICAgICBKb2huIE1lc3NlbmdlcjogV291bGQgc3VnZ2VzdCB3b3Jr IGRvbmUgaW4gODAyLjEgdG8gYW5hbHl6ZSB0aG9zZQ0KICAgICAgICAgIGNvbnNpZGVyYXRpb25z IHdpdGggODAyLCBpdCB3b3VsZCBiZSBuZWNlc3NhcnkgdG8gY29vcmRpbmF0ZSB0byB3b3JrDQog ICAgICAgICAgd2l0aCB0aGVtLiBTZW5kIGEgbWFpbCB0byBJRVRGLUlFRUU4MDIgY29vcmRpbmF0 aW9uIGdyb3VwLg0KICAgICAgICAgIEplZmYgSGFhczogQ2FuIHdlIHNpZ24geW91IGFzIGEgcmV2 aWV3ZXIgdG8gdGhpcyBkcmFmdD8NCg0KV2hhdCBpcyB0aGUgcHJvYmxlbSBhZ2FpbiwgYmV5b25k IHdoYXTigJlzIGFscmVhZHkgd2VsbCBzcGVjaWZpZWQgaW4gUkZDIDcxMzA/IElzIHRoaXMgYWdh aW4gYSBxdWljayDigJxzb2x1dGlvbuKAnSBsb29raW5nIGZvciBhbiBSRkMgbnVtYmVyPw0KDQpS ZWdhcmRpbmcgdGhlIHByb3Bvc2VkIHNvbHV0aW9uLCB0aGUgb25lIGVtYWlsIHRocmVhZCBzZWVt cyB0byBoYXZlIHBvaW50ZWQgb3V0IHNvbWUgc2VyaW91cyBpc3N1ZXMgbm90IGNvbnNpZGVyZWQ6 DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3J0Zy1iZmQvT0xXTENmNmRu LTN6eEdaYm9US1ZxVXdTcjZ3DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L3J0Zy1iZmQvbndmTGZ1ZERkTnc3UHlKYnBQLVJWblZGTWNRDQpodHRwczovL21haWxhcmNoaXZl LmlldGYub3JnL2FyY2gvbXNnL3J0Zy1iZmQvRXVST2JrbzBKTzQwXzRVUEI0YnVSMGl5eGNnDQpo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3J0Zy1iZmQvUVViNXJqODgyVEtl QUFYeVRvZjR5Y3EyRFVnDQoNCkFkZGl0aW9uYWxseSwgd2h5IHRoZSBzcGxpdCBpbnRvIHR3byBk cmFmdHMgZm9yIHRoaXM/IFRoZSB0ZXh0IG9mIGJvdGggZG9jdW1lbnRzIG92ZXJhbGwgc2VlbXMg Zm9yZ290dGVuLCBldmVuIHNsb3BweSwgd2l0aCBtYW55IHR5cG9zICjigJxNUFNM4oCdLCDigJxJ bmR2aWR1YWzigJ0sIGV0YyksIGFuZCBjb3B5L3Bhc3RlIHRleHQgYmV0d2VlbiB0aGUgdHdvIGRv Y3VtZW50cy4gVGhlIGNvbXBsZXRlIEludHJvZHVjdGlvbiBhbmQgUHJvYmxlbSBTdGF0ZW1lbnQg YXJlIHZlcmJhdGltIGNvcHkvcGFzdGUsIGFuZCBpbmNsdWRlIHRoaW5ncyBsaWtlOg0KDQogIFRo aXMgZG9jdW1lbnQNCiAgIHByb3Bvc2VzIGhvdyB0byBvdmVyY29tZSB0aGlzIHByb2JsZW0gaWYg dXNpbmcgSVAgb3IgTXVsdGktUHJvdG9jb2wNCiAgIExhYmVsIFN3aXRjaGluZyAoTVBMUykgZGF0 YSBwbGFuZSBlbmNhcHN1bGF0aW9uLg0KDQp3aGljaCBpcyBub3QgdGhlIGNhc2UgZm9yIGVpdGhl ciBkb2N1bWVudC4NCg0KVGVjaG5pY2FsbHksIHVzaW5nIG11bHRpY2FzdCBoZXJlIGV4ZXJjaXNl cyBhIGRpZmZlcmVudCBwYXRoLCBhbmQgdXNpbmcgYSBHQUwgZG9lcyBhcyB3ZWxsLiBXaGF0IGFy ZSB3ZSB0ZXN0aW5nPw0KDQpOZXQtbmV0LCBkbyBub3Qgc3VwcG9ydC4NCg0KVGhhbmtzLA0KDQri gJQgQ2FybG9zLg0KDQpPbiBBcHIgMTcsIDIwMTcsIGF0IDY6NTUgUE0sIEplZmZyZXkgSGFhcyA8 amhhYXNAcGZyYy5vcmc8bWFpbHRvOmpoYWFzQHBmcmMub3JnPj4gd3JvdGU6DQoNCldvcmtpbmcg R3JvdXAsDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10YW5taXItcnRnd2ct YmZkLW1jLWxhZy1pcC0wMA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt dGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctbXBscy8NCg0KVGhlIGF1dGhvcnMgb2YgQkZEIG9uIE11 bHRpLUNoYXNzIExpbmsgQWdncmVnYXRpb24gR3JvdXAgSW50ZXJmYWNlcyBmb3IgSVANCmFuZCBN UExTIGhhdmUgcmVxdWVzdGVkIEJGRCB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIGZvciB0aGVpciBk cmFmdHMuDQoNClRoZXNlIGRyYWZ0cyB3ZXJlIHByZXZpb3VzbHkgcHJlc2VudGVkIGF0IElFVEYt OTYuDQoNClBsZWFzZSBub3RlIHRoYXQgSVBSIGhhcyBiZWVuIGRlY2xhcmUgYWdhaW5zdCB0aGVz ZSBkcmFmdHMuICBUaGUgSVBSDQpkZWNsYXJhdGlvbiBtYXkgYmUgZm91bmQgZnJvbSB0aGUgZGF0 YXRyYWNrZXIgbGlua3MuDQoNClBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQvbGFjayBvZiBz dXBwb3J0IHRvIHRoZSBtYWlsaW5nIGxpc3QuDQoNCi0tIEplZmYgYW5kIFJlc2hhZA0KDQoNCg0K --_000_B14F6006540C459091DF4F434F571AC2ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1522FAABD7262A418DA154D21ECB063F@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSmVmZiBhbmQgUmVzaGFkLA0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBkbyBub3Qg c3VwcG9ydCBhZG9wdGlvbiBvZiBlaXRoZXIgZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWct aXAtMDEgb3IgZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctbXBscy0wMS48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBvdmVy YWxsIHByb2JsZW0gYW5kIHByb3Bvc2VkIHNvbHV0aW9uIGRpZCBub3Qgc2VlbSB0byBoYXZlIHJl Y2VpdmVkIG11Y2ggZGlzY3Vzc2lvbi4gSSB3YXMgb25seSBhYmxlIHRvIGZpbmQgb25lIGVtYWls IHRocmVhZCBvbiB0aGUgbGlzdCwgb3ZlciBhIHllYXIgYWdvLjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UmVnYXJkaW5nIHRoZSBwcm9i bGVtIHN0YXRlbWVudCwgaXTigJlzIHN0cmFuZ2UgdGhhdCB0aGVyZeKAmXMgbm8gbm9ybWF0aXZl IGRlZmluaXRpb24gb3IgYW55dGhpbmcgdG8gTUctTEFH4oCmIGZ1cnRoZXIsIHRoZSBtZWV0aW5n IG5vdGVzIGZyb20gSUVURjk2IHNheSB0aGluZ3MgbGlrZTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSm9obiBN ZXNzZW5nZXI6IFdvdWxkIHN1Z2dlc3Qgd29yayBkb25lIGluIDgwMi4xIHRvIGFuYWx5emUgdGhv c2U8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBjb25zaWRlcmF0aW9ucyB3aXRoIDgwMiwgaXQgd291bGQgYmUgbmVjZXNzYXJ5IHRvIGNvb3Jk aW5hdGUgdG8gd29yazwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHdpdGggdGhlbS4gU2VuZCBhIG1haWwgdG8gSUVURi1JRUVFODAyIGNvb3Jk aW5hdGlvbiBncm91cC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBKZWZmIEhhYXM6IENhbiB3ZSBzaWduIHlvdSBhcyBhIHJldmlld2VyIHRv IHRoaXMgZHJhZnQ/PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldoYXQgaXMgdGhlIHByb2JsZW0gYWdhaW4sIGJleW9uZCB3 aGF04oCZcyBhbHJlYWR5IHdlbGwgc3BlY2lmaWVkIGluIFJGQyA3MTMwPyBJcyB0aGlzIGFnYWlu IGEgcXVpY2sg4oCcc29sdXRpb27igJ0gbG9va2luZyBmb3IgYW4gUkZDIG51bWJlcj88L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJlZ2Fy ZGluZyB0aGUgcHJvcG9zZWQgc29sdXRpb24sIHRoZSBvbmUgZW1haWwgdGhyZWFkIHNlZW1zIHRv IGhhdmUgcG9pbnRlZCBvdXQgc29tZSBzZXJpb3VzIGlzc3VlcyBub3QgY29uc2lkZXJlZDo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hp dGUtc3BhY2U6IHByZTsiPjwvc3Bhbj48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL3J0Zy1iZmQvT0xXTENmNmRuLTN6eEdaYm9US1ZxVXdTcjZ3IiBjbGFzcz0i Ij5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3J0Zy1iZmQvT0xXTENmNmRu LTN6eEdaYm9US1ZxVXdTcjZ3PC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0i QXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTogcHJlOyI+PC9zcGFuPjxhIGhyZWY9 Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvcnRnLWJmZC9ud2ZMZnVkRGRO dzdQeUpicFAtUlZuVkZNY1EiIGNsYXNzPSIiPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvcnRnLWJmZC9ud2ZMZnVkRGROdzdQeUpicFAtUlZuVkZNY1E8L2E+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNw YWNlOiBwcmU7Ij48L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9h cmNoL21zZy9ydGctYmZkL0V1Uk9ia28wSk80MF80VVBCNGJ1UjBpeXhjZyIgY2xhc3M9IiI+aHR0 cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9ydGctYmZkL0V1Uk9ia28wSk80MF80 VVBCNGJ1UjBpeXhjZzwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxl LXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6IHByZTsiPjwvc3Bhbj48YSBocmVmPSJodHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3J0Zy1iZmQvUVViNXJqODgyVEtlQUFY eVRvZjR5Y3EyRFVnIiBjbGFzcz0iIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv bXNnL3J0Zy1iZmQvUVViNXJqODgyVEtlQUFYeVRvZjR5Y3EyRFVnPC9hPjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QWRkaXRpb25hbGx5 LCB3aHkgdGhlIHNwbGl0IGludG8gdHdvIGRyYWZ0cyBmb3IgdGhpcz8gVGhlIHRleHQgb2YgYm90 aCBkb2N1bWVudHMgb3ZlcmFsbCBzZWVtcyBmb3Jnb3R0ZW4sIGV2ZW4gc2xvcHB5LCB3aXRoIG1h bnkgdHlwb3MgKOKAnE1QU0zigJ0sIOKAnEluZHZpZHVhbOKAnSwgZXRjKSwgYW5kIGNvcHkvcGFz dGUgdGV4dCBiZXR3ZWVuIHRoZSB0d28gZG9jdW1lbnRzLiBUaGUgY29tcGxldGUgSW50cm9kdWN0 aW9uIGFuZCBQcm9ibGVtDQogU3RhdGVtZW50IGFyZSB2ZXJiYXRpbSBjb3B5L3Bhc3RlLCBhbmQg aW5jbHVkZSB0aGluZ3MgbGlrZTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgVGhpcyBkb2N1bWVu dDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7cHJvcG9zZXMgaG93IHRvIG92ZXJj b21lIHRoaXMgcHJvYmxlbSBpZiB1c2luZyBJUCBvciBNdWx0aS1Qcm90b2NvbDwvZGl2Pg0KPGRp diBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7TGFiZWwgU3dpdGNoaW5nIChNUExTKSBkYXRhIHBsYW5l IGVuY2Fwc3VsYXRpb24uPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPndoaWNoIGlzIG5vdCB0aGUgY2FzZSBmb3IgZWl0aGVy IGRvY3VtZW50LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+VGVjaG5pY2FsbHksIHVzaW5nIG11bHRpY2FzdCBoZXJlIGV4ZXJjaXNlcyBh IGRpZmZlcmVudCBwYXRoLCBhbmQgdXNpbmcgYSBHQUwgZG9lcyBhcyB3ZWxsLiBXaGF0IGFyZSB3 ZSB0ZXN0aW5nPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+TmV0LW5ldCwgZG8gbm90IHN1cHBvcnQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MsPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJQgQ2FybG9z LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEFwciAxNywgMjAxNywgYXQg Njo1NSBQTSwgSmVmZnJleSBIYWFzICZsdDs8YSBocmVmPSJtYWlsdG86amhhYXNAcGZyYy5vcmci IGNsYXNzPSIiPmpoYWFzQHBmcmMub3JnPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9 IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+V29ya2luZyBHcm91cCw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWct aXAtMDAiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10YW5taXIt cnRnd2ctYmZkLW1jLWxhZy1pcC0wMDwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1t cGxzLyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGFu bWlyLXJ0Z3dnLWJmZC1tYy1sYWctbXBscy88L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KVGhlIGF1dGhvcnMgb2YgQkZEIG9uIE11bHRpLUNoYXNzIExpbmsgQWdncmVnYXRpb24gR3Jv dXAgSW50ZXJmYWNlcyBmb3IgSVA8YnIgY2xhc3M9IiI+DQphbmQgTVBMUyBoYXZlIHJlcXVlc3Rl ZCBCRkQgd29ya2luZyBncm91cCBhZG9wdGlvbiBmb3IgdGhlaXIgZHJhZnRzLjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NClRoZXNlIGRyYWZ0cyB3ZXJlIHByZXZpb3VzbHkgcHJlc2VudGVk IGF0IElFVEYtOTYuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUGxlYXNlIG5vdGUgdGhh dCBJUFIgaGFzIGJlZW4gZGVjbGFyZSBhZ2FpbnN0IHRoZXNlIGRyYWZ0cy4gJm5ic3A7VGhlIElQ UjxiciBjbGFzcz0iIj4NCmRlY2xhcmF0aW9uIG1heSBiZSBmb3VuZCBmcm9tIHRoZSBkYXRhdHJh Y2tlciBsaW5rcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVhc2UgaW5kaWNhdGUg eW91ciBzdXBwb3J0L2xhY2sgb2Ygc3VwcG9ydCB0byB0aGUgbWFpbGluZyBsaXN0LjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCi0tIEplZmYgYW5kIFJlc2hhZDxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B14F6006540C459091DF4F434F571AC2ciscocom_-- From nobody Mon Apr 17 18:08:08 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8C71200C5 for ; Mon, 17 Apr 2017 18:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.709 X-Spam-Level: * X-Spam-Status: No, score=1.709 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 7MqqPc4Qd-iI for ; Mon, 17 Apr 2017 18:08:05 -0700 (PDT) Received: from sonic328-37.consmr.mail.ne1.yahoo.com (sonic328-37.consmr.mail.ne1.yahoo.com [66.163.191.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC93128D44 for ; Mon, 17 Apr 2017 18:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1492477679; bh=3SEJRW3GitfNj8r2HQtiCsZa2nlqPzZ6bUS6q2u9UHg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=DnC9uz62LLMGXuszE8SwMsXi3SsuPjc6EiSV6fP8OipyKXFIJxDx1DSx/JQC10oGwbA5VSVH8dnOVjuxZ6sTmeBDVBbKpKWzCKzIOQG4c0xdouM986Lv60hzXv2jVOUWaXTKG7RS+t0m4jZ5t0yFB9L7u9EYXxmOv1V7f/KwuIpBLK+Hq7UMCOpiYm3ahXWykQFuYbIaSBmRtKAMvRUHtaVMTLSB2cpxUNanlHtjkzLTua0W0T6qxjh1AheX2u85ZwMg8jJ1qbOIw5WKlS7M4BH8PKZ4MDjPkYTP81W4c3QNCQAJDqQ/ghmT78c2/cfSNau7TLLCcalrEnF2gFr0dw== X-YMail-OSG: AmW5Oi4VM1ks7_zfBbAxDLDoQNSvpUPqyszhNQYHrnA9BUb1DTbW7KZypxKA0u4 RRLUxyxk2Hlugy_YSdBnlEPS24fkGvqKolmLALJQJnEULKWqFlWUuT10S2pZ71UdOSOmoGh75hGC 2nkP1EgNGYmMJchqYt6aoSolLqDtzou.9mJ6sLV4DvAQ5kElTpfR8ET0XZ63efITpuyVp7fSOgR9 v7LEELU7THrnhzLRY1kmhgCDSF74BRTlEThSsQHScFQfpWYoTRP3hyow9TeJyyNbIhyrbWqUGitu qTDCBJCAGuLJZ7hZ_gkJf7ZPZ3I.IVImlSYHUSzj8tr59aw6MBDU5nyzEDznfFcVsZj28JgxktzW ZASJsUSJBu0ETYippssFMNQgGjfhoxvWmpj6tgrRJX.nKD95KdJc9a8mHlqMt60DZKFicF5HbDNm WmbRv03qXK8aY.86NFR_puEjqAQeC_iqUCyM0dCexQbDDPtMJ_7_V6j2d7KT1yJexDXyZMK4WAfj FrZxz45CZTI8rDbnTJIHHm3EqohxR3X9ujdjzc4eb9YNwt.gv9vjfhbJJxMaiSvOyhQeCSwMsIJ_ N3dTXWausA0Ota4OHKNNc.aTf6AuANZtLxg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic328.consmr.mail.ne1.yahoo.com with HTTP; Tue, 18 Apr 2017 01:07:59 +0000 Date: Tue, 18 Apr 2017 01:03:58 +0000 (UTC) From: LuHuang Reply-To: LuHuang To: Jeff Haas Cc: "rtg-bfd@ietf.org" Message-ID: <1313153203.2328850.1492477438392@mail.yahoo.com> In-Reply-To: References: <20170417213947.GC18219@pfrc.org> Subject: =?UTF-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_Adoption_call_for_draft-ashesh-?= =?UTF-8?Q?bfd-stability_(ends_April_30,_2017)?= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2328849_1750984206.1492477438390" X-Mailer: WebService/1.1.9408 YahooMailNeo Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 01:08:06 -0000 ------=_Part_2328849_1750984206.1492477438390 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable yes./support In our backbone network we do need this feature.=C2=A0--------------------L= uHuang China Mobile Research Institute Mobile: +86 13810820540 =20 > On Apr 17, 2017, at 5:39 PM, Jeffrey Haas wrote: >=20 > Working Group, >=20 > https://tools.ietf.org/html/draft-ashesh-bfd-stability-05 >=20 > The authors of BFD Stability (draft-ashesh-bfd-stability), presented thei= r > latest changes at IETF 98 in Chicago and have requested working group > adoption. >=20 > Please indicate your support or lack of support to the mailing list. >=20 > -- Jeff and Reshad >=20 =20 ------=_Part_2328849_1750984206.1492477438390 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
yes./su= pport
<= br>
In our backbone network we do ne= ed this feature.
 
--------------------
LuHuang
China Mobile Research Institute
Mobile: +86 13810820540

> On Apr 17, 2017, at 5:39 PM, Jeffrey Ha= as <jhaas@pfrc.org> wrote:
>
> Working Group,
>
> https://tools.ietf.org/html/draft-ashesh-bfd-stability-05
>
> The authors of BFD Stability (draft-= ashesh-bfd-stability), presented their
> latest change= s at IETF 98 in Chicago and have requested working group
= > adoption.
>
> Please indica= te your support or lack of support to the mailing list.
&= gt;
> -- Jeff and Reshad
>



=
------=_Part_2328849_1750984206.1492477438390-- From nobody Mon Apr 17 18:24:21 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BF41275C5 for ; Mon, 17 Apr 2017 18:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.309 X-Spam-Level: X-Spam-Status: No, score=0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 JC0n9QppUGPf for ; Mon, 17 Apr 2017 18:24:19 -0700 (PDT) Received: from sonic311-50.consmr.mail.ne1.yahoo.com (sonic311-50.consmr.mail.ne1.yahoo.com [66.163.188.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F0161200C5 for ; Mon, 17 Apr 2017 18:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1492478658; bh=8pWfht5tIgC6XvceOd640P9hVgZZh5zrvZhBbMAME08=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=AuUDp3F8PlTP0JEMsI7eC66OLC9prqCSH3JLlp+pYN7jpYecbsGgMjKt2zW0x9SbvibzLTlszRKUz48GQB1rgmzaLodcA4vLKmY9ZwK5PzCi4A187cqp1qoTqz/GW6iY81oIFnnZGhguEcB/YOsuxyJOGyiuFvRIHArTURZ8a6P8AZ4fxRlUEV3yEdC0BzyMH3uPKn79Y3UvtyK+hGzA4+yT12b1M+HSnf9lbJMCRg61lYLUMkN7yDCVuaEOwcWNT6K53aSW6nzdeJX7Z1pL4hQfleH/FKoizDRKpo4ZJrLGJPx9Kql7vsCzwoDEJ0ojXe7kstzxPA8EenhBmtBT7A== X-YMail-OSG: SGGMmvEVM1md.VRwoSj3GOOzMsJTmo_RxBLftWw2t7Bx0NQfxvR3SxFtYiK1RFw T3YgaMFkCErbbYh9ayd86Jpxo3Re5zoyKOyUcAgmRxvSSwUawwRC2yr659WiBbVYXb0qbxQk2ytY hD_XcFrFs7eed8V8zvuBa_AWQHT830s877El21Db6mN_6cbK9Sgn3SLtEdzmof6USovdTMvlystJ 0NdyLNpXOdlVEU9sCEbVQmBLJlNzGCnK1QrLTKomizlnotXkEcxkvCNeqOs2eD37ha8z4H6kexhS Sk1kMTVrT92t7QIze_mdnKrs2NG.nddAKf9D4whEJQQVcgUwbs7Aa7chm7ctUm7szpkHI3c71b91 N8nvwiQl91cea8WS3jkgV8hBQnW.nD53CnAQp3h4fkCajegFIN5LIqU53ZUF9V.H.pZhpTQALPMG Sio.jF7bEakN6J2X0nTcenO7jLBu1MQ9vyog8v94ZWSb3FP5xEf3Rhizzow27mRAV271QW_fyyBF 3AHniOJn7mGdLVG_IgQSsMXwS2E7C6rtVn2C38mBd0A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Tue, 18 Apr 2017 01:24:18 +0000 Date: Tue, 18 Apr 2017 01:19:57 +0000 (UTC) From: LuHuang Reply-To: LuHuang To: Jeffrey Haas , "rtg-bfd@ietf.org" Cc: "Reshad Rahman (rrahman)" , "agarwaso@cisco.com" Message-ID: <638481980.2346797.1492478397080@mail.yahoo.com> In-Reply-To: <20170417213533.GB18219@pfrc.org> References: <20170417213533.GB18219@pfrc.org> Subject: =?UTF-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_Adoption_call_for?= =?UTF-8?Q?_draft-sonal-bfd-secu?= =?UTF-8?Q?re-sequence-numbers_(ending_April_30,_2017)?= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2346796_200931300.1492478397079" X-Mailer: WebService/1.1.9408 YahooMailNeo Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 01:24:20 -0000 ------=_Part_2346796_200931300.1492478397079 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes./ support But I think one problem should be considered. If packet loss happens, the s= equence number of received packet won't be the expected number or hash valu= e, which should be distinguished from malicious packet. Thanks.=C2=A0--------------------LuHuang China Mobile Research Institute Mobile: +86 13810820540 =20 Jeffrey Haas =E4=BA=8E 2017=E5=B9=B44=E6=9C=8818=E6=97= =A5, =E6=98=9F=E6=9C=9F=E4=BA=8C, =E4=B8=8A=E5=8D=88 5:28 =E5=86=99=E9=81= =93=EF=BC=9A =20 Working Group, As part of our discussion at the Working Group session at IETF 98 in Chicago, Sonal Agarwal presented "Secure BFD Sequence Numbers" (draft-sonal-bfd-secure-sequence-numbers-00).=C2=A0 This work complements a problem space the Security area had asked us to address as part of the work on optimizing BFD authentication, our adopted draft-ietf-bfd-optimizing-authentication. The discussion on the implementation implictions of the optimizing authentication draft was energetic this last IETF.=C2=A0 To drive that solu= tion further along, we will need a technology similar to the one in the proposal= . This starts a 2 week adoption call for draft-sonal-bfd-secure-sequence-numb= ers. Please indicate your support or lack of support for the proposal to the mailing list. Note that part of the discussion was that optimizing BFD is not ready to proceed to Last CAll until we've adopted such a proposal and have properly integrated it into the optimization procedures. -- Jeff and Reshad =20 ------=_Part_2346796_200931300.1492478397079 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes./ s= upport
=
But I th= ink one problem should be considered. If packet loss happens, the sequence = number of received packet won't be the expected number or hash value, which= should be distinguished from malicious packet.

Thanks.
 
--------------------
LuH= uang
China Mobile Research Institute
Mobile: +86 13810820540


Jeffrey Haas <jhaas@pfrc.org> =E4=BA=8E 2017= =E5=B9=B44=E6=9C=8818=E6=97=A5, =E6=98=9F=E6=9C=9F=E4=BA=8C, =E4=B8=8A=E5= =8D=88 5:28 =E5=86=99=E9=81=93=EF=BC=9A


Working= Group,

As part of our discussion at the Working Group session at IE= TF 98 in
Chicago, Sonal Agarwal presented "Secure BFD Sequence Numbers"<= br>(draft-sonal-bfd-secure-sequence-numbers-00).  This work complement= s a
problem space the Security area had asked us to address as part of t= he work
on optimizing BFD authentication, our adopted
draft-ietf-bfd-= optimizing-authentication.

The discussion on the implementation impl= ictions of the optimizing
authentication draft was energetic this last I= ETF.  To drive that solution
further along, we will need a technolo= gy similar to the one in the proposal.

This starts a 2 week adoption= call for draft-sonal-bfd-secure-sequence-numbers.
Please indicate your = support or lack of support for the proposal to the
mailing list.

= Note that part of the discussion was that optimizing BFD is not ready toproceed to Last CAll until we've adopted such a proposal and have
prope= rly integrated it into the optimization procedures.

-- Jeff and Resh= ad



------=_Part_2346796_200931300.1492478397079-- From nobody Mon Apr 17 18:37:35 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14FF1200C5 for ; Mon, 17 Apr 2017 18:37: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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 U1bKb_mrNXtE for ; Mon, 17 Apr 2017 18:37:33 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCC7129412 for ; Mon, 17 Apr 2017 18:37:29 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id x184so73250380oia.1 for ; Mon, 17 Apr 2017 18:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VUx+9TcybTltm3JcFp9eDeyaeuFpKflRcNeyZ7UX4yc=; b=bjXZqoj+YrLnM8V1mRC0JMsXgfzTO0L+a5hcmcIpmgs+HGzQVZ0+ShZgqmUaWBjXji 8ezRDlsRFQVO3LjH3NI9rMklh2hkRKlut5s8nBy1bgBg6JIMDLK0orIJdL9HtKO4GqH2 KCXWGfUVhaYD//6hTUCvBTV2BxqjgfgUEt6JGhUWdMnnJZ8JbCdxg+bJ6kwgFyD/4C65 X0XhytQuKNcxmUHh9hncmUSYQ4vQRZvhkqvKSHeDEpPVm0r4NkytRyR2vrreglU/cWuO w1O7wv4ZsjSe0hgrJXAv3CdLw6L9Ei4+dPgnmNKaX8yRgrc+SQSu6PAesp4YAQM2wqz+ +k+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VUx+9TcybTltm3JcFp9eDeyaeuFpKflRcNeyZ7UX4yc=; b=SaMEAbqja22k1fYBeO70aSQoRiPE07POd8v3Ge+a7u4MpSuyBcV+3LPon5jP7DiTgM gfAVIFLop+oEwq4+0fn2I2swqx43dmakMpR88bqqG9uMywhHDDucnzNwtY58H6k0L+bk UYaqtK9wqo4TsWtwjM4ffUrlveLjbXJIggJuDZ2VWCpt6T+Ow6q8jiMhRpZxRBjeNTTn sY9nxBkGby3ELgoDHYlXDvdfQT5n2mKI1JaWrdIG54BwwYqWZqWiQ6wY5mxBwoKyJvJr CSV8Z4aUOPe1Ofr5c3zXf1dOXZLmRW52ZIevyJcOqbI7ChRU0xc18zVOVB3IrjXLMiEs yNAg== X-Gm-Message-State: AN3rC/68v7jAypYpSluTqDwOm1MO50pSZ3bZeKUv//OAnDFjc+HHLYiO Kvv7dYae/K969Jb4NITrPiCtfvuyaw== X-Received: by 10.157.43.88 with SMTP id f24mr7473239otd.25.1492479448948; Mon, 17 Apr 2017 18:37:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.56.45 with HTTP; Mon, 17 Apr 2017 18:37:28 -0700 (PDT) Received: by 10.157.56.45 with HTTP; Mon, 17 Apr 2017 18:37:28 -0700 (PDT) In-Reply-To: <20170417213947.GC18219@pfrc.org> References: <20170417213947.GC18219@pfrc.org> From: Manav Bhatia Date: Tue, 18 Apr 2017 07:07:28 +0530 Message-ID: Subject: Re: Adoption call for draft-ashesh-bfd-stability (ends April 30, 2017) To: Jeffrey Haas Cc: rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=001a113d1da463a69c054d66f357 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 01:37:35 -0000 --001a113d1da463a69c054d66f357 Content-Type: text/plain; charset=UTF-8 Support -- Sent from a mobile device On Apr 18, 2017 3:02 AM, "Jeffrey Haas" wrote: > Working Group, > > https://tools.ietf.org/html/draft-ashesh-bfd-stability-05 > > The authors of BFD Stability (draft-ashesh-bfd-stability), presented their > latest changes at IETF 98 in Chicago and have requested working group > adoption. > > Please indicate your support or lack of support to the mailing list. > > -- Jeff and Reshad > > --001a113d1da463a69c054d66f357 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support

--=
Sent from a mobile device

On Apr 18, 2017 3:02 AM, "Jeffrey Haas" = <jhaas@pfrc.org> wrote:
Working Group,

https://tools.ietf.org/html/draft-as= hesh-bfd-stability-05

The authors of BFD Stability (draft-ashesh-bfd-stability), presented their<= br> latest changes at IETF 98 in Chicago and have requested working group
adoption.

Please indicate your support or lack of support to the mailing list.

-- Jeff and Reshad

--001a113d1da463a69c054d66f357-- From nobody Mon Apr 17 18:42:20 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2744D128D44 for ; Mon, 17 Apr 2017 18:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TrJat_4o-vm1 for ; Mon, 17 Apr 2017 18:42:17 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0DA8128616 for ; Mon, 17 Apr 2017 18:42:16 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id b187so161272912oif.0 for ; Mon, 17 Apr 2017 18:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=shLiURy9pg4JnlBq+VKYozmStqRUED2GfNv3kA3cnJw=; b=QW/DD24Umh9Nv8iPNYYynftdQNLobWFuSNdrWMvGx+hQSIEXN1c7MtIcRrLDHXd7Hy uC9igniBxfewEdNZb6TR8RoAI9XRBEsNNoHiVq+Gt6/FWUNWaapqEQhH8EyJpG/UiJpK G9eJklJao0EsG++LQJ/wUyKHw+ApyV8Ea5jis1ML2sUQtKFL5+iJwVqi4iFA2rYacQz6 /cBRsxdE0mgBxiACFiEx9p/AcL450BRg6HB8yvPCyQ41knTgWCu/ENV1UDN1jyb+l1j9 LaoOEp1USTUZV/LWjdWuVhU/QG+gt2VHptSAt+oNXkR54e6hRX9cx9DqElP3nxpjVnDs WOLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=shLiURy9pg4JnlBq+VKYozmStqRUED2GfNv3kA3cnJw=; b=EvSRfIQqUVeZVMEZhW77k5kfEjChofyJGYuyddLIgqISf+oOsVTer3mEbKfg32+Xmd 1GDn4uJCtJH59buI5UnAMzWpODGcuSEQSFZbnxUf+iSiRsuMyyBpibFdBiow17xboe3Y k5VFEUnHlPPQm7G18ZkTDN7LkVU/BwHb6+QmHBVG7c9+ndEidoo+6p5VXgRLQ2W8pxxK yPQmJt4f5gXoC7e/cx1SZ6fpuM8wrSgQq+/ph1v3vDJ3DY2ZhrK6cC6HsVxG0AnrqTlQ BSGgjpb2DGndk1PpZ1t54Dluw7WaFRjRvbEogfCH+aK+X3d1espGNDEVIbGwpGGlfGMY B+PA== X-Gm-Message-State: AN3rC/5/UvISAFCZJTmpPJ2HZAPmIftFSzpbjBs82Lv7NIOue+dH5/CA Ue50FtF9Tflkpn36uPd2OFRMp6aqRQ== X-Received: by 10.157.42.82 with SMTP id t76mr5967162ota.40.1492479736161; Mon, 17 Apr 2017 18:42:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.56.45 with HTTP; Mon, 17 Apr 2017 18:42:15 -0700 (PDT) Received: by 10.157.56.45 with HTTP; Mon, 17 Apr 2017 18:42:15 -0700 (PDT) In-Reply-To: References: <20170417225539.GE18219@pfrc.org> From: Manav Bhatia Date: Tue, 18 Apr 2017 07:12:15 +0530 Message-ID: Subject: Re: Adoption call for draft-tanmir-rtgwg-bfd-mc-lag-* (ends April 30, 2017) To: "Carlos Pignataro (cpignata)" Cc: Jeffrey Haas , rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=001a113d09de822af2054d670468 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 01:42:19 -0000 --001a113d09de822af2054d670468 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I had raised the exact same concerns when this draft was originally posted. So I concur with what Carlos says. Cheers, Manav -- Sent from a mobile device On Apr 18, 2017 5:09 AM, "Carlos Pignataro (cpignata)" wrote: Jeff and Reshad, I do not support adoption of either draft-tanmir-rtgwg-bfd-mc-lag-ip-01 or draft-tanmir-rtgwg-bfd-mc-lag-mpls-01. The overall problem and proposed solution did not seem to have received much discussion. I was only able to find one email thread on the list, over a year ago. Regarding the problem statement, it=E2=80=99s strange that there=E2=80=99s = no normative definition or anything to MG-LAG=E2=80=A6 further, the meeting notes from I= ETF96 say things like: John Messenger: Would suggest work done in 802.1 to analyze those considerations with 802, it would be necessary to coordinate to work with them. Send a mail to IETF-IEEE802 coordination group. Jeff Haas: Can we sign you as a reviewer to this draft? What is the problem again, beyond what=E2=80=99s already well specified in = RFC 7130? Is this again a quick =E2=80=9Csolution=E2=80=9D looking for an RFC n= umber? Regarding the proposed solution, the one email thread seems to have pointed out some serious issues not considered: https://mailarchive.ietf.org/arch/msg/rtg-bfd/OLWLCf6dn-3zxGZboTKVqUwSr6w https://mailarchive.ietf.org/arch/msg/rtg-bfd/nwfLfudDdNw7PyJbpP-RVnVFMcQ https://mailarchive.ietf.org/arch/msg/rtg-bfd/EuRObko0JO40_4UPB4buR0iyxcg https://mailarchive.ietf.org/arch/msg/rtg-bfd/QUb5rj882TKeAAXyTof4ycq2DUg Additionally, why the split into two drafts for this? The text of both documents overall seems forgotten, even sloppy, with many typos (=E2=80=9CM= PSL=E2=80=9D, =E2=80=9CIndvidual=E2=80=9D, etc), and copy/paste text between the two docu= ments. The complete Introduction and Problem Statement are verbatim copy/paste, and include things like: This document proposes how to overcome this problem if using IP or Multi-Protocol Label Switching (MPLS) data plane encapsulation. which is not the case for either document. Technically, using multicast here exercises a different path, and using a GAL does as well. What are we testing? Net-net, do not support. Thanks, =E2=80=94 Carlos. On Apr 17, 2017, at 6:55 PM, Jeffrey Haas wrote: Working Group, https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-ip-00 https://datatracker.ietf.org/doc/draft-tanmir-rtgwg-bfd-mc-lag-mpls/ The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for IP and MPLS have requested BFD working group adoption for their drafts. These drafts were previously presented at IETF-96. Please note that IPR has been declare against these drafts. The IPR declaration may be found from the datatracker links. Please indicate your support/lack of support to the mailing list. -- Jeff and Reshad --001a113d09de822af2054d670468 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I had raised the exact same concerns when this draft was = originally posted. So I concur with what Carlos says.=C2=A0

Cheers, Manav=C2=A0

--
Sent from a mobile device

On Apr = 18, 2017 5:09 AM, "Carlos Pignataro (cpignata)" <cpignata@cisco.com> wrote:
Jeff and Reshad,

I do not support adoption of either draft-tanmir-rtgwg-bfd-mc-lag-ip-01 or draft-tanmir-rtgwg-bfd-mc-lag-mpls-01.

The overall problem and proposed solution did not seem to have receive= d much discussion. I was only able to find one email thread on the list, ov= er a year ago.

Regarding the problem statement, it=E2=80=99s strange that there=E2=80= =99s no normative definition or anything to MG-LAG=E2=80=A6 further, the me= eting notes from IETF96 say things like:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 John Messenger: Would suggest work = done in 802.1 to analyze those
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 considerations with 802, it would b= e necessary to coordinate to work
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with them. Send a mail to IETF-IEEE= 802 coordination group.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jeff Haas: Can we sign you as a rev= iewer to this draft?

What is the problem again, beyond what=E2=80=99s already well specifie= d in RFC 7130? Is this again a quick =E2=80=9Csolution=E2=80=9D looking for= an RFC number?

Regarding the proposed solution, the one email thread seems to have po= inted out some serious issues not considered:

Additionally, why the split into two drafts for this? The text of both= documents overall seems forgotten, even sloppy, with many typos (=E2=80=9C= MPSL=E2=80=9D, =E2=80=9CIndvidual=E2=80=9D, etc), and copy/paste text betwe= en the two documents. The complete Introduction and Problem Statement are verbatim copy/paste, and include things like:

=C2=A0 This document
=C2=A0 =C2=A0proposes how to overcome this problem if using IP or Mult= i-Protocol
=C2=A0 =C2=A0Label Switching (MPLS) data plane encapsulation.

which is not the case for either document.

Technically, using multicast here exercises a different path, and usin= g a GAL does as well. What are we testing?

Net-net, do not support.

Thanks,

=E2=80=94 Carlos.

On Apr 17, 2017, at 6:55 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:

Working Group,

https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-= mc-lag-ip-00
https://datatracker.ietf.org/doc/draft-tanmir-= rtgwg-bfd-mc-lag-mpls/

The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for IP<= br> and MPLS have requested BFD working group adoption for their drafts.

These drafts were previously presented at IETF-96.

Please note that IPR has been declare against these drafts.=C2=A0 The IPR declaration may be found from the datatracker links.

Please indicate your support/lack of support to the mailing list.

-- Jeff and Reshad




--001a113d09de822af2054d670468-- From nobody Mon Apr 17 20:17:23 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53C112941C for ; Mon, 17 Apr 2017 20:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2qx_1vnVLSKY for ; Mon, 17 Apr 2017 20:17:20 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF911274D2 for ; Mon, 17 Apr 2017 20:17:20 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id j201so10221112oih.2 for ; Mon, 17 Apr 2017 20:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e/4LbPJFmcrehpK9Zqtk5x5wo3IIh+YCUgoWnVoP3Yg=; b=mDLQszrgf/eDgdQnbfdZbzUwXxjs9C8UbNI+kAiNXIlmdLx3XwNYmuuAf/beyY79OJ CvkvyhxJ47ubU+76GaVs3Epkl9Pk521qRMHkgnZNgH5pZXs98wMK1SWlOULcIIxlKoy6 +sduoAH/TzCyo1nnm0h+Bubt2Anx0YxQgIIAEobZH9R5KRDTkplV8pGhOrfiXgIwlRup jCfngwkMaUXWRzkvUIMQ315UKsR9zApREkq8YbHGGpQ60u0ZibFD/3OZeb3ac/AA4HT4 aIxc/1y1axb8WdvTPRG4GZ9sKdRKWOLk6JjxqFLqgHCyNGlh/llErd8cbpinIaF7mqA2 j5dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e/4LbPJFmcrehpK9Zqtk5x5wo3IIh+YCUgoWnVoP3Yg=; b=VS8txEzr8SvgvvpYkxGrhFuhFSliP/Rv06ALovn88qEW2eupSR6fXAXb2UsGmhBsWG 0KCxzxepfYZB9z5v8nz+2HXThdz0h9uyV/gRh8vSs6JnqMRG3aJN457ZlZ3d7Asc+3GS fngGAwi2un1Zgl/9/YWopw3PpqMHBJZ+TnxdfScM3sUqMUblbq4ZDt3eGhe1YyErRSh8 sQOoV4IVKMeYidQcoiUX/dFvm32G8bjD7UFvkKyVE76RvcQnlzgd+uAhKkWpH+xpj3+j fyklFnr4GrkyCupW0utGZriVxZRECw04mLeOkBKvKmpX2dAjrLfIBGGgPXUuZ1f2g/vD vM8A== X-Gm-Message-State: AN3rC/7+JuO2eBEYfDuNdzdfNEoymiZuHcDveicJIeU5ddVXTVeVx9Yl OnOTr9N54vz1MN7F3wZfInvns2MFxA== X-Received: by 10.157.6.78 with SMTP id 72mr6330301otn.37.1492485439917; Mon, 17 Apr 2017 20:17:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.89.225 with HTTP; Mon, 17 Apr 2017 20:17:19 -0700 (PDT) In-Reply-To: References: <20170417225539.GE18219@pfrc.org> From: Greg Mirsky Date: Mon, 17 Apr 2017 20:17:19 -0700 Message-ID: Subject: Re: Adoption call for draft-tanmir-rtgwg-bfd-mc-lag-* (ends April 30, 2017) To: Manav Bhatia Cc: "Carlos Pignataro (cpignata)" , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0925467a92a9054d6858d0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 03:17:23 -0000 --94eb2c0925467a92a9054d6858d0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Manav, single-hop BFD is helpful when the two BFD peers have Layer 2 switched domain between them. If the nodes are connected by the single wire, then there's no apparent benefit of using BFD at all. The same is the case for these two drafts. BFD is not intended to verify whether forwarding tables are correlating with the routing tables but it is to verify that a path exists between the BFD peers. In the case we've considered, the path through the Layer 2 switched domain. Thus I don't see that traversing the same blocks in fast path processing on the end nodes of the single-hop IP link is the critical requirement. But if the working group agrees that it is, then we'll be glad to work together to confirm with such requirement. Regards, Greg On Mon, Apr 17, 2017 at 6:42 PM, Manav Bhatia wrote= : > I had raised the exact same concerns when this draft was originally > posted. So I concur with what Carlos says. > > Cheers, Manav > > -- > Sent from a mobile device > > On Apr 18, 2017 5:09 AM, "Carlos Pignataro (cpignata)" > wrote: > > Jeff and Reshad, > > I do not support adoption of either draft-tanmir-rtgwg-bfd-mc-lag-ip-01 > or draft-tanmir-rtgwg-bfd-mc-lag-mpls-01. > > The overall problem and proposed solution did not seem to have received > much discussion. I was only able to find one email thread on the list, ov= er > a year ago. > > Regarding the problem statement, it=E2=80=99s strange that there=E2=80=99= s no normative > definition or anything to MG-LAG=E2=80=A6 further, the meeting notes from= IETF96 > say things like: > John Messenger: Would suggest work done in 802.1 to analyze tho= se > considerations with 802, it would be necessary to coordinate to > work > with them. Send a mail to IETF-IEEE802 coordination group. > Jeff Haas: Can we sign you as a reviewer to this draft? > > What is the problem again, beyond what=E2=80=99s already well specified i= n RFC > 7130? Is this again a quick =E2=80=9Csolution=E2=80=9D looking for an RFC= number? > > Regarding the proposed solution, the one email thread seems to have > pointed out some serious issues not considered: > https://mailarchive.ietf.org/arch/msg/rtg-bfd/OLWLCf6dn-3zxGZboTKVqUwSr6w > https://mailarchive.ietf.org/arch/msg/rtg-bfd/nwfLfudDdNw7PyJbpP-RVnVFMcQ > https://mailarchive.ietf.org/arch/msg/rtg-bfd/EuRObko0JO40_4UPB4buR0iyxcg > https://mailarchive.ietf.org/arch/msg/rtg-bfd/QUb5rj882TKeAAXyTof4ycq2DUg > > Additionally, why the split into two drafts for this? The text of both > documents overall seems forgotten, even sloppy, with many typos (=E2=80= =9CMPSL=E2=80=9D, > =E2=80=9CIndvidual=E2=80=9D, etc), and copy/paste text between the two do= cuments. The > complete Introduction and Problem Statement are verbatim copy/paste, and > include things like: > > This document > proposes how to overcome this problem if using IP or Multi-Protocol > Label Switching (MPLS) data plane encapsulation. > > which is not the case for either document. > > Technically, using multicast here exercises a different path, and using a > GAL does as well. What are we testing? > > Net-net, do not support. > > Thanks, > > =E2=80=94 Carlos. > > On Apr 17, 2017, at 6:55 PM, Jeffrey Haas wrote: > > Working Group, > > https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-ip-00 > https://datatracker.ietf.org/doc/draft-tanmir-rtgwg-bfd-mc-lag-mpls/ > > The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for I= P > and MPLS have requested BFD working group adoption for their drafts. > > These drafts were previously presented at IETF-96. > > Please note that IPR has been declare against these drafts. The IPR > declaration may be found from the datatracker links. > > Please indicate your support/lack of support to the mailing list. > > -- Jeff and Reshad > > > > > --94eb2c0925467a92a9054d6858d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Manav,
single-hop BFD is helpful when the two BFD p= eers have Layer 2 switched domain between them. If the nodes are connected = by the single wire, then there's no apparent benefit of using BFD at al= l. The same is the case for these two drafts. BFD is not intended to verify= whether forwarding tables are correlating with the routing tables but it i= s to verify that a path exists between the BFD peers. In the case we've= considered, the path through the Layer 2 switched domain. Thus I don't= see that traversing the same blocks in fast path processing on the end nod= es of the single-hop IP link is the critical requirement. But if the workin= g group agrees that it is, then we'll be glad to work together to confi= rm with such requirement.

Regards,
Greg= =C2=A0

On Mon, Apr 17, 2017 at 6:42 PM, Manav Bhatia <manavbhatia@gmail.com<= /a>> wrote:
I= had raised the exact same concerns when this draft was originally posted. = So I concur with what Carlos says.=C2=A0

Cheers, Manav=C2=A0

--
Sent from a mobile device

On Apr 18, 2017 5:09 AM, "Carlos Pignataro (cpignata)&qu= ot; <cpignata@ci= sco.com> wrote:
Jeff and Reshad,

I do not support adoption of either draft-tanmir-rtgwg-bfd-mc-lag-ip-01 or draft-tanmir-rtgwg-bfd-mc-lag-mpls-01.

The overall problem and proposed solution did not seem to have receive= d much discussion. I was only able to find one email thread on the list, ov= er a year ago.

Regarding the problem statement, it=E2=80=99s strange that there=E2=80= =99s no normative definition or anything to MG-LAG=E2=80=A6 further, the me= eting notes from IETF96 say things like:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 John Messenger: Would suggest work = done in 802.1 to analyze those
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 considerations with 802, it would b= e necessary to coordinate to work
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with them. Send a mail to IETF-IEEE= 802 coordination group.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jeff Haas: Can we sign you as a rev= iewer to this draft?

What is the problem again, beyond what=E2=80=99s already well specifie= d in RFC 7130? Is this again a quick =E2=80=9Csolution=E2=80=9D looking for= an RFC number?

Regarding the proposed solution, the one email thread seems to have po= inted out some serious issues not considered:

Additionally, why the split into two drafts for this? The text of both= documents overall seems forgotten, even sloppy, with many typos (=E2=80=9C= MPSL=E2=80=9D, =E2=80=9CIndvidual=E2=80=9D, etc), and copy/paste text betwe= en the two documents. The complete Introduction and Problem Statement are verbatim copy/paste, and include things like:

=C2=A0 This document
=C2=A0 =C2=A0proposes how to overcome this problem if using IP or Mult= i-Protocol
=C2=A0 =C2=A0Label Switching (MPLS) data plane encapsulation.

which is not the case for either document.

Technically, using multicast here exercises a different path, and usin= g a GAL does as well. What are we testing?

Net-net, do not support.

Thanks,

=E2=80=94 Carlos.

On Apr 17, 2017, at 6:55 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:

Working Group,

https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-= mc-lag-ip-00
https://datatracker.ietf.org/doc/draft-tanmir-= rtgwg-bfd-mc-lag-mpls/

The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for IP<= br> and MPLS have requested BFD working group adoption for their drafts.

These drafts were previously presented at IETF-96.

Please note that IPR has been declare against these drafts.=C2=A0 The IPR declaration may be found from the datatracker links.

Please indicate your support/lack of support to the mailing list.

-- Jeff and Reshad





--94eb2c0925467a92a9054d6858d0-- From nobody Mon Apr 17 21:11:03 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FE21270A7 for ; Mon, 17 Apr 2017 21:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7LUuc_WXT279 for ; Mon, 17 Apr 2017 21:10:59 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5C3120454 for ; Mon, 17 Apr 2017 21:10:59 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id x184so75816967oia.1 for ; Mon, 17 Apr 2017 21:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+N3TEVipjwRiyG1gWshylCZoIuO10+PbmG7Q9DJ60gs=; b=r5NC5Fu5B7IXPmoqU9iUWSHcxf2p3h4h09W3zaMqk56Y7z6g/EE1zz/5jaq2KaHOiT x+nHQAKhXw4uRc5i/R9zJz37G9FKo4Cwx8QNkTn7hVHtOnzojUuGedSyOMZZvCLH7Dfi +qkdBaOB2/b/LD1xDo3Ft8uFU9WKniWcpAh/p89G8c7/0q9AzU5GvANfUKVUIrChpn+L eL6ZamOh4NRH5G2C/BWCSTY10h4P3NgHdYNbspqwp/TzDpgNDTvMyWo5OsnfJ2ZF8hFe sbgfVvsoGAZDyeDz2jAHLPzH/JpuMkYK0ITtW5604ZbaTQf91hZwU251AYVIdFhDphx/ HK0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+N3TEVipjwRiyG1gWshylCZoIuO10+PbmG7Q9DJ60gs=; b=Dzkef0a9YaPRJXIW1/rKbyISqXYgcaKtMp2PjIXlSQqaRgEONYqH0bzD72lUTYeMzO 98xF61ynBzvnqHthZoRnb2Kwl0RQRxqs8jE02Ph618SqrxanROby5qp/f/PipPc6vhnC Vkc0v5aroIeajArksa5p/8pecNxLbr6bzSXrII5mkJ0N95mBv0fzR1/NyfIBKl1dedI8 VUruf+i3X4ZXE3vnztSS6Bl7m/eFkjuB62aeKEQWqA1dIYOr/cj9Uo+3A+QwuZ2jmh5H c/ZMsnKtdNztzD7506BPpOkIyNBOSFqskRlETfkexF81l3OrlXArL+g291hWhYX7v9b0 7Zkg== X-Gm-Message-State: AN3rC/6n08o91kpktKtzACwCpAYDeHcjVEtZbC9dFxIRsTOK8e+3bNkU YZz5equik05oWtIpEWCyBd7i4SGw4w== X-Received: by 10.157.43.88 with SMTP id f24mr7727065otd.25.1492488658598; Mon, 17 Apr 2017 21:10:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.56.45 with HTTP; Mon, 17 Apr 2017 21:10:57 -0700 (PDT) Received: by 10.157.56.45 with HTTP; Mon, 17 Apr 2017 21:10:57 -0700 (PDT) In-Reply-To: References: <20170417225539.GE18219@pfrc.org> From: Manav Bhatia Date: Tue, 18 Apr 2017 09:40:57 +0530 Message-ID: Subject: Re: Adoption call for draft-tanmir-rtgwg-bfd-mc-lag-* (ends April 30, 2017) To: Greg Mirsky Cc: rtg-bfd@ietf.org, "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a113d1da453c08b054d691849 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 04:11:02 -0000 --001a113d1da453c08b054d691849 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Then BFD is not the right tool. You should use/invent something else. Cheers, Manav -- Sent from a mobile device On Apr 18, 2017 8:47 AM, "Greg Mirsky" wrote: Hi Manav, single-hop BFD is helpful when the two BFD peers have Layer 2 switched domain between them. If the nodes are connected by the single wire, then there's no apparent benefit of using BFD at all. The same is the case for these two drafts. BFD is not intended to verify whether forwarding tables are correlating with the routing tables but it is to verify that a path exists between the BFD peers. In the case we've considered, the path through the Layer 2 switched domain. Thus I don't see that traversing the same blocks in fast path processing on the end nodes of the single-hop IP link is the critical requirement. But if the working group agrees that it is, then we'll be glad to work together to confirm with such requirement. Regards, Greg On Mon, Apr 17, 2017 at 6:42 PM, Manav Bhatia wrote= : > I had raised the exact same concerns when this draft was originally > posted. So I concur with what Carlos says. > > Cheers, Manav > > -- > Sent from a mobile device > > On Apr 18, 2017 5:09 AM, "Carlos Pignataro (cpignata)" > wrote: > > Jeff and Reshad, > > I do not support adoption of either draft-tanmir-rtgwg-bfd-mc-lag-ip-01 > or draft-tanmir-rtgwg-bfd-mc-lag-mpls-01. > > The overall problem and proposed solution did not seem to have received > much discussion. I was only able to find one email thread on the list, ov= er > a year ago. > > Regarding the problem statement, it=E2=80=99s strange that there=E2=80=99= s no normative > definition or anything to MG-LAG=E2=80=A6 further, the meeting notes from= IETF96 > say things like: > John Messenger: Would suggest work done in 802.1 to analyze tho= se > considerations with 802, it would be necessary to coordinate to > work > with them. Send a mail to IETF-IEEE802 coordination group. > Jeff Haas: Can we sign you as a reviewer to this draft? > > What is the problem again, beyond what=E2=80=99s already well specified i= n RFC > 7130? Is this again a quick =E2=80=9Csolution=E2=80=9D looking for an RFC= number? > > Regarding the proposed solution, the one email thread seems to have > pointed out some serious issues not considered: > https://mailarchive.ietf.org/arch/msg/rtg-bfd/OLWLCf6dn-3zxGZboTKVqUwSr6w > https://mailarchive.ietf.org/arch/msg/rtg-bfd/nwfLfudDdNw7PyJbpP-RVnVFMcQ > https://mailarchive.ietf.org/arch/msg/rtg-bfd/EuRObko0JO40_4UPB4buR0iyxcg > https://mailarchive.ietf.org/arch/msg/rtg-bfd/QUb5rj882TKeAAXyTof4ycq2DUg > > Additionally, why the split into two drafts for this? The text of both > documents overall seems forgotten, even sloppy, with many typos (=E2=80= =9CMPSL=E2=80=9D, > =E2=80=9CIndvidual=E2=80=9D, etc), and copy/paste text between the two do= cuments. The > complete Introduction and Problem Statement are verbatim copy/paste, and > include things like: > > This document > proposes how to overcome this problem if using IP or Multi-Protocol > Label Switching (MPLS) data plane encapsulation. > > which is not the case for either document. > > Technically, using multicast here exercises a different path, and using a > GAL does as well. What are we testing? > > Net-net, do not support. > > Thanks, > > =E2=80=94 Carlos. > > On Apr 17, 2017, at 6:55 PM, Jeffrey Haas wrote: > > Working Group, > > https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-ip-00 > https://datatracker.ietf.org/doc/draft-tanmir-rtgwg-bfd-mc-lag-mpls/ > > The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for I= P > and MPLS have requested BFD working group adoption for their drafts. > > These drafts were previously presented at IETF-96. > > Please note that IPR has been declare against these drafts. The IPR > declaration may be found from the datatracker links. > > Please indicate your support/lack of support to the mailing list. > > -- Jeff and Reshad > > > > > --001a113d1da453c08b054d691849 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Then BFD is not the right tool. You should use/inven= t something else.=C2=A0

= Cheers, Manav=C2=A0

--
Sent from a mobile device

On Apr 18, 2017 8:47 AM, "Gre= g Mirsky" <gregimirsky@gma= il.com> wrote:
Hi Manav,
single-hop BFD is helpful when the two BFD peers= have Layer 2 switched domain between them. If the nodes are connected by t= he single wire, then there's no apparent benefit of using BFD at all. T= he same is the case for these two drafts. BFD is not intended to verify whe= ther forwarding tables are correlating with the routing tables but it is to= verify that a path exists between the BFD peers. In the case we've con= sidered, the path through the Layer 2 switched domain. Thus I don't see= that traversing the same blocks in fast path processing on the end nodes o= f the single-hop IP link is the critical requirement. But if the working gr= oup agrees that it is, then we'll be glad to work together to confirm w= ith such requirement.

Regards,
Greg=C2= =A0

On Mon, Apr 17, 2017 at 6:42 PM, Manav Bhatia <manavbhatia@gmail.com> wrote:
I had raised the exact same concerns when this draft= was originally posted. So I concur with what Carlos says.=C2=A0

Cheers, Manav=C2=A0

--
Sent from a mobile device

On Apr 18, 2017 5:09 AM, "Carlos Pignataro (cpignata)" <= ;cpignata@cisco.com= > wrote:
Jeff and Reshad,

I do not support adoption of either draft-tanmir-rtgwg-bfd-mc-lag-ip-01 or draft-tanmir-rtgwg-bfd-mc-lag-mpls-01.

The overall problem and proposed solution did not seem to have receive= d much discussion. I was only able to find one email thread on the list, ov= er a year ago.

Regarding the problem statement, it=E2=80=99s strange that there=E2=80= =99s no normative definition or anything to MG-LAG=E2=80=A6 further, the me= eting notes from IETF96 say things like:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 John Messenger: Would suggest work = done in 802.1 to analyze those
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 considerations with 802, it would b= e necessary to coordinate to work
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with them. Send a mail to IETF-IEEE= 802 coordination group.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jeff Haas: Can we sign you as a rev= iewer to this draft?

What is the problem again, beyond what=E2=80=99s already well specifie= d in RFC 7130? Is this again a quick =E2=80=9Csolution=E2=80=9D looking for= an RFC number?

Regarding the proposed solution, the one email thread seems to have po= inted out some serious issues not considered:

Additionally, why the split into two drafts for this? The text of both= documents overall seems forgotten, even sloppy, with many typos (=E2=80=9C= MPSL=E2=80=9D, =E2=80=9CIndvidual=E2=80=9D, etc), and copy/paste text betwe= en the two documents. The complete Introduction and Problem Statement are verbatim copy/paste, and include things like:

=C2=A0 This document
=C2=A0 =C2=A0proposes how to overcome this problem if using IP or Mult= i-Protocol
=C2=A0 =C2=A0Label Switching (MPLS) data plane encapsulation.

which is not the case for either document.

Technically, using multicast here exercises a different path, and usin= g a GAL does as well. What are we testing?

Net-net, do not support.

Thanks,

=E2=80=94 Carlos.

On Apr 17, 2017, at 6:55 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:

Working Group,

https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-= mc-lag-ip-00
https://datatracker.ietf.org/doc/draft-tanmir-= rtgwg-bfd-mc-lag-mpls/

The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for IP<= br> and MPLS have requested BFD working group adoption for their drafts.

These drafts were previously presented at IETF-96.

Please note that IPR has been declare against these drafts.=C2=A0 The IPR declaration may be found from the datatracker links.

Please indicate your support/lack of support to the mailing list.

-- Jeff and Reshad






--001a113d1da453c08b054d691849-- From nobody Mon Apr 17 22:01:57 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA7B129469 for ; Mon, 17 Apr 2017 22:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RWnXAXB9FjVa for ; Mon, 17 Apr 2017 22:01:54 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AECF1292D3 for ; Mon, 17 Apr 2017 22:01:54 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id x184so76609656oia.1 for ; Mon, 17 Apr 2017 22:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HVAfwV0nUixmqkPA2ZAnGoZZCOU6QYKUBle+ruQF/1I=; b=YynVQoQiMneWevc1C4iTnzYHR6A9+p4THVwAkuZdoioKCgLSU80xjAlSv7OMKtQk3g 3jmDuSR9TG5OV2rPVMU7zkWIzpv6n/xgDDffldAwdMOtkH1EVWxN3kcAebO4br0PI0GI AQB3bbM2WqiFy6ozMTyRCmNvYBmtQfcXeCeP93iuj90GdqDC2/4nkXUqWaZEWrkSXgDr wnmWeTAZBQc9jeArssl+oirhN/6+6O3AEnDdt0bZdd0PXvs/82FsAl/8eP4VyXgEScWh 8FlacxnzaW5MEZzNUCgRsUXxD3UsaEFPYOYPgPut9Jky6myGncJmpkRcB27Eo/y4qXEm l3Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HVAfwV0nUixmqkPA2ZAnGoZZCOU6QYKUBle+ruQF/1I=; b=OJCzGxRO0NNlyFC8UN4WyebcbBes7R2p+mVi/BorE5+Og8YYEIdngr1sk8p/nIVh/c Cq/liz3ir3OsiPY7I1idV8pY/+HUxIpzvoert78+Un9Ip+B1tKYpsNJHVnTIOVifGAtP 4xAFF38/19TJfIU76Vsqfai333YW6D44tKw+12K4Mhv1w0SJ9CrE28S0GAGQE1ysrGoG rmeX9c5dORRpwqMsEIjOqXZtpwRWQaEARh1fNy5TNuA02r068MPvV4SCvj0QZBqU1n7E hEdd0sFAFs6O65gOth2A963D8gxBbkvhOn7egRwwlEuwCQXTtrJXLozkIvhAN3ftW9IP F8Ew== X-Gm-Message-State: AN3rC/4IpHQL5RQv1zuLd5LMM9SFhuiN7nNdANzw12Z/E5GWmTD14ICX G7dAXyZS4DpjldAxWrpitZW/LmJVMw== X-Received: by 10.202.206.198 with SMTP id e189mr4197159oig.158.1492491713501; Mon, 17 Apr 2017 22:01:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.89.225 with HTTP; Mon, 17 Apr 2017 22:01:53 -0700 (PDT) In-Reply-To: References: <20170417225539.GE18219@pfrc.org> From: Greg Mirsky Date: Mon, 17 Apr 2017 22:01:53 -0700 Message-ID: Subject: Re: Adoption call for draft-tanmir-rtgwg-bfd-mc-lag-* (ends April 30, 2017) To: Manav Bhatia Cc: "rtg-bfd@ietf.org" , "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a113d31a669e11a054d69ced6 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 05:01:56 -0000 --001a113d31a669e11a054d69ced6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Manav, I agree that it would be helpful to discuss whether using BFD to monitor Layer 2 connectivity is the right approach. I'd point that from the Layer 2 perspective uBFD is not following the same fast path processing as data packets either. Thus there could be some scenarios when uBFD produces either false negative or false positive results. And while we understand that, we agreed that these are rather exceptions and that uBFD is useful to monitor constituent links. I believe it is reasonable to have the same discussion about monitoring constituent links of a MC-LAG. Is it the problem that needs to be solved? Do these drafts that propose to extend use of uBFD offer technically reasonable solution? These are the questions, per my understanding of WG adoption call, that we have in front of us. Regards, Greg On Mon, Apr 17, 2017 at 9:10 PM, Manav Bhatia wrote= : > Then BFD is not the right tool. You should use/invent something else. > > Cheers, Manav > > -- > Sent from a mobile device > > On Apr 18, 2017 8:47 AM, "Greg Mirsky" wrote: > > Hi Manav, > single-hop BFD is helpful when the two BFD peers have Layer 2 switched > domain between them. If the nodes are connected by the single wire, then > there's no apparent benefit of using BFD at all. The same is the case for > these two drafts. BFD is not intended to verify whether forwarding tables > are correlating with the routing tables but it is to verify that a path > exists between the BFD peers. In the case we've considered, the path > through the Layer 2 switched domain. Thus I don't see that traversing the > same blocks in fast path processing on the end nodes of the single-hop IP > link is the critical requirement. But if the working group agrees that it > is, then we'll be glad to work together to confirm with such requirement. > > Regards, > Greg > > On Mon, Apr 17, 2017 at 6:42 PM, Manav Bhatia > wrote: > >> I had raised the exact same concerns when this draft was originally >> posted. So I concur with what Carlos says. >> >> Cheers, Manav >> >> -- >> Sent from a mobile device >> >> On Apr 18, 2017 5:09 AM, "Carlos Pignataro (cpignata)" < >> cpignata@cisco.com> wrote: >> >> Jeff and Reshad, >> >> I do not support adoption of either draft-tanmir-rtgwg-bfd-mc-lag-ip-01 >> or draft-tanmir-rtgwg-bfd-mc-lag-mpls-01. >> >> The overall problem and proposed solution did not seem to have received >> much discussion. I was only able to find one email thread on the list, o= ver >> a year ago. >> >> Regarding the problem statement, it=E2=80=99s strange that there=E2=80= =99s no normative >> definition or anything to MG-LAG=E2=80=A6 further, the meeting notes fro= m IETF96 >> say things like: >> John Messenger: Would suggest work done in 802.1 to analyze >> those >> considerations with 802, it would be necessary to coordinate t= o >> work >> with them. Send a mail to IETF-IEEE802 coordination group. >> Jeff Haas: Can we sign you as a reviewer to this draft? >> >> What is the problem again, beyond what=E2=80=99s already well specified = in RFC >> 7130? Is this again a quick =E2=80=9Csolution=E2=80=9D looking for an RF= C number? >> >> Regarding the proposed solution, the one email thread seems to have >> pointed out some serious issues not considered: >> https://mailarchive.ietf.org/arch/msg/rtg-bfd/OLWLCf6dn-3zxGZboTKVqUwSr6= w >> https://mailarchive.ietf.org/arch/msg/rtg-bfd/nwfLfudDdNw7PyJbpP-RVnVFMc= Q >> https://mailarchive.ietf.org/arch/msg/rtg-bfd/EuRObko0JO40_4UPB4buR0iyxc= g >> https://mailarchive.ietf.org/arch/msg/rtg-bfd/QUb5rj882TKeAAXyTof4ycq2DU= g >> >> Additionally, why the split into two drafts for this? The text of both >> documents overall seems forgotten, even sloppy, with many typos (=E2=80= =9CMPSL=E2=80=9D, >> =E2=80=9CIndvidual=E2=80=9D, etc), and copy/paste text between the two d= ocuments. The >> complete Introduction and Problem Statement are verbatim copy/paste, and >> include things like: >> >> This document >> proposes how to overcome this problem if using IP or Multi-Protocol >> Label Switching (MPLS) data plane encapsulation. >> >> which is not the case for either document. >> >> Technically, using multicast here exercises a different path, and using = a >> GAL does as well. What are we testing? >> >> Net-net, do not support. >> >> Thanks, >> >> =E2=80=94 Carlos. >> >> On Apr 17, 2017, at 6:55 PM, Jeffrey Haas wrote: >> >> Working Group, >> >> https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-ip-00 >> https://datatracker.ietf.org/doc/draft-tanmir-rtgwg-bfd-mc-lag-mpls/ >> >> The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for = IP >> and MPLS have requested BFD working group adoption for their drafts. >> >> These drafts were previously presented at IETF-96. >> >> Please note that IPR has been declare against these drafts. The IPR >> declaration may be found from the datatracker links. >> >> Please indicate your support/lack of support to the mailing list. >> >> -- Jeff and Reshad >> >> >> >> >> > > --001a113d31a669e11a054d69ced6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Manav,
I agree that it would be helpful to discuss = whether using BFD to monitor Layer 2 connectivity is the right approach. I&= #39;d point that from the Layer 2 perspective uBFD is not following the sam= e fast path processing as data packets either. Thus there could be some sce= narios when uBFD produces either false negative or false positive results. = And while we understand that, we agreed that these are rather exceptions an= d that uBFD is useful to monitor constituent links. I believe it is reasona= ble to have the same discussion about monitoring constituent links of a MC-= LAG. Is it the problem that needs to be solved? Do these drafts that propos= e to extend use of uBFD offer technically reasonable solution? These are th= e questions, per my understanding of WG adoption call, that we have in fron= t of us.

Regards,
Greg

On Mon, Apr 17, 2017 at= 9:10 PM, Manav Bhatia <manavbhatia@gmail.com> wrote:
Then BFD is not the = right tool. You should use/invent something else.=C2=A0

Cheers, Manav=C2=A0
--
Sent from a mob= ile device

On Apr 18, 2017 8:47 AM, "G= reg Mirsky" <gregimirsky@gmail.com> wrote:
Hi Manav,
single= -hop BFD is helpful when the two BFD peers have Layer 2 switched domain bet= ween them. If the nodes are connected by the single wire, then there's = no apparent benefit of using BFD at all. The same is the case for these two= drafts. BFD is not intended to verify whether forwarding tables are correl= ating with the routing tables but it is to verify that a path exists betwee= n the BFD peers. In the case we've considered, the path through the Lay= er 2 switched domain. Thus I don't see that traversing the same blocks = in fast path processing on the end nodes of the single-hop IP link is the c= ritical requirement. But if the working group agrees that it is, then we= 9;ll be glad to work together to confirm with such requirement.
<= br>
Regards,
Greg=C2=A0

On Mon, Apr 17, 2017 at 6:42 PM, Manav Bhatia <manavbhatia= @gmail.com> wrote:
I had raised the exact same concerns when this draft was original= ly posted. So I concur with what Carlos says.=C2=A0

Cheers, Manav=C2=A0

--
Sent from a mobile device

On Apr 18, 2017 5:09 AM, "Carlos= Pignataro (cpignata)" <cpignata@cisco.com> wrote:
Jeff and Reshad,

I do not support adoption of either draft-tanmir-rtgwg-bfd-mc-lag-ip-01 or draft-tanmir-rtgwg-bfd-mc-lag-mpls-01.

The overall problem and proposed solution did not seem to have receive= d much discussion. I was only able to find one email thread on the list, ov= er a year ago.

Regarding the problem statement, it=E2=80=99s strange that there=E2=80= =99s no normative definition or anything to MG-LAG=E2=80=A6 further, the me= eting notes from IETF96 say things like:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 John Messenger: Would suggest work = done in 802.1 to analyze those
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 considerations with 802, it would b= e necessary to coordinate to work
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with them. Send a mail to IETF-IEEE= 802 coordination group.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jeff Haas: Can we sign you as a rev= iewer to this draft?

What is the problem again, beyond what=E2=80=99s already well specifie= d in RFC 7130? Is this again a quick =E2=80=9Csolution=E2=80=9D looking for= an RFC number?

Regarding the proposed solution, the one email thread seems to have po= inted out some serious issues not considered:

Additionally, why the split into two drafts for this? The text of both= documents overall seems forgotten, even sloppy, with many typos (=E2=80=9C= MPSL=E2=80=9D, =E2=80=9CIndvidual=E2=80=9D, etc), and copy/paste text betwe= en the two documents. The complete Introduction and Problem Statement are verbatim copy/paste, and include things like:

=C2=A0 This document
=C2=A0 =C2=A0proposes how to overcome this problem if using IP or Mult= i-Protocol
=C2=A0 =C2=A0Label Switching (MPLS) data plane encapsulation.

which is not the case for either document.

Technically, using multicast here exercises a different path, and usin= g a GAL does as well. What are we testing?

Net-net, do not support.

Thanks,

=E2=80=94 Carlos.

On Apr 17, 2017, at 6:55 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:

Working Group,

https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-= mc-lag-ip-00
https://datatracker.ietf.org/doc/draft-tanmir-= rtgwg-bfd-mc-lag-mpls/

The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for IP<= br> and MPLS have requested BFD working group adoption for their drafts.

These drafts were previously presented at IETF-96.

Please note that IPR has been declare against these drafts.=C2=A0 The IPR declaration may be found from the datatracker links.

Please indicate your support/lack of support to the mailing list.

-- Jeff and Reshad







--001a113d31a669e11a054d69ced6-- From nobody Tue Apr 18 08:47:02 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E667412EBCE for ; Tue, 18 Apr 2017 08:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lAZvQTv6xTmm for ; Tue, 18 Apr 2017 08:46:59 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0B2120727 for ; Tue, 18 Apr 2017 08:46:59 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id b187so182261762oif.0 for ; Tue, 18 Apr 2017 08:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bbmIazyz+BDpnV+Tl9eB0okm13YKIEeZ4ksMI6JTllM=; b=vh8wQWndogp7hVKahH68a4f8k/X3m9yth8ITbu62TDzLzP8P+44UVfjpyLdd8EH029 9c40mpQLJuBMy4mZ70TZKMf45o8dNqAatc8Ee9XB04fETqBfAyDFFAtE0XY/ELywkp05 chIKYB5anG3Y1Cv7UAzwRaqSt4rBeLVn10gGaf2Ei9Ypfoy4U6tYB2T7I/4nzdGmI6Lm nqNDv4wIFlwvCPcg4hQmCpKDeLyJdo5Fu4nNiTZvtEGy7bhsc8m8jTtgWDSAl3Uhub8F SN/xKSlETSXxTvxtgS3zW8V8yA/nonsG47Hm9q/aU/I6R6UFRi9N9/wbuavaXIK/9zLH S8mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bbmIazyz+BDpnV+Tl9eB0okm13YKIEeZ4ksMI6JTllM=; b=Xu25aLV5VmlTp9HnKYO73t+4V8chOFqw3vGgD5G+WdiJ2OJyPmlT6f1fN+w6SNj7wE FD6Cwp09/NXGvPyWfHKaUEdU9nlvUcCr/kO3oGPZhzbZsBgAeHbys8mFKG0hletvOTFR 886+W2qcUW/arXcISIJ1fI+dGWYcbQQJLwpw9yPt4hDGjL47DA2gzi/t1LIfsLe6cEha LC4C9wL7dgZwNSes4rHco7eFqrv4rWbyVBDM/gSq+qa3tevDnfwDA/RMcpD+p2CoKFEg 3tvG3w7KtWQMcvgHKihcesfK6T0TXgOWqBsIZ0eS4gPSrXuj2I3yNKq1k+nY22rZx6s+ 5XPg== X-Gm-Message-State: AN3rC/7JF2li6pdlRLIpHKE7ThD9lRkypgEUNWHxjjr3hUkPTQZIkXWi dGt7jfIC6uii5x28ul6OJ8dzXau4Ng== X-Received: by 10.202.225.212 with SMTP id y203mr6946358oig.46.1492530418807; Tue, 18 Apr 2017 08:46:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.56.45 with HTTP; Tue, 18 Apr 2017 08:46:58 -0700 (PDT) Received: by 10.157.56.45 with HTTP; Tue, 18 Apr 2017 08:46:58 -0700 (PDT) In-Reply-To: References: <20170417225539.GE18219@pfrc.org> From: Manav Bhatia Date: Tue, 18 Apr 2017 21:16:58 +0530 Message-ID: Subject: Re: Adoption call for draft-tanmir-rtgwg-bfd-mc-lag-* (ends April 30, 2017) To: Greg Mirsky Cc: rtg-bfd@ietf.org, "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a113d2dfe6dfb99054d72d145 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 15:47:02 -0000 --001a113d2dfe6dfb99054d72d145 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't know why you think ubfd packets do not follow the regular data path= ? I am traveling and have sporadic Internet connectivity, so response can get delayed. -- Sent from a mobile device On Apr 18, 2017 10:31 AM, "Greg Mirsky" wrote: > Hi Manav, > I agree that it would be helpful to discuss whether using BFD to monitor > Layer 2 connectivity is the right approach. I'd point that from the Layer= 2 > perspective uBFD is not following the same fast path processing as data > packets either. Thus there could be some scenarios when uBFD produces > either false negative or false positive results. And while we understand > that, we agreed that these are rather exceptions and that uBFD is useful = to > monitor constituent links. I believe it is reasonable to have the same > discussion about monitoring constituent links of a MC-LAG. Is it the > problem that needs to be solved? Do these drafts that propose to extend u= se > of uBFD offer technically reasonable solution? These are the questions, p= er > my understanding of WG adoption call, that we have in front of us. > > Regards, > Greg > > On Mon, Apr 17, 2017 at 9:10 PM, Manav Bhatia > wrote: > >> Then BFD is not the right tool. You should use/invent something else. >> >> Cheers, Manav >> >> -- >> Sent from a mobile device >> >> On Apr 18, 2017 8:47 AM, "Greg Mirsky" wrote: >> >> Hi Manav, >> single-hop BFD is helpful when the two BFD peers have Layer 2 switched >> domain between them. If the nodes are connected by the single wire, then >> there's no apparent benefit of using BFD at all. The same is the case fo= r >> these two drafts. BFD is not intended to verify whether forwarding table= s >> are correlating with the routing tables but it is to verify that a path >> exists between the BFD peers. In the case we've considered, the path >> through the Layer 2 switched domain. Thus I don't see that traversing th= e >> same blocks in fast path processing on the end nodes of the single-hop I= P >> link is the critical requirement. But if the working group agrees that i= t >> is, then we'll be glad to work together to confirm with such requirement= . >> >> Regards, >> Greg >> >> On Mon, Apr 17, 2017 at 6:42 PM, Manav Bhatia >> wrote: >> >>> I had raised the exact same concerns when this draft was originally >>> posted. So I concur with what Carlos says. >>> >>> Cheers, Manav >>> >>> -- >>> Sent from a mobile device >>> >>> On Apr 18, 2017 5:09 AM, "Carlos Pignataro (cpignata)" < >>> cpignata@cisco.com> wrote: >>> >>> Jeff and Reshad, >>> >>> I do not support adoption of either draft-tanmir-rtgwg-bfd-mc-lag-ip-01 >>> or draft-tanmir-rtgwg-bfd-mc-lag-mpls-01. >>> >>> The overall problem and proposed solution did not seem to have received >>> much discussion. I was only able to find one email thread on the list, = over >>> a year ago. >>> >>> Regarding the problem statement, it=E2=80=99s strange that there=E2=80= =99s no normative >>> definition or anything to MG-LAG=E2=80=A6 further, the meeting notes fr= om IETF96 >>> say things like: >>> John Messenger: Would suggest work done in 802.1 to analyze >>> those >>> considerations with 802, it would be necessary to coordinate >>> to work >>> with them. Send a mail to IETF-IEEE802 coordination group. >>> Jeff Haas: Can we sign you as a reviewer to this draft? >>> >>> What is the problem again, beyond what=E2=80=99s already well specified= in RFC >>> 7130? Is this again a quick =E2=80=9Csolution=E2=80=9D looking for an R= FC number? >>> >>> Regarding the proposed solution, the one email thread seems to have >>> pointed out some serious issues not considered: >>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/OLWLCf6dn-3zxG >>> ZboTKVqUwSr6w >>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/nwfLfudDdNw7Py >>> JbpP-RVnVFMcQ >>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/EuRObko0JO40_4 >>> UPB4buR0iyxcg >>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/QUb5rj882TKeAA >>> XyTof4ycq2DUg >>> >>> Additionally, why the split into two drafts for this? The text of both >>> documents overall seems forgotten, even sloppy, with many typos (=E2=80= =9CMPSL=E2=80=9D, >>> =E2=80=9CIndvidual=E2=80=9D, etc), and copy/paste text between the two = documents. The >>> complete Introduction and Problem Statement are verbatim copy/paste, an= d >>> include things like: >>> >>> This document >>> proposes how to overcome this problem if using IP or Multi-Protocol >>> Label Switching (MPLS) data plane encapsulation. >>> >>> which is not the case for either document. >>> >>> Technically, using multicast here exercises a different path, and using >>> a GAL does as well. What are we testing? >>> >>> Net-net, do not support. >>> >>> Thanks, >>> >>> =E2=80=94 Carlos. >>> >>> On Apr 17, 2017, at 6:55 PM, Jeffrey Haas wrote: >>> >>> Working Group, >>> >>> https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-ip-00 >>> https://datatracker.ietf.org/doc/draft-tanmir-rtgwg-bfd-mc-lag-mpls/ >>> >>> The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for >>> IP >>> and MPLS have requested BFD working group adoption for their drafts. >>> >>> These drafts were previously presented at IETF-96. >>> >>> Please note that IPR has been declare against these drafts. The IPR >>> declaration may be found from the datatracker links. >>> >>> Please indicate your support/lack of support to the mailing list. >>> >>> -- Jeff and Reshad >>> >>> >>> >>> >>> >> >> > --001a113d2dfe6dfb99054d72d145 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't know why you think ubfd packets do not follow= the regular data path?

I am t= raveling and have sporadic Internet connectivity, so response can get delay= ed.=C2=A0

--Sent from a mobile device
On Apr 18, 2017 10:31 AM, "Greg Mirsky&quo= t; <gregimirsky@gmail.com&g= t; wrote:
Hi Manav,
I agree that it would be helpful to discuss whether = using BFD to monitor Layer 2 connectivity is the right approach. I'd po= int that from the Layer 2 perspective uBFD is not following the same fast p= ath processing as data packets either. Thus there could be some scenarios w= hen uBFD produces either false negative or false positive results. And whil= e we understand that, we agreed that these are rather exceptions and that u= BFD is useful to monitor constituent links. I believe it is reasonable to h= ave the same discussion about monitoring constituent links of a MC-LAG. Is = it the problem that needs to be solved? Do these drafts that propose to ext= end use of uBFD offer technically reasonable solution? These are the questi= ons, per my understanding of WG adoption call, that we have in front of us.=

Regards,
Greg

On Mon, Apr 17, 2017 at 9:10 PM= , Manav Bhatia <manavbhatia@gmail.com> wrote:
Then BFD is not the right to= ol. You should use/invent something else.=C2=A0

=
Cheers, Manav=C2=A0

--
Sent from a mobile device

On Apr 18, 2017 8:47 AM, "= ;Greg Mirsky" <gregimirsky@gmail.com> wrote:
Hi Manav,
single-hop BFD is helpful when the two BFD peers have Laye= r 2 switched domain between them. If the nodes are connected by the single = wire, then there's no apparent benefit of using BFD at all. The same is= the case for these two drafts. BFD is not intended to verify whether forwa= rding tables are correlating with the routing tables but it is to verify th= at a path exists between the BFD peers. In the case we've considered, t= he path through the Layer 2 switched domain. Thus I don't see that trav= ersing the same blocks in fast path processing on the end nodes of the sing= le-hop IP link is the critical requirement. But if the working group agrees= that it is, then we'll be glad to work together to confirm with such r= equirement.

Regards,
Greg=C2=A0

On Mon, Apr 17, 201= 7 at 6:42 PM, Manav Bhatia <manavbhatia@gmail.com> wrote= :
I had raised the exac= t same concerns when this draft was originally posted. So I concur with wha= t Carlos says.=C2=A0

Cheers, M= anav=C2=A0

--Sent from a mobile device

On Apr 18, 2017 5:09 AM, &= quot;Carlos Pignataro (cpignata)" <cpignata@cisco.com> wrote:
Jeff and Reshad,

I do not support adoption of either draft-tanmir-rtgwg-bfd-mc-lag-ip-01 or draft-tanmir-rtgwg-bfd-mc-lag-mpls-01.

The overall problem and proposed solution did not seem to have receive= d much discussion. I was only able to find one email thread on the list, ov= er a year ago.

Regarding the problem statement, it=E2=80=99s strange that there=E2=80= =99s no normative definition or anything to MG-LAG=E2=80=A6 further, the me= eting notes from IETF96 say things like:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 John Messenger: Would suggest work = done in 802.1 to analyze those
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 considerations with 802, it would b= e necessary to coordinate to work
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with them. Send a mail to IETF-IEEE= 802 coordination group.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jeff Haas: Can we sign you as a rev= iewer to this draft?

What is the problem again, beyond what=E2=80=99s already well specifie= d in RFC 7130? Is this again a quick =E2=80=9Csolution=E2=80=9D looking for= an RFC number?

Regarding the proposed solution, the one email thread seems to have po= inted out some serious issues not considered:
https://maila= rchive.ietf.org/arch/msg/rtg-bfd/OLWLCf6dn-3zxGZboTKVqUwSr6w<= /div>
https://maila= rchive.ietf.org/arch/msg/rtg-bfd/nwfLfudDdNw7PyJbpP-RVnVFMcQ<= /div>
https://maila= rchive.ietf.org/arch/msg/rtg-bfd/EuRObko0JO40_4UPB4buR0iyxcg<= /div>
https://maila= rchive.ietf.org/arch/msg/rtg-bfd/QUb5rj882TKeAAXyTof4ycq2DUg<= /div>

Additionally, why the split into two drafts for this? The text of both= documents overall seems forgotten, even sloppy, with many typos (=E2=80=9C= MPSL=E2=80=9D, =E2=80=9CIndvidual=E2=80=9D, etc), and copy/paste text betwe= en the two documents. The complete Introduction and Problem Statement are verbatim copy/paste, and include things like:

=C2=A0 This document
=C2=A0 =C2=A0proposes how to overcome this problem if using IP or Mult= i-Protocol
=C2=A0 =C2=A0Label Switching (MPLS) data plane encapsulation.

which is not the case for either document.

Technically, using multicast here exercises a different path, and usin= g a GAL does as well. What are we testing?

Net-net, do not support.

Thanks,

=E2=80=94 Carlos.

On Apr 17, 2017, at 6:55 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:

Working Group,

https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-= mc-lag-ip-00
https://datatracker.ietf.org/doc/draft-tanmir-= rtgwg-bfd-mc-lag-mpls/

The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for IP<= br> and MPLS have requested BFD working group adoption for their drafts.

These drafts were previously presented at IETF-96.

Please note that IPR has been declare against these drafts.=C2=A0 The IPR declaration may be found from the datatracker links.

Please indicate your support/lack of support to the mailing list.

-- Jeff and Reshad







--001a113d2dfe6dfb99054d72d145-- From nobody Tue Apr 18 11:55:53 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221CD13146A for ; Tue, 18 Apr 2017 11:55:51 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JU-e_Em67ful for ; Tue, 18 Apr 2017 11:55:48 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A3912702E for ; Tue, 18 Apr 2017 11:55:48 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id r203so2362543oib.3 for ; Tue, 18 Apr 2017 11:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K/w2iGXV1UQ+88Hle1Futuv6Bwf/38znlzN+Z+pXO8s=; b=mt71KKNpqVwhVRomRZEKP+mRKjm42GeJekUmeVpEso9zeGoQZe54iOq4s5xkP7ve4/ +PQ3ZxDQclFw87phleyPpkX46lMuYUFnzUWw7/HIzn4CsfJk0duQ+IqNmUbu6LEFH4I5 7dHwN/1ns2WhAy7jDQch9W1T2sehDqoO68NA3qe5xxtHyUSGss0EaLaHR/5dqSQ9uglc HyN6YqdDK02dBHZTAMpp90Jsm99/vXHJJwBNhM6J+WjNfpXcJTH/rJfvaXTbrftoYw2X hOJh+OSyZ+dDQutf05uHlYgJzDSFUfjo1rJG1rcs9MBoUrb+BkudjIJhPH5wpxAA5xp4 Uyow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K/w2iGXV1UQ+88Hle1Futuv6Bwf/38znlzN+Z+pXO8s=; b=DrcW7rff/vOMSBVpBxwCCcDT3nvfuHUTcUPPA05X8gXs9V8v/s9zVn4WIlPiLvYtbx 2/iX/fdRsQ4BG7LjWEzjtn608AxgDKkKJk///PWwolkDr2myqcVYS5YS4LjCBVkBxITX MaIvb2fTa68vK4CMFf62P5XDCUnx4AHQ8yjA5cNfowDwgyAHnmIZtoqn29fzcg8iqhrz 9TFoEI8RWlN/RPcWdVxrP9JA/4OR9V/hr25SZfPrziprZ+LDHzOoFqgo7Ods2Txmy8G6 T0Pb2e5DpuetJn0lNF+5jGPY5Pn2MRAB8KgYcwWBiTftsrXievwv4B1kr+wQzdz4zOkg RR7g== X-Gm-Message-State: AN3rC/7I9imVGdSwgS5XWp34ukLaQqwv2E9MT85NMx+AEsy2slEmSvY5 lCKFpt9HB+wnXaBmYn1Ppi5lL0NGtQ== X-Received: by 10.202.235.196 with SMTP id j187mr6178954oih.167.1492541747641; Tue, 18 Apr 2017 11:55:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.89.225 with HTTP; Tue, 18 Apr 2017 11:55:47 -0700 (PDT) In-Reply-To: References: <20170417225539.GE18219@pfrc.org> From: Greg Mirsky Date: Tue, 18 Apr 2017 11:55:47 -0700 Message-ID: Subject: Re: Adoption call for draft-tanmir-rtgwg-bfd-mc-lag-* (ends April 30, 2017) To: Manav Bhatia Cc: "rtg-bfd@ietf.org" , "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a113cf63eae4403054d75746f Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 18:55:51 -0000 --001a113cf63eae4403054d75746f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Manav, thank you for your consideration. If we agree that what single-hop BFD effectively monitors is the Layer 2 switched domain, then we should pay attention to Layer 2 encapsulation. If uBFD implementation uses only the dedicated MAC address and does not switch to use of source MAC address in received BFD control packets as described in the first para Section 2.3 RFC 7130, then, I believe, it is possible that processing of L2 frames might be different whether it carries data or uBFD. Safe travel and regards, Greg On Tue, Apr 18, 2017 at 8:46 AM, Manav Bhatia wrote= : > I don't know why you think ubfd packets do not follow the regular data > path? > > I am traveling and have sporadic Internet connectivity, so response can > get delayed. > > -- > Sent from a mobile device > > On Apr 18, 2017 10:31 AM, "Greg Mirsky" wrote: > >> Hi Manav, >> I agree that it would be helpful to discuss whether using BFD to monitor >> Layer 2 connectivity is the right approach. I'd point that from the Laye= r 2 >> perspective uBFD is not following the same fast path processing as data >> packets either. Thus there could be some scenarios when uBFD produces >> either false negative or false positive results. And while we understand >> that, we agreed that these are rather exceptions and that uBFD is useful= to >> monitor constituent links. I believe it is reasonable to have the same >> discussion about monitoring constituent links of a MC-LAG. Is it the >> problem that needs to be solved? Do these drafts that propose to extend = use >> of uBFD offer technically reasonable solution? These are the questions, = per >> my understanding of WG adoption call, that we have in front of us. >> >> Regards, >> Greg >> >> On Mon, Apr 17, 2017 at 9:10 PM, Manav Bhatia >> wrote: >> >>> Then BFD is not the right tool. You should use/invent something else. >>> >>> Cheers, Manav >>> >>> -- >>> Sent from a mobile device >>> >>> On Apr 18, 2017 8:47 AM, "Greg Mirsky" wrote: >>> >>> Hi Manav, >>> single-hop BFD is helpful when the two BFD peers have Layer 2 switched >>> domain between them. If the nodes are connected by the single wire, the= n >>> there's no apparent benefit of using BFD at all. The same is the case f= or >>> these two drafts. BFD is not intended to verify whether forwarding tabl= es >>> are correlating with the routing tables but it is to verify that a path >>> exists between the BFD peers. In the case we've considered, the path >>> through the Layer 2 switched domain. Thus I don't see that traversing t= he >>> same blocks in fast path processing on the end nodes of the single-hop = IP >>> link is the critical requirement. But if the working group agrees that = it >>> is, then we'll be glad to work together to confirm with such requiremen= t. >>> >>> Regards, >>> Greg >>> >>> On Mon, Apr 17, 2017 at 6:42 PM, Manav Bhatia >>> wrote: >>> >>>> I had raised the exact same concerns when this draft was originally >>>> posted. So I concur with what Carlos says. >>>> >>>> Cheers, Manav >>>> >>>> -- >>>> Sent from a mobile device >>>> >>>> On Apr 18, 2017 5:09 AM, "Carlos Pignataro (cpignata)" < >>>> cpignata@cisco.com> wrote: >>>> >>>> Jeff and Reshad, >>>> >>>> I do not support adoption of either draft-tanmir-rtgwg-bfd-mc-lag-ip-0= 1 >>>> or draft-tanmir-rtgwg-bfd-mc-lag-mpls-01. >>>> >>>> The overall problem and proposed solution did not seem to have receive= d >>>> much discussion. I was only able to find one email thread on the list,= over >>>> a year ago. >>>> >>>> Regarding the problem statement, it=E2=80=99s strange that there=E2=80= =99s no normative >>>> definition or anything to MG-LAG=E2=80=A6 further, the meeting notes f= rom IETF96 >>>> say things like: >>>> John Messenger: Would suggest work done in 802.1 to analyze >>>> those >>>> considerations with 802, it would be necessary to coordinate >>>> to work >>>> with them. Send a mail to IETF-IEEE802 coordination group. >>>> Jeff Haas: Can we sign you as a reviewer to this draft? >>>> >>>> What is the problem again, beyond what=E2=80=99s already well specifie= d in RFC >>>> 7130? Is this again a quick =E2=80=9Csolution=E2=80=9D looking for an = RFC number? >>>> >>>> Regarding the proposed solution, the one email thread seems to have >>>> pointed out some serious issues not considered: >>>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/OLWLCf6dn-3zxG >>>> ZboTKVqUwSr6w >>>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/nwfLfudDdNw7Py >>>> JbpP-RVnVFMcQ >>>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/EuRObko0JO40_4 >>>> UPB4buR0iyxcg >>>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/QUb5rj882TKeAA >>>> XyTof4ycq2DUg >>>> >>>> Additionally, why the split into two drafts for this? The text of both >>>> documents overall seems forgotten, even sloppy, with many typos (=E2= =80=9CMPSL=E2=80=9D, >>>> =E2=80=9CIndvidual=E2=80=9D, etc), and copy/paste text between the two= documents. The >>>> complete Introduction and Problem Statement are verbatim copy/paste, a= nd >>>> include things like: >>>> >>>> This document >>>> proposes how to overcome this problem if using IP or Multi-Protocol >>>> Label Switching (MPLS) data plane encapsulation. >>>> >>>> which is not the case for either document. >>>> >>>> Technically, using multicast here exercises a different path, and usin= g >>>> a GAL does as well. What are we testing? >>>> >>>> Net-net, do not support. >>>> >>>> Thanks, >>>> >>>> =E2=80=94 Carlos. >>>> >>>> On Apr 17, 2017, at 6:55 PM, Jeffrey Haas wrote: >>>> >>>> Working Group, >>>> >>>> https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-ip-00 >>>> https://datatracker.ietf.org/doc/draft-tanmir-rtgwg-bfd-mc-lag-mpls/ >>>> >>>> The authors of BFD on Multi-Chass Link Aggregation Group Interfaces fo= r >>>> IP >>>> and MPLS have requested BFD working group adoption for their drafts. >>>> >>>> These drafts were previously presented at IETF-96. >>>> >>>> Please note that IPR has been declare against these drafts. The IPR >>>> declaration may be found from the datatracker links. >>>> >>>> Please indicate your support/lack of support to the mailing list. >>>> >>>> -- Jeff and Reshad >>>> >>>> >>>> >>>> >>>> >>> >>> >> --001a113cf63eae4403054d75746f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Manav,
thank you for your consideration. If we agre= e that what single-hop BFD effectively monitors is the Layer 2 switched dom= ain, then we should pay attention to Layer 2 encapsulation. If uBFD impleme= ntation uses only the dedicated MAC address and does not switch to use of s= ource MAC address in received BFD control packets as described in the first= para Section 2.3 RFC 7130, then, I believe, it is possible that processing= of L2 frames might be different whether it carries data or uBFD.

Safe travel and regards,
Greg

On Tue, Apr 18, 2017 at 8= :46 AM, Manav Bhatia <manavbhatia@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
I don't know why you th= ink ubfd packets do not follow the regular data path?

=
I am traveling and have sporadic Internet connectiv= ity, so response can get delayed.=C2=A0

--
Sent from a mobile device <= /div>

On Apr 18, 2017 10:31 AM, &= quot;Greg Mirsky" <gregimirsky@gmail.com> wrote:
Hi Manav,
I agree that it= would be helpful to discuss whether using BFD to monitor Layer 2 connectiv= ity is the right approach. I'd point that from the Layer 2 perspective = uBFD is not following the same fast path processing as data packets either.= Thus there could be some scenarios when uBFD produces either false negativ= e or false positive results. And while we understand that, we agreed that t= hese are rather exceptions and that uBFD is useful to monitor constituent l= inks. I believe it is reasonable to have the same discussion about monitori= ng constituent links of a MC-LAG. Is it the problem that needs to be solved= ? Do these drafts that propose to extend use of uBFD offer technically reas= onable solution? These are the questions, per my understanding of WG adopti= on call, that we have in front of us.

Regards,
Greg

On Mon, Apr 17, 2017 at 9:10 PM, Manav Bhatia <<= a href=3D"mailto:manavbhatia@gmail.com" target=3D"_blank">manavbhatia@gmail= .com> wrote:
Then BFD is not the right tool. You should use/invent something el= se.=C2=A0

Cheers, = Manav=C2=A0

--<= br>Sent from a mobile device
On Apr 18, 2017 8:47 AM, "Greg Mirsky"= ; <gregimirsk= y@gmail.com> wrote:
Hi Manav,
single-hop BFD is helpful when the two BFD peers hav= e Layer 2 switched domain between them. If the nodes are connected by the s= ingle wire, then there's no apparent benefit of using BFD at all. The s= ame is the case for these two drafts. BFD is not intended to verify whether= forwarding tables are correlating with the routing tables but it is to ver= ify that a path exists between the BFD peers. In the case we've conside= red, the path through the Layer 2 switched domain. Thus I don't see tha= t traversing the same blocks in fast path processing on the end nodes of th= e single-hop IP link is the critical requirement. But if the working group = agrees that it is, then we'll be glad to work together to confirm with = such requirement.

Regards,
Greg=C2=A0

On Mon, Apr 17, 2017 at 6:42 PM, Manav Bhatia <= ;manavbhatia@gma= il.com> wrote:
I had raised the exact same concerns when this draft was originally p= osted. So I concur with what Carlos says.=C2=A0

=
Cheers, Manav=C2=A0

--
Sent from a mobile device

On Apr 18, 2017 5:09 AM, "C= arlos Pignataro (cpignata)" <cpignata@cisco.com> wrote:
Jeff and Reshad,

I do not support adoption of either draft-tanmir-rtgwg-bfd-mc-lag-ip-01 or draft-tanmir-rtgwg-bfd-mc-lag-mpls-01.

The overall problem and proposed solution did not seem to have receive= d much discussion. I was only able to find one email thread on the list, ov= er a year ago.

Regarding the problem statement, it=E2=80=99s strange that there=E2=80= =99s no normative definition or anything to MG-LAG=E2=80=A6 further, the me= eting notes from IETF96 say things like:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 John Messenger: Would suggest work = done in 802.1 to analyze those
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 considerations with 802, it would b= e necessary to coordinate to work
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with them. Send a mail to IETF-IEEE= 802 coordination group.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jeff Haas: Can we sign you as a rev= iewer to this draft?

What is the problem again, beyond what=E2=80=99s already well specifie= d in RFC 7130? Is this again a quick =E2=80=9Csolution=E2=80=9D looking for= an RFC number?

Regarding the proposed solution, the one email thread seems to have po= inted out some serious issues not considered:

Additionally, why the split into two drafts for this? The text of both= documents overall seems forgotten, even sloppy, with many typos (=E2=80=9C= MPSL=E2=80=9D, =E2=80=9CIndvidual=E2=80=9D, etc), and copy/paste text betwe= en the two documents. The complete Introduction and Problem Statement are verbatim copy/paste, and include things like:

=C2=A0 This document
=C2=A0 =C2=A0proposes how to overcome this problem if using IP or Mult= i-Protocol
=C2=A0 =C2=A0Label Switching (MPLS) data plane encapsulation.

which is not the case for either document.

Technically, using multicast here exercises a different path, and usin= g a GAL does as well. What are we testing?

Net-net, do not support.

Thanks,

=E2=80=94 Carlos.

On Apr 17, 2017, at 6:55 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:

Working Group,

https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-= mc-lag-ip-00
https://datatracker.ietf.org/doc/draft-tanmir-= rtgwg-bfd-mc-lag-mpls/

The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for IP<= br> and MPLS have requested BFD working group adoption for their drafts.

These drafts were previously presented at IETF-96.

Please note that IPR has been declare against these drafts.=C2=A0 The IPR declaration may be found from the datatracker links.

Please indicate your support/lack of support to the mailing list.

-- Jeff and Reshad








--001a113cf63eae4403054d75746f-- From nobody Thu Apr 20 07:53:07 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FF0129A96 for ; Thu, 20 Apr 2017 07:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9TAhy9qQ1ShL for ; Thu, 20 Apr 2017 07:53:04 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6AE129543 for ; Thu, 20 Apr 2017 07:53:04 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id r203so53641266oib.3 for ; Thu, 20 Apr 2017 07:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x4itSTOjmAAZm6tL4OKXOATL9dV00LqLEea6aBM1Eco=; b=pMhI/JoQHQl1dfJ5ozgGBMW0fda5hJbBPBYGgVf8qnBswPHocTxsvTcW9DwUd1LFTz o+jr6OAUq2CWk0i39WcoSBJ/AqpHcUnGQ7Myg66aae+pDbB5HthCjdm6pqG+yU64K/qD C2y3OpayfxeKqevWmHoWdgqqtuZxUct5JKdcB2VJT0NzDun0mp9JvnsGQXuLguhdoTMS nxodZIoXsh2ZC0MF1gOtzWrqicR0RPUoXFj5hNMqMD8o6NqygVUlwOjfh3vNWKcczV8h M4hKYuQ+bkznZyizM7eLg5ZsgL3x17tgkV6pPxiBGtQTmQS1oYjyZqzPQF3SEPZz+7mg RDqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x4itSTOjmAAZm6tL4OKXOATL9dV00LqLEea6aBM1Eco=; b=h9f5KiibRUaX4LbtiW8S5L2mhSSanuf+rFdDM2HVnI+a4ikhWgWh3GGqHb8OV9tUVu 7sSjmjnZTH3b4Y7/dzuk6vuSUplLlJKD9gnzqeGrayQdsXmA9r3B5bmNIwIUqXBwVui1 fYPAY6+Icucx0sW2JfxknT6eGz9o8dBJN9ckj9EzKYQSPIOdZmrhysDhTbTALfxsHTJQ AIxYFy/IM44/R0o5kVnFUTg8WlMqyIOtILColE8jGDHtLUb55YM0jt3vsujgiH0dP8mM VmFiO3wGUIQ3OZJ3CNoyDF9tTx0/Qgk9yheJ/uyTaFg5KGlNufNfxufgMI3jmcRUwqY3 p1cA== X-Gm-Message-State: AN3rC/59iUzvhotWEaLIw3O6V8aQmDujP2gZu2sVVC6wPBX2l/vGkAYS NM/puQNjVcaO9EC/2shv82Dcoe3G7w== X-Received: by 10.202.253.84 with SMTP id b81mr4021589oii.54.1492699983508; Thu, 20 Apr 2017 07:53:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.178 with HTTP; Thu, 20 Apr 2017 07:53:03 -0700 (PDT) In-Reply-To: <20170417225539.GE18219@pfrc.org> References: <20170417225539.GE18219@pfrc.org> From: Greg Mirsky Date: Thu, 20 Apr 2017 07:53:03 -0700 Message-ID: Subject: Re: Adoption call for draft-tanmir-rtgwg-bfd-mc-lag-* (ends April 30, 2017) To: Jeffrey Haas Cc: "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=001a113d3cc845fbbb054d9a4c16 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 14:53:06 -0000 --001a113d3cc845fbbb054d9a4c16 Content-Type: text/plain; charset=UTF-8 Hi Jeff, Reshad, et. al, support as co-author. Regards, Greg On Mon, Apr 17, 2017 at 3:55 PM, Jeffrey Haas wrote: > Working Group, > > https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-ip-00 > https://datatracker.ietf.org/doc/draft-tanmir-rtgwg-bfd-mc-lag-mpls/ > > The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for IP > and MPLS have requested BFD working group adoption for their drafts. > > These drafts were previously presented at IETF-96. > > Please note that IPR has been declare against these drafts. The IPR > declaration may be found from the datatracker links. > > Please indicate your support/lack of support to the mailing list. > > -- Jeff and Reshad > > > --001a113d3cc845fbbb054d9a4c16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jeff, Reshad, et. al,
support as co-author.

Regards,
Greg

On Mon, Apr 17, 2017 at 3:55 PM, Jeffre= y Haas <jhaas@pfrc.org> wrote:
https://tools.ietf.org/html/draf= t-tanmir-rtgwg-bfd-mc-lag-ip-00
https://datatracker.ietf.org/doc/draft-tanmir-rtgwg-bfd-mc-lag-mpls/

The authors of BFD on Multi-Chass Link Aggregation Group Interfaces for IP<= br> and MPLS have requested BFD working group adoption for their drafts.

These drafts were previously presented at IETF-96.

Please note that IPR has been declare against these drafts.=C2=A0 The IPR declaration may be found from the datatracker links.

Please indicate your support/lack of support to the mailing list.

-- Jeff and Reshad



--001a113d3cc845fbbb054d9a4c16-- From nobody Thu Apr 20 23:23:52 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2BF12941C for ; Thu, 20 Apr 2017 23:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 XZMC5Lydeoe3 for ; Thu, 20 Apr 2017 23:23:48 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B49E128BB7 for ; Thu, 20 Apr 2017 23:23:48 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id k87so106003037ioi.0 for ; Thu, 20 Apr 2017 23:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FpRfxzEAaxAwJpbsWv+i1wlIEeV30QwJ5j/OWMgEYRw=; b=f39SapiuaDfz0Vrd0ywRPq04JuI45b4gF8ubDUW859a9sGzd+41VjZGHQ0nclcRZXz TUf44M6nnZT0ucHGdidZFrdHdAaFPKRBG00rEncDRGlIvDh4RxtcTMilu4FmpZmoXvgP IbvNElasRTUea1PI/h0oz6t90IEQ9L5Wg9Psn3+KBsz1WCS3gUEjAtEueXF726vRmwbm 1tP4VqzbuCMJoK08bGqqksRx+Jppy7YD2NpGjtEIUOkr+RbvLxKAJDOzoWZbp/zmyZAm x4UfBoNyv7HALdTRnrjkareMHhmSFpQXA4ROH3f34E02l109zFB3OzqmXD/nU855HNQT Xwfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FpRfxzEAaxAwJpbsWv+i1wlIEeV30QwJ5j/OWMgEYRw=; b=JStcdiMsP5jodq71PV0FxF+UB4VRmC1+7KLDTuhSJ7vPrIRBCNAEB/3vvu/kRjRb2y lF08END529qmQedwE0WpaliAe+c1R0Is8wyPNIk6xvpgioDCFdvhLzPHkmH3RNfEFqE1 Iq9ORxOOZ7mK8wNx97I42eU5tCJW3eGW4cODWLSnUHF/xhAngNXEju/uQR9OQjg91KFv pcSFIGbWAToggnZslI3vwXv4AvITM1+Z13EuwuG0FuSIu9DXXemftQyD9Az0VbTTl19r imQLozXZ1tUiao/ndkWM2odWKfWm+udOGNTxH/Bhif0vZl20GIz7ksd5y9wzC51hD0YQ vKcQ== X-Gm-Message-State: AN3rC/7zc3X1RlTyIOufDLeTfWGK0GbuSpUc0dIKeV+zgl06mqbsZi9u K8pJOYdYe8gETOAImCysLHglNA8gAw== X-Received: by 10.107.32.199 with SMTP id g190mr14614998iog.117.1492755827880; Thu, 20 Apr 2017 23:23:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.29.3 with HTTP; Thu, 20 Apr 2017 23:23:47 -0700 (PDT) In-Reply-To: References: <20170417213947.GC18219@pfrc.org> From: Santosh P K Date: Fri, 21 Apr 2017 11:53:47 +0530 Message-ID: Subject: Re: Adoption call for draft-ashesh-bfd-stability (ends April 30, 2017) To: Manav Bhatia Cc: Jeffrey Haas , rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=001a1140338adb79a5054da74c63 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 06:23:50 -0000 --001a1140338adb79a5054da74c63 Content-Type: text/plain; charset=UTF-8 support. On Tue, Apr 18, 2017 at 7:07 AM, Manav Bhatia wrote: > Support > > -- > Sent from a mobile device > > On Apr 18, 2017 3:02 AM, "Jeffrey Haas" wrote: > >> Working Group, >> >> https://tools.ietf.org/html/draft-ashesh-bfd-stability-05 >> >> The authors of BFD Stability (draft-ashesh-bfd-stability), presented their >> latest changes at IETF 98 in Chicago and have requested working group >> adoption. >> >> Please indicate your support or lack of support to the mailing list. >> >> -- Jeff and Reshad >> >> --001a1140338adb79a5054da74c63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
support.

On Tue, Apr 18, 2017 at 7:07 AM, Manav Bhatia <manavbhat= ia@gmail.com> wrote:
Support

--
Se= nt from a mobile device

On Apr 18, 2017 = 3:02 AM, "Jeffrey Haas" <jhaas@pfrc.org> wrote:
Working Group,

https://tools.ietf.org/html/draft-as= hesh-bfd-stability-05

The authors of BFD Stability (draft-ashesh-bfd-stability), presented their<= br> latest changes at IETF 98 in Chicago and have requested working group
adoption.

Please indicate your support or lack of support to the mailing list.

-- Jeff and Reshad


--001a1140338adb79a5054da74c63-- From nobody Sun Apr 23 23:47:44 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDEB128B93; Sun, 23 Apr 2017 23:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xezFoJMezYZ2; Sun, 23 Apr 2017 23:47:34 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070E4128ACA; Sun, 23 Apr 2017 23:47:34 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id k87so182181564ioi.0; Sun, 23 Apr 2017 23:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=rKj3K1tew4R622kegZb2Uz44Pi9WQ/OrvJW45SEVpYQ=; b=l5VllyuU+kC06XWGQBYsknU6MFMYgWmu7WSN92LX/kJCGJ9ykmWt1dSXaXk8v3PDl9 b6fwsApIpsUvkllA3+h4sCkyYz+npRja2/A44LqAiFA6BsDR5SVWarIkqpDZjSfmAdRR IzfaQ0+AMIko7IObF0qLXfp7yv7yhHXvWXjeeSSxR9WKncPcTHlCdVIgaiJR0IOR6PGV X8cyWWAGsQNlNrfWHPpBklVrQWTbCyYP6TUsAOUNDzamoFl6yP0l/fwSPCIpuASuORT5 4PvaTNaqVSwW2/vRJjmg92bK1yCcV9k0g8pymxsv/JOms5radH976HMdYmzgCFW2a642 BXCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=rKj3K1tew4R622kegZb2Uz44Pi9WQ/OrvJW45SEVpYQ=; b=k94r3LM8eqmw5hVOfSypkWIcH6LjPu3CgY2LL8Nv7cTOQkpbQefinGHpBHpq87om9Z VbT6/KAK5nDKti42ASO/xt8NlsPftH2X+ObCArCHyq7f6vGJk3EYoIG6wa0wuCUlhAUb unWpi/NUiE8m4lWn1efmc75JJOYKpJ0R5I62Dy5pv0ETvxr+SXZnBRA4nySZ84e7RBb+ le9r5ZXWrQSxX31DCinAhoBsH/t8fLWM8dXJ/owYzrwCiRaL6Ap4uAgXw00p3cGAwPlv rJmaicmq4uA/2C7yiqQPwLCjc5YMKmFB8qqkImT49FllNSnMck/mbX3br3iz4GokVqvJ rALw== X-Gm-Message-State: AN3rC/70j9KW0TvPyMXb02DTVHFyMZCEM7Iqw9BB25StSKEuG3IZz6bW ueAunN4sNb6KoPVclE23iqCtU8ArTwPV X-Received: by 10.202.4.83 with SMTP id 80mr13384714oie.196.1493016453301; Sun, 23 Apr 2017 23:47:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.118 with HTTP; Sun, 23 Apr 2017 23:47:32 -0700 (PDT) In-Reply-To: <149301621692.25816.13124720680765306194.idtracker@ietfa.amsl.com> References: <149301621692.25816.13124720680765306194.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Sun, 23 Apr 2017 23:47:32 -0700 Message-ID: Subject: Fwd: New Version Notification for draft-mirsky-mpls-p2mp-bfd-00.txt To: "rtg-bfd@ietf.org" , "mpls@ietf.org" Content-Type: multipart/alternative; boundary=001a113c037c57cb6f054de3fb91 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2017 06:47:36 -0000 --001a113c037c57cb6f054de3fb91 Content-Type: text/plain; charset=UTF-8 Dear All, the new draft is intended to define use of draft-ietf-bfd-multipoint over MPLS p2mp LSP. Appreciate your comments, qustions, and suggestions. Regards, Greg ---------- Forwarded message ---------- From: Date: Sun, Apr 23, 2017 at 11:43 PM Subject: New Version Notification for draft-mirsky-mpls-p2mp-bfd-00.txt To: Gregory Mirsky A new version of I-D, draft-mirsky-mpls-p2mp-bfd-00.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-mpls-p2mp-bfd Revision: 00 Title: BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP Document date: 2017-04-21 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-mirsky-mpls-p2mp- bfd-00.txt Status: https://datatracker.ietf.org/doc/draft-mirsky-mpls-p2mp-bfd/ Htmlized: https://tools.ietf.org/html/draft-mirsky-mpls-p2mp-bfd-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-mpls- p2mp-bfd-00 Abstract: This document describes procedures for using Bidirectional Forwarding Detection (BFD) for multipoint networks to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp) Label Switched Paths (LSPs). It also describes applicability of out- band solutions to bootstrap a BFD session in this environment. 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 --001a113c037c57cb6f054de3fb91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,
the new draft is intended to define use of d= raft-ietf-bfd-multipoint over MPLS p2mp LSP.
Appreciate your comm= ents, qustions, and suggestions.

Regards,
Greg

---------- Forwarded messag= e ----------
From: = <internet-drafts@ietf.org>
Date: Sun, Apr 23, 2017 at 11:43 PM
Subject: New Version= Notification for draft-mirsky-mpls-p2mp-bfd-00.txt
To: Gregory Mirsky &= lt;gregimirsky@gmail.com>


A new version of I-D, draft-mirsky-mpls-p2mp-bfd-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-mpls-p2mp-bfd Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BFD for Multipoint Networks over P= oint-to-Multi-Point MPLS LSP
Document date:=C2=A0 2017-04-21
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-mpls= -p2mp-bfd-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mirsky-mpls-p2mp-bfd/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /tools.ietf.org/html/draft-mirsky-mpls-p2mp-bfd-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mirsky-mpls-p2mp-b= fd-00


Abstract:
=C2=A0 =C2=A0This document describes procedures for using Bidirectional For= warding
=C2=A0 =C2=A0Detection (BFD) for multipoint networks to detect data plane f= ailures
=C2=A0 =C2=A0in Multiprotocol Label Switching (MPLS) point-to-multipoint (p= 2mp)
=C2=A0 =C2=A0Label Switched Paths (LSPs).=C2=A0 It also describes applicabi= lity of out-
=C2=A0 =C2=A0band solutions to bootstrap a BFD session in this environment.=




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


--001a113c037c57cb6f054de3fb91-- From nobody Mon Apr 24 06:47:31 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D26131539 for ; Mon, 24 Apr 2017 06:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 DWwS4flxk5vE for ; Mon, 24 Apr 2017 06:47:28 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369AD131531 for ; Mon, 24 Apr 2017 06:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8825; q=dns/txt; s=iport; t=1493041647; x=1494251247; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DciyYOyMB24l88Flo4PrTj7qQlArLOVM+X9cfyognRk=; b=BZNvZVT65Fj7Kzmwpkcxx66VtvajDA9MBNq4mMB+BhKt7U/++TbYAo5a NZPLXeJkWxgIpw9a27hs7sy+M5idGYfO4h21wHffNl4ETzzkbds0f6idb lSmyKx6RimSHBMUB51UxBJRIchWZkda9wqDPyjHlSF8cgyTSo8Hbk0dfv Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAQCVAf5Y/4YNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm47K4FtB4NgihWRaII8hWSIEIU1gg+GJAIag3E/GAECAQEBAQE?= =?us-ascii?q?BAWsohRUBAQEBAx1RCxACAQYCEQMBAigFAgIwEwEGAwgCBAENBRuJaQMVjU2dW?= =?us-ascii?q?AiCJIsbAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZThHaBPIEVgh0JgmKCYwWHXQy?= =?us-ascii?q?BUYQ0iFuGPTsBjkKEQ4IAhTOFKIR8ixKJBgEfOIEGYxVEhGgNEBkZgTF1iCmBD?= =?us-ascii?q?QEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,244,1488844800"; d="scan'208,217";a="240436435" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Apr 2017 13:47:27 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v3ODlRFD009576 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Apr 2017 13:47:27 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 24 Apr 2017 08:47:26 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Mon, 24 Apr 2017 08:47:26 -0500 From: "Reshad Rahman (rrahman)" To: LuHuang , Jeffrey Haas , "rtg-bfd@ietf.org" , Mahesh Jethanandani CC: "Sonal Agarwal (agarwaso)" Subject: =?gb2312?B?UmU6ILvYuLSjuiBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1zb25hbC1iZmQt?= =?gb2312?Q?secure-sequence-numbers_(ending_April_30,_2017)?= Thread-Topic: =?gb2312?B?u9i4tKO6IEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXNvbmFsLWJmZC1zZWN1?= =?gb2312?Q?re-sequence-numbers_(ending_April_30,_2017)?= Thread-Index: AQHSt8GOym0WvtZ2iE2jKJQ4DD+/I6HKqBaAgAn7twA= Date: Mon, 24 Apr 2017 13:47:26 +0000 Message-ID: References: <20170417213533.GB18219@pfrc.org> <638481980.2346797.1492478397080@mail.yahoo.com> In-Reply-To: <638481980.2346797.1492478397080@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.248.73] Content-Type: multipart/alternative; boundary="_000_D52373472840C9rrahmanciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 24 Apr 2017 13:47:30 -0000 --_000_D52373472840C9rrahmanciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 TWFoZXNoLCBzaG91bGQgdGhhdCBiZSBhZGRlZCB0byBkcmFmdC1pZXRmLWJmZC1vcHRpbWl6aW5n LWF1dGhlbnRpY2F0aW9uPw0KDQpGcm9tOiBSdGctYmZkIDxydGctYmZkLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBMdUh1YW5n IDxobGlzbmFtZUB5YWhvby5jb208bWFpbHRvOmhsaXNuYW1lQHlhaG9vLmNvbT4+DQpSZXBseS1U bzogTHVIdWFuZyA8aGxpc25hbWVAeWFob28uY29tPG1haWx0bzpobGlzbmFtZUB5YWhvby5jb20+ Pg0KRGF0ZTogTW9uZGF5LCBBcHJpbCAxNywgMjAxNyBhdCA5OjE5IFBNDQpUbzogSmVmZnJleSBI YWFzIDxqaGFhc0BwZnJjLm9yZzxtYWlsdG86amhhYXNAcGZyYy5vcmc+PiwgInJ0Zy1iZmRAaWV0 Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+IiA8cnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86 cnRnLWJmZEBpZXRmLm9yZz4+DQpDYzogUmVzaGFkIDxycmFobWFuQGNpc2NvLmNvbTxtYWlsdG86 cnJhaG1hbkBjaXNjby5jb20+PiwgIlNvbmFsIEFnYXJ3YWwgKGFnYXJ3YXNvKSIgPGFnYXJ3YXNv QGNpc2NvLmNvbTxtYWlsdG86YWdhcndhc29AY2lzY28uY29tPj4NClN1YmplY3Q6ILvYuLSjuiBB ZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1zb25hbC1iZmQtc2VjdXJlLXNlcXVlbmNlLW51bWJlcnMg KGVuZGluZyBBcHJpbCAzMCwgMjAxNykNCg0KWWVzLi8gc3VwcG9ydA0KDQpCdXQgSSB0aGluayBv bmUgcHJvYmxlbSBzaG91bGQgYmUgY29uc2lkZXJlZC4gSWYgcGFja2V0IGxvc3MgaGFwcGVucywg dGhlIHNlcXVlbmNlIG51bWJlciBvZiByZWNlaXZlZCBwYWNrZXQgd29uJ3QgYmUgdGhlIGV4cGVj dGVkIG51bWJlciBvciBoYXNoIHZhbHVlLCB3aGljaCBzaG91bGQgYmUgZGlzdGluZ3Vpc2hlZCBm cm9tIG1hbGljaW91cyBwYWNrZXQuDQoNClRoYW5rcy4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0N Ckx1SHVhbmcNCkNoaW5hIE1vYmlsZSBSZXNlYXJjaCBJbnN0aXR1dGUNCk1vYmlsZTogKzg2IDEz ODEwODIwNTQwDQoNCg0KSmVmZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9yZzxtYWlsdG86amhhYXNA cGZyYy5vcmc+PiDT2iAyMDE3xOo01MIxOMjVLCDQx8batv4sIMnPzucgNToyOCDQtLXAo7oNCg0K DQpXb3JraW5nIEdyb3VwLA0KDQpBcyBwYXJ0IG9mIG91ciBkaXNjdXNzaW9uIGF0IHRoZSBXb3Jr aW5nIEdyb3VwIHNlc3Npb24gYXQgSUVURiA5OCBpbg0KQ2hpY2FnbywgU29uYWwgQWdhcndhbCBw cmVzZW50ZWQgIlNlY3VyZSBCRkQgU2VxdWVuY2UgTnVtYmVycyINCihkcmFmdC1zb25hbC1iZmQt c2VjdXJlLXNlcXVlbmNlLW51bWJlcnMtMDApLiAgVGhpcyB3b3JrIGNvbXBsZW1lbnRzIGENCnBy b2JsZW0gc3BhY2UgdGhlIFNlY3VyaXR5IGFyZWEgaGFkIGFza2VkIHVzIHRvIGFkZHJlc3MgYXMg cGFydCBvZiB0aGUgd29yaw0Kb24gb3B0aW1pemluZyBCRkQgYXV0aGVudGljYXRpb24sIG91ciBh ZG9wdGVkDQpkcmFmdC1pZXRmLWJmZC1vcHRpbWl6aW5nLWF1dGhlbnRpY2F0aW9uLg0KDQpUaGUg ZGlzY3Vzc2lvbiBvbiB0aGUgaW1wbGVtZW50YXRpb24gaW1wbGljdGlvbnMgb2YgdGhlIG9wdGlt aXppbmcNCmF1dGhlbnRpY2F0aW9uIGRyYWZ0IHdhcyBlbmVyZ2V0aWMgdGhpcyBsYXN0IElFVEYu ICBUbyBkcml2ZSB0aGF0IHNvbHV0aW9uDQpmdXJ0aGVyIGFsb25nLCB3ZSB3aWxsIG5lZWQgYSB0 ZWNobm9sb2d5IHNpbWlsYXIgdG8gdGhlIG9uZSBpbiB0aGUgcHJvcG9zYWwuDQoNClRoaXMgc3Rh cnRzIGEgMiB3ZWVrIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXNvbmFsLWJmZC1zZWN1cmUtc2Vx dWVuY2UtbnVtYmVycy4NClBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQgb3IgbGFjayBvZiBz dXBwb3J0IGZvciB0aGUgcHJvcG9zYWwgdG8gdGhlDQptYWlsaW5nIGxpc3QuDQoNCk5vdGUgdGhh dCBwYXJ0IG9mIHRoZSBkaXNjdXNzaW9uIHdhcyB0aGF0IG9wdGltaXppbmcgQkZEIGlzIG5vdCBy ZWFkeSB0bw0KcHJvY2VlZCB0byBMYXN0IENBbGwgdW50aWwgd2UndmUgYWRvcHRlZCBzdWNoIGEg cHJvcG9zYWwgYW5kIGhhdmUNCnByb3Blcmx5IGludGVncmF0ZWQgaXQgaW50byB0aGUgb3B0aW1p emF0aW9uIHByb2NlZHVyZXMuDQoNCi0tIEplZmYgYW5kIFJlc2hhZA0KDQoNCg0K --_000_D52373472840C9rrahmanciscocom_ Content-Type: text/html; charset="gb2312" Content-ID: <938C65B248B0B245AE4E12040A50D08C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Mahesh, should that be added to draft-ietf-bfd-optimizing-authenticati= on?

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Lu= Huang <hlisname@yahoo.com><= br> Reply-To: LuHuang <hlisname@yahoo.com>
Date: Monday, April 17, 2017 at 9:1= 9 PM
To: Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Cc: Reshad <rrahman@cisco.com>, "Sonal Agarwal (agarwaso)&= quot; <agarwaso@cisco.com><= br> Subject: =BB=D8=B8=B4=A3=BA Adoptio= n call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017)<= br>

Yes./ support

But I think one problem s= hould be considered. If packet loss happens, the sequence number of receive= d packet won't be the expected number or hash value, which should be distin= guished from malicious packet.

Thanks.
 
-----= ---------------
LuHuang
China Mobile Research Institute
Mobile: +86 13810820540
<= br>
Jeffrey Haa= s <jhaas@pfrc.org> =D3=DA 2017= =C4=EA4=D4=C218=C8=D5, =D0=C7=C6=DA=B6=FE, =C9=CF=CE=E7 5:28 =D0=B4=B5=C0= =A3=BA


Working Group,

As part of our discussion at the Working Group session at IETF 98 in
Chicago, Sonal Agarwal presented "Secure BFD Sequence Numbers" (draft-sonal-bfd-secure-sequence-numbers-00).  This work complements a=
problem space the Security area had asked us to address as part of the work=
on optimizing BFD authentication, our adopted
draft-ietf-bfd-optimizing-authentication.

The discussion on the implementation implictions of the optimizing
authentication draft was energetic this last IETF.  To drive that solu= tion
further along, we will need a technology similar to the one in the proposal= .

This starts a 2 week adoption call for draft-sonal-bfd-secure-sequence-numb= ers.
Please indicate your support or lack of support for the proposal to the
mailing list.

Note that part of the discussion was that optimizing BFD is not ready to proceed to Last CAll until we've adopted such a proposal and have
properly integrated it into the optimization procedures.

-- Jeff and Reshad



 --_000_D52373472840C9rrahmanciscocom_-- From nobody Tue Apr 25 00:12:17 2017 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B9812025C; Tue, 25 Apr 2017 00:12:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-multipoint-active-tail-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149310432837.20766.10803298847728546326@ietfa.amsl.com> Date: Tue, 25 Apr 2017 00:12:08 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 07:12:08 -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 of the IETF. Title : BFD Multipoint Active Tails. Authors : Dave Katz Dave Ward Santosh Pallagatti Filename : draft-ietf-bfd-multipoint-active-tail-04.txt Pages : 17 Date : 2017-04-25 Abstract: This document describes active tail extensions to the Bidirectional Forwarding Detection (BFD) protocol for multipoint and multicast networks. Comments on this draft should be directed to rtg- bfd@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-multipoint-active-tail-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-active-tail-04 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 Tue Apr 25 00:16:11 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5DE128768 for ; Tue, 25 Apr 2017 00:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 b61sIl2u8Dt7 for ; Tue, 25 Apr 2017 00:16:07 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4234D1317A7 for ; Tue, 25 Apr 2017 00:16:05 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id g66so13524816ite.1 for ; Tue, 25 Apr 2017 00:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=nNJifnSJXj7GV5zFKoXButEkwCw2glQdeei4ckV/8iY=; b=YWXqbwF703VeUMErwFtzLTXSWM48klOWOpCMydzIJ43GSxe+rIMX2CXY16hBA+6M1Y WxvEanq4bVCXa/sQXx6y63KtYTP8KwGHrJaKTezVZ99v2/It3h7fh6TRzBslREQq9WlX UX8pcYYLL+I6XrPq/IAwCwjZVojQnqKFYA/O4dQYJ+4CHRCXjssv7gy1OHS6ol2kfzcK b1FLGHChwjYazCA3GHcqg+03IUxgOF1QIqBL5s7a1dLn5Rjq/mP4tEBKdO+hITLr11Tf 3cv0OnhyfdDm+CGpM4GzJ40VG7J63yBn+2dFg1hHs42R09TSYOCjACiC1FCytU07D4mz /ofg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=nNJifnSJXj7GV5zFKoXButEkwCw2glQdeei4ckV/8iY=; b=CkSI9F9TgU5oAhmiP/QYQtMmNPpEqPtcYSYqXK6NC9Mkk9HY7TRL6Ih4FshVsyrQtP 8u+6Nwb3cmf5yffuN4NpqGe6vt1jIUmiqHmadvgm2OBjzemw0w8RHjUhx97DA0U+4gf5 iN025Y0G0Jp/JGADwTjSV1Jzjd9hqSomg4Tm2t3x+AuoO6b7vv2hSrZNfVC9N8mxvReV 9glNeqAhFkp5LBh8MfHW6L0TlD5QFfSYQ7y0uXncvqRjF37tOkFlK9dRqjAJJWkS6Mww L6lsP1MKSvnCxes8luSkw6C0SZrIx8zh83ZX15NS44FOHfaQ7+uK2iI/W9MPYfc0RatC BkwQ== X-Gm-Message-State: AN3rC/7/kzOA4URKh8ZJEvb7mjSFCvSXhcfF4pprzVmV8P76lqBawoDc V+qZ2iO3tkiRJZp+LeDGEp6HXBl1EA== X-Received: by 10.36.80.194 with SMTP id m185mr2701750itb.24.1493104564526; Tue, 25 Apr 2017 00:16:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.29.3 with HTTP; Tue, 25 Apr 2017 00:16:04 -0700 (PDT) In-Reply-To: <149310432852.20766.12914755996983133809.idtracker@ietfa.amsl.com> References: <149310432852.20766.12914755996983133809.idtracker@ietfa.amsl.com> From: Santosh P K Date: Tue, 25 Apr 2017 12:46:04 +0530 Message-ID: Subject: Fwd: New Version Notification for draft-ietf-bfd-multipoint-active-tail-04.txt To: rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=001a114497302e8a91054df87f49 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 07:16:10 -0000 --001a114497302e8a91054df87f49 Content-Type: text/plain; charset=UTF-8 Hello All, Sorry for delay in refreshing multi point tail document. There is no change in the text. Thanks Santosh P K ---------- Forwarded message ---------- From: Date: Tue, Apr 25, 2017 at 12:42 PM Subject: New Version Notification for draft-ietf-bfd-multipoint- active-tail-04.txt To: Dave Katz , David Ward , Santosh Pallagatti , bfd-chairs@ietf.org A new version of I-D, draft-ietf-bfd-multipoint-active-tail-04.txt has been successfully submitted by Santosh Pallagatti and posted to the IETF repository. Name: draft-ietf-bfd-multipoint-active-tail Revision: 04 Title: BFD Multipoint Active Tails. Document date: 2017-04-25 Group: bfd Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-ietf-bfd-multipoi nt-active-tail-04.txt Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint- active-tail/ Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-multipoint-activ e-tail-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-multip oint-active-tail-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint -active-tail-04 Abstract: This document describes active tail extensions to the Bidirectional Forwarding Detection (BFD) protocol for multipoint and multicast networks. Comments on this draft should be directed to rtg- bfd@ietf.org. 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 --001a114497302e8a91054df87f49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All,
=C2=A0 =C2=A0 =C2=A0Sorry for delay in refr= eshing multi point tail document. There is no change in the text.

Thanks
Santosh P K

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Dat= e: Tue, Apr 25, 2017 at 12:42 PM
Subject: New Version Notification for d= raft-ietf-bfd-multipoint-active-tail-04.txt
To: Dave Katz <dkatz@juniper.net>= , David Ward <wardd= @cisco.com>, Santosh Pallagatti <santosh.pallagatti@gmail.com>= , bfd-chairs@ietf.= org



A new version of I-D, draft-ietf-bfd-multipoint-active-tail-04.txt
has been successfully submitted by Santosh Pallagatti and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-multipoint-act= ive-tail
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A004
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BFD Multipoint Active Tails.
Document date:=C2=A0 2017-04-25
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bfd
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 17
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-= ietf-bfd-multipoint-active-tail-04.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint= -active-tail/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-= tail-04
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-bfd-mul= tipoint-active-tail-04
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-b= fd-multipoint-active-tail-04

Abstract:
=C2=A0 =C2=A0This document describes active tail extensions to the Bidirect= ional
=C2=A0 =C2=A0Forwarding Detection (BFD) protocol for multipoint and multica= st
=C2=A0 =C2=A0networks.=C2=A0 Comments on this draft should be directed to r= tg-
=C2=A0 =C2=A0bfd@ietf.org= .





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


--001a114497302e8a91054df87f49-- From nobody Tue Apr 25 00:23:12 2017 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BD512708C; Tue, 25 Apr 2017 00:23:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-multipoint-10.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149310498450.24864.15460869454660511964@ietfa.amsl.com> Date: Tue, 25 Apr 2017 00:23:04 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 07:23:04 -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 of the IETF. Title : BFD for Multipoint Networks Authors : Dave Katz Dave Ward Santosh Pallagatti Filename : draft-ietf-bfd-multipoint-10.txt Pages : 18 Date : 2017-04-25 Abstract: This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg- bfd@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-multipoint-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-10 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 Tue Apr 25 00:24:42 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43DE128896 for ; Tue, 25 Apr 2017 00:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6atI0QW3FV3x for ; Tue, 25 Apr 2017 00:24:40 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4083D12708C for ; Tue, 25 Apr 2017 00:24:40 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id r16so203798230ioi.2 for ; Tue, 25 Apr 2017 00:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=OVT/2Px0lRhozxkoXjlB6Y/Chn/n5+P5P2zUH1Hkl4k=; b=gndnR8IrOXBIrtrs6bRqYSEwfVUtOUw504m56nAnUHzvog4C+BPp4/zVs92xopDWhM 9eKvKmmyrKT65oQQVctIoM7DuMuvfr7URwgovuks7Z43sbfEmuuknoSLzDBJVi3dv9PM HVs16mmZUIo4SYaVdVcXruDOhgXG2K9t09i0PcBjau1licLpM1eA7TR0576Ilulf3526 RFvuiehQ3IyW0Ynp13QwAfC4M5SFHB6Wlw6LobnetgFat9MlIQOvTC0sQkyCOL6LqFXz hEJrFI+oQF9paShIID+zZbGhihUESunKbweqitPRgd3aVTPzuf+GoIpYXQMSc/OPB/qE HyeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=OVT/2Px0lRhozxkoXjlB6Y/Chn/n5+P5P2zUH1Hkl4k=; b=Npb83S3bvaJ4q0Y/45+HV7rJtQ9ym1p61TXIBeQc14kxAQoSlwJ3/R6JJ3EtztYzE9 HMuEZ8EhW76WztgvmcMuvyAuiMp3nCO0PFeN/Y6Gx1P9mNmc2hyQ2wDRLjLqx2qfhkrr zgHChgCoozKChLg1x1OMSuXwAhZFDM2oTxxMVSM9uoC0ZEyjSwL0mBqJkExvVLVfyfv6 gdxFYeMJe7mkrUbdVzU4wx7lsAtLgQuE1ODjo/VWZlxHViiQftS4y3UVbi1Zl7r3dEBm ng6/nQHUajaFw776FicEWzN2qr3Ou6f+NIXrhH1pnT1IDkrWADlYnD810nawfMGANJNb kzPw== X-Gm-Message-State: AN3rC/4nbPehBNfK4Oqddn1+D0rtwfG/yOhmwZe1YbmesGXi8d9/KbpK Y6OUxf+Z2In4Bje57QPGzsTZPV/S2pwp X-Received: by 10.107.46.215 with SMTP id u84mr13961314iou.147.1493105079413; Tue, 25 Apr 2017 00:24:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.29.3 with HTTP; Tue, 25 Apr 2017 00:24:39 -0700 (PDT) In-Reply-To: <149310498465.24864.16078211767715499234.idtracker@ietfa.amsl.com> References: <149310498465.24864.16078211767715499234.idtracker@ietfa.amsl.com> From: Santosh P K Date: Tue, 25 Apr 2017 12:54:39 +0530 Message-ID: Subject: Fwd: New Version Notification for draft-ietf-bfd-multipoint-10.txt To: rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=001a11c1564cdf1a45054df89d76 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 07:24:42 -0000 --001a11c1564cdf1a45054df89d76 Content-Type: text/plain; charset=UTF-8 Hello All, Refresh of BFD multipoint document. There is no change in text. Thanks Santosh P K ---------- Forwarded message ---------- From: Date: Tue, Apr 25, 2017 at 12:53 PM Subject: New Version Notification for draft-ietf-bfd-multipoint-10.txt To: Dave Katz , David Ward , Santosh Pallagatti , bfd-chairs@ietf.org A new version of I-D, draft-ietf-bfd-multipoint-10.txt has been successfully submitted by Santosh Pallagatti and posted to the IETF repository. Name: draft-ietf-bfd-multipoint Revision: 10 Title: BFD for Multipoint Networks Document date: 2017-04-25 Group: bfd Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-ietf-bfd- multipoint-10.txt Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bfd- multipoint-10 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd- multipoint-10 Abstract: This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg- bfd@ietf.org. 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 --001a11c1564cdf1a45054df89d76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All,
=C2=A0 =C2=A0Refresh of BFD mult= ipoint document. There is no change in text.

Thank= s
Santosh P K

---------- Forw= arded message ----------
From: <internet-drafts= @ietf.org>
Date: Tue, Apr 25, 2017 at 12:53 PM
Subject:= New Version Notification for draft-ietf-bfd-multipoint-10.txt
To: Dave = Katz <dkatz@juniper.net>, Da= vid Ward <wardd@cisco.com>, Sa= ntosh Pallagatti <santos= h.pallagatti@gmail.com>, bfd-= chairs@ietf.org



A new version of I-D, draft-ietf-bfd-multipoint-10.txt
has been successfully submitted by Santosh Pallagatti and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-multipoint
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A010
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BFD for Multipoint Networks
Document date:=C2=A0 2017-04-25
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bfd
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 18
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-bfd-multipoint-10.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-ietf-bfd-multipoint-10
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-bfd-multipoint= -10
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-mu= ltipoint-10

Abstract:
=C2=A0 =C2=A0This document describes extensions to the Bidirectional Forwar= ding
=C2=A0 =C2=A0Detection (BFD) protocol for its use in multipoint and multica= st
=C2=A0 =C2=A0networks.=C2=A0 Comments on this draft should be directed to r= tg-
=C2=A0 =C2=A0bfd@ietf.org.





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


--001a11c1564cdf1a45054df89d76-- From nobody Tue Apr 25 12:44:10 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142F912943D for ; Tue, 25 Apr 2017 12:44:09 -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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 CDR-l9Cuqlvx for ; Tue, 25 Apr 2017 12:44:07 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 579DD1317A4 for ; Tue, 25 Apr 2017 12:44:05 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3E2881E34D; Tue, 25 Apr 2017 15:51:24 -0400 (EDT) Date: Tue, 25 Apr 2017 15:51:24 -0400 From: Jeffrey Haas To: "Reshad Rahman (rrahman)" Cc: LuHuang , "rtg-bfd@ietf.org" , Mahesh Jethanandani , "Sonal Agarwal (agarwaso)" Subject: Re: =?utf-8?B?5Zue5aSN77yaIEFkb3B0aW9uIGNh?= =?utf-8?Q?ll_for_draft-sonal-bfd-secure-sequence-number?= =?utf-8?Q?s?= (ending April 30, 2017) Message-ID: <20170425195123.GG30063@pfrc.org> References: <20170417213533.GB18219@pfrc.org> <638481980.2346797.1492478397080@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 19:44:09 -0000 On Mon, Apr 24, 2017 at 01:47:26PM +0000, Reshad Rahman (rrahman) wrote: > Mahesh, should that be added to draft-ietf-bfd-optimizing-authentication? > > From: Rtg-bfd > on behalf of LuHuang > > Reply-To: LuHuang > > Date: Monday, April 17, 2017 at 9:19 PM > To: Jeffrey Haas >, "rtg-bfd@ietf.org" > > Cc: Reshad >, "Sonal Agarwal (agarwaso)" > > Subject: 回复： Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017) > > Yes./ support > > But I think one problem should be considered. If packet loss happens, the sequence number of received packet won't be the expected number or hash value, which should be distinguished from malicious packet. FWIW, I think the procedure will need to be spelled out in one or both of the documents. Generally speaking (as an individual contributor), a mechanism that results in obfuscation of the sequence numbers would require the receiver to pre-calculate the N-next sequence numbers in the obfuscation series. N would be at least the Detection Multiplier number from the BFD session. Upon receiving a sequence number that is obfuscated, the series of N-next would be consulted to see if the sequence number is found. If present in the N-next but not the first, packet loss can be presumed, but still within the Detection Multiplier period. A consequence of this is that if the implementation determines that there had been loss, it must be able to fill the N-next entries in a timely fashion. This could obviously be done on a timer since the numbers are expected to be consumed within a timed environment. But mostly it means that if generating them is event driven the cost of doing so must be considered. This is all arguably an implementation detail, but I think one or both documents will have to cover an example of this for people who don't regularly think about BFD authentication. Similarly, discussion about initial sequence numbers using this obfuscation must also be done. -- Jeff From nobody Tue Apr 25 12:47:30 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D62B127342 for ; Tue, 25 Apr 2017 12:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 VQY6rdjaGXL0 for ; Tue, 25 Apr 2017 12:47:28 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5601B128768 for ; Tue, 25 Apr 2017 12:47:28 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 48DEF1E34D; Tue, 25 Apr 2017 15:54:47 -0400 (EDT) Date: Tue, 25 Apr 2017 15:54:47 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Adoption calls in progress, please respond (target April 30, 2017) Message-ID: <20170425195447.GH30063@pfrc.org> 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: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 19:47:29 -0000 Working Group, This is a reminder we have adoption calls in progress for the following documents: draft-tanmir-rtgwg-bfd-mc-lag-* draft-sonal-bfd-secure-sequence-numbers draft-ashesh-bfd-stability The adoption call is scheduled to end on April 30. It'd be good to get further feedback on whether these documents should be adopted or should not be adopted. Please respond to the individual draft's thread. -- Jeff From nobody Tue Apr 25 12:55:10 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3BC12946C for ; Tue, 25 Apr 2017 12:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 4OZ0JYzYUcCO for ; Tue, 25 Apr 2017 12:55:07 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C30C12943E for ; Tue, 25 Apr 2017 12:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1149; q=dns/txt; s=iport; t=1493150107; x=1494359707; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uTlBU4tMUK4sU0jKXwR931OuPQX7N8I24czrELxqJEY=; b=lUVNGFliBXXvtBnmOBgrpiI2WTzIydOuu/To1UVQ0X7K1lkSiKNNMlnw NczNFktgxZBILiSwA4HYapgSE4Z09Uic8Y4XTawxdagIlHZirFE6GiMbR EAqW/PWiZHncgQqicDCV25QsYY+5X8ZWMu3+wdWuPdllTrhTzPc19fh8P w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAAAqqf9Y/4oNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1SBbQeNdadTgg+GJAKEFT8YAQIBAQEBAQEBayiFFgYdHTQLEAI?= =?us-ascii?q?BCA4oEDIlAgQBDQUbigGseYskAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZThHaBP?= =?us-ascii?q?IkAAQSdQQGTBYIAhTOKJJQYAR84gQZjFUSEdSmBSnWIKQGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,250,1488844800"; d="scan'208";a="414627633" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Apr 2017 19:55:06 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v3PJt6uZ032377 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Apr 2017 19:55:06 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Apr 2017 14:55:05 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Tue, 25 Apr 2017 14:55:05 -0500 From: "Reshad Rahman (rrahman)" To: Jeffrey Haas , "rtg-bfd@ietf.org" CC: "Sonal Agarwal (agarwaso)" Subject: Re: Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017) Thread-Topic: Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017) Thread-Index: AQHSt8GOym0WvtZ2iE2jKJQ4DD+/I6HWnOaA Date: Tue, 25 Apr 2017 19:55:05 +0000 Message-ID: References: <20170417213533.GB18219@pfrc.org> In-Reply-To: <20170417213533.GB18219@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.119] Content-Type: text/plain; charset="us-ascii" Content-ID: <8D265B0B91EDD9429B831F10E55CA832@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 19:55:08 -0000 Support (as individual contributor). On 2017-04-17, 5:35 PM, "Jeffrey Haas" wrote: >Working Group, > >As part of our discussion at the Working Group session at IETF 98 in >Chicago, Sonal Agarwal presented "Secure BFD Sequence Numbers" >(draft-sonal-bfd-secure-sequence-numbers-00). This work complements a >problem space the Security area had asked us to address as part of the >work >on optimizing BFD authentication, our adopted >draft-ietf-bfd-optimizing-authentication. > >The discussion on the implementation implictions of the optimizing >authentication draft was energetic this last IETF. To drive that solution >further along, we will need a technology similar to the one in the >proposal. > >This starts a 2 week adoption call for >draft-sonal-bfd-secure-sequence-numbers. >Please indicate your support or lack of support for the proposal to the >mailing list. > >Note that part of the discussion was that optimizing BFD is not ready to >proceed to Last CAll until we've adopted such a proposal and have >properly integrated it into the optimization procedures. > >-- Jeff and Reshad From nobody Tue Apr 25 12:55:22 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5611315BE for ; Tue, 25 Apr 2017 12:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 2sNe0iQI7Mzm for ; Tue, 25 Apr 2017 12:55:12 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BDC312943E for ; Tue, 25 Apr 2017 12:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=515; q=dns/txt; s=iport; t=1493150112; x=1494359712; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VfL8hdsu5bvD9yymYYIO+SVCD5tnYBKsLezUQHLrzS0=; b=PndQJLyvfGY82Mhyq5HiQj9bCCpUE1PuKuId1FZdnZopuu524wS4BhGS FMMUpBU06PCO6ev0p0GezKUYgWq6x4043MqSb8lXsxpXB3bIuegXHUUY1 8DUwLC/qmdTShUzGlRnGJVj5rJEBp/cO6nmFNdoda2zAjHHrgjsOvlUzN 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAABCqf9Y/5RdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQwHjXWnU4IPLIV4AoQVPxgBAgEBAQEBAQFrKIUWBh0dNBs?= =?us-ascii?q?CAQgOKBAyJQIEARKKHA6sa4skAQEBAQEBAQEBAQEBAQEBAQEBAQEZBYZThHaBP?= =?us-ascii?q?IkAAQSdQQGHFotvgWgYhTOKJJQYAR84gQZjFUSEdYFzdYgpAYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.37,250,1488844800"; d="scan'208";a="241110768" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2017 19:55:11 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v3PJtB7U020039 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Apr 2017 19:55:11 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Apr 2017 14:55:10 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Tue, 25 Apr 2017 14:55:10 -0500 From: "Reshad Rahman (rrahman)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: Adoption call for draft-ashesh-bfd-stability (ends April 30, 2017) Thread-Topic: Adoption call for draft-ashesh-bfd-stability (ends April 30, 2017) Thread-Index: AQHSt8Iq7Q6HpdyNfU27jSXtAbcD1KHWnOYA Date: Tue, 25 Apr 2017 19:55:10 +0000 Message-ID: References: <20170417213947.GC18219@pfrc.org> In-Reply-To: <20170417213947.GC18219@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.119] Content-Type: text/plain; charset="us-ascii" Content-ID: <217CD3DB07ED9F48957FBF7637E5598E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 19:55:14 -0000 Support (as individual contributor). On 2017-04-17, 5:39 PM, "Rtg-bfd on behalf of Jeffrey Haas" wrote: >Working Group, > >https://tools.ietf.org/html/draft-ashesh-bfd-stability-05 > >The authors of BFD Stability (draft-ashesh-bfd-stability), presented their >latest changes at IETF 98 in Chicago and have requested working group >adoption. > >Please indicate your support or lack of support to the mailing list. > >-- Jeff and Reshad > From nobody Tue Apr 25 13:43:19 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2CD1292CE for ; Tue, 25 Apr 2017 13:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 shQ7n5c8i2B5 for ; Tue, 25 Apr 2017 13:43:16 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F66C12709D for ; Tue, 25 Apr 2017 13:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1516; q=dns/txt; s=iport; t=1493152996; x=1494362596; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=h8/480kuil2ampJc7HAynaqCmUyA6WEd7uy8TLtnLHc=; b=WcGwedxXL3gD2GTGhoQ9TdWwnzZmtZdYmJATtnQdAw7oX07df6Y1Ld+3 dzOuYwaGbA+RQ5pdFi2uly3wsiaBqlpxXAgqgAp1m0B1rHbmOgUrr2fPo Md0cQY2R9Dl9b8sbqEZ+NoEMbkNKn1T1rPhRcnk64wB1mw8aW3C0aHJgp Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAAC+tP9Y/4kNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1SBbQeNdZFulWWCD4YkAoQVPxgBAgEBAQEBAQFrKIUVAQEBAQM?= =?us-ascii?q?dHTQLDAQCAQgOAwQBAR8JBzIUCQgCBAENBQgTigGsdoskAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHYZThHaBPIkAAQSdQQGSfIIJhTOKJJQYAR84gQZjFUSFHoFKdYg?= =?us-ascii?q?pgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,251,1488844800"; d="scan'208";a="416957635" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Apr 2017 20:43:04 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v3PKh4qE020495 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Apr 2017 20:43:04 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Apr 2017 15:43:03 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Tue, 25 Apr 2017 15:43:03 -0500 From: "Les Ginsberg (ginsberg)" To: Jeffrey Haas , "rtg-bfd@ietf.org" CC: "Reshad Rahman (rrahman)" , "Sonal Agarwal (agarwaso)" Subject: RE: Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017) Thread-Topic: Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017) Thread-Index: AQHSt8GUD/TxZOMKzUiIHi1mn82Z1aHWmUcw Date: Tue, 25 Apr 2017 20:43:03 +0000 Message-ID: References: <20170417213533.GB18219@pfrc.org> In-Reply-To: <20170417213533.GB18219@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.152.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 20:43:18 -0000 Support - this seems a useful tool to help address security scalability in = BFD. Les > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Monday, April 17, 2017 2:36 PM > To: rtg-bfd@ietf.org > Cc: Reshad Rahman (rrahman); Sonal Agarwal (agarwaso) > Subject: Adoption call for draft-sonal-bfd-secure-sequence-numbers (endin= g > April 30, 2017) >=20 > Working Group, >=20 > As part of our discussion at the Working Group session at IETF 98 in Chic= ago, > Sonal Agarwal presented "Secure BFD Sequence Numbers" > (draft-sonal-bfd-secure-sequence-numbers-00). This work complements a > problem space the Security area had asked us to address as part of the wo= rk > on optimizing BFD authentication, our adopted draft-ietf-bfd-optimizing- > authentication. >=20 > The discussion on the implementation implictions of the optimizing > authentication draft was energetic this last IETF. To drive that solutio= n > further along, we will need a technology similar to the one in the propos= al. >=20 > This starts a 2 week adoption call for draft-sonal-bfd-secure-sequence- > numbers. > Please indicate your support or lack of support for the proposal to the m= ailing > list. >=20 > Note that part of the discussion was that optimizing BFD is not ready to > proceed to Last CAll until we've adopted such a proposal and have properl= y > integrated it into the optimization procedures. >=20 > -- Jeff and Reshad From nobody Tue Apr 25 14:02:02 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09471294AC for ; Tue, 25 Apr 2017 14:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EmeubFsJt7LQ for ; Tue, 25 Apr 2017 14:01:58 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8002C128B8F for ; Tue, 25 Apr 2017 14:01:56 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id w12so75096576oiw.3 for ; Tue, 25 Apr 2017 14:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Tw7YVk/xErpiW4l/TDrFlYfqvA/dBZVuU751SHJTK+4=; b=f1dZ3ykobfUTTkdcbqLzzh6qoJapc6u3QwtJHGCQGS6eo+ru1HrKc/BDcQyKFgsHMa wzSDida1BFHoXGY/yTZhwFxk9ID3roAYsHDCuZcnPycrMUORAu7rG6KIIFZBNeBy5ht9 V1w7u4hskYXPsQAMmEbffEUpz/sxD2nnsCQLLn8JWNdQtDcOtfn0ekYbWvxNbCD95JaQ EXqE90ezvL2UUPfIbQ5FLCP0URa8qfPgWRs3FJzek4QYzWDmHJvWlJ859+VTsW8NjBcP kPUZhIZFr467u/6jQLJnImHoB007bYjDPrzX9J2xvEHUZgZT6/p7CsIr1oRXVRWeWkS7 yelA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Tw7YVk/xErpiW4l/TDrFlYfqvA/dBZVuU751SHJTK+4=; b=bdxmhrK+3Vi81uU4x/oTv061usM8zjbASoDnPW8M7oNIjDQVt0By25vM1IyXr4H9ZJ 29KnXGAn5Ys4PVpXVBIngdkKS+QSKbNsnUmRs1PooJt9+IeS2V0QTckbzG7lug5y/E1J fZrlTJ1n8fW2nDCOsXjBETlzT5bPMY5yOrTjysn1JQUjtj/NeCW8wRaMMbByr/fqQf7L Ib43Hb46u72anltBy1AkEN0EkckAR4oIOM9V0eXVHUwqr/7OtXYKGuy+5+bDEHjgWt0m i+Z3s/8PqIg9/ta/9a8EQl+KtV8tq+bgzkYtsi+RXK4p37729TSFOtqLcdv7NoeMCZ9w R3ag== X-Gm-Message-State: AN3rC/7rLT5GSM3+FpyGF4fGDSs/W1i2IVWMRfcYjTknrThuvp6iSLcS EsFM6/TmFaghr2Fv9LFzaBrccq0sgA== X-Received: by 10.157.55.163 with SMTP id x32mr9048803otb.72.1493154115737; Tue, 25 Apr 2017 14:01:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.118 with HTTP; Tue, 25 Apr 2017 14:01:55 -0700 (PDT) In-Reply-To: <20170417213947.GC18219@pfrc.org> References: <20170417213947.GC18219@pfrc.org> From: Greg Mirsky Date: Tue, 25 Apr 2017 14:01:55 -0700 Message-ID: Subject: Re: Adoption call for draft-ashesh-bfd-stability (ends April 30, 2017) To: Jeffrey Haas Cc: "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary=001a114095e8a9df44054e040851 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 21:02:00 -0000 --001a114095e8a9df44054e040851 Content-Type: text/plain; charset=UTF-8 yes/support But I have to point that impact of the suggested in the draft periodic use of authentication when in Up state must be be investigated and addressed before we can move further, I mean WG LC, of course. Regards, Greg On Mon, Apr 17, 2017 at 2:39 PM, Jeffrey Haas wrote: > Working Group, > > https://tools.ietf.org/html/draft-ashesh-bfd-stability-05 > > The authors of BFD Stability (draft-ashesh-bfd-stability), presented their > latest changes at IETF 98 in Chicago and have requested working group > adoption. > > Please indicate your support or lack of support to the mailing list. > > -- Jeff and Reshad > > --001a114095e8a9df44054e040851 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
yes/support
But I have to point that impact of the sug= gested in the draft periodic use of authentication when in Up state must be= be investigated and addressed before we can move further, I mean WG LC, of= course.

Regards,
Greg

On Mon, Apr 17, 2017 at= 2:39 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
Working Group,

https://tools.ietf.org/html/draft-as= hesh-bfd-stability-05

The authors of BFD Stability (draft-ashesh-bfd-stability), presented their<= br> latest changes at IETF 98 in Chicago and have requested working group
adoption.

Please indicate your support or lack of support to the mailing list.

-- Jeff and Reshad


--001a114095e8a9df44054e040851-- From nobody Tue Apr 25 14:04:51 2017 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C82F1294AC for ; Tue, 25 Apr 2017 14:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 r9BianGAmNMT for ; Tue, 25 Apr 2017 14:04:47 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80CD1252BA for ; Tue, 25 Apr 2017 14:04:47 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id j201so187144009oih.2 for ; Tue, 25 Apr 2017 14:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zZo8g/it5s0953TVgnjARvC3KScfGjoYVAHaqsqo6rY=; b=YWNo/dPoNuDgeZrj42diQphW4+odC7Zyktb16Rkb7bqNCeB9gyfgjrMbUqJqAfYTwa AtjbyF7fAiotxjYRG291LXG/vjRcqO7qzvKxGGVacd5rag+5yqsM/4s9wR4w8AY3Gur+ CTf3wndwlVtSW3+UuzjvydWbrpkgMamafAyUh18aR6mmt9rMDL05O7lAs8p2pSMW7dFJ zJdR7e9LbNzxtoMNnflQ4Bw9PK3+zYmrRRgO+s5rHGVRf5HiyWQ15gYfmszK914xWsyg pQaIupX1kDSfLNAez5DWwo7L+Od+FWcfuFOSWPK/Ax0zFEKvFrLTGfjfdUZM+4v2+S2z ZRsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zZo8g/it5s0953TVgnjARvC3KScfGjoYVAHaqsqo6rY=; b=PUtInZQJc1lg+OQYez4JcWhT26CxsUde9n8B5NFzrei/c2L1weQukXcGPIxqnftG1j ws9r76298ZCpoxRXf2pP/A0eau5DyqJOTjErIayZEeOH0F3iPBeSFMbqf511/LY+6JQ0 ulLhnFjrD+nqdWjjXaW19Za1INJX1qJssbUYjHhjCgkiCBUFfG1gqS+th2F2mWVkRKCc fxwvkwB8dLc43q+HjhzJGQMgIvW8grmAtb+w670wCCFBm93wgYEfgWNnyoHccIBoSwBQ PiZdqLoK8ZpboEp4bEpdOVga9yM9CIclmULy49D3DwhCDx9btuptDkA+HqrdtcKd0HwK JP5Q== X-Gm-Message-State: AN3rC/4ozuKn9g94YBdfmijlctc8U45N0/ZTd8pPKerX5o1P6Je1vz7A QCe7zjY4scRUA8T2stbHifURXJ/cJg== X-Received: by 10.202.4.83 with SMTP id 80mr19394458oie.196.1493154287155; Tue, 25 Apr 2017 14:04:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.118 with HTTP; Tue, 25 Apr 2017 14:04:46 -0700 (PDT) In-Reply-To: <20170417213533.GB18219@pfrc.org> References: <20170417213533.GB18219@pfrc.org> From: Greg Mirsky Date: Tue, 25 Apr 2017 14:04:46 -0700 Message-ID: Subject: Re: Adoption call for draft-sonal-bfd-secure-sequence-numbers (ending April 30, 2017) To: Jeffrey Haas Cc: "rtg-bfd@ietf.org" , "Reshad Rahman (rrahman)" , agarwaso@cisco.com Content-Type: multipart/alternative; boundary=001a113c037ce1805a054e041292 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 21:04:49 -0000 --001a113c037ce1805a054e041292 Content-Type: text/plain; charset=UTF-8 yes/support And I concur with Jeff that it will be prudent to expand on implementation considerations. Regards, Greg On Mon, Apr 17, 2017 at 2:35 PM, Jeffrey Haas wrote: > Working Group, > > As part of our discussion at the Working Group session at IETF 98 in > Chicago, Sonal Agarwal presented "Secure BFD Sequence Numbers" > (draft-sonal-bfd-secure-sequence-numbers-00). This work complements a > problem space the Security area had asked us to address as part of the work > on optimizing BFD authentication, our adopted > draft-ietf-bfd-optimizing-authentication. > > The discussion on the implementation implictions of the optimizing > authentication draft was energetic this last IETF. To drive that solution > further along, we will need a technology similar to the one in the > proposal. > > This starts a 2 week adoption call for draft-sonal-bfd-secure- > sequence-numbers. > Please indicate your support or lack of support for the proposal to the > mailing list. > > Note that part of the discussion was that optimizing BFD is not ready to > proceed to Last CAll until we've adopted such a proposal and have > properly integrated it into the optimization procedures. > > -- Jeff and Reshad > > --001a113c037ce1805a054e041292 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
yes/support
And I concur with Jeff that it will be pru= dent to expand on implementation considerations.

R= egards,
Greg

On Mon, Apr 17, 2017 at 2:35 PM, Jeffrey Haas <jhaas@pfrc.or= g> wrote:
Working Group,
As part of our discussion at the Working Group session at IETF 98 in
Chicago, Sonal Agarwal presented "Secure BFD Sequence Numbers" (draft-sonal-bfd-secure-sequence-numbers-00).=C2=A0 This work compleme= nts a
problem space the Security area had asked us to address as part of the work=
on optimizing BFD authentication, our adopted
draft-ietf-bfd-optimizing-authentication.

The discussion on the implementation implictions of the optimizing
authentication draft was energetic this last IETF.=C2=A0 To drive that solu= tion
further along, we will need a technology similar to the one in the proposal= .

This starts a 2 week adoption call for draft-sonal-bfd-secure-sequence= -numbers.
Please indicate your support or lack of support for the proposal to the
mailing list.

Note that part of the discussion was that optimizing BFD is not ready to proceed to Last CAll until we've adopted such a proposal and have
properly integrated it into the optimization procedures.

-- Jeff and Reshad


--001a113c037ce1805a054e041292--