idnits 2.17.1 

draft-ietf-mboned-mix-00.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** Looks like you're using RFC 2026 boilerplate.  This must be updated to
     follow RFC 3978/3979, as updated by RFC 4748.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  ** Missing expiration date.  The document expiration date should appear on
     the first and last page.

  ** The document seems to lack a 1id_guidelines paragraph about
     Internet-Drafts being working documents. 

  ** The document seems to lack a 1id_guidelines paragraph about 6 months
     document validity -- however, there's a paragraph with a matching
     beginning. Boilerplate error?

  ** The document seems to lack a 1id_guidelines paragraph about the list of
     current Internet-Drafts. 

  ** The document seems to lack a 1id_guidelines paragraph about the list of
     Shadow Directories. 

  == The page length should not exceed 58 lines per page, but there was 9
     longer pages, the longest (page 2) being 60 lines

  == It seems as if not all pages are separated by form feeds - found 0 form
     feeds but 11 pages


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack an Introduction section.
     (A line matching the expected section header was found, but with an
    unexpected indentation:
     '    1.  Introduction' )

  ** The document seems to lack a Security Considerations section.
     (A line matching the expected section header was found, but with an
    unexpected indentation:
     '    6.  Security Considerations' )

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)

  ** There are 51 instances of too long lines in the document, the longest
     one being 4 characters in excess of 72.

  ** The abstract seems to contain references ([MSDP], [PIM-DM], [DVMRP],
     [PIM-SM]), which it shouldn't.  Please replace those with straight
     textual mentions of the documents in question.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (May 1999) is 9113 days in the past.  Is this
     intentional?


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  -- Missing reference section? 'PIM-SM' on line 387 looks like a reference

  -- Missing reference section? 'MSDP' on line 397 looks like a reference

  -- Missing reference section? 'DVMRP' on line 374 looks like a reference

  -- Missing reference section? 'PIM-DM' on line 392 looks like a reference


     Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	 Mbone Deployment Working Group                  Hugh LaMaster
3	 INTERNET-DRAFT                                  Steve Shultz
4	 Category: Informational                         NASA ARC/NREN
5	 draft-ietf-mboned-mix-00.txt                    John Meylor
6	 Operations and Management Area                  David Meyer
7	 Internet Engineering Task Force                 Cisco Systems
8	 12 November 1998
9	 Expires May 1999

11	               Multicast-Friendly Internet Exchange (MIX)
12	                      <draft-ietf-mboned-mix-00.txt

14	 Status of this Memo

16	    This document is an Internet-Draft. Internet-Drafts are working
17	    documents of the Internet Engineering Task Force (IETF), its areas,
18	    and its working groups. Note that other groups may also distribute
19	    working documents as Internet-Drafts.

21	    Internet-Drafts are draft documents valid for a maximum of six months
22	    and may be updated, replaced, or obsoleted by other documents at any
23	    time. It is inappropriate to use Internet-Drafts as reference
24	    material or to cite them other than as ``work in progress.''

26	    To learn the current status of any Internet-Draft, please check the
27	    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
28	    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
29	    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
30	    ftp.isi.edu (US West Coast).

32	    Abstract

34	    This document describes an architecture for a Multicast-friendly
35	    Internet eXchange (MIX), and the actual implementation at the NASA
36	    Ames Research Center Federal Internet eXchange (FIX-West, or FIX).
37	    The MIX has three objectives: native IP multicast routing, scalable
38	    interdomain policy-based route exchange, and to allow a variety of

40	 <draft-ietf-mboned-mix-01.txt                                November 1998

42	    IGP protocols and topologies for intra-domain use. In support of
43	    these objectives, the MIX architecture defines the following
44	    components: a peer-peer routing protocol, a method for multicast
45	    forwarding, a method for exchanging information about active sources,
46	    and a medium which provides native multicast.  This document
47	    describes the protocols and configurations necessary to provide a
48	    current, working multicast-friendly internet exchange, or MIX.

50	    This memo is a product of the MBONE Deployment Working Group (MBONED)
51	    in the Operations and Management Area of the Internet Engineering
52	    Task Force. Submit comments to <mboned@ns.uoregon.edu or the
53	    authors.

55	    Copyright Notice

57	    Copyright (C) The Internet Society (1998).  All Rights Reserved.

59	    Acknowledgments

61	    Thanks to the NASA HPCC program for supporting the NREN staff portion
62	    of this project; thanks to William P. Jones of the NASA ARC Gateway
63	    Facility for making the gateway facility available for housing this
64	    project.

