Subject: RE: [mobile-ip] Issue 63: Multicast

From: "Alan O'Neill" <[email-masked]>
Date: Wed, 17 Jul 2002 00:06:55 -0400

Hi Eric,

The reason that I wish to restrict the use of the CoA as the source for
foreign network multicast is not due to any comparison with
reverse-tunnelled multicast. Home and foreign multicast systems are needed
for many different technical and commercial reasons clearly.

However, it is not clear at the moment whether foreign network multicast
should ultimately use the the CoA or the HoA as the source address, so we
should do that work before giving the MN the option of origination into the
foreign system because of forwards compatibility.. The former has the
problem that the multicast system will be thrashed whilst the latter has the
RPF problem. Either might be fixable and a range of protocol (domain)
specific solutions exist in the interim which we can document, including
hybrid.

I don't understand how a potential thrashing problem can be allowed to
progress through the base spec. Maybe you don't believe this exists, or is
that you believe we can trust vendors and operators to do the right thing ?

Clarifying this would help...Maybe this could alternatively be addressed
with some applicability words that specifically does not rule out hybrid or
otheruses of the HoA as a foreign multicast source address ?

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: 16 July 2002 23:40
To: Alan O'Neill
Cc: [email-masked]'
Subject: RE: [mobile-ip] Issue 63: Multicast

> The suggested resolution was that the use of the home multicast system via
a
> bi-directional tunnel be included in the spec (fine) but that a MN can
> optionally use, for the foreign multicast system, its CCoA as a source
> address (not fine) to originate traffic to a multicast group, and that the
> detailed mechanisms for this would be detailed in draft-oneill-multicast
> etc..

The way I see this both approaches have performance issues of different
flavors. Reverse tunneling packets through the HA adds delay for packets
(and is subject to additional potentially congested devices in the network).
Using the CoA as the source causes multicast routing related overhead 
as you point out.
Thus I don't think we can say that one is strictly better than the other;
the performance issues aren't comparable.
Hence I don't see a need to prohibit sending packets with the CoA
as the source.

> It is as dangerous and unscalable (possibly more so) as supporting
> MN movement in the unicast routing system by using host routes rather than
> MIP edge tunnel redirection.

I suspect there are cases when reverse tunneling is equally "dangerous and 
unscalable" - it all depends on the assumptions.
So either we allow both ways (and provide future documentation with guidance
on the issues and tradeoffs between them) or we forbit both.

There are similar issues for the joining of multicast groups.
If it is done using the local interface (the "CoA") then the multicast
tree will change as the MN moves, which is bad. 
If it is done over the reverse tunnel (the "HoA") then the multicast
packets will be tunneled from the HA even though copies of the same
multicast packets might already be present on the visited link.

Also in that case I think both approaches make sense under different
cicumstances.

   Erik

****************************************************************************
************************************
This email may contain confidential and privileged material for the sole use
of the
intended recipient. Any review or distribution by others is strictly
prohibited.
If you are not the intended recipient please contact the sender and delete
all copies.
****************************************************************************
*************************************

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 17 Jul 2002 12:38:45 +0200 (CEST)

> foreign system because of forwards compatibility.

The current archiecture requires that the CoA is used as a source when
sending multicast packets on the foreign link and the HoA when reverse
tunneling them through the HA. An example of this architecture is
this statement in draft-ietf-ipv6-default-addr-select:
   For multicast and link-local destination addresses, the set of 
   candidate source addresses MUST only include addresses assigned to 
   interfaces belonging to the same link as the outgoing interface. 

(And, as an aside, the precense of ingress filtering routers
apply the same restriction to unicast packets from mobile nodes
that are away from home).

Perhaps there are possible future architectures that do not have
these constraints, and perhaps it makes sense exploring them to
provide different performance for multicast for MNs. But I suspect
this would result in added total complexity to the system.
The point is that the draft is about the current architecture.

> that you believe we can trust vendors and operators to do the right thing ?

I don't understand why mobility creates a unique problem here. 
IP traffic is known to be bursty, thus the multicast routing system needs 
to be able to deal with bursty sources on widely varying time scales.
A mobile node moving around and using the CoA as the source just looks
like multiple (bursty) sources that are not moving.

> otheruses of the HoA as a foreign multicast source address ?

Using the HoA as source on the visited link doesn't work due to RPF checks 
in the current archiecture as you already pointed out.

  Erik