Subject: Re: mboned: I-D on overview of multicast routing

From: David Meyer <[email-masked]>
Date: Wed, 1 Dec 2004 08:35:30 -0800

Pekka,

	Nice work. Just a couple of comments:

	(i).	This should likely be Informational. BTW, it
		might be worthwhile to try to deprecate the term
		"MBGP". While you give the correct definition,
		many think it means "Multicast BGP". So there is
		some confusion here.
		
	(ii).	What would be nice is a little more of the
		history of how some of these things (e.g.,
		PIM-SM, BGMP, etc) came to be. 

	(iii).	Section 2.1.2

		"Regardless of features for having different
		topologies for unicast and multicast, commonly
		deployed networks have managed well without them
		by deploying multicast same unicast routers."

		Kinda hard to parse. What did you mean to say
		here? 

	(iv).	Section 2.1.3

		Yes, appendix.

	(v).	Section 2.2

		Regarding PIM-SM and learning active sources, it
		is not clear that the RP mechanism itself is
		"completely unscalable" (there are several
		techniques that could be used to achieve better
		scaling properties than centralized rendezvous
		model, which most of us agree is not scalable). 

		One comment: The reason that SPs didn't like the
		whole RP concept was not due to scaling but
		rather to what I called a "third party resource
		dependency". That is (before the advent of MSDP):
		"Shared tree protocols require one or more
		globally shared Rendezvous Points (RPs) [PIM-SM]
		or Cores [CBT]. The RP or Core effectively serves
		as the root of a group specific shared tree. Data
		is sent to the RP/Core for delivery on the shared
		tree. This means that some groups may have an RP
		(or core) that is fielded by a third party. For
		example, if providers A, B and C share a PIM-SM
		inter-domain region, then there may exist an RP
		that is mapped to C's multicast border router. In
		this case, C is hosting a kind of "transit RP"
		for A and B (A and B register to C to communicate
		between themselves, even if C has no receivers
		for the group(s) served by the RP."

		See http://www.1-4-5.net/~dmm//draft-ietf-mboned-imrp-some-issues-01.txt

		BTW, would folks like to see an update to this
		document? (the point being that many of the
		issues are still outstanding) 

	(v).	You might want to add something in (perhaps in
		section 2) about the mixing of control and data
		planes (i.e., as with bridging, some of control
		plane information is "learned" in the data plane
		(i.e., when you see a data packets).

	(vi).	You might also want to add something about the
		so-called "Bursty Source problem", perhaps in the
		section about PIM-SM (and/or MSDP). This is
		likely of interest if one wanted to understand
		the design decision to encapsulate some number of
		the initial data packets in the control plane,
		i.e., that it intended, at least in part, to
		solve the bursty source problem (although it
		broke things for the reliable multicast folks;
		which brings up the reliable multicast issue,
		which also isn't covered...). 

	(vii).	Section 2.3.2

		What really killed dense mode was (i). the state
		requirements (sounds a little strange now, given
		the advent of SSM), and (ii). the desire of SPs
		to use multicast to deliver high bandwith streams
		(e.g. multi-channel TV) over multicast; without
		some form of hierarchical encoding (or even with
		it), the flodding of unwanted high-bandwith
		streams to all customers wasn't going to be
		viable.

	(viii).	Section 2.3.5

		MOSPF was indeed implemented and deployed (so you
		might soften the text here a little). You might
		also add BGMP in this section.

	Dave

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Beau Williamson <[email-masked]>
Date: Wed, 01 Dec 2004 14:25:24 -0600

>                 streams to all customers wasn't going to be

IMHO, what killed DM was it's nearly total lack of deterministic behavior 
since it was so dependent on the data plane.  It still has corner cases 
where multicast route loops can be formed which swamp the network to the 
point that the unicast routing protocol can't converge and heal the route 
loop.  (I've actually seen this happen on a NY Stock Exchange Trading 
Floor. Talk about some unhappy people!)  In addition to this, the heavy 
dependency on the Assert mechanism can result in lengthy reconvergence times.

So when it comes to DM, I usually tell people to "Just say No!".

Now all of these problems might be solvable but no one has wanted to spend 
the cycles to rework the protocol.  Heck, if you were willing to run a 
specific multicast routing protocol and build Truncated-Broadcast Trees 
(TBT's) like in DVMRP, it might be possible to solve these issues.  Of 
course, that means another routing protocol and another route table.  Most 
people don't seem to want to go there (although there are exceptions to 
every rule).

Beau Williamson

---

From: Pekka Savola <[email-masked]>
Date: Wed, 1 Dec 2004 22:54:29 +0200 (EET)

Thanks for your comments.  Inline..

On Wed, 1 Dec 2004, David Meyer wrote:
> 	(i).	This should likely be Informational.

I was personally thinking of BCP (like the addrarch document), but 
Info would be OK as well.  Do you see any particulatly non-BCPish 
components here why BCP would seem inappropriate?

> BTW, it

I'll consider this; I've certainly seen it misused myself.

> 		PIM-SM, BGMP, etc) came to be.

I'll try to figure out it a bit more, but I'm not as privy to the 
history as the others, so I would have to try to glean that from 
Introduction sections of the other documents, guessing, etc. -- so in 
the end, we'll maybe need to try to coax the old-timers to submit some 
text ;-)

> 		Kinda hard to parse. What did you mean to say

I've reworded this in my draft based on off-list comment; this is 
probably clearer:

    It is worth noting that interdomain incongruence and intradomain
    incongruence are generally orthogonal, so one doesn't require the
    other.  Specifically, interdomain incongruence is quite common, while
    intradomain incongruence isn't, so you see much more deployments of
    MBGP than MT-ISIS/OSPF.  Commonly deployed networks have managed well
    without protocols handling intradomain congruence.

I.e., it's trying to say we've managed relatively well without MT-ISIS 
(for multicast), so the fact that those are implemented does not 
automatically mean there is a critical demand for them.

> 		Yes, appendix.

There has been input to the other direction as well, so let me 
consider and revisit this later if needed.

> 		model, which most of us agree is not scalable).

