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
- Vendor Private Extension James Luciani
- Re: Vendor Private Extension Bruce Cole
- Re: Vendor Private Extension James Luciani
- Re: Vendor Private Extension Bruce Cole
- Re: Vendor Private Extension James Luciani
- Re: Vendor Private Extension Bruce Cole
- Re: Vendor Private Extension James Luciani
- Re: Vendor Private Extension Andrew Smith
- Re: Vendor Private Extension Trevor Blackwell
- Re: Vendor Private Extension Telford001
- Re: Vendor Private Extension Curtis Villamizar
- Re: Vendor Private Extension Tony Li
- Re: Vendor Private Extension Curtis Villamizar
- Re: Vendor Private Extension Tony Li
- Re: Vendor Private Extension Trevor Blackwell