From: The IESG <firstname.lastname@example.org>
To: IETF-Announce <email@example.com>
Cc: Internet Architecture Board <firstname.lastname@example.org>,
RFC Editor <email@example.com>,
l3vpn mailing list <firstname.lastname@example.org>,
l3vpn chair <email@example.com>
Subject: Protocol Action: 'Four-octet AS Specific BGP Extended Community' to Proposed Standard
The IESG has approved the following document:
- 'Four-octet AS Specific BGP Extended Community '
<draft-ietf-l3vpn-as4octet-ext-community-03.txt> as a Proposed Standard
This document is the product of the Layer 3 Virtual Private Networks Working Group.
The IESG contact persons are Ross Callon and Adrian Farrel.
A URL of this Internet-Draft is:
This document defines a new type of a BGP extended community - four-
octet AS specific extended community. This allows the BGP extended
community to carry a 4 octet autonomous system numbers.
Working Group Summary
No controvery reported (see PROTO writeup by Danny McPherson in
the I.D. Tracker). This was last called in both the L3VPN and IDR
The existing capability using 2 octet AS numbers is implemented
and widely deployed. This is a very straightforward extension to
support 4 octet AS numbers.
Danny McPherson is the Document Shepherd for this document. Ross
Callon is the Responsible Area Director.
RFC Editor Note
Please change the abstract to be:
This document defines a new type of a BGP extended community which
carries a four-octet autonomous system (AS) number.
Please update the last sentence of the Introduction as follows:
carry a four octets autonomous system number
carry a four octet autonomous system number
Please replace section 5 (security considerations) with the
5. Security Considerations
This document does not add new security issues. All the security
considerations for BGP Extended Communities apply here. At the time
that this document was written there were significant efforts
underway to improve the security properties of BGP. For examples of
documents that have been produced up to this time of publication,
see [RFC4593] and [SIDR].
There is a potential serious issue if a malformed malformed
optional transitive attribute is received. This issue
and the steps to avoid it are discussed in [OPT_TRANS].
And add the following references to section 7 (non-normative
[OPT_TRANS] Scudder, Chen, "Error Handling for Optional
Transitive BGP Attributes", work in progress,
draft-ietf-idr-optional-transitive, April 2009.
[RFC4593] Barbir, Murphy, Yang, "Generic Threats to Routing
Protocols", RFC4593, October 2006.
[SIDR] Lepinski, Kent, "An Infrastructure to Support Secure
Internet Routing", work in progress,
draft-ietf-sidr-arch-08.txt, July, 2009.