idnits 2.17.1 draft-ietf-idr-bgp-route-refresh-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 62, but not defined == Unused Reference: 'BGP-MP' is defined on line 128, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. 'BGP-4') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-MP' -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-CAP' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Enke Chen 2 Internet Draft Siara Systems 3 Expiration Date: May 2000 5 Route Refresh Capability for BGP-4 7 draft-ietf-idr-bgp-route-refresh-00.txt 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 except that the right to 13 produce derivative works is not granted. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2. Abstract 33 This document defines a new BGP capability termed 'Route Refresh 34 Capability', which would allow the dynamic exchange of route refresh 35 request between BGP speakers and subsequent re-advertisement of the 36 respective Adj-RIB-Out. One possible application of this capability 37 is to facilitate non-disruptive routing policy changes. 39 3. Introduction 41 Currently there does not exist a mechanism in BGP-4 [BGP-4] to 42 dynamically request a re-advertisement of the Adj-RIB-Out from a BGP 43 peer. When the inbound routing policy for a peer changes, all 44 prefixes from that peer must be somehow made available and then re- 45 examined against the new policy. To accomplish this, a commonly used 46 approach, known as 'soft-reconfiguration', is to store an unmodified 47 copy of all routes from that peer at all times, even though routing 48 policies do not change frequently (typically no more than a couple 49 times a day). Additional memory and CPU are required to maintain 50 these routes. 52 This document proposes an alternative solution that avoids the 53 additional maintenance cost. More specifically, it defines a new BGP 54 capability termed 'Route Refresh Capability', which would allow the 55 dynamic exchange of route refresh request between BGP speakers and 56 subsequent re-advertisement of the respective Adj-RIB-Out. 58 4. Route Refresh Capability 60 To advertise the Route Refresh Capability to a peer, a BGP speaker 61 uses BGP Capabilities Negotiation [BGP-CAP]. This capability is 62 advertised using the Capability code [TBD] and Capability length 0. 64 By advertising the Route Refresh Capability to a peer, a BGP speaker 65 conveys to the peer that the speaker is capable of receiving and 66 properly handling the ROUTE-REFRESH message (as defined in Section 5) 67 from the peer. 69 5. Route-REFRESH Message 71 The ROUTE-REFRESH message is a new BGP message type defined as 72 follows: 74 Type: TBD - ROUTE-REFRESH 76 Message Format: One encoded as 78 0 7 15 23 31 79 +-------+-------+-------+-------+ 80 | AFI | Res. | SAFI | 81 +-------+-------+-------+-------+ 83 The meaning, use and encoding of this field is the 84 same as defined in [BGP-MP, sect. 8]. More specifically, 85 AFI - Address Family Identifier (16 bit). 87 Res. - Reserved (8 bit) field. Should be set to 0 by the 88 sender and ignored by the receiver. 90 SAFI - Subsequent Address Family Identifier (8 bit). 92 6. Operation 94 A BGP speaker that is willing to receive the ROUTE-REFRESH message 95 from its peer should advertise the Route Refresh Capability to the 96 peer using BGP Capabilities negotiation [BGP-CAP]. 98 A BGP speaker may send a ROUTE-REFRESH message to its peer only if it 99 has received the Route Refresh Capability from its peer. The carried in such a message should be one of the that 101 the peer has advertised to the speaker at the session establishment 102 time via capability negotiation. 104 If a BGP speaker receives from its peer a ROUTE-REFRESH message with 105 the that the speaker didn't advertise to the peer at the 106 session establishment time via capability negotiation, the speaker 107 shall ignore such a message. Otherwise, the BGP speaker shall re- 108 advertise to that peer the Adj-RIB-Out of the carried in 109 the message, based on its outbound route filtering policy. 111 7. Security Considerations 113 This extension to BGP does not change the underlying security issues. 115 8. Acknowledgments 117 The concept of Route Refresh proposed is similar to the one used in 118 IDRP. 120 The author would like to thank Yakov Rekhter, Ravi Chandra, Srihari 121 Ramachandra and Bruce Cole for their review and comments. 123 9. References 125 [BGP-4] Rekhter, Y., and T. Li, 'A Border Gateway Protocol 4 (BGP- 126 4)', RFC 1771, March 1995. 128 [BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y., 129 'Multiprotocol Extensions for BGP-4', work in progress 131 [BGP-CAP] Chandra, R., Scudder, J., 'Capabilities Negotiation with 132 BGP-4', work in progress 134 10. Author Information 136 Enke Chen 137 Siara Systems Incorporated 138 300 Ferguson Drive 139 Mountain View, CA 94043 140 e-mail: enkechen@siara.com