From owner-freebsd-net@FreeBSD.ORG Wed Apr 21 00:13:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE4B016A4CE for ; Wed, 21 Apr 2004 00:13:44 -0700 (PDT) Received: from home.bluegrass.sk (home.bluegrass.sk [195.168.129.26]) by mx1.FreeBSD.org (Postfix) with SMTP id EF9A943D5C for ; Wed, 21 Apr 2004 00:13:42 -0700 (PDT) (envelope-from milan.obuch@bluegrass.sk) Received: (qmail 35203 invoked from network); 21 Apr 2004 07:13:41 -0000 Received: from tmp.bluegrass.sk (HELO localhost.invalid) (195.168.129.28) by bsd.bluegrass.sk with SMTP; 21 Apr 2004 07:13:41 -0000 From: Milan Obuch To: freebsd-net@freebsd.org Date: Wed, 21 Apr 2004 09:13:40 +0200 User-Agent: KMail/1.6 References: <20040419110912.A71274@xorpc.icir.org> <40861A71.1020502@he.iki.fi> <20040420235858.B47612@xorpc.icir.org> In-Reply-To: <20040420235858.B47612@xorpc.icir.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404210913.40513.milan.obuch@bluegrass.sk> Subject: Re: what is the story on if_index allocation ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 07:13:44 -0000 On Wednesday 21 April 2004 08:58, Luigi Rizzo wrote: > On Wed, Apr 21, 2004 at 09:53:37AM +0300, Petri Helenius wrote: > ... > > > Relevant quote from the RFC: > > a very appropriate one indeed, which seems to substantiate my point. > > > interfaces that might be added dynamically. The exact meaning of a > > "different" interface is hard to define, and there will be gray > > areas. Any firm definition in this document would likely turn out to > > be inadequate. Instead, implementors must choose what it means in > > their particular situation, subject to the following rules: > > so if there are gray areas in defining 'different' the same applies > to defining 'same' :) > > cheers > luigi > I would say the easiest way is to take any new interface as 'different' in relation to any once existed but deleted in past interface and let the management station define what does it mean to be 'the same' interface. We would have sparsely allocated ifindex values after some interface creation/deletion, which is not a big issue to me. I would not think there is one-to-one mapping even for one network management solution, it depends on actual needs. Regards, Milan