Re: Order of ASes in the BGP Path
On Tue, 30 Aug 2005, Abhishek Verma wrote: Since i smell some traces of sarcasm here. On 8/30/05, Randy Bush [EMAIL PROTECTED] wrote: I thank everyone who took time off their busy schedules and answered me on this. I now understand that people do look at the AS_PATH and the order of ASes is important for debugging, etc. and thank you for reading the rfc Randy, I respect your knowledge and wisdom and that of other people on this list here which is why i asked this question. Yes, i have gone through the RFC 1771 throughly and trust me it does not mention any other use of this Path attribute, except for the path length/loop detection. People on this list have a *lot* of experience and its these people who actually use this protocol. To me these were the best people to tell me if they indeed use it for other purposes also. from time to time people say 'but the rfc says...'. but theres a big place for precedent and common practice too. Steve
Re: Order of ASes in the BGP Path
As no one has asked yet, allow me.. what are you trying to do?
Basically I was thinking on these lines.
If i have an AS path {1 2} [3 4] { 5 } then is it possibleto pull the AS in the last segment and merge it with the first segment? This would give me {1 2 5} [3 4]. This way i dont need to carry two AS_SEQ segments in my path and i can manage with just one.
However,there are some problems here:
[1] I can never generate such an AS Path, given the way BGP works currently.
[2] Merging ASes from different segments can mangle the sequence in which the ASes appear in the AS Path. I wanted to know if this was required and used by admins, and hence my original mail.
Thanks everybody for all the help,
Abhishek
Re: Order of ASes in the BGP Path
### On Tue, 30 Aug 2005 11:02:18 +0100 (BST), Stephen J. Wilcox ### [EMAIL PROTECTED] casually decided to expound upon Abhishek ### Verma [EMAIL PROTECTED] the following thoughts about Re: ### Order of ASes in the BGP Path: SJW from time to time people say 'but the rfc says...'. but theres a big SJW place for precedent and common practice too. True... but the latest BGP draft series attempts to address BCP and updates on 1771. Typically, the answers sought in light of current BGP practices can be found in the draft. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
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.
If this is the case then the order should not really matter much.
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}
Would somebody mind if this was represented as {1 2 5} [3 4] ?
Thanks,
Abhishek
Re: Order of ASes in the BGP Path
On Mon, Aug 29, 2005 at 10:15:26PM +0530, Abhishek Verma wrote: 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. If this is the case then the order should not really matter much. My question is that whether the operators care if the order, for some reason changes? Just that pesky little thing called sanity, aka having a hope in hell of being able to figure out which network is connected to which and in what order. While it is technially possible to run everything with an unordered AS-PATH set, it is so rare that most people looking at AS-PATHs either don't know it is possible, or don't take its possibility into account properly. Besides being likely to confuse the hell out of a lot of people, you're even more likely to break someone's BGP querying perl scripts. I wouldn't underestimate the amount of that stuff out there either, especially in areas like abuse tracking/reporting. Basically you'd be making a general pain in the ass out of yourself, so hopefully you have a damn good reason for it. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Order of ASes in the BGP Path
Date: Mon, 29 Aug 2005 22:15:26 +0530
From: Abhishek Verma [EMAIL PROTECTED]
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. :)
Re: Order of ASes in the BGP Path
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 [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A
Fortune:
Take what you can use and let the rest go by.
-- Ken Kesey
Re: Order of ASes in the BGP Path
On Mon, 29 Aug 2005, Abhishek Verma wrote:
Legend: {} denotes the sequence, while [] denotes the set
Path {1 2} [3 4] {5}
Would somebody mind if this was represented as {1 2 5} [3 4] ?
Yes, they are different paths. You are allowed to merge adjacent
sequences, eg:
{1 2} {5} [3 4]
the two sequences can be merged, to give:
{1 2 5} [3 4]
You can *not* merge AS_SET's, as the current BGP specs imply an
AS_SET has a fixed path-length, hence you should NOT merge the sets
in:
{1 2} [3 4] [5 6]
into:
{1 2} [3 4 5 6]
as the former path has a length of 3, the latter a length of just 2 -
merging sets could change their meaning. Note though that you're not
at all likely to see such paths with BGP speakers implementing the
RFC / draft-ietf-idr-bgp-26.txt draft.
regards,
--
Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A
Fortune:
The best way to make a fire with two sticks is to make sure one of them
is a match.
-- Will Rogers
Re: Order of ASes in the BGP Path
seems to me that, if your questions are not clearly answered by the bgp specs, then something is sorely broken. randy
Re: Order of ASes in the BGP Path
In message [EMAIL PROTECTED], Abhishek Verma writes:
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.
If this is the case then the order should not really matter much.
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}
Would somebody mind if this was represented as {1 2 5} [3 4] ?
Any of the proposed BGP security schemes would have trouble with
reordering.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: Order of ASes in the BGP Path
On Mon, 29 Aug 2005, Abhishek Verma wrote:
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.
If this is the case then the order should not really matter much.
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}
Would somebody mind if this was represented as {1 2 5} [3 4] ?
I'd mind, I value the predictability and ability to understand how a bgp path
arrives into my network. Fiddling with this kind of thing is quite similar to
spoofing in some ways, particularly that I can see fabricating the as-path
could be used to confuse folks tracing announcements, perhaps I'm missing the
positive use for this.
As no one has asked yet, allow me.. what are you trying to do?
Steve
Re: Order of ASes in the BGP Path
I thank everyone who took time off their busy schedules and answered me on this. I now understand that people do look at the AS_PATH and the order of ASes is important for debugging, etc. Regards, Abhishek On 8/29/05, Richard A Steenbergen [EMAIL PROTECTED] wrote: On Mon, Aug 29, 2005 at 10:15:26PM +0530, Abhishek Verma wrote: 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. If this is the case then the order should not really matter much. My question is that whether the operators care if the order, for some reason changes?Just that pesky little thing called sanity, aka having a hope in hell ofbeing able to figure out which network is connected to which and in whatorder. While it is technially possible to run everything with an unordered AS-PATH set, it is so rare that most people looking at AS-PATHs eitherdon't know it is possible, or don't take its possibility into accountproperly.Besides being likely to confuse the hell out of a lot of people, you're even more likely to break someone's BGP querying perl scripts. I wouldn'tunderestimate the amount of that stuff out there either, especially inareas like abuse tracking/reporting. Basically you'd be making a general pain in the ass out of yourself, so hopefully you have a damn good reasonfor it. :)--Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/rasGPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)-- --Computer Science Deptt.Institute of Technology, BHU Varanasi - India
Re: Order of ASes in the BGP Path
I thank everyone who took time off their busy schedules and answered me on this. I now understand that people do look at the AS_PATH and the order of ASes is important for debugging, etc. and thank you for reading the rfc randy
Re: Order of ASes in the BGP Path
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.
Re: Order of ASes in the BGP Path
On Mon, 29 Aug 2005, Abhishek Verma wrote:
Legend: {} denotes the sequence, while [] denotes the set
Path {1 2} [3 4] {5}
Would somebody mind if this was represented as {1 2 5} [3 4] ?
I see it as a bad idea for bgp table / routing analysis as it
completely confuses who is #5 really peering with.
But at this time, I'd like to see you actually provide justification
as it applies to your case for why you would want to change bgp route
for routes coming from #5 in the first place?
--
William Leibzon
Elan Networks
[EMAIL PROTECTED]
Re: Order of ASes in the BGP Path
You can *not* merge AS_SET's, as the current BGP specs imply an
AS_SET has a fixed path-length, hence you should NOT merge the sets
in:
{1 2} [3 4] [5 6]
into:
{1 2} [3 4 5 6]
as the former path has a length of 3, the latter a length of just 2 -
merging sets could change their meaning. Note though that you're not
at all likely to see such paths with BGP speakers implementing the
RFC / draft-ietf-idr-bgp-26.txt draft.
This is one thing that i have always been aware of but dont see it
mentioned in the BGP draft which can be quite confusing to the
newbies. Is it possible to explicitly mention this in
draft-ietf-idr-bgp-26.txt?
Toms.
Re: Order of ASes in the BGP Path
Since i smell some traces of sarcasm here. On 8/30/05, Randy Bush [EMAIL PROTECTED] wrote: I thank everyone who took time off their busy schedules and answered me on this. I now understand that people do look at the AS_PATH and the order of ASes is important for debugging, etc.and thank you for reading the rfc Randy, I respect your knowledge and wisdom and that of other people on this list here which is why i asked this question. Yes, i have gone through the RFC 1771 throughly and trust me it does not mention any other use of this Path attribute, except for the path length/loop detection. People on this list have a *lot* of experience and its these people who actually use this protocol. To me these were the best people to tell me if they indeed use it for other purposes also. Thanks, Abhishek randy-- --Computer Science Deptt.Institute of Technology, BHU Varanasi - India
Re: Order of ASes in the BGP Path
On Tue, 30 Aug 2005, Tom Sanders wrote: This is one thing that i have always been aware of but dont see it mentioned in the BGP draft which can be quite confusing to the newbies. Is it possible to explicitly mention this in draft-ietf-idr-bgp-26.txt? Impossible given draft-ietf-idr-bgp4-26 is in the RFC Editor Queue. However, the IDR have a working document to update the definition of AS_PATH, draft-ietf-idr-as4bytes-10, so might feasible to have clarifying text put in. Ask on IDR. regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: Fanaticism consists of redoubling your effort when you have forgotten your aim. -- George Santayana
