Subject: Current thinking about MBONE across exchange points

From: Sean Donelan <[email-masked]>
Date: Fri, 16 May 1997 19:05:30 -0500

What is the current thinking for MBONE across shared media exchange
points.  Its been a while since I last peeked at the multicast traffic
at a NAP, my apologies if I got this wrong.  Now it appears to me
most providers are using multiple DVMRP tunnels on a bilateral basis.
Is this the current accepted practice?  I'm trying to figure out the
best position for my mrouters.

Thanks,
sean.

---

From: [email-masked] (Bill Manning)
Date: Fri, 16 May 1997 18:27:06 -0700 (PDT)

> best position for my mrouters.

I would think that it is a sub-optimal choice, although native PIM-SM
might actually be a good choice.

-- 
--bill

---

From: Petri Helenius <[email-masked]>
Date: Sat, 17 May 1997 06:50:32 +0300 (EEST)

> might actually be a good choice.

How do you propose to do PIM-SM between provides? Where would the RP
be?

Pete

---

From: John Meylor <[email-masked]>
Date: Fri, 16 May 1997 21:03:41 -0700

Sean Donelan wrote:

Sean, 
 I see your a MAE-West tenant, glad to help if I can.

arc1#trace SDG.DRA.COM
  1 mae-west.dra.net (198.32.136.86) 44 msec 12 msec 8 msec
  2 StLouis22-a2-1.dra.net (150.147.25.21) [AS 1746] 60 msec 60 msec 68
msec
  3 SDG.DRA.COM (192.65.218.29) [AS 1746] 72 msec 60 msec 136 msec

> points.  Its been a while since I last peeked at the multicast traffic

I believe your asking for a decription of what is actually
happening (as opposed to what we are striving to achieve).
We support dedicated mrouters on the FIX-West and MAE-West
exchange points so I can provide insight on this exchange.

On the MAE side the topology is gigaswitched, with
a current rate-limit for native mulicast on the switches which
is unusable. We are agressively looking for native solutions for
this side of the exchange.  Until then, we provide tunnels
from the MAE-W side of a dedicated, dual-homed mrouter. 
The mrouter is also attached to the FIX-West where it runs
native PIM-DM.  The mrouter is a Cisco 4700 and of therefore
can provide both GRE (to ciscos) and DVMRP mode
(to mrouted routers) tunnels. Most tunnels are using PIM-DM.
We configure ip dvmrp unicast routing for tunnels when requested
(eg. for ISPs needing to carry these routes internally).  Again
most currently utilize this approach.

Oh, BTW, we now also filter dvmrp default on all tunnels.  
Hopefully, appreciated by some out there :-)

> most providers are using multiple DVMRP tunnels on a bilateral basis.

By establishing the  dedicated
dual-homed mrouting point, we have offered a method for avoiding
a large mesh of tunnels. (I assume this is what you meant by
multiple, bilateral tunnels). If a tenant ISP establishes a tunnel to 
this mrouter, they get a one or two hop mroute to every other ISP
doing multicast on the FIX or MAE.  This of course will not scale
to all tenants and is why we're advocating native mrouting on
both sides. (We are running native multicast on the FIX-West).

> best position for my mrouters.

Call me and we can discuss some options.  We are always open to
ideas for advancing multicast on the exchange.

- John Meylor
Senior Network Engineer
NASA Research and Education Network
415-604-0353

---

From: "Jeff Young" <[email-masked]>
Date: Sat, 17 May 1997 11:29:29 -0400

would you need to elect an rp among the multiple providers?
what exactly does sparse mode exchange at a nap buy you unless
the providers who are a part of it are all running sparse
mode in their respective backbones?

Jeff Young
[email-masked]

> From: [email-masked] (Bill Manning)
> Message-Id: <[email-masked]>
> Subject: Re: Current thinking about MBONE across exchange points
> To: [email-masked] (Sean Donelan)
> Date: Fri, 16 May 1997 18:27:06 -0700 (PDT)
> Cc: [email-masked]
> 
> >

---

From: [email-masked] (Bill Manning)
Date: Sat, 17 May 1997 11:24:05 -0700 (PDT)

I said that PIM-SM might be the best choice if the constraints are
multicast between peers on a single L2 media.

If the media provider/maintainer provided an RP on the media,
and all participants selected sparse mode "edges", then this
might be the best choice. 
I am not sure that the attaching providers must run PIM-SM
within their infrastructures.

