idnits 2.17.1 draft-haberman-rpsl-reachable-test-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. 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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 11, 2009) is 5462 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF B. Haberman, Ed. 3 Internet-Draft JHU APL 4 Intended status: Standards Track May 11, 2009 5 Expires: November 12, 2009 7 A Dedicated RPSL Interface Identifier for Operational Testing 8 draft-haberman-rpsl-reachable-test-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 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 This Internet-Draft will expire on November 12, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 The deployment of new IP connectivity typically results in 47 intermittent reachability for numerous reasons which are outside the 48 scope of this document. In order to aid in the debugging of these 49 persistent problems, this document proposes the creation of a new 50 Routing Policy Specification Language object that allows a network to 51 advertise an IP address which is reachable and can be used as a 52 target for diagnostic tests (e.g., pings). 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. RPSL Extension for Diagnostic Address . . . . . . . . . . . . . 3 58 3. Using the RPSL Pingable Attribute . . . . . . . . . . . . . . . 4 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 63 6.2. Informative References . . . . . . . . . . . . . . . . . . 4 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1. Introduction 68 The deployment of new IP connectivity typically results in 69 intermittent reachability for numerous reasons which are outside the 70 scope of this document. In order to aid in the debugging of these 71 persistent problems, this document proposes the creation of a new 72 Routing Policy Specification Language object [RFC4012] that allows a 73 network to advertise an IP address which is reachable and can be used 74 as a target for diagnostic tests (e.g., pings). 76 The goal of this diagnostic address is to provide operators a means 77 to advertise selected hosts that can be targets of tests for such 78 common issues as reachability and Path MTU discovery. 80 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 81 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 82 "OPTIONAL" in this document are to be interpreted as described in 83 [RFC2119]. 85 2. RPSL Extension for Diagnostic Address 87 Network operators wishing to provide a diagnostic address for its 88 peers, customers, etc. can advertise its existence via the Routing 89 Policy Specification Language [RFC4012] [RFC2622]. The pingable 90 attribute is a member of the aut-num class of the RPSL. The debug 91 attribute has the following characteristics: 93 +-----------+-------------------------------+-----------------------+ 94 | Attribute | Value | Type | 95 +-----------+-------------------------------+-----------------------+ 96 | pingable | or | optional, | 97 | | | multi-valued | 98 +-----------+-------------------------------+-----------------------+ 100 The pingable attribute allows a network operator to advertise an IP 101 address of a node which should be reachable from outside networks. 102 This node can be used as a destination address for diagnostic tests. 103 An example of using the pingable attribute is shown in Figure 1. 105 aut-num: AS64500 106 pingable: 2001:DB8::DEAD:BEEF 108 Figure 1: DEBUG Attribute Example 110 3. Using the RPSL Pingable Attribute 112 The presence of one or more pingable attributes signals to network 113 operators that the maintainer of the referenced network is providing 114 the address(es) for external diagnostic testing. Tests involving the 115 advertised address(es) MUST be rate limited to no more than ten 116 probes in a five minute window. 118 4. IANA Considerations 120 None. 122 5. Acknowledgements 124 Randy Bush and David Farmer provided the original concept for the 125 pingable attribute and useful comments on preliminary versions of 126 this draft. 128 6. References 130 6.1. Normative References 132 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 133 Requirement Levels", BCP 14, RFC 2119, March 1997. 135 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 136 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 137 "Routing Policy Specification Language (RPSL)", RFC 2622, 138 June 1999. 140 [RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, 141 "Routing Policy Specification Language next generation 142 (RPSLng)", RFC 4012, March 2005. 144 6.2. Informative References 145 Author's Address 147 Brian Haberman (editor) 148 Johns Hopkins University Applied Physics Lab 149 11100 Johns Hopkins Road 150 Laurel, MD 20723-6099 151 US 153 Phone: +1 443 778 1319 154 Email: brian@innovationslab.net