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

From: "Alan O'Neill" <[email-masked]>
Date: Sat, 20 Jul 2002 05:52:53 -0400

Thanks Eric,

The mist is clearing...

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

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

AWO> Sure - I fully appreciate that the present barriers to using the HoA as
a foreign multicast source address are significant and hence why I am not
suggesting adding that to the spec. These barriers additionally include the
RPF check of course. Note though that hybrid multicast does not break either
requirement, but again I also have some concerns with adding that to the
spec. My only concern is whether the use of the CoA in MIPv6 should be
allowed in the base spec given the thrashing risk which you comment on
below. The current architecture of IPv6 allows the CoA address and is fine
because their is no mobility. My concern is limited to MIPv6 which has its
own additional architecture given that mobility, and I believe the draft 18
architecture has problems that are of concern. IPv6 also has a routing
header but in the case of mobility a special type header was needed
instead..mobility changes things.. So all I am requesting here is that draft
18 be amended if there is a problem, and as has happened before, IPv6
architecture should not just be accepted within MIPv6 without consideration
of new mobility specific problems...In addition, IPv6 architecture will
change as we learn more..I should also mention that given this issue also
exists for MIPv4, there is less of an 'architectural' barrier there because
the MN is not prohibited in IPv4 from using the HoA as a source address on a
foreign link.

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.

AWO> And I certainly do not want to add additional complexity unless it is
necessary..But I would rather have some additional complexity than a useless
or unstable feature, in the same way that RR complexity had to be added to
RO for different but important reasons.

> 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
?

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.

AWO> Ok - so lets concentrate on this point, so that the wg can agree if
there is, or is not, a problem. We can then come back to discuss / address
the barriers wrt solving it. I have a couple of other jobs I have to get
done first (other MIPwg stuff) and then I'll send some e-mails explaining
where this is similar yet very different from the bursty source problem in
conjunction with different multicast protocols. I'll also copy in some
multicast experts so we can ensure we isolate the correct issues and get
best advice on progression. I hope that is ok.

> 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 ?

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.

AWO> Absolutely..no disagreement here. The hybrid approach might though give
us a working feature..and if none of these work then we have to either
restrict the base spec, add applicability stuff and/or fix the
architecture(s)..

Regards, Alan.

****************************************************************************
************************************
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: Tue, 23 Jul 2002 03:14:36 +0200 (CEST)

> I should also mention that given this issue also

The same real-world constraints exist in IPv4 (ingress filtering for all
packets and RPF checks for multicast) as in IPv6. Of course, the mobile IPv4
documents might fail to mention this detail, but that isn't a fault of
the mobile IPv6 document :-)

Could you fix the above trailer in the email?

  Erik