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

Glen Kent <glen.kent@gmail.com> Wed, 13 April 2016 13:08 UTC

Return-Path: <glen.kent@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6366612DE26; Wed, 13 Apr 2016 06:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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] 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 dWeUoA7UWLQh; Wed, 13 Apr 2016 06:08:16 -0700 (PDT)
Received: from mail-ob0-x242.google.com (mail-ob0-x242.google.com [IPv6:2607:f8b0:4003:c01::242]) (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 7DB7512DE0A; Wed, 13 Apr 2016 06:08:16 -0700 (PDT)
Received: by mail-ob0-x242.google.com with SMTP id rf6so3046761obc.3; Wed, 13 Apr 2016 06:08:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=jQGfI6CoA1NDL5G+b28rNKIqgv0dUr8+YwTWcSe7Myc=; b=EUbqB1yYDM+ceovJCiehlZg9ZLwHTFT5dpfiw8QBquF/WdhyeJn5pPecL7nvi5iNhO J8+izVPOHpUGzPcj14xjSZ6TWFBQYNjvwx60NyczoIgRGyiwfkYZ6VD4uPN7WTHlbKdc ybwUdGjW/vSCwvVNg3GPbQBHweWFz+uvO1iBkT+Cglku/E8cXo2jsFWdqqTf7cviOY8F wsXm8WesnEyI7UpCXvHY5bzY32jMlf74I6IcoGz7hf+rzy1t4jUd8WIQfGX1dxWYMKG3 3llEOfx+UO2wOJkAFbhCS6ufVcnWyHnUu54tZvCCJbjEsowiyEPWXAF1KnqQYvqwl8P2 ubQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jQGfI6CoA1NDL5G+b28rNKIqgv0dUr8+YwTWcSe7Myc=; b=JMNGV+Yfg7iOTHj2oQMnipT2qmtN7AcY6wJGpbG4jz+bE74iTkpTFMy+LHPQp2NzcZ o/lg7VzryVQffKj8C1M+QyiBSiPFhme77j/+oQTa1gicsIzqRwZ1ICpxddyH18VCHnZL u8SOIYu6xdmtRNkRj2z3by2umjdRHbgwokH9NBd4SuRPvsRl4cNYeOAhU8H6iPEVWfTB 8StgaNj8bIob+gproEWRaJsGPqYTqDpsJiLoBiKQQx5STvX2jcLwjz+T+gBgY08Cug8/ SVwLmzmH2XfnraHfiVAMYAi+IMGSoi6DzpS9h7uK5mGFzkiwHCOg9W5FkebgmyEUUI+r 1d2w==
X-Gm-Message-State: AOPr4FWJ1rAmZTBDZqy848IR5IA2UPmLOMI/bhblIt8Kk1lJ+38SgJ/yEwNSoDva/1lS79Ph8wGNLsJw6TkxJw==
MIME-Version: 1.0
X-Received: by 10.182.105.65 with SMTP id gk1mr4309394obb.37.1460552895791; Wed, 13 Apr 2016 06:08:15 -0700 (PDT)
Received: by 10.202.62.133 with HTTP; Wed, 13 Apr 2016 06:08:15 -0700 (PDT)
In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A43F14@eusaamb103.ericsson.se>
References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F040F@SZXEMA510-MBX.china.huawei.com> <CAG1kdojp7Km16YDiwjvPKwRNjbvBWOkqpccRsEDCn8Q8BuV0Qg@mail.gmail.com> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <CAG1kdoibVBWsga3K88MGbZAFSbD_2q0efea_8aEKd_hN+CV53w@mail.gmail.com> <7347100B5761DC41A166AC17F22DF11221A40773@eusaamb103.ericsson.se> <D32D53C8.13B077%rrahman@cisco.com> <CA+RyBmW3nDxMphGaJ2eThZ3fs4zvD5D-9kiJBVSTzPoApkWqgA@mail.gmail.com> <20160411172332.GA22064@pfrc.org> <7347100B5761DC41A166AC17F22DF11221A43F14@eusaamb103.ericsson.se>
Date: Wed, 13 Apr 2016 18:38:15 +0530
Message-ID: <CAPLq3UPnsT4NJrj2juMZHhStOx6yC2oKr44XWSrAEsVUZ-o5_g@mail.gmail.com>
From: Glen Kent <glen.kent@gmail.com>
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
Content-Type: multipart/alternative; boundary=e89a8ff1cf9c87898a05305d78a3
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/wwIuv8TUwePiOtbYHSqCXesW9Zs>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "Reshad Rahman \(rrahman\)" <rrahman@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" <rtg-bfd-chairs@ietf.org>
Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2016 13:08:19 -0000

Gregory,

You are using a special GAL label for BFD packets. This label exists only
for the BFD packets.

How can you then claim connectivity for other traffic which will not use
this label?

Glen

On Wed, Apr 13, 2016 at 4:18 AM, Gregory Mirsky <gregory.mirsky@ericsson.com
> wrote:

> 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
> <https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-mpls-00>.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> -----Original Message-----
> From: Jeffrey Haas [mailto:jhaas@pfrc.org]
> Sent: Monday, April 11, 2016 10:24 AM
> To: Greg Mirsky
> Cc: Reshad Rahman (rrahman);
> draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org;
> mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg-bfd@ietf.org;
> rtg-bfd-chairs@ietf.org
> Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces
>
>
>
> Greg,
>
>
>
> 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)
>