-- 
--bill

---

From: Petri Helenius <[email-masked]>
Date: Sun, 18 May 1997 22:17:11 +0300 (EEST)

> within their infrastructures.
No offense, but have you really thought trough what you are proposing?
PIM-SM in it's current incarnation does not really work inter-provider.
Pete

---

From: [email-masked] (Bill Manning)
Date: Sun, 18 May 1997 12:58:39 -0700 (PDT)

> PIM-SM in it's current incarnation does not really work inter-provider.

I think I've thought it through.  But before we go much further, you have to
define provider.  I expect that our assumptions here differ and therein
lies most of the concerns about bill losing what is left of his mind.

-- 
--bill

---

From: Petri Helenius <[email-masked]>
Date: Mon, 19 May 1997 07:43:29 +0300 (EEST)

> lies most of the concerns about bill losing what is left of his mind.
In my terms provider equals an ISP having internal multicast routing
infrastructure, possibly providing transit to other similar entities
and needs to have control over what's injected within their domain and
additionally no external event should break connectivity internal to
an ISP.

Pete

---

From: Mobasshar Ahmed <[email-masked]>
Date: Mon, 19 May 1997 11:15:57 +0000 (GMT)

> > might actually be a good choice.

If you are running it across an Exchange point, why not run it as dense
mode?

----------------------<i-Exchange   The Internet Peering Point>--------------
i-Exchange	http://www.i-exchange.co.uk
MBONE		http://www.i-exchange.co.uk/mbone
Tel:		++44-181-256-9990	Fax:	++44-181-288-0222

---

From: "David M. Meyer" <[email-masked]>
Date: Mon, 19 May 1997 06:43:32 -0700 (PDT)

Actually, there has been some work on this. 
	Check draft-ietf-mboned-imrp-some-issues-0x.txt

	Dave

---

From: "David M. Meyer" <[email-masked]>
Date: Mon, 19 May 1997 06:56:13 -0700 (PDT)

Bill,

> multicast between peers on a single L2 media.

	Since you say *might*, you statement also implies
	*might not*, so there isn't much to object to. However,
	if you you mean that sparse mode *is the best choice*,
	I'll have to disagree.

> might be the best choice. 

	This immediately implies third party resource dependencies
	(for the providers), and any provider participating in 
	this scenario will expose it's users to the the distant core/RP 
	problem. Finally, this implies a flat routing domain between 
	the provider and it's customers.

> within their infrastructures.

	Unless you modifiy PIM-DM and DVMRP to provide DWRs 
	(domin wide reports), then how will you support
	"recieve only" dense-mode domains? The point is
	that unless you have either DWRs (or "receiver-is-sender" 
	hack;  uses  the observation that even receivers sent RTP
	reports, etc), then you can't have SM region gluing DM regions
	together.

	Dave

---

From: [email-masked]
Date: Mon, 19 May 1997 07:13:57 -0700 (PDT)

> additionally no external event should break connectivity internal to

Ah... ok.  If you will willingly suspend disbelief and shift your view
point a bit...  What if the exchange point were considered a "provider"
that gives multicast transit to its clients?

-- 
--bill

---

From: [email-masked]
Date: Mon, 19 May 1997 07:18:16 -0700 (PDT)

> If you are running it across an Exchange point, why not run it as dense

Sure, just as long as you won't bill me for SVC creation for every multicast
session/hello that is created.  (there are exchanges built out of things
like ATM, which are a bunch of p2p links in a partial mesh.) multicast is
"messy" on such a fabric, particularly in the absence of good p2mp capability.
Hence the selection of SM.

--bill

---

From: [email-masked]
Date: Mon, 19 May 1997 07:39:30 -0700 (PDT)

> 	if you you mean that sparse mode *is the best choice*,

	I think the first choice is more correct.  My own belief is
	that neither PIM is quite right.

> 	the provider and it's customers.

	Sort of like the third party dependency on maintaining the L2 fabric
	intact no?  And there is, like it or not, a flat routing domain
	between the participants on the smae L2 fabric of an exchange.

> 	reports, etc), then you can't have SM region gluing DM regions

	There are already cisco supported "s-is-r" hacks in place.
	The other consideration for SM selection is the fact that
	some exchange points are really partial meshes built out of
	p2p links. In these exchange fabrics, there are costs associated
	with each call setup.  Hence DM or DVMRP are more costly to create
	and maintain.  I expect that unless the L2 fabrics "escape" from
	the ethernet/fddi game (and Gb. ethernet looks alot like more
	p2p stuff again..)

