Re: Ordering of NHRP extensions

"Eric W. Gray" <gray@ctron.com> Fri, 03 May 1996 17:27 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21579; 3 May 96 13:27 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa21575; 3 May 96 13:27 EDT
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id NAA19973; Fri, 3 May 1996 13:17:53 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id NAA24811 for rolc-out; Fri, 3 May 1996 13:13:49 -0400 (EDT)
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id NAA24802 for <rolc@nexen.com>; Fri, 3 May 1996 13:13:46 -0400 (EDT)
Received: from gatekeeper.ctron.com (ctron.com [134.141.197.25]) by nexen.nexen.com (8.7.3/8.7.3) with SMTP id NAA19562 for <rolc@nexen.com>; Fri, 3 May 1996 13:13:42 -0400 (EDT)
Received: (from news@localhost) by gatekeeper.ctron.com (8.6.12/8.6.9) id NAA02291; Fri, 3 May 1996 13:13:31 -0400
Received: from stealth.ctron.com(134.141.5.107) by gatekeeper via smap (V1.3mjr) id sma002265; Fri May 3 13:13:07 1996
Received: from olympus.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA14682; Fri, 3 May 96 13:05:23 EDT
Received: from blarney (blarney.ctron.com [134.141.66.40]) by olympus.ctron.com (8.6.12/8.6.9) with ESMTP id NAA11288; Fri, 3 May 1996 13:13:07 -0400
Received: from blarney by blarney via SMTP (940816.SGI.8.6.9/930416.SGI) id NAA21649; Fri, 3 May 1996 13:13:14 -0400
Message-Id: <318A3EA4.63DE@ctron.com>
Date: Fri, 03 May 1996 13:13:08 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Eric W. Gray" <gray@ctron.com>
Organization: Cabletron Systems, Inc.
X-Mailer: Mozilla 2.0 (X11; I; IRIX 5.3 IP12)
Mime-Version: 1.0
To: "James V. Luciani" <luciani@baynetworks.com>
Cc: David Horton <horton@citr.com.au>, rolc@nexen.com
Subject: Re: Ordering of NHRP extensions
References: <9605031450.AA02046@exnex.engeast>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: [Un]Subscribe to rolc-request@nexen.com, submissions to rolc@nexen.com
X-Info: Email archive at ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/
X-Info: Hypermail archive at http://cell-relay.indiana.edu/mail/archives/rolc/
X-Info: FTP archive at ftp://ftp.nexen.com/pub/rolc/

Jim,

You wrote (in part):

> 
> David,
> > Is there any implied ordering of extensions in an NHRP packet?
...
> 
> >
> > Is there any requirement for the extensions to be kept in the same
> > order when forwarded?
> > I can envisage an implementation where an NHS would always
> > send out extensions in some particular fixed order, e.g. have some
> > code that looks like :-
> >       if (input_packet.destination_prefix_present)
> >               add_destination_prefix_extension(out_packet)
> >       if (input_packet.NBMA_subnetwork_extension_present)
> >               add_NBMA_subnetwork_extension(out_packet)
> >       etc
> >
> > Could the next draft of NHRP add a positive statement on the
> > subject one way or the other?
> 
> What do folks think about the above suggestions?

Interoperability may require that it be spelled out explicitly - either
order is preserved or order is arbitrary.  In the same way that David
anticipates the order-destroying implementation above, I can imagine an
implementation in which the requester assumes extensions not received
in the same order as they were sent have been dropped (or otherwise
handled as exceptions, i.e. - not understood, etc.).

Your answer to the first question has an obvious bearing on this one.
If order is explicit, then only handling of extension types which may 
occur more than once needs to be specified.  I would think that order
must be preserved for Vendor Private Extensions (all others can occur
only once).

Also, regardless of other relevant issues, it is very reasonable to
require that all users of Vendor Private Extensions group them.