Subject: Re: [ippm] Vote at IPPM session

From: "ram krishnan" <[email-masked]>
Date: Tue, 4 Apr 2017 21:14:18 -0700

Very good in person discussion on the topic of microservices with Frank and
its applicability to inband-oam, please see summary and next steps below. 
 
IETF 98 NFVRG slides on this topic --
https://www.ietf.org/proceedings/98/slides/slides-98-nfvrg-sessa-01-microser
vices-on-the-edge-the-infrastructure-impact-04.pdf -- most relevant would be
the slides on HW Acceleration Resource Modelling. A low-latency RDMA based
interconnect is critical to the success of microservice based deployments
for delivering low-latency services. In this context, in-band monitoring of
RDMA based lossless protocols such as RoCE is needed. These lossless
protocols use priority flow control (PFC) besides congestion management
techniques such as ECN. From an underlay switch monitoring perspective, an
important additional data field which would be needed is the switch buffer
pool(s) - for example Broadcom Trident family has a single buffer pool
whereas the Tomahawk family has multiple buffer pools. In addition, the
relation between the buffer pools utilization and queue depth needs to be
articulated.
 
Plan is to bring the use case and the relevant data fields in the upcoming
version of the draft.
 
Thanks,
Ramki
 
Thanks for the suggestions and comments. We've posted a new revision of
draft-brockners-inband-oam-data.
https://www.ietf.org/id/draft-brockners-inband-oam-data-04.txt includes
section 3 on Scope, Applicability, and Assumptions, capturing the discussion
we had in the WG meeting and on the list. We've also updated the
introduction to refer to RFC7799 and classify in-situ OAM appropriately as
hybrid, type-1 OAM.
 
For everyone's benefit, here is a quote of the new section 3:
 
3.  Scope, Applicability, and Assumptions
 
   In-situ OAM deployment assumes a set of contraints, requirements, and
   guiding principles which are described in this section.
 
   Scope: This document defines the data fields and associated data
   types for in-situ OAM.  The in-situ OAM data field can be transported
   by a variety of transport protocols, including NSH, Segment Routing,
   VXLAN-GPE, Geneve, IPv6, or IPv4.  Encapsulation details for these
   different transport protocols are outside the scope of this document.
 
   Deployment domain (or scope) of in-situ OAM deployment: IOAM is a
   network domain focused feature, with "network domain" being a set of
   network devices or entities within a single administration.  For
   example, a network domain can include an enterprise campus using
   physical connections between devices or an overlay network using
   virtual connections / tunnels for connectivity between said devices.
   A network domain is defined by its perimiter or edge.  The operator
   of such a domain MUST put provisions in place to ensure that in-situ
   OAM data stays within the specific domain only (i.e., does not leak
   beyond the edge) and consider potential impact of IOAM to ECMP
   processing, path MTU and ICMP message handling.
 
   In-situ OAM control points: IOAM data fields are added to or removed
   from the live user traffic by the devices which form the edge of a
   domain.  Devices within an IOAM domain can update and/or add IOAM
   data-fields.  Domain edge devices can be hosts or network devices.
 
   Traffic-sets that in-situ OAM is applied to: IOAM can be deployed on
   all or only on subsets of the live user traffic.  It SHOULD be
   possible to enable in-situ OAM on a selected set of traffic (e.g.,
   per interface, based on an access control list or flow specification
   defining a specific set of traffic, etc.)  The selected set of
   traffic can also be all traffic.
 
   Encapsulation independence: Data formats for in-situ OAM SHOULD be
   defined in a transport-independent manner.  In-situ OAM applies to a
   variety of encapsulating protocols.  A definition of how IOAM data
   fields are carried by different transport protocols is outside the
   scope of this document.
 
   Layering: If several encapsulation protocols (e.g., in case of
   tunneling) are stacked on top of each other, in-situ OAM data-records
   could be present at every layer.  The behavior follows the ships-in-
   the-night model.
 
   Combination with active OAM mechanisms: In-situ OAM SHOULD be usable
   for active network probing, enabling for example a customized version
   of traceroute.  Decapsulating in-situ OAM nodes may have an ability
   to send the in-situ OAM information retrieved from the packet back to
   the source address of the packet or to the encapsulating node.
 
   Im-situ OAM implementation: The IOAM data-field definitions take the
   specifics of devices with hardware data-plane and software data-plane
   into account.
 
Thoughts/comments? With these changes, are we able to kick-off an adoption
call?
 
Thanks, Frank