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

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Fri, 08 April 2016 15:50 UTC

Return-Path: <rrahman@cisco.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 5668212D517; Fri, 8 Apr 2016 08:50:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 P8uQTMJZgNAi; Fri, 8 Apr 2016 08:50:50 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178E712D101; Fri, 8 Apr 2016 08:50:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18946; q=dns/txt; s=iport; t=1460130650; x=1461340250; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6fMz7E/0vNhu6f3Ia5f9cH8Dd5oUMw0Fpokd39ey/iU=; b=W01dD/99a95hk3aNNZptaiNQu/WsPBkaPNfHDUmTyeRRY4YOzR5iUXEZ eojdVT5HEVtZ0d66ZGhaLJMmyTAYRdyiYtav7IhI6zYRQRhpTqG9fD54g yr73EALsG+mgbpoExfsYZpRHh4b+LqfN2i08hTs88nyU1GLf2nVZiO9u0 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AwAgD/0gdX/49dJa1cgmtMU30GrmeGZYRzAQ2BcyGFbAKBMzgUAQEBAQEBAWUnhEEBAQEEeRACAQgRAwEBARoCDAchERQJCAEBBAENBYgSAxIOuzgNhSEBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhhEuCQYIeDQknAoR3BY4GiU0xAYV2hiCBdYFnjSaGH4Erh1oBHgEBQoIEGYFKbFqHJD0BfQEBAQ
X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="scan'208,217";a="259150790"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 15:50:48 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u38FomrA009196 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 15:50:48 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 10:50:47 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 10:50:47 -0500
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Manav Bhatia <manavbhatia@gmail.com>, Gregory Mirsky <gregory.mirsky@ericsson.com>
Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces
Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZAB2XmwAAFPl8AAAFFQWA///JyYA=
Date: Fri, 08 Apr 2016 15:50:47 +0000
Message-ID: <D32D4A99.13B056%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>
In-Reply-To: <CAG1kdoibVBWsga3K88MGbZAFSbD_2q0efea_8aEKd_hN+CV53w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.1.160122
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.213.167]
Content-Type: multipart/alternative; boundary="_000_D32D4A9913B056rrahmanciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/eQFNQEgjABBw6Sgl4m3Ts9H6yE0>
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>, "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 15:50:53 -0000

I agree with Manav, and nothing in RFC7130 seems to preclude using different unicast IP address as destination on different member links.

Regards,
Reshad (as individual contributor).

From: Rtg-bfd <rtg-bfd-bounces@ietf.org<mailto:rtg-bfd-bounces@ietf.org>> on behalf of Manav Bhatia <manavbhatia@gmail.com<mailto:manavbhatia@gmail.com>>
Date: Friday, April 8, 2016 at 11:04 AM
To: Gregory Mirsky <gregory.mirsky@ericsson.com<mailto:gregory.mirsky@ericsson.com>>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org<mailto:draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org<mailto:draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>>, "mpls@ietf.org<mailto:mpls@ietf.org>" <mpls@ietf.org<mailto:mpls@ietf.org>>, "mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>" <mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>>, "Alia Atlas (akatlas@gmail.com<mailto:akatlas@gmail.com>)" <akatlas@gmail.com<mailto:akatlas@gmail.com>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>, "rtg-bfd-chairs@ietf.org<mailto:rtg-bfd-chairs@ietf.org>" <rtg-bfd-chairs@ietf.org<mailto:rtg-bfd-chairs@ietf.org>>
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<mailto: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<mailto:manavbhatia@gmail.com>]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org>; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org<mailto:draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>; rtg-bfd-chairs@ietf.org<mailto:rtg-bfd-chairs@ietf.org>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; Alia Atlas (akatlas@gmail.com<mailto: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<mailto: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<mailto:rtg-bfd-bounces@ietf.org>] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com<mailto:gregory.mirsky@ericsson.com>]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org>
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org<mailto:draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>; rtg-bfd-chairs@ietf.org<mailto:rtg-bfd-chairs@ietf.org>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; Alia Atlas (akatlas@gmail.com<mailto: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