Order of ASes in the BGP Path

Mailman List Mirror (Read Only)
1

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. :slight_smile:

2

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. :wink:

regards,

3

>
> 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.