FIX/NAP Connections (fwd)

Tue Feb 13 06:43:22 UTC 1996

please take to heart
so we can get real benefits
of multicast at the rather
strained interconnection points --

k

Forwarded message:
>From nobody  Mon Feb 12 13:52:53 1996
X-Mailer: exmh version 1.6.4 10/10/95
To: Peter Lothberg <roll at stupi.se>
Cc: Phil Dykstra <phil at arl.mil>, mbone at ISI.EDU
Subject: Re: FIX/NAP Connections 
In-Reply-To: Your message of "Sat, 10 Feb 1996 21:40:06 PST."
             <CMM.0.90.0.824017223.roll at Junk.Stupi.SE> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 12 Feb 1996 11:54:12 PST
From: Bill Fenner <fenner at parc.xerox.com>
Message-Id: <96Feb12.115421pst.177478 at crevenia.parc.xerox.com>

I would like to push for native peering rather than tunnels wherever possible. 
 Native peering allows the Ethernet/FDDI/whatever-physical-medium to do your 
packet replication for you, so instead of 10 tunnels to 10 providers meaning 
10 copies of each packet, you can have a single interface on a shared medium 
and have only one copy of each packet.

Now, this has its own expenses; if your existing routers don't support 
multicast (or don't support it well) then you need to put another 
two-interface box at the NAP & give it an interface on your router like Peter 
was describing.  My vision of how things might work is something like

                                                 T3 to provider A
                    _____________          ________/___
                    | A mrouter | -------- | A router | ---- Gigaswitch port
                    -------------          ------------
                     /        \
T1 to provider B    /          \                     T3 to provider C
____/____     _____/____    ____\_____          _______/___
|B Router| -- |B Mrouter|   |C Mrouter| ------- | C router | --- Gigaswitch 
port
---------     -------\---   --/--------         ------------
                      \______/

(I hate drawing ASCII diagrams).  Basically, there is a single FDDI ring 
(well, it could even be an ethernet, given the quantity of multicast traffic 
we are currently seeing) where each mrouter has an interface and everyone 
peers for multicast traffic.  Then each of these multicast routers has a 
private interface with the provider's unicast router in order to carry tunnels 
into the provider; this could also be an ethernet, because this box should 
only have one tunnel to the provider's internal multicast topology.

There is no real reason for the seperate subnet, other than isolation of 
resources, and assuming that the gigaswitch handles multicast properly.

This kind of thing is happening at MAE-East; PSI, Digex, Sprint and Sura are 
peering natively.  I would like to see it happen at every provider 
interconnect.

  Bill