Re: Order of ASes in the BGP Path
Date: Mon, 29 Aug 2005 22:15:26 +0530 From: Abhishek Verma <abhishekv.verma@gmail.com> Subject: Order of ASes in the BGP Path
Hi,
Is the order of AS numbers (except for perhaps the first one which denotes the AS the route was originated from) in the AS_PATH in BGP important? In fact, does anybody even care for the first AS number that appears in the Path?
AFAIK, AS numbers in the BGP serves two purposes. It helps in loop detection and it helps us count the AS Path length.
AS_PATH is used for various administrative 'policy' matters, as well. It is not used in the actual routing of data. that functionality is accomplished using only the destination netblock and 'next hop' info.
If this is the case then the order should not really matter much.
Except for standards compliance. <evil grin> 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. And you must use the ordered path tagging for any new stuff you generate.
My question is that whether the operators care if the order, for some reason changes?
Eg.
Legend: {} denotes the sequence, while [] denotes the set
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.
Would somebody mind if this was represented as {1 2 5} [3 4] ?
Did the topology change? Or did "somebody" just decide to re-write the AS_PATH elements ? your first illustration would 'apparently' describe a topology on the order of; +-3-+ / | \ 1--2 | 5 \ | / +-4-+ where the latter describes something on the order of: 3 /| 1--2--5-+ | \| 4 Anybody that is 'mapping' interconnections is going to be "unhappy" if the 'representation', and the 'reality' are not consistent. :)
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
Legend: {} denotes the sequence, while [] denotes the set
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.
Yes, I understand that right now it is not possible to receieve or generate such a Path, but i dont recollect the BGP draft precluding this. Correct me if i am mistaken here. Toms.
participants (3)
-
Paul Jakma -
Robert Bonomi -
Tom Sanders