idnits 2.17.1 draft-liu-lsr-p2poverlan-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 16, 2021) is 1038 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC1195' is mentioned on line 70, but not defined -- Looks like a reference, but probably isn't: '1' on line 294 == Missing Reference: 'RFC2328' is mentioned on line 70, but not defined -- Looks like a reference, but probably isn't: '2' on line 296 == Missing Reference: 'RFC5340' is mentioned on line 71, but not defined -- Looks like a reference, but probably isn't: '3' on line 298 -- Looks like a reference, but probably isn't: '4' on line 300 -- Looks like a reference, but probably isn't: '5' on line 302 -- Looks like a reference, but probably isn't: '6' on line 304 == Unused Reference: 'RFC2119' is defined on line 233, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 247, but no explicit reference was found in the text == Unused Reference: 'RFC6991' is defined on line 261, but no explicit reference was found in the text == Unused Reference: 'RFC7950' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'RFC8342' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'RFC7224' is defined on line 284, but no explicit reference was found in the text == Unused Reference: 'RFC8340' is defined on line 288, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Liu 3 Internet-Draft J. Halpern 4 Intended status: Informational C. Zhang 5 Expires: December 18, 2021 Ericsson 6 June 16, 2021 8 Interface Stack Table Definition for Point to Point (P2P) Interface over 9 LAN 10 draft-liu-lsr-p2poverlan-00 12 Abstract 14 The point-to-point circuit type is one of the mainly used circuit 15 types in link state routing protocol. It is important to identify 16 the correct circuit type when forming adjacencies, flooding link 17 state database packets, and monitor the link state. This document 18 defines point-to-point interface type and relevant stack tables to 19 provide benefit for operation, maintenance and statistics. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 18, 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 57 3. Relationship to the IF-MIB and Interfaces YANG Module . . . . 2 58 4. Interface Stack Table for P2P Interface Type . . . . . . . . 4 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 7.1. Normative references . . . . . . . . . . . . . . . . . . 5 63 7.2. Informative References . . . . . . . . . . . . . . . . . 7 64 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 Point-to-point is the predominant circuit type used by link state 70 routing protocols such as IS-IS [RFC1195] [1] and OSPF [RFC2328] [2] 71 [RFC5340] [3]. Compare with broadcast interface, point-to-point 72 interface is used differently when establish neighbor adjacencies, 73 flood link state information, representing the topology, etc. 75 To simplify configuration and operation, it is helpful To represent 76 the fact that an interface is to be considered a point-to-point 77 interface explicitly in the interface stack. This enables, for 78 example, routing protocols to automatically use the correct operating 79 mode without further configuration. 81 So it is necessary to abstract P2P as special sub-interface type and 82 define relevant interface stack table. 84 2. Requirements Language 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [4]. 90 3. Relationship to the IF-MIB and Interfaces YANG Module 92 As defined in [RFC8343] [5], if the device implements the IF-MIB 93 [RFC2863], each entry in the "/interfaces/interface" list in the 94 operational state is typically mapped to one ifEntry. 96 So P2P as sub-interface type should also fully map to one ifEntry, 97 meanwhile define the "higher-layer-if" and "lower-layer-if" in the 98 YANG corresponding to "ifStackTable" in IF-MIB to setup a complete 99 interface stack table, then the P2P interface type can borrow all 100 existing items in interfaces YANG and IF-MIB to take the full 101 advantages from operation, statistic, etc. 103 The "higher-layer-if" should be a network layer interface type, and 104 the lower-layer-if should be a data link layer interface type. 106 +--------------------------------------+----------------------------+ 107 | YANG data node in | IF-MIB object | 108 | /interfaces/interface | | 109 +--------------------------------------+----------------------------+ 110 | name | ifName | 111 | type | ifType | 112 | description | ifAlias | 113 | admin-status | ifAdminStatus | 114 | oper-status | ifOperStatus | 115 | last-change | ifLastChange | 116 | if-index | ifIndex | 117 | link-up-down-trap-enable | ifLinkUpDownTrapEnable | 118 | phys-address | ifPhysAddress | 119 | higher-layer-if and lower-layer-if | ifStackTable | 120 | speed | ifSpeed and ifHighSpeed | 121 | discontinuity-time | ifCounterDiscontinuityTime | 122 | in-octets | ifHCInOctets | 123 | in-unicast-pkts | ifHCInUcastPkts | 124 | in-broadcast-pkts | ifHCInBroadcastPkts | 125 | in-multicast-pkts | ifHCInMulticastPkts | 126 | in-discards | ifInDiscards | 127 | in-errors | ifInErrors | 128 | in-unknown-protos | ifInUnknownProtos | 129 | out-octets | ifHCOutOctets | 130 | out-unicast-pkts | ifHCOutUcastPkts | 131 | out-broadcast-pkts | ifHCOutBroadcastPkts | 132 | out-multicast-pkts | ifHCOutMulticastPkts | 133 | out-discards | ifOutDiscards | 134 | out-errors | ifOutErrors | 135 +--------------------------------------+----------------------------+ 137 YANG Data Nodes and Related IF-MIB Objects 139 Figure 1 141 4. Interface Stack Table for P2P Interface Type 143 P2P interface type is a kind of point-to-point circuit type. P2P 144 interface higher layer should be network layer "ipForward" (defined 145 in IANA [6]) to run routing protocol, P2P interface lower layer is 146 link data layer "ethernetCsmacd" (defined in IANA). 148 P2P interface type ifStackTable should be define as: 150 151 isis_int 152 ianaift:ipForward 153 155 156 eth1 157 ianaift:ethernetCsmacd 158 160 161 p2p 162 ianaift:p2pOverLan 163 isis_int 164 eth1 165 false 166 down 167 down 168 169 170 2021-04-01T03:00:00+00:00 171 172 173 174 176 Figure 2 178 5. Security Considerations 180 The interface stack table specified in this document is read-only. 181 Read operation to this table without complete protection shouldn't 182 have a negative effect on network operations. 184 The interface stack table defines to be accessed via network 185 management protocols such as NETCONF [RFC6241], RESTCONF [RFC8040]. 186 The NETCONF is over on layer secure transport, and the mandatory 187 secure transport is Secure Shell (SSH) [RFC6242]. The lowest 188 RESTCONF layer is HTTPS, and the mandatory-to-implement secure 189 transport is TLS [RFC5246]. 191 6. IANA Considerations 193 IANA need to update the "Interface Types(ifType)" registry (available 194 at https://www.iana.org/assignments/smi-numbers/smi- 195 numbers.xhtml#smi-numbers-5) with the following status types: 197 +=========+==================+=======================================+ 198 | Decimal | Name | Description | 199 +=========+==================+=======================================+ 200 | 303 | p2pOverLan | Point to Point over LAN interface | 201 +---------+------------------+---------------------------------------+ 203 Figure 3 205 IANA need to update the "IANAifType-MIB" registry (available at 206 https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib.xhtml) 207 with the following status types: 209 +=========+==================+=======================================+ 210 | Value | Name | Description | 211 +=========+==================+=======================================+ 212 | 303 | p2pOverLan | Point to Point over LAN interface | 213 +---------+------------------+---------------------------------------+ 215 Figure 4 217 IANA need to update the "iana-if-type YANG Module" registry 218 (available at https://www.iana.org/assignments/iana-if-type/iana-if- 219 type.xhtml) with the following status types: 221 identity p2pOverLan { 222 base iana-interface-type; 223 description 224 "Point to Point over LAN interface."; 225 } 227 Figure 5 229 7. References 231 7.1. Normative references 233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 234 Requirement Levels", BCP 14, RFC 2119, 235 DOI 10.17487/RFC2119, March 1997, 236 . 238 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 239 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 240 . 242 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 243 (TLS) Protocol Version 1.2", RFC 5246, 244 DOI 10.17487/RFC5246, August 2008, 245 . 247 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 248 Network Configuration Protocol (NETCONF)", RFC 6020, 249 DOI 10.17487/RFC6020, October 2010, 250 . 252 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 253 Bierman, "Network Configuration Protocol (NETCONF)", 254 RFC 6241, DOI 10.17487/RFC6241, June 2011, 255 . 257 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 258 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 259 . 261 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 262 DOI 10.17487/RFC6991, June 2011, 263 . 265 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", 266 RFC 7950, DOI 10.17487/RFC7950, August 2016, 267 . 269 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 270 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 271 . 273 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 274 and R. Wilton, "Network Management Datastore Architecture 275 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 276 . 278 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 279 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 280 . 282 7.2. Informative References 284 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 285 RFC 7224, DOI 10.17487/RFC7224, May 2014, 286 . 288 [RFC8340] Bjorklund, M. and L. Berger, "YANG Tree Diagrams", 289 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 290 . 292 7.3. URIs 294 [1] https://datatracker.ietf.org/doc/html/rfc1195 296 [2] https://datatracker.ietf.org/doc/html/rfc2328 298 [3] https://datatracker.ietf.org/doc/html/rfc5340 300 [4] https://datatracker.ietf.org/doc/html/rfc2119 302 [5] https://datatracker.ietf.org/doc/html/rfc8343 304 [6] https://www.iana.org/assignments/iana-if-type/iana-if-type.xhtml 306 Authors' Addresses 308 Daiying Liu 309 Ericsson 310 No.5 Lize East street 311 Beijing 100102 312 China 314 Email: harold.liu@ericsson.com 316 Joel Halpern 317 Ericsson 319 Email: joel.halpern@ericsson.com 321 Congjie Zhang 322 Ericsson 324 Email: congjie.zhang@ericsson.com