idnits 2.17.1 draft-nayak-intarea-probe-by-vfi-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 5) being 79 lines == It seems as if not all pages are separated by form feeds - found 4 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 5 instances of too long lines in the document, the longest one being 32 characters in excess of 72. -- The draft header indicates that this document updates RFC8335, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 16, 2019) is 1714 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) == Missing Reference: 'IANA-PEN' is mentioned on line 194, but not defined Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA WG M. Nayak 3 Internet-Draft R. Bonica 4 Updates: 8335 (if approved) R. Puttur 5 Intended status: Standards Track Juniper Networks 6 Expires: February 15, 2020 August 16, 2019 8 Probing IP Interfaces By Vendor Specific Identifiers 9 draft-nayak-intarea-probe-by-vfi-01 11 Abstract 13 This document enhances the PROBE diagnostic tool so that it can 14 identify the probed interface by Vendor Specific Identifiers. 15 In order to achieve that goal, this document also extends the 16 Interface Identification Object. The Interface Identification 17 Object is an ICMP Extension Object class. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 15, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 55 3. ICMP Extended Echo Request Message . . . . . . . . . . . . . 3 56 4. Interface Identification Object . . . . . . . . . . . . . . . 3 57 5. ICMP Extended Echo Reply Message . . . . . . . . . . . . . . 4 58 6. ICMP Message Processing . . . . . . . . . . . . . . . . . . . 4 59 7. Updates To RFC 8335 . . . . . . . . . . . . . . . . . . . . . 4 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 11.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 11.2. Informative References . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Problem Statement 70 PROBE [RFC8335] is a diagnostic tool that can be used to query the 71 status of an interface. PROBE sends an ICMP Extended Echo Request 72 message to a proxy interface. The ICMP Extended Echo Request message 73 contains an ICMP Extension Structure and the ICMP Extension Structure 74 contains an Interface Identification Object. The Interface 75 Identification Object identifies the probed interface by name, 76 ifIndex or address. 78 When the proxy interface receives the ICMP Extended Echo Request, the 79 node upon which it resides executes access control procedures as per 80 [RFC8335] security considerations. If access is granted, the node 81 determines the status of the probed interface and returns an ICMP 82 Extended Echo Reply message. The ICMP Extended Echo Reply indicates 83 the status of the probed interface. 85 Virtualized instance of the network adapter are created out of a 86 Network Interface Card to enable efficient sharing of Network 87 Interface Card in a virtualization environment. These Virtualized 88 instances of the network adapter are implemented in the hardware and 89 assigned a Vendor Specific Identifier to uniquely identify the 90 Virtualized instance of the network adapter. 92 This document enhances the PROBE so that it can identify the probed 93 interface by Vendor Specific Identifiers. This probe type is 94 necessary when none of the other probe types of PROBE (i.e., probe 95 interface by name, probe interface by address, etc) work. 96 Virtual Function Index (VFI) [SR-IOV] is one (but not the only) 97 instance of Vendor Specific Identifiers. Vendor Specific Identifiers, 98 hereinafter referred to as VSI in the remaining part of this document. 99 In order to achieve PROBE's enhancement, this document extends the 100 Interface Identification Object. The Interface Identification Object 101 is an ICMP Extension Object class. 103 2. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 3. ICMP Extended Echo Request Message 113 Section 2 of [RFC8335] defines the ICMP Extended Echo Request 114 message. As per [RFC8335], the ICMP Extended Echo Request message 115 contains the following fields: 117 o Type 119 o Code 121 o Checksum 123 o Identifier 125 o Reserved 127 o L (local) 129 o ICMP Extension Structure 131 Section 7 of [RFC4884] defines the ICMP Extension Structure. As per 132 [RFC4884], the Extension Structure contains exactly one Extension 133 Header followed by one or more objects. When applied to the ICMP 134 Extended Echo Request message, the ICMP Extension Structure contains 135 exactly one instance of the Interface Identification Object. 136 Section 2.1 of [RFC8335] defines the Interface Identification Object. 137 Section 4 of this document extends that definition. 139 If the L-bit is set, the Interface Identification Object can identify 140 the probed interface by name, index, address or VFI. If the L-bit is 141 clear, the Interface Identification Object identifies the probed 142 interface by address. 144 4. Interface Identification Object 146 Section 2.1 of [RFC8335] defines the Interface Identification Object. 147 The Interface Identification Object identifies the probed interface 148 by name, index, or address. Like any other ICMP Extension Object, it 149 contains an Object Header and Object Payload. The Object Header 150 contains the following fields: 152 o Class-Num: Interface Identification Object. The value is 3. 154 o C-Type: Determines how the probed interface is identified. 156 o Length: Length of the object, measured in octets, including the 157 Object Header and Object Payload. 159 Currently, the following values are defined for C-Type: 161 o (0) Reserved 163 o (1) Identifies Interface by Name 165 o (2) Identifies Interface by Index 167 o (3) Identifies Interface by Address 169 This document defines the following, new C-Type: 171 o (value TBD by IANA) Identifies Interfaces by Vendor Specific 172 Identifier (VSI) 174 Every vendor specific ID needs to be N-bits long and the vendor 175 gets to have exactly one of them (i.e, either VFI or some other 176 Vendor Specific Identifiers). If the Interface Identification 177 Object identifies the probed interface by VSI (Vendor Specific 178 Identfier), the payload is as depicted in Figure 1. 180 0 1 2 3 181 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | enterprise-number | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Identifier Length | Reserved | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 187 . identifier(variable length) . 188 . . 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Figure 1: VSI Format 193 This VSI consists of the 4-octet vendor's registered Private 194 Enterprise Number as maintained by IANA [IANA-PEN] followed by a 195 unique identifier assigned by the vendor. 197 Payload fields are defined as follows: 199 o Identifier Length: Number of significant bytes contained by the 200 VSI. (The VSI field contains significant bytes and padding 201 bytes.) 203 o Reserved: This field MUST be set to 0 and ignored upon receipt. 205 o Identifier: This variable-length field represents an Identifier 206 associated with the probed interface. If the Identifier field 207 would not otherwise terminate on a 32-bit boundary, it MUST be 208 padded with zeroes. 210 5. ICMP Extended Echo Reply Message 212 Section 3 of [RFC8335] defines the ICMP Extended Echo Reply message. 213 This document does not change that definition. 215 6. ICMP Message Processing 217 Section 4 of [RFC8335] defines the ICMP message processing. This 218 document does not change that definition. 220 7. Updates To RFC 8335 222 Section 2 of [RFC8335] states: 224 "If the L-bit is set, the Interface Identification Object can 225 identify the probed interface by name, index, or address. If the 226 L-bit is clear, the Interface Identification Object MUST identify the 227 probed interface by address." 229 This document updates that text as follows: 231 "If the L-bit is set, the Interface Identification Object can 232 identify the probed interface by name, index, address, or Vendor 233 Specific Identifier (VSI). If the L-bit is clear, the Interface 234 Identification Object MUST identify the probed interface by address." 236 8. IANA Considerations 238 IANA is requested to add the following a new C-type: 240 o (value TBD by IANA) Identifies Interfaces by Vendor Specific 241 Identifier (VSI) 243 This new C-Type is to be added to the Interface Identification Object 244 under the "ICMP Extension Object Classes and Class Sub-types" 245 registry. 247 9. Security Considerations 249 This document neither extends nor mitigates any of the security 250 considerations mentioned in [RFC8335]. 252 10. Acknowledgements 254 The authors wish to acknowledge Ross Callon for his helpful comments. 256 11. References 258 11.1. Normative References 260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", BCP 14, RFC 2119, 262 DOI 10.17487/RFC2119, March 1997, 263 . 265 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 266 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 267 DOI 10.17487/RFC4884, April 2007, 268 . 270 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 271 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 272 May 2017, . 274 [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. 275 Boucadair, "PROBE: A Utility for Probing Interfaces", 276 RFC 8335, DOI 10.17487/RFC8335, February 2018, 277 279 11.2. Informative References 281 [SR-IOV] PCI-SIG, ., "Single Root I/O Virtualization and Sharing 282 Specification Revision 1.1", January 2010, 283 . 286 Authors' Addresses 288 Manoj Nayak 289 Juniper Networks 290 Bangalore, KA 560103 291 India 293 Email: manojnayak@juniper.net 295 Ron Bonica 296 Juniper Networks 297 Herndon, Virginia 20171 298 USA 300 Email: rbonica@juniper.net 302 Rafik Puttur 303 Juniper Networks 304 Bangalore, KA 560103 305 India 307 Email: rafikp@juniper.net