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

From: Linda Dunbar <[email-masked]>
Date: Mon, 8 Dec 2014 23:04:24 +0000

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

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

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. 

We appreciate your feedback. 

Linda 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
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:            http://www.ietf.org/internet-drafts/draft-ghanwani-nvo3-app-mcast-framework-01.txt
Status:         https://datatracker.ietf.org/doc/draft-ghanwani-nvo3-app-mcast-framework/
Htmlized:       http://tools.ietf.org/html/draft-ghanwani-nvo3-app-mcast-framework-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ghanwani-nvo3-app-mcast-framework-01

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 tools.ietf.org.

The IETF Secretariat

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 8 Dec 2014 16:14:37 -0800

> "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 fo…

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

Dino

---

From: Sharon Barkai <[email-masked]>
Date: Tue, 9 Dec 2014 02:28:15 +0000

I think it's important to point out that all these features which require in-network anchoring e.g. multicast replication, mobility/motion, chaining, NAT traversal, anycast ... in lisp, use ONE consistent methodology - a "floating" anchor in the mapping database can be unambiguously resolved & realized dynamically at the network edge Ingres just in time.
Would really be good if this systemic anchoring approach is carried over to nvo3, 
rather then each such feature will be built based on a whole new methodology-terminology.

--szb

> On Dec 8, 2014, at 16:14, Dino Farinacci <[email-masked]> wrote:
> 
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 12 Dec 2014 19:18:33 +0000

Dino,

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,

Linda

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

Dino

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 12 Dec 2014 11:56:25 -0800

> 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.”  
>  

The description is fine but the term "multicast-group" is probably too specific and does not include IGMPv3 and MLDv2 (S,G) specific entries. I would change "multicast-group" to "joined-multicast-entry" and then define what a "joined-multicast-entry" can be.

Dino

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 12 Dec 2014 15:23:36 -0600

Sharon,

Is the "floating anchor in mapping database" same as the "systemic
anchoring"?

Can you send me the draft names that describe the "floating anchoring"?  We
definitely should make it consistent across multiple WGs.

Thanks, Linda

On Mon, Dec 8, 2014 at 8:28 PM, Sharon Barkai <[email-masked]>
wrote:
>
> I think it's important to point out that all these features which require
> in-network anchoring e.g. multicast replication, mobility/motion, chaining,
> NAT traversal, anycast ... in lisp, use ONE consistent methodology - a
> "floating" anchor in the mapping database can be unambiguously resolved &
> realized dynamically at the network edge Ingres just in time.
> >> "The fundamental multicast forwarding model is to encapsulate a
> multicast packet into another multicast packet"
> >
> > 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.
> >
> >> 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.
> >
> > Dino
> >
> >>
> >> 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
> >>
> >>
> >> URL:
> http://www.ietf.org/internet-drafts/draft-ghanwani-nvo3-app-mcast-framework-01.txt
> >> Status:
> https://datatracker.ietf.org/doc/draft-ghanwani-nvo3-app-mcast-framework/
> >> Htmlized:
> http://tools.ietf.org/html/draft-ghanwani-nvo3-app-mcast-framework-01
> >> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-ghanwani-nvo3-app-mcast-framework-01
> >>
> >> Abstract:
> >> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> >>
> >> The IETF Secretariat
> >
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 12 Dec 2014 21:44:28 +0000

Dino, 

How would you define the term "joined-multicast-entry"?

Literally, I see "joined-multicast-entry" being similar to  "replication-list for a multicast group", (instead of multicast group), correct? 

Linda

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: Friday, December 12, 2014 1:56 PM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]
Subject: Re: Comparing LISP multicast with draft-ghanwani-nvo3-app-mcast-framework-01.txt

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 12 Dec 2014 13:55:15 -0800

> How would you define the term "joined-multicast-entry"?

An IGMPv2 joined group, an IGMPv3 joined (*,G) or (S,G), as well as an MLDv2 (*,G) or (S,G) joined entry.

Dino