Network Working Group I. van Beijnum
Internet-Draft IMDEA Networks
Expires: August 21, 2008 February 18, 2008
A BGP Inter-AS Cost Attribute
draft-van-beijnum-idr-iac-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on August 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
Although BGP implementations have extensive path selection
algorithms, in practice operators have trouble performing
satisfactory traffic engineering of incoming traffic based on BGP
attributes that are taken into account in the path selection
algorithm alone. For this reason, many ASes deaggregate their
address range(s) into smaller blocks and announce these blocks
differently to different neighboring ASes in order to arrive at the
desired traffic flow. This practice contributes to the growth of the
global routing table, which drives up capital expenditures for
van Beijnum Expires August 21, 2008 [Page 1]
Internet-Draft Modified NAT-PT February 2008
networks engaging in inter-domain routing. This memo introduces a
new inter-domain metric that supports finer-grained traffic
engineering than current BGP attributes, most notably, the AS path.
1. Introduction
It's easy to see how comparing AS paths lengths is problematic in
today's flat AS hierarchy. Assume 10 tier-1 ISPs that can reach all
destinations connected to the internet through peering, and assume
that the local AS buys transit service from two tier-1 ISPs. The
traffic to the customers of those ISPs will normally flow through the
respective ISP. However, for all destinations reachable over the 8
other tier-1s, the AS paths will have the same length over both
transit ISPs. This means that prepending the AS path towards one ISP
has a very dramatic effect: as much as 80% of all traffic may
subsequently flow over the non-prepended ISP. With a finer-grained
value that is communicated across ASes this problem would be reduced.
2. IAC and IAClocal
The new metric is named Inter-AS Cost (IAC). The content of the IAC
is a 16-bit signed value that represents the cost or distance towards
the source of the associated prefix. The intent of this document is
that BGP implementations that support the IAC compare the IAC rather
than the AS path length as part of the path selection algorithm. As
such, it's necessary that the IAC is increased for every AS in the
path, even if the AS in question doesn't support the IAC. To
accomplish this, the IAC received over BGP is turned into IAClocal by
adding 16 * AS_path_length. The IAClocal is then used in path
selection.
In order let operators set finer-grained preferences on paths, an AS
may add to or subtract from the IAC attribute when receiving a path
over eBGP or when advertising a path over eBGP. In both cases, a
router may subtract a maximum of 7, or add a maximum of 56. As a
result, the IAC gets modified by any value between -14 and 112 by any
given AS. This means that the IAClocal in each AS is between 2 and
128 higher than in the previous AS, increasing the granularity of the
value that is compared when considering the IAC by more than a factor
120 over the situation where only the AS path length is considered.
3. Load balancing
To promote load balancing for traffic engineering purposes, the
IAClocal is pseudo-randomized over a small range of values. The size
van Beijnum Expires August 21, 2008 [Page 2]
Internet-Draft Modified NAT-PT February 2008
of the range is determined by the R variable, which is 4 by default.
The minimum is 1 (no randomization), the maximum 7. The IAClocal is
constructed from the IAC and Rt temporary value as follows:
Rt = IAC + (OriginAS bit-AND 0xffff) + (LocalAS bit-AND 0xffff)
IAClocal = 16 * ASPathLen + IAC + (Rt mod R)
Note that IAC is signed, while OriginAS and LocalAS are unsigned; Rt
must be large enough to hold 18-bit unsigned values. IAClocal must
be positive and no higher than 255 * 128 = 32640. 255 is the upper
bound on the number of AS hops imposed by the IP TTL/hop limit field,
128 the maximum increase of the IAC + AS path length per hop. So the
IAClocal can be stored in a 15-bit unsigned field or a 16-bit signed
field.
4. Backward compatibility
It would be undesirable to see a large shift in traffic flow when the
IAC capability becomes available after a software update or when it's
administratively enabled for the first time. To minimize this
problem, implementations SHOULD employ an IACscale variable, which
can be set system-wide, but overridden through neighbor-specific or
prefix-specific mechanisms such as route maps or policy filters.
Conceptually, the IACscale variable takes a value between 0 and 1,
although an approximation using integer math is acceptable. 0 means
the behavior is identical to comparing just AS path lengths, 1 means
the IAC is fully taken into account. Increasing the IACscale from 0
to 1 over time allows for the gradual introduction of the mechanism
in existing networks. However, the IAC is propagated without taking
the IACscale factor into account, so downstream networks can take
advantage of the mechanism even when an intermediate network uses an
IACscale of 0.
The steps below show how to calculate the IAC, taking all previously
defined steps as well as IACscale into account:
Rt = IAC + (OriginAS bit-AND 0xffff) + (LocalAS bit-AND 0xffff)
IAClocal = 16 * ASPathLen + (IAC + (Rt mod R)) * IACscale
Implementers are encouraged to set IACscale to 0 by default when the
IAC capability becomes available on previously configured systems but
set the IACscale to 1 by default on systems without a previous
configuration.
van Beijnum Expires August 21, 2008 [Page 3]
Internet-Draft Modified NAT-PT February 2008
5. The IAC attribute
The new IAC path attribute is an optional transitive attribute that
can take two forms: over eBGP, the attribute only contains the IAC.
When communicated through iBGP, the attribute both contains the IAC
and the IAClocal, in that order. Both attributes are 16-bit signed
values encoded as two octets in network byte order.
Generating the IAC attribute:
The attribute is only included when routes are generated if it
includes a non-zero value.
Updating of the IAC attribute:
1. When receiving a path with the IAC over eBGP: adjust IAC if
desired, compute IAClocal.
2. When transmitting a path with the IAC over iBGP: add IAClocal to
the IAC attribute.
3. When receiving a path with the IAC over iBGP: no action, unless
the system is specifically configured to compute the IAClocal
from the IAC. The IAC is NOT updated in the latter case.
4. When receiving a path without the IAC over iBGP: compute
IAClocal.
5. When transmitting a path over eBGP: adjust IAC if desired. If
there was no IAC attribute but the system is configured to adjust
the attribute, create the attribute with a value that reflects
the configured adjustment. If, after adjustment, the IAC is
zero, the IAC attribute SHOULD be removed. Include IAC attribute
with just the IAC value (not the IAClocal value) in eBGP updates.
6. IANA considerations
IANA is requested to allocate a BGP attribute type code.
7. Security considerations
When negative values outside of what's allowed by this specification
are used in the IAC, this may allow for unexpected and/or problematic
path selection.
van Beijnum Expires August 21, 2008 [Page 4]
Internet-Draft Modified NAT-PT February 2008
Appendix A. Document and discussion information
The latest version of this document will always be available at
http://www.muada.com/drafts/. Please direct questions and comments
to the idr mailinglist or directly to the author.
Author's Address
Iljitsch van Beijnum
IMDEA Networks
Avda. del Mar Mediterraneo, 22
Leganes, Madrid 28918
Spain
Email: iljitsch@muada.com
van Beijnum Expires August 21, 2008 [Page 5]
Internet-Draft Modified NAT-PT February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
van Beijnum Expires August 21, 2008 [Page 6]