IETF Logo Mail Archive

Re: [Idr] Why L2 liveness needed for BGP-SPF

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Sun, 22 July 2018 03:06 UTC

Return-Path: <jheitz@cisco.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 68955130DFC; Sat, 21 Jul 2018 20:06:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 86xPcMF7veGP; Sat, 21 Jul 2018 20:06:57 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B3A130DDA; Sat, 21 Jul 2018 20:06:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11760; q=dns/txt; s=iport; t=1532228817; x=1533438417; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=EkJqbSoPru9BxXNsnPQe78lMkyOmmXRlKgC9rTV7k5Q=; b=CZn2XYdiP4NJzqvX8Y+byX9Y1T0nAqz/7HyXHT3n2GpoklomdlClXPXN PGw2HB6Vc5K1ctODx0pUILrVCxHZwIXvjXYXBDVS/BySQ34gUs+20NhUa /qjdbAhEay82NOs91ZbLFyYpRW3ndpyz2xbIN1/SiId7uaC8o7osGcpvb o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C+AgDy81Nb/4UNJK1cGQEBAQEBAQEBAQEBAQcBAQEBAYJXdmN/KAqDdJQ2ggyDK40ChRCBegslhEcCF4J1ITYWAQIBAQIBAQJtHAyFNgEBAQQjClwCAQgRBAEBKwICAjAdCAIEARIIgxmBG2QPrjKBLopJBYkCgVc/gRGCE1AugxsEGIFdgmqCVQKReId0CQKGD4kXjXqKQoc4AhEUgSQkCSiBUnAVgySCJReDRYpSbwGNIoEbAQE
X-IronPort-AV: E=Sophos;i="5.51,387,1526342400"; d="scan'208,217";a="146505951"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jul 2018 03:06:56 +0000
Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w6M36uX4027261 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 22 Jul 2018 03:06:56 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 21 Jul 2018 22:06:55 -0500
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Sat, 21 Jul 2018 22:06:55 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: "徐小虎(义先)" <xiaohu.xxh@alibaba-inc.com>, "Lsvr@ietf.org" <Lsvr@ietf.org>, "idr@ietf.org" <idr@ietf.org>, Randy Bush <randy@psg.com>
Thread-Topic: [Idr] Why L2 liveness needed for BGP-SPF
Thread-Index: AQHUIWdrxEj5j5SS20yzOldIi2VD46SajO+w
Date: Sun, 22 Jul 2018 03:06:55 +0000
Message-ID: <bd5ff63067a8446ca8e2267c891933ad@XCH-ALN-014.cisco.com>
References: <fb35cb79-881d-4ca2-8a0b-738886d28b8f.xiaohu.xxh@alibaba-inc.com>
In-Reply-To: <fb35cb79-881d-4ca2-8a0b-738886d28b8f.xiaohu.xxh@alibaba-inc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.253.228]
Content-Type: multipart/alternative; boundary="_000_bd5ff63067a8446ca8e2267c891933adXCHALN014ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.25, xch-rcd-015.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/0jU2DuuymSHykzFqW7GmPykToTc>
Subject: Re: [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 03:07:00 -0000

What do you really mean by L2 liveness?
L2 can be Ethernet, Token Ring, ATM, Frame Relay, PPP, SLIP, MTP2 and others that may be invented in the future.
Each one needs its own liveness protocol. You will need to do it separately in each L2 protocol.
Do you mean the answer to the question:
Can the nodes at each end of the link forward IP packets to each other and forward those packets to the correct interface where they need to go?

Regards,
Jakob.

From: Idr <idr-bounces@ietf.org> On Behalf Of ???(??)
Sent: Saturday, July 21, 2018 7:55 PM
To: Lsvr@ietf.org; idr@ietf.org
Subject: [Idr] Why L2 liveness needed for BGP-SPF

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