Re: Ordering of NHRP extensions

Paul_Koning/US/3Com%3COM@smtp1.isd.3com.com Fri, 03 May 1996 16:07 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20007; 3 May 96 12:07 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa19995; 3 May 96 12:07 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 LAA19430; Fri, 3 May 1996 11:57:58 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id LAA23503 for rolc-out; Fri, 3 May 1996 11:55:57 -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 LAA23494 for <rolc@nexen.com>; Fri, 3 May 1996 11:55:53 -0400 (EDT)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Paul_Koning/US/3Com%3COM@smtp1.isd.3com.com
Received: from ISD.3Com.com (chipcom.com [192.41.247.9]) by nexen.nexen.com (8.7.3/8.7.3) with SMTP id LAA18049 for <rolc@nexen.com>; Fri, 3 May 1996 11:55:51 -0400 (EDT)
Received: from (smtp1.chipcom.com) by ISD.3Com.com (4.1/SMI-4.0) id AA07491; Fri, 3 May 96 11:55:32 EDT
Received: by (IBM OS/2 SENDMAIL VERSION 1.3.17/1.2) id AA5395; Fri, 03 May 96 11:55:48 -0700
Message-Id: <9605031855.AA5395@>
Received: by 3Com (Lotus Notes Mail Gateway for SMTP V1.1) id D95F640A19917CB98525631F00574B6F; Fri, 3 May 96 11:55:47 EDT
To: luciani@baynetworks.com
Cc: rolc@nexen.com
Date: Fri, 03 May 1996 11:56:19 -0400
Subject: Re: Ordering of NHRP extensions
Mime-Version: 1.0
Content-Type: Text/Plain
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/

>> Is there any implied ordering of extensions in an NHRP packet?
>Good idea! :-)  I actually suggested this (via proxy of Andy Malis)
>at the last European based IETF.  I explicitly asked for 2 things:
>1) the extensions be placed in numerical order by type code

I hope not.  This might in a few cases speed up receive processing
slightly, at the cost of a more substantial hit in time and complexity
at the transmit end.

I assume here that you meant that the receiver is allowed to assume
order but is not expected to check it.  Clearly, requiring the receiver
to check an ordering rule is a really bad idea.  Note that in any case
your receiver has to be able to survive arrival of packets with out of
order options -- though it would not be required to do useful things
with such packets.

This sort of idea has been floated in other places and generally
rejected.  I think it should be rejected here as well.

 paul

!-----------------------------------------------------------------------
! Paul Koning, NI1D, C-24183
! 3Com Corporation, 1-3A, 118 Turnpike Road, Southborough MA 01772 USA
! phone: +1 508 229 1695, fax: +1 508 490 5873
! email: paul_koning@isd.3com.com  or  paul_koning@3mail.3com.com
! Pgp:   27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over 
!  any member of a civilized community, against his will, is to prevent
!  harm to others.  His own good, either physical or moral, is not
!  a sufficient warrant."    -- John Stuart Mill, "On Liberty" 1859