66	    1.  Introduction

68	    The MIX objective was to use current technology to implement a
69	    scalable, high-performance, efficient, native IP multicast
70	    architecture.

72	    Past experience at ARC, NASA WANs, and at FIX-West, had shown that
73	    mrouted/DVMRP "Mbone" tunnels were an inefficient of routing
74	    multicast through an exchange point.  Specifically, at FIX-West, the
75	    large number of tunnels often resulted in unicast traffic loads on

77	 <draft-ietf-mboned-mix-01.txt                                November 1998

79	    the FIX FDDI that were 10 times the underlying multicast load.  In
80	    addition, some WANs had multiple tunnels criss-crossing the same
81	    physical links, resulting in wasted WAN bandwidth.  And, the separate
82	    workstation and router infrastructure for the "Mbone" tunnels created
83	    numerous problems.  Maintenance of Unix system and tunnel
84	    configurations was often ad hoc, because some of the network
85	    operators lacked the necessary expertise.  And the hardware and
86	    software configuration and performance of the tunnel infrastructure
87	    was often out of step with the underlying router-based unicast
88	    structure. In addition, use of a single, shared, distance-vector IGP
89	    in the inter-domain space led to instability.

91	    Therefore, it was desired to implement a new multicast internet
92	    exchange from the ground up, using current technology, and
93	    significantly improving performance, efficiency, and reliability.

95	    Four elements were identified as being necessary for the MIX
96	    architecture in order to meet the objectives.  These were to define a
97	    peer-peer routing protocol, a method for multicast forwarding, a
98	    method for exchanging information about distant sources and groups,
99	    and a non-switched broadcast medium.

101	    NASA Ames Research Center hosts the Federal Internet eXchange (FIX-
102	    West, or, "the FIX") as well as hosting the Ames Internet eXchange
103	    (AIX), which is connected at high speed to the MAE-West, and, which
104	    also shares the same address space as the MAE-West. These facilities
105	    are co-located at the Ames Telecommunications Gateway Facility.  It
106	    was felt that this would be an excellent location to test the
107	    viability of the native multicast technologies. The Multicast-
108	    friendly Internet eXchange (MIX) is co-located adjacent to the FIX
109	    for easy access from the existing FIX routers.

111	    Choices were made for each element, and the MIX was implemented
112	    adjacent to the existing NASA ARC FIX gateway facility.  At the time
113	    of writing, there are eight direct participants in the MIX, peering
114	    and exchanging routes and multicast traffic natively, and the
115	    performance and reliability have already far exceeded the tunneled
116	    infrastructure the MIX replaced.

118	    2. Requirements and Technology

120	    In order to meet the objectives for this multicast exchange, all

122	 <draft-ietf-mboned-mix-01.txt                                November 1998

124	    peering partners had to agree mutually to standardize on the
125	    following four elements.  These are:

127	     - the protocol to be used for multicast route exchange
128	     - the method for performing multicast forwarding
129	     - the method for identifying active sources
130	     - the physical medium for the multicast exchange

132	    The elements chosen to implement the MIX were BGP4+ (also known as
133	    "MBGP") for routing and route exchange [BGP4+], PIM-DM and PIM-SM for
134	    multicast forwarding on the exchange, dense-mode flooding, and, the
135	    MSDP protocol for information on sources and groups, and, FDDI for
136	    the multicast medium.

138	    2.1 Routing

140	    Two of the objectives of the MIX were to provide an EGP for scalable
141	    interdomain policy-based route exchange, and to allow a variety of
142	    IGP protocols and topologies for intra-domain use.  As with unicast
143	    interdomain routing, BGP could be used as the EGP to exchange routes
144	    for multicast.  However, the unicast and multicast routing paths and
145	    policies would have to be completely congruent.  In practice, this is
146	    sometimes not the case.  It is possible, however, to take advantage
147	    of the extensions in BGP4+ to deal with these policy and path
148	    incongruencies.

150	    BGP4+ [BGP4+] describes extensions to (unicast) BGP that allow use of
151	    the existing BGP machinery to provide the necessary scalability,
152	    policy control, and route stability features and mechanisms to be
153	    applied to both unicast and multicast routes consistently.

155	    BGP4+ allows routes to be marked "unicast forwarding", "multicast
156	    forwarding", or "both unicast and multicast forwarding".  In this
157	    way, BGP4+ supports different multicast and unicast forwarding paths
158	    and policies.  This removes the dependency on unicast-only routing.

