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

Greg Mirsky <gregimirsky@gmail.com> Fri, 08 April 2016 18:43 UTC

Return-Path: <gregimirsky@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 B7C3612D53A; Fri, 8 Apr 2016 11:43:22 -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 stlYrNalqw6h; Fri, 8 Apr 2016 11:43:20 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 D497C12D510; Fri, 8 Apr 2016 11:43:19 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id t10so144987462ywa.0; Fri, 08 Apr 2016 11:43:19 -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=BuUKHdXn2DaCPugCE0YhFDsx1ATdIuhVIP/f39XEcgk=; b=JJGIyoJmaTvuW9lVhEbNrC+loMdeYxwsqr31FFyXnyar5oXMEK33ow9qctoHbr2Cd/ STyN11chwfU5LtCsapFOoojjqeoGZN5E/pTcemrvd1XO52duA4Q49+TA1zMPKxQ9PtWZ l1nkKmdrzIYLG+OxEXl7ZzwrllzMJx/T9tnSG76IqyXaQzHCN2gQyrh0goJO1L3jt8zI HLiq2VllX8SNpgA02//XPtdnPFS7/NPagh4IOQbiPsc1YP6I9mNkE4dflW0vAI3/G02q F1O+YdVtFAHREVYt7fR/OqEHd8ZP+3R0i8JotbC4yLvRhAN8RSrYtOkLV+xc6729BxMe kV2Q==
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=BuUKHdXn2DaCPugCE0YhFDsx1ATdIuhVIP/f39XEcgk=; b=DpLyRbQf6PE4eDGV4sY2VAZHSCX7VGLKe3Nk6n1DWXiF/8VbMwUd/5bnkHY/kwJbRG 4ceJI3BOH0mibPmAdlNfZ2/Z1aomiakVqm24IXcGXOR+U/GHuLqYW4NjSRmnGxYZzH2G cn3KDo8AjdEXqC5NWy+favhWTbcaLdxGLQevV2zp88xI6uzqcpjxfJZwr8OH5FAy7ncT XeJQcBwOLVpbu+y3flLsOFlxteIHPeNeErpPHBAVTXf9aszmQ6cJf2dIUASTqlpS6lDm Sq6j+v2aZbRPr3ufHZ8qSvnjLAI1GVP1joFx2gDi1D6vCmP2EhmGulOFINhL2bfzr1tM xjWg==
X-Gm-Message-State: AD7BkJLpHe0KHKeErdQP2f5XmUj8Kdg4EpqEbP+BmATwzbn1zYH13COY4lRtJ1oet4Id+i+BUDO/uxFdv13RBA==
MIME-Version: 1.0
X-Received: by 10.129.159.194 with SMTP id w185mr5711357ywg.297.1460140998984; Fri, 08 Apr 2016 11:43:18 -0700 (PDT)
Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 11:43:18 -0700 (PDT)
Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 11:43:18 -0700 (PDT)
In-Reply-To: <D32D53C8.13B077%rrahman@cisco.com>
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>
Date: Fri, 08 Apr 2016 11:43:18 -0700
Message-ID: <CA+RyBmW3nDxMphGaJ2eThZ3fs4zvD5D-9kiJBVSTzPoApkWqgA@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
Content-Type: multipart/alternative; boundary="94eb2c0c0126910dbd052ffd91e1"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/LAQQZ9t4tWLvj4zXqiZ0508gKpY>
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>, Manav Bhatia <manavbhatia@gmail.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: Fri, 08 Apr 2016 18:43:23 -0000

Hi Reshad,
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.
Regards, Greg
On Apr 8, 2016 11:28 AM, "Reshad Rahman (rrahman)" <rrahman@cisco.com>
wrote:

