Re: IDR WG Last Call

Jeffrey Haas <jhaas@nexthop.com> Tue, 15 January 2002 04:22 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 XAA08514 for <idr-archive@nic.merit.edu>; Mon, 14 Jan 2002 23:22:05 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DAC6291238; Mon, 14 Jan 2002 23:21:41 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ACCC891239; Mon, 14 Jan 2002 23:21:41 -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 8041591238 for <idr@trapdoor.merit.edu>; Mon, 14 Jan 2002 23:21:40 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 4C0C95DDAC; Mon, 14 Jan 2002 23:21:40 -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 34D705DDA7 for <idr@merit.edu>; Mon, 14 Jan 2002 23:21:40 -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 g0F4LTo68244; Mon, 14 Jan 2002 23:21:29 -0500 (EST) (envelope-from jhaas@nexthop.com)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0F4LSY14723; Mon, 14 Jan 2002 23:21:28 -0500 (EST)
Date: Mon, 14 Jan 2002 23:21:28 -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: <20020114232128.B14701@nexthop.com>
References: <jhaas@nexthop.com> <20020115000424.A0D247E6C1@popserv3.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: <20020115000424.A0D247E6C1@popserv3.redback.com>; from enke@redback.com on Mon, Jan 14, 2002 at 04:04:24PM -0800
X-NextHop-MailScanner: Found to be clean
Sender: owner-idr@merit.edu
Precedence: bulk

On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote:
> It seems that the "SAFI 3" certainly makes the issue at hand much more
> complicated.

IMO, SAFI 3 was probably not a very good idea.  Dealing with it can
be a real pain in the implementation. :-)

> As Yakov and Sue pointed out, it is a good idea to discourage
> having one prefix in multiple fields of an update message. How about the
> following text:
> 
>    An UPDATE message should not include the same address prefix in more than
>    one of the following fields: WITHDRAWN ROUTES field, Network Reachability
>    Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The
>    processing of an UPDATE message in this form is un-defined.

I think that "undefined" is overkill.  I would suggest the following instead:

An UPDATE message should not include the same address prefix in
more than one of the following fields: WITHDRAWN ROUTES, Network
Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI.
An implementation that receives a packet in this form should process
the Update as if it had processed it in the following order:
WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer
Reachability Information.

The wording could probably use some tightening.

The intended result is that reachability rules over unreachability.

> -- Enke

-- 
Jeff Haas 
NextHop Technologies