< draft-ietf-ippm-ioam-data-13.txt		draft-ietf-ippm-ioam-data-14.txt >
	ippm F. Brockners, Ed.		ippm F. Brockners, Ed.
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track S. Bhandari, Ed.		Intended status: Standards Track S. Bhandari, Ed.
	Expires: December 26, 2021 Thoughtspot		Expires: December 26, 2021 Thoughtspot
	T. Mizrahi, Ed.		T. Mizrahi, Ed.
	Huawei		Huawei
	June 24, 2021		June 24, 2021
	Data Fields for In-situ OAM		Data Fields for In-situ OAM
	draft-ietf-ippm-ioam-data-13		draft-ietf-ippm-ioam-data-14
	Abstract		Abstract
	In-situ Operations, Administration, and Maintenance (IOAM) records		In-situ Operations, Administration, and Maintenance (IOAM) records
	operational and telemetry information in the packet while the packet		operational and telemetry information in the packet while the packet
	traverses a path in the network. This document discusses the data		traverses a path in the network. This document discusses the data
	fields and associated data types for in-situ OAM. In-situ OAM data		fields and associated data types for in-situ OAM. In-situ OAM data
	fields can be encapsulated into a variety of protocols such as NSH,		fields can be encapsulated into a variety of protocols such as NSH,
	Segment Routing, Geneve, or IPv6. In-situ OAM can be used to		Segment Routing, Geneve, or IPv6. In-situ OAM can be used to
	complement OAM mechanisms based on, e.g., ICMP or other types of		complement OAM mechanisms based on, e.g., ICMP or other types of
	skipping to change at page 4, line 34 ¶		skipping to change at page 4, line 34 ¶
	3. Conventions		3. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Abbreviations and definitions used in this document:		Abbreviations and definitions used in this document:
	E2E Edge to Edge		E2E: Edge to Edge
	Geneve: Generic Network Virtualization Encapsulation [RFC8926]		Geneve: Generic Network Virtualization Encapsulation [RFC8926]
	IOAM: In-situ Operations, Administration, and Maintenance		IOAM: In-situ Operations, Administration, and Maintenance
	MTU: Maximum Transmit Unit		MTU: Maximum Transmit Unit
	NSH: Network Service Header [RFC8300]		NSH: Network Service Header [RFC8300]
	OAM: Operations, Administration, and Maintenance		OAM: Operations, Administration, and Maintenance
	skipping to change at page 40, line 11 ¶		skipping to change at page 40, line 11 ¶
	o Check whether the request is neither a duplicate of nor		o Check whether the request is neither a duplicate of nor
	conflicting with either an already existing allocation or a		conflicting with either an already existing allocation or a
	pending allocation. In case of duplicates or conflicts, the		pending allocation. In case of duplicates or conflicts, the
	expert will ask the requestor to update the allocation request		expert will ask the requestor to update the allocation request
	accordingly.		accordingly.
	o Solicit feedback from relevant working groups and communities to		o Solicit feedback from relevant working groups and communities to
	ensure that the new allocation request has been properly reviewed		ensure that the new allocation request has been properly reviewed
	and that rough consensus on the request exists. At a minumum, the		and that rough consensus on the request exists. At a minumum, the
	expert will solicit feedback from the IPPM working group in the		expert will solicit feedback from the IPPM working group in the
	IETF by posting the request to the ippm@ietf.org mailing list. If		IETF by posting the request to the ippm@ietf.org mailing list.
	the feedback received from the relevant working groups and		The expert will allow for a 3-week review period on the mailing
	communities indicates rough consensus on the request, the expert		lists. If the feedback received from the relevant working groups
	will approve the request and ask IANA for allocating the new		and communities within the review period indicates rough consensus
	Namespace-ID. In case the expert senses a lack of consensus from		on the request, the expert will approve the request and ask IANA
	the feedback received, the expert will ask the requestor to engage		for allocating the new Namespace-ID. In case the expert senses a
	with the corresponding working groups and communities to further		lack of consensus from the feedback received, the expert will ask
	review and refine the request.		the requestor to engage with the corresponding working groups and
			communities to further review and refine the request.
	It is intended that any allocation will be accompanied by a published		It is intended that any allocation will be accompanied by a published
	RFC. In order to allow for the allocation of code points prior to		RFC. In order to allow for the allocation of code points prior to
	the RFC being approved for publication, the designated expert can		the RFC being approved for publication, the designated expert can
	approve allocations once it seems clear that an RFC will be		approve allocations once it seems clear that an RFC will be
	published.		published.
	0x0000: default namespace (known to all IOAM nodes)		0x0000: default namespace (known to all IOAM nodes)
	0x0001 - 0x7FFF: reserved for private use		0x0001 - 0x7FFF: reserved for private use
End of changes. 3 change blocks.
	10 lines changed or deleted		11 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/