Protocol Action: 'Four-octet AS Specific BGP Extended Community' to Proposed Standard

[The IESG <[e-mail]>]

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:
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-as4octet-ext-community-03.txt

Technical Summary

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

Document Quality

   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. 

Personnel

   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:

     ABSTRACT

     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:

   OLD

      carry a four octets autonomous system number

   NEW

      carry a four octet autonomous system number

   Please replace section 5 (security considerations) with the 
   following: 

     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 
   references): 
 
     [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.