From owner-pim@catarina.usc.edu Sat Feb 2 03:04:54 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00219 for ; Sat, 2 Feb 2002 03:04:53 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id XAA07265 for pim-list; Fri, 1 Feb 2002 23:49:13 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from TechmeSRV.Partners500.Com ([62.90.222.70]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id XAA07260 for ; Fri, 1 Feb 2002 23:49:11 -0800 (PST) From: Viagra9520@eudoramail.com Received: from mx1.eudoramail.com (dai-tx1a-59.rasserver.net [204.32.146.59]) by TechmeSRV.Partners500.Com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CVGW8VRG; Sat, 2 Feb 2002 09:49:56 +0200 Message-ID: <000038d26378$00003cf2$00006d10@mx1.eudoramail.com> To: Subject: [pim] Make This Valentine's Day Unforgettable. C Date: Sat, 02 Feb 2002 01:48:34 -1800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reply-To: Viagra9520@eudoramail.com Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable = Orders Today will be Shipped Tomorrow


 

    • Orders Today will be Shipped Tomorrow
    • No Prescription Necessary
    • U.S. Doct= ors and Pharmacy available for co= nsultation
    • All orders shipped Fed Ex Overnight

 
 
 
 
To be removed from future mailing= s, please reply with "Remove" as subject.
 
 From owner-pim@catarina.usc.edu Sat Feb 2 05:02:53 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01318 for ; Sat, 2 Feb 2002 05:02:52 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id BAA07636 for pim-list; Sat, 2 Feb 2002 01:51:52 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from localhost (s211-33-80-128.thrunet.ne.kr [211.33.80.128]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id BAA07626 for ; Sat, 2 Feb 2002 01:51:50 -0800 (PST) Message-Id: <200202020951.BAA07626@catarina.usc.edu> Reply-To: kasdfasdf@lycos.co.kr From: 마켓도우미 To: pim@catarina.usc.edu Subject: [pim] 15만원짜리종합쇼핑몰 Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 2 Feb 2002 18:49:26 +0900 Sender: owner-pim@catarina.usc.edu Precedence: bulk 상업성 광고메일을 보내게 되어서 정말죄송합니다

15만원짜리종합쇼핑몰 견본보기

◎ 제공서비스

▶주문, 결재, 배송, 택배시스템
등 온라인 상점에 필요로 하는 모든 시스템을 원스톱으로 제공하고 있어,
재고나 배송의 부담이 전혀 없습니다.

▶공동구매기능

▶무료문자메세지기능

▶ 20,000여 상품 공급가(딜러가)제공..(수시 업그레이드)
       - 종합몰 및 전문몰 형태로 운영하실 수 있습니다..
▶ 주문, 배송, 반품, 상품관리 물류 원스톱(One Stop)서비스 이용
       - 주문서 작성만 하시면 됩니다..(당사에서 모두처리)
▶ 해피콜센터 이용 (주문확인 및 배송확인 콜서비스)
       - 고객(쇼핑몰)에 대한 신뢰감 형성

전화상담받습니다 053-641-4433인터넷사업부

9만9천원짜리 홈페이지제작견본보기

9만9천원짜리 홈페이지메뉴얼둘러보기

수신거부합니다

님의 메일주소는 인터넷여행을 하다 수집하였읍니다.

저희는 귀하에 대해 어떠한 정보도 가지고있지않습니다

수신거부를 해주시면 다음부터는 두번다시 메일을 보내지 않겠습니다

From owner-pim@catarina.usc.edu Sat Feb 2 17:45:59 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08402 for ; Sat, 2 Feb 2002 17:45:59 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA12445 for pim-list; Sat, 2 Feb 2002 14:24:56 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from mail.asiaitech.com.hk (ipvpn086121.netvigator.com [203.198.159.121]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA12440; Sat, 2 Feb 2002 14:24:53 -0800 (PST) From: webmaster@europort.net Received: from europort.net ([10.0.0.1]) by mail.asiaitech.com.hk (8.11.6/8.11.6) with SMTP id g12MfkF12428; Sun, 3 Feb 2002 06:41:48 +0800 Subject: [pim] toner supplies Date: Sat, 2 Feb 2002 17:38:06 Message-Id: <255.26395.749833@europort.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pim@catarina.usc.edu Precedence: bulk **** VORTEX SUPPLIES **** NEW PRICES ON TONER CARTRIDGES FOR LASER PRINTERS AND COPIERS. ORDER BY PHONE:1-888-288-9043 ORDER BY FAX: 1-888-977-1577 E-MAIL REMOVAL LINE: 1-888-248-4930 UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED) ALL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL. PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS). IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. NUMBER NOTE: WE DO NOT CARRY 1) XEROX, BROTHER, PANASONIC, FUJITSU PRODUCTS 2) DESKJETJET/INK JET OR BUBBLE JET CARTRIDGES 3) ANY OFFBRANDS BESIDES THE ONES LISTED BELOW. OUR LASER PRINTER TONER CARTRIDGE PRICES ARE AS FOLLOWS: (PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER) FOR HEWLETT PACKARD: (ON PAGE 2) ITEM #1 LASERJET SERIES 4L,4P (74A)------------------------$44 ITEM #2 LASERJET SERIES 1100 (92A)-------------------------$44 ITEM #3 LASERJET SERIES 2 (95A)----------------------------$39 ITEM #4 LASERJET SERIES 2P (75A)---------------------------$54 ITEM #5 LASERJET SERIES 5P,6P,5MP, 6MP (3903A)---------- -$44 ITEM #6 LASERJET SERIES 5SI, 8000 (09A)--------------------$95 ITEM #7 LASERJET SERIES 2100, 2200 (96A)-------------------$74 ITEM #8 LASERJET SERIES 8100 (82X)-------------------------$115 ITEM #9 LASERJET SERIES 5L/6L (3906A)----------------------$39 ITEM #10 LASERJET SERIES 4V---------------------------------$95 ITEM #11 LASERJET SERIES 4000 (27X)--------------------------$79 ITEM #12 LASERJET SERIES 3SI/4SI (91A)-----------------------$54 ITEM #13 LASERJET SERIES 4, 4M, 5,5M-------------------------$49 ITEM #13A LASERJET SERIES 5000 (29X)-------------------------$125 ITEM #13B LASERJET SERIES 1200-------------------------------$59 ITEM #13C LASERJET SERIES 4100-------------------------------$99 ITEM #18 LASERJET SERIES 3100------------------------------$39 ITEM #19 LASERJET SERIES 4500 BLACK--------------------------$79 ITEM #20 LASERJET SERIES 4500 COLORS ------------------------$125 FOR HEWLETT PACKARD FAX (ON PAGE 2) ITEM #14 LASERFAX 500, 700 (FX1)----------$49 ITEM #15 LASERFAX 5000,7000 (FX2)--------$64 ITEM #16 LASERFAX (FX3)------------------$59 ITEM #17 LASERFAX (FX4)------------------$54 FOR LEXMARK/IBM (ON PAGE 3) OPTRA 4019, 4029 HIGH YIELD---------------$89 OPTRA R, 4039, 4049 HIGH YIELD-----------$105 OPTRA E310.312 HIGH YIELD----------------$79 OPTRA E-----------------------------------$59 OPTRA N----------------------------------$115 OPTRA S----------------------------------$165 OPTRA T----------------------------------$195 OPTRA E310/312---------------------------$79 OPTAA E410/412---------------------------$89 FOR EPSON (ON PAGE 4) ACTION LASER 7000,7500,8000,9000----------$105 ACTION LASER 1000,1500--------------------$105 FOR CANON PRINTERS (ON PAGE 5) PLEASE CALL FOR MODELS AND UPDATED PRICES FOR CANON PRINTER CARTRIDGES PANASONIC (0N PAGE 7) NEC SERIES 2 MODELS 90 AND 95----------$105 FOR APPLE (0N PAGE 8) LASER WRITER PRO 600 or 16/600------------------$49 LASER WRITER SELECT 300,320,360-----------------$74 LASER WRITER 300 AND 320------------------------$54 LASER WRITER NT, 2NT----------------------------$54 LASER WRITER 12/640-----------------------------$79 FOR CANON FAX (ON PAGE 9) LASERCLASS 4000 (FX3)---------------------------$59 LASERCLASS 5000,6000,7000 (FX2)-----------------$54 LASERFAX 5000,7000 (FX2)------------------------$54 LASERFAX 8500,9000 (FX4)------------------------$54 FOR CANON COPIERS (PAGE 10) PC 3, 6RE, 7 AND 11 (A30)---------------------$69 PC 300,320,700,720,760,900,910,920(E-40)------$89 90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS. ALL TRADEMARKS AND BRAND NAMES LISTED ABOVE ARE PROPERTY OF THE RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY. From owner-pim@catarina.usc.edu Sun Feb 3 23:20:00 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05148 for ; Sun, 3 Feb 2002 23:20:00 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id TAA15145 for pim-list; Sun, 3 Feb 2002 19:56:54 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from gate.alliedtelesyn.co.nz (IDENT:proxyuser@gate.alliedtelesyn.co.nz [202.49.72.33]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id TAA15140 for ; Sun, 3 Feb 2002 19:56:53 -0800 (PST) Received: (qmail 31417 invoked from network); 4 Feb 2002 07:18:50 -0000 Received: from aslan.alliedtelesyn.co.nz (HELO alliedtelesyn.co.nz) (202.49.74.92) by gate-int.alliedtelesyn.co.nz with SMTP; 4 Feb 2002 07:18:50 -0000 Received: from ASLAN/SpoolDir by alliedtelesyn.co.nz (Mercury 1.47); 4 Feb 02 15:22:20 +1300 Received: from SpoolDir by ASLAN (Mercury 1.47); 4 Feb 02 15:22:16 +1300 From: "Anttoni Nurkka " Organization: Allied Telesyn Research, Chch, NZ To: pim@catarina.usc.edu Date: Mon, 4 Feb 2002 15:22:12 +1300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: [pim] Comments re: draft-ietf-pim-sm-v2-new-04 Reply-to: anttoni.nurkka@alliedtelesyn.co.nz Message-ID: <3C5EA729.4043.18AFE93@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7BIT Greetings, I'm part of the team here at Allied Telesyn Research in NZ wokring on our PIM implementation. I have a few comments and questions regarding the PIM- SM Protocol Specification. 1- Table of Contents Comment: No headings for section 4.7.1 and 2.7.2 2- Section 4. Protocol Specification Comment: A description of Section 4.7 is missing 3- Section 4.4.6. Sending (*,G) Join/Prune Messages Comment: Figure 7: the "RPF'(*,G) changes due to an Assert" transition indicates an immediate Send Join (*,G). This is repeated in the tabular form for said transition. However, in the textual description, the Join Timer is modified (lowered) causing the Send Join (*,G) to occur on Join Timer Expiry. From our testing, the text describes the correct operation. 4- Section 4.4.7. Sending (S,G) Join/Prune Messages Comment: Figure 8 is missing the "RPF'(S,G) changes due to an Assert" transition, and it is missing from the tabular form. The transition is mentioned in the textual description. 5- Section 4.5.1. (S,G) Assert Message State Machine Comment: The tabular form of the state machine, for the "In I Am Assert Loser (L) State", the transitions for "Receive Inferior" and "Receive Acceptable" Assert from Current Winner have the actions swapped. 6- Section 4.5.2. (*,G) Assert Message State Machine Question: The bold sentence: "It is important to note that no transition occurs in the (*,G) state machine as a result of receiving an Assert message if the (S,G) assert state machine for the relevant S and G is not in the "NoInfo" state." This has caused me some confusion, so here is how I have interpreted the sentence: "Assert message" = a (*,G) assert (RPT bit set) but with a source specified. "relevant" = with the above interpretation for the assert message, this just means the matching (S,G) assert state machine. Question1: is this the correct interpretation? If this interpretation is correct, then noting that the (S,G) assert state machine has a transition for receiving an (S,G) assert with RPT bit set (which is in fact a (*,G) assert), the sentence may be unnecessary. Or at least, may benefit from a re-write to indicate the correct interpretation. Question2: For an actual (*,G) assert (S=INADDR_ANY, RPT bit set), does the state of any (S,G) assert state machine need to be considered? (This, obviously, is where I am confused) 7- Section 6.2. Non-cryptographic Authentication Mechanisms Comment: The sentence: "An implementation SHOULD provide a mechanism to allow a DR to restrict the range of source addresses from which it accepts Register-encapsulated packets." I would expect DR to be RP, since it is the RP which receives Register- encapsulated packets. I hope these comments and questions are useful, and I look forward to getting clarification for my questions in point 6. Sincerely, Anttoni ------------------------------------------------------------- Anttoni Nurkka 27 Nazareth Avenue Software Engineer PO Box 8011 Allied Telesyn Research Christchurch phone +64 3 339 3000 New Zealand fax +64 3 339 3002 email: anttoni.nurkka@alliedtelesyn.co.nz web: http://www.alliedtelesyn.co.nz/ ------------------------------------------------------------- From owner-pim@catarina.usc.edu Mon Feb 4 02:03:19 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11153 for ; Mon, 4 Feb 2002 02:03:18 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id WAA15884 for pim-list; Sun, 3 Feb 2002 22:48:24 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from mailweb13.rediffmail.com ([203.199.83.25]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id WAA15879 for ; Sun, 3 Feb 2002 22:48:22 -0800 (PST) Received: (qmail 13995 invoked by uid 510); 4 Feb 2002 06:45:26 -0000 Date: 4 Feb 2002 06:45:26 -0000 Message-ID: <20020204064526.13994.qmail@mailweb13.rediffmail.com> Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 04 Feb 2002 06:45:26 -0000 MIME-Version: 1.0 From: "P.Jhingran" Reply-To: "P.Jhingran" To: pim@catarina.usc.edu Subject: [pim] Differentiating PIM-SM from PIM-DM Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id WAA15880 Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, I have a trivial doubt.What shall happen if PIM-SM and PIM-DM enabled interfaces are connected back to back. PIM-SM is enabled on router R1's interface 1 while PIM-DM is enabled on interface 2. Router R1 <----------> Router R2 PIM-SM PIM-DM Interface 1 Interface 2 Is cisco or any other router able to distinguish the above two modes?? The hello format is same for both the modes and now it is up the to administrator to make proper connections!! regards, Prashant From owner-pim@catarina.usc.edu Mon Feb 4 14:21:42 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03617 for ; Mon, 4 Feb 2002 14:21:40 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA17140 for pim-list; Mon, 4 Feb 2002 10:48:49 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA17135 for ; Mon, 4 Feb 2002 10:48:47 -0800 (PST) Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA14750 for ; Mon, 4 Feb 2002 10:44:36 -0800 (PST) Received: from ptrivedi-bsd.juniper.net (ptrivedi-bsd.juniper.net [172.17.12.230]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g14IgC635152; Mon, 4 Feb 2002 10:42:12 -0800 (PST) (envelope-from paras@juniper.net) Received: (from paras@localhost) by ptrivedi-bsd.juniper.net (8.11.1/8.9.3) id g14IgCm84979; Mon, 4 Feb 2002 10:42:12 -0800 (PST) (envelope-from paras) From: Paras Trivedi Message-Id: <200202041842.g14IgCm84979@ptrivedi-bsd.juniper.net> Subject: Re: [pim] Differentiating PIM-SM from PIM-DM To: learning_pim@rediffmail.com Date: Mon, 4 Feb 2002 10:42:12 -0800 (PST) Cc: pim@catarina.usc.edu In-Reply-To: <20020204064526.13994.qmail@mailweb13.rediffmail.com> from "P.Jhingran" at Feb 04, 2002 06:45:26 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sparse or dense used to be a property of the interface in PIMv1. But, in PIMv2, these days, the sparse or dense is a property of a group or group range. So, the interface simply needs to run PIM, regardless of any particular mode. (Although, in some exceptional cases it is needed to run an interface in strictly sparse or dense mode.) Most implementations (at least JunOS and IOS) allow you to turn on PIM, regardless of the mode, with "sparse-dense mode" command. Yes, it'd be a misconfiguration to have sparse configuration on one end of a link and dense, on another. And PIMv2 hello does not carry this information. So, it cannot be detected automatically. But, if you absolutely do this, then I guess, the sparse router will do sparse thing (If DR, send register, send (*,G) join) and dense router will do dense thing (flood and expect to prune), for any combination of source/receiver/transit situation, leading most likely to chaos. - Paras. > > > Hi all, > I have a trivial doubt.What shall happen if PIM-SM and PIM-DM enabled interfaces are connected back to back. > PIM-SM is enabled on router R1's interface 1 while PIM-DM is enabled on interface 2. > > Router R1 <----------> Router R2 > PIM-SM PIM-DM > Interface 1 Interface 2 > > Is cisco or any other router able to distinguish the above two modes?? The hello format is same for both the modes and now it is up the to administrator to make proper connections!! > regards, > Prashant > From owner-pim@catarina.usc.edu Mon Feb 4 15:32:34 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05346 for ; Mon, 4 Feb 2002 15:32:33 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA17604 for pim-list; Mon, 4 Feb 2002 12:03:41 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA17542; Mon, 4 Feb 2002 12:02:47 -0800 (PST) Received: from heracles.cyberia.cl (IDENT:root@heracles.hostingchile.cl [200.54.163.34]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id EAA08255; Mon, 4 Feb 2002 04:04:19 -0800 (PST) Received: from mailgirl.risq.ca (190-57.adsl.cust.tie.cl [200.54.190.57]) by heracles.cyberia.cl (8.11.6/8.11.6) with SMTP id g14Ague32291; Mon, 4 Feb 2002 07:42:57 -0300 Date: Mon, 4 Feb 2002 07:42:57 -0300 From: "M.Cruz@risq.qc.ca" To: "6142@yahoo.com" <6142@yahoo.com> Message-ID: <1012845204.0953126277@mailgirl.risq.ca> Subject: [pim] Is There Such Thing As A No-Risk Investment? MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Government Secured

WEALTH WITHOUT R= ISK=21

Government =22Secured=22 tax certificates PAY YOU between= 16%-50%=21

Receive your fre= e copy of =22INSIDER SECRETS OF IVESTING IN SECURED GOVERNMENT TAX CERTIFICATES,=22 just for filling out= this form=21 (A =2439.95 Value)YOURS FREE=21=21<= /B>

