idnits 2.17.1 draft-mauch-bgp-accepted-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 18, 2019) is 1592 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4760' is defined on line 154, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 159, but no explicit reference was found in the text == Unused Reference: 'RFC2918' is defined on line 165, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing J. Mauch 3 Internet-Draft Akamai 4 Intended status: Informational November 18, 2019 5 Expires: May 21, 2020 7 Provide for method to know accepted and rejected NLRI. 8 draft-mauch-bgp-accepted-00 10 Abstract 12 This document defines a method to receive accepted and rejected NLRI 13 over a BGP peering session. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on May 21, 2020. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 51 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 57 7.2. Informational References . . . . . . . . . . . . . . . . 4 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1. Introduction 62 BGP [RFC4271] operators face challenges when attempting to 63 troubleshoot external BGP sessions. Commonly operators debug BGP 64 sessions with commands that display the results of advertised or 65 received routes. 67 When operating a network, you can easily verify you are sending 68 routes to a BGP peer, but you have limited ability to understand the 69 external partner device. Common debugging tools such as a looking 70 glass or contacting a remote operator via e-mail, telephone or other 71 out of band methods is required. 73 This proposal intends to provide an automated method to see the NLRI 74 eligible for selection that pass any filtering methods provided by 75 the peer software stack. 77 2. Requirements Language 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in BCP 82 14 [RFC2119] when, and only when, they appear in all capitals, as 83 shown here. 85 3. Solution 87 The requesting device will send a BGP message of type XXX to the 88 partner device requesting the list of the NLRI. (excerpted from 89 rfc2918) 90 Message Format: One AFI, SAFI encoded as 92 0 7 15 23 31 93 +-------+-------+-------+-------+ 94 | AFI | Res. | SAFI | 95 +-------+-------+-------+-------+ 97 The meaning, use and encoding of this AFI, SAFI field is the same as 98 defined in [BGP-MP, sect. 7]. More specifically, 100 AFI - Address Family Identifier (16 bit). 102 Res. - Reserved (8 bit) field. Should be set to 0 by the sender and 103 ignored by the receiver. 105 SAFI - Subsequent Address Family Identifier (8 bit). 107 Responses will include: 109 Message Format: per 111 0 15 31 47 64 112 +---+---+---+---+---+---+---+---+ 113 | accepted | rejected | 114 +---+---+---+---+---+---+---+---+ 116 Count of NLRI accepted (unsigned 32-bits) 118 Count of NLRI rejected (unsigned 32-bits) 120 List of NLRI accepted (NLRI list in same format as UPDATE) 122 List of NLRI rejected (NLRI list in same format as UPDATE - 123 infeasible) 125 4. Acknowledgements 127 The authors would like to thank the following people for their 128 comments and support: XXX. 130 5. Security Considerations 132 This message MAY be subject to rate-limits by a partner device to 133 protect itself from CPU or other resource exhaustion. A suggested 134 interval is to not permit more than one request per 60 seconds. 136 6. IANA Considerations 138 This document has unknown IANA Considerations 140 7. References 142 7.1. Normative References 144 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 145 Requirement Levels", BCP 14, RFC 2119, 146 DOI 10.17487/RFC2119, March 1997, 147 . 149 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 150 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 151 DOI 10.17487/RFC4271, January 2006, 152 . 154 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 155 "Multiprotocol Extensions for BGP-4", RFC 4760, 156 DOI 10.17487/RFC4760, January 2007, 157 . 159 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 160 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 161 2009, . 163 7.2. Informational References 165 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 166 DOI 10.17487/RFC2918, September 2000, 167 . 169 Author's Address 171 Jared Mauch 172 Akamai Technologies Inc. 173 8285 Reese Lane 174 Ann Arbor Michigan 48103 175 US 177 Email: jared@akamai.com