IETF Logo Mail Archive

re: checking for empty AS_PATH

Timothy O'Connor <toconnor@bbn.com> Fri, 18 July 1997 20:45 UTC

Received: from cnri by ietf.org id aa14386; 18 Jul 97 16:45 EDT
Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA16964 for <ietf-archive@cnri.reston.va.us>; Fri, 18 Jul 1997 16:43:56 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id PAA11978 for idr-outgoing; Fri, 18 Jul 1997 15:55:33 -0400 (EDT)
Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by merit.edu (8.8.5/8.8.5) with SMTP id PAA11968 for <bgp@merit.edu>; Fri, 18 Jul 1997 15:55:24 -0400 (EDT)
Received: by interlock.ans.net id AA26813 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Fri, 18 Jul 1997 15:55:16 -0400
Message-Id: <199707181955.AA26813@interlock.ans.net>
To: bgp@ans.net
Subject: re: checking for empty AS_PATH
Date: Fri, 18 Jul 1997 15:50:37 -0400
From: Timothy O'Connor <toconnor@bbn.com>
Sender: owner-idr@merit.edu
Precedence: bulk

Yakov wrote

> we should probably make the check even stronger by checking
> whether the most recent AS in the AS_PATH is the same as the
> AS of the external peer. 

Any opinion on the case of whether a non-zero AS path is allowed
in an UPDATE containing only unreachable routes? Should the spec
say that the contents of the Path is ignored in this case, or
should it say that there must be no Path information at all?

This actually showed up as a bug between BBN routers and another
router. We were sending a length-1 AS Path containing AS "0" and
the other router rejected the Path information even though there
were no reachable NLRI in the UPDATE. We originally coded it this
way for compatibility with some older routers that always expected
a non-zero AS Path length! You can't win.

Tim O'Connor <toconnor@bbn.com>
BBN Systems & Technologies
Cambridge, Massachusetts

v2.23.0 | Report a Bug | By Email