160	    The ability of BGP4+ to support separate paths and policies for
161	    multicast is important for meeting the objectives of the exchange in
162	    various ways.  It allows for a participant's multicast routing policy
163	    to be independent of its established unicast routing policy.  This is
164	    important in order that the exchange can support providers migrating
165	    to BGP4+ as an IDMR.  This is because it allows for the exchange of
166	    routes previously exchanged via DVMRP, even though those routes would
167	    not meet the existing unicast routing policy.  It allows for

169	 <draft-ietf-mboned-mix-01.txt                                November 1998

171	    different policy in the interim.  For example, routes may be
172	    exchanged for BGP4+ multicast forwarding even though they would not
173	    be permitted under existing unicast routing policy.  BGP4+ also
174	    provides for the possibility that even after full migration is
175	    complete, a separate multicast routing policy can be applied.

177	    The exchange architecture imposes no requirements on the IGP or the
178	    multicast forwarding protocol or topology used internal to an AS.

180	    2.2 Multicast Forwarding

182	    The first requirement for the multicast forwarding protocol is that
183	    it be able to use routes exchanged via BGP4+.  For this reason, PIM
184	    was selected.  For the MIX, PIM-Dense-Mode (PIM-DM) was selected
185	    initially for the mutually agreed upon multicast forwarding process.
186	    By flooding data using PIM-DM, it was possible to provide information
187	    about active sources to PIM-SM RP's co-located on the MIX.  Migration
188	    to PIM-Sparse-Mode (PIM-SM) with MSDP is underway.

190	    The use of PIM on a shared LAN has certain consequences. It is
191	    necessary for all MIX participants to agree on certain configuration
192	    conventions affecting PIM forwarding on multi-access LANs.  In
193	    particular, it is necessary to establish a standard protocol "metric
194	    preference" (also known as "distance" or process "precedence") to be
195	    used by all peers for the PIM Assert process, because the PIM Assert
196	    process [PIM-SM] uses the "metric preference" [PIM-SM] as a mechanism
197	    by which the multicast forwarder is chosen.  If all parties are not
198	    following the convention, there may be black holes, in which a route
199	    appears to be valid, but traffic does not flow, or, there may be
200	    multicast loops, which can have deleterious consequences.

202	    For the MIX, a standard set of metric preferences are applied to the
203	    BGP4+ routes as the convention for the PIM forwarding mechanism.

205	    2.3 Active Sources

207	    There are two current methods for distributing information about
208	    active sources to participating AS's.  The AS's may be dense-mode
209	    regions, or, they may contain PIM-SM RP's.  One method is to use
210	    dense-mode to flood data packets to dense-mode regions and to
211	    sparse-mode RPs co-located on the exchange.  The second method is to

213	 <draft-ietf-mboned-mix-01.txt                                November 1998

215	    use a protocol that allows each AS to share information about the
216	    sources contained within it.

218	    For the MIX, it was decided use dense-mode, and, all participating
219	    sparse-mode peers would co-locate their RP's on the router directly-
220	    connected to the MIX.

222	    Dense-mode, including PIM-DM, and (mrouted-based) DVMRP, uses data
223	    flooding to propagate information about active source-group or <S,G
224	    pairs throughout the global multicast routing world. Unwanted sources
225	    are pruned back, and are periodically re-flooded in order to fully
226	    refresh forwarding state in mrouters.  This is a simple and very
227	    reliable method of propagating information on source-group pairs, but
228	    the effectiveness of dense-mode depends upon reliable pruning, and
229	    flooding traffic to propagate <S,G information over WANs does not
230	    scale well.

232	    Recently, a new protocol, MSDP [MSDP] has been proposed that, when
233	    combined with PIM-SM, will allow independent AS's to share
234	    information about distant sources and groups without flooding.
235	    Instead of flooding all data, only <S,G information is flooded, and
236	    then, only to systems, such as PIM-SM RP's, which require the
237	    information.  MSDP allows each AS to choose its own mode, sparse or
238	    dense, and also to run its own sparse-mode region independent of all
239	    other sparse-mode regions.

241	    MSDP has now been deployed on many of the MIX routers, and some MIX-
242	    connected AS's are now running sparse-mode internally.  This
243	    deployment is ongoing, and is not yet complete.

245	    2.4 Medium

247	    The objective for the MIX medium was to provide support for native
248	    multicast among multiple peering partners.

