One document matched: draft-hares-bgp-assign-afisafi-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 02:53:13 |