Subject: RE tunneling partner

From: [email-masked] (bob hayes)
Date: Fri, 10 May 1996 08:02:27 -0700

I have "[email-masked]" in a list for mci mbone contacts -
DISCLAIMER - "young" is from some forwarded email, and
may not be the person you need to talk to at all-- I
never have exchanged any email with them --

I have no direct experience with mci providing a tunnel,
but one of the catches is that it seems you are restricted from
feeding any other site through any line provided to you by mci ?!?

This seems to be a fairly major restriction or an 'encouragement'
to go to some other vendor? Is this a rational reduction of bandwidth
on a line or some sort of 'shift 'em into a higher tariff' method?
Seems like some of the business ploys were a restriction to only
one service vendor for all traffic, though, rather than a limit
on one particular protocol -- i'm fuzzy on this! 
Any comments on quality or policy? (NOT an invitation for flame wars!)

Bob Hayes	< [email-masked] >	
Western Washington University
Computer Science Dept., Bond Hall 302	Mail Stop 9062
Bellingham, Washington 98225
Obbligato Disclaimer: Tell `em Uncle Bob sez so!

---

From: "Jeff Young" <[email-masked]>
Date: Fri, 10 May 1996 12:20:13 -0400

the policy in question means that if you get a feed from mci
you agree not to clutter the mci backbone by either taking
another feed from a different organization via the same line,
or provide a feed to a different organization via the same 
line.  

there is nothing to say that you can't feed some other organization,
we just hope that you would do so via private connections.  if the
private connection happens to be a line provided to you by mci(the telco), 
so much the better.  if fact, a little deeper in the policy statement,
we ask that you feed your downstream networks.  perhaps i just need to
word the restriction more precisely.

we have a pretty extensive mbone infrastructure.  we have it because
we'd rather make the MCImbone heirarchical than anarchical.  it makes
sense for us to send one stream from denver to san francisco to feed
either city rather than allow n customers in denver to exchange mbone
traffic with m customers in san francisco.

Jeff Young
[email-masked]

> From: [email-masked] (bob hayes)
> Message-Id: <199605101502.IAA02073@reef>
> To: [email-masked]
> Subject: RE tunneling partner
> Sender: [email-masked]
> Precedence: bulk
> Content-Type: text
> Content-Length: 1045
>

---

From: "Matt Mathis" <[email-masked]>
Date: Sat, 11 May 1996 17:10:28 -0400

"[email-masked]" is correct.

MCI's policy is designed to help foster alignment between the topology
of the MBone and the topology of the Internet itself.   This is one
common bad habit that must be corrected before the MBone can grow
up and become real.

Consider this situation:
                                 Interconnect
       MCI                        /        \        ISP2
    -------------------------------        ------------------- 
    /  /  /  /          /                    \  \  \  \       \
    M1 M2 M3 M4 ....... Mn                   I1 I2 I3 I4 .... In
     (Customers of MCI)                       (Customers of ISP2)

Suppose that for most part all M* are fed from MCI and all I* from
ISP2.

Furthermore suppose that there is a tunnel from M1 to I1.
How does multicast get from M2 to I2?

If it goes M2->MCI->Interconnect->ISP2->I2, it has the property that
the BW profile along the path rises and falls with the degree of
aggregation..
If it goes M2->MCI->M1->MCI->Interconnect->ISP2->I1->ISP2->I2,
potential bottlenecks at M1&I1 can only hurt the overall path.
Suppose all M* and I* choose the M1-T1 tunnel?  Does this scale?
How about if MCI->Interconnect->ISP2 is OC3, and the aggregate load
from M* to I* is 2Mbits?   Can M1 and I1 handle the traffic?

MCI and ISP2 can cooperate to fix transit problems only if the path is
direct.
-------------

This is just one example of the many problems that arise if the
logical topology of the MBone doesn't agree with the physical topology
of the Internet as a whole.

MCI's approach is to discourage tunnels that go back out across MCI.
In my example above, one of the conditions for the MCI->M1 feed would
be to cut the M1 to I1 tunnel.

Here at PSC we had 4 non-compliant tunnels:
1) An MCI customer: MCI gave them a direct feed.
2) To another MCI customer that turned out to be running mrouted 2.2,
MCI refused to feed them without an upgrade.  When we realized that
they were 2.2, we er, also strongly requested that they upgrade,
because we didn't want to feed them either.
3) NASA at fix-w: We strongly encouraged Jeff Young to deal with fix-w
directly.
4) another site who was connected via ANS.  Our tunnel to them went to
timbukto and back, so they were happy to find a better feed.

All in all these changes were good for the MBone.  We try to
inductively apply the same policy to the local sites which we feed, but
we are hampered by the lack of a good specification.

Jeff and I iterated on some words, but the result wasn't really
satisfactory.

Quality?  Very good to many sites, very poor to others...

--MM--