Re: BFD chair response to presentation on draft-mirmin-bfd-extended

"Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com> Fri, 22 November 2019 03:28 UTC

Return-Path: <rgandhi@cisco.com>
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 DD1CC12084A; Thu, 21 Nov 2019 19:28:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 header.b=a99GGise; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LuG5KNPy
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 XPh4GUSho71z; Thu, 21 Nov 2019 19:28:43 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A8A1120836; Thu, 21 Nov 2019 19:28:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7094; q=dns/txt; s=iport; t=1574393323; x=1575602923; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Y55crl5vaQgyT0GrO+C/t0wvtHi4DIFCnk7MgyjvDlo=; b=a99GGise6XwDsJxKkJJww4jPVjZKLWBuqbRlku+Vk5VmAO2jJ28uHulT kG5jiX8GTzLJvVGoVdpPv9wk0xoJc+UUSkLk5oPX49XpkaTZmEp7rNYY9 8Xm7HufyoWeuz6Hb99V71r4HiJtf9PF82p4g57rv9VHGeF2h5FvteMbdu A=;
IronPort-PHdr: =?us-ascii?q?9a23=3A0JLRHB/3ner5Af9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdSKAEv3LP/CZC0hF8MEX1hgrDm2?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxAAAKVddd/5pdJa1kGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF+gUtQBYFEIAQLKoQqg0YDim2COpgmglIDVAk?= =?us-ascii?q?BAQEMAQEtAgEBhEACF4IRJDgTAgMNAQEEAQEBAgEFBG2FNwyFUgIBAxIREQw?= =?us-ascii?q?BATcBDwIBCA4MAhkNAgICMBUQAgQBDQUigwCCRwMuAQKiegKBOIhgdYEygn4?= =?us-ascii?q?BAQWCSYI/GIIXCYEOKIwWGoFAP4ERJwwTgkw+hEUXgnkygiyNB4MPnh4Kgiu?= =?us-ascii?q?VUBuCPodqj3COSJoMAgQCBAUCDgEBBYFpIoFYcBVlAYJBUBEUhkgMF4NQilN?= =?us-ascii?q?0gSiQHQEB?=
X-IronPort-AV: E=Sophos;i="5.69,228,1571702400"; d="scan'208";a="375711072"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Nov 2019 03:28:42 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id xAM3Sgsx011617 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Nov 2019 03:28:42 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 21 Nov 2019 21:28:41 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 21 Nov 2019 22:28:40 -0500
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 21 Nov 2019 21:28:40 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nZj97V4i2Czita78o+9aPDRQC3fMkBV1pm7DTptQN3fX1Y61NBgNCcFPhM4rhUFsAqR2VdPaG3QWd+V5S7dofFCwS9R1QnGKOFb3OX6qudcGghqJ2NBE4kstGFZTvXMAOVwGQUZYuBup7+4bMtqkD0tRimoxidbljS4Jdl+xv98ka/2gmpu21VuLw6uYsuVlN9OcgvDEzfAOI+16sb7U8E7MNeICJ1XHYz3ap4xYFevwl3G9ra2HLMXvUAPGvkvyOTjlruFmaOUG7dKubv35t2k5hdIGIOMIympTtx3gqHLzTSLfJ9zXF1ZeYO2x0f1WNN/LwTlYAXMCa9eH3qhm+g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y55crl5vaQgyT0GrO+C/t0wvtHi4DIFCnk7MgyjvDlo=; b=g80ASk5ssyRk/oPYo3N0PvCOhO8B3t6cxGaiNs7EknWqxLfRKeebhS51K2kPf3Lew3OvxtI0kM8DwEwXUsh8yn+0H8PDBiQDs1wewlq8Yxs6KsiheoyxcpElC1inNY357Z7t1fek9dqMnuNOl8jNFbQYClzFYLxJlTkPPEBV6JpVO1cRcunB5p7zF6RfqzCxJCawLJLHTcFQgOIUOY1atBewhvTOPG3AA3qK0DnO1k7wpZoDtPmMtPsKNs+FkGaG7iEJ5+jxLgfFxa9UONvB9D0dxxZrxlt2+MQRDF51AbyfTTiSZJxRV5Djj3xVUyDpmTVfoo5jL6fie9vm9fBBHA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y55crl5vaQgyT0GrO+C/t0wvtHi4DIFCnk7MgyjvDlo=; b=LuG5KNPyN4FtifXYX3pYmNsnR1WblKY9er0XyE8I5pqhj9ksJPFNZyuFRGS9jWwmyaftuiDtylTPtvU3zVY6OzR+mJiql3vwxx6U7/nZ2sFIK7aJ9dBAcGcNWvIVWAdN0Po8X+xbYCiXmQaKSwdRHrThKsLR5gBbZyLNHFL4exk=
Received: from BYAPR11MB3061.namprd11.prod.outlook.com (20.177.224.85) by BYAPR11MB2757.namprd11.prod.outlook.com (52.135.229.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.19; Fri, 22 Nov 2019 03:28:39 +0000
Received: from BYAPR11MB3061.namprd11.prod.outlook.com ([fe80::c9f1:5bf6:d43f:ddc1]) by BYAPR11MB3061.namprd11.prod.outlook.com ([fe80::c9f1:5bf6:d43f:ddc1%5]) with mapi id 15.20.2451.032; Fri, 22 Nov 2019 03:28:39 +0000
From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
CC: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: BFD chair response to presentation on draft-mirmin-bfd-extended
Thread-Topic: BFD chair response to presentation on draft-mirmin-bfd-extended
Thread-Index: AQHVoN9rOKFV6n8KJUCeo0/1v97X/6eXDjkA
Date: Fri, 22 Nov 2019 03:28:39 +0000
Message-ID: <C1A1DF70-ABBC-4A9E-9642-E0A64F5CFC61@cisco.com>
References: <20191122025255.GW21134@pfrc.org>
In-Reply-To: <20191122025255.GW21134@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1e.0.191013
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rgandhi@cisco.com;
x-originating-ip: [2001:420:c0dc:1002::1a5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2c5ae4f9-0a78-4046-48c4-08d76efc1127
x-ms-traffictypediagnostic: BYAPR11MB2757:
x-microsoft-antispam-prvs: <BYAPR11MB27570B6D80542E107F34E83ABF490@BYAPR11MB2757.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 02296943FF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(136003)(39860400002)(366004)(376002)(189003)(199004)(11346002)(446003)(76176011)(36756003)(6246003)(2616005)(186003)(102836004)(4326008)(14454004)(33656002)(25786009)(46003)(2906002)(6116002)(6506007)(478600001)(99286004)(4001150100001)(2501003)(6436002)(64756008)(6486002)(7736002)(76116006)(66476007)(66946007)(229853002)(66556008)(305945005)(14444005)(256004)(66446008)(91956017)(8676002)(81156014)(5660300002)(81166006)(58126008)(8936002)(71190400001)(71200400001)(110136005)(316002)(6512007)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2757; H:BYAPR11MB3061.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: g3zE2zGHi1pRVRuq4t9qUOFujGw3hXAmo2mAf7SNOBxU6nm9SyhoCl9zh3hISzBEzFpYKv6Cl5H+TQKYVnNjfdLjEk9IHq/ha+f+d0p9yEBNRL2rpw3kRuy4oVu/+hpkb8hbU7p45FCNVYRTN5wnSYjrpdSHYmlUEN31x2yENkBp8UZf+3gFJ7jfJmtr07kaKZ+hN6WHWnXy2IQqf6LyoMcTJePbgSw4Fr4PB5AavgxdjAxx3FMxdZN/+Wv8jGVkEFbyMZYBYfCP/LXDaT9NeobcgxRFT8hr/p27Ofm49fHtGKou2GWqOWLjWwhwRkcxqDHlpJCf2lv78whLIryExQoZyc4XqBsna2qSKBL/T42JcSM1j5IT9lWD9ZJERETG1BkVBWz+yLTtNQcX0FxvnqHC24dDWHiPjFR5XSNGY4aXlDIhJNgDOBN0yGtxrq4L
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <054A19B6C1D7F04F98EBFCD3B79B8A15@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2c5ae4f9-0a78-4046-48c4-08d76efc1127
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2019 03:28:39.2559 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: AZgLtP0OyOfDwiQHGVoLq0/LrwXiLk21DZp5UyjSobDpSrLgr8q+9CpGQvWfGWTfMTbJRZe5gvc7FvVQoM1PSg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2757
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/hdei8nZpQFdAb7j3j_1NfKtPIek>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Nov 2019 03:28:46 -0000

Hi WGs,
This was greatly discussed in the BFD WG meeting in Montreal, and that there was NO support to complicate the BFD for IPPM use-cases. There are number of existing protocols (OWAMP, TWAMP, RFC6374, STAMP, IOAM, etc.) designed, implemented and deployed for IPPM use-cases already. I am surprised that the text is still present in the latest version (02) of the draft (Section 3.4) and presented in another WG.

Thanks,
Rakesh


On 2019-11-22, 10:49 AM, "Rtg-bfd on behalf of Jeffrey Haas" <rtg-bfd-bounces@ietf.org on behalf of jhaas@pfrc.org> wrote:

    In the interest of permitting the presentations to move smoothly at this
    Friday's rtgwg session, I withheld my comments from microphone.  However,
    please consider these comments for the record for IETF-106.
    
    Firstly, I'm surprised the chairs had a BFD presentation at rtgwg.  rtgwg is
    indeed intended to be a general purpose dispatch group for work without a
    home, but that's not the case for BFD.
    
    Secondly, Reshad and I intentionally did not schedule work on BFD extension
    work, including Greg's presentation, for this IETF.  This is because there
    is open charter discussions we're starting with the IESG on this space.
    
    -----
    
    Specific comments on BFD extension work and the charter discussions:
    
    During prior IETFs, and culminating at IETF-105, we've seen regular work to
    try to stuff BFD with additional features of various forms.  The litmus test
    generally used for BFD's core use case over the years has been "what do you
    want to hear every 3.3ms?"  To that end, things that enhance BFD's core
    continuity verification uses cases have ended up in the protocol.
    
    Somewhat similar to other popular protocols such as DNS and BGP, BFD has
    nice properties that make it an appealing place to try to extend.  In
    particular, it's a continuing conversation between two systems.
    
    During IETF-105, the IPPM group members attending explicitly noted that they
    did not want to see their mechanisms present in BFD and did not consider it
    a good fit.
    
    As part of that discussion, the chairs noted that one option potentially
    open is that we permit the "BFDv2" option we have discussed at IETF-105 and
    previous to permit an option where we do not use the core BFDv1 session used
    for continuity for these extensions, and use a different protocol version
    and port set to enable the other use cases.
    
    Thus, the discussion with the IESG is whether BFD hands over the "gift" of a
    general and mature mechanism for a conversation between two systems that may
    be generally extended to carry "interesting" information.
    
    This addresses Tony Li's point about "please don't make BFD difficult to
    implement in hardware".
    
    -----
    
    Specific comments on draft-mirmin-bfd-extended:
    
    The somewhat peculiar extension mechanism shown in Greg's draft was
    originally seeded by work I started in BFD for draft-ietf-bfd-large-packets.
    In fairness to history, this was similar to work that was done in OSPF years
    back for how the authentication mechanism was spliced onto the protocol.
    The one sentence description of that use case is "make the packet padded to
    test MTU".  It's a hack, but one that does a reasonable job of its use case.
    
    However, with regard to leveraging this hack for a general purpose extension
    mechanism, I don't find it a good fit.  BFDv1 does not expect to find
    information regarding the packet or state machine outside of the main PDU.
    It is likely a new version number will need to be used to establish future
    semantics.  (Per prior discussion in the working group.)
    
    The capabilities mechanism will likely require either integration into some
    form of an updated state machine for the new version header, or a different
    form.  IMO, I find it likely that a "capability advertisement" mechanism
    would be necessary rather than negotiation to avoid a wholesale replacement
    of the BFD state machinery.  And if we replace that much of the machinery,
    let's just stop calling this BFD at all and move on.
    
    With regard to IPPM style content for the draft, I refer you to the IPPM
    members comments above from IETF-105.
    
    With regard to authentication, there are two possibilities here:
    - Faster authentication of BFD style packets is covered by work completing
      BFD WGLC draft-ietf-bfd-optimitizing-authentication.  I'd encourage other
      working groups in need of a faster per-packet authentication mechanism to
      consider whether it's an appropriate fit.
    - In the case that such a future BFD, or mechanism built on similar
      machinery, want a way to autenticate the payload different from the
      headers, there will likely need to be discussion about not only what
      envelope is used, but also strength vs. periodicity.  (And if you don't need
      this stuff periodically, why use something like BFD?)
    
    -- Jeff