Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces

Gregory Mirsky <> Tue, 12 April 2016 22:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E076012DBD7; Tue, 12 Apr 2016 15:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6ren1AXIExCF; Tue, 12 Apr 2016 15:48:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77E8D12DDE5; Tue, 12 Apr 2016 15:48:43 -0700 (PDT)
X-AuditID: c618062d-f79886d000002334-82-570d74c7d730
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 50.CE.09012.7C47D075; Wed, 13 Apr 2016 00:20:55 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Tue, 12 Apr 2016 18:48:42 -0400
From: Gregory Mirsky <>
To: Jeffrey Haas <>, Greg Mirsky <>
Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces
Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZABt/KgAADGd7oAANpwaAAAYagaD//+aOgIAAJa0AgASgtgD//lcisA==
Date: Tue, 12 Apr 2016 22:48:40 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A43F14eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUyuXRPrO7xEt5wg+kzjSw+PbzEbHFg00FG i2/TnrJa7D/4ltVi3eVTbBa3lq5ktbi2opXdYsnte+wWn/9sY3Tg9JjyeyOrx85Zd9k9liz5 yeRxuXcrq8eXy5/ZAlijuGxSUnMyy1KL9O0SuDK2NixiKzhkWbH87wSmBsazhl2MnBwSAiYS L59OZoWwxSQu3FvP1sXIxSEkcJRRYn9DAwuEs5xR4sPbk2BVbAJGEi829rCD2CICbhK3puxl BiliFmhiltg3/xgLSEJYwFHi+/xrzBBFThIfrixmhbCzJA4+XQVmswioSlyfthqsnlfAV+L+ /EVQ2w6wSNy8vYoJJMEpoCcx5f1+NhCbEei+76fWgMWZBcQlbj2ZzwRxt4DEkj3nmSFsUYmX j/9B/aMkMWnpOVaI+nyJh29us0EsE5Q4OfMJywRG0VlIRs1CUjYLSRlEXEdiwe5PbBC2tsSy ha+ZYewzBx4zIYsvYGRfxchRWlyQk5tuZLCJERi/xyTYdHcw3p/ueYhRgINRiYd3QRhPuBBr YllxZe4hRgkOZiUR3pwK3nAh3pTEyqrUovz4otKc1OJDjNIcLErivI3B/8KEBNITS1KzU1ML UotgskwcnFINjHrPb4WnHEv+tMvKfnvWqwVPpI4uWBk4tdfo2D/Jqb+/fWg5uCZayXGP6uND O20rFl59HiXL/sbOM81MyYdt6sqHNx62nrpyyUnEU6cgTy/1cPTRdx9Td+1beaVwbrOTgcL0 Vo9ny/Xe8mmYJr0/euhd6QHF6yqqR2u8UjTstpdfDI4Ifr+I/ZYSS3FGoqEWc1FxIgADdEGL 2wIAAA==
Archived-At: <>
Cc: "" <>, "" <>, "" <>, "Reshad Rahman (rrahman)" <>, "" <>, "" <>
Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Apr 2016 22:48:46 -0000

Hi Jeff,

thank you for adding more details to the discussions before RFC 7130. We have submitted another draft that proposes to use MPLS encapsulation of BFD control packets over MC-LAG interfaces. Would greatly appreciate reviews, questions and comments on draft-tanmir-rtgwg-bfd-mc-lag-mpls<>.



-----Original Message-----
From: Jeffrey Haas []
Sent: Monday, April 11, 2016 10:24 AM
To: Greg Mirsky
Cc: Reshad Rahman (rrahman);;;; Alia Atlas (;;
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces


This is more of a general comment on discussions from the development from RFC 7130 than any specific comment on your draft.

On Fri, Apr 08, 2016 at 11:43:18AM -0700, Greg Mirsky wrote:

> yes, link local multicast may be used in MC-LAG scenario. The draft

> states that it MAY be used while the broadcast has SHOULD normative.

> But we are all open to the discussion.

During our discussions across multiple vendors, including some hardware vendors, it was determined that attempts to exercise the layer 3 mechanisms would vary significantly across implementations depending on how packets were encapsulated.  Multicast in particular provided some problematic issues for us beyond the initial bootstrapping phase of LAG for BFD wherein we might not have ARP completed.

My recommendation is to proceed with your drafts with similar caution.  Try to stay as true to pure IP as possible to best insure the L3 data paths are exercised across implementations from various vendors.

-- Jeff (speaking as an individual contributor)