[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Idr] Question about RFC4893

Ben,

1) RFC 4893 has been revised by the following document:

    http://www.ietf.org/id/draft-ietf-idr-rfc4893bis-01.txt
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.

  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.

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

Please let us know which part of the algorithm that you think is not clear.

Regards,   -- Enke

Benjamin April wrote:

Greetings,

I find myself in the process of updating one of our BGP
data-collectors to support 4-octet ASNs. I did my best to follow
RFC-4893, however I have a nagging feeling that I don't understand
one element. I hope you folks can point me in the right direction here.

The language in question is in section 4.2.3. The passages of
particular concern to me are:

Under certain conditions, it may not be possible to reconstruct the
entire AS path information from the AS_PATH and the AS4_PATH
attributes of a route.  This occurs when two or more routes that
carry the AS4_PATH attribute are aggregated by an OLD BGP speaker,
and the AS4_PATH attribute of at least one of these routes carries
at least one 4-octet AS number (as oppose to a 2-octet AS number
that is encoded in 4 octets).  Depending on the implementation,
either the AS4_PATH attribute would be lost during route
aggregation, or both the AS_PATH attribute and the AS4_PATH
attribute would contain valid, partial information that cannot be
combined seamlessly, resulting in incomplete AS path information in
these cases.

and

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
[BGP] and [RFC3065] 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.


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.



Forgive me, but this all sounds like an awful lot of hand-waving to
me. Has anything been done since this RFC was published to better
describe in a more formal way the procedure a BGP speaker should
follow to re-construct an accurate AS_PATH from the AS4_PATH and
AS_PATH attributes? Based on this description I can see more than
one way to implement this. I would like to do so correctly, but I
need to know what is correct first.

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.
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr