IETF Logo Mail Archive

Re: as4bytes - 4byte speaker receiving new* attributes?

Enke Chen <enke@redback.com> Tue, 08 May 2001 18:33 UTC

Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA20611 for <idr-archive@nic.merit.edu>; Tue, 8 May 2001 14:33:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C40CA5E677; Tue, 8 May 2001 14:21:41 -0400 (EDT)
Delivered-To: idr-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56) id 8C0BE5E60C; Tue, 8 May 2001 14:14:52 -0400 (EDT)
Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id D132C5E91B for <idr@merit.edu>; Tue, 8 May 2001 14:06:18 -0400 (EDT)
Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 8D60D60D2F1; Tue, 8 May 2001 11:06:18 -0700 (PDT)
Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 810DD7FFA6; Tue, 8 May 2001 11:06:18 -0700 (PDT)
To: Jeffrey Haas <jhaas@nexthop.com>
Cc: idr@merit.edu, enke@redback.com
Subject: Re: as4bytes - 4byte speaker receiving new* attributes?
In-Reply-To: Message from Jeffrey Haas <jhaas@nexthop.com> of "Tue, 08 May 2001 13:40:44 EDT." <20010508134044.B17620@nexthop.com>
Date: Tue, 08 May 2001 11:06:18 -0700
From: Enke Chen <enke@redback.com>
Message-Id: <20010508180618.810DD7FFA6@popserv3.redback.com>
Sender: owner-idr@merit.edu
Precedence: bulk

> Date: Tue, 8 May 2001 13:40:44 -0400
> From: Jeffrey Haas <jhaas@nexthop.com>
> To: Enke Chen <enke@redback.com>
> Cc: idr@merit.edu
> Subject: Re: as4bytes - 4byte speaker receiving new* attributes?
> Message-ID: <20010508134044.B17620@nexthop.com>
> References: <jhaas@nexthop.com> <20010508170954.7C9737FFA6@popserv3.redback.com>
> 
> On Tue, May 08, 2001 at 10:09:54AM -0700, Enke Chen wrote:
> > > In the current as4bytes draft (draft-ietf-idr-as4bytes-02.txt):
> > > :    The new attributes, NEW_AS_PATH and NEW_AGGREGATOR should not be
> > > :    carried in the updates between NEW BGP peers. A NEW BGP speaker that
> > > :    receives an UPDATE message from a NEW BGP speaker, with the
> > > :    NEW_AS_PATH attribute carried in the UPDATE message must ignore the
> > > :    attribute. The same applies to the NEW_AGGREGATOR attribute.
> 
> > There is no need to send a notification in this case as the receiver can deal with
> > the message and function properly. It is consistent with the famous protocol
> > rule: "Be conservative with what you send, and be liberal with what you accept".
> 
> I'm picturing two cases here:
> 1. The receiver gets a route containing both an as_path and a new_aspath.
>    Since both speakers are 4byte speakers, AS_PATH should contain
>    the same things as NEW_AS_PATH.  What if they don't?

Regardless, the NEW_AS_PATH is ignored.

> 2. If we simply ignore it, its still transitive. 

It was meant to be "ignored and dropped". We will clarify this in the next
revision.  Thanks. -- Enke

>    When this finally
>    gets to a 2byte boundary (possibly several AS's over), should
>    this speaker discard the NEW_AS_PATH prior to generating a new one?


> 
> It is my general impression that the NEW_* path attributes aren't
> really meant to exist within a 4byte domain and are only added
> on egress into a 2byte domain.  Perhaps I'm mistaken.
> 
> > -- Enke
> 
> -- 
> Jeff Haas 
> NextHop Technologies

v2.23.0 | Report a Bug | By Email