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/