Re: IDR WG Last Call

Enke Chen <enke@redback.com> Tue, 15 January 2002 17:47 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 MAA02015 for <idr-archive@nic.merit.edu>; Tue, 15 Jan 2002 12:47:47 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 73D6E91224; Tue, 15 Jan 2002 12:47:23 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DE4291239; Tue, 15 Jan 2002 12:47:23 -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 4921991224 for <idr@trapdoor.merit.edu>; Tue, 15 Jan 2002 12:47:18 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 13C2C5DDAE; Tue, 15 Jan 2002 12:47:18 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id D1B395DDAC for <idr@merit.edu>; Tue, 15 Jan 2002 12:47:17 -0500 (EST)
Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 2810DF2C5C; Tue, 15 Jan 2002 09:47:17 -0800 (PST)
Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id CC5A815D3C1; Tue, 15 Jan 2002 09:47:16 -0800 (PST)
To: Jeffrey Haas <jhaas@nexthop.com>
Cc: idr@merit.edu, enke@redback.com
Subject: Re: IDR WG Last Call
In-Reply-To: Message from Jeffrey Haas <jhaas@nexthop.com> of "Mon, 14 Jan 2002 23:21:28 EST." <20020114232128.B14701@nexthop.com>
Date: Tue, 15 Jan 2002 09:47:16 -0800
From: Enke Chen <enke@redback.com>
Message-Id: <20020115174716.CC5A815D3C1@popserv1.redback.com>
Sender: owner-idr@merit.edu
Precedence: bulk

Jeff,

> 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>
> 
> 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. :-)

So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem to add
much value, but has caused a lot of confusion and complexity. I am not
aware of any depolyment either.

> 
> > 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.

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.

-- Enke