draft-ietf-idr-bgp-issues-05.txt   draft-ietf-idr-bgp-issues-06.txt 
IDR A. Lange IDR A. Lange
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Informational August 11, 2011 Intended status: Informational March 27, 2012
Expires: February 12, 2012 Expires: September 28, 2012
Issues in Revising BGP-4 (RFC1771 to RFC4271) Issues in Revising BGP-4 (RFC1771 to RFC4271)
draft-ietf-idr-bgp-issues-05 draft-ietf-idr-bgp-issues-06
Abstract Abstract
This document records the issues discussed and the consensus reached This document records the issues discussed and the consensus reached
in the Interdomain Routing (IDR) Working Group during its efforts to in the Interdomain Routing (IDR) Working Group during its efforts to
revise and bring up to date the base specification for the BGP-4 revise and bring up to date the base specification for the BGP-4
protocol as documented in RFC1771. The document focuses on the protocol as documented in RFC1771. The document focuses on the
changes tracked from August 2002 when the last major push for changes tracked from August 2002 when the last major push for
revision began. The results of these efforts are encoded in RFC4271, revision began. The results of these efforts are encoded in RFC4271,
which should be taken as normative for any of the issues that were which should be taken as normative for any of the issues that were
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 12, 2012. This Internet-Draft will expire on September 28, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 5, line 26 skipping to change at page 5, line 26
Established State . . . . . . . . . . . . . . . . . . . . 164 Established State . . . . . . . . . . . . . . . . . . . . 164
3.51. Clearing Keepalive timer in OpenConfirm and 3.51. Clearing Keepalive timer in OpenConfirm and
Established State . . . . . . . . . . . . . . . . . . . . 164 Established State . . . . . . . . . . . . . . . . . . . . 164
3.52. Handling Event 18 in the OpenSent state (Keepalive 3.52. Handling Event 18 in the OpenSent state (Keepalive
Timer) . . . . . . . . . . . . . . . . . . . . . . . . . 165 Timer) . . . . . . . . . . . . . . . . . . . . . . . . . 165
3.53. Established State MIB . . . . . . . . . . . . . . . . . . 167 3.53. Established State MIB . . . . . . . . . . . . . . . . . . 167
3.54. State impact of not supporting Optional Events . . . . . 168 3.54. State impact of not supporting Optional Events . . . . . 168
3.55. New DelayOpen State . . . . . . . . . . . . . . . . . . . 169 3.55. New DelayOpen State . . . . . . . . . . . . . . . . . . . 169
3.56. Clarify what is covered in the base document . . . . . . 169 3.56. Clarify what is covered in the base document . . . . . . 169
4. Security Considerations . . . . . . . . . . . . . . . . . . . 170 4. Security Considerations . . . . . . . . . . . . . . . . . . . 170
5. Normative References . . . . . . . . . . . . . . . . . . . . 170 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 170
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 170 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 170
6.1. Normative References . . . . . . . . . . . . . . . . . . 170
6.2. Informative References . . . . . . . . . . . . . . . . . 170
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 171
1. Introduction 1. Introduction
This document records the issues discussed and the consensus reached This document records the issues discussed and the consensus reached
in the Interdomain Routing (IDR) Working Group during its efforts to in the Interdomain Routing (IDR) Working Group during its efforts to
revise and bring up to date the base specification for the BGP-4 revise and bring up to date the base specification for the BGP-4
protocol as documented in RFC1771. The results of these efforts are protocol as documented in RFC1771. The results of these efforts are
encoded in RFC4271. The rational for doing this is simple: encoded in RFC4271. The rational for doing this is simple:
Experience has demonstrated that the same issues and questions tend Experience has demonstrated that the same issues and questions tend
to come up again and again. This memo will document not only the to come up again and again. This memo will document not only the
skipping to change at page 14, line 46 skipping to change at page 14, line 46
Yakov agreed to this, and Jonathan seconded it. Yakov agreed to this, and Jonathan seconded it.
2.10. Extending AS_PATH Attribute 2.10. Extending AS_PATH Attribute
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Add this to 9.2: Summary: Add this to 9.2:
If due to the limits on the maximum size of an UPDATE message (see If due to the limits on the maximum size of an UPDATE message (see
Section 4) a single route doesn't fit into the message, the BGP Section 4) a single route doesn't fit into the message, the BGP
speaker MUST not advertise the route to its peers and may choose to speaker MUST NOT advertise the route to its peers and may choose to
log an error locally. log an error locally.
Discussion: Discussion:
The "Extending AS_PATH attribute length en route" thread brought up The "Extending AS_PATH attribute length en route" thread brought up
the issue of what action should we specify when we receive a route the issue of what action should we specify when we receive a route
with an AS_PATH that exceeds the defined maximum length. There was with an AS_PATH that exceeds the defined maximum length. There was
some discussion, and it was suggested that, after logging the error, some discussion, and it was suggested that, after logging the error,
the route not be propagated. the route not be propagated.
skipping to change at page 15, line 46 skipping to change at page 15, line 46
After some additional discussion, it was decided that we add "and may After some additional discussion, it was decided that we add "and may
choose to log an error locally." to the end of Yakov's text. choose to log an error locally." to the end of Yakov's text.
Also, we agreed to change "may choose not to advertise..." to "MUST Also, we agreed to change "may choose not to advertise..." to "MUST
NOT advertise...". NOT advertise...".
So the text on the table right now is: So the text on the table right now is:
If due to the limits on the maximum size of an UPDATE message (see If due to the limits on the maximum size of an UPDATE message (see
Section 4) a single route doesn't fit into the message, the BGP Section 4) a single route doesn't fit into the message, the BGP
speaker MUST not advertise the route to its peers and may choose to speaker MUST NOT advertise the route to its peers and may choose to
log an error locally. log an error locally.
This met with one agreement and no disagreements. We have a This met with one agreement and no disagreements. We have a
consensus. consensus.
2.11. Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1 2.11. Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1
Status: Consensus Status: Consensus
Change: Yes Change: Yes
Summary: Add this text: Summary: Add this text:
skipping to change at page 170, line 22 skipping to change at page 170, line 22
This was discussed in the "Next-Hop in IPv6 only environments" This was discussed in the "Next-Hop in IPv6 only environments"
thread. thread.
4. Security Considerations 4. Security Considerations
This document is an informational document that discusses the changes This document is an informational document that discusses the changes
made in revising the BGP-4 specification. There are no security made in revising the BGP-4 specification. There are no security
considerations applicable to this document. considerations applicable to this document.
5. Normative References 5. IANA Considerations
This document has no considerations for IANA.
6. References
6.1. Normative References
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995. (BGP-4)", RFC 1771, March 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
6.2. Informative References
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2842] Chandra, R. and J. Scudder, "Capabilities Advertisement
with BGP-4", RFC 2842, May 2000.
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
September 2000.
[RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 3065, February 2001.
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement
with BGP-4", RFC 3392, November 2002.
[RFC4065] Kempf, J., "Instructions for Seamoby and Experimental
Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
Author's Address Author's Address
Andrew S. Lange Andrew S. Lange
Alcatel-Lucent Alcatel-Lucent
Email: andrew.lange@alcatel-lucent.com Email: andrew.lange@alcatel-lucent.com
 End of changes. 9 change blocks. 
10 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/