Re: [lisp] Comparing LISP multicast with draft-ghanwani-nvo3-app-mcast-framework-01.txt

Linda Dunbar <> Fri, 12 December 2014 19:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A46AD1A9027; Fri, 12 Dec 2014 11:18:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NtYIo6yPf36B; Fri, 12 Dec 2014 11:18:42 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 12C121A88E4; Fri, 12 Dec 2014 11:18:41 -0800 (PST)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BMU27616; Fri, 12 Dec 2014 19:18:40 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 12 Dec 2014 19:18:39 +0000
Received: from ([]) by dfweml705-chm ([]) with mapi id 14.03.0158.001; Fri, 12 Dec 2014 11:18:33 -0800
From: Linda Dunbar <>
To: Dino Farinacci <>
Thread-Topic: Comparing LISP multicast with draft-ghanwani-nvo3-app-mcast-framework-01.txt
Thread-Index: AQHQEztPcgLT28AsZ0i/51SzuPuK+5yG6eGAgAVgHLA=
Date: Fri, 12 Dec 2014 19:18:33 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645E7D27F@dfweml701-chm>
References: <4A95BA014132FF49AE685FAB4B9F17F645E75398@dfweml701-chm> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645E7D27Fdfweml701chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "" <>, "" <>
Subject: Re: [lisp] Comparing LISP multicast with draft-ghanwani-nvo3-app-mcast-framework-01.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Dec 2014 19:18:50 -0000


We already have a section (3.3.1) on the mechanism similar to draft-farinacci-lisp-signal-free-multicast-01, i.e. Egress maintaining the (S, G) state and send update to the Multicast Service Node (MSN),(whereas in LISP, the update is sent to MapServer).

In NVO3, we also want to allow Multicast Agnostic NVEs (primarily for server based NVEs that don't do anything special for multicast control packets)

For the "source replication" description of our draft (section3.2), I can add the following to make it consistent with the LISP approach. Is it OK?
      "The method of receiver-sites registration for a particular multicast-group described in [LISP-Signal-Free] can be used for NVO3. The registrations from different receiver-sites can be merged at the Multicast Service Node (MSN of Section 3.3) or the NVA to assemble a multicast-replication-list inclusive of all remote NVEs to which receivers for a particular multicast-group are attached. The replication-list for each specific multicast entry is maintained either by MSN or NVA.
      The receiver-sites registration is achieved by egress NVEs performing the IGMP/MLD snooping to maintain which attached Tenant Systems have subscribed to a given IP multicast stream. When the members of a multicast group are outside the NVO3 domain, it is necessary for NVO3 domain gateways to keep track of the remote members of each multicast group."

Please let me know if this description is good enough?

Thank you,


-----Original Message-----
From: Dino Farinacci []
Sent: Monday, December 08, 2014 6:15 PM
To: Linda Dunbar
Subject: Re: Comparing LISP multicast with draft-ghanwani-nvo3-app-mcast-framework-01.txt

> RFC 6831 (LISP for Multicast) states:
> "The fundamental multicast forwarding model is to encapsulate a multicast packet into another multicast packet"

Right, the fundamental model so we have the most efficient form of multicast delivery.

> So LISP assumes that the underlay network supports some sort of IP multicast scheme.

No, LISP does not, just this RFC does. If you look at the other LISP multicast related RFCs, you will see that you can encapsulate multicast packets inside of unicast packets.

And you can use PIM signaling specified in RFC 6831 to instruct an ETR to encapsulate in unicast.

> In NVO3 environment, especially in data center environment, the underlay network may not necessarily support IP multicast. draft-ghanwani-nvo3-app-mcast-framework-01 describes various mechanisms for forwarding tenant multicast traffic without the underlay network supporting the multicast protocols.

Right, see draft-farinacci-lisp-signal-free-multicast-01. It can simplify the control-plane as well as encapsulate in either unicast or multicast.


> We appreciate your feedback.
> Linda
> -----Original Message-----
> From:<> []
> Sent: Monday, December 08, 2014 4:17 PM
> To: Vinay Bannai; Linda Dunbar; Vinay Bannai; Ram (Ramki) Krishnan; Linda Dunbar; Anoop Ghanwani; Ram Krishnan; Anoop Ghanwani
> Subject: New Version Notification for draft-ghanwani-nvo3-app-mcast-framework-01.txt
> A new version of I-D, draft-ghanwani-nvo3-app-mcast-framework-01.txt
> has been successfully submitted by Linda Dunbar and posted to the IETF repository.
> Name:         draft-ghanwani-nvo3-app-mcast-framework
> Revision:     01
> Title:                Framework of Supporting Applications Specific Multicast in NVO3
> Document date:        2014-12-08
> Group:                Individual Submission
> Pages:                16
> URL:  
> Status:
> Htmlized:
> Diff: 
> Abstract:
>   This draft discusses the framework of supporting applications
>   specific multicast traffic, i.e. the non ARP/ND related
>   multicast/broadcast traffic, in a network that uses Network
>   Virtualization using Overlays over Layer 3 (NVO3). It describes the
>   various mechanisms and considerations that can be used for
>   delivering those application specific multicast traffic in networks
>   that use NVO3.
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at
> The IETF Secretariat