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*
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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