> Hi Greg,
>
> With the proposal in the draft won’t you need a change to indicate that
> the link-local multicast address should be used?
>
> Regards,
> Reshad.
>
> From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Gregory Mirsky <
> gregory.mirsky@ericsson.com>
> Date: Friday, April 8, 2016 at 12:12 PM
> To: Manav Bhatia <manavbhatia@gmail.com>
> 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>, "Alia
> Atlas (akatlas@gmail.com)" <akatlas@gmail.com>, "rtg-bfd@ietf.org" <
> rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" <rtg-bfd-chairs@ietf.org>
> Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces
>
> Hi Manav,
>
> thank you for your consideration. The advantage of the MC-LAG is that
> there’s nothing changes for SE which still sees it LAG. If one to use
> different destination IP addresses on SE side, then that advantage will be
> lost. Our proposal is to preserve it.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Manav Bhatia [mailto:manavbhatia@gmail.com <manavbhatia@gmail.com>]
>
> *Sent:* Friday, April 08, 2016 8:05 AM
> *To:* Gregory Mirsky
> *Cc:* Mach Chen; rtg-bfd@ietf.org; mpls@ietf.org;
> draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org;
> mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
> *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces
>
>
>
> Hi Greg,
>
>
>
> Why cant different micro-BFD packets use the IP address of the MC-LAG end
> points? Ones going to router 1 will all carry the same unicast IP address.
> The ones going towards the other router will all carry some other IP
> address, which would be configured along with the MC-LAG configs.
>
>
>
> In fact i would argue that the u-bfd packets going to different routers
> must use different IP addresses so that you can actually verify the data
> plane liveliness. Whats the point in sending a contrived IP address if the
> path that it takes is different from the other regular packets?
>
>
>
> Cheers, Manav
>
>
>
> On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky <
> gregory.mirsky@ericsson.com> wrote:
>
> Hi Manav,
>
> thank you for sharing insight view of discussions around RFC 7130,
> extremely helpful.
>
> We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents
> different case and the compromise that you’ve pointed too is justified. We
> will add more details on the potential differences between unicast and
> multicast fast paths in the next update.
>
> We are open to the discussion and always welcome comments and alternative
> proposals.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Manav Bhatia [mailto:manavbhatia@gmail.com]
> *Sent:* Thursday, April 07, 2016 7:39 PM
> *To:* Mach Chen
> *Cc:* Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org;
> draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org;
> mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
> *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces
>
>
>
> I believe it had to do with multicast datapath (especially link local)
> being different from the unicast datapath in most routers. Using link local
> multicast IP addresses may not necessarily guarantee Unicast IP
> reachability.
>
>
>
> When writing 7130 we spent quite a bit of time ensuring that we dont carve
> out a special data path for the micro-BFD packets. Using link local would
> have made it a lot simpler.
>
>
>
> And this is where i think the current proposal is flawed -- they use link
> local multicast to ensure IP unicast reachability which is incorrect.
>
>
>
> Cheers, Manav
>
>
>
> On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen <mach.chen@huawei.com> wrote:
>
> Hi Greg and all,
>
>
>
> I just have quick review on the drafts. If my understanding is correct,
> the idea is to use multicast destination address other than unicast address
> when  sending BFD packets over LAG links. And actually this idea has been
> proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the
> predecessor of RFC 7130). And at that time, the co-authors of RFC 7130 did
> discuss the idea of using multicast destination address, but for some
> reason I forget now(I may need to reiterate the discussions on the
> archive), the idea was abandoned, although I still think multicast
> destination address is a smart idea.
>
>
>
> Best regards,
>
> Mach
> ------------------------------
>
> *From:* Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [
> gregory.mirsky@ericsson.com]
> *Sent:* Tuesday, April 05, 2016 6:16
> *To:* rtg-bfd@ietf.org; mpls@ietf.org
> *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org;
> rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (
> akatlas@gmail.com)
> *Subject:* Two new drafts on (micro-)BFD over MC-LAG interfaces
>
> Dear All,
>
> two new drafts, related to RFC 7130, were published before the meeting:
>
> ·         BFD on MC-LAG interfaces in IP network
> <https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-ip-00>
>
> ·         BFD on MC-LAG interfaces in IP/MPLS network
> <https://tools.ietf.org/html/draft-tanmir-rtgwg-bfd-mc-lag-mpls-00>
>
>
>
> Greatly appreciate your reviews, comments, questions and suggestions.
>
>
>
> Regards,
>
>         Greg
>
>
>
>
>