Re: [Idr] Question about RFC4893

[Benjamin April <ben_april at trendmicro.com>]

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

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

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

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