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