--bill

---

From: Petri Helenius <[email-masked]>
Date: Mon, 19 May 1997 17:44:59 +0300 (EEST)

> that gives multicast transit to its clients?

That would turn the current BGP peering model upside down or introduce
a single point of failure between AS's.

Pete

---

From: "David M. Meyer" <[email-masked]>
Date: Mon, 19 May 1997 08:27:39 -0700 (PDT)

Bill,

> 	intact no?  

	No. When I attach to the L2 fabric, I don't need to be sure 
	that some L3 provider, say P1, is functioning correctly so 
	that I can exchange unicast traffic with some other provider, 
	say P2. The PIM-SM v1 creates cases in which I will have
	to depend on P1 to deliver multicast trafffic to P2 (i.e.,
	in those cases in which P1 fields the RP for some group).
	This is true even if neither I nor P2 have a bilateral 
	(or other agreement) with P1.

> And there is, like it or not, a flat routing domain between 
> the participants on the smae L2 fabric of an exchange.

	Yes, but not between the participants in the same L2 
	fabiric *and* their customers, which is what the
	current incarnation on SM requires. Worse, it's
	not even the customers of the provider fielding the RP
	(that is, the RP space is flat). This is the different
	between what I have been calling "third-party resource
	dependency" and "distant core/RP problem". The first one
	effects the providers, the second affects users (and thus
	indirectly the providers).

