Asia Pacific Network Information Centre

gih@apnic.net http://www.apnic.net

Individual Submission Individual Submission This document provides a survey of BGP-4 4-Byte AS Number support implementations.

This document provides a survey of BGP-4 4-Byte AS Number Support implementations. After a brief summary, each response is listed. The editor, makes no claim as to the accuracy of the information provided.

Organization: Juniper Networks Person filling out this form: Bruno Rijsman <brijsman@juniper.net> Implementation: JUNOSe 4-1-0 and later Does the implementation include all parts of the specification: Yes Are there parts of the specification that are unclear where the implementor had to exercise some judgement that may impact interoperability? It isn't clear what to do if the information in the old as-path is inconsistent with the information in the new as-path. There some places where AS numbers are used where it wasn't clear how to deal with 4-octet as-numbers (e.g. extended communities). It isn't spelled out that this capability cannot be dynamically negotiated. Has there been any interoperability testing? Yes; no problems were discovered. NEW / OLD ineroperability testing with: Juniper ERX (older version which does not support draft) Juniper M/T/J Cisco 7500 NEW / NEW interoperability testing with: Juniper M/T/J Redback SmartEdge Most deployed Juniper ERX routers run code which supports 4-octet AS-numbers (and the feature is enabled by default). This provides some confidence that the draft does not cause interoperability problems. Note however that the NEW_AS_PATH attribute is not generated unless the AS-path contains at least one AS-number greater than 65535 which is -as far as we know- not yet the case in the Internet today. Has there been testing of the interface between this implementation and the 2-byte BGP implementation on the NEW (4-byte) to OLD (2byte) update path? Yes Has there been testing of the OLD (2-byte) to NEW (4-byte) path? Yes Have there been any issues noted with the mechanism to reconstruct the 4-byte AS path from the NEW_AS-PATH attribute and the 2-byte AS Path on an OLD -NEW BGP update session? It isn't clear what to do if the information in the old as-path is inconsistent with the information in the new as-path. Any other comments regarding the implementation Some older versions of Cisco IOS send an unsupported capability notification (instead of ignoring the capability) when they receive a capability advertisement which they don't recognize and which has non-empty data. The 4-octet as-number capability is such a capability. Our implementation recognizes this notification and stops automatically stops advertising the 4-octet as-numbers capability (and others) until the next hard clear on the BGP session.

Organization: Redback Person filling out this form: Albert Tian <tian@redback.com> Does the implementation include all parts of the specification: Yes Are there parts of the specification that are unclear where the implementor had to exercise some judgement that may impact interoperability? No. Has there been any interoperability testing? Yes Has there been testing of the interface between this implementation and the 2-byte BGP implementation on the NEW (4-byte) to OLD (2byte) update path? Yes (Cisco: 2-byte; Redback: 4 byte). Has there been testing of the OLD (2-byte) to NEW (4-byte) path? Yes. (Cisco: 2-byte; Redback: 4-byte). Have there been any issues noted with the mechanism to reconstruct the 4-byte AS path from the NEW_AS-PATH attribute and the 2-byte AS Path on an OLD -NEW BGP update session? No Have there been any issues noted with the mechanism to reconstruct the 4-byte AS path from the NEW_AS-PATH attribute and the 2-byte AS Path on an OLD -> NEW BGP update session? No. Any other comments regarding the implementation No

No IANA considerations are noted in this document

Security considerations are documented in .

Juniper Networks Cisco Systems