Erik, Erik Nordmark wrote: > > > > 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. > > > > 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?
Argh. I was trying to use a simple example, which doesn't make the point. You are correct about the zero prefix. > > 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. 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 -------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
