IETF Logo Mail Archive

[Idr] Why L2 liveness needed for BGP-SPF

"=?UTF-8?B?5b6Q5bCP6JmOKOS5ieWFiCk=?=" <xiaohu.xxh@alibaba-inc.com> Sun, 22 July 2018 02:54 UTC

Return-Path: <xiaohu.xxh@alibaba-inc.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C9D130E2C; Sat, 21 Jul 2018 19:54:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.019
X-Spam-Level:
X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.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 XprwWc99enWq; Sat, 21 Jul 2018 19:54:53 -0700 (PDT)
Received: from out0-142.mail.aliyun.com (out0-142.mail.aliyun.com [140.205.0.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC87130DE2; Sat, 21 Jul 2018 19:54:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1532228084; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=052eXJAL+KcXZCKRZCF7YYUAz46aiByPxCDbt6hZA48=; b=huUCwMNfhpJDFB+0g/DOXXXluHLtU0togomHLE9TZyMO5XRa5cv/0wrLGXw6yUIdQnA+i/Wl8W9J/iACX+wgU80zMLxgVx8snYrATEVTT/fOpz0EPG/6rr+3wP3szNHQOpjFIWh0BuXZcyl1FBXbq4HmGB1RYXEEVpyVzrCBvoQ=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R181e4; CH=green; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03312; MF=xiaohu.xxh@alibaba-inc.com; NM=1; PH=DW; RN=2; SR=0; TI=W4_5318390_v5ForWebDing_0A9326EC_1532224562346_o7001c8u;
Received: from WS-web (xiaohu.xxh@alibaba-inc.com[W4_5318390_v5ForWebDing_0A9326EC_1532224562346_o7001c8u]) by e02c03279.eu6 at Sun, 22 Jul 2018 10:54:43 +0800
Date: Sun, 22 Jul 2018 10:54:43 +0800
From: "徐小虎(义先)" <xiaohu.xxh@alibaba-inc.com>
To: "Lsvr@ietf.org" <Lsvr@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Reply-To: "徐小虎(义先)" <xiaohu.xxh@alibaba-inc.com>
Message-ID: <fb35cb79-881d-4ca2-8a0b-738886d28b8f.xiaohu.xxh@alibaba-inc.com>
X-Mailer: [Alimail-Mailagent revision 7][W4_5318390][v5ForWebDing][Safari]
MIME-Version: 1.0
x-aliyun-mail-creator: W4_5318390_v5ForWebDing_QvNTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTJfNikgQXBwbGVXZWJLaXQvNjA0LjUuNiAoS0hUTUwsIGxpa2UgR2Vja28pIFZlcnNpb24vMTEuMC4zIFNhZmFyaS82MDQuNS42La
Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_96528_4f873940_5b53f1f3_1800d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/h5rTGw77JOd1qqWjZmlqtLNqRFo>
Subject: [Idr] Why L2 liveness needed for BGP-SPF
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Jul 2018 02:54:57 -0000

Hi all,

I just watched the IDR meeting record at https://play.conf.meetecho.com/Playout/?session=IETF102-IDR-20180719-1810

I'm in favor of the AD's recommendation of finding a unified proposal rather than two different proposals doing almost the same thing. BGP-SPF is intended to be a link-state protocol built on the BGP base protocol and L3 liveness works fine for link-state protocols (eg., OSPF). Hence I'm curious about the reason why L2 liveness is a must for BGP-SPF.  In other word, what's special for BGP-SPF as a link-state protocol that makes it have such "nice constrained problem"?

By the way, provided that BGP-SPF did need L2 liveness which in turn is expected by some BGP-SPF guys to be generic and therefore be applicable to other scenarios beyond BGP, wouldn't IEEE be a better place to pursue such generic L2 liveness mechanism?

Best regards,
Xiaohu

v2.23.0 | Report a Bug | By Email