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