Subject: Re: Why MSDP?

From: David Meyer <[email-masked]>
Date: Thu, 5 Apr 2001 08:55:32 -0700 (PDT)

Not sure about the history of this thread, but here's some
	of the history.

	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.

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

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

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

---

From: Ali Boudani <[email-masked]>
Date: Thu, 05 Apr 2001 17:28:04 +0200

can you specifie more,

---

From: Ali Boudani <[email-masked]>
Date: Thu, 05 Apr 2001 18:38:44 +0200

I think I didnt understand well the SA message.

In unicast (using BGP), a source can send messages without disturbing the BGP ,
so why isnt the case in MBGP??
and if we imagine that we are using PIM-SM shared tree, then it is the same as
unicast ?? (in some way).

what am I missing here?
thanx

---

From: Ali Boudani <[email-masked]>
Date: Thu, 05 Apr 2001 19:09:42 +0200

Hello,
I think I understand but just correct me if I am wrong.

the multicast topology advertised by MBGP is not the Trees but it is just
advertising the network reachability of the connected multicast routers. that
mean instead of advertising all the routes in a domain , we just advertise the
routes between multicast routers and subnetworks.
MBGP is not advertising the trees in the domains and that is why we should send
another kind messages when a source appers. because this source will construct a
new multicast tree in the domain using PIM-SM or other protocol.
Of course, MBGP like BGP cant support a lot of changes in the topology in a
domain and that is why , multicast trees (reachability) should not transported
via MBGP.
we should found something else (and that is why we are using MSDP)

Is that true? (I hope I am right :-) )

thanx
Ali

---

From: "Nagesh Chintada" <[email-masked]>
Date: Thu, 05 Apr 2001 13:39:03 -0400

>         Not sure about the history of this thread, but here's some

I  think you are addressing the core of this topic, which is, why we can't use
MBGP instead of MSDP.

>                 we had to somehow (attempt to) solve the bursty

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.

>                 of BGP (that is, of the global routing system). Neither

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)

>                 version of BGP that carried SAs? MBGP with SAFI \in {1,2}

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

---

From: Selina Priestley <[email-masked]>
Date: Thu, 05 Apr 2001 14:36:57 -0400

I am just learning about Multicast, so folks correct me if I am wrong:

I *believe* that MBGP carries the source networks that will be sending
multicast traffic (there is no tree because BGP is basically fancy
distance vector).  These networks are announced in MBGP whenever the 
sources associated network is up, whether the source is sending traffic 
or not.  This is used for reachability info only - how do I forward away 
from this source? or send joins/prunes toward the source?

MSDP is used to send information about specific sources, *when they
are actually sending traffic*.  This is used to start building trees
in the first place (assuming you have local receivers).  Then you use
the MBGP info to send your join to the source.

Networks are up for days, weeks, maybe even months.  Sources are sending
traffic for hours tops.

This may be what you're saying below, but I can't be sure.  :)

Selina

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 5 Apr 2001 15:25:25 -0500

Thus spake "Ali Boudani" <[email-masked]>
> advertising the network reachability of the connected multicast
routers.
> that mean instead of advertising all the routes in a domain , we just
> advertise the routes between multicast routers and subnetworks.

You're missing what MBGP does.  For mcast forwarding, all routers need
an RPF table.  Normally, the RPF table is identical to the unicast (BGP)
routing table; however, in some cases we want RPF and unicast to be
different.  For that, we have MBGP.

> Of course, MBGP like BGP cant support a lot of changes in the topology
> in a domain and that is why , multicast trees (reachability) should
not
> transported via MBGP.

Remember that the PIM-SM shared tree is limited to a single domain.  To
find sources outside your domain, you need a global shared tree; that's
the purpose of MSDP.

Think of the split between PIM and MSDP as similar to the split between
ISIS/OSPF/EIGRP/RIP and BGP -- we use different protocols within and
between routing domains.

S

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        Network Design Consultant, ANS
   :|||:      :|||:       RCDN2 in Richardson, TX
.:|||||||:..:|||||||:.    Email: [email-masked]

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 5 Apr 2001 15:27:01 -0500

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

BGP route advertisements are measured in days or months; MSDP source
advertisements are measured in seconds.

Also, the traffic patterns for the two are completely different.  BGP
only needs updates when networks (dis)connect to each other or when
there is a critical link failure -- things that are fairly rare and
relatively long-lived.  MSDP needs an SA for every new mcast flow
originated, and they can be as small as a single packet and rarely last
more than a few hours.

S

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 5 Apr 2001 14:14:53 -0700

>> ISIS/OSPF/EIGRP/RIP and BGP -- we use different protocols within and

    I wouldn't go that far.

Dino

---

From: Bill Nickless <[email-masked]>
Date: Thu, 05 Apr 2001 18:19:26 -0500

-----BEGIN PGP SIGNED MESSAGE-----

> >> ISIS/OSPF/EIGRP/RIP and BGP -- we use different protocols within and

Making sure I understand you here: MSDP is PIM-specific?

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     [email-masked]

---

From: Steve Simlo <[email-masked]>
Date: Fri, 06 Apr 2001 08:11:38 +0100

>Making sure I understand you here: MSDP is PIM-specific?

