[lisp] Questions on using LISP's signal free multicast for draft-ghanwani-nvo3-app-mcast-framework

Linda Dunbar <linda.dunbar@huawei.com> Sun, 31 August 2014 13:22 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A7E1A8976; Sun, 31 Aug 2014 06:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.868
X-Spam-Level:
X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
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 L3TrRqzZGEKH; Sun, 31 Aug 2014 06:22:02 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31BE11A897D; Sun, 31 Aug 2014 06:22:02 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIX45381; Sun, 31 Aug 2014 13:22:00 +0000 (GMT)
Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 31 Aug 2014 14:22:00 +0100
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Sun, 31 Aug 2014 06:21:57 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Dino Farinacci <farinacci@gmail.com>
Thread-Topic: Questions on using LISP's signal free multicast for draft-ghanwani-nvo3-app-mcast-framework
Thread-Index: Ac/EhQABYHv1vOWVT6W+msem4gUujQ==
Date: Sun, 31 Aug 2014 13:21:57 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DDEAFB@dfweml701-chm>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.5.213]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645DDEAFBdfweml701chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/1_mgI_e6Zkl1Q2dxpTESHMoejwY
Cc: "nvo3@ietf.org" <nvo3@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>
Subject: [lisp] Questions on using LISP's signal free multicast for draft-ghanwani-nvo3-app-mcast-framework
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Aug 2014 13:22:05 -0000

Dino,

At Toronto NV03 session, you suggested that draft-ghanwani-nvo3-app-mcast-framework can use LISP's signal free multicast scheme.
After studying the draft-farinacci-lisp-signal-free-multicast-00, I agree that the proposed scheme can definitely solve the problem of application initiated multicast in environment where underlay network don't support any IP multicast protocol.

But there are some issues of using the LISP's signal free multicast mechanism in Data Centers when NVEs, especially the server based hypervisor virtual switches,  don't ( or can't) support the "General Receiver-site procedure" documented in the "draft-farinacci-list-signal-free-multicast-00".  The general receiver-site procedure requires egress edge (i.e. egress NVE) to terminate IGMP or PIM messages. But many NVEs (server based virtual switches) don't terminate IGMP nor PIM.

Therefore, NVO3 needs a simpler scheme for "Receiver NVEs".   draft-ghanwani-nvo3-app-mcast-framework-00 suggests all IGMP messages are sent to "multicast server".

Or "Multicast server" can fake "IGMP query" to all the NVEs, which forwarded down to applications. The reply (IGMP report) can be automatically sent back to "multicast server" without NVE doing anything extra.

What do you think?


Linda