250	    There exist a number of unresolved issues regarding use of layer-2
251	    switched media at interexchange points, and, until these issues are
252	    resolved, running native multicast on such media is problematic.

254	    Fortunately, BGP4+ permits unicast and multicast to be carried on
255	    different media, permitting a multicast medium to be used
256	    independently of the unicast medium.

258	    A FDDI concentrator was selected to provide the native multicast
259	    exchange medium. It was router-efficient, because it permitted the
260	    medium to do the multicast packet replication, with a single copy

262	 <draft-ietf-mboned-mix-01.txt                                November 1998

264	    from a router being replicated to all neighbors.  Using a simple
265	    broadcast medium eliminates the complexity of using a switch for
266	    multicast.  And FDDI was considered operationally convenient by most
267	    of the participants.  Unicast traffic continues to be routed over the
268	    existing unicast exchange media.

270	    3.  The NASA Ames Research Center Multicast-Friendly Internet
271	    Exchange

273	    The Ames Multicast-friendly Internet eXchange, or MIX, began with the
274	    first beta-test trials in March 1998, and became operational,
275	    exchanging BGP4+ routes externally and using BGP4+ between multiple
276	    AS's, in May 1998.  NREN implemented BGP4+ and internal BGP4+ and
277	    began trial external peerings in the same time frame, evolving from
278	    the first trials, to full deployment by October. As of October 1998,
279	    there were 8 AS's peering using BGP4+ and actively exchanging
280	    multicast on the MIX FDDI.  One of the AS's, AS10888, represents a
281	    multi-router virtual BGP4+ backbone, and a router within AS10888 has
282	    been located on the MIX by NREN, as a gateway router.  The physical
283	    and logical topologies are as follows:

285	                           AS10888---R----"MBone"
286	                                     |
287	                                MIX  |  multicast_exchange
288	                              ----------------
289	                                 /         \
290	                                /           \
291	                   bgp4+_peer---R             R---bgp4+_peer
292	                                \           /
293	                                 \         /
294	                               ---------------
295	                            FIX unicast_exchanges

297	    AS10888 acts as a transit AS to connect other multicast-friendly
298	    exchanges to the NASA ARC MIX.  It also acts as a gateway between
299	    the DVMRP-based "Mbone" and the BGP4+ area.

301	    4.  Topology, Architecture, and Special Considerations

303	 <draft-ietf-mboned-mix-01.txt                                November 1998

305	    BGP4+

307	     -PIM Asserts and Metric preference

309	    The PIM Assert mechanism requires that all routing protocols
310	    "compete" to see which router is allowed for forward onto the
311	    shared medium.  To first order, the protocol metric preference
312	    is used to determine the forwarder.  All MIX peers must coordinate
313	    routing protocol parameters so that one router does not inadvertantly
314	    win PIM asserts over a neighbor which has a functional path.
315	    This requires that BGP4+ routes have preference over other
316	    routes, such as BGP, OSPF, and DVMRP.  In particular,
317	    it was necessary to standardize protocol metric preferences,
318	    and give BGP4+ routes the lowest, preferred, dynamic routing
319	    protocol metric preferences.  For this reason, the standard
320	    set of BGP4+ metric preferences was chosen to be less than any
321	    other dynamic unicast routing protocol metric preferences.
322	    Any MIX routers which are using DVMRP must use a DVMRP metric
323	    preference higher than the BGP4+ metric preferences, rather than
324	    what many people have used previously as the DVMRP metric preference,
325	    of 0.

327	     -Default

329	    One transitional requirement is the necessity to have routes
330	    to "Mbone" sources, that is, sources within the global DVMRP
331	    routing region.  Currently, the mechanism used is to have
332	    a single router in AS10888 on the MIX originate MBGP default
333	    to all external peers.

335	    DVMRP routing

337	     -DVMRP route redistribution

339	    At present, all BGP4+ routes tagged with a particular community
340	    are redistributed at the MIX into DVMRP within AS10888.  This is
341	    to provide DVMRP region users access to sources originating
342	    within AS's that are being routed via BGP4+ exclusively.
343	    Unless a particular community string is set, it is
344	    assumed that redistribution is not desired.  In the reverse
345	    direction, instead of sending DVMRP routes into BGP4+,
346	    BGP4+ default is originated from the intermediary router.

