From nobody Mon Feb 6 08:14: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 E5D50129EC4; Mon, 6 Feb 2017 08:14:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Subject: bfd - New Meeting Session Request for IETF 98 X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148639765091.18926.15123563660315357621.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2017 08:14:10 -0800 Archived-At: Cc: rrahman@cisco.com, rtg-bfd@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 16:14:11 -0000 A new meeting session request has just been submitted by Reshad Rahman, a Chair of the bfd working group. --------------------------------------------------------- Working Group Name: Bidirectional Forwarding Detection Area Name: Routing Area Session Requester: Reshad Rahman Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 40 Conflicts to Avoid: First Priority: idr,i2rs,mpls,sfc,spring,bier,lime Second Priority: bess,isis,nvo3,ospf,pals,rtgwg,teas People who must be present: Jeffrey Haas Reshad Rahman Alvaro Retana Resources Requested: Meetecho support in room Special Requests: Monday to Thursday. --------------------------------------------------------- From nobody Wed Feb 22 12:00: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 6F5AF129ABD for ; Wed, 22 Feb 2017 12:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 R_aRoc4v9OP5 for ; Wed, 22 Feb 2017 12:00:54 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 7E205129AED for ; Wed, 22 Feb 2017 12:00:44 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id 189so398810pfu.3 for ; Wed, 22 Feb 2017 12:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=cH7R2uZkifsZNYF8jKzsmJ//OtPPsJLDMFelCIM5Ot4=; b=A2oL/gTExWYws3Zqpv1tu6n2qJvK4HEJXPwzsFYID6mJDyJj+rkNwo1IhizA4xeS4y FuSHaUaiTjAzzvXIRPg/GsIrz/znQ7GCAHS7k840YiriovaHXdgYjnjrndZezIGajx09 O/P+pBhzr1Ofhcdf+WxwP1wEQLu8n/j54K16Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=cH7R2uZkifsZNYF8jKzsmJ//OtPPsJLDMFelCIM5Ot4=; b=gzy2oAL13CsEeHrV6fzvOoUEDEfNzcVZERU4FWdCsA27tsevE0qqW4ZgcIUNwJRsyA LQVhugVUYuBEMKQcRIJNm8rIqfL40dl2ZsGHkWG8SKNhk4xfl5bnSV5q0pv4nbkJTvRh ohlRe7qsYW+XBech51qWhIdpM4KHXQ0tLuTrEaLCs+JQJwyyMkxjdLSP2otKbC30HaRD bhiMwzfJR8x5VrJXt8LDUjmoL6DSe2utHWocSBvVKhNU6FOK8Hy8H0ygNjxPGcimAxYH w04xikrNbMQrNx5R4sT4Ri4SpT37Fq5r3lHQxISIa2kAwSRMoHVqORVFrTncQTL0Xhpl NRwg== X-Gm-Message-State: AMke39kV1+cFZm4SXK5vtmQT8K9emhs2ELp9t/KVIFF07iroTJstvsYnt1Q5UL1AODmY1y1q X-Received: by 10.98.14.217 with SMTP id 86mr42014153pfo.79.1487793643798; Wed, 22 Feb 2017 12:00:43 -0800 (PST) Received: from [10.16.86.217] ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id y21sm5218451pgh.52.2017.02.22.12.00.41 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 22 Feb 2017 12:00:41 -0800 (PST) From: Shahram Davari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: BFD interval in down state Message-Id: Date: Wed, 22 Feb 2017 12:00:40 -0800 To: rtg-bfd@ietf.org X-Mailer: iPhone Mail (13G36) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 20:00:55 -0000 Hi=20 When moving from UP to down state we are supposed to reduce the rate to 1 se= c. Do we need to do a poll sequence to reduce the rate? Regards, Shahram From nobody Wed Feb 22 12:03: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 307E7129ABB for ; Wed, 22 Feb 2017 12:03:01 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 juLGUpSolqbt for ; Wed, 22 Feb 2017 12:02:59 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::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 A5DF9129A9C for ; Wed, 22 Feb 2017 12:02:59 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id s67so4917030pgb.3 for ; Wed, 22 Feb 2017 12:02:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:mime-version:to:from:subject:date:importance:in-reply-to :references; bh=vUZeS6JFlnjH11pdBCkgRCvqnlEjHawtYf/U+qtIIJ4=; b=oha1yjvE61P6NnXr+wyyepj5svbLtI8qozS2kt3jZvAidChIfvVE9txWnBpnBwUauu ChCk2j8rqRL/BdHC0sV59AFZMNXUySGIQmyTveDOtvrx/BUyXvYGNDfkLTlkVXs8XTpw QwW3SCGrHN5DUUvRJPJcsTtpUXW70fvKgaaBPM8uunXBsXDkopoN5LrbkoKcx03NxuTr io1kDmQ26zNkmlrxt5wjWzFrbXOlgFgmr7rIF3C0ybjH9H5mAjoeZi/P7Eu2ZyrJkxWC NGzwEf1H4RhZvxJMXAoSdKk2eMBC72zghKrY0JU2gMjPhzQ3jgWyRYtG9PMXkP1DbGb7 GDKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:in-reply-to:references; bh=vUZeS6JFlnjH11pdBCkgRCvqnlEjHawtYf/U+qtIIJ4=; b=oRpP4pAYyCtXQ5AXxdCWVBlYyeaFQb6+RDm1HoMFzMEpSi0BYIaPDXI1Yty9uYuvtQ XuqdnVPc9YqHiFNYAPCDiArDxKVAcfaRNccdBFenJ/9fh7+YDbP5nb/adW9PvKkHTB6x SJ+8K+VPH0RxdN4HR/QIiPkmUJcPohmk9zcAtZMZLlfh25j6f0sgnO/AZGxUO4ZJI1TN VeiL5MDGb9lV4JPFMxsXNBJXVS+edjfnvSSOs7jJQTLrtY/bUKvlp2PMCLaPsE7JhhEP MuE/C2493dwgzk0oMBgmDcH2MXug9AajKfSH2nEd24nZuG3OUF5KmqU6O78K7qUir/Ub bcsQ== X-Gm-Message-State: AMke39lulnGg70yv5m7NAcimAgon2CCadS/kZAIFAYXpv3AnJ8Sp5JYMRphfvdX9PHf3Cw== X-Received: by 10.99.130.67 with SMTP id w64mr43062258pgd.194.1487793779251; Wed, 22 Feb 2017 12:02:59 -0800 (PST) Received: from ?IPv6:::ffff:192.168.1.2? ([117.221.212.254]) by smtp.gmail.com with ESMTPSA id g194sm5248783pfb.19.2017.02.22.12.02.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Feb 2017 12:02:58 -0800 (PST) Message-ID: <58adee72.cb52620a.ca404.8e29@mx.google.com> MIME-Version: 1.0 To: Shahram Davari , "rtg-bfd@ietf.org" From: Subject: RE: BFD interval in down state Date: Thu, 23 Feb 2017 01:33:03 +0530 Importance: normal X-Priority: 3 In-Reply-To: References: Content-Type: multipart/alternative; boundary="_98791566-2762-483B-9AB5-4C055BBA7E54_" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 20:03:01 -0000 --_98791566-2762-483B-9AB5-4C055BBA7E54_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" In my understanding based on 5+ Implementations I have seen, you NEED NOT.= =20 When state moves to down, simply reduce the rate yourself. Sent from Mail for Windows 10 From: Shahram Davari Sent: Thursday, February 23, 2017 1:31 AM To: rtg-bfd@ietf.org Subject: BFD interval in down state Hi=20 When moving from UP to down state we are supposed to reduce the rate to 1 s= ec. Do we need to do a poll sequence to reduce the rate? Regards, Shahram --_98791566-2762-483B-9AB5-4C055BBA7E54_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

In my understanding based on 5+ Impl= ementations I have seen, you NEED NOT.

 =

When state moves to down, simply reduce the = rate yourself.

 

Sent from Mail for Windows 10

 

From: Sh= ahram Davari
Sent: Thursday, February 23, 2017 1:31 AM
= To: rtg-bfd@ietf.org
Subj= ect: BFD interval in down state

&nbs= p;

Hi

 

When moving from UP to down state we are suppos= ed to reduce the rate to 1 sec. Do we need to do a poll sequence to reduce = the rate?

 

Regards,

Shahram

&nbs= p;

 

