No subject
Sat May 17 20:32:47 2003
Return-Path: xorp-cvs-admin@icir.org
Delivery-Date: Sat, 17 May 2003 20:33:03 -0700
Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14])
by tigger.icir.org (8.12.8p1/8.12.3) with ESMTP id h4I3X3Kd012562
for <atanu@tigger.icir.org>; Sat, 17 May 2003 20:33:03 -0700 (PDT)
(envelope-from xorp-cvs-admin@icir.org)
Received: from fruitcake.icsi.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11])
by wyvern.icir.org (8.12.8p1/8.12.3) with ESMTP id h4I3X2DD015950
for <atanu@icir.org>; Sat, 17 May 2003 20:33:02 -0700 (PDT)
(envelope-from xorp-cvs-admin@icir.org)
Received: from fruitcake.icsi.Berkeley.EDU (localhost [127.0.0.1])
by fruitcake.icsi.Berkeley.EDU (8.12.9/8.12.9) with ESMTP id h4I3X2KJ007321;
Sat, 17 May 2003 20:33:02 -0700 (PDT)
Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14])
by fruitcake.icsi.Berkeley.EDU (8.12.9/8.12.9) with ESMTP id h4I3WmKJ007314
for <xorp-cvs@icsi.berkeley.edu>; Sat, 17 May 2003 20:32:48 -0700 (PDT)
Received: from vulture.icir.org (adsl-67-117-79-130.dsl.sntc01.pacbell.net [67.117.79.130])
by wyvern.icir.org (8.12.8p1/8.12.3) with ESMTP id h4I3WlDD015948;
Sat, 17 May 2003 20:32:48 -0700 (PDT)
(envelope-from mjh@vulture.icir.org)
Received: from vulture.icir.org (localhost [127.0.0.1])
by vulture.icir.org (8.12.8p1/8.12.3) with ESMTP id h4I3Wlin050462;
Sat, 17 May 2003 20:32:47 -0700 (PDT)
(envelope-from mjh@vulture.icir.org)
From: Mark Handley <mjh@icir.org>
X-Organisation: ICIR
To: pavlin@icir.org
cc: xorp-cvs@icir.org
Subject: Re: [Xorp-cvs] XORP cvs commit: xorp/libproto/ proto_unit.cc
In-reply-to: Your message of "Sat, 17 May 2003 19:56:50."
<200305180256.h4I2uojb093341@xorpc.icir.org>
Date: Sat, 17 May 2003 20:32:47 -0700
Message-ID: <50461.1053228767@vulture.icir.org>
Sender: xorp-cvs-admin@icir.org
Errors-To: xorp-cvs-admin@icir.org
X-BeenThere: xorp-cvs@icir.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:xorp-cvs-request@icir.org?subject=help>
List-Post: <mailto:xorp-cvs@icir.org>
List-Subscribe: <http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs>,
<mailto:xorp-cvs-request@icir.org?subject=subscribe>
List-Id: Mailing list for XORP CVS commit messages <xorp-cvs.icir.org>
List-Unsubscribe: <http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs>,
<mailto:xorp-cvs-request@icir.org?subject=unsubscribe>
> Note to ourselves: a number of target names
> ("fea", "bgp", "rib", "ospf" and probably few more) are hardcoded
> in a number of places, which is a bad style.
Hmm. I don't have a problem with the default name of the rib xrl
router being "rib", and BGP talking explicitly to the "rib" target.
Now, what should happen is that BGP registers interest in targets
called "rib", the finder tells BGP about a particular instance of this
target, and then BGP only talks to this specific instance. But this
requires a finder interface that isn't finished yet.
But if you're saying the the rib should under some circumstances call
it's XRL router "foobar" and BGP should somehow learn that the RIB is
called foobar today, then I think this is perhaps useful testing
functionality, but shouldn't normally be done.
One of the good things about XRLs in our architecture is that the
target names are a fixed point, at least for singleton processes.
This means you can write scripts or monitoring processes or whatever
that can work without needing an additional level of indirection
beyond that already provided by the finder. This is kind of like
well-known ports with TCP: yes, you can run an SMTP server on another
port than 25, but many people who you'd like to talk to you won't be
able to find you.
So, I don't think it's bad style to use and depend to a large degree
on well-known target names. But it probably should be possible to
override them if you really want to do so.
Cheers,
Mark
_______________________________________________
Xorp-cvs mailing list
Xorp-cvs@icir.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs