From owner-idmr@cs.ucl.ac.uk Tue Feb 1 01:12:27 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26312 for ; Tue, 1 Feb 2000 01:12:08 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 1 Feb 2000 04:05:36 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 1 Feb 2000 04:05:32 +0000 Received: from ids2.idsonline.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 1 Feb 2000 04:06:00 +0000 Received: from 21rst-century.com (laurel-md-241.idsonline.com [209.8.42.241]) by ids2.idsonline.com (8.9.1/8.6.9) with ESMTP id AAA32103; Tue, 1 Feb 2000 00:14:56 -0500 Message-ID: <38965C47.E4A3699A@21rst-century.com> Date: Mon, 31 Jan 2000 23:08:43 -0500 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies LLC X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: idmr@cs.ucl.ac.uk Subject: Re: Multicast MIB References: <200001312232.OAA25774@dthaler.microsoft.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hello; Dave Thaler wrote: > The IESG feedback on the Multicast MIB was that we need IANA > guidelines on how to assign new values for unicast and multicast > routing protocols. Page 5 of RFC 2434 provides several possibilities, > including (see RFC for description): > Private Use > Hierarchical allocation > First Come First Served > Expert Review > Specification Required > IESG Approval > IETF Consensus > Standards Action > > Based on reviewing various existing IANA-maintained MIBs > and what they require, in my opinion, the "designated expert" > would work here, as might requiring RFCs. > > So to steal language from existing RFCs, here are two > strawmen (pick one, or suggest alternative): > > Alternative A (either "published documentation" or Expert): > > Any and all requests for additional values require > > proper and readily available documentation. Possible forms > > of documentation include, but are not limited to, RFCs. > > Other requests may also be accepted under the advice of a > > "designated expert". (Contact the IANA for the contact information > > of the current expert.)" > > Alternative B (always Expert): > > Any additions or changes to the contents of this MIB > > module require Designated Expert Review as defined in > > the Guidelines for Writing IANA Considerations Section > > document. The Designated Expert will be selected by > > the IESG Area Director of the Routing Area. > > Preferences? > > -Dave Why not require "proper and readily available documentation" as well as expert review ? Isn't this a good thing to require in any case ? In that case you could say Any additions or changes to the contents of this MIB module requires both proper and readily available documentation and Designated Expert Review (as defined in the Guidelines for Writing IANA Considerations Section document). The Designated Expert will be selected by the IESG Area Director of the Routing Area. The existence of proper documentation will be certified by the Designated Expert. (That way, any appropriate documentation could be submitted, as long as it would satisfy the DE.) -- Regards Marshall Eubanks T.M. Eubanks CTO Multicast Technologies, LLC P.O. Box 99 Clifton, Virginia 20124 Phone : 703-803-8141 Fax : 703-222-3250 e-mail : tme@21rst-century.com From owner-idmr@cs.ucl.ac.uk Wed Feb 2 09:26:02 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10266 for ; Wed, 2 Feb 2000 09:26:01 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 2 Feb 2000 11:35:09 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 2 Feb 2000 11:35:05 +0000 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 2 Feb 2000 11:35:29 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03041; Wed, 2 Feb 2000 06:35:26 -0500 (EST) Message-Id: <200002021135.GAA03041@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: idmr@cs.ucl.ac.uk From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idmr-igmp-mib-13.txt Date: Wed, 02 Feb 2000 06:35:26 -0500 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Multicast Routing Working Group of the IETF. Title : Internet Group Management Protocol MIB Author(s) : K. McCloghrie, D. Farinacci, D. Thaler Filename : draft-ietf-idmr-igmp-mib-13.txt Pages : 21 Date : 01-Feb-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-mib-13.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idmr-igmp-mib-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idmr-igmp-mib-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000201100636.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-igmp-mib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-igmp-mib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000201100636.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idmr@cs.ucl.ac.uk Wed Feb 2 09:30:46 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10513 for ; Wed, 2 Feb 2000 09:30:44 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 2 Feb 2000 11:35:28 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 2 Feb 2000 11:35:22 +0000 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 2 Feb 2000 11:35:34 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03055; Wed, 2 Feb 2000 06:35:31 -0500 (EST) Message-Id: <200002021135.GAA03055@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: idmr@cs.ucl.ac.uk From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idmr-pim-mib-10.txt Date: Wed, 02 Feb 2000 06:35:31 -0500 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Multicast Routing Working Group of the IETF. Title : Protocol Independent Multicast MIB for IPv4 Author(s) : K. McCloghrie, D. Farinacci, D. Thaler, B. Fenner Filename : draft-ietf-idmr-pim-mib-10.txt Pages : 32 Date : 01-Feb-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-pim-mib-10.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idmr-pim-mib-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idmr-pim-mib-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000201100647.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-pim-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-pim-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000201100647.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idmr@cs.ucl.ac.uk Wed Feb 2 18:10:55 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23357 for ; Wed, 2 Feb 2000 18:10:55 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 2 Feb 2000 20:10:36 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 2 Feb 2000 20:10:32 +0000 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 2 Feb 2000 20:11:00 +0000 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id A4A0C4CE0A; Wed, 2 Feb 2000 15:10:54 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA28929; Wed, 2 Feb 2000 15:10:53 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id MAA08158; Wed, 2 Feb 2000 12:10:50 -0800 (PST) Message-Id: <200002022010.MAA08158@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: tme@21rst-century.com Subject: Re: Multicast MIB Cc: dthaler@dthaler.microsoft.com, idmr@cs.ucl.ac.uk References: <200001312232.OAA25774@dthaler.microsoft.com> <38965C47.E4A3699A@21rst-century.com> Date: Wed, 2 Feb 2000 12:10:50 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >Why not require "proper and readily available documentation" as well as >expert review ? Isn't this a good thing to require in any case ? Well, the other option is to trust the IANA to know when an expert should be called in. This has the advantage of speeding up assignments that the IANA feels that it can handle itself. I'm personally in favor of what Dave called option A: > Any and all requests for additional values require > proper and readily available documentation. Possible forms > of documentation include, but are not limited to, RFCs. > Other requests may also be accepted under the advice of a > "designated expert". (Contact the IANA for the contact information > of the current expert.)" Do any other WG members have an opinion? Otherwise, as rough as it may be I think we have a rough consensus on option A. Bill From owner-idmr@cs.ucl.ac.uk Fri Feb 4 16:48:19 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11129 for ; Fri, 4 Feb 2000 16:48:12 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 4 Feb 2000 19:17:36 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 4 Feb 2000 19:17:14 +0000 Received: from PPPa10-ResaleDenver8001-1R1010.saturn.bbn.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 4 Feb 2000 19:17:35 +0000 From: mpss5 Subject: ADV: Stock Portfolio 2000 February Profile Date: Fri, 4 Feb 2000 09:41:50 Message-Id: <560.532358.41036@www.alltheplanet.com> Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Apparently-To: idmr-pp Hello and welcome to the Stock Portfolio 2000 Newsletter. If you no longer wish to receive this free newsletter, please visit http://63.86.208.131/remove.html For more information, please visit http://63.86.208.131 or call toll free 888-323-0856. The greatest thing about the Internet is that it is the great equalizer in business and information resources. Look at the easiest example, a small website, which has now grown into an industry leader, started to sell books. They became so big so quickly that they made the industry leader in book sales change how and where they do business. The same is happening in all fields of business especially the music industry. More musicians than ever are getting broader exposure to new audiences that they could never reach before. The most innovative website on the music scene is MPEG Super Site, Inc. MPEG Super Site, Inc. is a dynamic, comprehensive, music website that will be the measuring stick for all future websites. Utilizing the company's vast experience in the music industry, MPEG Super Site, Inc. will be an independent record label on the Internet, discovering, developing and promoting new artists in all the major genres of music. MPEG Super Site, Inc. is committed to signing the artists who have the ability to fulfill the niche market of the Internet generation. MPEG Super Site Inc. puts people who are hungry for new music in touch with free downloadable music, exclusive music news, concert information and album reviews on today's hottest musical acts. They also will have state of the art webcasts of special events on a global scale and a forum for direct interaction between artist and fan base. The MPEG Super Site will be user friendly for those who are new to the Internet. It will be sophisticated for the hardcore user. MPEG Super Site, Inc. is poised to redefine the way we purchase and listen to music into the next millennium. MPEG Super Site, Inc. will compliment its Internet development with more traditional lines of business. A full service management company, MPEG represents both new and established musical artists, television and motion picture directors and choreographers, songwriters, producers and celebrities. As a rising force in film production, MPEG Super Site, Inc. is currently evaluating several production deals with high profile, established production companies for both television and theatrical release. MPEG Super Site, Inc. is a booking agent for several major entertainment venues in Las Vegas and Atlantic City. The company plans to support the sales of music CD's via the Internet with traditional record distribution. The company has an agreement in place with several international distributors. MPEG Super Site, Inc. is clearly the cutting edge of the entertainment industry. At the present time no other entity brings together the product, the talent, the experience and the total package to the Internet industry like MPEG Super Site, Inc. The Future of entertainment is through computers and the Internet. One company will emerge as the industry leader and take us into the next century of entertainment. The company that is positioned and poised to do so is MPEG Super Site, Inc. Once again please visit http://63.86.208.131 or call toll free 888-323-0856. Disclaimer ---------- This material is being provided by Stock Portfolio 2000, an electronic newsletter paid by the issuer for publishing the information contained in this report. Euro Media, Inc. has paid a consideration of 25,000 free trading shares of common stock of MPEG Super Site, Inc. to Stock Portfolio 2000 as payment for the publication of the information contained in this report. Stock Portfolio 2000 and its affiliates have agreed not to sell the common stock received as payment for its services until January 27, 2000, which date is 10 days from the initial dissemination of this report. After such date, Stock Portfolio 2000 may sell such shares in spite of any historical, current or future report or information conveyed about such securities. Because Stock Portfolio 2000 is paid for its services, there is an inherent conflict of interest in Stock Portfolio 2000's statements and opinions and such statements and opinions cannot be considered independent. The information contained in this publication is for informational purposes only, and not to be construed as an offer to sell or solicitation of an offer to buy any security. Please be advised that MPEG Super Site, Inc. is not offering securities for sale to persons in California or Minnesota. Stock Portfolio 2000 makes no representation or warranty relating to the validity of the facts presented nor does Stock Portfolio 2000 represent or warrant that all material facts necessary to make an investment decision are presented above. All statements of opinions are those of Stock Portfolio 2000. Stock Portfolio 2000 relies exclusively on information gathered from public filings on featured companies, as well as, in certain circumstances, interviews conducted by Stock Portfolio 2000 of management of featured companies. Investors should not rely solely on the information contained in this publication. Rather, investors should use the information contained in this publication as a starting point for conducting additional research on the featured companies in order to allow the investor to form his or her own opinion regarding the featured companies. Factual statements contained in this publication are made as of the date stated and they are subject to change without notice. Stock Portfolio 2000 is not a registered investment adviser, broker or a dealer. Investment in the companies reviewed is speculative and extremely high-risk and may result in the loss of some or all of any investment made in MPEG Super Site, Inc. Projections of future financial results are provided solely by MPEG Super Site, Inc. No assurances are given that MPEG Super Site, Inc. will achieve said projections. This publication contains forward-looking statements that are subject to risk and uncertainties that could cause results to differ materially from those set forth in the forward-looking statements. These forward-looking statements represent the judgment of MPEG Super Site, Inc. as of the date of this publication. The Company disclaims any intent or obligation to update these forward-looking statements. From owner-idmr@cs.ucl.ac.uk Mon Feb 7 18:47:26 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24332 for ; Mon, 7 Feb 2000 18:47:25 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 7 Feb 2000 21:03:33 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 7 Feb 2000 21:03:29 +0000 Received: from bacardi.torrentnet.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 7 Feb 2000 21:03:57 +0000 Received: from bacardi.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by bacardi.torrentnet.com (8.9.2/8.9.2) with ESMTP id QAA27274 for ; Mon, 7 Feb 2000 16:03:55 -0500 (EST) Message-Id: <200002072103.QAA27274@bacardi.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: idmr@cs.ucl.ac.uk Subject: Question on MBGP. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Feb 2000 16:03:55 -0500 From: Chirayu Shah Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi, I had a MBGP-deployment question. It seems that for receivers in a PIM domain which is a part of an AS to be able to receive traffic from sources external to the AS, it is necessary to run IMBGP on all the routers in the AS. Is this correct? Is there any other way in which one can receive MBGP routes on a router within a PIM domain without having to run IMBGP on it? I believe it is not possible to export MBGP routes into OSPF/RIP because it would be difficult to differentiate between BGP and MBGP routes (assuming that BGP and MBGP topologies are incongruent). Chirayu Shah Software Engineer. Ericsson IP Infrastructure 12120 Plum Orchard Dr Suite A Silver Spring, MD 20904. From owner-idmr@cs.ucl.ac.uk Mon Feb 7 18:48:34 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24368 for ; Mon, 7 Feb 2000 18:48:33 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 7 Feb 2000 23:22:21 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 7 Feb 2000 23:22:16 +0000 Received: from wodc7-2.corprelay.mail.uu.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 7 Feb 2000 23:22:45 +0000 Received: from neserve0.corp.us.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.201.88]) id QQibkv15638; Mon, 7 Feb 2000 23:22:44 GMT Received: by neserve0.corp.us.uu.net id QQibkv10319; Mon, 7 Feb 2000 18:22:42 -0500 (EST) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: Question on MBGP. In-Reply-To: <200002072103.QAA27274@bacardi.torrentnet.com> from Chirayu Shah at "Feb 7, 2000 04:03:55 pm" To: Chirayu Shah Date: Mon, 7 Feb 2000 18:22:42 -0500 (EST) CC: idmr@cs.ucl.ac.uk X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit yes, traditionally, we deploy IMBGP just like we deploy IBGP. We do NOT under ANY circumstances mix the multicast nlri with unicast nlri in a routing protocol. Such a mix would cause DESASTEROUS consequences. Also, deploy MSDP between the domains on EMBGP boundaries. _J In the new year, Chirayu Shah wrote: > > Hi, > I had a MBGP-deployment question. It seems that for receivers > in a PIM domain which is a part of an AS to be able to > receive traffic from sources external to the AS, it is necessary to run > IMBGP on all the routers in the AS. Is this correct? Is there any > other way in which one can receive MBGP routes on a router within a PIM > domain without having to run IMBGP on it? I believe it is not > possible to export MBGP routes into OSPF/RIP because it would be difficult > to differentiate between BGP and MBGP routes (assuming that > BGP and MBGP topologies are incongruent). > > > Chirayu Shah > Software Engineer. > Ericsson IP Infrastructure > 12120 Plum Orchard Dr > Suite A > Silver Spring, MD 20904. > From owner-idmr@cs.ucl.ac.uk Mon Feb 7 21:34:00 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25563 for ; Mon, 7 Feb 2000 21:33:59 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 8 Feb 2000 01:42:48 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 8 Feb 2000 01:42:43 +0000 Received: from mailfw2.ford.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 8 Feb 2000 01:43:11 +0000 Received: by mailfw2.ford.com id UAA02296 (InterLock SMTP Gateway 4.2 for idmr@cs.ucl.ac.uk); Mon, 7 Feb 2000 20:42:53 -0500 Message-Id: <200002080142.UAA02296@mailfw2.ford.com> Received: by mailfw2.ford.com (Internal Mail Agent-1); Mon, 7 Feb 2000 20:42:53 -0500 From: "Houdek, Stephen (S.W.)" To: idmr@cs.ucl.ac.uk Subject: Question on MS-DS Mroute Date: Mon, 7 Feb 2000 20:42:51 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="windows-1252" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Take a look at the following mroute.....(from my RP). (*, 224.0.1.24), 09:27:02/00:02:54, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/0/0.58, Forward/Sparse-Dense, 09:27:02/00:00:00 GigabitEthernet9/0/0.112, Forward/Sparse-Dense, 09:20:46/00:00:00 GigabitEthernet9/0/1, Forward/Sparse-Dense, 09:20:29/00:00:00 Can someone clue me into what Microsoft-DS does? Who are the listeners to this group? What are the dynamics of the application? Is it one to one, one to many?? This showed up unexpectedly and I am trying to figure out what impact (if any) it may have in my network. Thanks in advance for your help! Stephen W. Houdek shoudek@ford.com (313) 845-4128 (313) 845-2491 -----Original Message----- From: Chirayu Shah [mailto:cshah@torrentnet.com] Sent: Monday, February 07, 2000 4:04 PM To: idmr@cs.ucl.ac.uk Subject: Question on MBGP. Hi, I had a MBGP-deployment question. It seems that for receivers in a PIM domain which is a part of an AS to be able to receive traffic from sources external to the AS, it is necessary to run IMBGP on all the routers in the AS. Is this correct? Is there any other way in which one can receive MBGP routes on a router within a PIM domain without having to run IMBGP on it? I believe it is not possible to export MBGP routes into OSPF/RIP because it would be difficult to differentiate between BGP and MBGP routes (assuming that BGP and MBGP topologies are incongruent). Chirayu Shah Software Engineer. Ericsson IP Infrastructure 12120 Plum Orchard Dr Suite A Silver Spring, MD 20904. From owner-idmr@cs.ucl.ac.uk Mon Feb 7 21:39:01 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25618 for ; Mon, 7 Feb 2000 21:39:00 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 8 Feb 2000 00:31:40 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 8 Feb 2000 00:31:36 +0000 Received: from ntserver1.redstonecom.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 8 Feb 2000 00:32:05 +0000 Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21) id <1LLSNZB0>; Mon, 7 Feb 2000 19:31:58 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C05B1F0@uniwest1.redstonecom.com> From: "Shekhar, Ravi" To: Chirayu Shah , idmr@cs.ucl.ac.uk Subject: RE: Question on MBGP. Date: Mon, 7 Feb 2000 19:31:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Chirayu, If the MSDP speakers in the PIM domain create a stub domain with respect to MBGP topology, I guess one can configure MSDP mesh-group between the MSDP speakers. Other way would be to implement new LSAs using Opaque OSPF LSAs. But I dont know of any such implementation. Regards. - Ravi Shekhar. > > > Hi, > I had a MBGP-deployment question. It seems that for receivers > in a PIM domain which is a part of an AS to be able to > receive traffic from sources external to the AS, it is > necessary to run > IMBGP on all the routers in the AS. Is this correct? Is there any > other way in which one can receive MBGP routes on a router > within a PIM > domain without having to run IMBGP on it? I believe it is not > possible to export MBGP routes into OSPF/RIP because it would > be difficult > to differentiate between BGP and MBGP routes (assuming that > BGP and MBGP topologies are incongruent). > > > Chirayu Shah > Software Engineer. > Ericsson IP Infrastructure > 12120 Plum Orchard Dr > Suite A > Silver Spring, MD 20904. > From owner-idmr@cs.ucl.ac.uk Tue Feb 8 04:02:12 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12673 for ; Tue, 8 Feb 2000 04:02:10 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 8 Feb 2000 07:04:50 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 8 Feb 2000 07:04:46 +0000 Received: from mailfw3.ford.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 8 Feb 2000 07:05:14 +0000 Received: by mailfw3.ford.com id CAA29297 (InterLock SMTP Gateway 4.2 for idmr@cs.ucl.ac.uk); Tue, 8 Feb 2000 02:05:09 -0500 Message-Id: <200002080705.CAA29297@mailfw3.ford.com> Received: by mailfw3.ford.com (Internal Mail Agent-1); Tue, 8 Feb 2000 02:05:09 -0500 From: "Houdek, Stephen (S.W.)" To: "'jhall@UU.NET'" Cc: idmr@cs.ucl.ac.uk Subject: RE: Question on MS-DS Mroute Date: Tue, 8 Feb 2000 02:05:08 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="windows-1252" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Yes, there is a connected IGMP member. Interestingly enough it turns out to be the same Video server (MS-W2K) we have setup to pilot Video multicast. Stephen W. Houdek shoudek@ford.com (313) 845-4128 (313) 845-2491 -----Original Message----- From: jhall@UU.NET [mailto:jhall@UU.NET] Sent: Tuesday, February 08, 2000 1:58 AM To: Houdek, Stephen (S.W.) Cc: idmr@cs.ucl.ac.uk Subject: Re: Question on MS-DS Mroute hmm it's a dense group, you have joined the SPT, and you have connected IGMP members (I think) or you are joined to a pim / dvmrp border. _J In the new year, Houdek, Stephen (S.W.) wrote: > Take a look at the following mroute.....(from my RP). > > (*, 224.0.1.24), 09:27:02/00:02:54, RP 0.0.0.0, flags: DJC > Incoming interface: Null, RPF nbr 0.0.0.0 > Outgoing interface list: > GigabitEthernet0/0/0.58, Forward/Sparse-Dense, 09:27:02/00:00:00 > GigabitEthernet9/0/0.112, Forward/Sparse-Dense, 09:20:46/00:00:00 > GigabitEthernet9/0/1, Forward/Sparse-Dense, 09:20:29/00:00:00 > > > Can someone clue me into what Microsoft-DS does? Who are the listeners to > this group? What are the dynamics of the application? Is it one to one, > one to many?? This showed up unexpectedly and I am trying to figure out > what impact (if any) it may have in my network. > > Thanks in advance for your help! > > Stephen W. Houdek > shoudek@ford.com > (313) 845-4128 > (313) 845-2491 > > > -----Original Message----- > From: Chirayu Shah [mailto:cshah@torrentnet.com] > Sent: Monday, February 07, 2000 4:04 PM > To: idmr@cs.ucl.ac.uk > Subject: Question on MBGP. > > > > Hi, > I had a MBGP-deployment question. It seems that for receivers > in a PIM domain which is a part of an AS to be able to > receive traffic from sources external to the AS, it is necessary to run > IMBGP on all the routers in the AS. Is this correct? Is there any > other way in which one can receive MBGP routes on a router within a PIM > domain without having to run IMBGP on it? I believe it is not > possible to export MBGP routes into OSPF/RIP because it would be difficult > to differentiate between BGP and MBGP routes (assuming that > BGP and MBGP topologies are incongruent). > > > Chirayu Shah > Software Engineer. > Ericsson IP Infrastructure > 12120 Plum Orchard Dr > Suite A > Silver Spring, MD 20904. > From owner-idmr@cs.ucl.ac.uk Tue Feb 8 04:03:28 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12706 for ; Tue, 8 Feb 2000 04:03:27 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 8 Feb 2000 06:57:49 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 8 Feb 2000 06:57:45 +0000 Received: from wodc7-1.corprelay.mail.uu.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 8 Feb 2000 06:58:13 +0000 Received: from neserve0.corp.us.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.203.88]) id QQiblz03676; Tue, 8 Feb 2000 06:58:12 GMT Received: by neserve0.corp.us.uu.net id QQiblz16611; Tue, 8 Feb 2000 01:58:10 -0500 (EST) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: Question on MS-DS Mroute In-Reply-To: <200002080142.UAA02296@mailfw2.ford.com> from "Houdek, Stephen (S.W.)" at "Feb 7, 2000 08:42:51 pm" To: "Houdek, Stephen (S.W.)" Date: Tue, 8 Feb 2000 01:58:10 -0500 (EST) CC: idmr@cs.ucl.ac.uk X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit hmm it's a dense group, you have joined the SPT, and you have connected IGMP members (I think) or you are joined to a pim / dvmrp border. _J In the new year, Houdek, Stephen (S.W.) wrote: > Take a look at the following mroute.....(from my RP). > > (*, 224.0.1.24), 09:27:02/00:02:54, RP 0.0.0.0, flags: DJC > Incoming interface: Null, RPF nbr 0.0.0.0 > Outgoing interface list: > GigabitEthernet0/0/0.58, Forward/Sparse-Dense, 09:27:02/00:00:00 > GigabitEthernet9/0/0.112, Forward/Sparse-Dense, 09:20:46/00:00:00 > GigabitEthernet9/0/1, Forward/Sparse-Dense, 09:20:29/00:00:00 > > > Can someone clue me into what Microsoft-DS does? Who are the listeners to > this group? What are the dynamics of the application? Is it one to one, > one to many?? This showed up unexpectedly and I am trying to figure out > what impact (if any) it may have in my network. > > Thanks in advance for your help! > > Stephen W. Houdek > shoudek@ford.com > (313) 845-4128 > (313) 845-2491 > > > -----Original Message----- > From: Chirayu Shah [mailto:cshah@torrentnet.com] > Sent: Monday, February 07, 2000 4:04 PM > To: idmr@cs.ucl.ac.uk > Subject: Question on MBGP. > > > > Hi, > I had a MBGP-deployment question. It seems that for receivers > in a PIM domain which is a part of an AS to be able to > receive traffic from sources external to the AS, it is necessary to run > IMBGP on all the routers in the AS. Is this correct? Is there any > other way in which one can receive MBGP routes on a router within a PIM > domain without having to run IMBGP on it? I believe it is not > possible to export MBGP routes into OSPF/RIP because it would be difficult > to differentiate between BGP and MBGP routes (assuming that > BGP and MBGP topologies are incongruent). > > > Chirayu Shah > Software Engineer. > Ericsson IP Infrastructure > 12120 Plum Orchard Dr > Suite A > Silver Spring, MD 20904. > From owner-idmr@cs.ucl.ac.uk Wed Feb 9 14:23:53 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18569 for ; Wed, 9 Feb 2000 14:23:52 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 9 Feb 2000 16:41:33 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 9 Feb 2000 16:41:29 +0000 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 9 Feb 2000 16:41:58 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10025; Wed, 9 Feb 2000 11:41:52 -0500 (EST) Message-Id: <200002091641.LAA10025@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: idmr@cs.ucl.ac.uk From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idmr-multicast-routmib-13.txt Date: Wed, 09 Feb 2000 11:41:52 -0500 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Multicast Routing Working Group of the IETF. Title : IPv4 Multicast Routing MIB Author(s) : K. McCloghrie, D. Farinacci, D. Thaler Filename : draft-ietf-idmr-multicast-routmib-13.txt Pages : 33 Date : 08-Feb-00 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing IP Multicast Routing for IPv4, independent of the specific multicast routing protocol in use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-multicast-routmib-13.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idmr-multicast-routmib-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idmr-multicast-routmib-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000208135239.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-multicast-routmib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-multicast-routmib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000208135239.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idmr@cs.ucl.ac.uk Mon Feb 14 22:22:16 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02872 for ; Mon, 14 Feb 2000 22:22:15 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 15 Feb 2000 00:58:21 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 15 Feb 2000 00:58:17 +0000 Received: from hercules.cs.ucsb.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 15 Feb 2000 00:58:35 +0000 Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id QAA20791 for ; Mon, 14 Feb 2000 16:58:32 -0800 (PST) Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4) id QAA06515 for idmr@cs.ucl.ac.uk; Mon, 14 Feb 2000 16:58:30 -0800 (PST) Date: Mon, 14 Feb 2000 16:58:30 -0800 (PST) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <200002150058.QAA06515@jackson.cs.ucsb.edu> To: idmr@cs.ucl.ac.uk Subject: multi-homing and load balancing Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk I'm having an interesting configuration problem that I'd like some advice on. My network looks like the following: ____ ___ |DR| |R| ---- --- ! ! ------------------------ ! --- |H| --- This is a straightforward, multi-homed network and the designated router, DR, is the left router. The fundamental question is whether there is any way to get multicast traffic to flow through the non-DR. * My sense is, there is no easy way. Because IGMP msgs go to the DR the DR initiates the join toward the RP/source. Now here is a sneaky hack: * If I can assign different addresses to the SOURCES. Set routing so that the ONLY path to the source is through the non-DR. * This way, when the DR gets the join, it sends the join back over the LAN and to the non-DR router who now sends a join toward the source. Why do I want to do this: load balancing. I need to bring some traffic onto the multi-homed subnet via both the DR and the non-DR router. So a re-state of the question: do I need to do something as absurd as having all my sources multi-homed in order to get this to work? Is there something easier? If not, will this actually work? -Kevin From owner-idmr@cs.ucl.ac.uk Tue Feb 15 01:03:20 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07159 for ; Tue, 15 Feb 2000 01:03:19 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 15 Feb 2000 04:18:35 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 15 Feb 2000 04:18:31 +0000 Received: from sirius.ctr.columbia.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 15 Feb 2000 04:19:02 +0000 Received: from comet.columbia.edu (argo.comet.columbia.edu [128.59.68.36]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id XAA21220; Mon, 14 Feb 2000 23:19:00 -0500 (EST) Received: from localhost (xwang@localhost) by comet.columbia.edu (8.8.7/8.8.7/COMET) with SMTP id XAA06265; Mon, 14 Feb 2000 23:19:00 -0500 (EST) X-Authentication-Warning: argo.comet.columbia.edu: xwang owned process doing -bs Date: Mon, 14 Feb 2000 23:18:59 -0500 (EST) From: Xin Wang X-Sender: xwang@argo To: "Kevin C. Almeroth" cc: idmr@cs.ucl.ac.uk Subject: Re: multi-homing and load balancing In-Reply-To: <200002150058.QAA06515@jackson.cs.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk On Mon, 14 Feb 2000, Kevin C. Almeroth wrote: > > I'm having an interesting configuration problem that I'd like > some advice on. > > My network looks like the following: > > ____ ___ > |DR| |R| > ---- --- > ! ! > ------------------------ > ! > --- > |H| > --- > > This is a straightforward, multi-homed network and the > designated router, DR, is the left router. > > The fundamental question is whether there is any way to get > multicast traffic to flow through the non-DR. My understanding is the repsonsibility of the DR is just to draw down the traffic initially, and it will then forward all the traffic to the LAN. In this case, both the non-DR and H will receive the traffic. In some topology, the non-DR may become the Forwarder when it has minimum cost path to RP/source, if you use PIM. Xin From owner-idmr@cs.ucl.ac.uk Tue Feb 15 06:37:34 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22430 for ; Tue, 15 Feb 2000 06:37:31 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 15 Feb 2000 09:30:20 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 15 Feb 2000 09:30:17 +0000 Received: from monsoon.mail.pipex.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 15 Feb 2000 09:30:47 +0000 Received: (qmail 2366 invoked from network); 15 Feb 2000 09:30:46 -0000 Received: from userl316.uk.uudial.com (HELO vaio-note) (193.149.74.129) by smtp.dial.pipex.com with SMTP; 15 Feb 2000 09:30:46 -0000 Message-ID: <004501bf7797$40d60c80$dc6a45c2@vaio-note> Reply-To: Tony Ballardie From: Tony Ballardie To: "Kevin C. Almeroth" , idmr Subject: Re: multi-homing and load balancing Date: Tue, 15 Feb 2000 09:29:22 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit >My network looks like the following: > > ____ ___ > |DR| |R| > ---- --- > ! ! > ------------------------ > ! > --- > |H| > --- > >The fundamental question is whether there is any way to get >multicast traffic to flow through the non-DR. > > * My sense is, there is no easy way. Because IGMP msgs > go to the DR the DR initiates the join toward > the RP/source. in general... (and not speaking for pim, though I imagine it would/should do this): joins should follow the normally routed paths, so for some join destinations the DR will forward the join off-LAN, and for others the DR will forward the join to R for forwarding off-LAN. For the latter, in CBT the DR doesn't keep fwd state for the group (even though it originates joins in response to IGMP), so mcast traffic is only forwarded by the off-LAN forwarder for the group. I don't 'think there currently exist means to go beyond this "natural" load balancing in any of the protocols without hacks. Tony From owner-idmr@cs.ucl.ac.uk Tue Feb 15 15:07:34 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20818 for ; Tue, 15 Feb 2000 15:07:32 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 15 Feb 2000 18:04:34 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 15 Feb 2000 18:04:30 +0000 Received: from wodc7-2.corprelay.mail.uu.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 15 Feb 2000 18:04:56 +0000 Received: from neserve0.corp.us.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.203.88]) id QQicno04888; Tue, 15 Feb 2000 18:04:54 GMT Received: by neserve0.corp.us.uu.net id QQicno26500; Tue, 15 Feb 2000 13:04:50 -0500 (EST) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: multi-homing and load balancing In-Reply-To: <200002151758.JAA09704@jackson.cs.ucsb.edu> from "Kevin C. Almeroth" at "Feb 15, 2000 09:58:37 am" To: "Kevin C. Almeroth" Date: Tue, 15 Feb 2000 13:04:50 -0500 (EST) CC: idmr@cs.ucl.ac.uk X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit In sparse mode, yes it works fine. In dense mode, a condition can occur where all traffic is forwarded due to a favourite vendor feature. _J In the new year, Kevin C. Almeroth wrote: > A couple of folks have asked me to clarify my > picture. Hating ASCII pictures... let me explain > in words: > > Classic multi-homed subnet. Two routers, and > one is elected the DR and the other is obviously > not. > > My understanding is that all IGMP joins will go to > the DR who will then send a join into the network. > This creates forwarding state so ALL multicast traffic > flows through the DR. > > This becomes a load balancing issue if you have a > slightly more complicated picture than what I've > drawn. In reality, we have a few Layer 2 switches > on the multi-homed network and a full-duplex connection. > So, it becomes an issue that we don't want ALL mcast > traffic going through the DR. Sometimes, we'd like > traffic to go through the non-DR. > > As Tony pointed out the correct behavior seems to be > for the DR to send the join to the other router and > let it do the forwarding. This is exactly what we > want but wanted to know if anyone had experienced this > in practice. > > -Kevin > From owner-idmr@cs.ucl.ac.uk Tue Feb 15 15:07:48 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20829 for ; Tue, 15 Feb 2000 15:07:46 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 15 Feb 2000 17:58:18 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 15 Feb 2000 17:58:14 +0000 Received: from hercules.cs.ucsb.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 15 Feb 2000 17:58:42 +0000 Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id JAA26230; Tue, 15 Feb 2000 09:58:38 -0800 (PST) Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4) id JAA09704 for ; Tue, 15 Feb 2000 09:58:37 -0800 (PST) Date: Tue, 15 Feb 2000 09:58:37 -0800 (PST) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <200002151758.JAA09704@jackson.cs.ucsb.edu> To: idmr@cs.ucl.ac.uk Subject: Re: multi-homing and load balancing Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk A couple of folks have asked me to clarify my picture. Hating ASCII pictures... let me explain in words: Classic multi-homed subnet. Two routers, and one is elected the DR and the other is obviously not. My understanding is that all IGMP joins will go to the DR who will then send a join into the network. This creates forwarding state so ALL multicast traffic flows through the DR. This becomes a load balancing issue if you have a slightly more complicated picture than what I've drawn. In reality, we have a few Layer 2 switches on the multi-homed network and a full-duplex connection. So, it becomes an issue that we don't want ALL mcast traffic going through the DR. Sometimes, we'd like traffic to go through the non-DR. As Tony pointed out the correct behavior seems to be for the DR to send the join to the other router and let it do the forwarding. This is exactly what we want but wanted to know if anyone had experienced this in practice. -Kevin From owner-idmr@cs.ucl.ac.uk Tue Feb 15 15:09:43 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20914 for ; Tue, 15 Feb 2000 15:09:41 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 15 Feb 2000 19:19:56 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 15 Feb 2000 19:19:48 +0000 Received: from smtprch1.nortelnetworks.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 15 Feb 2000 19:20:18 +0000 Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Tue, 15 Feb 2000 13:18:26 -0600 Received: from zsc4c004.corpwest.baynetworks.com ([134.177.2.151]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 12FVSQZ4; Tue, 15 Feb 2000 14:18:20 -0500 Received: from hnguyen-nt (hnguyen-nt.corpwest.baynetworks.com [134.177.80.194]) by zsc4c004.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 198NBPWS; Tue, 15 Feb 2000 11:18:18 -0800 Message-Id: <3.0.32.20000215111041.00a15d20@ZSC4C004.corpwest.baynetworks.com> X-Sender: ssingatw@ZSC4C004.corpwest.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 15 Feb 2000 11:10:44 -0800 To: idmr From: Sundeep Singatwaria Subject: draft-ietf-idmr-multicast-routmib-13.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Altough it seems pretty obvious from the field name but I would still like to clarify this -> Is the field 'ipMRouteExpiryTime' in IpMRouteEntry data structure in draft http://www.ietf.org/internet-drafts/draft-ietf-idmr-multicast-routmib-13.txt , the expiry time of route or the expiry time of the group ?? Thanks. sundeep From owner-idmr@cs.ucl.ac.uk Tue Feb 15 15:10:38 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20960 for ; Tue, 15 Feb 2000 15:10:36 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 15 Feb 2000 18:02:41 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 15 Feb 2000 18:02:37 +0000 Received: from mail5.microsoft.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 15 Feb 2000 18:03:07 +0000 Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 15 Feb 2000 09:49:45 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id ; Tue, 15 Feb 2000 09:49:44 -0800 Message-ID: From: Chris Engdahl To: "'Houdek, Stephen (S.W.)'" , "'jhall@UU.NET'" Cc: idmr@cs.ucl.ac.uk Subject: RE: Question on MS-DS Mroute Date: Tue, 15 Feb 2000 09:47:41 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk WINS does this: see microsoft support knowledge base, Article ID Q151761 for more info. http://support.microsoft.com/support/kb/articles/Q151/7/61.asp?LNG=ENG&SA=AL LKB&FR=0 -----Original Message----- From: Houdek, Stephen (S.W.) [mailto:shoudek@ford.com] Sent: Monday, February 07, 2000 11:05 PM To: 'jhall@UU.NET' Cc: idmr@cs.ucl.ac.uk Subject: RE: Question on MS-DS Mroute Yes, there is a connected IGMP member. Interestingly enough it turns out to be the same Video server (MS-W2K) we have setup to pilot Video multicast. Stephen W. Houdek shoudek@ford.com (313) 845-4128 (313) 845-2491 -----Original Message----- From: jhall@UU.NET [mailto:jhall@UU.NET] Sent: Tuesday, February 08, 2000 1:58 AM To: Houdek, Stephen (S.W.) Cc: idmr@cs.ucl.ac.uk Subject: Re: Question on MS-DS Mroute hmm it's a dense group, you have joined the SPT, and you have connected IGMP members (I think) or you are joined to a pim / dvmrp border. _J In the new year, Houdek, Stephen (S.W.) wrote: > Take a look at the following mroute.....(from my RP). > > (*, 224.0.1.24), 09:27:02/00:02:54, RP 0.0.0.0, flags: DJC > Incoming interface: Null, RPF nbr 0.0.0.0 > Outgoing interface list: > GigabitEthernet0/0/0.58, Forward/Sparse-Dense, 09:27:02/00:00:00 > GigabitEthernet9/0/0.112, Forward/Sparse-Dense, 09:20:46/00:00:00 > GigabitEthernet9/0/1, Forward/Sparse-Dense, 09:20:29/00:00:00 > > > Can someone clue me into what Microsoft-DS does? Who are the listeners to > this group? What are the dynamics of the application? Is it one to one, > one to many?? This showed up unexpectedly and I am trying to figure out > what impact (if any) it may have in my network. > > Thanks in advance for your help! > > Stephen W. Houdek > shoudek@ford.com > (313) 845-4128 > (313) 845-2491 > > > -----Original Message----- > From: Chirayu Shah [mailto:cshah@torrentnet.com] > Sent: Monday, February 07, 2000 4:04 PM > To: idmr@cs.ucl.ac.uk > Subject: Question on MBGP. > > > > Hi, > I had a MBGP-deployment question. It seems that for receivers > in a PIM domain which is a part of an AS to be able to > receive traffic from sources external to the AS, it is necessary to run > IMBGP on all the routers in the AS. Is this correct? Is there any > other way in which one can receive MBGP routes on a router within a PIM > domain without having to run IMBGP on it? I believe it is not > possible to export MBGP routes into OSPF/RIP because it would be difficult > to differentiate between BGP and MBGP routes (assuming that > BGP and MBGP topologies are incongruent). > > > Chirayu Shah > Software Engineer. > Ericsson IP Infrastructure > 12120 Plum Orchard Dr > Suite A > Silver Spring, MD 20904. > From owner-idmr@cs.ucl.ac.uk Tue Feb 15 17:43:51 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26370 for ; Tue, 15 Feb 2000 17:43:51 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 15 Feb 2000 20:48:15 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 15 Feb 2000 20:48:09 +0000 Received: from 131.107.152.20 by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 15 Feb 2000 20:48:40 +0000 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id OAA16496; Tue, 15 Feb 2000 14:26:22 -0800 (PST) (envelope-from dthaler) From: Dave Thaler Message-Id: <200002152226.OAA16496@dthaler.microsoft.com> Subject: Re: draft-ietf-idmr-multicast-routmib-13.txt In-Reply-To: <3.0.32.20000215111041.00a15d20@ZSC4C004.corpwest.baynetworks.com> from Sundeep Singatwaria at "Feb 15, 2000 11:10:44 am" To: ssingatw@nortelnetworks.com (Sundeep Singatwaria) Date: Tue, 15 Feb 2000 14:26:11 -0800 (PST) Cc: idmr@cs.ucl.ac.uk X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit > Altough it seems pretty obvious from the field name but I would still like > to clarify this -> > > Is the field 'ipMRouteExpiryTime' in IpMRouteEntry data structure in draft > http://www.ietf.org/internet-drafts/draft-ietf-idmr-multicast-routmib-13.txt > , the expiry time of route or the expiry time of the group ?? The expiry time of the row, which would be the (S,G) entry, or (*,G) entry if the source address is 0.0.0.0. -Dave From owner-idmr@cs.ucl.ac.uk Tue Feb 15 17:45:26 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26423 for ; Tue, 15 Feb 2000 17:45:25 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 15 Feb 2000 20:33:31 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 15 Feb 2000 20:33:26 +0000 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 15 Feb 2000 20:33:57 +0000 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 80E851E01E; Tue, 15 Feb 2000 15:33:55 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA05145; Tue, 15 Feb 2000 15:33:55 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id MAA21880; Tue, 15 Feb 2000 12:33:41 -0800 (PST) Message-Id: <200002152033.MAA21880@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: almeroth@cs.ucsb.edu Subject: Re: multi-homing and load balancing Cc: idmr@cs.ucl.ac.uk Date: Tue, 15 Feb 2000 12:33:41 -0800 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >My understanding is that all IGMP joins will go to >the DR who will then send a join into the network. >This creates forwarding state so ALL multicast traffic >flows through the DR. If the DR's route towards the RP or source points through the other router, then the Join will go that way. The way you painted the original picture, I thought maybe the DR was one of the exit routers and that's why the other one wasn't being used. If you have 2 exit routers which each only have routes pointing out, using either one as a DR will not allow load balancing. Try making the "downstream" router the DR. >This becomes a load balancing issue if you have a >slightly more complicated picture than what I've >drawn. In reality, we have a few Layer 2 switches >on the multi-homed network and a full-duplex connection. >So, it becomes an issue that we don't want ALL mcast >traffic going through the DR. Sometimes, we'd like >traffic to go through the non-DR. Note that unless you have PIM-snooping switches, the multicast traffic on the lan will go to the DR anyway, since the switches know that the DR is a multicast router. Bill From owner-idmr@cs.ucl.ac.uk Wed Feb 16 14:58:35 2000 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11770 for ; Wed, 16 Feb 2000 14:58:29 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 16 Feb 2000 17:37:20 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 16 Feb 2000 17:37:16 +0000 Received: from popcorn.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 16 Feb 2000 17:37:47 +0000 Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id JAA23063; Wed, 16 Feb 2000 09:37:13 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200002151758.JAA09704@jackson.cs.ucsb.edu> References: <200002151758.JAA09704@jackson.cs.ucsb.edu> Date: Wed, 16 Feb 2000 09:38:47 -0800 To: almeroth@cs.ucsb.edu (Kevin C. Almeroth) From: Steve Deering Subject: Re: multi-homing and load balancing Cc: idmr@cs.ucl.ac.uk Content-Type: text/plain; charset="us-ascii" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk At 9:58 AM -0800 2/15/00, Kevin C. Almeroth wrote: > Classic multi-homed subnet. Two routers, and > one is elected the DR and the other is obviously > not. > >My understanding is that all IGMP joins will go to >the DR who will then send a join into the network. Kevin, IGMP reports (not "joins") go to *all* multicast routers on the subnet, not just the DR. Steve