Subject: RE: uni-based-mcast and malloc-ipv6-guide

From: "Dave Thaler" <[email-masked]>
Date: Mon, 17 Sep 2001 13:26:26 -0700

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Monday, September 17, 2001 1:11 PM
> To: Dave Thaler
> Cc: Erik Nordmark; [email-masked]; [email-masked]
> Subject: RE: uni-based-mcast and malloc-ipv6-guide
> 
> > > -----Original Message-----
> > > From: Erik Nordmark [mailto:[email-masked]]
> > > Sent: Monday, September 17, 2001 11:23 AM
> > >
> > > > See RFC 2908.
> > >
> > > At least that reference is missing from the document.
> > > But I see a mismatch between the draft and RFC 2908 since the
latter
> > > seems to say that an application can request multicast addresses
with
> > > a particular lifetime. With the uni-based addresses there can be
no
> > > way for the application to request a lifetime.
> > > How can this be resolved?
> >
> > What makes you think there isn't a way for the app to request a
> > lifetime?
> > RFC 2771 applies to all dynamic multicast addresses.
> 
> Huh?
> 
> How does the application requesting a particular lifetime effect the
> lifetime that the routers use when advertising the unicast prefix?

It doesn't.
In the abstract API, the application supplies a minimum and desired
lifetime.  If the app says [0, 6 months] and the host knows that
the unicast prefix is valid for 1 week, it can tell the app it has
it for one week (and the app can renew it at any time).
 
> Are you envisioning some new protocol to inform the routers (and the
> system
> admin, ISP, RIR) that allocated the unicast prefix that it needs to
> stay around for long enough to satisfy the applications request? :-)

Gosh I hope not :)

> So while there might be an abstract API that allows the application
> to ask, the scheme in uni-based-mcast doesn't seem to have the pieces
> so that the system can honor such a request; at least not with a
strict
> interpretation of the relationship between the RFC 2462 notion of
lifetime
> of the unicast prefix, and the presumed lifetime of the derived
multicast'
> address.

If the app says [6 months, 6 months] then personally I would expect the
host to fail the request if it only has a unicast prefix lifetime of 1
week.
I think your question is really: should we allow such a host to grant
a request for 6 months if it only has a unicast prefix lifetime of 1
week?

In my previous email, if there is a need to allow this (and I'm not
saying
there is), then we'd have to just say it SHOULD NOT, and say that after
the unicast lifetime, the multicast packets are not guaranteed to be
routed.

> Hence my question whether the intent is to have such a strict
relationship
> or not.

I'd like to hear others opinions, but I think that is the authors'
intent.
 
-Dave
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Sep 2001 09:29:29 +0200 (CEST)

> a request for 6 months if it only has a unicast prefix lifetime of 1

Bingo!

The related question is: are there applications which would fail to function
today if you applied the constraints imposed by this today i.e. the
fact that no multicast addresses could be allocated by the API
with an end time more than a week into the future?
(For this excercise it would make sense to consider the IPv4 multicast
applications as well as the IPv6 multicast applications that exist just
to try to understand the scope of the applications dependency on multicast
address lifetimes.)

> the unicast lifetime, the multicast packets are not guaranteed to be

I fail to understand why routing might fail. Could you explain?
I do understand that there is a different probability of allocating duplicate
uni-based mcast addresses should the unicast prefix be assigned to another
entity, but this doesn't lead to routing failing unless you are assuming
that routing will do something it doesn't currently do.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Sep 2001 17:14:38 +0200 (CEST)

> I think one possible example is with SSM.  The first hop router
> may receive an IGMPv3 join with an old prefix that has been
> renumbered.  It then tries to send the SPT Join to the wrong
> network.  That network doesn't exist and so the Join fails and
> the multicast traffic never flows.

Brian,

I thought uni-based mcast addresses for SSM has an all zero prefix component.
(That's what the uni-based draft says.)
Are you referring to such a prefix or the IP source address?

Clearly SSM, which explicitly identifies a group by the pair <IP source
address, Multicast destination>, is likely to barf when the IP source address
is no longer valid for the sender. 
Depending on whether the document is correct or not about having a zero
prefix in the SSM multicast destination, this may or may not be
an issue for the actual multicast address.

  Erik

---

From: "Brian Haberman" <[email-masked]>
Date: Tue, 18 Sep 2001 10:11:09 -0400

Dave,

> it for one week (and the app can renew it at any time).

That was my intent.  It fits the existing v4 mcast allocation
architecture.  A host may request an address for ANY particular
lifetime, but there are no guarantees that the requested lifetime
can be honored.

> > stay around for long enough to satisfy the applications request? :-)

Agreed!  I am trying to reduce the number of protocols.

> the unicast lifetime, the multicast packets are not guaranteed to be

I have no problems changin the text to SHOULD NOT.

> I'd like to hear others opinions, but I think that is the authors'

It was my intent.  IF we are going to try and eliminate the multi-
layered allocation architecture, there needs to be some controlling
mechanism and the only one I could find was the unicast prefix in
the RAs.

Brian

---

From: "Brian Haberman" <[email-masked]>
Date: Tue, 18 Sep 2001 10:19:16 -0400

Erik,

> to try to understand the scope of the applications dependency on multicast

As I said in an earlier response, this is not a v6 specific issue.
Applications/stacks/nodes/etc. using MAPCAP in v4 will have to deal
with the aspect of mcast address leases not filling their initial
lifetime requests.

Maybe someone with more operational experience than me with MAPCAP
allocated addresses will describe how they deal with lease renewal
and advertisement issues.  I don't see usage of dynamically allocated
addresses being requested weeks in advance for one day use.  I could
be wrong, but I haven't seen any behave in that manner.

Brian

---

From: "Brian Haberman" <[email-masked]>
Date: Tue, 18 Sep 2001 11:28:30 -0400

Erik,

> Are you referring to such a prefix or the IP source address?

Argh.  I was trying to use a simple example, which doesn't make the
point.  You are correct about the zero prefix.

> an issue for the actual multicast address.

OK, I have had a little time to think about some of these comments.
The lifetime of the mcast address allocation may still have an affect
on the routing.  Since mcast forwarding is based on an <S,G> state,
due to RPF checks, as long as G is not changed by the application
sending the data, forwarding should work.  Except for the fact that
if G changes due to a prefix lifetime expiration, S may/will change
as well.  This holds true for SSM or ASM.

If S is not the one who requested G from the MADCAP server, then it
will be arbitrary as to whether or not S will change when G changes
due to a lifetime expiration.

Brian