idnits 2.17.1 draft-liu-lsr-p2poverlan-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: ---------------------------------------------------------------------------- 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 17, 2021) is 1016 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6241' is mentioned on line 188, but not defined == Missing Reference: 'RFC8040' is mentioned on line 188, but not defined == Missing Reference: 'RFC6242' is mentioned on line 190, but not defined == Missing Reference: 'RFC8446' is mentioned on line 192, but not defined == Unused Reference: 'RFC5309' is defined on line 253, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 262, but no explicit reference was found in the text == Unused Reference: 'RFC6991' is defined on line 267, but no explicit reference was found in the text == Unused Reference: 'RFC7950' is defined on line 271, but no explicit reference was found in the text == Unused Reference: 'RFC7224' is defined on line 281, but no explicit reference was found in the text == Unused Reference: 'RFC8340' is defined on line 285, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). 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 19, 2021 Ericsson 6 June 17, 2021 8 Interface Stack Table Definition for Point to Point (P2P) Interface over 9 LAN 10 draft-liu-lsr-p2poverlan-01 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 19, 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 . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 Point-to-point is the predominant circuit type used by link state 69 routing protocols such as IS-IS [RFC1195] and OSPF [RFC2328] 70 [RFC5340]. Compare with broadcast interface, point-to-point 71 interface is used differently when establish neighbor adjacencies, 72 flood link state information, representing the topology, etc. 74 To simplify configuration and operation, it is helpful To represent 75 the fact that an interface is to be considered a point-to-point 76 interface explicitly in the interface stack. This enables, for 77 example, routing protocols to automatically use the correct operating 78 mode without further configuration. 80 So it is necessary to abstract P2P as special sub-type type and 81 define relevant interface stack table. And if no entry saying 82 p2pOverLan layer over ethernet, the management will suffer since lose 83 the ability to get to the Ethernet-specific management properties 84 (Ethernet MIB or YANG model) via many tools. 86 2. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 3. Relationship to the IF-MIB and Interfaces YANG Module 94 As defined in [RFC8343], if the device implements the IF-MIB 95 [RFC2863], each entry in the "/interfaces/interface" list in the 96 operational state is typically mapped to one ifEntry. 98 So P2P as sub-interface type should also fully map to one ifEntry, 99 meanwhile define the "higher-layer-if" and "lower-layer-if" in the 100 YANG corresponding to "ifStackTable" in IF-MIB to setup a complete 101 interface stack table, then the P2P interface type can borrow all 102 existing items in interfaces YANG and IF-MIB to take the full 103 advantages from operation, statistic, etc. 105 The "higher-layer-if" should be a network layer interface type, and 106 the lower-layer-if should be a data link layer interface type. 108 +--------------------------------------+----------------------------+ 109 | YANG data node in | IF-MIB object | 110 | /interfaces/interface | | 111 +--------------------------------------+----------------------------+ 112 | name | ifName | 113 | type | ifType | 114 | description | ifAlias | 115 | admin-status | ifAdminStatus | 116 | oper-status | ifOperStatus | 117 | last-change | ifLastChange | 118 | if-index | ifIndex | 119 | link-up-down-trap-enable | ifLinkUpDownTrapEnable | 120 | phys-address | ifPhysAddress | 121 | higher-layer-if and lower-layer-if | ifStackTable | 122 | speed | ifSpeed and ifHighSpeed | 123 | discontinuity-time | ifCounterDiscontinuityTime | 124 | in-octets | ifHCInOctets | 125 | in-unicast-pkts | ifHCInUcastPkts | 126 | in-broadcast-pkts | ifHCInBroadcastPkts | 127 | in-multicast-pkts | ifHCInMulticastPkts | 128 | in-discards | ifInDiscards | 129 | in-errors | ifInErrors | 130 | in-unknown-protos | ifInUnknownProtos | 131 | out-octets | ifHCOutOctets | 132 | out-unicast-pkts | ifHCOutUcastPkts | 133 | out-broadcast-pkts | ifHCOutBroadcastPkts | 134 | out-multicast-pkts | ifHCOutMulticastPkts | 135 | out-discards | ifOutDiscards | 136 | out-errors | ifOutErrors | 137 +--------------------------------------+----------------------------+ 139 YANG Data Nodes and Related IF-MIB Objects 141 Figure 1 143 4. Interface Stack Table for P2P Interface Type 145 P2P interface type is a kind of point-to-point circuit type. P2P 146 interface higher layer should be network layer "ipForward" (defined 147 in IANA) to run routing protocol, P2P interface lower layer is link 148 data layer "ethernetCsmacd" (defined in IANA). 150 P2P interface type ifStackTable should be defined as the following 151 example: 153 154 isis_int 155 ianaift:ipForward 156 158 159 eth1 160 ianaift:ethernetCsmacd 161 163 164 p2p 165 ianaift:p2pOverLan 166 isis_int 167 eth1 168 false 169 down 170 down 171 172 173 2021-04-01T03:00:00+00:00 174 175 176 177 179 Figure 2 181 5. Security Considerations 183 The interface stack table specified in this document is read-only. 184 Read operation to this table without complete protection shouldn't 185 have a negative effect on network operations. 187 The interface stack table defines to be accessed via network 188 management protocols such as NETCONF [RFC6241], RESTCONF [RFC8040]. 189 The NETCONF is over on layer secure transport, and the mandatory 190 secure transport is Secure Shell (SSH) [RFC6242]. The lowest 191 RESTCONF layer is HTTPS, and the mandatory-to-implement secure 192 transport is TLS [RFC8446]. 194 6. IANA Considerations 196 IANA need to update the "Interface Types(ifType)" registry (available 197 at https://www.iana.org/assignments/smi-numbers/smi- 198 numbers.xhtml#smi-numbers-5) with the following status types: 200 +=========+==================+=======================================+ 201 | Decimal | Name | Description | 202 +=========+==================+=======================================+ 203 | 303 | p2pOverLan | Point to Point over LAN interface | 204 +---------+------------------+---------------------------------------+ 206 Figure 3 208 IANA need to update the "IANAifType-MIB" registry (available at 209 https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib.xhtml) 210 with the following status types: 212 +=========+==================+=======================================+ 213 | Value | Name | Description | 214 +=========+==================+=======================================+ 215 | 303 | p2pOverLan | Point to Point over LAN interface | 216 +---------+------------------+---------------------------------------+ 218 Figure 4 220 IANA need to update the "iana-if-type YANG Module" registry 221 (available at https://www.iana.org/assignments/iana-if-type/iana-if- 222 type.xhtml) with the following status types: 224 identity p2pOverLan { 225 base iana-interface-type; 226 description 227 "Point to Point over LAN interface."; 228 } 230 Figure 5 232 7. References 234 7.1. Normative references 236 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 237 dual environments", December 1990, 238 . 240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 241 Requirement Levels", BCP 14, RFC 2119, 242 DOI 10.17487/RFC2119, March 1997, 243 . 245 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 6242, 246 DOI 10.17487/RFC2328, April 1998, 247 . 249 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 250 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 251 . 253 [RFC5309] Zinin, A. and N. Shen, "Point-to-Point Operation over LAN 254 in Link State Routing Protocols", RFC 5309, 255 DOI 10.17487/RFC5309, October 2008, 256 . 258 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 259 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 260 . 262 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 263 Network Configuration Protocol (NETCONF)", RFC 6020, 264 DOI 10.17487/RFC6020, October 2010, 265 . 267 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 268 DOI 10.17487/RFC6991, June 2011, 269 . 271 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", 272 RFC 7950, DOI 10.17487/RFC7950, August 2016, 273 . 275 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 276 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 277 . 279 7.2. Informative References 281 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 282 RFC 7224, DOI 10.17487/RFC7224, May 2014, 283 . 285 [RFC8340] Bjorklund, M. and L. Berger, "YANG Tree Diagrams", 286 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 287 . 289 Authors' Addresses 291 Daiying Liu 292 Ericsson 293 No.5 Lize East street 294 Beijing 100102 295 China 297 Email: harold.liu@ericsson.com 299 Joel Halpern 300 Ericsson 302 Email: joel.halpern@ericsson.com 304 Congjie Zhang 305 Ericsson 307 Email: congjie.zhang@ericsson.com