[83862] in North American Network Operators' Group
Re: Order of ASes in the BGP Path
daemon@ATHENA.MIT.EDU (Paul Jakma)
Mon Aug 29 14:44:08 2005
Date: Mon, 29 Aug 2005 19:43:04 +0100 (IST)
From: Paul Jakma <paul@clubi.ie>
To: Robert Bonomi <bonomi@mail.r-bonomi.com>
Cc: nanog@nanog.org
In-Reply-To: <200508291747.j7THlIVf001838@host122.r-bonomi.com>
Mail-Copies-To: paul@hibernia.jakma.org
Mail-Followup-To: paul@hibernia.jakma.org
Errors-To: owner-nanog@merit.edu
On Mon, 29 Aug 2005, Robert Bonomi wrote:
> Per the RFCs on the subject, if you _receive_ an unordered set from
> a downstream, you can propogate that unordered set, but you must
> prepend your AS in the 'ordered' fashion.
Right.
> And you must use the ordered path tagging for any new stuff you generate.
Where do you get this idea from? See, for example, route-aggregation,
for one ;).
>> Path {1 2} [3 4] {5}
> As I understand the specs, that is -not- allowed. an unordered set
> can appear only as the _last_ element of the AS path list.
Curious, but how do you read that from the draft?
While a collection of BGP speakers implementing BGP-4 (eg 1771 or the
latest IDR draft) will /not/ cause such a path to be generated, that
does /not/ mean such a path is not allowed. The following should all
be valid:
{1 2} [3 4] {5}
{1 2} [3 4] {5} [7 8 9] {10}
etc. Though, such paths would not be seen with todays BGP speakers.
> your first illustration would 'apparently' describe a topology on
> the order of;
>
> +-3-+
> / | \
> 1--2 | 5
> \ | /
> +-4-+
The connection between 3 and 4 isn't known. ;)
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Take what you can use and let the rest go by.
-- Ken Kesey
