Protocol Action: 'BGP Support for Four-octet AS Number Space' to Proposed Standard
The IESG <iesg-secretary <at> ietf.org>
2007-03-09 21:34:36 GMT
The IESG has approved the following document:
- 'BGP Support for Four-octet AS Number Space '
<draft-ietf-idr-as4bytes-13.txt> as a Proposed Standard
This document is the product of the Inter-Domain Routing Working Group.
The IESG contact persons are Bill Fenner and Ross Callon.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-13.txt
Technical Summary
Currently the Autonomous System number is encoded as a two-octet
entity in BGP. This document describes extensions to BGP to carry the
Autonomous System number as a four-octet entity.
Based on historical and current allocation rates, the range available
to two-octet AS numbers is expected to run out in 2010.
Working Group Summary
This is a long-standing work item for the working group, with the
first draft being published in February 2001.
The approach described in the draft to support 4 Byte AS numbers
is one of no change to BGP in terms of protocol in all but one
aspect: The OPEN message uses a 4-Byte capability advertisement
and the use of a 2 Byte MyAS field value. In all other respects
there is no change to the protocol elements of BGP, other than
using 4 bytes where ASs are used.
The other substantive topic of the draft is in the interoperation
of 4-Byte AS speakers with 2-Byte AS speakers.
The OPEN message with capability advertisement has attracted one
comment that this is contrary to RFC3392, however a detailed
analysis of this comment has not lead to substantiation of this
comment. Using this as a dynamic capability rather than an OPEN
capability was raised as a comment, with the response that there
is no reason to make the capability dynamic in this case.
The tunnelling technique of using an opaque transitive community
attribute to carry the 4-Byte AS Path attracted some comment. The
comment was concerned with the reconstruction of the 4-Byte AS
path across a 2-to-4 byte BGP boundary, where the algorithm for
the reconstruction was, in some comments, not sufficiently
well-defined.
However it is also the case that the critical elements of the role
of the AS Path are adequately described in the draft. The AS path
length is used as a metric in the BGP path selection process, and
the AS path itself is used for loop prevention. The draft
specifies that the reconstruction of the AS path across a 2-byte
to 4-byte AS transition should preserve the AS path length. The
draft does not cover every possible eventuality of reconstruction
of the 4-byte AS path, but a closer examination of the loop
detection issue reveals that loops that may occur across a mixed 2
Byte / 4 Byte path are detectable within one iteration of the loop
within the 2-Byte component of the mixed loop path in all
circumstances. Accordingly, both the use of the AS path length as
a path metric and the use of the AS path as a loop detection
mechanism are preserved in this approach, even though the draft is
not definitive in describing the AS path reassembly algorithm in
every possible eventuality. In other words the draft contains the
necessary and sufficient minimum set of properties for AS path
reconstruction, leaving the precise algorithm up to the
implementation. This approach is not seen as impairing the
functionality, interoperability or integrity of BGP, either within
the context of the individual peering session or in the context of
the broader IDR framework.
A comment was raised that on-the-wire inspection of BGP updates
would not know in all cases whether they were seeing 2-byte or
4-byte AS BGP updates. The BGP update contains no additional
control flags, and unless the on-the-wire device collects the
initial OPEN message with the capability negotiation then the
information as to 2-byte or 4-byte AS updates is not explicit. It
has been noted that heuristics could be readily applied here, and
the presence of the reserved 2-byte AS value 0 in the AS path is
one indicator that the momitor is applying a 2-byte interpretation
to a 4-byte BGP update.
There were no other approaches referenced in the working group
during Last Call, and the choice of this draft as representing one
that is backwards compatible with existing BGP appears to have
been an obvious obvious choice to the working group.
The IETF Last call comments concernd the RFC3392 Capability
Advertisement examination of these comments indicates that the
concerns relating to RFC3392 are unwarranted, and the treatment of
the capability advertisement is consistent with a conventional use
of RFC3392 and is compatible with older versions of BGP.
The IETF Last Call comments touched upon the larger size of BGP
updates, and the desireability of using a compressed
representation of AS Path. The Working Group did not see any need
to include a compressed representation of AS paths in BGP
updates. It appears that the onus of making a case that some form
of compressed encoding of these BGP fields is of merit lies with
the proponents of this as a potential source of problem, and the
solution with respect to the AS_PATH representation lies in
RFC3392 with additional capabilities being negotiated, either at
session OPEN time or possibly dynamically. Thus, this 4-byte
spec, that does not used compressed representation of AS_PATH is
adequate, and those who believe that more compact representations
are called for have a clear path of proposing such a specification
to the IDR working group as a negotiated capability. The task for
those who are of the opinion that such compact encodings are
important to show why and propose a capability to be negotiated to
do so in both the 4Byte and 2Byte worlds in the IDR Working
Group.
Protocol Quality
Bill Fenner and Geoff Huston reviewed the document for the IESG.
There are implementations; see the implementation report at
http://www.ietf.org/IESG/Implementations/bgp4_impleme.txt
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www1.ietf.org/mailman/listinfo/idr
, as ...InPrefixes = ...InPrefixesAccepted + ...InPrefixesRejected.
(I asked a MIB doctor who happened to be sitting next to me, and he
said it would be better to avoid this kind of redundancy in a MIB.)
> Please send what in BGP MIB v2 is useful to you.
Definitely useful:
Everything that's under bgpM2PrefixCountersTable (except one of the
three objects mentioned above, to remove the redundancy).
I especially like the fact that this table (and all others) allow
peerings over IPv6 to be monitoring. We cannot currently do this in
our network, and that is a pain.
> The BGP MIB v2 has been in limbo for 5 years due to lack of feedback.
> We would like to encourage feedback from operators who actually use
> these variables.
We cannot use them since they don't exist, but we would use them
almost instantly if we had software that supported them, even in
vendor-specific variants.
> Please send what variables you use to the list.
RSS Feed