Re: PQC and QOSPF
Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Thu, 23 July 1998 18:51 UTC
Delivery-Date: Thu, 23 Jul 1998 14:51:05 -0400
Return-Path: owner-qosr@ca.newbridge.com
Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA06438 for <ietf-archive@ietf.org>; Thu, 23 Jul 1998 14:51:04 -0400 (EDT)
Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id OAA28893; Thu, 23 Jul 1998 14:47:47 -0400 (EDT)
Received: from kanata-gw1.newbridge.com(192.75.23.72), claiming to be "kanata-gw1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa28861; Thu Jul 23 14:47:39 1998
Received: from kanmaster.ca.newbridge.com by kanata-gw1.ca.newbridge.com via smtpd (for ns.newbridge.com [192.75.23.67]) with SMTP; 23 Jul 1998 18:47:37 UT
Received: from distmaster.newbridge.com (distmaster.ca.newbridge.com [138.120.118.27]) by ca.newbridge.com. (8.8.8/8.8.6) with SMTP id OAA01600; Thu, 23 Jul 1998 14:47:27 -0400 (EDT)
Received: by distmaster.newbridge.com (SMI-8.6/SMI-SVR4) id OAA20193; Thu, 23 Jul 1998 14:35:44 -0400
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199807231825.DAA09823@necom830.hpcl.titech.ac.jp>
Subject: Re: PQC and QOSPF
To: zzhang@argon.com
Date: Fri, 24 Jul 1998 03:24:43 -0000
Cc: ychen@fla.fujitsu.com, qosr@newbridge.com
In-Reply-To: <199807231238.IAA06171@rodney>; from "Zhaohui Zhang" at Jul 23, 98 8:38 am
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-qosr@ca.newbridge.com
Precedence: bulk
X-Info: [Un]Subscribe to qosr-request@newbridge.com
Jeffry; > I have not read the paper yet, so my response is based your email only. I think you have. > Flooding RRAs anywhere does cause the scaling problem, but from day one > we proposed an alleviation - use Explicit Routing. Nope. ER does not work with large scale multicast. Note also that multicast routing table can not be aggregated, which makes inter-/intra- domain separation of QoSR meaningless. That is, you can't say you can ignore scalability issues of QOSPF by flow aggregation. > We also tried to put it into RSVP so that only routers on the path would > get the info, but RSVP folks did not think that was a good idea, so we > had to give up. It, of course, is a bad idea to use RSVP to let multicast members know about all the pathes to all the other members. Masataka Ohta
- Re: PQC and QOSPF Yao-Min Chen
- PQC in draft-ietf-qosr-framework-06.txt FUJIKAWA Kenji
- Re: PQC in draft-ietf-qosr-framework-06.txt Masataka Ohta
- PQC and QOSPF Yao-Min Chen
- Re: PQC and QOSPF Zhaohui Zhang
- Re: PQC and QOSPF Masataka Ohta
- Re: PQC and QOSPF Yao-Min Chen
- Re: PQC and QOSPF Yao-Min Chen
- Re: PQC and QOSPF FUJIKAWA Kenji
- Re: PQC and QOSPF Masataka Ohta
- Re: PQC and QOSPF Masataka Ohta
- Re: PQC and QOSPF Zhaohui Zhang
- Re: PQC and QOSPF Jon Crowcroft
- Re: PQC and QOSPF Masataka Ohta
- Re: PQC and QOSPF Kenneth CARLBERG
- Re: PQC and QOSPF Masataka Ohta
- Re: PQC and QOSPF Kenneth CARLBERG
- Re: PQC and QOSPF Yao-Min CHEN