< draft-liu-lsr-p2poverlan-07.txt		draft-liu-lsr-p2poverlan-08.txt >
	Network Working Group D. Liu		Network Working Group D. Liu
	Internet-Draft J. Halpern		Internet-Draft J. Halpern
	Intended status: Informational C. Zhang		Intended status: Informational C. Zhang
	Expires: 15 August 2022 Ericsson		Expires: 8 November 2022 Ericsson
	11 February 2022		7 May 2022
	Interface Stack Table Definition and Example for Point-to-Point (P2P)		Interface Stack Table Definition and Example for Point-to-Point (P2P)
	Interface over LAN		Interface over LAN
	draft-liu-lsr-p2poverlan-07		draft-liu-lsr-p2poverlan-08
	Abstract		Abstract
	RFC 5309 defines the Point-to-Point (P2P) circuit type, one of the		RFC 5309 defines the Point-to-Point (P2P) circuit type, one of the
	two circuit types used in the link state routing protocols, and		two circuit types used in the link state routing protocols, and
	highlights that it is important to identify the correct circuit type		highlights that it is important to identify the correct circuit type
	when forming adjacencies, flooding link state database packets, and		when forming adjacencies, flooding link state database packets, and
	monitoring the link state.		monitoring the link state.
	The P2P interface over LAN ifType value 303, has been assigned by		The P2P interface over LAN ifType value 303, has been assigned by
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 15 August 2022.		This Internet-Draft will expire on 8 November 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	3. Interface Stack Table for P2P Interface Type . . . . . . . . 3		3. Interface Stack Table for P2P Interface Type . . . . . . . . 3
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 4		3.1. P2P Interface higher-layer-if and lower-layer-if . . . . 3
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		3.2. P2P Interface Statistics . . . . . . . . . . . . . . . . 4
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.3. P2P Interface Administrative State . . . . . . . . . . . 4
	6.1. Normative references . . . . . . . . . . . . . . . . . . 4		4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	6.2. Informative References . . . . . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
			7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
			7.1. Normative references . . . . . . . . . . . . . . . . . . 5
			7.2. Informative References . . . . . . . . . . . . . . . . . 6
			Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 6
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	[RFC5309] defines the P2P circuit type and highlights that it is		[RFC5309] defines the P2P circuit type and highlights that it is
	important to identify the correct circuit type when forming		important to identify the correct circuit type when forming
	adjacencies, flooding link state database packets, and monitoring the		adjacencies, flooding link state database packets, and monitoring the
	link state.		link state.
	The assignment of 303, as the value for p2pOverLan ifType was made by		The assignment of 303, as the value for p2pOverLan ifType was made by
	Expert Review [Assignment]. This document requests IANA to add this		Expert Review [Assignment]. This document requests IANA to add this
	skipping to change at page 2, line 50 ¶		skipping to change at page 3, line 10 ¶
	enables, for example, routing protocols to automatically inherit the		enables, for example, routing protocols to automatically inherit the
	correct operating mode from the interface stack without further		correct operating mode from the interface stack without further
	configuration (No need to explicitly configure the P2P interface in		configuration (No need to explicitly configure the P2P interface in
	routing protocols).		routing protocols).
	It is helpful to map the P2P interface over LAN type in the interface		It is helpful to map the P2P interface over LAN type in the interface
	management stack table. And if no entry specifies the P2P interface		management stack table. And if no entry specifies the P2P interface
	lower layer, the management suffers loses the ability to get to the		lower layer, the management suffers loses the ability to get to the
	lower layer specific management properties via many tools.		lower layer specific management properties via many tools.
			The P2P interface over LAN type is intended to be used solely as a
			means to signal in standard network management protocols that make
			use of ifStackTables that the upper layer interface is P2P interface,
			and thus the upper and lower layers of P2P over LAN type will be
			expected to apply appropriate semantics: In general, P2P over LAN
			type higher layer SHOULD always be "ipForward" (Value 142,
			[Assignment]), and the P2P over LAN type lower layer SHOULD be any
			appropriate link data layer of "ipForward".
	The purpose of this document is to suggest how to use		The purpose of this document is to suggest how to use
	ifStackTable for the P2P interface over LAN type, and provide		ifStackTable for the P2P interface over LAN type, and provide
	examples.		examples.
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119] [RFC8174].		document are to be interpreted as described in [RFC2119] [RFC8174].
	3. Interface Stack Table for P2P Interface Type		3. Interface Stack Table for P2P Interface Type
			3.1. P2P Interface higher-layer-if and lower-layer-if
	If a device implements the IF-MIB [RFC2863], each entry in the		If a device implements the IF-MIB [RFC2863], each entry in the
	"/interfaces/interface" list (in "Interface Management YANG") in the		"/interfaces/interface" list (in "Interface Management YANG") in the
	operational state is typically mapped to one ifEntry as required in		operational state is typically mapped to one ifEntry as required in
	[RFC8343], therefore the P2P interface over LAN type should also be		[RFC8343], therefore the P2P interface over LAN type should also be
	fully mapped to one ifEntry by defining the "ifStackTable" ("higher-		fully mapped to one ifEntry by defining the "ifStackTable" ("higher-
	layer-if" and "lower-layer-if").		layer-if" and "lower-layer-if").
	The P2P interface higher layer SHOULD be network layer "ipForward"		In ifStackTable the P2P interface over LAN type higher layer SHOULD
	(defined in IANA) to run routing protocol, the P2P interface lower		be network layer "ipForward" to run routing protocol, and the P2P
	layer SHOULD be link data layer "ethernetCsmacd" (defined in IANA).		interface over LAN type lower layer SHOULD be any link data layer
			that can be bound to "ipForward" including "ethernetCsmacd",
			"ieee8023adLag", "l2vlan", and so on (defined in IANA).
	The P2P interface type ifStackTable can be defined along the lines of		The P2P interface over LAN type ifStackTable can be defined along the
	following example which complies with [RFC8343] [RFC6991] [RFC8340]:		lines of following example (In the example, "lower-layer-if" takes
			"ethernetCsmacd" but in fact, "lower-layer-if" can be any other
			available link data layer. See Appendix A for more examples) which
			complies with [RFC8343] [RFC6991]:
	<CODE BEGINS>		<CODE BEGINS>
	<interface>		<interface>
	<name>isis_int</name>		<name>isis_int</name>
	<type>ianaift:ipForward</type>		<type>ianaift:ipForward</type>
	</interface>		</interface>
	<interface>		<interface>
	<name>eth1</name>		<name>eth1</name>
	<type>ianaift:ethernetCsmacd</type>		<type>ianaift:ethernetCsmacd</type>
	</interface>		</interface>
	<interface>		<interface>
	<name>p2p</name>		<name>p2p</name>
	<type>ianaift:p2pOverLan</type>		<type>ianaift:p2pOverLan</type>
	<higher-layer-if>isis_int</higher-layer-if>		<higher-layer-if>isis_int</higher-layer-if>
	<lower-layer-if>eth1</lower-layer-if>		<lower-layer-if>eth1</lower-layer-if>
	<enabled>false</enabled>		<enabled>false</enabled>
	<admin-status>down</admin-status>		<admin-status>down</admin-status>
	<oper-status>down</oper-status>		<oper-status>down</oper-status>
	<statistics>		<statistics>
	<discontinuity-time>		<discontinuity-time>
	2021-04-01T03:00:00+00:00		2021-04-01T03:00:00+00:00
	</discontinuity-time>		</discontinuity-time>
	<!-- counters now shown here -->		<!-- counters now shown here -->
	</statistics>		</statistics>
	</interface>		</interface>
	<CODE ENDS>		<CODE ENDS>
	Figure 1		Figure 1
			3.2. P2P Interface Statistics
			Because multiple IP interfaces can be bound to one physical port, the
			statistics on the physical port SHOULD be a complete set which
			includes statistics of all upper layer interfaces. Therefore,
			exactly same as upper layer interface type of P2P interface -
			"ipForward", the P2P interface ifStackTable only collects and
			displays the traffic entering this P2P interface.
			3.3. P2P Interface Administrative State
			P2P interface can be shutdown independently of the underlying
			interface, as same as "ipForward".
			If P2P interface is administratively up and underlying interface is
			administratively up, then the "oper-status" of the P2P interface
			ifStackTable SHOULD just mirror the underlying interface; If either
			the P2P interface is administratively down or underlying interface
			administratively down, the "oper-status" of the P2P interface
			ifStackTable SHOULD be down. Details refer to Appendix A.
	4. Security Considerations		4. Security Considerations
	The interface stack table specified in this document is read-only.		The interface stack table specified in this document is read-only.
	Read operation to this table should not have a negative effect on		Read operation to this table should not have a negative effect on
	network operations.		network operations.
	5. IANA Considerations		5. IANA Considerations
	In the Interface Types registry, IANA has assigned a value of 303 for		In the Interface Types registry, IANA has assigned a value of 303 for
	p2pOverLan [Assignment] with a reference of [RFC5309]. IANA is		p2pOverLan [Assignment] with a reference of [RFC5309]. IANA is
	requested to amend the reference for that code point to be to this		requested to amend the reference for that code point to be to this
	document and to make a similar amendment in the YANG iana-if-type		document and to make a similar amendment in the YANG iana-if-type
	module (originally specified in [RFC7224]) which currently points to		module (originally specified in [RFC7224]) which currently points to
	[RFC8561], as this document explains how the ifType is to be used.		[RFC8561], as this document explains how the ifType is to be used.
	6. References		6. Acknowledgements
	6.1. Normative references		The authors would like to thank Rob Wilton and Eliot Lear for their
			reviews and valuable comments and suggestions.
			7. References
			7.1. Normative references
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group		[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
	MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,		MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
	<https://www.rfc-editor.org/info/rfc2863>.		<https://www.rfc-editor.org/info/rfc2863>.
	skipping to change at page 5, line 36 ¶		skipping to change at page 6, line 18 ¶
	[RFC8343] Bjorklund, M., "A YANG Data Model for Interface		[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
	Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,		Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
	<https://www.rfc-editor.org/info/rfc8343>.		<https://www.rfc-editor.org/info/rfc8343>.
	[RFC8561] Ahlberg, J., Ye, M., Li, X., Spreafico, D., and M.		[RFC8561] Ahlberg, J., Ye, M., Li, X., Spreafico, D., and M.
	Vaupotic, "A YANG Data Model for Microwave Radio Link",		Vaupotic, "A YANG Data Model for Microwave Radio Link",
	RFC 8561, DOI 10.17487/RFC8561, June 2019,		RFC 8561, DOI 10.17487/RFC8561, June 2019,
	<https://www.rfc-editor.org/info/rfc8561>.		<https://www.rfc-editor.org/info/rfc8561>.
	6.2. Informative References		7.2. Informative References
	[Assignment]		[Assignment]
	"Interface Types (ifType)",		"Interface Types (ifType)",
	<https://www.iana.org/assignments/smi-numbers/smi-		<https://www.iana.org/assignments/smi-numbers/smi-
	numbers.xhtml#smi-numbers-5>.		numbers.xhtml#smi-numbers-5>.
	[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",		[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
	RFC 6991, DOI 10.17487/RFC6991, July 2013,		RFC 6991, DOI 10.17487/RFC6991, July 2013,
	<https://www.rfc-editor.org/info/rfc6991>.		<https://www.rfc-editor.org/info/rfc6991>.
	[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",		Appendix A. Examples
	BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
	<https://www.rfc-editor.org/info/rfc8340>.		In the case of underlying interface is VLAN sub-interface, the
			ifStackTable should be defined as:
			<CODE BEGINS>
			<interface>
			<name>isis_int</name>
			<type>ianaift:ipForward</type>
			</interface>
			<interface>
			<name>eth1_valn1</name>
			<type>ianaift:l2vlan</type>
			</interface>
			<interface>
			<name>p2p</name>
			<type>ianaift:p2pOverLan</type>
			<higher-layer-if>isis_int</higher-layer-if>
			<lower-layer-if>eth1_valn1</lower-layer-if>
			<enabled>false</enabled>
			<admin-status>down</admin-status>
			<oper-status>down</oper-status>
			<statistics>
			<discontinuity-time>
			2021-04-01T03:00:00+00:00
			</discontinuity-time>
			<!-- counters now shown here -->
			</statistics>
			</interface>
			<CODE ENDS>
			Figure 2
			In the case of underlying interface is LAG, the ifStackTable should
			be defined as:
			<CODE BEGINS>
			<interface>
			<name>isis_int</name>
			<type>ianaift:ipForward</type>
			</interface>
			<interface>
			<name>eth1_lag1</name>
			<type>ianaift:ieee8023adLag</type>
			</interface>
			<interface>
			<name>p2p</name>
			<type>ianaift:p2pOverLan</type>
			<higher-layer-if>isis_int</higher-layer-if>
			<lower-layer-if>eth1_lag1</lower-layer-if>
			<enabled>false</enabled>
			<admin-status>down</admin-status>
			<oper-status>down</oper-status>
			<statistics>
			<discontinuity-time>
			2021-04-01T03:00:00+00:00
			</discontinuity-time>
			<!-- counters now shown here -->
			</statistics>
			</interface>
			<CODE ENDS>
			Figure 3
			In the case of P2P interface and underlying interface are both
			administratively up, and the underlying interface operational status
			is up:
			<CODE BEGINS>
			<interface>
			<name>p2p</name>
			<type>ianaift:p2pOverLan</type>
			<higher-layer-if>isis_int</higher-layer-if>
			<lower-layer-if>eth1</lower-layer-if>
			<admin-status>up</admin-status>
			<oper-status>up</oper-status>
			</interface>
			<CODE ENDS>
			Figure 4
			In the case of P2P interface and underlying interface are
			administratively up, but the underlying interface operational status
			is down:
			<CODE BEGINS>
			<interface>
			<name>p2p</name>
			<type>ianaift:p2pOverLan</type>
			<higher-layer-if>isis_int</higher-layer-if>
			<lower-layer-if>eth1</lower-layer-if>
			<admin-status>up</admin-status>
			<oper-status>down</oper-status>
			</interface>
			<CODE ENDS>
			Figure 5
			In the case of P2P interface is administratively down:
			<CODE BEGINS>
			<interface>
			<name>p2p</name>
			<type>ianaift:p2pOverLan</type>
			<higher-layer-if>isis_int</higher-layer-if>
			<lower-layer-if>eth1</lower-layer-if>
			<admin-status>down</admin-status>
			<oper-status>down</oper-status>
			</interface>
			<CODE ENDS>
			Figure 6
			In the case of P2P interface is administratively up but underlying is
			administratively down:
			<CODE BEGINS>
			<interface>
			<name>p2p</name>
			<type>ianaift:p2pOverLan</type>
			<higher-layer-if>isis_int</higher-layer-if>
			<lower-layer-if>eth1</lower-layer-if>
			<admin-status>up</admin-status>
			<oper-status>down</oper-status>
			</interface>
			<CODE ENDS>
			Figure 7
	Authors' Addresses		Authors' Addresses
	Daiying Liu		Daiying Liu
	Ericsson		Ericsson
	No.5 Lize East street		No.5 Lize East street
	Beijing		Beijing
	100102		100102
	China		China
	Email: harold.liu@ericsson.com		Email: harold.liu@ericsson.com
	Joel Halpern		Joel Halpern
	Ericsson		Ericsson
	Email: joel.halpern@ericsson.com		Email: joel.halpern@ericsson.com
	Congjie Zhang		Congjie Zhang
	Ericsson		Ericsson
	Email: congjie.zhang@ericsson.com		Email: congjie.zhang@ericsson.com
End of changes. 20 change blocks.
	47 lines changed or deleted		221 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/