Re: Why MSDP?

["Nagesh Chintada" <nagesh.chintada@alcatel.com>]

David Meyer wrote:
>         Not sure
> about the history of this thread, but here's some
>         of the history.
>  
I  think you are addressing the core of this topic, which is, why
we can't use MBGP instead of MSDP.

 
        First, we looked at putting SAs into BGP. I wanted to
        do this as a first thought since the MBGP/MSDP split
        effectively splits the control plane. However, this
        turned out to be a less than optimal solution for several
        reasons, not the least of which included:

        (i).    State

                The reason MSDP is periodic and not incremental
                (and originally non-caching) is that we were tryin
                to avoid explosion of (S,G) state. I guess we're
                not so worried about that (c.f. SSM). In addition,
                we had to somehow (attempt to) solve the bursty
                source problem.

Yes, indeed SSM seems to side-step this problem very well.
About the bursty sources: it seems to me that we add a lot of overhead
to MSDP to solve this problem, and yet it is not clear if it is completely
reliable.

 
        (ii).   BGP Stability

                I don't really want to argue that the dynamic nature
                of SA advertisements is going to help the stability
                of BGP (that is, of the global routing system). Neither
                do you, I would guess.
 

Is there info available to compare the time-scales of these two traffic
types ( i.e SA-advt vs Unicast Route advt)? If so, that will be enlightening,
and I'd urge anyone to post it.

If I want to analyze this, I'd have to consider in a given time, in a given network, the number of routes, the
rate at which these are changing. What are the assumptions about:
   1. Rate of unicast route change ( per route)
   2. Number of unicast routes in the network
   3. Rate of an average SA advt ( per S,G)
   4. Number of sources in the network.

My suspicion is that #4 is far less compared to #2, and also that #1 is far slower compared to #3. leading to an intereting question on where the trade-off lies.

So, unless we are talking about really short sessions and  much larger  number of sources than is typical, it is not clear to me that this would threaten BGP's stability.

And what about timescales for other types of MBGP traffic? ( VPNs, for example) 

 
        (iii).  Deployment

                Because of (i). and (ii). above, SAs in BGP would have been
                impossible to deploy (who would want to deploy a
                version of BGP that carried SAs? MBGP with SAFI \in {1,2}
                was hard enough).
 

I have a question: If some provider is starting to deploy interdomain Multicast
from scratch ( anyone out there?), I'd think that it is far more attractive
to deploy MBGP based SA-advt since
1. MBGP is stable, widely deployed, and very well understood
2. MBGP can provide policy framework missing in MSDP ( and it is also
well understood)
3. No learning curve or additional time required to deploy one more
protocol like MSDP
4. MSDP implementations are more buggy compared to MBGP
5. MSDP is supposed to be only interim.

Any thoughts from the deployment side on this topic?

Thanks,
Nagesh

 

        There were a few other things, but these were the main concerns.
        BTW, what we were doing was attempting to find a way to free
        providers from having to co-locate their RPs on a dense-mode
        exchange point (i.e., get (S,G) state from outside their domain onto
        their RPs so their customers could join those groups, w/o sharing
        RPs). That was the (lost in the mist of history) design goal.

        Dave
 

According to Ali Boudani:
>
> > One reason: the timescales for change of active source indications are
> > much different than BGP was designed to carry.  BGP wants to carry
> > data that doesn't change very often, e.g. see route dampening.  Sources
> > can come and go at an arbitrary rate, so the rate of change of the
> > information is potentially much higher.
>
> can you specifie more,
> why should the timescales for change active source indications are much
> different.???
>
>