Correct - MSDP is PIM SM specific....from:

http://search.ietf.org/internet-drafts/draft-ietf-msdp-spec-08.txt

snip
The Multicast Source Discovery Protocol, MSDP, describes a mechanism
    to connect multiple PIM-SM domains together. Each PIM-SM domain uses
    its own independent RP(s) and does not have to depend on RPs in other
    domains.
snip

>-----BEGIN PGP SIGNATURE-----
>Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
>
>iQCVAwUBOsz9fqwgm7ipJDXBAQFBhwQAhl0FlwZhhXnvhQtGWVfBWlKIU+ZpAXDF
>3LsV3euohtrJPH1WZf78bF550WxgiHoxHxvWFsSZ25qczNqw/m63LcO81yN4r0qq
>3nLx03TdWVKzGlF61FqDYdjDsbe9wDk/XjFu9nyW3+57xVfxe193z0e0bp97k51l
>pOb9NDqmefg=
>=fwar
>-----END PGP SIGNATURE-----

Steve Simlo
Consulting Engineer
Cisco Systems Ltd
3 The Square
Stockley Park
Uxbridge
Middlesex UB11 1BN
United Kingdom

Direct Line: 		+44 20-8756 8435
Fax:			+44-20-8756 8099
GSM:    		+44 7802-608 318
Home Office Tel: 	+44 20-8767 5886

Email: 	[email-masked]
Internal 
URL: 	http://wwwin-emea/FieldInfo/Consult/General/team/PersInfo/ssimlo.htm

---

From: [email-masked] (Jeremy Hall)
Date: Fri, 6 Apr 2001 07:11:44 -0400 (EDT)

msdp could in theory be used to cross a pim-sm domain and connect two
dvmrp domains. The fact that no sane vendor has implemented this
functionality is beyond the scope of the definition of msdp.

_J

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 06 Apr 2001 11:59:45 -0400

Let me give this a try.

MBGP conveys information about the AS hop path that multicast traffic
should follow. It says that, for example, for us (here at AS 16517) to reach
171.70.89.102   =  dhcp-171-70-89-102.cisco.com

multicasttech-2>show ip mbgp 171.70.89.102
BGP routing table entry for 171.68.0.0/14, version 899674
Paths: (2 available, best #2, table NULL)
Flag: 0x208
  Advertised to non peer-group peers:
  192.168.1.2
  145 24 1239 109
    204.147.129.89 from 204.147.129.89 (204.147.128.136)
      Origin IGP, localpref 100, valid, external
      Community: 9503719
  1239 109
    160.81.38.225 from 160.81.38.225 (144.228.242.54)
      Origin IGP, metric 59, localpref 100, valid, external, best

So, for us to get multicast traffic from this IP address, we send the join to AS 1239 (Sprint).

You need MBGP as multicast traffic may need to follow a different route than
unicast traffic. This is the case here :

multicasttech-2>show ip bgp 171.70.89.102
BGP routing table entry for 171.68.0.0/14, version 5801427
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  192.168.1.2
  701 109
    157.130.46.53 from 157.130.46.53 (137.39.4.99)
      Origin IGP, localpref 100, valid, external, best
  1239 1239 1239 109
    160.81.38.225 from 160.81.38.225 (144.228.242.54)
      Origin IGP, metric 59, localpref 100, valid, external
multicasttech-2>

For unicast, our preferred route involves AS 701 (UUNET).

Now, this is ROUTING. Routing does not convey information about traffic - BGP does not
tell you if you have an email waiting. MBGP likewise does not tell you about sources.

MSDP involves SOURCE DISCOVERY.  We have
sources here in AS 16517. We also have an RP. Each of our sources informs our RP of
its existence. Our RP floods this info to our neighboring RP's, including the ones
in Sprint, and they tell the ones in Cisco.com. When  171.70.89.102 wants to
join one of our groups, which it did on Tuesday,   it sends an IGMP message which
triggers a PIM-SM join TO THE CISCO.COM RP. This RP knows about us,
and so it sends a join to our source directly.

The biggest advantage to this method is that you rely only on your RP for work. Since
you presumably pay for your RP, this is not a problem.

MSDP uses the MBGP routing info to only select SA messages  that come from the right
direction. (We, for example, would only accept CISCO.com SA messages that came through
Sprint.) These Reverse Path Forwarding (RPF) checks for MSDP will likely be relaxed
to make the system more robust - this was discussed a lot at the recent IETF.

SSM shoves the source discovery out of the protocol entirely. You find out sources by other
means (e-mail, webpage,...), and join the group and source directly. MSDP is not needed.

I hate to say it, but this discussion would be more appropriate on the IPMULTICAST
mailing list.

> Networks are up for days, weeks, maybe even months.  Sources are sending

Not correct, or at least, not always true.

Our sources have been up since October, 2000, and have had continuous multicast state
going out since early November, except for a few hours of downtime due to computer
problems. U Oregon and Broadcast.com, at least, have similar permanent groups.

> >Is that true? (I hope I am right :-) )

                                 Regards
                                 Marshall Eubanks

T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624
Fax     : 703-293-9609
e-mail : [email-masked]
http://www.on-the-i.com

Test your network for multicast : http://www.multicasttech.com/mt/