Network Working Group Internet Draft S.Hares Document:draft-hares-bgp-assign-afisafi-00.txt NextHop Technologies, Inc. Expires: August 2004 February 2004 BGP Assign AFI/SAFI numbers Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes mechanisms for assigning the AFI/SAFI values for short-term use while BGP specifications are under development. These short-term AFI/SAFI values will be assigned for temporary use to a particular enterprise while BGP specifications are under development. After 1 year, if the BGP specification has been adopted as an IDR draft, the lease will be renewed. If the draft has not be adopted, the AFI/SAFI value returns to the pool of Enterprise AFI/SAFI. This draft a means to assign these short- term AFI/SAFI values. Hares Expires - August 2004 [Page 1] BGP Assign AFI/SAFI numbers February 2004 Table of Contents 1. Overview.......................................................2 2. Assignment Mechanism...........................................3 3. Protocol mechanisms............................................3 3.1 Support of temporary AFI/SAFI in OPEN......................3 3.2 Support of temporary AFI/SAFI in Dynamic Capabilities......3 Security Considerations...........................................3 References........................................................3 Acknowledgments...................................................4 Author's Addresses................................................4 1. Overview There is a problem with the allocation policy that is specified in the current BGP spec. Yakov Rekhter noted in email that: "From the IANA Considerations section of the current BGP spec: All new BGP message types, Path Attributes Type codes, Message Header Error subcodes, OPEN Message Error subcodes, and UPDATE Message Error subcodes MUST only be made using the Standards action process defined in [RFC2434]. From rfc2434: Standards Action - Values are assigned only for Standards Track RFCs approved by the IESG. The problem with the Standards Action policy is that it makes impossible to assign a value when a document is just an Internet Draft. Yet in the routing area to advance an Internet Draft to even a Proposed Standard requires more than one (interoperable) implementation as a prerequisite for the advancement. Which means that it is necessary to assign a value when the document is still an Internet Draft, prior to the approval by the IESG. So, the bottom line is that the Standards Action policy, as *currently specified in rfc2434, is unsuitable (and not just for IDR, but for any WG in the Routing Area)." This draft provides a operational mechanism to assign a short-term allocation pool of AFI/SAFIs that may be used by an Enterprise or a group of Enterprise while an Internet Draft is under consideration. Hares Expires - August 2004 [Page 2] BGP Assign AFI/SAFI numbers February 2004 2. Assignment Mechanism An enterprise may request an AFI/SAFI out of the temporary AFI/SAFI space. IANA will define a pool of 128AFIs each with 8 bits of SAFIs from the top of the assignment pool with a mask of 0XFFFF FE00. After the 1 year timeframe, if the IETF draft is accpted as an IDR working group document the AFI/SAFI will be re-leased to that BGP application until If not, the AFI/SAFI will be returned to the pool. The IANA will publish the AFI/SAFI as temporary space with the warning that these AFI/SAFIs will be re-assigned. 3. Protocol mechanisms 3.1 Support of temporary AFI/SAFI in OPEN If an implementation utilizes an AFI/SAFI with the mask 0XFFFF FE00, the OPEN may be responded to with an Error code that indicates: XXXX value Support of AFI/SAFI pair in temporary AFI/SAFI Number assignment not supported. 3.2 Support of temporary AFI/SAFI in Dynamic Capabilities If an implementation utilizes an AFI/SAFI with the mask 0XFFFF FE00, BGP dynamic capability negotiation [DYN] may send back a CAPABILITY Message error (error code 7), with a sub-code of: 4 Temporary AFI/SAFI will not accept 5 Temporary AFI/SAFI utilize official AFI/SAFI (where AFI/SAFI that the bgp speaker thinks is valuable is specified.) Security Considerations Security concerns for BGP-4 are addressed in the BGP-4 specification, and accompanying specifications on TCP MD5 [1] and IP Security[2]. No additional considerations need to be made for the BGP-4 state machine description. References 1 "Protection of BGP Sessions via the TCP MD5 Signature Option" A. Heffernan, rfc2385.txt Hares Expires - August 2004 [Page 3] BGP Assign AFI/SAFI numbers February 2004 2 BGP-4 "Border Gateway Protocol Version 4", draft-ietf-idr-bgp4- 23.txt 3 RFC2434 Acknowledgments Yakov Rekhter for his clear statement of the problem in an IDR message as of 2/4/04. Discussions with Andrew Lange and Gargi Nalawade at NANOG 30. Author's Addresses Susan Hares NextHop Technologies, Incorporated 825 Victors Way, Suite 100 Ann Arbor, MI 48108-2738 Phone: 734.222.1600 Email: skh@nexthop.com Hares Expires - August 2004 [Page 4]