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