> 	There are already cisco supported "s-is-r" hacks in place.

	Sure. That's what I said. But are you saying I have
	to run Cisco <X> (X like PIM-DM) if I want to run some 
	DM protocol as my multicast IGP because they've implemented
	some hack (i.e., I don't believe that mrouted has this hack; 
	someone correct me if I'm wrong)? In any event, the point is
	that if we want to generically support SM transit domains
	with arbitrary leaf domains, we need something "like" DWRs.

	BTW, this hack puts another requirement on receiver-only
	DM regions, namely, that receivers must be running an
	application that runs over RTP. This requirement is clearly
	unacceptable.

> 	the ethernet/fddi game (and Gb. ethernet looks alot like more

	You've mashed a couple of things here. First, there
	are issues in doing multicast on "true" p2p links, e.g., 
	that a router may have to do copying that is 
	O(number of multicast neightbors). On the other hand, if 
	the underlying L2 technology has some p2mp concept, you 
	might be able to exploit that (there are at least two 
	proposals for how to deal with this on ATM).

	Second, are you saying that some exchanges would allow me to set 
	up per-flow SVCs? If so, which ones? What is their chargning 
	model? Or maybe I implement this myself with PVP to some of 
	my neighbors? 
	
	In any case, I think I agree with what appears to be your 
	premise, namely, that "data driven approaches may not be 
	optimal in all cases". 

	Dave

---

From: John Hawkinson <[email-masked]>
Date: Mon, 19 May 1997 11:51:52 -0400 (EDT)

> that gives multicast transit to its clients?

No "client" (NSP) would want to lose multicast connectivity
because of a failure of a single "provider" (exchange).

Bill, if you are going to mince words and use unconventional definitions,
please don't ask the rest of us to state our explicitly and then tell
us what yours are -- please be forthright and open and state precisely
what you mean. Up to now you've been very unclear.

--jhawk

---

From: Mobasshar Ahmed <[email-masked]>
Date: Mon, 19 May 1997 16:01:36 +0000 (GMT)

---

From: [email-masked]
Date: Mon, 19 May 1997 09:16:08 -0700 (PDT)

> what you mean. Up to now you've been very unclear.

Hi,
	I've always postualted that an exchange is a form of provider.
	Quite a number of folks think I've lost my mind as a result,
	although I've seen other people with similar delusions, Deering,
	Li et.al. have even published along the same lines.

	When I see providers of partial mesh L2 infrastructure add
	L3 components then I don't think I'm that far off.  AADS is adding
	L3 services and the old NSF NAPs had the dependencies that Dave M.
	was talking about.  There were significant problems with no
	NLRI between points A and C, while there was NLRI between A and B
	and B and C.  
	These problems still exist, although the symptoms are currently 
	masked.  With the addition of many new L2 clients and the 
	need/desire to differentiate, you will see things like L3 support
	being added.  Things like nameservers, ntp/time service, perhaps
	even DHCP service.  Layered on top of these things are items like
	http and nntp caches. Thinking that multicast services won't be added
	to the mix is an act of denial.
	To constrain the problem to a fixed form of L2 capability is also
	an act of denial.  To think that ISPs won't take advantage of these
	services, if offered in a cost effective fashion, is insane.
	This is much like the old argument I had with Global Sprintlink
	(may it soul rest in peace) regarding the need for heirarchy.
	Any ISP can not expect to own the entire client base and do full
	up vertical support, from owning cable plant, equipment manufacturing,
	the infrastructure operations and client ownership. But I digress...

	I will have to thank Dave Meyer for stating the point much better
	than I could.  

--bill

---

From: Len Rose <[email-masked]>
Date: Mon, 19 May 1997 13:55:06 -0400 (EDT)

That's funny coming from someone who could only provide a read-only mbone
feed.

Len

[deleted]

> what you mean. Up to now you've been very unclear.

[email-masked]
http://www.netsys.com

---

From: John Hawkinson <[email-masked]>
Date: Mon, 19 May 1997 14:03:01 -0400 (EDT)

> That's funny coming from someone who could only provide a read-only mbone

Gee, Len, I don't know what you're referring to. Perhaps you could
be more explicit?

There was a time when I didn't deal with personal mail that you sent
me that I told you to send to [email-masked], but that's about
it.

If you have a complaint and choose to air it publically, please do so
with care, precision, and accuracy.

--jhawk

---

From: [email-masked]
Date: Mon, 19 May 1997 11:11:25 -0700 (PDT)

Um, excuse me. jhawk is someone I respect, as I have seen his chops.
His call for clarification is within bounds.  If you want something
for nothing, then don't be critical of what you get.

-- 
--bill

---

From: Len Rose <[email-masked]>
Date: Mon, 19 May 1997 14:22:19 -0400 (EDT)

Umm, I sent you (and mbone) alot of mail indicating a problem with 
the fact that no one on network was seeing our dvmrp routes.. It
was completely ignored.

I had to get a feed from cerf.net just to use the mbone.

Are you now saying you never saw any of this mail?

Len

> From [email-masked]  Mon May 19 14:03:03 1997
> Received: from all-purpose-gunk.near.net (all-purpose-gunk.near.net [199.94.220.184])
> 	by netsys.com (8.8.5/8.8.5-NETSYS) with ESMTP id OAA20349
> 	for <[email-masked]>; Mon, 19 May 1997 14:03:03 -0400 (EDT)
> Received: (from jhawk@localhost)
> 	by all-purpose-gunk.near.net (8.8.5/8.8.5) id OAA22628;
> 	Mon, 19 May 1997 14:03:01 -0400 (EDT)
> From: John Hawkinson <[email-masked]>
> Message-Id: <[email-masked]>
> To: [email-masked] (Len Rose)
> Date: Mon, 19 May 1997 14:03:01 -0400 (EDT)
> Cc: [email-masked]
> In-Reply-To: <[email-masked]> from "Len Rose" at May 19, 97 01:55:06 pm
> X-Mailer: ELM [version 2.4 PL25]
> MIME-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> 

[email-masked]
http://www.netsys.com

---

From: John Hawkinson <[email-masked]>
Date: Mon, 19 May 1997 14:57:53 -0400 (EDT)

(I don't really think [email-masked] is an appropriate place for this
discussion, at the very least, perhaps we could move to mbone-na?)

> the fact that no one on network was seeing our dvmrp routes.. It

It was not "completely ignored". I don't recall precisely, but I
believe there was some sort of global MBone problem at the time
(routing table explosion?) and the problem you were seeing was
initially thought to be related to it.

In any case, the fact that an operational problem prevented your
routes from being advertised should make the point of my message even
more real to you--that's certainly not a desirable state of affairs,
and single points of failure are to be avoided.

I suppose you may have issues with our response time; you did receive
multiple responses to your inquiries, however.

> I had to get a feed from cerf.net just to use the mbone.

After you stated that it didn't seem as if you were desirous of a
reply, so we didn't send one.

> Are you now saying you never saw any of this mail?

No, Len, I am only stating what I state explicitly.

--jhawk

---

From: "Carl Malamud [IMS]" <[email-masked]>
Date: Mon, 19 May 1997 16:42:13 -0400 (EDT)

> for nothing, then don't be critical of what you get.

Agreed.  My mbone feed worked very well for 12 months and jhawk
was extremely responsive.

Carl