Re: Vendor Private Extension

Trevor Blackwell <tlb@eecs.harvard.edu> Mon, 31 July 1995 19:44 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22978; 31 Jul 95 15:44 EDT
Received: from nexen.nexen.com by IETF.CNRI.Reston.VA.US id aa22970; 31 Jul 95 15:44 EDT
Received: from maelstrom.acton.timeplex.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id PAA00630; Mon, 31 Jul 1995 15:29:57 -0400
Received: (from root@localhost) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) id PAA01334 for rolc-out; Mon, 31 Jul 1995 15:26:53 -0400
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) with ESMTP id PAA01325 for <rolc@nexen.com>; Mon, 31 Jul 1995 15:26:50 -0400
Received: from cabernet.eecs.harvard.edu (cabernet.eecs.harvard.edu [140.247.60.60]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id PAA00398 for <rolc@nexen.com>; Mon, 31 Jul 1995 15:26:49 -0400
Received: from gorgonzola.eecs.harvard.edu (gorgonzola [140.247.60.111]) by cabernet.eecs.harvard.edu (8.6.12/8.6.12) with ESMTP id PAA04291 for <rolc@nexen.com>; Mon, 31 Jul 1995 15:06:59 -0400
Received: from localhost (localhost [127.0.0.1]) by gorgonzola.eecs.harvard.edu (8.6.12/8.6.12) with SMTP id OAA15427 for rolc@nexen.com; Mon, 31 Jul 1995 14:24:16 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Trevor Blackwell <tlb@eecs.harvard.edu>
Message-Id: <199507311824.OAA15427@gorgonzola.eecs.harvard.edu>
X-Authentication-Warning: gorgonzola.eecs.harvard.edu: Host localhost didn't use HELO protocol
To: rolc@nexen.com
Subject: Re: Vendor Private Extension
In-reply-to: Your message of "Mon, 31 Jul 95 10:50:34 PDT." <199507311750.KAA22139@greatdane.cisco.com>
Date: Mon, 31 Jul 95 14:24:16 -0400
X-Mts: smtp
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/

Could someone provide an example of a possible extension?  Right now I
can't imagine any very practical uses. What is it that might work
"better" between two brand-X routers?

If the extensions are for more detailed information, such as more
accurate cost or QOS descriptions, then maybe they should be made as
optional fields within the appropriate message elements, rather than
as top-level elements.

If the extensions are for fancy features, such as time/date dependent
routing or something, then it might make sense to implement these
entirely outside the scope of NHRP.

If there is some reasonable example, then I would definitely prefer to
see an explicit mechanism, rather than the time-honoured technique of
taking some message element that nobody else uses, and adapting it for
whatever special purposes.

--
Trevor Blackwell         tlb@eecs.harvard.edu          (617) 495-8912