IETF Logo Mail Archive

Re: Active Route - OT

"John G. Scudder" <jgs@cisco.com> Fri, 04 October 2002 15:32 UTC

Received: from trapdoor.merit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08067 for <idr-archive@ietf.org>; Fri, 4 Oct 2002 11:32:01 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C172491212; Fri, 4 Oct 2002 11:33:45 -0400 (EDT)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7088191384; Fri, 4 Oct 2002 11:33:42 -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 3CF4B91212 for <idr@trapdoor.merit.edu>; Fri, 4 Oct 2002 11:31:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 084475DEE4; Fri, 4 Oct 2002 11:31:44 -0400 (EDT)
Delivered-To: idr@merit.edu
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id 4B82C5DEDC for <idr@merit.edu>; Fri, 4 Oct 2002 11:31:43 -0400 (EDT)
Received: from [171.69.182.140] (dhcp-171-69-182-140.cisco.com [171.69.182.140]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA06050; Fri, 4 Oct 2002 11:31:21 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a02b9c36307fdc7@[192.168.42.10]>
In-Reply-To: <20021004105951.C11052@nexthop.com>
References: <39469E08BD83D411A3D900204840EC55BC2F25@vie-msgusr-01.dc.fore.com> <3D9D5734.8B38A91D@alcatel.be> <20021004105951.C11052@nexthop.com>
Date: Fri, 04 Oct 2002 11:27:19 -0400
To: Jeffrey Haas <jhaas@nexthop.com>
From: "John G. Scudder" <jgs@cisco.com>
Subject: Re: Active Route - OT
Cc: hans.de_vleeschouwer@alcatel.be, idr@merit.edu
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-idr@merit.edu
Precedence: bulk

At 10:59 AM -0400 10/4/02, Jeffrey Haas wrote:
>  > Unless  of course, my whole appreciation of the atributes is 
>wrong. But in this
>>  case it would be good to indicate what can and cannot be expected from an
>>  attribute.
>
>Honestly, its best to *not* expect anything beyond guaranteeing loop
>free routing.  The fact that you can *try* is an operational decision.
>It might even work.

Indeed, and this has been called out in the spec for a very long time 
now, in the case of ATOMIC_AGGREGATE.  From 5.1.6:

    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
    attribute needs to be cognizant of the fact that the actual path to
    destinations, as specified in the NLRI of the route, while having the
    loop-free property, may not be the path specified in the AS_PATH
    attribute of the route.

Consider this statement in combination with your earlier observation 
that in effect, everything is an atomic aggregate (or at least, must 
be treated as if it were).

--John

v2.46.0 | Report a Bug | By Email | System Status