This was commented by Jean-Jacques as well.  By the ambiguous 'this', 
I was referring to having a single PIM domain (from BSR etc. 
perspective) for the whole Internet.  Will clarify.

> 		See http://www.1-4-5.net/~dmm//draft-ietf-mboned-imrp-some-issues-01.txt

With the MSDP model, I think this issue was fixed.

With Embedded-RP, it's back in some sense, though because the RP 
configuration is per-group, not per-domain, this is probably much, 
much smaller problem (if at all).

> 		issues are still outstanding)

Might be useful.  There's some overlap with the expired "gap analysis" 
document.  Not sure which would be the best way forward here.

> 		(i.e., when you see a data packets).

I think I understand which issues you're referring to, but could you 
elaborate a bit so I'm more certain?  In particular, while this is an 
issue as such, I'm not sure how this relates to the routing Info/BCP 
overview document?  (Maybe you'd like to spell out that if the 
deployment has requirements for not depending on data-driven events, 
it kind of limits the options .. but this is already there in some way 
under bidir-pim.)

> 		which also isn't covered...).

Agree that the reliable multicast stuff isn't there.  Maybe it should 
be, though I'm not really familiar with it.

The bursty source problem might be something that would belong in the 
"background/introduction" for a particular protocol (i.e., why it was 
designed like that).

We'll want to avoid getting too verbose here, though.

> 		streams to all customers wasn't going to be

OK, I'll try to use this and the bits from Beau to rev this.

> 		also add BGMP in this section.

BGMP added based on earlier comments.  Looks like (ospf WG minutes 
from '98) it was implemented at least by Bay, IBM, Ascent and 3com. 
I guess all of those are more or less gone already, but I'll soften 
the tone a bit..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: David Meyer <[email-masked]>
Date: Wed, 1 Dec 2004 16:25:57 -0800

>> people don't seem to want to go there (although there are exceptions to 

	Yep, no argument with the above. 

	Dave

---

From: David Meyer <[email-masked]>
Date: Wed, 1 Dec 2004 16:23:41 -0800

>> components here why BCP would seem inappropriate?

	Because it doesn't specify a "practice"?

>> the end, we'll maybe need to try to coax the old-timers to submit some 

	Or I can give you some. I'll try to get you something
	after I recover from a disk failure or 2 :-(
>>    without protocols handling intradomain congruence.

	ok.

>> consider and revisit this later if needed.

	Ok, not a big deal here...

>> >		See 
>> >		http://www.1-4-5.net/~dmm//draft-ietf-mboned-imrp-some-issues-01.txt
>> 

	Yep, that's why we built it (but it was our second try;
	first was to flood (DM) accros the exchange so that (S,G)
	state was created on the RP; the problem was that there
	wasn't any flexibility as to where you could put your
	RP).

>> document.  Not sure which would be the best way forward here.

	I'll look at doing something with it.

>> it kind of limits the options .. but this is already there in some way 

	Just that the "multicast routing protocol" isn't the only
	source of control plane information....

>> "background/introduction" for a particular protocol (i.e., why it was 

	Yep. Let me know if you need text.

>> I guess all of those are more or less gone already, but I'll soften 

	Thanks,

	Dave

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 02 Dec 2004 08:40:03 +0000

agree - another viewpoint (i think mark handley said this) is that
basically when you have a unicast routing problem, dense mode makes it
exponentially harder to debug - when you have a multicast routing
problem, it may be an unicast underdlying cause or a multicast problm,
so its doubly exponentially hard in dense mode, whereas sparse and
single source trees kind of relate to what the underlying unicast
oughta be doing anyhow so when they dont, the cause is more clear...

In missive <[email-masked]>, Beau Williams

 >>people don't seem to want to go there (although there are exceptions to 
 
i stil lbelieve that _eventually_ someone may want to deploy large
scale DM applications (eventually someones game is gonan scale beyond
server based), but til then, we dont have to solve this here, and can
leave it up to some cool PhD student (Deering version 3?) to do...

 cheers

   jon