Authors
I have reviewed the latest version of the draft. In general, the draft is clear
and well written – thanks! I have a few comments in-line below that are mainly
aimed at improving the readability of the document, prefixed by MB> or s/ ( in
the case of grammar issues). Please treat these as you would any other WG last
call comments.
Regards
Matthew
=======
NVO3 Working Group G. Mirsky
Internet-Draft Ericsson
Intended status: Standards Track S. Boutros
Expires: 28 February 2025 Ciena
D. Black
Dell EMC
S. Pallagatti
VMware
27 August 2024
OAM for use in GENEVE
draft-ietf-nvo3-geneve-oam-11
Abstract
This document lists a set of general requirements for active OAM
protocols in the Geneve overlay network. Based on the requirements,
s/the requirements/these requirements
IP encapsulation for active Operations, Administration, and
Maintenance protocols in Geneve protocol is defined. Considerations
for using ICMP and UDP-based protocols are discussed.
[snip]
1. Introduction
Geneve [RFC8926] is intended to support various scenarios of network
virtualization. In addition to carrying multi-protocol payload,
s/multi-protocol payload/multiple protocols
e.g., Ethernet, IPv4/IPv6, the Geneve message includes metadata.
Operations, Administration, and Maintenance (OAM) protocols support
fault management and performance monitoring functions necessary for
comprehensive network operation. Active OAM protocols, as defined in
[RFC7799], use specially constructed packets that are injected into
the network. To ensure that the measured performance metric or the
detected failure of the transport layer are related to a particular
Geneve flow, it is critical that these test packets share fate with
overlay data packets for that flow when traversing the underlay
network.
MB> The last sentence above is a little hard to parse, and I think we should
also avoid mixing "transport layer" with the IETF concept of transport
protocols.
Maybe rephrase along the following lines:
"To ensure that a performance metric or a detected failure are related to a
particular
Geneve flow, it is critical that these OAM test packets share fate with
overlay data packets for that flow when traversing the underlay
network."
A set of general requirements for active OAM protocols in the Geneve
overlay network is listed in Section 2. IP encapsulation conforms to
these requirements and is a suitable encapsulation of active OAM
protocols in a Geneve overlay network. Active OAM in a Geneve
overlay network are exchanged between two Geneve tunnel endpoints,
which may be an NVE (Network Virtualization Edge) or another device
Mirsky, et al. Expires 28 February 2025 [Page 2]
Internet-Draft OAM in GENEVE August 2024
acting as a Geneve tunnel endpoint. For simplicity, NVE is used to
s/NVE/an NVE
represent the Geneve tunnel endpoint. Please refer to [RFC7365] and
[RFC8014] for detailed definitions and descriptions of NVE. The IP
s/NVE/an NVE
encapsulation of Geneve OAM defined in this document applies to an
overlay service by introducing a Management Virtual Network
Identifier (VNI) that could be used in combination with various
values of the Protocol Type field in the Geneve header, i.e.,
Ethertypes for IPv4 or IPv6. Analysis and definition of other types
s/Analysis / The analysis
of OAM encapsulation in Geneve are outside the scope of this
document.
1.1. Conventions used in this document
[snip]
1.1.3. Acronyms
Geneve Generic Network Virtualization Encapsulation
NVO3 Network Virtualization Overlays
OAM Operations, Administration, and Maintenance
VNI Virtual Network Identifier
MB> I suggest adding a '-' or ':' after the terms above
2. Active OAM Protocols in Geneve Networks
[snip]
tunnel and the state of the OAM protocol the OAM encapsulation is
required to comply with the following requirements:
REQ#1: Geneve OAM test packets MUST share the fate with data
traffic of the monitored Geneve tunnel, i.e., be in-band
(Section 1.1.1) with the monitored traffic, follow the same
overlay and transport path as packets with data payload, in the
forward direction, i.e. from ingress toward egress endpoint(s) of
the OAM test.
MB> I suggest expanding "REQ" to "Requirement" throughout.
An OAM protocol MAY be used to monitor the particular Geneve tunnel
as a whole. In that case, test packets could be in-band relative to
a sub-set of tenant flows transported over the Geneve tunnel. If the
goal is to monitor the condition experienced by the flow of a
particular tenant, the test packets MUST be in-band with that
specific flow in the Geneve tunnel. Both scenarios are discussed in
detail in Section 2.1.
REQ#2: Encapsulation of OAM control message and data packets in
underlay network MUST be indistinguishable from the underlay
network IP forwarding point of view.
MB> This is not really clear. I think you are trying to say: "The encapsulation
of
OAM control messages and data packets in the underlay network MUST be
indistinguishable from
each other from an underlay network IP forwarding point of view."
REQ#3: Presence of OAM control message in Geneve packet MUST be
unambiguously identifiable to Geneve functionality, e.g., at
endpoints of Geneve tunnels.
s/Presence of OAM control message in Geneve packet / The presence of OAM
control messages
in the Geneve packet
REQ#4: OAM test packets MUST NOT be forwarded to a tenant system.
A test packet generated by an active OAM protocol, either for a
defect detection or performance measurement, according to REQ#1, MUST
be in-band (Section 1.1.1) with the tunnel or data flow being
monitored. In an environment where multiple paths through the domain
are available, underlay transport nodes can be programmed to use
characteristic information to balance the load across known paths.
It is essential that test packets follow the same route, i.e.,
traverses the same set of nodes and links, as a data packet of the
monitored flow. Thus, the following requirement to support OAM
packet fate-sharing with the data flow:
REQ#5: It MUST be possible to express entropy for underlay Equal
Cost Multipath in the Geneve encapsulation of OAM packets.
2.1. Defect Detection and Troubleshooting in Geneve Network with Active
OAM
Figure 1 presents an example of a Geneve domain. In this section, we
consider two scenarios of active OAM being used to detect and
localize defects in the Geneve network.
MB> I suggest removing the first person from the above sentence. Also,
rearrange it so the description
of the section comes first and flows into the figure description:
" This section considers two scenarios where active OAM is used to detect and
localize defects in a Geneve network. Figure 1 presents an example of a
Geneve domain."
Mirsky, et al. Expires 28 February 2025 [Page 4]
Internet-Draft OAM in GENEVE August 2024
+--------+ +--------+
| Tenant +--+ +----| Tenant |
| VNI 28 | | | | VNI 35 |
+--------+ | ................ | +--------+
| +----+ . . +----+ |
| | NVE|--. .--| NVE| |
+--| A | . . | B |---+
+----+ . . +----+
/ . .
/ . Geneve .
+--------+ / . Network .
| Tenant +--+ . .
| VNI 35 | . .
+--------+ ................
|
+----+
| NVE|
| C |
+----+
|
|
=====================
| |
+--------+ +--------+
| Tenant | | Tenant |
| VNI 28 | | VNI 35 |
+--------+ +--------+
Figure 1: An example of a Geneve domain
In the first case, consider when a communication problem between
Network Virtualization Edge (NVE) device A and NVE C exists. Upon
the investigation, the operator discovers that the forwarding in the
underlay, e.g., the IP network, is working well. Still, the Geneve
connection is unstable for all NVE A and NVE C tenants. Detection,
troubleshooting, and localization of the problem can be done
irrespective of the VNI value.
MB> I think this could be phrased "regardless of the VNI value" rather than
"irrespective of" because you are not totally dismissng the VNI, but rather
saying that
detection, troubleshooting and localization can be done for all or any value of
VNI. Is that
what you mean?
Also, I think you are refering to the IP underlay network working well. Please
clarify.
In the second case, traffic on VNI 35 between NVE A and NVE B has no
problems, as on VNI 28 between NVE A and NVE C. But traffic on VNI
35 between NVE A and NVE C experiences problems, for example,
excessive packet loss.
The first case can be detected and investigated using any VNI value,
whether it connects tenant systems or not; however, to conform to
REQ#4 (Section 2) OAM test packets SHOULD be transmitted on a VNI
that doesn't have any tenants. Such a Geneve tunnel is dedicated to
Mirsky, et al. Expires 28 February 2025 [Page 5]
Internet-Draft OAM in GENEVE August 2024
carrying only control and management data between the tunnel
endpoints, hence it is referred to as a Geneve control channel and
that VNI is referred to as the Management VNI. A configured VNI MAY
be used to identify the control channel, but it is RECOMMENDED that
the default value 1 be used as the Management VNI. Encapsulation of
test packets using the Management VNI is discussed in Section 2.2.
The control channel of a Geneve tunnel MUST NOT carry tenant data.
As no tenants are connected using the control channel, a system that
supports this specification, MUST NOT forward a packet received over
the control channel to any tenant. A packet received over the
control channel MAY be forwarded if and only if it is sent onto the
control channel of the a concatenated Geneve tunnel.
MB> The sentence above is hard to parse. I guess there are a couple of cases:
- forward to a concatenated Geneve tunnel.
- terminate locally.
Also, why is the above a 'MAY' and not a 'MUST'? Isn't it the case that if
it is forwarded, it MUST only be
forwarded on the management VNI of a concatenated Geneve tunnel. Else, it
MUST be terminated locally?
The Management
VNI SHOULD be terminated on the tenant-facing side of the Geneve
encap/decap functionality, not the DC-network-facing side (per
definitions in Section 4 of [RFC8014]) so that Geneve encap/decap
functionality is included in its scope. This approach causes an
active OAM packet, e.g., an ICMP echo request, to be decapsulated in
the same fashion as any other received Geneve packet. In this
example, the resulting ICMP packet is handed to NVE's local
management functionality for the processing which generates an ICMP
echo reply. The ICMP echo reply is encapsulated in Geneve as
specified in Section 2.2. for forwarding back to the NVE that sent
the echo request. One advantage of this approach is that a repeated
ping test could detect an intermittent problem in Geneve encap/decap
hardware, which would not be tested if the Management VNI were
handled as a "special case" at the DC-network-facing interface.
MB> please expand 'encap/decap' to 'encapsulation / decapsulation'
The second case is when a test packet is transmitted using the VNI
value associated with the monitored service flow. By doing that, the
test packet experiences network treatment as the tenant's packets.
Details of that use case are outside the scope of this specification.
2.2. OAM Encapsulation in Geneve
Active OAM over a Management VNI in the Geneve network uses an IP
encapsulation. Protocols such as BFD [RFC5880] or STAMP [RFC8762]
MB> suggest changing to 'BFD [RFC5880] and STAMP [RFC8762] since both can use
UDP transport.
use UDP transport. The destination UDP port number in the inner UDP
header (Figure 2) identifies the OAM protocol. This approach is
well-known and has been used, for example, in MPLS networks
[RFC8029]. To use IP encapsulation for an active OAM protocol the
Protocol Type field of the Geneve header MUST be set to the IPv4
(0x0800) or IPv6 (0x86DD) value.
s/active OAM protocol the / active OAM protocol, the
[snip]
5. Security Considerations
As part of a Geneve network, active OAM inherits the security
considerations discussed in [RFC8926]. Additionally, a system MUST
provide control to limit the rate of Geneve OAM packets punted to the
Geneve control plane for processing in order to avoid overloading
that control plane.
OAM in GENEVE packets uses the General TTL Security Mechanism
[RFC5082] and any packet received with an inner TTL / Hop Count other
than 255 MUST be discarded.
MB> I suggest adding a ',' after [RFC5082].
[snip]
Appendix A. Additional Considerations for OAM Encapsulation Method in
Geneve
MB> Do we still need this appendix? I am not sure this history adds value to a
standards track protocol document.
I suggest removing it.
Several other options for OAM encapsulation were considered. Those
are listed in the Appendix solely for informational purposes. These
options were discarded in favor of the approach described in the main
body of this document.
A Protocol Type field might be used to demultiplex active OAM
protocols directly. Such method avoids the use of additional
intermediate header but requires that each active OAM protocol be
assigned unique identifier from the Ether Types registry maintained
by IANA.
The alternative to using the Protocol Type directly is to use a shim
that, in turn, identifies the OAM Protocol and, optionally, includes
additional information. [RFC5586] defines how the Generic Associated
Channel Label (GAL) can be used to identify that the Associated
Channel Header (ACH), defined in [RFC4385], immediately follows the
Bottom-of-the-Stack label. Thus, the MPLS Generic Associated Channel
can be identified, and protocols are demultiplexed based on the
Channel Type field's value. Number of channel types, e.g., for
continuity check and performance monitoring, already have been
defined and are listed in IANA MPLS Generalized Associated Channel
Types (including Pseudowire Associated Channel Types) registry. The
value of the Protocol Type field in the Geneve header MUST be set to
MPLS to use this approach. The Geneve header MUST be immediately
followed by the GAL label with the S flag set to indicate that GAL is
the Bottom-of-the-stack label. Then ACH MUST follow the GAL label
and the value of the Channel Type identifies which of active OAM
protocols being encapsulated in the packet.
_______________________________________________
nvo3 mailing list -- nvo3@ietf.org
To unsubscribe send an email to nvo3-le...@ietf.org
