Subject: [lisp] Multicast LISP

From: Paul Vinciguerra <[email-masked]>
Date: Sun, 24 Mar 2013 22:13:46 +0000

I know I'm showing up late to the party, but can someone expand upon this from the RFC?

5.  Source Addresses versus Group Addresses

   Multicast group addresses don't have to be associated with either the
   EID or RLOC namespace.  They actually are a namespace of their own
   that can be treated as logical with relatively opaque allocation.
   So, by their nature, they don't detract from an incremental
   deployment of LISP-Multicast.

The documents make reference to:
(S-EID,G)
(S-RLOC,G)

It seems that while both these may be numerically identical (eg. 239.255.255.254), in terms of LISP, doesn't (S,G) have to much more complex and represent either (S-EID,G-EID(IID)) and (S-RLOC,G-RLOC(IID))?

Once we introduce LISP mobility, what does (G) actually mean, especially when (G) can refer to link-local multicast for a host that has roamed off of its home subnet?

Paul

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 24 Mar 2013 15:28:53 -0700

> It seems that while both these may be numerically identical (eg. 239.255.255.254), in terms of LISP, doesn’t (S,G) have to much more
> 
Well yes. The spec used "G" to be the group address the users use to join to and/or send to. And the spec says you COULD map one-to-one so if you are encapilcating to G, then G must be globally unique (perhaps out of GLOP space or something like embed-RP space in IPv6). 
> complex and represent either (S-EID,G-EID(IID)) and (S-RLOC,G-RLOC(IID))?
> 
Right. An instance-ID will allow both the EID and G to be reused by LISP sites participating in the VPN use-case. Meaning a shared data-plane core can be used as well as a shared control-plane mapping database system. 
>  Once we introduce LISP mobility, what does (G) actually mean, especially when (G) can refer to link-local multicast for a host that has roamed off of its home subnet? 
In the pre-LISP Internet G was always mobile because if a receiver roamed it just IGMP joined and the distribution tree is built with a new branch. Just as if the receiver didn't moved, was not joined, then joined and the branch of the distribution tree was built.

I hope I answered your question or satisfied your concern. 

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 24 Mar 2013 18:54:12 -0400

Maybe I am naive, but it strikes me that trying to extend link-local 
IPv6 multicasts with LISP is probably a bad idea.  Within the mobile 
device scope, the registration mechanisms would seem to provide better 
tools for things like address duplication prevention.

While I don't know if the documents capture it properly, the 
fragmentation effect of mobile devices on EID resolution blocks is such 
that I generally would want to keep them separate from the fixed devices.

Yours,
Joel

On 3/24/2013 6:13 PM, Paul Vinciguerra wrote:
> I know I’m showing up late to the party, but can someone expand upon
> this from the RFC?
>
> *5.  Source Addresses versus Group Addresses*
>
> It seems that while both these may be numerically identical (eg.
> 239.255.255.254), in terms of LISP, doesn’t (S,G) have to much more
> Once we introduce LISP mobility, what does (G) actually mean, especially
> when (G) can refer to link-local multicast for a host that has roamed
> off of its home subnet?
>
> Paul
>
>
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Paul Vinciguerra <[email-masked]>
Date: Sun, 24 Mar 2013 23:04:23 +0000

Yes.  I think this is really not a LISP question as much as it is a corner case for the host that LISP creates.  With no changes to the host, if a host moves, should the host expect to be able to continue talking to its existing (G) members, or should the expectation be that host needs to do a join to the new (G') in the link-local case.

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Sunday, March 24, 2013 6:54 PM
> To: Paul Vinciguerra
> Cc: [email-masked]
> Subject: Re: [lisp] Multicast LISP
> 
> IPv6 multicasts with LISP is probably a bad idea.  Within the mobile device scope,
> the registration mechanisms would seem to provide better tools for things like
> address duplication prevention.
> 
> While I don't know if the documents capture it properly, the fragmentation
> effect of mobile devices on EID resolution blocks is such that I generally would
> want to keep them separate from the fixed devices.
> 
> Yours,
> Joel
> 
> > 239.255.255.254), in terms of LISP, doesn't (S,G) have to much more
> > Once we introduce LISP mobility, what does (G) actually mean,
> > especially when (G) can refer to link-local multicast for a host that
> > has roamed off of its home subnet?
> >
> > Paul
> >
> >
> >

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 24 Mar 2013 17:48:02 -0700

Joel - if we talk about link-local multicast being forwarded it is in context of an L2 overlay where EIDs are MAC addresses. So NVO3 related work, even though NVO3 is not limited to L2 overlays. 

Dino

On Mar 24, 2013, at 3:54 PM, "Joel M. Halpern" <[email-masked]> wrote:

> Maybe I am naive, but it strikes me that trying to extend link-local IPv6 multicasts with LISP is probably a bad idea.  Within the mobile device scope, the registration mechanisms would seem to provide better tools for things like address duplication prevention.
> 
> While I don't know if the documents capture it properly, the fragmentation effect of mobile devices on EID resolution blocks is such that I generally would want to keep them separate from the fixed devices.
> 
> Yours,
> Joel
>

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 24 Mar 2013 17:52:08 -0700

> Yes.  I think this is really not a LISP question as much as it is a corner case for the host that LISP creates.  With no changes to the host, if a host moves, should the host expect to be able to continue talking to its existing (G) members, or should the

Yes it should but G is not limited to just link-local. If a moved host expects to talk to on-subnet host via unicast Mac-addressing or link-local multicasting MAC addressing is a layer-2 interconnect issue WHICH LISP can support. 

But Paul - when you read 6831, it is related to layer-3 multicast. You probably know that but just FYI. 
 
> expectation be that host needs to do a join to the new (G') in the link-local case.

There is only one G that the app of the moving system is joined too. And also, link-local multicast groups are not explicitly joined. 

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 24 Mar 2013 22:24:35 -0400

I guess I saw "mobility" and thought it was abut the stuff we have seen 
in drafts abut LISP for mobile devices (cellular and WiFi).  If the 
discussion topic is VM movement and L2 extension, yes, I agree with what 
you have said.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 24 Mar 2013 19:37:25 -0700

And if we are talking in your context then a link-local multicast packet (or unicast for that matter) should STAY ON LINK, which means it should not be layer-3 encapsulated. So we are in agreement. 

Note, STAY ON LINK, in most circles, means contained within a subnet/VLAN/layer-2 domain.

Dino

On Mar 24, 2013, at 7:24 PM, "Joel M. Halpern" <[email-masked]> wrote:

> I guess I saw "mobility" and thought it was abut the stuff we have seen in drafts abut LISP for mobile devices (cellular and WiFi).  If the discussion topic is VM movement and L2 extension, yes, I agree with what you have said.
> 
> Yours,
> Joel
>