Ben, Benjamin April wrote:
Enke, Thanks for the quick reply. Enke Chen wrote:Ben, 1) RFC 4893 has been revised by the following document: http://www.ietf.org/id/draft-ietf-idr-rfc4893bis-01.txtAs a member of the general public and not being connected to idr how am I supposed to know about this document? The first 3 pages of google results for "RFC4893" or "RFC 4893" say nothing about bis-01, also searching at IETF this link is likewise absent.
I would think that the introductory books on BGP should have pointers to IETF / ROUTING / IDR.
2) Sect. 4.2.3 presents a complete, and precise algorithm for constructing the as-path: ---------------------------------- A NEW BGP speaker should also be prepared to receive the AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an OLD BGP speaker. When both the attributes are received, if the AS number in the AGGREGATOR attribute is not AS_TRANS, then: - the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL be ignored, - the AGGREGATOR attribute SHALL be taken as the information about the aggregating node, and - the AS_PATH attribute SHALL be taken as the AS path information. Otherwise, - the AGGREGATOR attribute SHALL be ignored, - the AS4_AGGREGATOR attribute SHALL be taken as the information about the aggregating node, and - the AS path information would need to be constructed, as in all other cases.Am I mistaken or does this fail to address the case where a non-NEW speaker aggregates routes advertised to it by a new speaker? In such a case you would not have an AS4_AGGREGATOR but you would have an AS4_PATH attribute. By using the AS4_AGGREGATOR as the decision trigger the AS4_AGGREGATOR and thus AS4_PATH gets ignored.
In that case the AS4_PATH attribute would appear as an unrecognized, optional, transitive attribute to the aggregator (an OLD speaker). Certainly I am not aware of any implementation that would preserve such an attribute during aggregation. (Even if it were preserved, the AS_PATH and AS4_PATH would most likely inconsistent, and why bother with doing anything different?)
BTW, irrespective of 4byte AS, it is pretty common for the as-path info to be truncated during aggregation.
In order to construct the AS path information, it would be necessary to first calculate the number of AS numbers in the AS_PATH and AS4_PATH attributes using the method specified in Section 9.1.2.2 [RFC4271] and [RFC5065] for route selection. If the number of AS numbers in the AS_PATH attribute is less than the number of AS numbers in the AS4_PATH attribute, then the AS4_PATH attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken as the AS path information.Is there an expected causes for this case? Just dropping all of that nice AS4_PATH goodness on the floor seems to me a rather careless action. One would hope that such a structured protocol would complain about such oddities unless they originated from a known mostly-harmless source.
It is not a realistic scenario. That paragraph in the spec is mainly for the sake of completeness.
Sure, one could craft it in the lab. When AS_PATH and AS4_PATH are inconsistent, it is subject to debate whether we should favor the latest info (AS_PATH), or the oldest info (AS4_PATH). We have to specify one.
Some of the discussions occurred several years ago on IDR. You might be able to dig them up in the IDR archives.
Regards, -- Enke
If the number of AS numbers in the AS_PATH attribute is larger than or equal to the number of AS numbers in the AS4_PATH attribute, then the AS path information SHALL be constructed by taking as many AS numbers and path segments as necessary from the leading part of the AS_PATH attribute, and then prepending them to the AS4_PATH attribute so that the AS path information has an identical number of AS numbers as the AS_PATH attribute. Note that a valid AS_CONFED_SEQUENCE or AS_CONFED_SET path segment SHALL be prepended if it is either the leading path segment or adjacent to a path segment that is prepended.Sorry for the delayed reply. Busy weekend. Thanks Ben TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.