DOES THIS SOUND LI= KE YOU?

  • Looking For a Crisis Proof Investment?
  • Want For Flexible Investment Terms?
  • Want Something SAFE For a Change?
  • Frustrated Watching The Stock Market?
  • Want an Investment Backed By =22Real Property?
  • Would Like a Guaranteed Rate of Return?

    • WE WILL SHOW YO= U HOW TO:

  • Remove Yourself From The Crisis World=21
  • Receive Flexible Options For Your Money
  • Provide Yourself With SAFE Investment Tools
  • Get Away From The Market Fluctuations
  • Get a Collateralized Investment Opportunity=21
  • Get Yourself a Guaranteed Rate of Return=21

    • What Can I M= ake?*

    *=5BThe numbers used below are for example only, your indi= vidual situations will vary. Affidavits on file=5D

    The average in= terest one makes on back taxes is 15%-50% guaranteed by the government, and this is the low end. Our clients are making an incr= edible 30 to 50 times their money on a high end. The banks have been doing th= is for over 100 years. Our company has developed a program that allows you= to capitalize on these proven techniques and strategies for the first t= ime ever. Please review the chart below to see what our program can do for you= when taking advantage of this exciting opportunity=21
    = <= /TBODY>

    Property =23

    Assessed

    State

    Amount Paid

    Assessed Value

    PROFIT POTENTIAL

    =23196

    Assessed

    Oklahoma

    =24300.00

    =2420,000.00

    =2419,700.00

    =23206

    Assessed

    Florida

    =241,957.00

    =24250,000.00

    =24248,043.00

    =23209

    Assessed

    California

    =2465,595.00

    =24262,349.00

    =24196,794.00

    =23211

    Assessed

    New York

    =247,000.00

    =2442,500.00

    =2435,500.00

    TOTAL 4 Properties

    Assessed

    Single Family

    =2474,012.00

    		   =24574,849= .00

    =24500,837.00

    Please fill out the following,NO OBLIGATION Form to Receive your FREE Copy of =22INSIDER SECRETS OF INVESTING IN SECURED GOVERNMENT TA= X CERTIFICATES=22 (A =2439.95 VALUE)

    All information gi= ven herein is strictly confidential and will not be re-distributed for= any reason other than for the specific use intended.

    Required Inp= ut Field*

    = <= /TR>
    Name*<= /B>
    Web Address
    Company Name
    State *
    Business Phone*
    Home Phone
    Best time to= contact: *
    Email Address*
    Type of Business



    To be removed from our distribution lists, please Click here.

    ******* From owner-pim@catarina.usc.edu Mon Feb 4 15:33:02 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05359 for ; Mon, 4 Feb 2002 15:33:02 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA17758 for pim-list; Mon, 4 Feb 2002 12:10:16 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA17751 for ; Mon, 4 Feb 2002 12:10:15 -0800 (PST) Received: from gate2.itt.com (gate2.itt.com [151.190.254.105]) by usc.edu (8.9.3.1/8.9.3/usc) with SMTP id EAA10679 for ; Mon, 4 Feb 2002 04:13:38 -0800 (PST) Received: from no.name.available by gate2.itt.com via smtpd (for [128.125.19.136]) with SMTP; 4 Feb 2002 12:13:01 UT Received: by FWDCMAIL2.de.ittind.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Feb 2002 07:11:27 -0500 Message-ID: From: "Nicholas, Jonathan" To: pim@catarina.usc.edu Subject: RE: [pim] Differentiating PIM-SM from PIM-DM Date: Mon, 4 Feb 2002 07:11:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk Such a configuration results in a simplex link from DM to SM. This has been tested and confirmed for the Cisco implementation. Jonathan Nicholas Network Systems Engineer ITT Aerospace/Communications Division > Hi all, > I have a trivial doubt.What shall happen if PIM-SM and > PIM-DM enabled interfaces are connected back to back. > PIM-SM is enabled on router R1's interface 1 while PIM-DM is > enabled on interface 2. > > Router R1 <----------> Router R2 > PIM-SM PIM-DM > Interface 1 Interface 2 > > Is cisco or any other router able to distinguish the above > two modes?? The hello format is same for both the modes and > now it is up the to administrator to make proper connections!! > regards, > Prashant > ************************************ If this email is not intended for you, or you are not responsible for the delivery of this message to the addressee, please note that this message may contain ITT Privileged/Proprietary Information. In such a case, you may not copy or deliver this message to anyone. You should destroy this message and kindly notify the sender by reply email. Information contained in this message that does not relate to the business of ITT is neither endorsed by nor attributable to ITT. ************************************ From owner-pim@catarina.usc.edu Mon Feb 4 15:33:52 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05371 for ; Mon, 4 Feb 2002 15:33:51 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA17565 for pim-list; Mon, 4 Feb 2002 12:03:23 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA17552 for ; Mon, 4 Feb 2002 12:03:22 -0800 (PST) Received: from gate1.itt.com (gate1.itt.com [151.190.254.100]) by usc.edu (8.9.3.1/8.9.3/usc) with SMTP id GAA25097 for ; Mon, 4 Feb 2002 06:35:02 -0800 (PST) Received: from no.name.available by gate1.itt.com via smtpd (for usc.edu [128.125.19.136]) with SMTP; 4 Feb 2002 14:34:24 UT Received: by FWDCMAIL2.de.ittind.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Feb 2002 09:32:53 -0500 Message-ID: From: "Nicholas, Jonathan" To: "'pim@catarina.usc.edu'" Cc: "Nicholas, Jonathan" Subject: [pim] PIM MIB Date: Mon, 4 Feb 2002 09:32:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pim@catarina.usc.edu Precedence: bulk All, I would like to propose adding the following MIB objects to the PIM MIB for PIM-DM. Jonathan Nicholas Network Systems Engineer ITT Aerospace/Communication Division pimInterfaceTriggeredHelloInterval OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum time before a triggered PIM Hello message is transmitted on this interface." DEFVAL { 5 } ::= { pimInterfaceEntry 10 } pimInterfaceHelloHoldtime OBJECT-TYPE SYNTAX Integer32 (0..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The value set in the Holdtime field of Hello messages transmitted on this interface. This should be 3.5 times the value of pimInterfaceHelloInterval." DEFVAL { 105 } ::= { pimInterfaceEntry 11 } pimInterfaceLANPruneDelay OBJECT-TYPE SYNTAX BITS { off (0), on (1) } MAX-ACCESS read-create STATUS current DESCRIPTION "Turns the LAN Prune Delay Option off and on on this interface." DEFVAL { off } ::= { pimInterfaceEntry 12 } pimInterfacePropagationDelay OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-create STATUS current DESCRIPTION "The value inserted into the LAN Prune Delay field of a LAN Prune Delay option on this interface." DEFVAL { 50 } ::= { pimInterfaceEntry 13 } pimInterfaceOverrideInterval OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-create STATUS current DESCRIPTION "The value inserted into the Override Interval field of a LAN Prune Delay option on this interface." DEFVAL { 150 } ::= { pimInterfaceEntry 14 } pimInterfaceGenerationID OBJECT-TYPE SYNTAX BITS { off (0), on (1) } MAX-ACCESS read-create STATUS current DESCRIPTION "Turns the Generation ID Option off and on on this interface." DEFVAL { off } ::= { pimInterfaceEntry 15 } pimInterfaceGraftRetryInterval OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The interval a PIM router waits for a Graft Ack before resending a Graft on this interface." DEFVAL { 3 } ::= { pimInterfaceEntry 16 } pimInterfaceMaxGraftRetries OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of times this router will resend a Graft on this interface." DEFVAL { 3 } ::= { pimInterfaceEntry 17 } pimInterfaceSRTTLThreshold OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The Time To Live in a PIM-DM State Refresh message at which it is not forwarded on this interface." DEFVAL { 0 } ::= { pimInterfaceEntry 18 } pimLANDelayEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Evaluates to TRUE if all routers on this interface are using the LAN Prune Delay Option." ::= { pimInterfaceEntry 19 } pimStateRefreshCapable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Evaluates to TRUE if all routers on this interface are using the State Refresh Capable Option." ::= { pimInterfaceEntry 20 } pimNeighborLANPruneDelay OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of LAN Prune Delay field of the LAN Prune Delay Option received from this neighbor. A value of 0 indicates that no LAN Prune Delay Option was received from this neigbor." ::= { pimNeighborEntry 6 } pimNeighborOverrideInterval OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of Override Interval field of the LAN Prune Delay Option received from this neighbor. A value of 0 indicates that no LAN Prune Delay Option was received from this neigbor." ::= { pimNeighborEntry 7 } pimStateRefreshCapable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Evaluates to TRUE if this neighbor is using the State Refresh Capable Option." ::= { pimNeighborEntry 8 } pimIpMRouteAssertWinnerAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP Address of the upstream Assert Winner." ::= { pimIpMRouteEntry 6 } pimIpMRouteSourceTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time before this router ceases originating State Refresh messages for this route." ::= { pimIpMRouteEntry 7 } pimDownstreamAssertWinner OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP Address of the Assert Winner." ::= { pimIpMRouteNextHopEntry 3 } pimDownstreamAssertTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining before the PIM-DM router leaves the current Assert state. A value of 0 indicates that the router is in the No Info state." ::= { pimIpMRouteNextHopEntry 4 } pimDownstreamAssertMetric OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The metric advertised by the Assert Winner." ::= { pimIpMRouteNextHopEntry 5 } pimDownstreamAssertMetricPref OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The metric preference advertised by the Assert Winner." ::= { pimIpMRouteNextHopEntry 6 } pimDownstreamPruneTimer OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining before the PIM-DM router resumes forwarding on this interface." ::= { pimIpMRouteNextHopEntry 7 } pimSourceLifetime OBJECT-TYPE SYNTAX Integer32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum time this router will continue to originate State Refresh messages in the absence of traffic from the source itself." DEFVAL { 210 } ::= { pim 13 } pimStateRefreshInterval OBJECT-TYPE SYNTAX Integer32 (1..255) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The interval between successive State Refresh messages originated by this router." DEFVAL { 60 } ::= { pim 14 } pimStateRefreshLimitInterval OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-create STATUS current DESCRIPTION "This router will not forward successive State Refresh messages received at less than this interval." DEFVAL { 0 } ::= { pim 15 } pimStateRefreshTimeToLive OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The TTL to be used by this router's originated State Refresh messages if the data packet's TTL is not recorded." DEFVAL { 16 } ::= { pim 16 } ************************************ If this email is not intended for you, or you are not responsible for the delivery of this message to the addressee, please note that this message may contain ITT Privileged/Proprietary Information. In such a case, you may not copy or deliver this message to anyone. You should destroy this message and kindly notify the sender by reply email. Information contained in this message that does not relate to the business of ITT is neither endorsed by nor attributable to ITT. ************************************ From owner-pim@catarina.usc.edu Mon Feb 4 16:00:19 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05880 for ; Mon, 4 Feb 2002 16:00:18 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA18228 for pim-list; Mon, 4 Feb 2002 12:31:40 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from sundmz2.procket.com (dmz2.procket.com [65.174.124.37]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA18223 for ; Mon, 4 Feb 2002 12:31:39 -0800 (PST) Received: from miata.procket.com (unknown [10.1.1.1]) by sundmz2.procket.com (Postfix) with ESMTP id C607934431; Mon, 4 Feb 2002 12:33:39 -0800 (PST) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g14KV6r6021327; Mon, 4 Feb 2002 12:31:06 -0800 (PST) Received: from procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 4 Feb 2002 12:31:06 -0800 Message-ID: <3C5EEF8A.5AFF1912@procket.com> Date: Mon, 04 Feb 2002 12:31:09 -0800 From: John Zwiebel Reply-To: john.zwiebel@procket.com Organization: Procket Networks X-Mailer: Mozilla 4.73 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Paras Trivedi Cc: learning_pim@rediffmail.com, pim@catarina.usc.edu Subject: Re: [pim] Differentiating PIM-SM from PIM-DM References: <200202041842.g14IgCm84979@ptrivedi-bsd.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Feb 2002 20:31:06.0677 (UTC) FILETIME=[DF686E50:01C1ADBA] Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Not exactly chaos. It depends on the toplogy. "ONCE UPON A TIME..." one could configure a dense router and a sparse router next to one another to transition between a sparse and a dense domain -- where 'dense' also includes DVMRP areas. Paras did hint at this when he said "exceptional cases". The "sparseness" of a group is determined by whether or not a router knows about an RP for a given multicast group. If it does, then the route is sparse. If it doesn't the route is dense. FWIW: although it would appear at first glance that dense-mode PIM is useful (especially now with "state-refresh"), in practice it has not proven to be. Part of the reason is that PIM-dense doesn't work well with the "expanding ring search", partly because of the fact that some routers throw away packets with TTL of 1 or 0 if they aren't specifically addressed to an IP address on that router, resulting in duplicate packet delivery in some topologies... And part of the reason is that application developers don't understand how PIM-dense works and so the result in certain toplogies is unexpected. Also, sparse-mode can "do" everything that dense-mode can and... in any case, SSM and bi-dir PIM may prove to be much more appropriate than any of the multicast routing protocols now used. 2cents Paras Trivedi wrote: > > Sparse or dense used to be a property of the interface in PIMv1. > But, in PIMv2, these days, the sparse or dense is a property of > a group or group range. So, the interface simply needs to run PIM, > regardless of any particular mode. (Although, in some exceptional > cases it is needed to run an interface in strictly sparse or dense mode.) > > Most implementations (at least JunOS and IOS) allow you to > turn on PIM, regardless of the mode, with "sparse-dense mode" command. > > Yes, it'd be a misconfiguration to have sparse configuration on > one end of a link and dense, on another. And PIMv2 hello does not > carry this information. So, it cannot be detected automatically. > But, if you absolutely do this, then I guess, the sparse router > will do sparse thing (If DR, send register, send (*,G) join) > and dense router will do dense thing (flood and expect to prune), for > any combination of source/receiver/transit situation, leading most > likely to chaos. > > - Paras. > > > > > > > Hi all, > > I have a trivial doubt.What shall happen if PIM-SM and PIM-DM enabled interfaces are connected back to back. > > PIM-SM is enabled on router R1's interface 1 while PIM-DM is enabled on interface 2. > > > > Router R1 <----------> Router R2 > > PIM-SM PIM-DM > > Interface 1 Interface 2 > > > > Is cisco or any other router able to distinguish the above two modes?? The hello format is same for both the modes and now it is up the to administrator to make proper connections!! > > regards, > > Prashant > > > > _______________________________________________ > Pim-external mailing list > Pim-external@mailist.procket.com > http://mailist.procket.com/mailman/listinfo/pim-external From owner-pim@catarina.usc.edu Mon Feb 4 16:56:50 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06752 for ; Mon, 4 Feb 2002 16:56:49 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA19355 for pim-list; Mon, 4 Feb 2002 13:29:30 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from mailFA2.rediffmail.com ([202.54.124.147]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id NAA19347 for ; Mon, 4 Feb 2002 13:29:27 -0800 (PST) Received: (qmail 429 invoked by uid 510); 4 Feb 2002 21:31:01 -0000 Date: 4 Feb 2002 21:31:01 -0000 Message-ID: <20020204213101.428.qmail@mailFA2.rediffmail.com> Received: from unknown (63.115.58.2) by rediffmail.com via HTTP; 04 Feb 2002 21:31:01 -0000 MIME-Version: 1.0 From: "pnh" Reply-To: "pnh" To: pim@catarina.usc.edu Subject: [pim] Forwarding BSM Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id NAA19351 Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hello, If a router configured as candidate BSR, receives an BSM from elected BSR with lower priority than its own priority, it will transition to Pending BSR state ("Receive Non-preferred BSM from Elected BSR" event in Candidate BSR state machine). Shouldn't it be fowarding this received BSM to all other routers so that even they update their view of elected BSR? Otherwise others will accept BSM from this router only when old one times out! Thanks PNH From owner-pim@catarina.usc.edu Mon Feb 4 22:58:17 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13310 for ; Mon, 4 Feb 2002 22:58:16 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id TAA21413 for pim-list; Mon, 4 Feb 2002 19:34:52 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from fsnt.future.futsoft.com ([203.197.140.35]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id TAA21408 for ; Mon, 4 Feb 2002 19:34:50 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 05 Feb 2002 09:19:56 +0530 Received: from prashantj (prashantj.future.futsoft.com [10.4.5.20]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g153XXm32648; Tue, 5 Feb 2002 09:03:33 +0530 Reply-To: From: "Prashant Jhingran" To: "'pnh'" , Subject: RE: [pim] Forwarding BSM Date: Tue, 5 Feb 2002 09:05:55 +0530 Message-Id: <000101c1adf6$37f2bea0$1405040a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020204213101.428.qmail@mailFA2.rediffmail.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit hi, I feel it should definitely forward the received BSR message regardless of the fact "Receive Non-preferred BSM from Elected BSR"....more over it shall also store the RP set. In case if the above is not done, a black hole might be created in the domain, with some routers having no clue about the RP set thus making communication/multicasting vulnerable. regards, Prashant -----Original Message----- From: owner-pim-implementors@catarina.usc.edu [mailto:owner-pim-implementors@catarina.usc.edu]On Behalf Of pnh Sent: Tuesday, February 05, 2002 3:01 AM To: pim@catarina.usc.edu Subject: [pim] Forwarding BSM Hello, If a router configured as candidate BSR, receives an BSM from elected BSR with lower priority than its own priority, it will transition to Pending BSR state ("Receive Non-preferred BSM from Elected BSR" event in Candidate BSR state machine). Shouldn't it be fowarding this received BSM to all other routers so that even they update their view of elected BSR? Otherwise others will accept BSM from this router only when old one times out! Thanks PNH From owner-pim@catarina.usc.edu Mon Feb 4 23:30:46 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13898 for ; Mon, 4 Feb 2002 23:30:46 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id UAA21560 for pim-list; Mon, 4 Feb 2002 20:10:43 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from mailweb18.rediffmail.com ([203.199.83.142]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id UAA21555 for ; Mon, 4 Feb 2002 20:10:41 -0800 (PST) Received: (qmail 28960 invoked by uid 510); 5 Feb 2002 04:08:47 -0000 Date: 5 Feb 2002 04:08:47 -0000 Message-ID: <20020205040847.28959.qmail@mailweb18.rediffmail.com> Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 05 Feb 2002 04:08:47 -0000 MIME-Version: 1.0 From: "P.Jhingran" Reply-To: "P.Jhingran" To: "John Zwiebel" Cc: pim@catarina.usc.edu, "Paras Trivedi" Subject: Re: Re: [pim] Differentiating PIM-SM from PIM-DM Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id UAA21556 Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit hi all, Thanx for replying. After going through your views I feel that though one can have an option like "sparse-dense mode" for PIM, using which one can communicate between PIM-DM and PIM-SM routers, but such an option will definitely be involving some new messages between the two routers. What I mean to say is interaction between them is chaotic unless one has some proprietary messages between the routers. These proprietary messages should prevent the "chaos" which Paras is refering to, basically detecting in which mode the other router is configured or may be like whether messages like register/registerstop can be processed or not etc...all implementation specific. Why not we can come out with some new standard (ietf-stuff) messages which can be used to identify the PIM mode configured on the neighbouring router???. thanx, P.Jhingran On Tue, 05 Feb 2002 John Zwiebel wrote : > Not exactly chaos. It depends on the toplogy. > > "ONCE UPON A TIME..." > > one could configure a dense router and a sparse router > next to one another to transition between a sparse and > a dense domain -- where 'dense' also includes DVMRP > areas. > > Paras did hint at this when he said "exceptional cases". > > The "sparseness" of a group is determined by whether or > not > a router knows about an RP for a given multicast group. > If > it does, then the route is sparse. If it doesn't the > route > is dense. > > FWIW: although it would appear at first glance that > dense-mode > PIM is useful (especially now with "state-refresh"), in > practice > it has not proven to be. Part of the reason is that > PIM-dense doesn't work well with the "expanding ring > search", > partly because of the fact that some routers throw away > packets with TTL of 1 or 0 if they aren't specifically > addressed > to an IP address on that router, resulting in duplicate > packet delivery in some topologies... And part of the > reason is that application developers don't understand > how PIM-dense works and so the result in certain > Also, sparse-mode can "do" everything that dense-mode > can and... > > in any case, SSM and bi-dir PIM may prove to be much > more > appropriate than any of the multicast routing protocols > now > used. > > 2cents > > Paras Trivedi wrote: > > > > Sparse or dense used to be a property of the > interface in PIMv1. > > But, in PIMv2, these days, the sparse or dense is a > property of > > a group or group range. So, the interface simply > needs to run PIM, > > regardless of any particular mode. (Although, in some > exceptional > > cases it is needed to run an interface in strictly > sparse or dense mode.) > > > > Most implementations (at least JunOS and IOS) allow > you to > > turn on PIM, regardless of the mode, with > ccommand. > > > > Yes, it'd be a misconfiguration to have sparse > configuration on > > one end of a link and dense, on another. And PIMv2 > hello does not > > carry this information. So, it cannot be detected > automatically. > > But, if you absolutely do this, then I guess, the > sparse router > > will do sparse thing (If DR, send register, send (*,G) > join) > > and dense router will do dense thing (flood and > expect to prune), for > > any combination of source/receiver/transit situation, > leading most > > likely to chaos. > > > > - Paras. > > > > > > > > > > > Hi all, > > > I have a trivial doubt.What shall happen if > PIM-SM and PIM-DM enabled interfaces are connected back > to back. > > > PIM-SM is enabled on router R1's interface 1 while > PIM-DM is enabled on interface 2. > > > > > > Router R1 <----------> Router R2 > > > PIM-SM PIM-DM > > > Interface 1 Interface 2 > > > > > > Is cisco or any other router able to distinguish > the above two modes?? The hello format is same for both > the modes and now it is up the to administrator to make > proper connections!! > > > regards, > > > Prashant > > > > > > > _______________________________________________ > > Pim-external mailing list > > Pim-external@m n/listinfo/pim-extern- > al From owner-pim@catarina.usc.edu Mon Feb 4 23:48:03 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14340 for ; Mon, 4 Feb 2002 23:48:02 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id UAA21629 for pim-list; Mon, 4 Feb 2002 20:23:21 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id UAA21624 for ; Mon, 4 Feb 2002 20:23:20 -0800 (PST) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g154Mn667978; Mon, 4 Feb 2002 20:22:49 -0800 (PST) (envelope-from paras@juniper.net) Received: (from paras@localhost) by garnet.juniper.net (8.11.5/8.11.3) id g154Mni59328; Mon, 4 Feb 2002 20:22:49 -0800 (PST) (envelope-from paras) From: Paras Trivedi Message-Id: <200202050422.g154Mni59328@garnet.juniper.net> Subject: Re: Re: [pim] Differentiating PIM-SM from PIM-DM To: learning_pim@rediffmail.com Date: Mon, 4 Feb 2002 20:22:49 -0800 (PST) Cc: john.zwiebel@procket.com (John Zwiebel), pim@catarina.usc.edu, paras@juniper.net (Paras Trivedi) In-Reply-To: <20020205040847.28959.qmail@mailweb18.rediffmail.com> from "P.Jhingran" at Feb 05, 2002 04:08:47 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Most of the chaos I was referring to, was when there is a receiver or source on the LAN that connects the two routers where one is sparse and another is dense (which is what I called, misconfiguration). For, interconnecting sparse domains and dense domains with a single p2p link, with each side configured appropriately, people have achieved the objective with non-properietry messages. You can look up on DWR (Domain Wide Reorts) in IDMR/MAGMA working groups, for solving some of the issues of sparse vs dense interconnect. Althogh, it would be cool if the admins could see the configured mode of the PIM neighbors via hello option (eventhough we know that configured mode may not be significant as mode is a property of group ranges, not interfaces). - Paras. > > > hi all, > Thanx for replying. After going through your views I feel that though one can have an option like "sparse-dense mode" for PIM, using which one can communicate between PIM-DM and PIM-SM routers, but such an option will definitely be involving some new messages between the two routers. What I mean to say is interaction between them is chaotic unless one has some proprietary messages between the routers. > These proprietary messages should prevent the "chaos" which Paras is refering to, basically detecting in which mode the other router is configured or may be like whether messages like register/registerstop can be processed or not etc...all implementation specific. > > Why not we can come out with some new standard (ietf-stuff) messages which can be used to identify the PIM mode configured on the neighbouring router???. > > thanx, > P.Jhingran > > On Tue, 05 Feb 2002 John Zwiebel wrote : > > Not exactly chaos. It depends on the toplogy. > > > > "ONCE UPON A TIME..." > > > > one could configure a dense router and a sparse router > > next to one another to transition between a sparse and > > a dense domain -- where 'dense' also includes DVMRP > > areas. > > > > Paras did hint at this when he said "exceptional cases". > > > > The "sparseness" of a group is determined by whether or > > not > > a router knows about an RP for a given multicast group. > > If > > it does, then the route is sparse. If it doesn't the > > route > > is dense. > > > > FWIW: although it would appear at first glance that > > dense-mode > > PIM is useful (especially now with "state-refresh"), in > > practice > > it has not proven to be. Part of the reason is that > > PIM-dense doesn't work well with the "expanding ring > > search", > > partly because of the fact that some routers throw away > > packets with TTL of 1 or 0 if they aren't specifically > > addressed > > to an IP address on that router, resulting in duplicate > > packet delivery in some topologies... And part of the > > reason is that application developers don't understand > > how PIM-dense works and so the result in certain > > Also, sparse-mode can "do" everything that dense-mode > > can and... > > > > in any case, SSM and bi-dir PIM may prove to be much > > more > > appropriate than any of the multicast routing protocols > > now > > used. > > > > 2cents > > > > Paras Trivedi wrote: > > > > > > Sparse or dense used to be a property of the > > interface in PIMv1. > > > But, in PIMv2, these days, the sparse or dense is a > > property of > > > a group or group range. So, the interface simply > > needs to run PIM, > > > regardless of any particular mode. (Although, in some > > exceptional > > > cases it is needed to run an interface in strictly > > sparse or dense mode.) > > > > > > Most implementations (at least JunOS and IOS) allow > > you to > > > turn on PIM, regardless of the mode, with > > ccommand. > > > > > > Yes, it'd be a misconfiguration to have sparse > > configuration on > > > one end of a link and dense, on another. And PIMv2 > > hello does not > > > carry this information. So, it cannot be detected > > automatically. > > > But, if you absolutely do this, then I guess, the > > sparse router > > > will do sparse thing (If DR, send register, send (*,G) > > join) > > > and dense router will do dense thing (flood and > > expect to prune), for > > > any combination of source/receiver/transit situation, > > leading most > > > likely to chaos. > > > > > > - Paras. > > > > > > > > > > > > > > > Hi all, > > > > I have a trivial doubt.What shall happen if > > PIM-SM and PIM-DM enabled interfaces are connected back > > to back. > > > > PIM-SM is enabled on router R1's interface 1 while > > PIM-DM is enabled on interface 2. > > > > > > > > Router R1 <----------> Router R2 > > > > PIM-SM PIM-DM > > > > Interface 1 Interface 2 > > > > > > > > Is cisco or any other router able to distinguish > > the above two modes?? The hello format is same for both > > the modes and now it is up the to administrator to make > > proper connections!! > > > > regards, > > > > Prashant > > > > > > > > > > _______________________________________________ > > > Pim-external mailing list > > > Pim-external@m > n/listinfo/pim-extern- > > al > > From owner-pim@catarina.usc.edu Tue Feb 5 06:14:49 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27179 for ; Tue, 5 Feb 2002 06:14:48 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id CAA23508 for pim-list; Tue, 5 Feb 2002 02:51:28 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from www.yahho.com (28.c210-85-16.ethome.net.tw [210.85.16.28]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id CAA23503; Tue, 5 Feb 2002 02:51:24 -0800 (PST) Date: Tue, 5 Feb 2002 02:51:24 -0800 (PST) Received: from party by pchome.com.tw with SMTP id JS3q3xGyaKG5YSPMqMe; Tue, 05 Feb 2002 19:00:09 +0800 Message-ID: From: 417@tpts6.seed.net.tw To: 2lu9eI0P@tpts8.seed.net.tw Subject: [pim] X-Mailer: friNhBfm6YbCUeU5FR9Eb Content-Type: text/plain; X-Priority: 3 X-MSMail-Priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by catarina.usc.edu id CAD23504 Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit 굼쫀쬋�劫@�單？疲볶滌�---셕�理膨� 쪾붕셕�弛訪綻볕瀅株P빌ㅝずㄼ걺캱쌓,쩳쩑갠О좽턗첿ず겉┮. 줄뇩ⓔ짦�\쫐쮀�~셕�痍單疲벳豊イ觀滌�,Ω첿4x6�@켲쪀춏6ㅈ! �磋S쬜ず촑,줄┳캯압쩮ず쩧��,㏀툹�~쩧곌퀿Ⅴ뷜쪿쩖�覡껐O압쩮,퀿ㄳΞ㎮Notebook┴쩧쩲! www.dcview.com.tw From owner-pim@catarina.usc.edu Tue Feb 5 10:29:44 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03808 for ; Tue, 5 Feb 2002 10:29:44 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id HAA24476 for pim-list; Tue, 5 Feb 2002 07:02:12 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from mailFA5.rediffmail.com ([202.54.124.150]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id HAA24471 for ; Tue, 5 Feb 2002 07:02:10 -0800 (PST) Received: (qmail 15511 invoked by uid 510); 5 Feb 2002 15:02:58 -0000 Date: 5 Feb 2002 15:02:58 -0000 Message-ID: <20020205150258.15510.qmail@mailFA5.rediffmail.com> Received: from unknown (203.197.138.194) by rediffmail.com via HTTP; 05 Feb 2002 15:02:58 -0000 MIME-Version: 1.0 From: "P.Jhingran" Reply-To: "P.Jhingran" To: pim@catarina.usc.edu Subject: [pim] Doubt regarding *,*,RP state maintenance Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id HAA24472 Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, According to the RFC 2719 section 4.4 (also in the latest 04 draft) a PMBR is supposed to do the following: "A PIM-SM component acts as a wildcard receiver for internally-reached sources if and only if any other component is a wildcard receiver for externally-reached sources. It does this by periodically sending (*,*,RP) Joins to all RPs for non-local groups...." Does this means that the PMBR is supposed to send (*,*,RP) Joins to all RPs present in the RP set list??? If so then there might be redundant traffic & (*,*,RP)state maintenance between the PMBR and some of the CRP's present in a domain !!...Can this be avoided somehow?? Thanx and regards, P.Jhingran From owner-pim@catarina.usc.edu Tue Feb 5 14:17:24 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14604 for ; Tue, 5 Feb 2002 14:17:23 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA25304 for pim-list; Tue, 5 Feb 2002 10:50:35 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from sundmz1.procket.com (dmz1.procket.com [65.174.124.36]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA25299 for ; Tue, 5 Feb 2002 10:50:34 -0800 (PST) Received: from miata.procket.com (unknown [10.1.1.1]) by sundmz1.procket.com (Postfix) with ESMTP id 7950123C29; Tue, 5 Feb 2002 10:41:35 -0800 (PST) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g15Io3r6010911; Tue, 5 Feb 2002 10:50:03 -0800 (PST) Received: from procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Feb 2002 10:50:01 -0800 Message-ID: <3C602951.105B99BD@procket.com> Date: Tue, 05 Feb 2002 10:49:54 -0800 From: John Zwiebel Reply-To: john.zwiebel@procket.com Organization: Procket Networks X-Mailer: Mozilla 4.73 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "P.Jhingran" Cc: pim@catarina.usc.edu, Paras Trivedi Subject: Re: [pim] Differentiating PIM-SM from PIM-DM References: <20020205040847.28959.qmail@mailweb18.rediffmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2002 18:50:01.0717 (UTC) FILETIME=[EAD2BA50:01C1AE75] Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit OPINION, OPINION, OPINION... In a previous life, I flew jets. After leaving that one, I messed around for a little while as a "business man" in a startup involved in Laser and microwave interferometry. Then I decided to 'get serious' about what I wanted to do with my life and got into telecommunications. First I used that to launch rockets and then I got into routers. With such a diverse background, I kind of consider myself to be a dilettante. Heck, there are any number of people on this list that have more training in networking and understand all the intricacies much better than I do. But in all that time, I learned something that I find is "best" described by my partner in the laser business. You have to know "when to -shoot- the engineer." My partner liked to say that all the time, but could never get around to shooting himself, which is why I'm not in routers. :-) What he was trying to say is that there comes a point in time where you have to decide that what you have is "good enough". You have to start questioning whether or not there is much to be gained by additional effort spent in further defining the 'product' or in this case the 'spec'. Without a doubt, it can -always- be better. The interaction between dense-mode PIM and sparse-mode PIM is one example of this. Another is deployment of (*,*,RP) trees. A third -might- be the percieved usefulness and requirement of dense-mode PIM at all. I submit that each of these represents a "problem" to be solved and as such, are fun and interesting. But that is because they are 'engineering' problems. As such, they do have very important relevance. The question I'd like you to think about is whether or not solving these problems is going to actually matter to the 'consumer'. I'm talking about the guy sitting at home who is going to be the mass consumer of multicast data. What is it that this guy needs? Is dense-mode important to him? Will he be receiving his data on a (*,*,RP) tree? An interesting article was in this morning's San Jose Mercury News: Pepsi commercial was most replayed during Super Bowl Sunday http://www0.mercurycenter.com/business/top/078619.htm Wow, people actually -like- to watch commercials. "What if" Pepsi decided to put its commercials out on the internet? Would it be via multicast or would they use an expensive Akami/Intomi distribution system? Of course, there are many, many more variables that would have to be considered here before a choice could be made. But, that is also true of whether or not dense-mode or (*,*,RP) trees are necessary. My point is -- now it the time to get out the 'good enough' version of multicast. It is time to 'shoot the engineer'. It is time to be 'practical'. Some questions to examine: -- Which is more important: Source Specific Multicast or (*,*,RP) trees? -- Who has the greatest potential of using IP multicast: a company that -must- guarantee delivery of data and is therefore willing to spend money on it, or one that is looking for the cheapest way of putting their content out there? -- Which is easier to implement: getting the network to reliably distribute SDR announcements, or creating a web page that returns the source and group information to the requester? -- Which is easier to implement: tuning the network to insure delivery of the first data packet an application might put out on the net or having the application send out a 30 second "test pattern" that allows the receivers to "tune in" before the transmission begins? Its important to recognize that I'm pushing the "easy" choice. App developers may not understand multicast because it gets into choices of (*,*,RP) trees and dense vs sparse and BGMP and a ton of arcane choices that they don't have time to understand -- especially ehen they just figured out how to get a TCP or UDP stream to carry their informaation. There's a science fiction story about a technologically advanced society that made some tremendous discoveries during a war they had with "inferiors". Yet the society that used the "good enough" choice, and responded fast enough was the one that won. An excellent historical example is the Mongol horde that nearly conquered the world. Of course, you can say that 'in the end' the Mongols lost because they couldn't adapt their form of government. And in the Sci Fi story, if you were to continue it, perhaps the technologically advanced societ would have been the one that started a resistance to overthrow their "evil masters". But, I'm not in this to -eventually- win. I passionately -just-know- that multicast is the right solution for many of the information distribution problems that are facing whatever organization you can think of. But if we get lost in arguing about the number of angels that can dance on the head of a 'PIM' then a viable IP multicast solution is not going to get deployed and isn't going to happen for a long, long, long time. Think of the 'evil empire' that we are up against. Content providers don't want to use multicast because they can make an excellent profit now using forms of distribution that don't even involve the internet at all. The internet is a threat to them because they end up losing control of the form of distribution. But how many times have you heard "artists" (let's talk specifically about recording artists) complain about how they are being held captive by some group of elitists (the "labels" for instance). How many are 'out there' that could take advantage of a simpler and cheaper distribution system? Where are these folks who aren't "in it for the money?" This is the group that IP multicast has to go after. And we go after them because -- "ta-dah" -- that's where the money is!!! IP multicast is the new 'assembly line'. It is the new 'mass marketing' corporation. It is the 'efficient mode of travel'. It is the way of allowing anyone -- anywhere a way of getting out their message. Whatever that message is. It removes the middle man. It frees the receiver from having to choose from the limited offerings of the networks (like cable TV did). And, in doing so, opens up a new opportunity for making gobs and gobs of money as the velocity of that money is increased by an order of magnitude. Consider Hollywood's dominance of the entertainment industry. Yes they are the "best" when it comes to making a movie. But look at all the inefficiencies. Why should Michael Eisner get paid millions and millions of dollars? Its because he has a monopoly on the distribution of product. People who make movies want to profit from them. The only way they can profit is if they gain Eisner's blessing. What if a content provider in Timbuktu were able to scrape together $5000 and was able to make a very compelling movie. Would Eisner support it? Would you ever see it? What if that movie were made available on the internet via a "good enough" delivery system that made a return on investment possible. If the movie is 'multicast' and encoded -- yes there will be some loss of revenue because of fraud on the part of the receivers -- will it provide enough credit card subscritions to encourage the content provider to try again? So, all this leads to asking those of you on this list, what is it you want to have happen with this IP multicast stuff you've been working on. Is it important to you that you have solved all the dense/sparse interaction problems? Is it important that (*,*,RP) trees are deployed? Or do you want to do something that is "good enough" and enables new ways for people to interact with each other. New ways that can be seen as socially "good" or ways that can be "mined" for 'lots-of-bucks'. Especially when the 'lots-of-bucks' approach will lead to the recognition of the need for alternate forms of ip multicast services that can only be realized if the sparse/dense and (*,*,RP) problems are solved. I've been doing IP multicast for nearly 10 years. It "ain't a goin' no where". I want to see it 'out there' and used. Providing solutions for problems that don't yet need to be solved, while ignoring the interoperation problems that are standing in the way of deploying a "good enough" solution is a way of commiting a slow and painful suicide. It is time to 'shoot the engineer'. It is time to make a robust, interoperable, and simple solution that will "prove" the viability of multicast so that you can work on all these other 'interesting' problems. We need something that is "good enough". I have an opinion on what that is -- I've stated it often enough that everyone 'should know' what it is. I had to be persuaded that it was the right choice, but now that I've been converted, the obviousness of that choice is extremely compelling. If you recognize that choice, then it should be obvious to you that getting (*,*,RP) trees to work just isn't important right now. Your boss may be telling you that you need the best PIM implementation possible, but what gives him the prescience to know that? Is he just "listening to the customer"? An excuse for not thinking about what really works and a way of avoiding having to "do something" about it. When a customer doesn't know what the product is, you have to teach him. Your customer isn't the people on this list. Multicast is in the "push" stage of technological evolution. Its time to get out there and push. 2cents "P.Jhingran" wrote: > > hi all, > Thanx for replying. After going through your views I feel that though one can have an option like "sparse-dense mode" for PIM, using which one can communicate between PIM-DM and PIM-SM routers, but such an option will definitely be involving some new messages between the two routers. What I mean to say is interaction between them is chaotic unless one has some proprietary messages between the routers. > These proprietary messages should prevent the "chaos" which Paras is refering to, basically detecting in which mode the other router is configured or may be like whether messages like register/registerstop can be processed or not etc...all implementation specific. > > Why not we can come out with some new standard (ietf-stuff) messages which can be used to identify the PIM mode configured on the neighbouring router???. > > thanx, > P.Jhingran > > On Tue, 05 Feb 2002 John Zwiebel wrote : > > Not exactly chaos. It depends on the toplogy. > > > > "ONCE UPON A TIME..." > > > > one could configure a dense router and a sparse router > > next to one another to transition between a sparse and > > a dense domain -- where 'dense' also includes DVMRP > > areas. > > > > Paras did hint at this when he said "exceptional cases". > > > > The "sparseness" of a group is determined by whether or > > not > > a router knows about an RP for a given multicast group. > > If > > it does, then the route is sparse. If it doesn't the > > route > > is dense. > > > > FWIW: although it would appear at first glance that > > dense-mode > > PIM is useful (especially now with "state-refresh"), in > > practice > > it has not proven to be. Part of the reason is that > > PIM-dense doesn't work well with the "expanding ring > > search", > > partly because of the fact that some routers throw away > > packets with TTL of 1 or 0 if they aren't specifically > > addressed > > to an IP address on that router, resulting in duplicate > > packet delivery in some topologies... And part of the > > reason is that application developers don't understand > > how PIM-dense works and so the result in certain > > toplogies > > is unexpected. > > > > Also, sparse-mode can "do" everything that dense-mode > > can and... > > > > in any case, SSM and bi-dir PIM may prove to be much > > more > > appropriate than any of the multicast routing protocols > > now > > used. > > > > 2cents > > > > Paras Trivedi wrote: > > > > > > Sparse or dense used to be a property of the > > interface in PIMv1. > > > But, in PIMv2, these days, the sparse or dense is a > > property of > > > a group or group range. So, the interface simply > > needs to run PIM, > > > regardless of any particular mode. (Although, in some > > exceptional > > > cases it is needed to run an interface in strictly > > sparse or dense mode.) > > > > > > Most implementations (at least JunOS and IOS) allow > > you to > > > turn on PIM, regardless of the mode, with > > ccommand. > > > > > > Yes, it'd be a misconfiguration to have sparse > > configuration on > > > one end of a link and dense, on another. And PIMv2 > > hello does not > > > carry this information. So, it cannot be detected > > automatically. > > > But, if you absolutely do this, then I guess, the > > sparse router > > > will do sparse thing (If DR, send register, send (*,G) > > join) > > > and dense router will do dense thing (flood and > > expect to prune), for > > > any combination of source/receiver/transit situation, > > leading most > > > likely to chaos. > > > > > > - Paras. > > > > > > > > > > > > > > > Hi all, > > > > I have a trivial doubt.What shall happen if > > PIM-SM and PIM-DM enabled interfaces are connected back > > to back. > > > > PIM-SM is enabled on router R1's interface 1 while > > PIM-DM is enabled on interface 2. > > > > > > > > Router R1 <----------> Router R2 > > > > PIM-SM PIM-DM > > > > Interface 1 Interface 2 > > > > > > > > Is cisco or any other router able to distinguish > > the above two modes?? The hello format is same for both > > the modes and now it is up the to administrator to make > > proper connections!! > > > > regards, > > > > Prashant > > > > > > > > > > _______________________________________________ > > > Pim-external mailing list > > > Pim-external@mailist.procket.com > > > http://mailist.procket.com/mailman/listinfo/pim-extern- > > al > From owner-pim@catarina.usc.edu Tue Feb 5 15:13:53 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17453 for ; Tue, 5 Feb 2002 15:13:52 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA25509 for pim-list; Tue, 5 Feb 2002 11:42:44 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from sundmz2.procket.com (dmz2.procket.com [65.174.124.37]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA25504 for ; Tue, 5 Feb 2002 11:42:43 -0800 (PST) Received: from miata.procket.com (unknown [10.1.1.1]) by sundmz2.procket.com (Postfix) with ESMTP id 5E1F934438; Tue, 5 Feb 2002 11:44:48 -0800 (PST) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g15JgCr6028778; Tue, 5 Feb 2002 11:42:13 -0800 (PST) Received: from procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Feb 2002 11:42:12 -0800 Message-ID: <3C603593.B8FFC675@procket.com> Date: Tue, 05 Feb 2002 11:42:12 -0800 From: John Zwiebel Reply-To: john.zwiebel@procket.com Organization: Procket Networks X-Mailer: Mozilla 4.73 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: anttoni.nurkka@alliedtelesyn.co.nz Cc: pim@catarina.usc.edu Subject: Re: [pim] Comments re: draft-ietf-pim-sm-v2-new-04 References: <3C5EA729.4043.18AFE93@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2002 19:42:12.0723 (UTC) FILETIME=[350C5430:01C1AE7D] Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Anttoni Nurkka wrote: > > Question1: is this the correct interpretation? Yes. FWIW though, I had to read your 'interpretation' several times to understand what you were asking. So, what's in the spec, although murky, perhaps can't be expressed much better than it already is. 2 cents > Question2: For an actual (*,G) assert (S=INADDR_ANY, RPT bit set), does > the state of any (S,G) assert state machine need to be considered? (This, > obviously, is where I am confused) No. Providing that one recognizes that an (S,G) entry and an (S,G,RP-bit) entry are for 2 different distribution trees suh that when you ask "any (S,G) assert state..." you are referring only to the source-tree and you are not confusing it with the shared tree. -and- you recognize that a source-tree assert always wins over a shared-tree assert. So, if you have a (*,G) with the same olist as the (S,G) and the same IIF as the (S,G) and you receive a (*,G) assert, you do not prune off the (S,G) olist, but will see data on that OIF and send an (S,G) assert. (Which could mean that -- depending on what you meant by your question -- that my answer 'should have been' "Yes". But the (S,G) assert isn't sent because of the (*,G) assert so I'll stick with my "No" answer. ) From owner-pim@catarina.usc.edu Tue Feb 5 15:58:41 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19091 for ; Tue, 5 Feb 2002 15:58:40 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA25831 for pim-list; Tue, 5 Feb 2002 12:37:21 -0800 (PST) Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA25825 for ; Tue, 5 Feb 2002 12:37:20 -0800 (PST) Received: from maroon.jnpr.net (maroon.jnpr.net [172.24.244.36]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g15Kax610745; Tue, 5 Feb 2002 12:36:59 -0800 (PST) (envelope-from shep@juniper.net) Received: from localhost (shep@localhost) by maroon.jnpr.net (8.11.3/8.11.3) with ESMTP id g15Kaxa22692; Tue, 5 Feb 2002 12:36:59 -0800 (PST) (envelope-from shep@juniper.net) X-Authentication-Warning: maroon.jnpr.net: shep owned process doing -bs Date: Tue, 5 Feb 2002 12:36:59 -0800 (PST) From: Greg Shepherd X-X-Sender: To: John Zwiebel cc: "P.Jhingran" , , Paras Trivedi Subject: Re: [pim] Differentiating PIM-SM from PIM-DM In-Reply-To: <3C602951.105B99BD@procket.com> Message-ID: <20020205123614.Q6823-100000@maroon.jnpr.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pim@catarina.usc.edu Precedence: bulk Reverend John has spoken! -I'm not being sarcastic and he knows it. Thanks John, Greg On Tue, 5 Feb 2002, John Zwiebel wrote: > OPINION, OPINION, OPINION... > > In a previous life, I flew jets. After leaving that one, I > messed around for a little while as a "business man" in a > startup involved in Laser and microwave interferometry. Then > I decided to 'get serious' about what I wanted to do with my > life and got into telecommunications. First I used that to > launch rockets and then I got into routers. > > With such a diverse background, I kind of consider myself to > be a dilettante. Heck, there are any number of people on this > list that have more training in networking and understand all > the intricacies much better than I do. > > But in all that time, I learned something that I find is "best" > described by my partner in the laser business. You have to > know "when to -shoot- the engineer." My partner liked to say > that all the time, but could never get around to shooting himself, > which is why I'm not in routers. :-) > > What he was trying to say is that there comes a point in time > where you have to decide that what you have is "good enough". You > have to start questioning whether or not there is much to be gained > by additional effort spent in further defining the 'product' or > in this case the 'spec'. Without a doubt, it can -always- be > better. > > The interaction between dense-mode PIM and sparse-mode PIM is one > example of this. Another is deployment of (*,*,RP) trees. A third > -might- be the percieved usefulness and requirement of dense-mode > PIM at all. > > I submit that each of these represents a "problem" to be solved > and as such, are fun and interesting. But that is because they > are 'engineering' problems. As such, they do have very important > relevance. > > The question I'd like you to think about is whether or not solving > these problems is going to actually matter to the 'consumer'. I'm > talking about the guy sitting at home who is going to be the mass > consumer of multicast data. What is it that this guy needs? Is > dense-mode important to him? Will he be receiving his data on > a (*,*,RP) tree? > > An interesting article was in this morning's San Jose Mercury News: > Pepsi commercial was most replayed during Super Bowl Sunday > http://www0.mercurycenter.com/business/top/078619.htm > > Wow, people actually -like- to watch commercials. > > "What if" Pepsi decided to put its commercials out on the internet? > Would it be via multicast or would they use an expensive Akami/Intomi > distribution system? Of course, there are many, many more variables > that would have to be considered here before a choice could be made. > But, that is also true of whether or not dense-mode or (*,*,RP) trees > are necessary. > > My point is -- now it the time to get out the 'good enough' version > of multicast. It is time to 'shoot the engineer'. It is time to > be 'practical'. > > Some questions to examine: > -- Which is more important: Source Specific Multicast or (*,*,RP) trees? > -- Who has the greatest potential of using IP multicast: a company > that -must- guarantee delivery of data and is therefore willing > to spend money on it, or one that is looking for the cheapest way > of putting their content out there? > -- Which is easier to implement: getting the network to reliably > distribute SDR announcements, or creating a web page that returns > the source and group information to the requester? > -- Which is easier to implement: tuning the network to insure > delivery of the first data packet an application might put out > on the net or having the application send out a 30 second "test > pattern" that allows the receivers to "tune in" before the > transmission begins? > > Its important to recognize that I'm pushing the "easy" choice. App > developers may not understand multicast because it gets into choices > of (*,*,RP) trees and dense vs sparse and BGMP and a ton of arcane > choices that they don't have time to understand -- especially ehen they > just figured out how to get a TCP or UDP stream to carry their > informaation. > > There's a science fiction story about a technologically advanced > society that made some tremendous discoveries during a war they > had with "inferiors". Yet the society that used the "good enough" > choice, and responded fast enough was the one that won. An excellent > historical example is the Mongol horde that nearly conquered the > world. > > Of course, you can say that 'in the end' the Mongols lost because > they couldn't adapt their form of government. And in the Sci Fi > story, if you were to continue it, perhaps the technologically > advanced societ would have been the one that started a resistance > to overthrow their "evil masters". But, I'm not in this to > -eventually- win. I passionately -just-know- that multicast is > the right solution for many of the information distribution problems > that are facing whatever organization you can think of. > > But if we get lost in arguing about the number of angels that > can dance on the head of a 'PIM' then a viable IP > multicast solution is not going to get deployed and isn't going > to happen for a long, long, long time. > > Think of the 'evil empire' that we are up against. Content providers > don't want to use multicast because they can make an excellent > profit now using forms of distribution that don't even involve the > internet at all. The internet is a threat to them because they > end up losing control of the form of distribution. > > But how many times have you heard "artists" (let's talk specifically > about recording artists) complain about how they are being held > captive by some group of elitists (the "labels" for instance). > How many are 'out there' that could take advantage of a simpler > and cheaper distribution system? Where are these folks who > aren't "in it for the money?" This is the group that IP multicast > has to go after. > > And we go after them because -- "ta-dah" -- that's where the money > is!!! > > IP multicast is the new 'assembly line'. It is the new 'mass marketing' > corporation. It is the 'efficient mode of travel'. It is the way > of allowing anyone -- anywhere a way of getting out their message. > Whatever that message is. It removes the middle man. It frees > the receiver from having to choose from the limited offerings of > the networks (like cable TV did). And, in doing so, opens up a > new opportunity for making gobs and gobs of money as the velocity > of that money is increased by an order of magnitude. > > Consider Hollywood's dominance of the entertainment industry. Yes > they are the "best" when it comes to making a movie. But look at > all the inefficiencies. Why should Michael Eisner get paid millions > and millions of dollars? Its because he has a monopoly on the > distribution of product. People who make movies want to profit > from them. The only way they can profit is if they gain Eisner's > blessing. What if a content provider in Timbuktu were able to > scrape together $5000 and was able to make a very compelling movie. > Would Eisner support it? Would you ever see it? What if that movie > were made available on the internet via a "good enough" delivery > system that made a return on investment possible. If the movie > is 'multicast' and encoded -- yes there will be some loss of revenue > because of fraud on the part of the receivers -- will it provide > enough credit card subscritions to encourage the content provider > to try again? > > So, all this leads to asking those of you on this list, what is it > you want to have happen with this IP multicast stuff you've been > working on. Is it important to you that you have solved all the > dense/sparse interaction problems? Is it important that (*,*,RP) > trees are deployed? > > Or do you want to do something that is "good enough" and enables > new ways for people to interact with each other. New ways that > can be seen as socially "good" or ways that can be "mined" for > 'lots-of-bucks'. Especially when the 'lots-of-bucks' approach will > lead to the recognition of the need for alternate forms of > ip multicast services that can only be realized if the sparse/dense > and (*,*,RP) problems are solved. > > I've been doing IP multicast for nearly 10 years. It "ain't a goin' > no where". I want to see it 'out there' and used. Providing solutions > for problems that don't yet need to be solved, while ignoring the > interoperation problems that are standing in the way of deploying > a "good enough" solution is a way of commiting a slow and painful > suicide. > > It is time to 'shoot the engineer'. It is time to make a robust, > interoperable, and simple solution that will "prove" the viability > of multicast so that you can work on all these other 'interesting' > problems. We need something that is "good enough". > > I have an opinion on what that is -- I've stated it often enough > that everyone 'should know' what it is. I had to be persuaded that > it was the right choice, but now that I've been converted, the > obviousness of that choice is extremely compelling. If you recognize > that choice, then it should be obvious to you that getting (*,*,RP) > trees to work just isn't important right now. Your boss may be > telling you that you need the best PIM implementation possible, but > what gives him the prescience to know that? Is he just "listening > to the customer"? An excuse for not thinking about what really > works and a way of avoiding having to "do something" about it. > When a customer doesn't know what the product is, you have to teach > him. Your customer isn't the people on this list. > > Multicast is in the "push" stage of technological evolution. Its > time to get out there and push. > > 2cents > > "P.Jhingran" wrote: > > > > hi all, > > Thanx for replying. After going through your views I feel that though one can have an option like "sparse-dense mode" for PIM, using which one can communicate between PIM-DM and PIM-SM routers, but such an option will definitely be involving some new messages between the two routers. What I mean to say is interaction between them is chaotic unless one has some proprietary messages between the routers. > > These proprietary messages should prevent the "chaos" which Paras is refering to, basically detecting in which mode the other router is configured or may be like whether messages like register/registerstop can be processed or not etc...all implementation specific. > > > > Why not we can come out with some new standard (ietf-stuff) messages which can be used to identify the PIM mode configured on the neighbouring router???. > > > > thanx, > > P.Jhingran > > > > On Tue, 05 Feb 2002 John Zwiebel wrote : > > > Not exactly chaos. It depends on the toplogy. > > > > > > "ONCE UPON A TIME..." > > > > > > one could configure a dense router and a sparse router > > > next to one another to transition between a sparse and > > > a dense domain -- where 'dense' also includes DVMRP > > > areas. > > > > > > Paras did hint at this when he said "exceptional cases". > > > > > > The "sparseness" of a group is determined by whether or > > > not > > > a router knows about an RP for a given multicast group. > > > If > > > it does, then the route is sparse. If it doesn't the > > > route > > > is dense. > > > > > > FWIW: although it would appear at first glance that > > > dense-mode > > > PIM is useful (especially now with "state-refresh"), in > > > practice > > > it has not proven to be. Part of the reason is that > > > PIM-dense doesn't work well with the "expanding ring > > > search", > > > partly because of the fact that some routers throw away > > > packets with TTL of 1 or 0 if they aren't specifically > > > addressed > > > to an IP address on that router, resulting in duplicate > > > packet delivery in some topologies... And part of the > > > reason is that application developers don't understand > > > how PIM-dense works and so the result in certain > > > toplogies > > > is unexpected. > > > > > > Also, sparse-mode can "do" everything that dense-mode > > > can and... > > > > > > in any case, SSM and bi-dir PIM may prove to be much > > > more > > > appropriate than any of the multicast routing protocols > > > now > > > used. > > > > > > 2cents > > > > > > Paras Trivedi wrote: > > > > > > > > Sparse or dense used to be a property of the > > > interface in PIMv1. > > > > But, in PIMv2, these days, the sparse or dense is a > > > property of > > > > a group or group range. So, the interface simply > > > needs to run PIM, > > > > regardless of any particular mode. (Although, in some > > > exceptional > > > > cases it is needed to run an interface in strictly > > > sparse or dense mode.) > > > > > > > > Most implementations (at least JunOS and IOS) allow > > > you to > > > > turn on PIM, regardless of the mode, with > > > ccommand. > > > > > > > > Yes, it'd be a misconfiguration to have sparse > > > configuration on > > > > one end of a link and dense, on another. And PIMv2 > > > hello does not > > > > carry this information. So, it cannot be detected > > > automatically. > > > > But, if you absolutely do this, then I guess, the > > > sparse router > > > > will do sparse thing (If DR, send register, send (*,G) > > > join) > > > > and dense router will do dense thing (flood and > > > expect to prune), for > > > > any combination of source/receiver/transit situation, > > > leading most > > > > likely to chaos. > > > > > > > > - Paras. > > > > > > > > > > > > > > > > > > > Hi all, > > > > > I have a trivial doubt.What shall happen if > > > PIM-SM and PIM-DM enabled interfaces are connected back > > > to back. > > > > > PIM-SM is enabled on router R1's interface 1 while > > > PIM-DM is enabled on interface 2. > > > > > > > > > > Router R1 <----------> Router R2 > > > > > PIM-SM PIM-DM > > > > > Interface 1 Interface 2 > > > > > > > > > > Is cisco or any other router able to distinguish > > > the above two modes?? The hello format is same for both > > > the modes and now it is up the to administrator to make > > > proper connections!! > > > > > regards, > > > > > Prashant > > > > > > > > > > > > > _______________________________________________ > > > > Pim-external mailing list > > > > Pim-external@mailist.procket.com > > > > http://mailist.procket.com/mailman/listinfo/pim-extern- > > > al > > > From owner-pim@catarina.usc.edu Tue Feb 5 20:09:12 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26735 for ; Tue, 5 Feb 2002 20:09:12 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA30902 for pim-list; Tue, 5 Feb 2002 16:36:48 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from delta.interbusiness.it (www.sec-srl.it [151.99.207.2]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA30897 for ; Tue, 5 Feb 2002 16:36:46 -0800 (PST) From: TermQuotes@eudoramail.com Received: from mx2.eudoramail.com (dai-tx1a-147.rasserver.net [204.32.146.147]) by delta.interbusiness.it with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DM2G81RV; Wed, 6 Feb 2002 01:12:55 +0100 Message-ID: <000043e52782$000041ad$00005aba@mx2.eudoramail.com> To: Subject: [pim] Are You Paying Too Much For Life Insurance? MXNW Date: Tue, 05 Feb 2002 18:36:08 -1800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reply-To: TermQuotes@eudoramail.com Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable

    M= ost likely, YES !

    Here's why.&= nbsp; Fierce ... take no prisoner ... insurance industry PRICE WARS have driven premiums DOWN, and = down, and down --30 -- 40 -- 50 -- even 70% from where they were just a short time ago!

    YOUR INSURANCE COMPANY DOESN'T WANT YOU TO READ THIS= ...=

    They will continue to take your money, while o= ffering lower rates (up to 50%, even 70% lower) to new buyers.

    BUT DON'T TAKE OUR WORD FOR IT<= span style=3D"font-size:16.0pt;mso-bidi-font-size: 12.0pt">... Visit

    http://www.lifeinsurance.net.cn/email/

    and request an online quote today.&nbs= p; Be prepared to be surprised by how cheaply you can buy large amounts of term life insurance!

     

    If you think, that you will not benefit from t= his correspondence, please reply with =FFFFFF93remove key=FFFFFF94 as the = subject matter.

     

    From owner-pim@catarina.usc.edu Wed Feb 6 13:35:10 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27907 for ; Wed, 6 Feb 2002 13:35:08 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA32567 for pim-list; Wed, 6 Feb 2002 10:14:31 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA32562 for ; Wed, 6 Feb 2002 10:14:30 -0800 (PST) Received: from voyager.colo.ibsystems.com ([216.142.234.101]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA18797 for ; Wed, 6 Feb 2002 07:08:25 -0800 (PST) Received: from wookie (wookie.ibsystems.com [216.142.234.105]) by voyager.colo.ibsystems.com (8.10.2/8.10.2) with SMTP id g16F41727334; Wed, 6 Feb 2002 07:04:01 -0800 (PST) MIME-Version: 1.0 Reply-To: subrata_csg@dacafe.com Date: Wed, 6 Feb 2002 07:03:39 -0800 From: "Subrata Sa" Message-Id: <1013007819.mailspinnerdV3.2.5.3@smtp.dacafe.com> To: pim@catarina.usc.edu Subject: [pim] Join triggered by IGMP V3 Report (Cisco router) Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, I'm using Cisco 7200, IOS version is 12.2(3.6)T2. The router do not send Join (S, G) upon receiving IGMP V3 Report (include S). IGMP debug on the router shows that the reports are for group G and intend to include S (mode is ALLOW_NEW_SOURCES). The router is the DR for the downstream interface and IGMP router version is set to V3 on the router. Does that version support the feature or it is on the road map? Thanks in advance, Subrata ------------------------------ Subrata Sa Advance Network Division Communication Solutions Group Agilent Technologies ------------------------------ _____________________________________________________________ From owner-pim@catarina.usc.edu Wed Feb 6 13:41:18 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28041 for ; Wed, 6 Feb 2002 13:41:17 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA32580 for pim-list; Wed, 6 Feb 2002 10:15:25 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA32575 for ; Wed, 6 Feb 2002 10:15:24 -0800 (PST) Received: from voyager.colo.ibsystems.com ([216.142.234.101]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA27174 for ; Wed, 6 Feb 2002 07:19:49 -0800 (PST) Received: from wookie (wookie.ibsystems.com [216.142.234.105]) by voyager.colo.ibsystems.com (8.10.2/8.10.2) with SMTP id g16FFM708119; Wed, 6 Feb 2002 07:15:22 -0800 (PST) MIME-Version: 1.0 Reply-To: subrata_csg@dacafe.com Date: Wed, 6 Feb 2002 07:15:00 -0800 From: "Subrata Sa" Message-Id: <1013008500.mailspinnerdV3.2.5.3@smtp.dacafe.com> To: pim@catarina.usc.edu Subject: [pim] Re: Join triggered by IGMP V3 Report (Cisco router) Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi, Just to add more. It sends Join(*, G) towards RP instead of sending Join (S, G) towards source. Topology is as follows: R RP | | +---X---+ | | H R: router towards source S RP: Rendezvous point X: Cisco router H: Host sending IGMP V3 Report Thanks, Subrata ---------Included Message---------- >Date: Wed, 6 Feb 2002 07:03:39 -0800 >From: "Subrata Sa" >Reply-To: >To: >Subject: Join triggered by IGMP V3 Report (Cisco router) > > >Hi, > >I'm using Cisco 7200, IOS version is 12.2(3.6)T2. The >router do not send Join (S, G) upon receiving IGMP V3 >Report (include S). IGMP debug on the router shows that >the reports are for group G and intend to include S >(mode is ALLOW_NEW_SOURCES). > >The router is the DR for the downstream interface and >IGMP router version is set to V3 on the router. > >Does that version support the feature or it is on >the road map? > >Thanks in advance, >Subrata > >------------------------------ >Subrata Sa >Advance Network Division >Communication Solutions Group >Agilent Technologies >------------------------------ >_____________________________________________________________ > > > ---------End of Included Message---------- ------------------------------ Subrata Sa Advance Network Division Communication Solutions Group Agilent Technologies ------------------------------ _____________________________________________________________ From owner-pim@catarina.usc.edu Wed Feb 6 13:43:54 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28113 for ; Wed, 6 Feb 2002 13:43:53 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA32590 for pim-list; Wed, 6 Feb 2002 10:16:04 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA32585 for ; Wed, 6 Feb 2002 10:16:03 -0800 (PST) Received: from voyager.colo.ibsystems.com ([216.142.234.101]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA00951 for ; Wed, 6 Feb 2002 07:25:16 -0800 (PST) Received: from wookie (wookie.ibsystems.com [216.142.234.105]) by voyager.colo.ibsystems.com (8.10.2/8.10.2) with SMTP id g16FKr713237; Wed, 6 Feb 2002 07:20:53 -0800 (PST) MIME-Version: 1.0 Reply-To: subrata_csg@dacafe.com Date: Wed, 6 Feb 2002 07:20:31 -0800 From: "Subrata Sa" Message-Id: <1013008831.mailspinnerdV3.2.5.3@smtp.dacafe.com> To: pim@catarina.usc.edu Subject: [pim] Re: Join triggered by IGMP V3 Report (Cisco router) Sender: owner-pim@catarina.usc.edu Precedence: bulk The topology does not look right in the mail. Host H is connected to the third interface (downstream )of router X. ---------Included Message---------- >Date: Wed, 6 Feb 2002 07:15:00 -0800 >From: "Subrata Sa" >Reply-To: >To: >Subject: Re: Join triggered by IGMP V3 Report (Cisco router) > > >Hi, > >Just to add more. It sends Join(*, G) towards RP instead >of sending Join (S, G) towards source. Topology is as follows: > >R RP >| | >+---X---+ >| >| >H > >R: router towards source S >RP: Rendezvous point >X: Cisco router >H: Host sending IGMP V3 Report > >Thanks, >Subrata > >---------Included Message---------- >>Date: Wed, 6 Feb 2002 07:03:39 -0800 >>From: "Subrata Sa" >>Reply-To: >>To: >>Subject: Join triggered by IGMP V3 Report (Cisco router) >> >> >>Hi, >> >>I'm using Cisco 7200, IOS version is 12.2(3.6)T2. The >>router do not send Join (S, G) upon receiving IGMP V3 >>Report (include S). IGMP debug on the router shows that >>the reports are for group G and intend to include S >>(mode is ALLOW_NEW_SOURCES). >> >>The router is the DR for the downstream interface and >>IGMP router version is set to V3 on the router. >> >>Does that version support the feature or it is on >>the road map? >> >>Thanks in advance, >>Subrata >> >>------------------------------ >>Subrata Sa >>Advance Network Division >>Communication Solutions Group >>Agilent Technologies >>------------------------------ >>_____________________________________________________________ >> >> >> >---------End of Included Message---------- > >------------------------------ >Subrata Sa >Advance Network Division >Communication Solutions Group >Agilent Technologies >------------------------------ >_____________________________________________________________ > > > ---------End of Included Message---------- ------------------------------ Subrata Sa Advance Network Division Communication Solutions Group Agilent Technologies ------------------------------ _____________________________________________________________ From owner-pim@catarina.usc.edu Wed Feb 6 14:16:39 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28958 for ; Wed, 6 Feb 2002 14:16:39 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA33370 for pim-list; Wed, 6 Feb 2002 10:56:48 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from mailweb14.rediffmail.com ([203.199.83.26]) by catarina.usc.edu (8.9.3/8.9.3) with SMTP id KAA33365 for ; Wed, 6 Feb 2002 10:56:46 -0800 (PST) Received: (qmail 20422 invoked by uid 510); 6 Feb 2002 09:55:23 -0000 Date: 6 Feb 2002 09:55:23 -0000 Message-ID: <20020206095523.20421.qmail@mailweb14.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 06 Feb 2002 09:55:23 -0000 MIME-Version: 1.0 From: "Bakar" Reply-To: "Bakar" To: pim@catarina.usc.edu Subject: [pim] Sending (*,*,RP) J in a PMBR Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id KAA33366 Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Greetings, In a PMBR when wildcard receiver components are present, it should send (*,*,RP) to all the RP in the PIM domain - draft says so. My question: Can a implementation send (*,*,RP)J to all C-RP it comes to know of ? instead of selecting the RP from the BSM, just send it to all C-RP ? thanx & regards Bakar From owner-pim@catarina.usc.edu Wed Feb 6 14:37:17 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29535 for ; Wed, 6 Feb 2002 14:37:17 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA33486 for pim-list; Wed, 6 Feb 2002 11:09:16 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA33481 for ; Wed, 6 Feb 2002 11:09:15 -0800 (PST) Received: from mail1.cisco.com (mail1.cisco.com [171.68.225.60]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA23301 for ; Wed, 6 Feb 2002 07:58:12 -0800 (PST) Received: from bwilliam-t20.cisco.com (sjc-vpn2-268.cisco.com [10.21.113.12]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA26100; Wed, 6 Feb 2002 07:55:45 -0800 (PST) Message-Id: <4.3.2.7.2.20020206094909.00b4abc8@mail1.cisco.com> X-Sender: bwilliam@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Feb 2002 09:50:47 -0600 To: john.zwiebel@procket.com, "P.Jhingran" From: Beau Williamson Subject: Re: [pim] Differentiating PIM-SM from PIM-DM Cc: pim@catarina.usc.edu, Paras Trivedi In-Reply-To: <3C602951.105B99BD@procket.com> References: <20020205040847.28959.qmail@mailweb18.rediffmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pim@catarina.usc.edu Precedence: bulk John, I pretty sure I've told this before, but I think you missed your true calling. :) :) :) :) Beau Williamson At 12:49 PM 2/5/2002, John Zwiebel wrote: >OPINION, OPINION, OPINION... > > In a previous life, I flew jets. After leaving that one, I > messed around for a little while as a "business man" in a > startup involved in Laser and microwave interferometry. Then > I decided to 'get serious' about what I wanted to do with my > life and got into telecommunications. First I used that to > launch rockets and then I got into routers. > > With such a diverse background, I kind of consider myself to > be a dilettante. Heck, there are any number of people on this > list that have more training in networking and understand all > the intricacies much better than I do. > > But in all that time, I learned something that I find is "best" > described by my partner in the laser business. You have to > know "when to -shoot- the engineer." My partner liked to say > that all the time, but could never get around to shooting himself, > which is why I'm not in routers. :-) > > What he was trying to say is that there comes a point in time > where you have to decide that what you have is "good enough". You > have to start questioning whether or not there is much to be gained > by additional effort spent in further defining the 'product' or > in this case the 'spec'. Without a doubt, it can -always- be > better. > > The interaction between dense-mode PIM and sparse-mode PIM is one > example of this. Another is deployment of (*,*,RP) trees. A third > -might- be the percieved usefulness and requirement of dense-mode > PIM at all. > > I submit that each of these represents a "problem" to be solved > and as such, are fun and interesting. But that is because they > are 'engineering' problems. As such, they do have very important > relevance. > > The question I'd like you to think about is whether or not solving > these problems is going to actually matter to the 'consumer'. I'm > talking about the guy sitting at home who is going to be the mass > consumer of multicast data. What is it that this guy needs? Is > dense-mode important to him? Will he be receiving his data on > a (*,*,RP) tree? > > An interesting article was in this morning's San Jose Mercury News: > Pepsi commercial was most replayed during Super Bowl Sunday > http://www0.mercurycenter.com/business/top/078619.htm > > Wow, people actually -like- to watch commercials. > > "What if" Pepsi decided to put its commercials out on the internet? > Would it be via multicast or would they use an expensive Akami/Intomi > distribution system? Of course, there are many, many more variables > that would have to be considered here before a choice could be made. > But, that is also true of whether or not dense-mode or (*,*,RP) trees > are necessary. > > My point is -- now it the time to get out the 'good enough' version > of multicast. It is time to 'shoot the engineer'. It is time to > be 'practical'. > > Some questions to examine: > -- Which is more important: Source Specific Multicast or (*,*,RP) trees? > -- Who has the greatest potential of using IP multicast: a company > that -must- guarantee delivery of data and is therefore willing > to spend money on it, or one that is looking for the cheapest way > of putting their content out there? > -- Which is easier to implement: getting the network to reliably > distribute SDR announcements, or creating a web page that returns > the source and group information to the requester? > -- Which is easier to implement: tuning the network to insure > delivery of the first data packet an application might put out > on the net or having the application send out a 30 second "test > pattern" that allows the receivers to "tune in" before the > transmission begins? > > Its important to recognize that I'm pushing the "easy" choice. App > developers may not understand multicast because it gets into choices > of (*,*,RP) trees and dense vs sparse and BGMP and a ton of arcane > choices that they don't have time to understand -- especially ehen they > just figured out how to get a TCP or UDP stream to carry their > informaation. > > There's a science fiction story about a technologically advanced > society that made some tremendous discoveries during a war they > had with "inferiors". Yet the society that used the "good enough" > choice, and responded fast enough was the one that won. An excellent > historical example is the Mongol horde that nearly conquered the > world. > > Of course, you can say that 'in the end' the Mongols lost because > they couldn't adapt their form of government. And in the Sci Fi > story, if you were to continue it, perhaps the technologically > advanced societ would have been the one that started a resistance > to overthrow their "evil masters". But, I'm not in this to > -eventually- win. I passionately -just-know- that multicast is > the right solution for many of the information distribution problems > that are facing whatever organization you can think of. > > But if we get lost in arguing about the number of angels that > can dance on the head of a 'PIM' then a viable IP > multicast solution is not going to get deployed and isn't going > to happen for a long, long, long time. > > Think of the 'evil empire' that we are up against. Content providers > don't want to use multicast because they can make an excellent > profit now using forms of distribution that don't even involve the > internet at all. The internet is a threat to them because they > end up losing control of the form of distribution. > > But how many times have you heard "artists" (let's talk specifically > about recording artists) complain about how they are being held > captive by some group of elitists (the "labels" for instance). > How many are 'out there' that could take advantage of a simpler > and cheaper distribution system? Where are these folks who > aren't "in it for the money?" This is the group that IP multicast > has to go after. > > And we go after them because -- "ta-dah" -- that's where the money > is!!! > > IP multicast is the new 'assembly line'. It is the new 'mass marketing' > corporation. It is the 'efficient mode of travel'. It is the way > of allowing anyone -- anywhere a way of getting out their message. > Whatever that message is. It removes the middle man. It frees > the receiver from having to choose from the limited offerings of > the networks (like cable TV did). And, in doing so, opens up a > new opportunity for making gobs and gobs of money as the velocity > of that money is increased by an order of magnitude. > > Consider Hollywood's dominance of the entertainment industry. Yes > they are the "best" when it comes to making a movie. But look at > all the inefficiencies. Why should Michael Eisner get paid millions > and millions of dollars? Its because he has a monopoly on the > distribution of product. People who make movies want to profit > from them. The only way they can profit is if they gain Eisner's > blessing. What if a content provider in Timbuktu were able to > scrape together $5000 and was able to make a very compelling movie. > Would Eisner support it? Would you ever see it? What if that movie > were made available on the internet via a "good enough" delivery > system that made a return on investment possible. If the movie > is 'multicast' and encoded -- yes there will be some loss of revenue > because of fraud on the part of the receivers -- will it provide > enough credit card subscritions to encourage the content provider > to try again? > > So, all this leads to asking those of you on this list, what is it > you want to have happen with this IP multicast stuff you've been > working on. Is it important to you that you have solved all the > dense/sparse interaction problems? Is it important that (*,*,RP) > trees are deployed? > > Or do you want to do something that is "good enough" and enables > new ways for people to interact with each other. New ways that > can be seen as socially "good" or ways that can be "mined" for > 'lots-of-bucks'. Especially when the 'lots-of-bucks' approach will > lead to the recognition of the need for alternate forms of > ip multicast services that can only be realized if the sparse/dense > and (*,*,RP) problems are solved. > > I've been doing IP multicast for nearly 10 years. It "ain't a goin' > no where". I want to see it 'out there' and used. Providing solutions > for problems that don't yet need to be solved, while ignoring the > interoperation problems that are standing in the way of deploying > a "good enough" solution is a way of commiting a slow and painful > suicide. > > It is time to 'shoot the engineer'. It is time to make a robust, > interoperable, and simple solution that will "prove" the viability > of multicast so that you can work on all these other 'interesting' > problems. We need something that is "good enough". > > I have an opinion on what that is -- I've stated it often enough > that everyone 'should know' what it is. I had to be persuaded that > it was the right choice, but now that I've been converted, the > obviousness of that choice is extremely compelling. If you recognize > that choice, then it should be obvious to you that getting (*,*,RP) > trees to work just isn't important right now. Your boss may be > telling you that you need the best PIM implementation possible, but > what gives him the prescience to know that? Is he just "listening > to the customer"? An excuse for not thinking about what really > works and a way of avoiding having to "do something" about it. > When a customer doesn't know what the product is, you have to teach > him. Your customer isn't the people on this list. > > Multicast is in the "push" stage of technological evolution. Its > time to get out there and push. > >2cents > >"P.Jhingran" wrote: >> >> hi all, >> Thanx for replying. After going through your views I feel that though one can have an option like "sparse-dense mode" for PIM, using which one can communicate between PIM-DM and PIM-SM routers, but such an option will definitely be involving some new messages between the two routers. What I mean to say is interaction between them is chaotic unless one has some proprietary messages between the routers. >> These proprietary messages should prevent the "chaos" which Paras is refering to, basically detecting in which mode the other router is configured or may be like whether messages like register/registerstop can be processed or not etc...all implementation specific. >> >> Why not we can come out with some new standard (ietf-stuff) messages which can be used to identify the PIM mode configured on the neighbouring router???. >> >> thanx, >> P.Jhingran >> >> On Tue, 05 Feb 2002 John Zwiebel wrote : >> > Not exactly chaos. It depends on the toplogy. >> > >> > "ONCE UPON A TIME..." >> > >> > one could configure a dense router and a sparse router >> > next to one another to transition between a sparse and >> > a dense domain -- where 'dense' also includes DVMRP >> > areas. >> > >> > Paras did hint at this when he said "exceptional cases". >> > >> > The "sparseness" of a group is determined by whether or >> > not >> > a router knows about an RP for a given multicast group. >> > If >> > it does, then the route is sparse. If it doesn't the >> > route >> > is dense. >> > >> > FWIW: although it would appear at first glance that >> > dense-mode >> > PIM is useful (especially now with "state-refresh"), in >> > practice >> > it has not proven to be. Part of the reason is that >> > PIM-dense doesn't work well with the "expanding ring >> > search", >> > partly because of the fact that some routers throw away >> > packets with TTL of 1 or 0 if they aren't specifically >> > addressed >> > to an IP address on that router, resulting in duplicate >> > packet delivery in some topologies... And part of the >> > reason is that application developers don't understand >> > how PIM-dense works and so the result in certain >> > toplogies >> > is unexpected. >> > >> > Also, sparse-mode can "do" everything that dense-mode >> > can and... >> > >> > in any case, SSM and bi-dir PIM may prove to be much >> > more >> > appropriate than any of the multicast routing protocols >> > now >> > used. >> > >> > 2cents >> > >> > Paras Trivedi wrote: >> > > >> > > Sparse or dense used to be a property of the >> > interface in PIMv1. >> > > But, in PIMv2, these days, the sparse or dense is a >> > property of >> > > a group or group range. So, the interface simply >> > needs to run PIM, >> > > regardless of any particular mode. (Although, in some >> > exceptional >> > > cases it is needed to run an interface in strictly >> > sparse or dense mode.) >> > > >> > > Most implementations (at least JunOS and IOS) allow >> > you to >> > > turn on PIM, regardless of the mode, with >> > ccommand. >> > > >> > > Yes, it'd be a misconfiguration to have sparse >> > configuration on >> > > one end of a link and dense, on another. And PIMv2 >> > hello does not >> > > carry this information. So, it cannot be detected >> > automatically. >> > > But, if you absolutely do this, then I guess, the >> > sparse router >> > > will do sparse thing (If DR, send register, send (*,G) >> > join) >> > > and dense router will do dense thing (flood and >> > expect to prune), for >> > > any combination of source/receiver/transit situation, >> > leading most >> > > likely to chaos. >> > > >> > > - Paras. >> > > >> > > > >> > > > >> > > > Hi all, >> > > > I have a trivial doubt.What shall happen if >> > PIM-SM and PIM-DM enabled interfaces are connected back >> > to back. >> > > > PIM-SM is enabled on router R1's interface 1 while >> > PIM-DM is enabled on interface 2. >> > > > >> > > > Router R1 <----------> Router R2 >> > > > PIM-SM PIM-DM >> > > > Interface 1 Interface 2 >> > > > >> > > > Is cisco or any other router able to distinguish >> > the above two modes?? The hello format is same for both >> > the modes and now it is up the to administrator to make >> > proper connections!! >> > > > regards, >> > > > Prashant >> > > > >> > > >> > > _______________________________________________ >> > > Pim-external mailing list >> > > Pim-external@mailist.procket.com >> > > http://mailist.procket.com/mailman/listinfo/pim-extern- >> > al >> From pim-admin@catarina.usc.edu Wed Feb 13 17:50:09 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23367 for ; Wed, 13 Feb 2002 17:50:08 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1DMo5K58903 for ; Wed, 13 Feb 2002 14:50:06 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Date: Wed, 13 Feb 2002 14:50:06 -0800 (PST) Message-Id: <200202132250.g1DMo5K58903@catarina.usc.edu> Subject: Welcome to the "Pim" mailing list From: pim-request@catarina.usc.edu To: pim-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Welcome to the Pim@catarina.usc.edu mailing list! To post to this list, send your email to: pim@catarina.usc.edu General information about the mailing list is at: http://catarina.usc.edu/mailman/listinfo/pim If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://catarina.usc.edu/mailman/options/pim/pim-archive%40lists.ietf.org You can also make such adjustments via email by sending a message to: Pim-request@catarina.usc.edu with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: kimoit If you forget your password, don't worry, you will receive a monthly reminder telling you what all your catarina.usc.edu mailing list passwords are, and how to unsubscribe or change your options. There is also a button on your options page that will email your current password to you. You may also have your password mailed to you automatically off of the Web page noted above. From pim-admin@catarina.usc.edu Thu Feb 14 03:26:58 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13271 for ; Thu, 14 Feb 2002 03:26:57 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1E8Q3K69047; Thu, 14 Feb 2002 00:26:03 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1E8PQK69026 for ; Thu, 14 Feb 2002 00:25:26 -0800 (PST) (envelope-from owner-mobile-ip@sunroof.eng.sun.com) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id TAA28981 for ; Wed, 13 Feb 2002 19:19:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-Id: <200201231424.JAA09722@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: magma@innovationslab.net, mobile-ip@sunroof.eng.sun.com, pim@catarina.usc.edu From: Internet-Drafts@ietf.org Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Owner: Status: RO X-UID: 890 Subject: [Pim] [mobile-ip] I-D ACTION:draft-jelger-mssmsv6-00.txt Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 23 Jan 2002 09:24:21 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Supporting Mobile SSM Sources for IPv6 (MSSMSv6) Author(s) : C. Jelger, T. Noel Filename : draft-jelger-mssmsv6-00.txt Pages : 11 Date : 22-Jan-02 Mobile IPv6 describes how a Mobile Node can change its point of attachment to the Internet. While MIPv6 focuses on unicast communications, it also proposes two basic mechanisms, known as bidirectionnal tunneling and remote subscription, to handle multicast communications with mobile members. In the mean time, the deployment of Source-Specific Multicast (SSM) is of great consideration, using the PIM-SM and MLDv2 protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jelger-mssmsv6-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-jelger-mssmsv6-00.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-jelger-mssmsv6-00.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: <20020122153345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jelger-mssmsv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jelger-mssmsv6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020122153345.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Thu Feb 14 04:24:31 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13945 for ; Thu, 14 Feb 2002 04:24:31 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1E9NYK69804; Thu, 14 Feb 2002 01:23:34 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from mailFA8.rediffmail.com ([202.54.124.153]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id g1E9JOK69755 for ; Thu, 14 Feb 2002 01:19:24 -0800 (PST) (envelope-from bakar_di@rediffmail.com) Received: (qmail 26369 invoked by uid 510); 14 Feb 2002 03:52:38 -0000 Message-ID: <20020214035238.26368.qmail@mailFA8.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 14 Feb 2002 03:52:38 -0000 MIME-Version: 1.0 From: "Bakar" Reply-To: "Bakar" To: pim@catarina.usc.edu Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id g1E9JOK69755 Subject: [Pim] (*,G) Upstream state machine Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: 14 Feb 2002 03:52:38 -0000 Content-Transfer-Encoding: 8bit Hi, in draft-4, sec 4.4.6 Sending (*,G) Join/Prune Messages when MRIB.next_hop(RP(G)) changes the text form says, "The upstream (*,G) state machine remains in Joined state. Send Prune(*,G) to the old upstream neighbor, which is the old value of RPF`(*,G). Send Join(*,G) to the new upstream neighbor which is the new value of MRIB.next_hop(RP(G))." Lets say A is old MRIB.next_hop(RP(G)) B is AssertWinner(*,G,I) C is new MRIB.next_hop(RP(G)) and A, B, C are all on the same interface. as i understand, we should send Prune to B, and Join to C. after this when the upsream JT expires, should we send Join to RPF`(*,G) or MRIB.next_hop(RP(G)) thanx, Bakar _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Thu Feb 14 04:45:01 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14292 for ; Thu, 14 Feb 2002 04:45:00 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1E9i4K70045; Thu, 14 Feb 2002 01:44:04 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from wisbech.cl.cam.ac.uk (exim@mta1.cl.cam.ac.uk [128.232.0.15]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1E9axK69979 for ; Thu, 14 Feb 2002 01:36:59 -0800 (PST) (envelope-from jon.crowcroft@cl.cam.ac.uk) Received: from shep.cl.cam.ac.uk ([128.232.8.11] helo=cl.cam.ac.uk ident=jac22) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 16bIIo-0003WR-00; Thu, 14 Feb 2002 09:35:42 +0000 To: "T.H.Nguyen" cc: rmt@ietf.org, pim@catarina.usc.edu In-Reply-To: Message from "T.H.Nguyen" of "Wed, 13 Feb 2002 18:00:45 +0900." <20020213180045.5d5b7db3.haguen@mlab.t.u-tokyo.ac.jp> From: Jon Crowcroft Message-Id: Subject: [Pim] Re: [eagle 00635] Fw: [Rmt] pim-sm and layered multicast Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 09:35:38 +0000 In message <20020213180045.5d5b7db3.haguen@mlab.t.u-tokyo.ac.jp>, "T.H.Nguyen" typed: >>These problems were described in the following paper: >>"Rendezvous Points based Layered Multicast", IEICE Trans. >>Commun., Vol. E84-B, No. 12, Dec. 2001. >>Abstract and PDF file are available at this URL: >>http://search.ieice.org/2001/files/e000b12.htm#e84-b,12,3133 cool - neat paper note that one reason for hashing to different RPs is to load balance so there are two problems with layered coded schemes and this 1/ if yo uhave 2 flowss with potentuialyl 2 layers, and 2 RPs, then instead of getting 1 layer for each flow on each RP, you could end up with the each layer of 1 flow on each RP, and none of the second flow - this is clearly unfair, 2/is loss at an RP really correlated with bottlenecks ? in the UK national and MAN nets, RPs are in overprovisoned palces, and loss is typically in the leaf/site networks (we think, and others seem to agree)...if we could say use ECN, then the RP could monitor ECN rate per group...which might then be a really cute way of extendign your idea cheers jon _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Thu Feb 14 21:34:37 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15626 for ; Thu, 14 Feb 2002 21:34:35 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1F2XFK88633; Thu, 14 Feb 2002 18:33:15 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1F2Q0K88493 for ; Thu, 14 Feb 2002 18:26:00 -0800 (PST) (envelope-from bakar_di@rediffmail.com) Received: from mailweb13.rediffmail.com ([203.199.83.25]) by usc.edu (8.9.3.1/8.9.3/usc) with SMTP id EAA15410 for ; Thu, 14 Feb 2002 04:22:38 -0800 (PST) Received: (qmail 22402 invoked by uid 510); 14 Feb 2002 11:51:57 -0000 Message-ID: <20020214115157.22401.qmail@mailweb13.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 14 Feb 2002 11:51:57 -0000 MIME-Version: 1.0 From: "Bakar" Reply-To: "Bakar" To: pim@catarina.usc.edu Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id g1F2Q0K88493 Subject: [Pim] (no subject) Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: 14 Feb 2002 11:51:57 -0000 Content-Transfer-Encoding: 8bit Hi, If in a PIM-SM domain every router is configured with static RP set, and every router also learns RP set dynamically by BSR mechanism, routers in effect will have two RP sets. One dynamic and One static. What should be search mode for a given G ? Is it like, search if we have matching G/M in dynamic first if not then lookup static set. If that is so, lets say a longest match is available in static. To be more clear dynamic has => 245.0.0.0/8 = R1 and static has => 245.1.0.0/16 = R2 if we dont consult static also then we will end up sending join towards R1. but instead we do like this, do a longest match on static also we will send to R2 in the second approach static entry is rejected only if there is a clashing entry in static also. eg dynamic has => 245.0.0.0/8 => R1 and static also has => 245.0.0.0/8 => R2 then in this case prefernce is given to dynamically learnt. I want to know how this is done in cisco / juniper. Will be very much helpfull if someone can share this knowledge. thanx and regards, Bakar _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Thu Feb 14 21:42:36 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16074 for ; Thu, 14 Feb 2002 21:42:35 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1F2fVK88740; Thu, 14 Feb 2002 18:41:31 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1F2ORK88438 for ; Thu, 14 Feb 2002 18:24:27 -0800 (PST) (envelope-from mjh@vulture.icir.org) Received: from vulture.icir.org (adsl-63-196-11-253.dsl.snfc21.pacbell.net [63.196.11.253]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA08149 for ; Thu, 14 Feb 2002 07:35:41 -0800 (PST) Received: from vulture.icir.org (localhost [127.0.0.1]) by vulture.icir.org (8.11.6/8.11.3) with ESMTP id g1EFYll88573; Thu, 14 Feb 2002 07:34:47 -0800 (PST) (envelope-from mjh@vulture.icir.org) From: Mark Handley X-Organisation: ACIRI To: "Bakar" cc: pim@catarina.usc.edu Subject: Re: [Pim] (*,G) Upstream state machine In-reply-to: Your message of "14 Feb 2002 03:52:38 GMT." <20020214035238.26368.qmail@mailFA8.rediffmail.com> Message-ID: <88571.1013700887@vulture.icir.org> Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 07:34:47 -0800 >in draft-4, sec 4.4.6 Sending (*,G) Join/Prune Messages > >when MRIB.next_hop(RP(G)) changes >the text form says, > >"The upstream (*,G) state machine remains in Joined state. Send Prune(*,G) to >the old upstream neighbor, which is the old value of RPF`(*,G). Send Join(*,G) > to the new upstream neighbor which is the new value of MRIB.next_hop(RP(G))." > >Lets say >A is old MRIB.next_hop(RP(G)) >B is AssertWinner(*,G,I) >C is new MRIB.next_hop(RP(G)) >and A, B, C are all on the same interface. > >as i understand, we should send Prune to B, and Join to C. >after this when the upsream JT expires, should we send Join to RPF`(*,G) or MR >IB.next_hop(RP(G)) If C is on a different interface from A and B, then the Assert state machine causes the assert state to be dropped when MRIB.next_hop(RP(G)) changes interface. The question is only meaningful when C is on the same interface as A and B. In this case, from a high level point of view, it doesn't really matter whether B or C now does the forwarding. We know the path to the RP through B works. But C might have a lower cost path. So we send a single Join to C, but we maintain the Assert state. In the normal case, traffic will start arriving via C, and an Assert will happen causing the best path to win, and all our future periodic Joins go to the winner. If (for whatever reason) the path through C doesn't work, the path through B will continue forwarding, and so we want the next periodic Join to go to B to maintain that state. The only issue with this would be in the case where B's next hop to RP(G) becomes the LAN containing C. In this case the Assert state machine will cause B to send an AssertCancel, and so you'll then send periodic joins to C in the normal way. So, your summary is correct, even though it may seem a little strange at first glance. BTW, if you dropped the Assert state, then most likely the same thing would happen, but you'd be fractionally less robust. I hope this clarifies the thinking behind this. Cheers, Mark _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Thu Feb 14 23:11:46 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18162 for ; Thu, 14 Feb 2002 23:11:45 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1F4AcK89919; Thu, 14 Feb 2002 20:10:38 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1F3xFK89825 for ; Thu, 14 Feb 2002 19:59:15 -0800 (PST) (envelope-from shankarv@future.futsoft.com) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Fri, 15 Feb 2002 09:45:35 +0530 Received: from shankarv (shankarv.future.futsoft.com [10.4.8.19]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g1F3wRh07529; Fri, 15 Feb 2002 09:28:27 +0530 Reply-To: From: "Shankar V" To: "'Bakar'" , Subject: RE: [Pim] (no subject) Message-Id: <002601c1b5d4$f5a7e5c0$1308040a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020214115157.22401.qmail@mailweb13.rediffmail.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 15 Feb 2002 09:27:59 +0530 Content-Transfer-Encoding: 7bit Hi Bakar, If my understanding is correct, this needs to be the same in all implementation otherwise domain deploying different vendor machines will have different views of RP and will lead to chaos. cisco's config manual says something like "If a conflict exists between the RP configured with this command and one learned by Auto-RP, the Auto-RP information is used, unless the override keyword is configured." in description of the cli command to configure static RP. so it is clear that only on "conflict", we have the ambiguity to choose which one, either dynamic / static entry. usually a policy can be configured to dictate the preference to solve the ambiguity. i guess by "conflict" we mean the case where 245.0.0.0/8 is both learnt dynamically and statically configured. I would call the other one to be "overlapping" i.e 245.0.0.0/8 and 245.1.0.0/16 are not conflicting and in my view, for a G = 245.1.3.250 (say) the entry chosen would be the static one 245.1.0.0/16 => R2 for a G = 245.2.3.250 (say) the entry chosen would be the dynamic one 245.0.0.0/8 => R1 I hope my views are correct. Somebody correct me if am wrong. regards, shankar -----Original Message----- From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On Behalf Of Bakar Sent: Thursday, February 14, 2002 5:22 PM To: pim@catarina.usc.edu Subject: [Pim] (no subject) Hi, If in a PIM-SM domain every router is configured with static RP set, and every router also learns RP set dynamically by BSR mechanism, routers in effect will have two RP sets. One dynamic and One static. What should be search mode for a given G ? Is it like, search if we have matching G/M in dynamic first if not then lookup static set. If that is so, lets say a longest match is available in static. To be more clear dynamic has => 245.0.0.0/8 = R1 and static has => 245.1.0.0/16 = R2 if we dont consult static also then we will end up sending join towards R1. but instead we do like this, do a longest match on static also we will send to R2 in the second approach static entry is rejected only if there is a clashing entry in static also. eg dynamic has => 245.0.0.0/8 => R1 and static also has => 245.0.0.0/8 => R2 then in this case prefernce is given to dynamically learnt. I want to know how this is done in cisco / juniper. Will be very much helpfull if someone can share this knowledge. thanx and regards, Bakar _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Fri Feb 15 00:38:42 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19860 for ; Fri, 15 Feb 2002 00:38:42 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1F5baK90762; Thu, 14 Feb 2002 21:37:36 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1F5NcK90610 for ; Thu, 14 Feb 2002 21:23:38 -0800 (PST) (envelope-from ycai@cisco.com) Received: (from ycai@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id VAA00418; Thu, 14 Feb 2002 21:23:15 -0800 (PST) Message-Id: <200202150523.VAA00418@cisco.com> From: Yiqun Cai To: shankarv@future.futsoft.com CC: bakar_di@rediffmail.com, pim@catarina.usc.edu In-reply-to: <002601c1b5d4$f5a7e5c0$1308040a@future.futsoft.com> (shankarv@future.futsoft.com) Subject: Re: [Pim] (no subject) Reply-to: ycai@cisco.com Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 21:23:15 -0800 (PST) > Importance: Normal > > Hi Bakar, > > If my understanding is correct, this needs to be the same in all > implementation > otherwise domain deploying different vendor machines will have different > views of > RP and will lead to chaos. > > cisco's config manual says something like > > "If a conflict exists between the RP configured with this command and one > learned by Auto-RP, the Auto-RP information is used, unless the override > keyword is configured." > > in description of the cli command to configure static RP. > > so it is clear that only on "conflict", we have the ambiguity to choose > which one, either dynamic / static entry. usually a policy can be configured > to dictate the preference to solve the ambiguity. > > i guess by "conflict" we mean the case where 245.0.0.0/8 is both learnt > dynamically and statically configured. > > I would call the other one to be "overlapping" i.e 245.0.0.0/8 and > 245.1.0.0/16 are not conflicting and in my view, > for a G = 245.1.3.250 (say) the entry chosen would be the static one > 245.1.0.0/16 => R2 If "override" is configured, Cisco IOS will choose R2 as the RP for 245.1.3.250; otherwise, R1 is selected. The prefix length is not considered as a tie-breaker to decide between learned RP and statically configured RP. > > for a G = 245.2.3.250 (say) the entry chosen would be the dynamic one > 245.0.0.0/8 => R1 > > I hope my views are correct. Somebody correct me if am wrong. > > regards, > shankar > > -----Original Message----- > From: pim-admin@catarina.usc.edu [mailto:pim-admin@catarina.usc.edu]On > Behalf Of Bakar > Sent: Thursday, February 14, 2002 5:22 PM > To: pim@catarina.usc.edu > Subject: [Pim] (no subject) > > > > Hi, > > If in a PIM-SM domain every router is configured with static RP set, and > every router also learns RP set dynamically by BSR mechanism, routers in > effect will have two RP sets. One dynamic and One static. > > What should be search mode for a given G ? Is it like, > search if we have matching G/M in dynamic first > if not then lookup static set. > > If that is so, lets say a longest match is available in static. > > To be more clear > dynamic has => 245.0.0.0/8 = R1 > and > static has => 245.1.0.0/16 = R2 > > if we dont consult static also then we will end up sending join towards R1. > > but instead we do like this, > do a longest match on static also we will send to R2 > > in the second approach static entry is rejected only if there is a clashing > entry in static also. eg > > dynamic has => 245.0.0.0/8 => R1 and > static also has => 245.0.0.0/8 => R2 > > then in this case prefernce is given to dynamically learnt. > > I want to know how this is done in cisco / juniper. Will be very much > helpfull if someone can share this knowledge. > > thanx and regards, > Bakar > > > > > _______________________________________________ > Pim mailing list > Pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim > > _______________________________________________ > Pim mailing list > Pim@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/pim > -- Yiqun _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Sat Feb 16 15:57:09 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16482 for ; Sat, 16 Feb 2002 15:57:08 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1GKswK12693; Sat, 16 Feb 2002 12:54:58 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1G5PuK03389 for ; Fri, 15 Feb 2002 21:25:56 -0800 (PST) (envelope-from gtech@gtech21.com) Received: from localhost ([211.222.117.6]) by usc.edu (8.9.3.1/8.9.3/usc) with SMTP id VAA25377 for ; Fri, 15 Feb 2002 21:26:27 -0800 (PST) Message-Id: <200202160526.VAA25377@usc.edu> Reply-To: gtech@gtech21.com From: (주)지텍 To: pim@catarina.usc.edu Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Subject: [Pim] 자동 줄 감김장치 신개념 휴대폰용 이어폰 !!! [광고] Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 16 Feb 2002 14:25:45 +0900 mail02-1
    ⊙ 허락없이 메일을 보내서 죄송합니다.
    ⊙ 본메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다.
    ⊙ e-mail 주소는 인터넷상에서 취득하였으며, 주소외 어떠한 개인 정보도 가지고 있지 않습니다.
    ⊙ 수신을 원치 않으시면 '수신거부'를 눌러주세요. [수신거부]
     
    		 
     
    		 
    (주)지텍 인천광역시 계양구 작전동 852-73 Tel:(032)552-7222
    E-mail : gtech@gtech21.com    Homepage : http://www.gtech21.com
     
    _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Sat Feb 16 20:17:32 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19214 for ; Sat, 16 Feb 2002 20:17:32 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1H1GlK15135; Sat, 16 Feb 2002 17:16:48 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from mailweb11.rediffmail.com ([203.199.83.23]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id g1F7TfK91929 for ; Thu, 14 Feb 2002 23:29:43 -0800 (PST) (envelope-from bakar_di@rediffmail.com) Received: (qmail 19926 invoked by uid 510); 15 Feb 2002 07:28:50 -0000 Message-ID: <20020215072850.19925.qmail@mailweb11.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 15 Feb 2002 07:28:50 -0000 MIME-Version: 1.0 From: "Bakar" Reply-To: "Bakar" To: "Yiqun Cai" Cc: pim@catarina.usc.edu, shankarv@future.futsoft.com Subject: Re: Re: [Pim] (no subject) Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id g1F7TfK91929 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: 15 Feb 2002 07:28:50 -0000 Content-Transfer-Encoding: 8bit Hi, find inlined... > > I would call the other one to be "overlapping" i.e > 245.0.0.0/8 and > > 245.1.0.0/16 are not conflicting and in my view, > > for a G = 245.1.3.250 (say) the entry chosen would be > the static one > > 245.1.0.0/16 => R2 > [Bakar] the above one is more similar to the unicast route lookup proceedure. isint it ? > If "override" is configured, Cisco IOS will choose R2 > as the RP for > 245.1.3.250; otherwise, R1 is selected. The prefix > length is not > considered as a tie-breaker to decide between learned > RP and > statically configured RP. > [Bakar] Yiqun, Is there any specific reason why it is done this way in cisco? and do we know if all the vendors do the same ? regards, Bakar _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Sat Feb 16 20:21:08 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19283 for ; Sat, 16 Feb 2002 20:21:07 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1H1KYK15188; Sat, 16 Feb 2002 17:20:34 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from mailweb29.rediffmail.com ([203.199.83.149]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id g1FAlhK93316 for ; Fri, 15 Feb 2002 02:47:43 -0800 (PST) (envelope-from bakar_di@rediffmail.com) Received: (qmail 31307 invoked by uid 510); 15 Feb 2002 09:45:46 -0000 Message-ID: <20020215094546.31306.qmail@mailweb29.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 15 Feb 2002 09:45:46 -0000 MIME-Version: 1.0 From: "Bakar" Reply-To: "Bakar" To: "Mark Handley" Cc: pim@catarina.usc.edu Subject: Re: Re: [Pim] (*,G) Upstream state machine Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id g1FAlhK93316 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: 15 Feb 2002 09:45:46 -0000 Content-Transfer-Encoding: 8bit exactly, it first looked strange to me, when a prune is sent to B, and immediately when JT timer expires, send a Join to it again. Now i understand the reason much better. thanx Mark, and C need not wait till data arrives via its tree, since it has the CouldAssert(*,G,I) TRUE when it recieves data forwarded by B on I. It then sends assert (*,G) after assuming itself as Winner and eventually a winner would be decided. thanx & regards, Bakar On Thu, 14 Feb 2002 Mark Handley wrote : > > >in draft-4, sec 4.4.6 Sending (*,G) Join/Prune Messages > > > >when MRIB.next_hop(RP(G)) changes > >the text form says, > > > >"The upstream (*,G) state machine remains in Joined > state. Send Prune(*,G) to > >the old upstream neighbor, which is the old value of > RPF`(*,G). Send Join(*,G) > > to the new upstream neighbor which is the new value > of MRIB.next_hop(RP(G))." > > > >Lets say > >A is old MRIB.next_hop(RP(G)) > >B is AssertWinner(*,G,I) > >C is new MRIB.next_hop(RP(G)) > >and A, B, C are all on the same interface. > > > >as i understand, we should send Prune to B, and Join > to C. > >after this when the upsream JT expires, should we send > Join to RPF`(*,G) or MR > >IB.next_hop(RP(G)) > > If C is on a different interface from A and B, then the > Assert state > machine causes the assert state to be dropped when > MRIB.next_hop(RP(G)) changes interface. > > The question is only meaningful when C is on the same > interface as A > and B. In this case, from a high level point of view, > it doesn't > really matter whether B or C now does the forwarding. > We know the > path to the RP through B works. But C might have a > lower cost path. > So we send a single Join to C, but we maintain the > Assert state. In > the normal case, traffic will start arriving via C, and > an Assert will > happen causing the best path to win, and all our future > periodic Joins > go to the winner. If (for whatever reason) the path > through C doesn't > work, the path through B will continue forwarding, and > so we want periodic Join to go to B to maintain that state. > > The only issue with this would be in the case where B's > next hop to > RP(G) becomes the LAN containing C. In this case the > Assert state > machine will cause B to send an AssertCancel, and so > you'll then send > periodic joins to C in the normal way. > > So, your summary is correct, even though it may seem a > little strange > at first glance. > > BTW, if you dropped the Assert state, then most likely > the same thing > would happen, but you'd be fractionally less robust. > > I hope this clarifies the thinking behind this. > > Cheers, > Mark _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Sat Feb 16 20:23:51 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19311 for ; Sat, 16 Feb 2002 20:23:51 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1H1NCK15248; Sat, 16 Feb 2002 17:23:12 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from lycos.com ([61.78.207.21]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id g1FEwvK95524 for ; Fri, 15 Feb 2002 06:59:05 -0800 (PST) (envelope-from guise1qw@lycos.com) Message-Id: <200202151459.g1FEwvK95524@catarina.usc.edu> Reply-To: guise1qw@lycos.com From: 네트워크 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-User: 2.62-figjdliv-lilkhn-Ddigq Subject: [Pim] [광고]돈되는 사업및 부업을 소개합니다 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 15 Feb 2002 23:58:39 +0900

    ▶ 허락없이 홍보메일을 보내게 된 점 사과드립니다.
    ▶ 정보통신망이용촉진법규정을 준수하여 광고메일임을 표시하였읍니다.
    ▶ 전자우편주소는 인터넷상에서 취득하였으며, 전자우편주소외 어떠한 개인 정보도 가지고 있지 않습니다


    !!!! 지금 이순간 님께서 저희 다이너스티를 만나신 것은 대단한 행운이라 확신합니다. !!!!

     

    반갑습니다.
    저는 부산에서 직장을 다니면서 부업으로 이 사업을 진행하고 있는 장강민이란 사람입니다.
    적극적이고 열정적으로 살면서 자기 발전을 위해 끊임없이 노력하고 있습니다.

    사업은 물론 만나서 대화를 나누어야 가장 좋겠지만, 우선 서면으로 대략을 알려드리니 살 펴보시고 계속 관심이 있으시면 연락주시기 바랍니다....

     

    사업의 개념이 이해하기쉽고, 네트웤을 형성하는 방법이 on-line, off-line 으로 다양하고, 듣는 사람도 너무나 쉽게 납득할 수 있기 때문에 누구나 하실 수가 있습니다.

    특히 기존에 어떤 형식이든 네트웤 마케팅을 하고 계시는 분들이면 더욱 잘 하실 수
    있습니다.

     

    이 사업은 통신 사업 중 가장먼저 시작된 새로운 사업으로서 다이너스티 라는 회사로 별정통신1호와 2호의 회사입니다.

    자본 없이도 자기사업을 하는것과 같으며 시간이 흐름에 따라 점차 그 규모가 커져 1년 후 회원 수와 매출액면에서 비교가 안 될 정도로 확장되는 굉장히 비젼이 있는 사업입니다.

     

    아마도 주변에서 아는분들이 다단계 사업을 하시면서 같이 사업해 보지 않겠냐는 제안 한 두 번쯤 안 들어보신 분들 거의없으리라 생각됩니다.

    그렇지만 다단계가 뭡니까. 기존 시장의 유통구조를 바꾸어 즉 중간유통단계(총판, 대리점) 또는 광고없이 구전에 의한판매로 중간단계에서 발생되는 지출을 줄여 그수익을 소비자에게 환원시켜주는 선진형 판매방식입니다.

    네트웍 사업은 회원들의 재구매가 빠른 제품으로 구성되어야 한다는것은 잘아시겠죠?

    우리가 하루도 전화를 걸지 않고는 살아갈 수 없다는 것을 님께서도 인정하십니까?
    바로 이 전화요금을 현재 기간통신에 후불로 납부하는것을 선불로 카드에 충전해서 쓰는것이 사업입니다.

     

    2000년도 국내 소비시장중 통신시장규모는 자그만치 약24조원이었으며 2001년도는 아직 통계가 나오지 않아 잘모르지만 훨씬 늘어났으며 참고로 말씀드린다면 쌀소비시장은 약 1조원, 자동차시장-약6조, 유류(석유)시장-약6조원이었습니다.
    통신시장 규모가 얼마나 큰시장인지 짐작이 가시겠죠?

     

    이 거대통신시장이 이대로 개방된다면우리나라 신경인 통신은 그대로 외국유수업체에 잠식 당할 수 밖에 없습니다.
    그래서 정부에서 별정통신을 허용하여 개인전화국(1호사업자)으로 하여금 개방이전에 국제경쟁력을 갖추기 위한 국책사업입니다.

     

    통합선불카드 하나로 시내.외,공중전화 통화는 물론 휴대폰 기종,번호변경없이 011부터 019까지 축기능으로 많은 버튼을 누르지 않고 온가족이 함께 간편하게 사용하실수 있습니다.


    물론 상기내용은 아주 기본적인 내용이구요.
    자기밑으로 2명만 둘수 있는 바이너리 구조입니다

    이외에도 부가산업도 뿐만아니라  수익구조,전자상거래등등 하고싶은 이야기는 많으나 이정도로 설명을 해드리구요 더궁굼하신것들은 직접 상담을 하시거나 회사의 홈페이지를 둘러보시면 되겠읍니다.

     

    http://www.dynastytel.co.kr(별정통신)
    http://www.clubaqua.co.kr(여행사)
    http://www.visiondynasty.com(전자상거래)
    http://www.e-dynasty.co.kr(홈페이지)
    연락처 : codejang@intizen.com
    H.P    : 019-596-9808
    수신거부 : e-dynasty@simmani.com 또는 아래의 수신거부 버튼을 눌러주세요

     

     

     

     

    원치않으시면 수신거부 를 눌러주시고 제목에 수신거부라고 적어주시기 바랍니다. 불편을 드렸다면 죄송합니다. _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Sat Feb 16 20:26:35 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19355 for ; Sat, 16 Feb 2002 20:26:34 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1H1Q1K15334; Sat, 16 Feb 2002 17:26:01 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1E88PK68623 for ; Thu, 14 Feb 2002 00:08:26 -0800 (PST) (envelope-from preenam@future.futsoft.com) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 14 Feb 2002 09:31:46 +0530 Received: from preenam (preenam.future.futsoft.com [10.4.8.9]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g1E3ieh21844 for ; Thu, 14 Feb 2002 09:14:40 +0530 Reply-To: From: "Preena M" To: Message-Id: <003001c1b50a$1f0f95a0$0908040a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: [Pim] (no subject) Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 09:16:00 +0530 Content-Transfer-Encoding: 7bit unsubscribe pim _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Sat Feb 16 20:29:19 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19384 for ; Sat, 16 Feb 2002 20:29:18 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1H1ShK15403; Sat, 16 Feb 2002 17:28:43 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1F31IK89185 for ; Thu, 14 Feb 2002 19:01:18 -0800 (PST) (envelope-from apdaly@northlandinc.com) Received: from apollo.NORTHLAND.local ([206.47.172.148]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA20212 for ; Thu, 14 Feb 2002 12:53:43 -0800 (PST) Received: from adaly ([10.1.1.170]) by apollo.NORTHLAND.local with Microsoft SMTPSVC(5.0.2195.3779); Thu, 14 Feb 2002 15:33:35 -0500 Message-ID: <07c801c1b596$dee424e0$aa01010a@northland.local> From: "Alan Daly" To: "Alan Daly" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07C5_01C1B56C.F40EF180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 14 Feb 2002 20:33:35.0645 (UTC) FILETIME=[E054A4D0:01C1B596] Subject: [Pim] 2 DAY MPLS COURSE COMING TO OTTAWA, CANADA MARCH 21ST AND 22ND, 2002 Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 15:33:29 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_07C5_01C1B56C.F40EF180 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Please note that this is a one-time mailing only concerning this course = and date. To be removed, simply reply with an "UNSUBSCRIBE" in the body = of the email. Good afternoon Networking Professionals. Northland Systems, the world leader in = non-vendor specific MPLS, Fiber Optic, Gigabit Ethernet, and IP = training, is pleased to announce that our much anticipated, highly = successful, 2 day MPLS Technologies course is scheduled to run again in = Ottawa, Canada on March 21st and 22nd. I was wondering if you could = forward this onto your colleagues and clients to see if they would be = interested in attending. The cost to attend this course is $1100.00 = CDN per student (plus applicable taxes). Taught onsite at such industry = leaders as Alcatel, 360 Networks, Telus, AT&T and Marconi = Communications, the student will leave with a thorough and comprehensive = understanding of this leading-edge networking technology. The class is = limited to 20 students, and we are expecting this session to sell out = extremely quickly, so time is of the essence if you plan on registering = either yourself and/or your colleagues on this course.=20 **PLEASE NOTE THAT AS A SPECIAL OFFER, ANYONE SIGNING UP MORE THAN ONE = ATTENDEE ON THIS COURSE WITH ME AT A TIME WILL RECEIVE A COMPLIMENTARY = NORTHLAND DENIM SHIRT FOR THEMSELVES AS WELL AS THEIR COLLEAGUE(S)!!!** As an added value, all attendees will receive 30 days free access to the = Northland Online "MPLS Technology" eLearning course upon completion of = this session! This course introduces the challenge of the = next generation networks and describes how MPLS addresses it at both a = high and low level. Participants are expected to have a strong = understanding and experience in WANs, LANs, data communications, = routing, internetworking, and communications protocols. This course will: a.. Explain the MPLS concepts, architecture & components.=20 b.. Provide an in-depth view of MPLS.=20 c.. Provide a thorough understanding across all areas of the = technology.=20 d.. Describe how MPLS relates to different evolving network = technologies. Please review the detailed course outline below for more information on = the content being covered. To find out more about how to bring this or any other 2 day course = in-house to a group at your facility, or to register, please call me = directly at 613-667-5063.=20 Have a great day!=20 Sincerely, Alan P. Daly Account Representative Northland Systems Training Inc. 255 Albert St. 5th Floor Ottawa, ON K1P-6A9 Direct: (613) 667-5063 Cellular: (613) 223-1062 Fax: (613) 667-5098 Check Out Our Website at http://www.northlandelearning.com -------------------------------------------------------------------------= --- "Changing learning from an event to a life long process" KNOW YOUR WAY visit http://www.northlandelearning.com -------------------------------------------------------------------------= --- COURSE OUTLINE: *********************** INTRODUCTION=20 =B7 Why MPLS =B7 Routers & Switches =B7 Route at Edge, Switch in Core =B7 Labeled Packet Forwarding =B7 Label & FEC =B7 Traffic Aggregation or Splitting =B7 Label Switched Path =B7 LSP and the Node =B7 LSP Establishment =B7 Packet Labeling & Forwarding =B7 Forwarding Table & LIB =B7 FEC, Labels & LSPs =20 MPLS LABEL ENCODING=20 =B7 Shim Layer Concept =B7 Layer 2 technologies & Labels =B7 MPLS Shim Description =B7 Shim Fields (Label, Exp, S & TTL) =B7 Label Values =B7 Media Encapsulation =B7 Hop Popping =B7 Routing & Tunneling =B7 Multipoint to point trees =B7 MPLS reflects nature of IP Networks =B7 Label Aggregation & Frame merging =B7 Overview: What is MPLS? =20 ICMP MESSAGES=20 =B7 A brief review of ICMP =B7 ICMP Message to source LSR =B7 Tunneling through an AS =B7 Tunnel Private Address via Public Backbones =B7 Extended ICMP Message Length =B7 MPLS Extension Data Structure =B7 MPLS Object Extensions =B7 Stack Entry Object & Extended payload Object =B7 Traceroute over MPLS =20 LDP SIGNALING PROTOCOL=20 =B7 LDP Overview =B7 Applicability & Features =B7 Scalability & Security =B7 LSP Establishment =B7 Upstream LSR versus Downstream LSR =B7 Downstream or Upstream Label Binding =B7 Unsolicited versus On-Demand =B7 Independent or Ordered =B7 Conservative or Liberal Label Retention =B7 Label Request Procedures =B7 L DP over TCP between Neighbors =B7 LDP Security & Privacy =B7 LDP Message Format & Types =B7 For further study items =B7 LDP Message Format & Types =B7 Hello Messages & Targeted Hellos =B7 Encoding of Hello Message & TLVs =B7 Common & Optional Hello Parameters =B7 Hello Discovery Phase =B7 TCP Connection Phases =B7 Session Initialization State Machine =B7 Session Initialization Message =B7 Frame Relay Session Parameters =B7 Advertisement Messages to set LSP =B7 Label Request & Mapping Messages =B7 Label Abort, Withdraw & Release Messages =B7 Address & Address Withdraw Messages =B7 Vendor Private Messages =B7 Notification & Keep Alive Messages =B7 Detailed TLV Encoding =20 CR-LDP SIGNALING PROTOCOL=20 =B7 CR-LDP Overview =B7 Constraint-Routing =B7 CR-LDP Features =B7 Traffic Parameters =B7 Strict & Loose Explicit Routing =B7 Explicit Route TLV =B7 Node & Abstract Node =B7 CSPF =B7 Preemption =B7 Route Pinning =B7 Handling of Failures =B7 LSPID =B7 Resource Class =B7 CR-LDP Messages =B7 LDP PDUs =B7 CR-LDP Message Format =B7 Label Request & Mapping Messages =B7 Notification Message =B7 Detailed CR-LDP TLV Encoding =20 RSVP-TE SIGNALING PROTOCOL=20 =B7 Review of RSVP =B7 RSVP Node & Session Data Flow =B7 Reservation Styles =B7 RSVP PATH & RESV Messages =B7 Reservation & Data Flow =B7 PATH Message & RESV Messages =B7 RSVP Message Common Header =B7 RSVP Message Object Structure =B7 RSVP Message Objects =B7 RSVP-TE Common Header =B7 RSVP-TE Message Object Structure =B7 RSVP-TE LSP Setup Flow =B7 New RSVP-TE Objects =B7 New C-types =B7 RSVP-TE Label Request & Label Objects =B7 LSP Tunnel IP Session Object =B7 ERO & RRO Objects =B7 Path Additional Data Objects =B7 RSVP-TE versus CR-LDP =B7 Comparative Analysis =20 BGP 4=20 =B7 A brief Review on BGP4 =B7 Routing & Tunneling =B7 Directly connected LSRs =B7 Not-directly connected BGP LSRs MPLS over ATM=20 =B7 A brief review of ATM =B7 Motivation for MPLS over ATM =B7 ATM-LSR (LC-ATM, LSR-CC, ATM-CC) =B7 ATM-LSR Behavior & Constraints =B7 Frame-based & Cell-based LSRs =B7 ATM-LSR Integrated & Peer Approaches =B7 SIN Model - Ships in the Night =B7 Transparent Point-to-Point Link =B7 RFC 2684/1483 =B7 Connected through a VP or a VC =B7 VCID & VCID Signaling =B7 ATM Label Stack Encoding =B7 Passing SHIM fields across ATM =B7 VC Merge & Non-VC Merge ATM-LSRs =B7 Communication from edge to edge LSRs =20 VIRTUAL PRIVATE NETWORKS=20 =B7 A brief review on VPN =B7 VPN Overlay & Peer Models =B7 VPN Peer Model Key Technologies =B7 Constrained Distribution of Routing =B7 Extended Communities =B7 PE Forwarding Tables =B7 VPN-IP Address =B7 BGP in PE, IGP within the Provider Network =B7 MPLS as the forwarding Mechanism =20 MPLS QoS SUPPORT=20 =B7 A brief review on IP QoS =B7 IntServ QoS Model =B7 Guaranteed Service & Controlled Load =B7 MPLS RSVP-TE Support of InServ QoS =B7 Diff-Serv QoS Model =B7 MPLS Support of Diff-Serv =B7 E-LSP & L-LSP =B7 MPLS ECN Support =20 MPLS EVOLUTION & REFERENCES=20 =B7 IP Switching Initiatives =B7 MPLS Forum =B7 IETF Working Group MPLS Charter =B7 MPLS Drafts & Standards =B7 MPLS Vendor Products =B7 MPLS Testing & Analyser Products =B7 Interoperability Testing Centers =B7 Example of interoperability testing =B7 MPLS Resource Center =B7 MPLS Applications & Early Adopters =B7 Evolution of the Internet =B7 Convergence of Audio, Video & Data =B7 Next Generation Applications =B7 Abilene & vBNS NGI Initiatives =B7 CA*net 2 & 3 =B7 Next Generation Networks Key Technologies =20 ------=_NextPart_000_07C5_01C1B56C.F40EF180 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    Please note that this is a = one-time mailing=20 only concerning this course and date. To be removed, simply reply with = an=20 "UNSUBSCRIBE" in the body of the email.
     
    Good afternoon Networking=20 Professionals.
     
              &nbs= p;            = ;     =20 Northland Systems, the world leader in non-vendor specific = MPLS, Fiber=20 Optic, Gigabit Ethernet, and  IP training,  is pleased to = announce that our much anticipated, highly successful, 2 = day MPLS=20 Technologies course is scheduled to run again in Ottawa, Canada = on March 21st and 22nd. I was wondering if = you could=20 forward this onto your colleagues and clients to see if they would be = interested=20 in attending.
     
              &nbs= p;            = ;    =20 The cost to attend this course is $1100.00 CDN per student (plus = applicable=20 taxes). Taught onsite at such industry leaders as = Alcatel, 360=20 Networks, Telus, AT&T and Marconi Communications, the=20 student will leave with a thorough and comprehensive understanding = of this=20 leading-edge networking technology.  The class is limited to = 20=20 students, and we are expecting this session to sell out extremely = quickly, so=20 time is of the essence if you plan on registering either yourself and/or = your=20 colleagues on this course.
     
    **PLEASE NOTE THAT AS A SPECIAL OFFER, = ANYONE=20 SIGNING UP MORE THAN ONE ATTENDEE ON THIS COURSE WITH ME AT A TIME WILL = RECEIVE=20 A COMPLIMENTARY NORTHLAND DENIM SHIRT FOR THEMSELVES AS WELL AS THEIR=20 COLLEAGUE(S)!!!**
     
    As an added value, all attendees will receive 30 days free = access=20 to the Northland Online "MPLS Technology" eLearning course upon = completion of=20 this session!
     
      =20             &= nbsp;          =20 This course introduces the = challenge of the=20 next generation networks and describes how MPLS addresses it at both a = high and=20 low level. Participants are expected to have a strong understanding = and=20 experience in WANs, LANs, data communications, routing, internetworking, = and=20 communications protocols.
     
    This course will:
    • Explain the MPLS concepts, architecture & components.=20
    • Provide an in-depth view of MPLS.=20
    • Provide a thorough understanding across all areas of the = technology.=20
    • Describe how MPLS relates to different evolving network=20 technologies.
    Please review the detailed course = outline below for=20 more information on the content being covered.
     
    To find out more about how to bring this = or any=20 other 2 day course in-house to a group at your facility, or to register, = please=20 call me directly at 613-667-5063.
     
    Have a great day!
     
    Sincerely,
     

    Alan P. Daly
    Account Representative
    Northland Systems = Training=20 Inc.
    255 Albert St. 5th Floor
    Ottawa,=20 ON
    K1P-6A9
    Direct:     (613)=20 667-5063
    Cellular:   (613)=20 223-1062
    Fax:        (613)=20 667-5098
    Check Out Our Website at http://www.northlandelearning.= com
     
    --------------------------------------------------------------------= --------
    "Changing=20 learning from an event to a life long process"
     
               &n= bsp;           &nb= sp;  =20 KNOW YOUR=20 WAY
               = visit=20 http://www.northlandelearning.= com
    --------------------------------------------------------------= --------------
     
    COURSE = OUTLINE:
    ***********************
     
    INTRODUCTION 
    =B7    &n= bsp;    =20 Why MPLS
    =B7          = Routers=20 & = Switches
    =B7          = Route=20 at Edge, Switch in=20 Core
    =B7          = Labeled Packet=20 Forwarding
    =B7          = Label=20 & FEC
    =B7          = Traffic=20 Aggregation or=20 Splitting
    =B7          = Label=20 Switched = Path
    =B7          LSP = and=20 the Node
    =B7          = LSP=20 Establishment
    =B7         = ; Packet=20 Labeling &=20 Forwarding
    =B7          = Forwarding=20 Table & = LIB
    =B7          FEC,=20 Labels & LSPs
     
    MPLS LABEL=20 ENCODING 
    =B7       &= nbsp; =20 Shim Layer = Concept
    =B7         =20 Layer 2 technologies &=20 Labels
    =B7          MPLS = Shim=20 Description
    =B7          = Shim=20 Fields (Label, Exp, S &=20 TTL)
    =B7          Label=20 Values
    =B7          = Media=20 Encapsulation
    =B7         = ; Hop=20 Popping
    =B7          = Routing &=20 Tunneling
    =B7          = Multipoint=20 to point = trees
    =B7          MPLS=20 reflects nature of IP=20 Networks
    =B7          = Label=20 Aggregation & Frame=20 merging
    =B7          = Overview:=20 What is MPLS?
     
    ICMP=20 MESSAGES 
    =B7       &= nbsp; =20 A brief review of=20 ICMP
    =B7          ICMP = Message to=20 source LSR
    =B7          = Tunneling=20 through an = AS
    =B7          Tunnel=20 Private Address via Public=20 Backbones
    =B7          = Extended=20 ICMP Message = Length
    =B7         =20 MPLS Extension Data=20 Structure
    =B7          = MPLS Object=20 Extensions
    =B7          = Stack=20 Entry Object & Extended payload=20 Object
    =B7          = Traceroute=20 over MPLS
     
    LDP SIGNALING=20 PROTOCOL 
    =B7       &= nbsp; =20 LDP = Overview
    =B7         =20 Applicability &=20 Features
    =B7          = Scalability=20 & = Security
    =B7          = LSP=20 Establishment
    =B7         = ;=20 Upstream LSR versus Downstream=20 LSR
    =B7          = Downstream or=20 Upstream Label=20 Binding
    =B7          = Unsolicited=20 versus = On-Demand
    =B7         =20 Independent or=20 Ordered
    =B7          = Conservative=20 or Liberal Label=20 Retention
    =B7          = Label=20 Request = Procedures
    =B7          = L=20 DP over TCP between=20 Neighbors
    =B7          = LDP=20 Security &=20 Privacy
    =B7          LDP = Message=20 Format & = Types
    =B7         =20 For further study=20 items
    =B7          LDP = Message=20 Format & = Types
    =B7         =20 Hello Messages & Targeted=20 Hellos
    =B7          = Encoding of=20 Hello Message &=20 TLVs
    =B7          Common = &=20 Optional Hello=20 Parameters
    =B7          = Hello=20 Discovery = Phase
     =B7          = TCP Connection = Phases
    =B7         =20 Session Initialization State=20 Machine
    =B7          = Session=20 Initialization=20 Message
    =B7          = Frame Relay=20 Session = Parameters
    =B7         =20 Advertisement Messages to set=20 LSP
    =B7          Label = Request=20 & Mapping=20 Messages
    =B7          = Label Abort,=20 Withdraw & Release=20 Messages
    =B7          = Address=20 & Address Withdraw=20 Messages
    =B7          = Vendor=20 Private = Messages
    =B7         =20 Notification & Keep Alive=20 Messages
    =B7          = Detailed TLV=20 Encoding
     
    CR-LDP SIGNALING=20 PROTOCOL 
    =B7       &= nbsp; =20 CR-LDP = Overview
    =B7         =20 Constraint-Routing
    =B7        =  =20 CR-LDP = Features
    =B7         =20 Traffic = Parameters
    =B7         =20 Strict & Loose Explicit=20 Routing
    =B7          = Explicit=20 Route TLV
    =B7          = Node &=20 Abstract = Node
    =B7         =20 CSPF
    =B7         =20 Preemption
    =B7          = Route=20 Pinning
    =B7          = Handling of=20 Failures
    =B7         =20 LSPID
    =B7          = Resource=20 Class
    =B7          = CR-LDP=20 Messages
    =B7          = LDP=20 PDUs
    =B7          CR-LDP = Message=20 Format
    =B7          = Label Request=20 & Mapping=20 Messages
    =B7          = Notification=20 Message
    =B7          = Detailed=20 CR-LDP TLV Encoding
     
    RSVP-TE SIGNALING=20 PROTOCOL 
    =B7       &= nbsp; =20 Review of = RSVP
    =B7          RSVP=20 Node & Session Data=20 Flow
    =B7          = Reservation=20 Styles
    =B7          RSVP = PATH=20 & RESV = Messages
    =B7         =20 Reservation & Data=20 Flow
    =B7          PATH = Message=20 & RESV = Messages
    =B7         =20 RSVP Message Common=20 Header
    =B7          RSVP = Message=20 Object = Structure
    =B7          = RSVP=20 Message = Objects
    =B7         =20 RSVP-TE Common = Header
    =B7         =20 RSVP-TE Message Object=20 Structure
    =B7          = RSVP-TE LSP=20 Setup Flow
    =B7          = New=20 RSVP-TE = Objects
    =B7          New = C-types
    =B7          = RSVP-TE Label=20 Request & Label=20 Objects
    =B7          LSP = Tunnel IP=20 Session = Object
    =B7          ERO=20 & RRO = Objects
    =B7         =20 Path Additional Data=20 Objects
    =B7          = RSVP-TE=20 versus = CR-LDP
    =B7         =20 Comparative Analysis
     
    BGP=20 4 
    =B7        &n= bsp; A=20 brief Review on = BGP4
    =B7         =20 Routing &=20 Tunneling
    =B7          = Directly=20 connected = LSRs
    =B7         =20 Not-directly connected BGP LSRs
     
    MPLS over=20 ATM 
    =B7        =   A=20 brief review of = ATM
    =B7         =20 Motivation for MPLS over=20 ATM
    =B7          ATM-LSR = (LC-ATM,=20 LSR-CC, = ATM-CC)
    =B7         =20 ATM-LSR Behavior &=20 Constraints
    =B7          = Frame-based & Cell-based=20 LSRs
    =B7          = ATM-LSR=20 Integrated & Peer=20 Approaches
    =B7          = SIN Model=20 - Ships in the = Night
    =B7         =20 Transparent Point-to-Point=20 Link
    =B7          RFC=20 2684/1483
    =B7          = Connected=20 through a VP or a = VC
    =B7         =20 VCID & VCID=20 Signaling
    =B7          = ATM Label=20 Stack = Encoding
    =B7         =20 Passing SHIM fields across=20 ATM
    =B7          VC = Merge &=20 Non-VC Merge = ATM-LSRs
    =B7         =20 Communication from edge to edge LSRs
     
    VIRTUAL = PRIVATE=20 NETWORKS 
    =B7       &= nbsp; =20 A brief review on = VPN
    =B7         =20 VPN Overlay & Peer=20 Models
    =B7          VPN = Peer Model=20 Key = Technologies
    =B7         = =20 Constrained Distribution of=20 Routing
    =B7          = Extended=20 Communities
    =B7          = PE=20 Forwarding = Tables
    =B7         =20 VPN-IP = Address
    =B7          BGP = in=20 PE, IGP within the Provider=20 Network
    =B7          = MPLS as the=20 forwarding Mechanism
     
    MPLS QoS=20 SUPPORT 
    =B7       &n= bsp; =20 A brief review on IP=20 QoS
    =B7          IntServ = QoS=20 Model
    =B7          = Guaranteed=20 Service & Controlled=20 Load
    =B7          MPLS = RSVP-TE=20 Support of  InServ=20 QoS
    =B7          = Diff-Serv QoS=20 Model
    =B7          MPLS = Support of=20 Diff-Serv
    =B7          = E-LSP &=20 L-LSP
    =B7          MPLS = ECN=20 Support
     
    MPLS EVOLUTION &=20 REFERENCES 
    =B7       = ;  =20 IP Switching=20 Initiatives
    =B7          = MPLS=20 Forum
    =B7          IETF = Working=20 Group MPLS = Charter
    =B7         =20 MPLS Drafts &=20 Standards
    =B7          = MPLS Vendor=20 Products
    =B7          = MPLS Testing=20 & Analyser=20 Products
    =B7         =20 Interoperability Testing=20 Centers
    =B7          = Example of=20 interoperability=20 testing
    =B7          = MPLS Resource=20 Center
    =B7          MPLS = Applications & Early=20 Adopters
    =B7          = Evolution of=20 the = Internet
    =B7         =20 Convergence of Audio, Video &=20 Data
    =B7          Next = Generation=20 Applications
    =B7         = Abilene=20 & vBNS NGI=20 Initiatives
    =B7          = CA*net 2=20 & 3
    =B7          = Next=20 Generation Networks Key Technologies
     
     =20
     
    ------=_NextPart_000_07C5_01C1B56C.F40EF180-- _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Tue Feb 19 08:10:27 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17061 for ; Tue, 19 Feb 2002 08:10:27 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1JD8wK44043; Tue, 19 Feb 2002 05:08:58 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from yahoo.com (adsl-63-197-151-245.dsl.snfc21.pacbell.net [63.197.151.245]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id g1IKdDK35503 for ; Mon, 18 Feb 2002 12:39:16 -0800 (PST) (envelope-from youcherry@yahoo.com) Message-Id: <200202182039.g1IKdDK35503@catarina.usc.edu> From: youcherry@yahoo.com Reply-To: youcherry@yahoo.com To: pim@catarina.usc.edu MIME-Version: 1.0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 8bit Subject: [Pim] Take me. Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: 18 Feb 2002 21:11:55 GMT Content-Transfer-Encoding: 8bit


    Can you break my cherry?

    Click Here and give it a try...

    Little sluts are waiting for your big dick!
    What are you waiting for?

    HERE
















    Note: this is not a spam email. This email was sent to you because your email was entered in on a website requesting to be a registered subscriber. If you did not request this email, please just answer on this mail.


    _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed Feb 20 03:42:51 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25092 for ; Wed, 20 Feb 2002 03:42:49 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1K8b5K58635; Wed, 20 Feb 2002 00:37:05 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from localhost ([211.50.255.50]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id g1FI5pK96936 for ; Fri, 15 Feb 2002 10:05:54 -0800 (PST) (envelope-from pricelist@hutmail.com) Message-Id: <200202151805.g1FI5pK96936@catarina.usc.edu> Reply-To: pricelist@hutmail.com From: 컴정보 To: pim@catarina.usc.edu Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Subject: [Pim] {광 고} 컴퓨터가격정보 메일링 회원이 되세요 (^-^)~ Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 16 Feb 2002 03:05:45 +0900 컴퓨터 가격정보 메일링 신청 받습니다.

    먼저 허락없이 글을 올린것에 대해 진심으로 사과말씀 드립니다.
    귀하의 이메일 주소는 인터넷 게시판을 통하여 취합하였습니다

    컴퓨터 가격정보를
    매일 매일 회원님의 이메일로 발송해 드리는 서비스입니다.
    항상 최신의 가격정보가 회원님의 이메일속에 담겨져 있게 해드리겠습니다.

    현재 일간(화,목,토요일 발행) 및 주간(목요일 발행) 형태로 발행중입니다.
    일요일 및 공휴일은 발행을 하지 않습니다.

    물론 본 서비스는 무료입니다.

    구독신청은 메일주소만 써주시면 끝입니다.. 간단하죠..^^

    컴퓨터 가격정보 [일간]



    컴퓨터 가격정보 [주간]


    한메일 사용자용 [일간]
      컴퓨터가격정보

    한메일 사용자용 [주간]
      컴퓨터가격정보

    지난메일링보기 ★

    본 메일로 기분 상하셨다면 깊이사과 드립니다.!
    수신거부 해주시면 반복발송하지 않도록 하겠습니다.
    본메일은 1회성 메일입니다.

    수신거부 <== 수신거부는 꼭 요기를 눌러주세요.. 감사합니다.

     _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Wed Feb 20 10:25:51 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03535 for ; Wed, 20 Feb 2002 10:25:51 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1KFNDK62044; Wed, 20 Feb 2002 07:23:13 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from hatoo.net ([61.101.11.42]) by catarina.usc.edu (8.11.6/8.11.6) with SMTP id g1KFMBK62033 for ; Wed, 20 Feb 2002 07:22:12 -0800 (PST) (envelope-from hatoo@hatoo.net) Message-ID: <417074-22002232015238874@hatoo.net> X-EM-Version: 6, 0, 0, 4 X-EM-Registration: #0010630410721500AB30 Reply-To: "'도학위룡'" From: "도학위룡" To: pim@catarina.usc.edu MIME-Version: 1.0 Content-Type: text/html; charset=euc-kr Subject: [Pim] [광고] 아시나요? 용쟁화투? Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 21 Feb 2002 00:23:08 +0900
     
     
     
     
    안녕하세요.
    밝은 마음, 밝은 화투, 용쟁화투입니다.

    용쟁화투가 뭐냐구요?
    용쟁화투는 디자인 전문회사에서 만든 캐릭터 화투입니다.

    많은 분들이 즐기시지만 부정적인 이미지를 많이 담고 있는 기존의 화투를
    밝고 긍정적인 이미지로 Redisign한 화투랍니다.

    이제 음침한 분위기의 화투는 안녕~~~
    마음까지 밝아지는 용쟁화투를 즐겨보세요^^



    귀하의 승락없이 홍보성 이메일을 보내게 된 점 정중히 사과드립니다.

    본메일은 정보통신망 이용촉진법 규정을 준수하여 [광고] 메일임을 표시하였으며, 수신거부를 할수 있도록 하였습니다.

    본 메일은 인터넷 상에 공개된 메일 주소를 근거로 발송하였으며
    귀하의 이메일 정보 이외에 저희가 보유하고 있는 개인정보는 일체 갖고 있지않음을 알려드립니다.

    귀하의 행복한 날과 하시는일 모두 번창하시길 바랍니다.
    		 
     
    Copyright(c) 2001 PARL Entertainment Co,.Ltd All right Reserved.
    _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Thu Feb 28 02:28:49 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13522 for ; Thu, 28 Feb 2002 02:28:48 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1S7P7n80670; Wed, 27 Feb 2002 23:25:07 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from vegas.usc.edu (vegas.usc.edu [204.57.0.6]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1KMZDK73518 for ; Wed, 20 Feb 2002 14:35:13 -0800 (PST) (envelope-from mehringe@vegas.usc.edu) Received: (from mehringe@localhost) by vegas.usc.edu (8.11.6/8.11.6) id g1KMZnX03665 for pim@catarina.usc.edu; Wed, 20 Feb 2002 14:35:49 -0800 From: John Mehringer Message-Id: <200202202235.g1KMZnX03665@vegas.usc.edu> To: pim@catarina.usc.edu Subject: [Pim] Test Message Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 20 Feb 2002 14:35:49 -0800 _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim From pim-admin@catarina.usc.edu Thu Feb 28 04:55:06 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15657 for ; Thu, 28 Feb 2002 04:55:06 -0500 (EST) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1S9q1n82786; Thu, 28 Feb 2002 01:52:02 -0800 (PST) (envelope-from pim-admin@catarina.usc.edu) Received: from mx06aba.westnet24.com ([208.178.66.37]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g1S9Won82586 for ; Thu, 28 Feb 2002 01:32:51 -0800 (PST) (envelope-from amalik@ns1.ehost2102.com) Message-Id: <200202280931.g1S9Ut414752@mx06aba.westnet24.com> X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Reply-To: From: To: Subject: [Pim] Thanks For Lunch Mike Sender: pim-admin@catarina.usc.edu Errors-To: pim-admin@catarina.usc.edu X-BeenThere: pim@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 28 Feb 2002 04:31:05 -0500 Mike, Thanks again for lunch it was great! Best regards, Steve _______________________________________________ Pim mailing list Pim@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/pim