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