Re: IDR WG Last Call

Jeffrey Haas <jhaas@nexthop.com> Tue, 15 January 2002 21:17 UTC

Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA09269 for <idr-archive@nic.merit.edu>; Tue, 15 Jan 2002 16:17:08 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 5F77F91274; Tue, 15 Jan 2002 16:16:25 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 778DE91277; Tue, 15 Jan 2002 16:16:24 -0500 (EST)
Delivered-To: idr@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 204CC91274 for <idr@trapdoor.merit.edu>; Tue, 15 Jan 2002 16:16:23 -0500 (EST)
Received: by segue.merit.edu (Postfix) id F06655DDAC; Tue, 15 Jan 2002 16:16:22 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id A9F9E5DDA5 for <idr@merit.edu>; Tue, 15 Jan 2002 16:16:22 -0500 (EST)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0FLFr398465; Tue, 15 Jan 2002 16:15:53 -0500 (EST) (envelope-from jhaas@nexthop.com)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0FLFqL16584; Tue, 15 Jan 2002 16:15:52 -0500 (EST)
Date: Tue, 15 Jan 2002 16:15:52 -0500
From: Jeffrey Haas <jhaas@nexthop.com>
To: Enke Chen <enke@redback.com>
Cc: idr@merit.edu
Subject: Re: IDR WG Last Call
Message-ID: <20020115161552.C16527@nexthop.com>
References: <jhaas@nexthop.com> <20020115174716.CC5A815D3C1@popserv1.redback.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20020115174716.CC5A815D3C1@popserv1.redback.com>; from enke@redback.com on Tue, Jan 15, 2002 at 09:47:16AM -0800
X-NextHop-MailScanner: Found to be clean
Sender: owner-idr@merit.edu
Precedence: bulk

On Tue, Jan 15, 2002 at 09:47:16AM -0800, Enke Chen wrote:
> If we want to define the behavior, I would like to suggest sticking to
> the order in the message. That probably would reflect the sender's
> intention more closely, and make the processing simpler.

Two issues:
1. Path attribute order, when sorted, puts MP_UNREACH_NLRI after 
   MP_REACH_NLRI.
2. Path attributes are now explicitly allowed to be unordered.

I'd rather see some determinism across implementations.

> -- Enke

-- 
Jeff Haas 
NextHop Technologies