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