Re: Another suggestion for draft-ietf-idr-bgp4-12.txt

Enke Chen <enke@redback.com> Thu, 23 August 2001 20:51 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 QAA12415 for <idr-archive@nic.merit.edu>; Thu, 23 Aug 2001 16:51:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C6724912F2; Thu, 23 Aug 2001 16:51:04 -0400 (EDT)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91F6A912F3; Thu, 23 Aug 2001 16:51:04 -0400 (EDT)
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 9E64F912F2 for <idr@trapdoor.merit.edu>; Thu, 23 Aug 2001 16:51:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 66FAD5DDA3; Thu, 23 Aug 2001 16:51:03 -0400 (EDT)
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 2238E5DDA0 for <idr@merit.edu>; Thu, 23 Aug 2001 16:51:03 -0400 (EDT)
Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 77C4BF2C54; Thu, 23 Aug 2001 13:51:02 -0700 (PDT)
Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv2.redback.com (Postfix) with ESMTP id 33F87979C1; Thu, 23 Aug 2001 13:51:02 -0700 (PDT)
To: Jeffrey Haas <jhaas@nexthop.com>
Cc: idr@merit.edu, enke@redback.com
Subject: Re: Another suggestion for draft-ietf-idr-bgp4-12.txt
In-Reply-To: Message from Jeffrey Haas <jhaas@nexthop.com> of "Thu, 23 Aug 2001 13:27:02 EDT." <20010823132702.D16323@nexthop.com>
Date: Thu, 23 Aug 2001 13:51:01 -0700
From: Enke Chen <enke@redback.com>
Message-Id: <20010823205102.33F87979C1@popserv2.redback.com>
Sender: owner-idr@merit.edu
Precedence: bulk

> Date: Thu, 23 Aug 2001 13:27:02 -0400
> From: Jeffrey Haas <jhaas@nexthop.com>
> To: Enke Chen <enke@redback.com>, idr@merit.edu
> Subject: Re: Another suggestion for draft-ietf-idr-bgp4-12.txt
> Message-ID: <20010823132702.D16323@nexthop.com>
> References: <20010822181519.D48CA7E6C1@popserv3.redback.com>
>
> On Wed, Aug 22, 2001 at 11:15:19AM -0700, Enke Chen wrote:
> > The requirement on attribute ordering no longer makes sense with the
> > MP_* attributes as they contain NLRI but with values inbetween other
> > true attributes. In addition, the requirement does not reflect
> > the reality (deployed codes) AFAIK.
> > 
> > As the receiver is always required to deal with out of order attributes,
> > the attribute ordering requirement is not really necessary, and is
> > safe to relax.
> 
> And here's the original text:
> 
> > !    The sender of an UPDATE message should order path attributes within
> > !    the UPDATE message in ascending order of attribute type.  The
> 
> In the spirit of RFC 2119, I don't think we need to alter this text:
> 
> : 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
> :    may exist valid reasons in particular circumstances to ignore a
> :    particular item, but the full implications must be understood and
> :    carefully weighed before choosing a different course.

This "SHOULD/RECOMMENED" no longer makes sense with the introduction of
MP_REACH and MP_UNREACH (see my original message). Is there any reason
that we should continue this recommendation?

-- Enke