All things related to multicast

[Magnus Danielson <>]

From: Marshall Eubanks 
<>
Subject: Re: MSDP Storm
Date: Fri, 19 Jan 2001 10:50:15 -0500

> Dear Magnus;

Dear Marshall,

> Magnus Danielson wrote:
> > 
> > From: Marshall Eubanks 
> > <>
> > Subject: Re: MSDP Storm
> > Date: Fri, 19 Jan 2001 10:00:33 -0500
> > 
> > > Hello Magnus;
> > 
> > Dear Marshall,
> > 
> > > Magnus Danielson wrote:
> > > >
> > > > From: Marshall Eubanks 
> > > > <>
> > > > Subject: Re: MSDP Storm
> > > > Date: Thu, 18 Jan 2001 13:39:44 -0500
> > > >
> > > > > I would agree. Mischievously, I would point out that there is an 
> > > > > IGMP v3 RFC grinding along :
> > > > >  <draft-ietf-idmr-igmp-v3-05.txt>
> > > > > AND a MSDP draft grinding along as well :
> > > > > <draft-ietf-msdp-spec-06.txt>
> > > > >
> > > >
> > > > The actual numbers should never be put into that RFC. If specific 
> > > > numbers are
> > > > required, then you should have a separate RFC also running as a BCP 
> > > > to detail
> > > > it and updates can be made according to need.
> > >
> > > Correct, although a mboned BCP might not be a bad idea.
> > 
> > IMHO Mboned is the correct IETF WG for such a BCP. I just didn't imply 
> > the WG
> > to do the BCP in question.
> > 
> 
> My guess is that the numbers will be the hard part. It is easy, after
> all,  to say
> 
> MSDP neighbors SHALL limit the number of Session Announcements flooded out.

Right, please note what I said above... "If specific number are required, then
you should have a separate RFC also running as a BCP to detail it and updates
can be made according to need.", that is IF we find it necessary.
Also, since those numbers would be a Best Current Practice, we say that they
are open for changes if the best current practice changes.

Your wording above is correct for the MSDP ID/RFC regardless weither there are
an BCP or not.

Further, I rather propose a dynamic method in which you look back at running
statistics of say 60 days and only accept say an excess of 10 % over the
extrapolated curve. Something like that. The exact details we can work out, 
but
the need to change numbers becomes far less and the method may be better 
suited
to survive time and exponential growth if the statistical analysis and
extrapolation is well selected. In addition to this you could have a hard
limit as an option, but I think doing something like this limits the excess in
relation to what the box should expect to handle as a normal case.

> But it is not transparent (to me, at least) what that limit should be.
> Most people running a RP with MSDP will want guidance as to what limit
> should be
> used and/or what limits are reasonable. The same can be said for IGMP
> and PIM.

Certainly. I dont like hard limits like those, they are very coarse means of
control and needs attention to keep handling the normal case. Thus, a too
tight limit may hurt your normal buissness and require manual update on a
regular basis. Better to find a suitable method of doing this by automatic
means if we could do so.

We can however consider to standardize filters such as proposed. However, we
should be carefull not to bite our fannies or get our squeeker dysfunctional
since rate-limiting a single box at IGMP level could work against the intended
working if that box happends to be a application gateway or playback server.
There are a few notable applications which could generate many legal IGMP
joins.

Cheers,
Magnus