= --_98791566-2762-483B-9AB5-4C055BBA7E54_-- From nobody Wed Feb 22 12:16: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 33810129AD9 for ; Wed, 22 Feb 2017 12:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 AEJ6iu5IfGk3 for ; Wed, 22 Feb 2017 12:16:27 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0110.outbound.protection.outlook.com [104.47.33.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC7D129AB5 for ; Wed, 22 Feb 2017 12:16:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=34cZYE1ARMaS+18jQmV07QINpZDrsY2eyoT7qvSatE4=; b=fHMmhH80aFF+9kIS+59sykpG/J/qCx3fCxug4qkhLznGada6p/pPt/fi/2oV7gxZPkYVNf3FrRnKl8nfs8CfJLZ0d+Oxup5pdpgnnVrFNtqzaozbOQ7JUrc6QnLDr8UoMTk0vMHcUxdfQuhRNUiArtJ8kmylDbur52/1m4ANOc4= Received: from DM5PR05MB2954.namprd05.prod.outlook.com (10.168.176.142) by DM5PR05MB2956.namprd05.prod.outlook.com (10.168.176.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.7; Wed, 22 Feb 2017 20:16:25 +0000 Received: from DM5PR05MB2954.namprd05.prod.outlook.com ([10.168.176.142]) by DM5PR05MB2954.namprd05.prod.outlook.com ([10.168.176.142]) with mapi id 15.01.0947.001; Wed, 22 Feb 2017 20:16:25 +0000 From: Dave Katz To: "binnyjeshan@gmail.com" Subject: Re: BFD interval in down state Thread-Topic: BFD interval in down state Thread-Index: AQHSjUZ+mcPXPGUbEk+g6PCPVOfqeaF1csyAgAADuwA= Date: Wed, 22 Feb 2017 20:16:25 +0000 Message-ID: References: <58adee72.cb52620a.ca404.8e29@mx.google.com> In-Reply-To: <58adee72.cb52620a.ca404.8e29@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.15] x-ms-office365-filtering-correlation-id: 50f761f6-a867-4d90-d1a0-08d45b5fad3b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DM5PR05MB2956; x-microsoft-exchange-diagnostics: 1; DM5PR05MB2956; 7:ERv2crCa+tXNtLuT/pB4V3IgAOaPW97+7PBs01kGLryLDn2tHtozSJ/rXE4pf0X3UpQMekT6+LQEOqNSX6p/CkkwSAiekb3uQZ50n/t/FW8bRtNf8VB39q9PMNvyuBqLX4+FXy2R8JKRazG+3ZaROa3aE8TBao2aADdBSAgE5xdUyGcopOA7tw/woRtxF+U+7UqGEkmEg7FTSKaAZ/ZMtgHGgmhwuWlpOtCKTybsYuS6fkvjwu5GVDqB0Uc0wIbXOy6Fn+y740aCJws82/QflA+PixGW5rbZvxwTJ5T0D5RJgrHiEpcLh8YRROXchduvdIKwD2Kdp6nE0xtzAaoO8g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(156600954879566); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558025)(6072148); SRVR:DM5PR05MB2956; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB2956; x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39860400002)(39410400002)(39850400002)(39450400003)(39840400002)(377454003)(3905003)(57704003)(24454002)(53936002)(6486002)(99286003)(77096006)(38730400002)(6506006)(54906002)(83716003)(110136004)(8936002)(6436002)(6246003)(4326007)(36756003)(5640700003)(33656002)(606005)(2900100001)(66066001)(3660700001)(2950100002)(3280700002)(7736002)(81166006)(122556002)(1730700003)(6916009)(57306001)(25786008)(5660300001)(2351001)(82746002)(8676002)(86362001)(76176999)(7906003)(50986999)(50226002)(1411001)(6512007)(236005)(2906002)(53546006)(6306002)(39060400002)(54896002)(2501003)(106116001)(3846002)(102836003)(92566002)(6116002)(189998001)(229853002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2956; H:DM5PR05MB2954.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AABD6B4D856C4461BF70C62F02BEC1A5junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2017 20:16:25.0400 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2956 Archived-At: Cc: "rtg-bfd@ietf.org" , Shahram Davari X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 20:16:29 -0000 --_000_AABD6B4D856C4461BF70C62F02BEC1A5junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmlnaHQsIHRoZSBvbmx5IHBvaW50IG9mIHRoZSBwb2xsIHNlcXVlbmNlIHdoZW4gY2hhbmdpbmcg dGltaW5nIGlzIHRvIGtlZXAgdGhlIHNlc3Npb24gZnJvbSB0aW1pbmcgb3V0IChiZWNhdXNlLCBm b3IgZXhhbXBsZSwgdGhlIHRyYW5zbWl0IHJhdGUgd2FzIHJlZHVjZWQgYnV0IHRoZSByZWNlaXZl ciBkaWRu4oCZdCB5ZXQga25vdyB0aGF0IHRoZSBob2xkaW5nIHRpbWUgd2FzIGJlaW5nIGV4dGVu ZGVkKS4NCg0KSW4gdGhpcyBjYXNlLCB0aGUgc2Vzc2lvbiBpcyBhbHJlYWR5IGRvd24sIHNvIHlv dSBjYW7igJl0IGRvIHRvbyBtdWNoIGRhbWFnZSB0byBpdC4NCg0K4oCURGF2ZQ0KDQpPbiBGZWIg MjIsIDIwMTcsIGF0IDEyOjAzIFBNLCBiaW5ueWplc2hhbkBnbWFpbC5jb208bWFpbHRvOmJpbm55 amVzaGFuQGdtYWlsLmNvbT4gd3JvdGU6DQoNCkluIG15IHVuZGVyc3RhbmRpbmcgYmFzZWQgb24g NSsgSW1wbGVtZW50YXRpb25zIEkgaGF2ZSBzZWVuLCB5b3UgTkVFRCBOT1QuDQoNCldoZW4gc3Rh dGUgbW92ZXMgdG8gZG93biwgc2ltcGx5IHJlZHVjZSB0aGUgcmF0ZSB5b3Vyc2VsZi4NCg0KU2Vu dCBmcm9tIE1haWw8aHR0cHM6Ly9nby5taWNyb3NvZnQuY29tL2Z3bGluay8/TGlua0lkPTU1MDk4 Nj4gZm9yIFdpbmRvd3MgMTANCg0KRnJvbTogU2hhaHJhbSBEYXZhcmk8bWFpbHRvOnNoYWhyYW0u ZGF2YXJpQGJyb2FkY29tLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyMywgMjAxNyAx OjMxIEFNDQpUbzogcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4NClN1 YmplY3Q6IEJGRCBpbnRlcnZhbCBpbiBkb3duIHN0YXRlDQoNCkhpDQoNCldoZW4gbW92aW5nIGZy b20gVVAgdG8gZG93biBzdGF0ZSB3ZSBhcmUgc3VwcG9zZWQgdG8gcmVkdWNlIHRoZSByYXRlIHRv IDEgc2VjLiBEbyB3ZSBuZWVkIHRvIGRvIGEgcG9sbCBzZXF1ZW5jZSB0byByZWR1Y2UgdGhlIHJh dGU/DQoNClJlZ2FyZHMsDQpTaGFocmFtDQoNCg== --_000_AABD6B4D856C4461BF70C62F02BEC1A5junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdj5SaWdodCwgdGhlIG9ubHkg cG9pbnQgb2YgdGhlIHBvbGwgc2VxdWVuY2Ugd2hlbiBjaGFuZ2luZyB0aW1pbmcgaXMgdG8ga2Vl cCB0aGUgc2Vzc2lvbiBmcm9tIHRpbWluZyBvdXQgKGJlY2F1c2UsIGZvciBleGFtcGxlLCB0aGUg dHJhbnNtaXQgcmF0ZSB3YXMgcmVkdWNlZCBidXQgdGhlIHJlY2VpdmVyIGRpZG7igJl0IHlldCBr bm93IHRoYXQgdGhlIGhvbGRpbmcgdGltZSB3YXMgYmVpbmcgZXh0ZW5kZWQpLjwvZGl2Pg0KPGRp dj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SW4gdGhpcyBjYXNlLCB0aGUgc2Vzc2lvbiBp cyBhbHJlYWR5IGRvd24sIHNvIHlvdSBjYW7igJl0IGRvIHRvbyBtdWNoIGRhbWFnZSB0byBpdC48 L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PuKAlERhdmU8L2Rpdj4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPk9uIEZlYiAyMiwgMjAxNywgYXQgMTI6MDMgUE0sIDxhIGhyZWY9Im1haWx0bzpi aW5ueWplc2hhbkBnbWFpbC5jb20iIGNsYXNzPSIiPg0KYmlubnlqZXNoYW5AZ21haWwuY29tPC9h PiB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29y ZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPg0KSW4gbXkgdW5kZXJzdGFuZGluZyBiYXNlZCBvbiA1JiM0MzsgSW1wbGVtZW50YXRp b25zIEkgaGF2ZSBzZWVuLCB5b3UgTkVFRCBOT1QuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpXaGVuIHN0YXRlIG1vdmVzIHRv IGRvd24sIHNpbXBseSByZWR1Y2UgdGhlIHJhdGUgeW91cnNlbGYuPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9v OnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NClNl bnQgZnJvbTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJodHRwczovL2dvLm1pY3Jvc29mdC5jb20vZndsaW5rLz9MaW5rSWQ9NTUwOTg2IiBz dHlsZT0iY29sb3I6IHJnYigxNDksIDc5LCAxMTQpOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGlu ZTsiIGNsYXNzPSIiPk1haWw8L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPmZvciBXaW5kb3dzIDEwPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLXRvcC1jb2xv cjogcmdiKDIyNSwgMjI1LCAyMjUpOyBib3JkZXItdG9wLXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDNw dCAwaW4gMGluOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGJv cmRlcjogbm9uZTsgcGFkZGluZzogMGluOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Gcm9tOjxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+PGEgaHJl Zj0ibWFpbHRvOnNoYWhyYW0uZGF2YXJpQGJyb2FkY29tLmNvbSIgc3R5bGU9ImNvbG9yOiByZ2Io MTQ5LCA3OSwgMTE0KTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5TaGFo cmFtIERhdmFyaTwvYT48YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TZW50OjxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+VGh1cnNkYXksIEZlYnJ1 YXJ5IDIzLCAyMDE3IDE6MzEgQU08YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPjxhIGhyZWY9Im1h aWx0bzpydGctYmZkQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHJnYigxNDksIDc5LCAxMTQpOyB0 ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPnJ0Zy1iZmRAaWV0Zi5vcmc8L2E+ PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U3ViamVjdDo8c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkJGRCBpbnRlcnZhbCBpbiBkb3duIHN0YXRl PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi Pg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KSGk8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCldoZW4gbW92aW5nIGZyb20gVVAgdG8g ZG93biBzdGF0ZSB3ZSBhcmUgc3VwcG9zZWQgdG8gcmVkdWNlIHRoZSByYXRlIHRvIDEgc2VjLiBE byB3ZSBuZWVkIHRvIGRvIGEgcG9sbCBzZXF1ZW5jZSB0byByZWR1Y2UgdGhlIHJhdGU/PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9 IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj4NClJlZ2FyZHMsPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NClNoYWhyYW08L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AABD6B4D856C4461BF70C62F02BEC1A5junipernet_-- From nobody Wed Feb 22 14:08:48 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 56787129C24 for ; Wed, 22 Feb 2017 14:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 eEF3_x0xqJGE for ; Wed, 22 Feb 2017 14:08:45 -0800 (PST) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 24D59129C23 for ; Wed, 22 Feb 2017 14:08:45 -0800 (PST) Received: by mail-wr0-x232.google.com with SMTP id 89so11252391wrr.3 for ; Wed, 22 Feb 2017 14:08:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=T6CaIcSdlzYO8g/okpDyfjh/+v9o6VSYBZI8/sc27wM=; b=YyCJ4suut5nyaiHh3Aq4Jlba4xXFMftPiqo73LPX04YzXO0ssTYBksUDg6r39JA4OO FMgewgxP8LSBNGteKbL5upYiO4cKjch4PrM6GwzIcvIcxIrTExfVECyPuwvRzmqHls/J bme6GiI/VKtjRwd3j+CmOmOmf+OTnSzrTsCZo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=T6CaIcSdlzYO8g/okpDyfjh/+v9o6VSYBZI8/sc27wM=; b=iQJf/0sZL4aNYCu08Q9LyA3THjYn1KIbMCiykzhREUYOsdi8dQNLMDisOuXxOqVJzV LjK7oMWAemKp+UIMEQkPFJ1lv7ZZ8fRcV2WuXuZY+8QjeaepKF7ijNClpKDAyfEQPIJ8 TRMPBzToedI9VAdS+Ba4WYBrfyrkYKh8jbUpUfKVXEmjsFhk1MQ8H+EkOgOKNRz7mgl+ 5oqqvF72BGpM1eqmbRVX0mNwYa9lC6v3EbtT0MuPLiep41mnCsqkCp9dfVzDD22vKUBz mqw/ObdqQex/wX1X+/Y+WlOFJWlszMLdThzo7RwFMSD0QYUf2Fz/J1xH3ytmrj8Ufva8 fF9w== X-Gm-Message-State: AMke39nDj9LgYE1IzslCFCk/un0ewLIZzS3wDAOO7d6iVKvdussp/aMClBHC5jKIihBtHZ6V X-Received: by 10.223.174.26 with SMTP id x26mr18361165wrc.124.1487801323422; Wed, 22 Feb 2017 14:08:43 -0800 (PST) Received: from dhcpe1-sj1-102.sj.broadcom.com ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id 36sm3332621wrk.57.2017.02.22.14.08.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 22 Feb 2017 14:08:42 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_ACB15A20-5EC8-454E-832B-ACEF0F12265E" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: BFD interval in down state From: Shahram Davari In-Reply-To: Date: Wed, 22 Feb 2017 14:08:42 -0800 Message-Id: <0774A927-5930-41A9-A3B6-E0423B37B44D@broadcom.com> References: <58adee72.cb52620a.ca404.8e29@mx.google.com> To: Dave Katz X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 22:08:47 -0000 --Apple-Mail=_ACB15A20-5EC8-454E-832B-ACEF0F12265E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Dave, that=E2=80=99s what I thought, Shahram > On Feb 22, 2017, at 12:16 PM, Dave Katz wrote: >=20 > Right, the only point of the poll sequence when changing timing is to = keep the session from timing out (because, for example, the transmit = rate was reduced but the receiver didn=E2=80=99t yet know that the = holding time was being extended). >=20 > In this case, the session is already down, so you can=E2=80=99t do too = much damage to it. >=20 > =E2=80=94Dave >=20 >> On Feb 22, 2017, at 12:03 PM, binnyjeshan@gmail.com = wrote: >>=20 >> In my understanding based on 5+ Implementations I have seen, you NEED = NOT.=20 >> =20 >> When state moves to down, simply reduce the rate yourself. >> =20 >> Sent from Mail for = Windows 10 >> =20 >> From: Shahram Davari >> Sent: Thursday, February 23, 2017 1:31 AM >> To: rtg-bfd@ietf.org >> Subject: BFD interval in down state >> =20 >> Hi=20 >> =20 >> When moving from UP to down state we are supposed to reduce the rate = to 1 sec. Do we need to do a poll sequence to reduce the rate? >> =20 >> Regards, >> Shahram >=20 --Apple-Mail=_ACB15A20-5EC8-454E-832B-ACEF0F12265E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Dave, that=E2=80=99s what I thought,

Shahram


On Feb 22, 2017, at 12:16 PM, = Dave Katz <dkatz@juniper.net> wrote:

Right, the only point of the poll sequence when changing = timing is to keep the session from timing out (because, for example, the = transmit rate was reduced but the receiver didn=E2=80=99t yet know that = the holding time was being extended).

In this case, the session is already down, so you = can=E2=80=99t do too much damage to it.

=E2=80=94Dave

On Feb 22, 2017, at 12:03 PM, binnyjeshan@gmail.com wrote:

In my understanding based on 5+ Implementations I have seen, you NEED = NOT. 
 
When state moves to down, simply reduce the rate yourself.
 
Sent from Mail for Windows 10
 
From: Shahram Davari
Sent: Thursday, February 23, = 2017 1:31 AM
To: rtg-bfd@ietf.org
Subject: BFD interval in down = state
 
Hi 
 
When moving from UP to down state we are supposed to reduce the rate to = 1 sec. Do we need to do a poll sequence to reduce the rate?
 
Regards,
Shahram


= --Apple-Mail=_ACB15A20-5EC8-454E-832B-ACEF0F12265E-- From nobody Wed Feb 22 14:11:28 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 01A30129C35 for ; Wed, 22 Feb 2017 14:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 yN2gHyhE1Ypp for ; Wed, 22 Feb 2017 14:11:25 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 F3319129C31 for ; Wed, 22 Feb 2017 14:11:24 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id v186so153958366wmd.0 for ; Wed, 22 Feb 2017 14:11:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=O0hD4uo12nIRavprm6bwj1I1scS6h6MV9t6roT5W2d4=; b=d8iyooq+c16P5dga52rJAUSDtZ11idIvZU9mxzc1R3Ul3RwgOen4q0aLq4JyDm35/C nIIYAtDfpxf4P4elJqtANdk+/OTnBHgHL3TE42f/SA4l21Sv9kLGs7rIPjkBJCBabVWa FRGyzrllXmO+sSEjVJFO5BQcnbN3u66Zs0odQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=O0hD4uo12nIRavprm6bwj1I1scS6h6MV9t6roT5W2d4=; b=tMZZuhfy5J+egKnWa2yiXegDm64ZsIbh8RKKhmsezxCF8nATIID6xmjapw/PIO3WO7 8EH2ijdsGzFCZEERcKdibvRHgJ619vEsgRKns1hqpgQSrZicHMLnKtojNsEt0rOgE2vz UCUHF9OjpobbfQmDD0lvtp+LfYmekyr32dUj9k1PXK3u/BdfptuzpLEX+5LuS+t6TAXs t1gtAVYtxvUDV4050gsqMTb+tWKaS45thtoTeMNstedW2NNPaQiMEzuTvB/a+ZoNSdRS kvnbuLc3RLrfBJYyWAaGRvQcfnZGZo+qydXBvYwE/0EXtOlNgBQTErG4DC1fWf+EOlui /1bQ== X-Gm-Message-State: AMke39kJ70HyUTIumiYblxLiTFqPSQ7EedDU8T732aVm56GVQGAECPFVXzHtJxQxoRfSsk9O X-Received: by 10.28.158.74 with SMTP id h71mr319866wme.59.1487801483511; Wed, 22 Feb 2017 14:11:23 -0800 (PST) Received: from dhcpe1-sj1-102.sj.broadcom.com ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id 10sm4143124wmi.23.2017.02.22.14.11.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 22 Feb 2017 14:11:22 -0800 (PST) Subject: Re: BFD interval in down state Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_288A2C08-DAF6-463C-961B-AE17251D010F" From: Shahram Davari X-Priority: 3 In-Reply-To: <58adee72.cb52620a.ca404.8e29@mx.google.com> Date: Wed, 22 Feb 2017 14:11:24 -0800 Message-Id: <311124D4-D4CE-4D19-BE12-AEEFA62793B4@broadcom.com> References: <58adee72.cb52620a.ca404.8e29@mx.google.com> To: binnyjeshan@gmail.com X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 22 Feb 2017 22:11:27 -0000 --Apple-Mail=_288A2C08-DAF6-463C-961B-AE17251D010F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for your great input. SD > On Feb 22, 2017, at 12:03 PM, = wrote: >=20 > In my understanding based on 5+ Implementations I have seen, you NEED = NOT.=20 > =20 > When state moves to down, simply reduce the rate yourself. > =20 > Sent from Mail for = Windows 10 > =20 > From: Shahram Davari > Sent: Thursday, February 23, 2017 1:31 AM > To: rtg-bfd@ietf.org > Subject: BFD interval in down state > =20 > Hi=20 > =20 > When moving from UP to down state we are supposed to reduce the rate = to 1 sec. Do we need to do a poll sequence to reduce the rate? > =20 > Regards, > Shahram --Apple-Mail=_288A2C08-DAF6-463C-961B-AE17251D010F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks for your great input.

SD

On = Feb 22, 2017, at 12:03 PM, <binnyjeshan@gmail.com> <binnyjeshan@gmail.com> wrote:

In my understanding based = on 5+ Implementations I have seen, you NEED NOT. 
 
When state moves to down, simply reduce the rate = yourself.
 
Sent = from Mail for Windows 10
 
From: Shahram Davari
Sent: Thursday, February 23, = 2017 1:31 AM
To: rtg-bfd@ietf.org
Subject: BFD interval in down = state
 
Hi 
 
When moving from UP to down state we are supposed to reduce = the rate to 1 sec. Do we need to do a poll sequence to reduce the = rate?
 
Regards,
Shahram

= --Apple-Mail=_288A2C08-DAF6-463C-961B-AE17251D010F-- From nobody Thu Feb 23 18:38:56 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 A58B212949E for ; Thu, 23 Feb 2017 18:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 1YpCSLeTnrYU for ; Thu, 23 Feb 2017 18:38:53 -0800 (PST) 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 D8C8C129443 for ; Thu, 23 Feb 2017 18:38:52 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id 65so4905542oig.1 for ; Thu, 23 Feb 2017 18:38:52 -0800 (PST) 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=6hayw0HIbpWVRIxzAIvyAAFdDMdqkq6nALYoz959TdY=; b=K0lFHC5K4ToHvENltTqAhqXbr0VtCJZquMi7aigMq8yl2vF2NNaEE1wNFQz59mso2J vy8PMtUtKS6sNMeDgL42f9hWfpZBd/GbHsha8t5ZLij8RiVEYHPsjpwlmzHOBqEzHuGT KPekXBSjx/egm4IwDxaCpVa/WMfwaAWNTrKwlXIJHE8e4XTcvI4OWSRMD2+ci/e9woWd r3oAx73WpnpFlgkfFLQXZNfN2pToKpO1lc0V2OuBuJ4bqja6AokCcclKqbQjZS2tSPCP DSp3kLZCtbcLE6OVx9CNcGrEdYFg0lUeKOD+pI0Pi8ft2bfju6VPP2NO6wSP6UxKa8lG pCJQ== 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=6hayw0HIbpWVRIxzAIvyAAFdDMdqkq6nALYoz959TdY=; b=Kvr5/t1FIIubBxuB1+27EAcPkn5rcRLJVSAja4+RgEHs7aehypsKYhj9eW0qrlVk6p f8zVz2rTwSyKm/iyVOwS+6PvMaUj1TIrLs2YVGE0uL+fnZE7GUxfHhX4/Oi5qV0UKX8w 8oK7bLMj1Ptk4XjweehXvdL52YVhwQ7Iz2MgyrPvHgIJDfB8NxYRiAZ3V4CfvNxbR3Uz 0YtTlCDdGB34OSQK+/tnBZr8251Xk9EWXXCHizENsCD3ILi/cM9hUtsWeI18muTf/atJ pHtNrku16nXXCxzhocInV2hYTiLwbnkNTzAdypFiQN6Nqwz5KPEsrkzfH0L5sEChIckx V8AA== X-Gm-Message-State: AMke39lK27VVitt4Qjj+nAdQuEbuB6WbRm+aMW8p7P3CxdFFwBXlKYbT40JekyK36JO9HKe667ZIIxA2yKDGuA== X-Received: by 10.202.241.3 with SMTP id p3mr243364oih.86.1487903931933; Thu, 23 Feb 2017 18:38:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.3.212 with HTTP; Thu, 23 Feb 2017 18:38:51 -0800 (PST) From: Sonal Agarwal Date: Thu, 23 Feb 2017 18:38:51 -0800 Message-ID: Subject: Request to review "Security enhancments for BFD packet's sequence number" To: rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0925bc52ab1305493da1ae Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 24 Feb 2017 02:38:54 -0000 --94eb2c0925bc52ab1305493da1ae Content-Type: text/plain; charset=UTF-8 Hi all, Could the WG chairs and members please review this new draft? ** *You posted a new draft today. In the interest of informing your Cisco colleagues, would you be so kind as to fill the rest of us in on your project and what the draft is about?* ** What technology, solution, or service is this draft targeted toward?* ** What, specifically, does your draft propose?* ** What set of products are used in the technology, solution, or service, and would need to implement it?* ** What business segment would find this specifically useful, and why?* ** Do you have customer engagements related to it?* *The file may be found online at* *https://tools.ietf.org/html/draft-sonal-bfd-secure-sequence-numbers-00.txt* *By the way: if you know of a CPOL that might relate to this, and you have not done so, would you please access* *http://wwwin-eng.cisco.com/pcb/standards/csrt.cgi to register the relationship between the CPOL and the draft?* *The abstract you included reads:* * This document describes a security enhancements for the BFD packet's sequence number.* ** Thanks, Sonal. --94eb2c0925bc52ab1305493da1ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Could the WG chairs and members= please review this new draft?

= <snip>

You posted a new draft today= . In the interest of informing your Cisco=C2=A0colleagues, would you= be so kind as to fill the rest of us in on your project and what the draft= is about?

* What technology, solution, or service is this draft ta= rgeted=C2=A0toward?

* What, specifically, does your draft propose?

* What set of products are used in the technology, solut= ion, or=C2=A0service, and would need to implement it?

* What business segment would find this specifically use= ful, and why?

* Do you have customer engagements related to it?

The file may be found online at

https://tools.ietf.org/html/draft-sonal-bfd-= secure-sequence-numbers-00.txt

By the way: if you know of a CPOL that might relate to t= his, and you=C2=A0have not done so, would you please access

http://wwwin-eng.cisco.com/pcb/standards/csrt.cgi to register the=C2=A0relationship between the CPOL = and the draft?

The ab= stract you included reads:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0This document describes a = security enhancements for the BFD packet's=C2=A0sequence number.=

</snip>


Thanks,

Sonal.


--94eb2c0925bc52ab1305493da1ae-- From nobody Thu Feb 23 22:12: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 B895912959D for ; Thu, 23 Feb 2017 22:12:56 -0800 (PST) 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, MIME_QP_LONG_LINE=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 AYr2dpfWKwzR for ; Thu, 23 Feb 2017 22:12:54 -0800 (PST) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 D1C2D12959B for ; Thu, 23 Feb 2017 22:12:54 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id 2so1396070pfz.0 for ; Thu, 23 Feb 2017 22:12:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=P2IGbwfI96RVQwFmIY3FkxuwE8EADUSr0w4hBcp1w5o=; b=LNFAzuea5GoHVZk5HLSTQN1/yC/wzp5zWUY6ZmVScJReWP2y1iP7hpoPDvqHT2pHHu TwfNqZn8+R8YnY1uvH8ArmEKOpNWVpv2UcnC3cXw49b6wB27yjzQgf1Ol0Il2nX1KrQz enMuDy0NMyWXLuvWX7hwe0sTA59DuhBTZvaWSdkLKks1B16IS0hUr2AWBzGvpRW8PE8J QGunSCwYIMr80W6u/pXNrOMRTeq3C0JHgxc3fusaDFnehKWhRZ8T46oL6HCM2kniWE5g 8ClEcwMRcDmnlV6L/anyh1vc7ys98T4ZbRYpRk/N/wNPoBbHaIDpVknVbyyisAPJsHaa XXTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=P2IGbwfI96RVQwFmIY3FkxuwE8EADUSr0w4hBcp1w5o=; b=PzpxajkN5La0ZxiT/xTeMubdE2GoTUasczKg//5/rf0I4QpCxtdotgkZBCIq6gCWsh cxWk7+zVD3SOMvEBnfkdWZo50LvuoMoKEXT9NlGwjWmja5Z9nQ4WXqJHjSZTt6tp2z60 oxbdyibZIMxPhHf6ul8DQunvfZbsbbo/ObbMHA9e2yTCINzL4UKjNCJMw6/HHbhkoVux 5XgYuvdsdSSpkaUjo2CRpyFHzm3suey8wrZsyvjKjXhs5hozv5Glniv3emghH72alACs aab5X3ZF26ogHfVaQkOsBTHke1R5lJovhtdRFBh9dmobYh3yYkvYMwnlBKLMMQ/Mq0sQ oohA== X-Gm-Message-State: AMke39mfI/bsTWQbyOZYyukfN/LG4w1ToYuT4N4qehOiPyrdiJPpv+VJDbE8EDLwACROhQ== X-Received: by 10.84.142.101 with SMTP id 92mr1584019plw.66.1487916774318; Thu, 23 Feb 2017 22:12:54 -0800 (PST) Received: from ?IPv6:2602:306:cf77:df90:99e2:8888:527c:c852? ([2602:306:cf77:df90:99e2:8888:527c:c852]) by smtp.gmail.com with ESMTPSA id o66sm12841349pfa.119.2017.02.23.22.12.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 23 Feb 2017 22:12:53 -0800 (PST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-0FD728E2-9D86-44FB-9334-B3B2D82874C8 Content-Transfer-Encoding: 7bit Message-Id: <82C98FEC-E199-4F5D-BB41-932082C03F74@gmail.com> X-Mailer: iPad Mail (13G36) From: Mahesh Jethanandani Subject: Re: Request to review "Security enhancments for BFD packet's sequence number" Date: Thu, 23 Feb 2017 22:12:51 -0800 To: Sonal Agarwal Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 24 Feb 2017 06:12:56 -0000 --Apple-Mail-0FD728E2-9D86-44FB-9334-B3B2D82874C8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable What Sonal means to ask if for folks to review the draft. https://tools.ietf.org/html/draft-sonal-bfd-secure-sequence-numbers-00.txt The abstract of which reads: This document describes a security enhancements for the BFD packet's se= quence number. Ignore the rest of the mail. Mahesh Jethanandani mjethanandani@gmail.com > On Feb 23, 2017, at 6:38 PM, Sonal Agarwal wrote: >=20 > Hi all, >=20 > Could the WG chairs and members please review this new draft? >=20 > >=20 > You posted a new draft today. In the interest of informing your Cisco coll= eagues, would you be so kind as to fill the rest of us in on your project an= d what the draft is about? > * What technology, solution, or service is this draft targeted toward? >=20 > * What, specifically, does your draft propose? >=20 > * What set of products are used in the technology, solution, or service, a= nd would need to implement it? >=20 > * What business segment would find this specifically useful, and why? >=20 > * Do you have customer engagements related to it? >=20 > The file may be found online at >=20 > https://tools.ietf.org/html/draft-sonal-bfd-secure-sequence-numbers-00.txt= >=20 > By the way: if you know of a CPOL that might relate to this, and you have n= ot done so, would you please access >=20 > http://wwwin-eng.cisco.com/pcb/standards/csrt.cgi to register the relation= ship between the CPOL and the draft? >=20 > The abstract you included reads: >=20 > This document describes a security enhancements for the BFD packet's s= equence number. >=20 > >=20 >=20 >=20 > Thanks, >=20 > Sonal. >=20 >=20 --Apple-Mail-0FD728E2-9D86-44FB-9334-B3B2D82874C8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
What Sonal means to ask if for folks t= o review the draft.


<= /div>

<= span style=3D"background-color: rgba(255, 255, 255, 0);">The abstract of which reads:
=

  &= nbsp;  This document describes a security enhancements for the BFD= packet's sequence number.


Ignore the res= t of the mail.

Mahesh Jethanandani

On Feb 23, 2017= , at 6:38 PM, Sonal Agarwal <saga= rwal12@gmail.com> wrote:

=
Hi all,

Could the WG chairs and members p= lease review this new draft?

<= snip>

You posted a new draft today. In th= e interest of informing your Cisco colleagues, would you be so k= ind as to fill the rest of us in on your project and what the draft is about= ?

* What technology, solution, or service is this draft targ= eted toward?

* What, specifically, does your draft propose?<= /p>

* What set of products are used in the technology, solutio= n, or service, and would need to implement it?

* What business segment would find this specifically usefu= l, and why?

* Do you have customer engagements related to it?

The file may be found online at

https://tools.ietf.org/html/draft-sonal-bfd-sec= ure-sequence-numbers-00.txt

By the way: if you know of a CPOL that might relate to thi= s, and you have not done so, would you please access

http://wwwin-eng.cisco.com/pcb/standards/csrt.cgi to register the relationship between the CPOL and th= e draft?

The abs= tract you included reads:

     This document describes a se= curity enhancements for the BFD packet's sequence number.

</snip>


=

Thanks,

Sonal.


= --Apple-Mail-0FD728E2-9D86-44FB-9334-B3B2D82874C8-- From nobody Sat Feb 25 15:48:39 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 3BED312A3F1; Sat, 25 Feb 2017 15:48:38 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Cyxsxx-2TqXv; Sat, 25 Feb 2017 15:48:37 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 30D80129549; Sat, 25 Feb 2017 15:48:37 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id k4so33935866otc.0; Sat, 25 Feb 2017 15:48:37 -0800 (PST) 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=/Js/7/C3+uz4aFV/5EKnB4t0WwrVN6JyKXpmRShi+ps=; b=mxtv1UKxmIUDXfD9gAMUKaSsz6fzdYDQ+CmoRSUUbYXyDe3EvkoMCjDwoMHlizoCaT B+aYlDna7GYO6sONkD+mCPOBEPEd7dqiWFrTWbKuuNdgT/RsZQ6ChyQrIELRGYznNtWl 1Ko0sOiQurFbKZDuc/fQh+S4qdVUw07hC0ybe0PrIWQZwDregQlGkRQqbg6gR/oZ3v3e cFljNV5GeD2k79kS3ptOvYXHHio8z7TA6R5nctrQx0A7XvTWM/zLKGrmQeaPbPTxhoc7 iCRnOwIdJY09xvwMZPe5fK/wCdIwM82qCHW3Ld9RIOeGJDinSqZOdQ7Oi/Yt1pQNNrEp p9aA== 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=/Js/7/C3+uz4aFV/5EKnB4t0WwrVN6JyKXpmRShi+ps=; b=mZPr2EneyongxqeYJIPdPpJXgP8KI/Tk/EUcEC9u1Ekawn3fqi6qtWpvbNnrxwfwuQ kd8nnUxqWyQcNAI+RxRBRv6Z941hUL2JrBNrX2ambOn6Xk066hxOa754WOZi2pumUmLg da5QqRWwhgJIwV1DtEtqy3FA4xgqk0GirFlSgSekywJOtZCYboCbPv3fInVqtSft644I T+aNiF52YkkvpqgGFfbut4s+DnyFy09Z4fhCDWQtK9MkZTA8beAL01g0ZnrdOBv/WUcL ApdxQL2GGny2cJOmsMMsekXmdGlsmaFK1JlJ2+9MilxD3zg8AMHDf8giCMvqoOUv2Bdc 32EQ== X-Gm-Message-State: AMke39mlT0bxD/dJc6jQg9rlTLjLNeiCsv3blHVvarL8IqJssqHrkA/0/7/fQbRRtYeUX+gzI0EYvW2jz/9kBg== X-Received: by 10.157.56.137 with SMTP id p9mr3822654otc.68.1488066516391; Sat, 25 Feb 2017 15:48:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Sat, 25 Feb 2017 15:48:36 -0800 (PST) From: Greg Mirsky Date: Sat, 25 Feb 2017 15:48:36 -0800 Message-ID: Subject: Correcting BFD Echo model To: "rtg-bfd@ietf.org" , draft-ietf-bfd-yang@ietf.org Content-Type: multipart/alternative; boundary=001a11c10e5e1ca1210549637c1e Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2017 23:48:38 -0000 --001a11c10e5e1ca1210549637c1e Content-Type: text/plain; charset=UTF-8 Dear All, I've reviewed the BFD YANG model and now I'm thinking that desired-min-echo-tx-interval and attributing to it the behavior, i.e. when the value is 0, of Required Min Echo RX Interval are not in the right place. I think that definition of desired transmit interval of BFD Echo should be in corresponding RPC definition, not in configuration part of the model. Appreciate your comments. Regards, Greg --001a11c10e5e1ca1210549637c1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,
I've reviewed the BFD YANG model and now= I'm thinking that d= esired-min-echo-tx-interval and attributing to it the behavior, i.e. when t= he value is 0, of=C2=A0Required Min Echo RX Interval are not in the right place. I = think that definition of desired transmit interval of BFD Echo should be in= corresponding RPC definition, not in configuration part of the model.
Appreciat= e your comments.

Regards,
Greg
--001a11c10e5e1ca1210549637c1e-- From nobody Sun Feb 26 14:52:59 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 6ED691294AA; Sun, 26 Feb 2017 14:52:58 -0800 (PST) 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, 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, 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 sOsS14Jy3nmQ; Sun, 26 Feb 2017 14:52:57 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2503412941E; Sun, 26 Feb 2017 14:52:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5021; q=dns/txt; s=iport; t=1488149577; x=1489359177; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=zBJI35oQ1RjjWy0RVUNtBNFSNIGxYqPY45YlF1r/jmM=; b=VWZaz6SGXaR6TuQNJT0wFXhD0qT5+ADPKtlE+xH+Ogywenw5ZG7nxVFp TxmtePP37T83zlK3k7Ok12Ex4WD/TXd9hLuMnvmAhsCD9dzCAB1qB7Z/I Dk9FOxW8qetVklbFXSRuLDps8JtqkS+IvI6AFNNsltQ5wKtS1nvyMiv4f o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAQD8WrNY/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5igWoHjVyRXogMh32FLIINhiICghA/GAECAQEBAQEBAWIohHA?= =?us-ascii?q?BAQEEgQkCAQgRAwECKAchERQJCAIEARKJXAMVsXaHKQ2EAAEBAQEBAQEDAQEBA?= =?us-ascii?q?QEBAQEghkyEb4JRgiOFRQWVbYV3OgGOBYQhgXuFIIl9ikqIZgEfOIEBVBWHC3W?= =?us-ascii?q?JSYENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,211,1484006400"; d="scan'208,217";a="390804564" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2017 22:52:56 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v1QMqu1L026091 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 26 Feb 2017 22:52:56 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; Sun, 26 Feb 2017 16:52:55 -0600 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; Sun, 26 Feb 2017 16:52:55 -0600 From: "Reshad Rahman (rrahman)" To: Greg Mirsky , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" Subject: Re: Correcting BFD Echo model Thread-Topic: Correcting BFD Echo model Thread-Index: AQHSj8Gxk5FkqTOyS0attHx6x8g/UaF791cA Date: Sun, 26 Feb 2017 22:52:55 +0000 Message-ID: References: In-Reply-To: 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.241.101] Content-Type: multipart/alternative; boundary="_000_D4D8BE3125AE5Crrahmanciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 22:52:58 -0000 --_000_D4D8BE3125AE5Crrahmanciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Can you please explain why you believe this should go in RPC? Regards, Reshad. From: Greg Mirsky > Date: Saturday, February 25, 2017 at 6:48 PM To: "rtg-bfd@ietf.org" >, "draft-ietf-bfd-yang@ietf.org" > Subject: Correcting BFD Echo model Resent-From: > Resent-To: >, Reshad >, >, >, = > Resent-Date: Saturday, February 25, 2017 at 6:48 PM Dear All, I've reviewed the BFD YANG model and now I'm thinking that desired-min-echo= -tx-interval and attributing to it the behavior, i.e. when the value is 0, = of Required Min Echo RX Interval are not in the right place. I think that d= efinition of desired transmit interval of BFD Echo should be in correspondi= ng RPC definition, not in configuration part of the model. Appreciate your comments. Regards, Greg --_000_D4D8BE3125AE5Crrahmanciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1E717F706FEDD7438D80C47C62A356E8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Greg,

Can you please explain why you believe this should go in RPC?

Regards,
Reshad.

From: Greg Mirsky <gregimirsky@gmail.com>
Date: Saturday, February 25, 2017 a= t 6:48 PM
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-yang@ietf.org" <draft-ietf-bfd-yang@ietf.org>
Subject: Correcting BFD Echo model<= br> Resent-From: <alias-bounces@ietf.org>
Resent-To: <vero.zheng@huawei.com>, Reshad <rrahman@cisco.com>, <mjethanandani@gmail.com>, <santosh.pallagatti@gmail.com>, <gregimirsky@gmail.com>=
Resent-Date: Saturday, February 25,= 2017 at 6:48 PM

Dear All,
I've reviewed the BFD YANG model and now I'm thinking that desired-min-echo-tx-interval and = attributing to it the behavior, i.e. when the value is 0, of Required Min Echo= RX Interval are not in the right place. I think that definition of desired transmit interval of BFD Echo should be= in corresponding RPC definition, not in configuration part of the model.
Appreciate your c= omments.

Regards,
Greg
--_000_D4D8BE3125AE5Crrahmanciscocom_-- From nobody Sun Feb 26 16:39:12 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 19BB9129494; Sun, 26 Feb 2017 16:39:11 -0800 (PST) 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 ug8DYp5LtXxN; Sun, 26 Feb 2017 16:39:09 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003: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 C796D1299F6; Sun, 26 Feb 2017 16:39:09 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id f192so12532287oic.3; Sun, 26 Feb 2017 16:39:09 -0800 (PST) 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=TOemXZSx5wcRqy0q9PvmhT/OlPkGZFyDXjsoFqgpTLM=; b=nFEd9rC5VO2lpprKLcYxaF+wjNJnJTN01etVjUqvv7AHH6hFVWTc2bCjeRXCSExRow 69fK6DWgTJmKrjIBwwmrUTHkVmTy8pvPb7mWNZp0nxv6kUX4MOmuCBMf0tC9xKTK18ZM eW2uluViUEJeNmt89LHxxrd+9BBDC4x1QgA6Wiz8Njt9PYdXHnCWIKLjwqjtI/WYsdT6 Boa8XQQ6vJNjtejct7glZficoZVyqEfJ98w1aKYzeli2qYzPnbfNiVBeIxk+bWRWnmXu hNCrITKO/srs2wqIrLH7aiY1D8nTgidPy8R5aD3Trs+S9HleIo4S1hXPicJ24Lux6kNo ioxA== 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=TOemXZSx5wcRqy0q9PvmhT/OlPkGZFyDXjsoFqgpTLM=; b=bNDyhhkMSd4mYfMa/agcwvYeOFCkXtM1QGyjAtDDrnrOpqjRjEh1WpaD5iIyYAoSKB pFLsRyQFuqdkT2rKpKC/OlGFoVNzIlRGWVP1Oq/Hg3Z3sdR1o0QCFPHVD+NmFtMtkMHs hU593ZcESzLIbB5dx8nlafuv5q4wPGnx3Ues6h7z8mgfqzxqSj13LNgjg3EvcLARwzqn kxUxzMg8FTa+x0FH17zy5qkY71fTgELOZLtCO7I05yad+/3KcdlUBNfBMnJhFL2U6e2l 2/Tg8l0JBG/yiFa6IiqXt5WP6qdcYvjZizcauhMeBAe2kPOXsxgEPRdAboFzXV4J8b6x T0mg== X-Gm-Message-State: AMke39mH8kd0ngxI3dCv8GYkO0Xm30jBh3Fwy+w1UR//2RH/bLLiitYA4RwiP5/yjHhPuynKBPnNS9PxTVPqdw== X-Received: by 10.202.232.210 with SMTP id f201mr6347889oih.60.1488155949086; Sun, 26 Feb 2017 16:39:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Sun, 26 Feb 2017 16:39:08 -0800 (PST) In-Reply-To: References: From: Greg Mirsky Date: Sun, 26 Feb 2017 16:39:08 -0800 Message-ID: Subject: Re: Correcting BFD Echo model To: "Reshad Rahman (rrahman)" Content-Type: multipart/alternative; boundary=001a11407b32b73fd30549784edc Archived-At: Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 00:39:11 -0000 --001a11407b32b73fd30549784edc Content-Type: text/plain; charset=UTF-8 Hi Reshad, thank you for the question. Here's my reasoning: - only Required Min Echo RX Interval is present in RFC 5880 and it allows to indicate not only the smallest interval between consecutive BFD Echo packets but whether system supports BFD Echo function at all; - since BFD Echo may be transmitted only when the session state is Up, operator is fully equipped to learn the value of Required Min Echo RX Interval of its BFD peer and to set Echo transmit interval accordingly; - requesting BFD Echo, in my opinion, is no different from requesting IP ping or LSP ping. Hence my conclusion - transmit interval for BFD Echo is more suitable in RPC then as configuration parameter. Regards, Greg On Sun, Feb 26, 2017 at 2:52 PM, Reshad Rahman (rrahman) wrote: > Hi Greg, > > Can you please explain why you believe this should go in RPC? > > Regards, > Reshad. > > From: Greg Mirsky > Date: Saturday, February 25, 2017 at 6:48 PM > To: "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" > > Subject: Correcting BFD Echo model > Resent-From: > Resent-To: , Reshad , < > mjethanandani@gmail.com>, , < > gregimirsky@gmail.com> > Resent-Date: Saturday, February 25, 2017 at 6:48 PM > > Dear All, > I've reviewed the BFD YANG model and now I'm thinking that desired-min-echo-tx-interval > and attributing to it the behavior, i.e. when the value is 0, of Required > Min Echo RX Interval are not in the right place. I think that definition of > desired transmit interval of BFD Echo should be in corresponding RPC > definition, not in configuration part of the model. > Appreciate your comments. > > Regards, > Greg > --001a11407b32b73fd30549784edc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Reshad,
thank you for the question. Here's my r= easoning:
  • only Required Min Echo RX Interval is present i= n RFC 5880 and it allows to indicate not only the smallest interval between= consecutive BFD Echo packets but whether system supports BFD Echo function= at all;
  • since BFD Echo may be transmitted only when the session st= ate is Up, operator is fully equipped to learn the value of Required Min Ec= ho RX Interval of its BFD peer and to set Echo transmit interval accordingl= y;
  • requesting BFD Echo, in my opinion, is no different from request= ing IP ping or LSP ping.
Hence my conclusion - transmit inter= val for BFD Echo is more suitable in RPC then as configuration parameter.

Regards,
Greg

On Sun, Feb 26, 2017 at 2:5= 2 PM, Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:
=
Hi Greg,

Can you please explain why you believe this should go in RPC?

Regards,
Reshad.

From: Greg Mirsky <gregimirsky@gmail.com>=
Date: Saturday, February 25, 2017 a= t 6:48 PM
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bf= d-yang@ietf.org" <draft-ietf-bfd-yang@ietf.org>
Subject: Correcting BFD Echo model<= br> Resent-From: <alias-bounces@ietf.org> Resent-To: <vero.zheng@huawei.com>, Resha= d <rrahman@cisco.= com>, <mjethanandani@gmail.com>, <santosh.pallagatti@gmail.com>, <gregimirsky= @gmail.com>
Resent-Date: Saturday, February 25,= 2017 at 6:48 PM

Dear All,
I've reviewed the BFD YANG model and now I'm thinking that desired-min-echo-tx-interval and = attributing to it the behavior, i.e. when the value is 0, of=C2=A0Required Min Echo= RX Interval are not in the right place. I think that definition of desired transmit interval of BFD Echo should be= in corresponding RPC definition, not in configuration part of the model.
Appreciate your c= omments.

Regards,
Greg

--001a11407b32b73fd30549784edc-- From nobody Sun Feb 26 20:33:14 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 0354F1296F2; Sun, 26 Feb 2017 20:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 bWj8voWxjUcQ; Sun, 26 Feb 2017 20:33:11 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::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 2FFBD127058; Sun, 26 Feb 2017 20:33:11 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id p5so14703182pga.1; Sun, 26 Feb 2017 20:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=9n8la2ZfNW7HKyZ8wJwfbqDgBamgoHTD962lw1+iOzU=; b=P3ZKkSLAjIVME5Lfku2OepGBar1MfAcVVqFJNJR2k2weaDFWxFDnbBj8W84BJoggAX +wjdo6Vd0RxqGtRtWbAQjVhc2BGG+4pQmgsNZu7zvPjfhbVWazNHy/PT/FNN06hHvrRs SeiRgooFiOdDc7z7+iyiryvLoFkWhaBSXwWVDIdY4RWg0fgpQydg5wPXf65H7UtfhHY+ 8ShVzg3gYOJP8E+h4D52Qd8T2yiC4bH+WpdS5BOBGzJFpXXLvs/jf/WcF4szxjvtL8rs s/Td1sfLXv3g5i2cUOLNP41OX0OGo9IrGfHxjADExuwj37rkj+v9THHsJTDkMxlWkOkT xGvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=9n8la2ZfNW7HKyZ8wJwfbqDgBamgoHTD962lw1+iOzU=; b=jp9UbuFcsApZgqieRrOlJf5fz93ZfJk0h6p0vOh7pFCvpl9viTv1qIPTfswO7AQrBJ 8psS14L9QhBsDGTFMHuIO/97jMJZ91WYhTWXsNjZCj0AA5tUXFph0AU4YywGQ/Io6Wqh qZ07cJ8MyklamF+lt0F76pM3ro3fVdJ/QHY25piGgmy9nxnej5b+OwslpNvjP/iMO3gX hUFMu/S7qxQQVFggMaaDRp5ES1vUUrSZXmWP5qGl4ZsOvvD+BRJbekWy3H4sd/j9r6M2 QgYnzfahqMyIXaHNTohrtM+//i7PEYK0fHtuIVoLC6j0uqSgyeO14idD/EKoys38oW// 1Spg== X-Gm-Message-State: AMke39kdZQLe2THkOsAWvk6oeJPnF3Cfe6KsNgYFEgiT9fbUly10zeFloyd346vM8PMcdw== X-Received: by 10.84.210.228 with SMTP id a91mr2876328pli.120.1488169990683; Sun, 26 Feb 2017 20:33:10 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2602:306:cf77:df90:3034:ab32:9822:dd2a]) by smtp.gmail.com with ESMTPSA id 85sm15473248pfz.15.2017.02.26.20.33.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 26 Feb 2017 20:33:09 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1657134F-4A55-4727-87CD-1E8CD752E93A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Correcting BFD Echo model From: Mahesh Jethanandani In-Reply-To: Date: Sun, 26 Feb 2017 20:33:04 -0800 Message-Id: References: To: Greg Mirsky X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf. org" , "draft-ietf-bfd-yang@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 04:33:13 -0000 --Apple-Mail=_1657134F-4A55-4727-87CD-1E8CD752E93A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 26, 2017, at 4:39 PM, Greg Mirsky = wrote: >=20 > Hi Reshad, > thank you for the question. Here's my reasoning: > only Required Min Echo RX Interval is present in RFC 5880 and it = allows to indicate not only the smallest interval between consecutive = BFD Echo packets but whether system supports BFD Echo function at all; > since BFD Echo may be transmitted only when the session state is Up, = operator is fully equipped to learn the value of Required Min Echo RX = Interval of its BFD peer and to set Echo transmit interval accordingly; > requesting BFD Echo, in my opinion, is no different from requesting IP = ping or LSP ping. > Hence my conclusion - transmit interval for BFD Echo is more suitable = in RPC then as configuration parameter. I do not think that is reason enough for it to be a RPC. A RPC is an operation one defines in the YANG model specifying both = input and output parameters. There are no operations to be had here. And the definition and desired behavior of desired-min-echo-tx-interval = is not very different from required-min-echo-x-interval. It is as the = definition says, a configuration parameter that can be set, with zero = having a special meaning in both cases. >=20 > Regards, > Greg >=20 > On Sun, Feb 26, 2017 at 2:52 PM, Reshad Rahman (rrahman) = > wrote: > Hi Greg, >=20 > Can you please explain why you believe this should go in RPC? >=20 > Regards, > Reshad. >=20 > From: Greg Mirsky > > Date: Saturday, February 25, 2017 at 6:48 PM > To: "rtg-bfd@ietf.org " >, "draft-ietf-bfd-yang@ietf.org = " > > Subject: Correcting BFD Echo model > Resent-From: > > Resent-To: >, = Reshad >, = >, = >, = > > Resent-Date: Saturday, February 25, 2017 at 6:48 PM >=20 > Dear All, > I've reviewed the BFD YANG model and now I'm thinking that = desired-min-echo-tx-interval and attributing to it the behavior, i.e. = when the value is 0, of Required Min Echo RX Interval are not in the = right place. I think that definition of desired transmit interval of BFD = Echo should be in corresponding RPC definition, not in configuration = part of the model. > Appreciate your comments. >=20 > Regards, > Greg >=20 --Apple-Mail=_1657134F-4A55-4727-87CD-1E8CD752E93A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Feb 26, 2017, at 4:39 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Reshad,
thank you for the question. Here's = my reasoning:
  • only = Required Min Echo RX Interval is present in RFC 5880 and it allows to = indicate not only the smallest interval between consecutive BFD Echo = packets but whether system supports BFD Echo function at all;
  • since BFD Echo may be transmitted only when the session state = is Up, operator is fully equipped to learn the value of Required Min = Echo RX Interval of its BFD peer and to set Echo transmit interval = accordingly;
  • requesting BFD Echo, in my opinion, is = no different from requesting IP ping or LSP ping.
Hence my conclusion - transmit interval for BFD Echo is more = suitable in RPC then as configuration = parameter.

I= do not think that is reason enough for it to be a RPC.

A RPC is an operation one defines in the YANG = model specifying both input and output parameters. There are no = operations to be had here.

And the = definition and desired behavior of desired-min-echo-tx-interval is not = very different from required-min-echo-x-interval. It is as the = definition says, a configuration parameter that can be set, with zero = having a special meaning in both cases.


Regards,
Greg

On Sun, = Feb 26, 2017 at 2:52 PM, Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:
Hi Greg,

Can you please explain why you believe this should go in = RPC?

Regards,
Reshad.

From: Greg Mirsky = <gregimirsky@gmail.com>
Date: Saturday, = February 25, 2017 at 6:48 PM
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-yang@ietf.org" <draft-ietf-bfd-yang@ietf.org>
Subject: Correcting = BFD Echo model
Resent-From: <alias-bounces@ietf.org>
Resent-To: <vero.zheng@huawei.com>, Reshad <rrahman@cisco.com>, <mjethanandani@gmail.com>, <santosh.pallagatti@gmail.com>, <gregimirsky@gmail.com>
Resent-Date: = Saturday, February 25, 2017 at 6:48 PM

Dear All,
I've reviewed the BFD YANG model and now I'm thinking = that desired-min-echo-tx-interval and attributing to it the = behavior, i.e. when the value is 0, of Required Min Echo RX Interval = are not in the right place. I think that definition of desired transmit interval of BFD Echo should = be in corresponding RPC definition, not in configuration part of the = model.
Appreciate your comments.

Regards,
Greg


= --Apple-Mail=_1657134F-4A55-4727-87CD-1E8CD752E93A-- From nobody Sun Feb 26 22:08: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 7AC2F129B5C; Sun, 26 Feb 2017 22:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 94vDWWTUTvQq; Sun, 26 Feb 2017 22:07:59 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 31665129B0C; Sun, 26 Feb 2017 22:07:59 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id k4so45612802otc.0; Sun, 26 Feb 2017 22:07:59 -0800 (PST) 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=ZgYC6vkA4YHQFtLRg5B9FhJ7CIUhAdtqDG9OLHvWrvA=; b=nP6rpDiR8h4K45HVwVgIlwpMY4Fn+hpA+FB88yl4zSQIS7JQ7ZFFxR3kQyYG3XvdGR FPcibvcvUOwAXt9AKrsCTbnwd/2piTgFD1Vtr4bsOzo4uKBVxEex16WRA4/Yg/pOu7gs wkEQfc7AGXtlzKVPBawChN9LomP3I/AMmMMjtWWtuC6g7N9n8+SiYGU5VCu25++oI4ju diEIhlOlTHiVmsGDbwp7gV5zbUHuA6C5/oqiNST4twyr9v65PBArkgZXDuxI4buafkSs 1rCDsdl23y3MfV+qBiQOvekREV9O+CLNO4BlrvPQFwVerrgt5/Lh+DRbfBoHxyKnQCnR 2q+A== 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=ZgYC6vkA4YHQFtLRg5B9FhJ7CIUhAdtqDG9OLHvWrvA=; b=doa/jwJbnX5QhEgfdfNPP0XzB0HHmC/P6xaU6thL00HOiHlNQcdQesqvCEESLqapCj fOh00J/YsGta5spWxBPOkxWQS78qzVyOIDrIztWWT37ensDAXSvlNwYGwmQobEAK2G5T pj7aZkfQF2eDb9VzGY1ST0Ed7+G4/5+DLltfTVbuoG89IPeM+d303pLu/bca8z7xlS+2 X+qZ8pMgjZo9Is01eBv3yD/62xLM6bKozqb0xAtYcYVUSL4SyXMZN7g7BZVyJoZ6O114 WaDb9GgCe0TcESk7y5o8qPCD/OKldncJubSao6xq5s+FFCKBWWwzN4h5BDAoy4pZ81Hk yJbw== X-Gm-Message-State: AMke39ldafBaYpU/e6DTMOEPk37YS5DhHOZljn3Pyda8IEmtlbPlA+o9Kj0fGF9Vc0GAlAbpUjH6rcy+HJJF8w== X-Received: by 10.157.1.229 with SMTP id e92mr6917009ote.40.1488175678493; Sun, 26 Feb 2017 22:07:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Sun, 26 Feb 2017 22:07:58 -0800 (PST) In-Reply-To: References: From: Greg Mirsky Date: Sun, 26 Feb 2017 22:07:58 -0800 Message-ID: Subject: Re: Correcting BFD Echo model To: Mahesh Jethanandani Content-Type: multipart/alternative; boundary=94eb2c03c39aae19a005497ce6a4 Archived-At: Cc: "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf. org" , "draft-ietf-bfd-yang@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 06:08:00 -0000 --94eb2c03c39aae19a005497ce6a4 Content-Type: text/plain; charset=UTF-8 Hi Mahesh, BFD Echo transmit interval is not part of RFC 5880, only Rx interval is. And Rx interval is sufficent to reflect whether local system is willing to receive BFD Echo messages from the particular BFD peer. Introduced desired-min-echo-tx-interval functionally overlaps with the standard-defined required-min-echo-rx-interval. Hence my suggestion to remove desired-min-echo-tx-interval from grouping bfd-grouping-echo-cfg-parms. But operators need a way to specify transmit interval for on-demand OAM command like BFD Echo, IP ping or LSP ping. I couldn't find YANG model proposal for IP ping but in draft-zheng-mpls-lsp-ping-yang-cfg transmit interval used in RPC, not as part of configuration. Regards, Greg On Sun, Feb 26, 2017 at 8:33 PM, Mahesh Jethanandani < mjethanandani@gmail.com> wrote: > > On Feb 26, 2017, at 4:39 PM, Greg Mirsky wrote: > > Hi Reshad, > thank you for the question. Here's my reasoning: > > - only Required Min Echo RX Interval is present in RFC 5880 and it > allows to indicate not only the smallest interval between consecutive BFD > Echo packets but whether system supports BFD Echo function at all; > - since BFD Echo may be transmitted only when the session state is Up, > operator is fully equipped to learn the value of Required Min Echo RX > Interval of its BFD peer and to set Echo transmit interval accordingly; > - requesting BFD Echo, in my opinion, is no different from requesting > IP ping or LSP ping. > > Hence my conclusion - transmit interval for BFD Echo is more suitable in > RPC then as configuration parameter. > > > I do not think that is reason enough for it to be a RPC. > > A RPC is an operation one defines in the YANG model specifying both input > and output parameters. There are no operations to be had here. > > And the definition and desired behavior of desired-min-echo-tx-interval is > not very different from required-min-echo-x-interval. It is as the > definition says, a configuration parameter that can be set, with zero > having a special meaning in both cases. > > > Regards, > Greg > > On Sun, Feb 26, 2017 at 2:52 PM, Reshad Rahman (rrahman) < > rrahman@cisco.com> wrote: > >> Hi Greg, >> >> Can you please explain why you believe this should go in RPC? >> >> Regards, >> Reshad. >> >> From: Greg Mirsky >> Date: Saturday, February 25, 2017 at 6:48 PM >> To: "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" >> >> Subject: Correcting BFD Echo model >> Resent-From: >> Resent-To: , Reshad , < >> mjethanandani@gmail.com>, , < >> gregimirsky@gmail.com> >> Resent-Date: Saturday, February 25, 2017 at 6:48 PM >> >> Dear All, >> I've reviewed the BFD YANG model and now I'm thinking that desired-min-echo-tx-interval >> and attributing to it the behavior, i.e. when the value is 0, of Required >> Min Echo RX Interval are not in the right place. I think that definition of >> desired transmit interval of BFD Echo should be in corresponding RPC >> definition, not in configuration part of the model. >> Appreciate your comments. >> >> Regards, >> Greg >> > > > --94eb2c03c39aae19a005497ce6a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mahesh,
BFD Echo transmit interval is not part of R= FC 5880, only Rx interval is. And Rx interval is sufficent to reflect wheth= er local system is willing to receive BFD Echo messages from the particular= BFD peer. Introduced desired-min-echo-tx-interval functionally overlaps wi= th the standard-defined=C2=A0required-m= in-echo-rx-interval.=C2=A0Hence my suggestion to remove=C2=A0desired-min-echo-tx-interval from=C2=A0grouping bfd-grouping-echo-cfg-parms.= But operators need a way to specify transmit interval for on-demand OAM co= mmand like BFD Echo, IP ping or LSP ping. I couldn't find YANG model pr= oposal for IP ping but in=C2=A0draft-zheng-mpls-lsp-ping-yang-cfg transm= it interval used in RPC, not as part of configuration.

Regards= ,
Greg


On Sun, Feb 26, 2017 at 8:33 PM, Mahesh Jethanandani <= span dir=3D"ltr"><mjethanandani@gmail.com> wrote:

On Feb 26, 2017, at 4:39 PM, Greg Mirsky &l= t;gregimirsky@gm= ail.com> wrote:

Hi Reshad,
thank you for the questi= on. Here's my reasoning:
  • only Required Min Echo RX In= terval is present in RFC 5880 and it allows to indicate not only the smalle= st interval between consecutive BFD Echo packets but whether system support= s BFD Echo function at all;
  • since BFD Echo may be transmitted only = when the session state is Up, operator is fully equipped to learn the value= of Required Min Echo RX Interval of its BFD peer and to set Echo transmit = interval accordingly;
  • requesting BFD Echo, in my opinion, is no dif= ferent from requesting IP ping or LSP ping.
Hence my conclusi= on - transmit interval for BFD Echo is more suitable in RPC then as configu= ration parameter.

I do not think that is reason enough for it to be a RPC.

A RPC is an operation one defines in the YANG model specifying both= input and output parameters. There are no operations to be had here.
=

And the definition and desired behavior of desired-min-= echo-tx-interval is not very different from required-min-echo-x-interval. I= t is as the definition says, a configuration parameter that can be set, wit= h zero having a special meaning in both cases.
<= br>

Rega= rds,
Greg

On Sun, Feb 26, 2017 at 2:52 PM, Reshad Rahman (rrahman) <rr= ahman@cisco.com> wrote:
Hi Greg,

Can you please explain why you believe this should go in RPC?

Regards,
Reshad.

From: Greg Mirsky <gregimirsky@gmail.com>=
Date: Saturday, February 25, 2017 a= t 6:48 PM
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bf= d-yang@ietf.org" <draft-ietf-bfd-yang@ietf.org>
Subject: Correcting BFD Echo model<= br> Resent-From: <alias-bounces@ietf.org> Resent-To: <vero.zheng@huawei.com>, Resha= d <rrahman@cisco.= com>, <mjethanandani@gmail.com>, <santosh.pallagatti@gmail.com>, <gregimirsky= @gmail.com>
Resent-Date: Saturday, February 25,= 2017 at 6:48 PM

Dear All,
I've reviewed the BFD YANG model and now I'm thinking that desired-min-echo-tx-interval and = attributing to it the behavior, i.e. when the value is 0, of=C2=A0Required Min Echo RX Interval are = not in the right place. I think that definition of desired transmit interval of BFD Echo should be= in corresponding RPC definition, not in configuration part of the model.
Appreciate your comments.

Regards,
Greg



--94eb2c03c39aae19a005497ce6a4-- From nobody Mon Feb 27 05:56:34 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 498311298C8; Mon, 27 Feb 2017 05:56:33 -0800 (PST) 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 KH5P8cNjfJRU; Mon, 27 Feb 2017 05:56:31 -0800 (PST) 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 E9D8E129528; Mon, 27 Feb 2017 05:56:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14631; q=dns/txt; s=iport; t=1488203790; x=1489413390; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jHSfvXIfMxHfvEDeX0T9W7REXXtnr+qtTTzlWIjx7IY=; b=PPseqhxxlhUGtVO+qw5v/3Ieskgk1GH52KFRh9r71DOvYyXOFOxq3Qeh edCwyh06iCJXVfUN6iwH5wN/LaHQlMptnXmIEc19T1BpGP+QSzqvjAThz 1GtsXCMAaJ4hGBoqQOJ1L2dxqCJWwkI/k6Es8v7WDy4K2o+B70CC7ANO9 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQDeLrRY/5tdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm45KYFqB41ckWCIDId9hSyCDYYiAoIXPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?wAQEBBHkQAgEIEQMBAigHIREUCQgCBAENBYlcAxWyG4cxDYQAAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYZMhG+CUYIjhUUFkBKFW4V3OgGOBYQhgXuFIIl9ikqIZgE?= =?us-ascii?q?fOIEBVBWHC3WJDQGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,214,1484006400"; d="scan'208,217";a="389281458" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2017 13:56:29 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v1RDuTkZ011571 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Feb 2017 13:56:29 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Feb 2017 07:56:28 -0600 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, 27 Feb 2017 07:56:28 -0600 From: "Reshad Rahman (rrahman)" To: Greg Mirsky , Mahesh Jethanandani Subject: Re: Correcting BFD Echo model Thread-Topic: Correcting BFD Echo model Thread-Index: AQHSj8Gxk5FkqTOyS0attHx6x8g/UaF791cAgABxigCAAEFcAIAAGoQAgAAvKQA= Date: Mon, 27 Feb 2017 13:56:28 +0000 Message-ID: References: In-Reply-To: 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: [161.44.212.65] Content-Type: multipart/alternative; boundary="_000_D4D9967A25B679rrahmanciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf. org" , "draft-ietf-bfd-yang@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 13:56:33 -0000 --_000_D4D9967A25B679rrahmanciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Greg, draft-zheng-mpls-ls-ping-yang-cfg defines transmit interval in RPC because = all ping operations are done via RPC. I do not consider BFD echo to be "on= demand" like LSP Ping (caveat: this is possibly due to the BFD configurati= on/implementation I am most familiar with). Regards, Reshad. From: Greg Mirsky > Date: Monday, February 27, 2017 at 1:07 AM To: Mahesh Jethanandani > Cc: Reshad >, "rtg-bfd@ietf.org= " >, "dr= aft-ietf-bfd-yang@ietf.org" > Subject: Re: Correcting BFD Echo model Hi Mahesh, BFD Echo transmit interval is not part of RFC 5880, only Rx interval is. An= d Rx interval is sufficent to reflect whether local system is willing to re= ceive BFD Echo messages from the particular BFD peer. Introduced desired-mi= n-echo-tx-interval functionally overlaps with the standard-defined required= -min-echo-rx-interval. Hence my suggestion to remove desired-min-echo-tx-in= terval from grouping bfd-grouping-echo-cfg-parms. But operators need a way = to specify transmit interval for on-demand OAM command like BFD Echo, IP pi= ng or LSP ping. I couldn't find YANG model proposal for IP ping but in draf= t-zheng-mpls-lsp-ping-yang-cfg transmit interval used in RPC, not as part o= f configuration. Regards, Greg On Sun, Feb 26, 2017 at 8:33 PM, Mahesh Jethanandani > wrote: On Feb 26, 2017, at 4:39 PM, Greg Mirsky > wrote: Hi Reshad, thank you for the question. Here's my reasoning: * only Required Min Echo RX Interval is present in RFC 5880 and it allo= ws to indicate not only the smallest interval between consecutive BFD Echo = packets but whether system supports BFD Echo function at all; * since BFD Echo may be transmitted only when the session state is Up, = operator is fully equipped to learn the value of Required Min Echo RX Inter= val of its BFD peer and to set Echo transmit interval accordingly; * requesting BFD Echo, in my opinion, is no different from requesting I= P ping or LSP ping. Hence my conclusion - transmit interval for BFD Echo is more suitable in RP= C then as configuration parameter. I do not think that is reason enough for it to be a RPC. A RPC is an operation one defines in the YANG model specifying both input a= nd output parameters. There are no operations to be had here. And the definition and desired behavior of desired-min-echo-tx-interval is = not very different from required-min-echo-x-interval. It is as the definiti= on says, a configuration parameter that can be set, with zero having a spec= ial meaning in both cases. Regards, Greg On Sun, Feb 26, 2017 at 2:52 PM, Reshad Rahman (rrahman) > wrote: Hi Greg, Can you please explain why you believe this should go in RPC? Regards, Reshad. From: Greg Mirsky > Date: Saturday, February 25, 2017 at 6:48 PM To: "rtg-bfd@ietf.org" >, "draft-ietf-bfd-yang@ietf.org" > Subject: Correcting BFD Echo model Resent-From: > Resent-To: >, Reshad >, >, >, = > Resent-Date: Saturday, February 25, 2017 at 6:48 PM Dear All, I've reviewed the BFD YANG model and now I'm thinking that desired-min-echo= -tx-interval and attributing to it the behavior, i.e. when the value is 0, = of Required Min Echo RX Interval are not in the right place. I think that d= efinition of desired transmit interval of BFD Echo should be in correspondi= ng RPC definition, not in configuration part of the model. Appreciate your comments. Regards, Greg --_000_D4D9967A25B679rrahmanciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <3108B8381634F149A54E51015CA3B7DF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Greg,

draft-zheng-mpls-ls-ping-yang-cfg defines transmit interval in RPC bec= ause all ping operations are done via RPC.  I do not consider BFD echo= to be “on demand” like LSP Ping (caveat: this is possibly due = to the BFD configuration/implementation I am most familiar with). 

Regards,
Reshad.

From: Greg Mirsky <gregimirsky@gmail.com>
Date: Monday, February 27, 2017 at = 1:07 AM
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Reshad <rrahman@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-yang@ietf.org" <draft-ietf-bfd-yang@ie= tf.org>
Subject: Re: Correcting BFD Echo mo= del

Hi Mahesh,
BFD Echo transmit interval is not part of RFC 5880, only Rx interval i= s. And Rx interval is sufficent to reflect whether local system is willing = to receive BFD Echo messages from the particular BFD peer. Introduced desir= ed-min-echo-tx-interval functionally overlaps with the standard-defined = required-min-echo-rx-interval. Hence my suggestion to remove desired-min= -echo-tx-interval from grouping bfd-grouping-echo-cfg-parms. But operators need a way to specify transmit = interval for on-demand OAM command like BFD Echo, IP ping or LSP ping. I co= uldn't find YANG model proposal for IP ping but in draft-zheng-mpls-lsp= -ping-yang-cfg transmit interval used in RPC, not as part of configuration.

Regards,
Greg


On Sun, Feb 26, 2017 at 8:33 PM, Mahesh Jethanan= dani <mjethanand= ani@gmail.com> wrote:

On Feb 26, 2017, at 4:39 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Reshad,
thank you for the question. Here's my reasoning:
  • only Required Min Echo RX Interval is present in RFC 5880 and it allows= to indicate not only the smallest interval between consecutive BFD Echo pa= ckets but whether system supports BFD Echo function at all;
  • since B= FD Echo may be transmitted only when the session state is Up, operator is f= ully equipped to learn the value of Required Min Echo RX Interval of its BF= D peer and to set Echo transmit interval accordingly;
  • requesting BF= D Echo, in my opinion, is no different from requesting IP ping or LSP ping.=
Hence my conclusion - transmit interval for BFD Echo is more suitable = in RPC then as configuration parameter.

I do not think that is reason enough for it to be a RPC.

A RPC is an operation one defines in the YANG model specifying both in= put and output parameters. There are no operations to be had here.

And the definition and desired behavior of desired-min-echo-tx-interva= l is not very different from required-min-echo-x-interval. It is as the def= inition says, a configuration parameter that can be set, with zero having a= special meaning in both cases.


Regards,
Greg

On Sun, Feb 26, 2017 at 2:52 PM, Reshad Rahman (= rrahman) <rrahman@cisco.com> wrote:
Hi Greg,

Can you please explain why you believe this should go in RPC?

Regards,
Reshad.

From: Greg Mirsky <gregimirsky@gmail.com>=
Date: Saturday, February 25, 2017 a= t 6:48 PM
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bf= d-yang@ietf.org" <draf= t-ietf-bfd-yang@ietf.org>
Subject: Correcting BFD Echo model<= br> Resent-From: <alias-bounces@ietf.org> Resent-To: <vero.zheng@huawei.com>, Resha= d <rrahman@cisco.= com>, <mjethanandani@gmail.com>, <sant= osh.pallagatti@gmail.com>, <gregimirsky@gmail.com>
Resent-Date: Saturday, February 25,= 2017 at 6:48 PM

Dear All,
I've reviewed the BFD YANG model and now I'm thinking that desired-min-echo-tx-interval and = attributing to it the behavior, i.e. when the value is 0, of Required Min Echo RX Interval are = not in the right place. I think that definition of desired transmit interval of BFD Echo should be in corresponding RPC de= finition, not in configuration part of the model.
Appreciate your comments.

Regards,
Greg



 --_000_D4D9967A25B679rrahmanciscocom_-- From nobody Mon Feb 27 07:31:05 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 362CD12A144; Mon, 27 Feb 2017 07:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 2M3wrTOLF-mq; Mon, 27 Feb 2017 07:31:02 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::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 55A4512A137; Mon, 27 Feb 2017 07:31:02 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id i1so13384435ota.3; Mon, 27 Feb 2017 07:31:02 -0800 (PST) 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=x9cfI5822ot/DKEYiu66myu4X/ePXpU0fssLuGB1nZQ=; b=oX63qA/GpJsPmfAalY1xe8y4KPlnFVrn0Sz72w3s/SSau9GpKjrQvmRI8fMAUog1Ab jdbsEyZeoIm8EWa2gdIBLjAOyu2fFpceZSKmtpKMNNbx+my8vKCD49f1btRz6yRxRt5e hmU71Fl/7z0R3ezSozRb5IrMpxOS4LzQZPZzP8vIVeRkcJY6hCXs7bDSZn4DRjC4Ot+j c45q6yErNjFihMOGO0vUPOGM/CS3NHsay7e72BXzftwpQaDUVAdJ7sIiTmEgGVZUQotY iHGD6DcVkvqT6LRgb6sZCxd2uctIm7u4J0gXec04v5qF3gBIELqxBrFzOcfQjefJS7UG giVw== 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=x9cfI5822ot/DKEYiu66myu4X/ePXpU0fssLuGB1nZQ=; b=S5J7g6WGWzphakt56hhxrIc2RECdoHNqQnRVfEADC85DmTrRl+b8AcjpDaDRkZufQo lLPtY3cnp0cGgYSdxvza85IEnlpYXwWOWuvf6t+LoEWdQoREygRR49Pgn/irDw06qgSM jjtdqlRma8pY+b1P4FCtJ9qs8r6c2yyFbJS4ZwhASDqD/10KB7D2aUh4J4MCEtdoHM6I xZJfdqYtr6igIpsiyMX9abHIktFkRz0bEHac7v95GLMElsSiMCIZQqQrQrMzPYPnIpDu jcUL2RNJqIii6+FhlTNDWqjluPpiImM0mtqSdEJIWMEMiSIVtXhiSLXBYZlSqpE+N9ea pQkg== X-Gm-Message-State: AMke39nGSJoHzEOiZNDSnt1TUsjurAD9+T/FgKD9QppVdKQUACW12D05SST6cU9ky+a39c+qe3p5a3bdwwMf6w== X-Received: by 10.157.1.229 with SMTP id e92mr7938568ote.40.1488209461596; Mon, 27 Feb 2017 07:31:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Mon, 27 Feb 2017 07:31:01 -0800 (PST) In-Reply-To: References: From: Greg Mirsky Date: Mon, 27 Feb 2017 07:31:01 -0800 Message-ID: Subject: Re: Correcting BFD Echo model To: "Reshad Rahman (rrahman)" Content-Type: multipart/alternative; boundary=94eb2c03c39a4f7325054984c40c Archived-At: Cc: "rtg-bfd@ietf. org" , "draft-ietf-bfd-yang@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 15:31:04 -0000 --94eb2c03c39a4f7325054984c40c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Reshad, thank you for providing the context to BFD Echo TX. Indeed, I'm familiar with implementations that use BFD Echo as Echo request/reply and thus Tx would be in RPC, not in configuration. I think that it would be good to discuss this in Chicago unless we hear comments from others on the list. Regards, Greg On Mon, Feb 27, 2017 at 5:56 AM, Reshad Rahman (rrahman) wrote: > Hi Greg, > > draft-zheng-mpls-ls-ping-yang-cfg defines transmit interval in RPC > because all ping operations are done via RPC. I do not consider BFD echo > to be =E2=80=9Con demand=E2=80=9D like LSP Ping (caveat: this is possibly= due to the BFD > configuration/implementation I am most familiar with). > > Regards, > Reshad. > > From: Greg Mirsky > Date: Monday, February 27, 2017 at 1:07 AM > To: Mahesh Jethanandani > Cc: Reshad , "rtg-bfd@ietf.org" , " > draft-ietf-bfd-yang@ietf.org" > Subject: Re: Correcting BFD Echo model > > Hi Mahesh, > BFD Echo transmit interval is not part of RFC 5880, only Rx interval is. > And Rx interval is sufficent to reflect whether local system is willing t= o > receive BFD Echo messages from the particular BFD peer. Introduced > desired-min-echo-tx-interval functionally overlaps with the > standard-defined required-min-echo-rx-interval. Hence my suggestion to > remove desired-min-echo-tx-interval from grouping > bfd-grouping-echo-cfg-parms. But operators need a way to specify transmit > interval for on-demand OAM command like BFD Echo, IP ping or LSP ping. I > couldn't find YANG model proposal for IP ping but in > draft-zheng-mpls-lsp-ping-yang-cfg transmit interval used in RPC, not as > part of configuration. > > Regards, > Greg > > > On Sun, Feb 26, 2017 at 8:33 PM, Mahesh Jethanandani < > mjethanandani@gmail.com> wrote: > >> >> On Feb 26, 2017, at 4:39 PM, Greg Mirsky wrote: >> >> Hi Reshad, >> thank you for the question. Here's my reasoning: >> >> - only Required Min Echo RX Interval is present in RFC 5880 and it >> allows to indicate not only the smallest interval between consecutive= BFD >> Echo packets but whether system supports BFD Echo function at all; >> - since BFD Echo may be transmitted only when the session state is >> Up, operator is fully equipped to learn the value of Required Min Ech= o RX >> Interval of its BFD peer and to set Echo transmit interval accordingl= y; >> - requesting BFD Echo, in my opinion, is no different from requesting >> IP ping or LSP ping. >> >> Hence my conclusion - transmit interval for BFD Echo is more suitable in >> RPC then as configuration parameter. >> >> >> I do not think that is reason enough for it to be a RPC. >> >> A RPC is an operation one defines in the YANG model specifying both inpu= t >> and output parameters. There are no operations to be had here. >> >> And the definition and desired behavior of desired-min-echo-tx-interval >> is not very different from required-min-echo-x-interval. It is as the >> definition says, a configuration parameter that can be set, with zero >> having a special meaning in both cases. >> >> >> Regards, >> Greg >> >> On Sun, Feb 26, 2017 at 2:52 PM, Reshad Rahman (rrahman) < >> rrahman@cisco.com> wrote: >> >>> Hi Greg, >>> >>> Can you please explain why you believe this should go in RPC? >>> >>> Regards, >>> Reshad. >>> >>> From: Greg Mirsky >>> Date: Saturday, February 25, 2017 at 6:48 PM >>> To: "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.or= g" >>> >>> Subject: Correcting BFD Echo model >>> Resent-From: >>> Resent-To: , Reshad , < >>> mjethanandani@gmail.com>, , < >>> gregimirsky@gmail.com> >>> Resent-Date: Saturday, February 25, 2017 at 6:48 PM >>> >>> Dear All, >>> I've reviewed the BFD YANG model and now I'm thinking that desired-min-= echo-tx-interval >>> and attributing to it the behavior, i.e. when the value is 0, of Requir= ed >>> Min Echo RX Interval are not in the right place. I think that definitio= n of >>> desired transmit interval of BFD Echo should be in corresponding RPC >>> definition, not in configuration part of the model. >>> Appreciate your comments. >>> >>> Regards, >>> Greg >>> >> >> >> > --94eb2c03c39a4f7325054984c40c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Reshad,
thank you for providing the context to BFD = Echo TX. Indeed, I'm familiar with implementations that use BFD Echo as= Echo request/reply and thus Tx would be in RPC, not in configuration. I th= ink that it would be good to discuss this in Chicago unless we hear comment= s from others on the list.

Regards,
Greg=

On Mo= n, Feb 27, 2017 at 5:56 AM, Reshad Rahman (rrahman) <<= a href=3D"mailto:rrahman@cisco.com" target=3D"_blank">rrahman@cisco.com= > wrote:
Hi Greg,

draft-zheng-mpls-ls-ping-yang-cfg defines transmit interval in RP= C because all ping operations are done via RPC.=C2=A0 I do not consider BFD= echo to be =E2=80=9Con demand=E2=80=9D like LSP Ping (caveat: this is poss= ibly due to the BFD configuration/implementation I am most familiar with).=C2=A0

Regards,
Reshad.

From: Greg Mirsky <gregimirsky@gmail.com>=
Date: Monday, February 27, 2017 at = 1:07 AM
To: Mahesh Jethanandani <mjethanandani@gmail.c= om>
Cc: Reshad <rrahman@cisco.com>, "rtg-bfd@ietf.org" &= lt;rtg-bfd@ietf.org>, "draft-ietf-bfd-yang@ietf.org" <draf= t-ietf-bfd-yang@ietf.org>
Subject: Re: Correcting BFD Echo mo= del

Hi Mahesh,
BFD Echo transmit interval is not part of RFC 5880, only Rx interval i= s. And Rx interval is sufficent to reflect whether local system is willing = to receive BFD Echo messages from the particular BFD peer. Introduced desir= ed-min-echo-tx-interval functionally overlaps with the standard-defined=C2=A0= required-min-echo-rx-interval.=C2=A0Hence my suggestion to remove=C2=A0desired-min= -echo-tx-interval from=C2=A0grouping bfd-grouping-echo-cfg-parms. But operators need a way to specify transmit = interval for on-demand OAM command like BFD Echo, IP ping or LSP ping. I co= uldn't find YANG model proposal for IP ping but in=C2=A0<= font color=3D"#000000" face=3D"arial,helvetica,sans-serif">draft-zheng-mpls= -lsp-ping-yang-cfg transmit interval used in RPC, not as part of configuration.

Regards,
Greg


On Sun, Feb 26, 2017 at 8:33 PM, Mahesh Jethanan= dani <mjethanand= ani@gmail.com> wrote:

On Feb 26, 2017, at 4:39 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Reshad,
thank you for the question. Here's my reasoning:
  • only Required Min Echo RX Interval is present in RFC 5880 and it allows= to indicate not only the smallest interval between consecutive BFD Echo pa= ckets but whether system supports BFD Echo function at all;
  • since B= FD Echo may be transmitted only when the session state is Up, operator is f= ully equipped to learn the value of Required Min Echo RX Interval of its BF= D peer and to set Echo transmit interval accordingly;
  • requesting BF= D Echo, in my opinion, is no different from requesting IP ping or LSP ping.=
Hence my conclusion - transmit interval for BFD Echo is more suitable = in RPC then as configuration parameter.

I do not think that is reason enough for it to be a RPC.

A RPC is an operation one defines in the YANG model specifying both in= put and output parameters. There are no operations to be had here.

And the definition and desired behavior of desired-min-echo-tx-interva= l is not very different from required-min-echo-x-interval. It is as the def= inition says, a configuration parameter that can be set, with zero having a= special meaning in both cases.


Regards,
Greg

On Sun, Feb 26, 2017 at 2:52 PM, Reshad Rahman (= rrahman) <rrahman@cisco.com> wrote:
Hi Greg,

Can you please explain why you believe this should go in RPC?

Regards,
Reshad.

From: Greg Mirsky <gregimirsky@gmail.com>=
Date: Saturday, February 25, 2017 a= t 6:48 PM
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bf= d-yang@ietf.org" <draf= t-ietf-bfd-yang@ietf.org>
Subject: Correcting BFD Echo model<= br> Resent-From: <alias-bounces@ietf.org> Resent-To: <vero.zheng@huawei.com>, Resha= d <rrahman@cisco.= com>, <mjethanandani@gmail.com>, <sant= osh.pallagatti@gmail.com>, <gregimirsky@gmail.com>
Resent-Date: Saturday, February 25,= 2017 at 6:48 PM

Dear All,
I've reviewed the BFD YANG model and now I'm thinking that desired-min-echo-tx-interval and = attributing to it the behavior, i.e. when the value is 0, of=C2=A0Required Min Echo RX Interval are = not in the right place. I think that definition of desired transmit interval of BFD Echo should be in corresponding RPC de= finition, not in configuration part of the model.
Appreciate your comments.

Regards,
Greg




--94eb2c03c39a4f7325054984c40c--