348	    In addition, local, stub-region DVMRP routes are redistributed
349	    into BGP4+ internally by several of the peers.  As long as the
350	    regions remain stub regions, there is no danger, but, the
351	    possibility of a backdoor into the Mbone presents an ever-present

353	 <draft-ietf-mboned-mix-01.txt                                November 1998

355	    threat of loops unless care is taken to redistribute
356	    only the routes which are known to be owned within the AS.

358	    5.  Conclusions and Recommendations

360	     -Provide support for native multicast
361	     -Use BGP4+ as a method of exchanging routes for
362	      inter-domain multicast
363	     -Use PIM-DM, or PIM-SM with MSDP
364	     -Concurrent use of BGP4+ and DVMRP for inter-domain
365	      routing is not recommended.  It is strongly
366	      recommended to use BGP4+ for inter-domain route exchange.

368	    6.  Security Considerations

370	    There are no security considerations unique to the multicast exchange.

372	    7.  References

374	    [DVMRP]   T. Pusateri, "Distance Vector Multicast Routing
375	                 Protocol", <draft-ietf-idmr-dvmrp-v3-07.txt,
376	                 August 1998.

378	    [BGP4+]   T. Bates, R. Chandra, D. Katz, Y. Rekhter,
379	                 "Multiprotocol Extensions for BGP-4", RFC 2283,
380	                 February 1998.

382	    [BGP4+2]  T. Bates, R. Chandra, D. Katz, Y. Rekhter,
383	                 "Multiprotocol Extensions for BGP-4", Internet Draft,
384	                 <draft-ietf-idr-bgp4-multiprotocol-v2-01.txt,
385	                 August 1998.

387	    [PIM-SM]  D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering,
388	                 M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei,
389	                 "Protocol Independent Multicast-Sparse Mode (PIM-SM):
390	                 Protocol Specification", RFC 2362, June 1998.

392	    [PIM-DM]  S. Deering, D. Estrin, D. Farinacci, V. Jacobson, A. Helmy,
393	                 D. Meyer, L. Wei, "Protocol Independent Multicast
394	                 Version 2 Dense Mode Specification", Internet Draft,
395	                 <draft-ietf-pim-v2-dm-01.txt, November 1998.

397	    [MSDP]    D. Farinacci, Y. Rekhter, P. Lothberg, H. Kilmer, J. Hall,

399	 <draft-ietf-mboned-mix-01.txt                                November 1998

401	                 "Multicast Source Discovery Protocol (MSDP)",
402	                 <draft-farinacci-msdp-00.txt, June 1998.

404	    Author's Address

406	    Hugh LaMaster
407	    Steve Shultz
408	    NASA Ames Research Center
409	    Mail Stop 233-21
410	    Moffett Field, CA 94035-1000
411	    email: hlamaster@arc.nasa.gov
412	           shultz@arc.nasa.gov

414	    David Meyer
415	    John Meylor
416	    Cisco Systems
417	    San Jose, CA
418	    email: dmm@cisco.com
419	           jmeylor@cisco.com

421	    8.  Full Copyright Statement

423	    Copyright (C) The Internet Society (1998).  All Rights Reserved.

425	    This document and translations of it may be copied and furnished to
426	    others, and derivative works that comment on or otherwise explain it or
427	    assist in its implmentation may be prepared, copied, published and
428	    distributed, in whole or in part, without restriction of any kind,
429	    provided that the above copyright notice and this paragraph are included
430	    on all such copies and derivative works.  However, this document itself
431	    may not be modified in any way, such as by removing the copyright notice
432	    or references to the Internet Society or other Internet organizations,
433	    except as needed for the purpose of developing Internet standards in
434	    which case the procedures for copyrights defined in the Internet
435	    languages other than English.

437	    The limited permissions granted above are perpetual and will not be
438	    revoked by the Internet Society or its successors or assigns.

440	    This document and the information contained herein is provided on an "AS
441	    IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
442	    FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
443	    LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
444	    INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
445	    FITNESS FOR A PARTICULAR PURPOSE."

447	 <draft-ietf-mboned-mix-01.txt                                November 1998

449	    Table of Contents

451	    1 Introduction ....................................................    2
452	    2 Requirements and Technology .....................................    3
453	    3 The NASA Ames MIX ...............................................    7
454	    4 Topology, Architecture, and Special Considerations ..............    7
455	    5 Conclusions and Recommendations .................................    9
456	    6 Security Considerations .........................................    9
457	    7 References ......................................................    9
458	    8 Full Copyright Statement ........................................   10