Order of ASes in the BGP Path
Paul Jakma
paul at clubi.ie
Mon Aug 29 18:43:04 UTC 2005
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 at clubi.ie paul at jakma.org Key ID: 64A2FF6A
Fortune:
Take what you can use and let the rest go by.
-- Ken Kesey
More information about the NANOG
mailing list