Hi Greg,

good catch – there is a bit of loose language in some of the drafts. We’ll make 
things crisper in the next rev. Note that there is no generic “IOAM header” but 
that definition is always within the context of a particular encapsulation 
protocol. draft-weis-ippm-ioam-gre-00 already has a definition of the IOAM 
header (for GRE) – see section 3. For the other drafts, we use language like 
“The IOAM related fields in VXLAN-GPE are defined as follows” or “The fields 
related to the encapsulation of IOAM data fields in Geneve are defined as 
follows”, i.e. the information that is required to perform the encapsulation 
into the parent protocol, along with the actual IOAM data fields. Moving 
forward, we can be crisper and split things into an “encapsulation dependent 
part” and a “data part”.


From: Greg Mirsky <gregimir...@gmail.com>
Sent: Donnerstag, 19. April 2018 18:15
To: Frank Brockners (fbrockne) <fbroc...@cisco.com>
Cc: IETF IPPM WG <i...@ietf.org>; NVO3 <n...@ietf.org>; Service Function 
Chaining IETF list <s...@ietf.org>; int-area@ietf.org
Subject: Re: [ippm] encapsulation of IOAM data in various protocols - follow up 
from WG discussion in London

Hi Frank, et. al,
we have a very good discussion, thank you. I have a question and appreciate 
your consideration:

  *   encapsulation documents refer to IOAM HDR, its length is reflected in the 
field labeled either Length or IOAM HDR len. But I cannot find the definition 
of IOAM HDR. What is the IOAM HDR?


On Wed, Apr 11, 2018 at 3:02 AM, Frank Brockners (fbrockne) 
<fbroc...@cisco.com<mailto:fbroc...@cisco.com>> wrote:
Back at the IPPM meeting in London, we discussed several drafts dealing with 
the encapsulation of IOAM data in various protocols 
(draft-brockners-ippm-ioam-vxlan-gpe-00, draft-brockners-ippm-ioam-geneve-00, 
draft-weis-ippm-ioam-gre-00). One discussion topic that we decided to take to 
the list was the question on whether draft-ooamdt-rtgwg-ooam-header could be 
leveraged.  After carefully considering draft-ooamdt-rtgwg-ooam-header, I came 
to the conclusion that the “OOAM header” does not meet the needs of IOAM:
* Efficiency: IOAM adds data to live user traffic. As such, an encapsulation 
needs to be as efficient as possible. The “OOAM header” is 8 bytes long. The 
approach for IOAM data encapsulation in the above mentioned drafts only 
requires 4 bytes. Using the OOAM header approach would add an unnecessary 
overhead of 4 bytes – which is significant.
* Maturity: IOAM has several implementations, which were also shown at recent 
IETF hackathons – and we’re expecting additional implementations to be 
publicized soon. Interoperable implementations need timely specifications. 
Despite the question being asked, the recent thread on OOAM in the NVO3 list 
hasn’t revealed any implementation of the OOAM header. In addition, the thread 
revealed that several fundamental questions about the OOAM header are still 
open, such as whether or how active OAM mechanisms within protocols such as 
Geneve would apply to the OOAM header. This ultimately means that we won’t get 
to a timely specification.
* Scope: It isn’t entirely clear to which protocols the OOAM header would 
ultimately apply to. The way the OOAM header is defined, OOAM uses a 8-bit 
field for “Next Prot”, the next protocol. Some protocols that IOAM data needs 
to be encapsulated into use 16-bits for their next protocol code points. See 
e.g. the GRE encapsulation – as specified in draft-weis-ippm-ioam-gre-00.
With the above in mind, I’d suggest that the WG moves forward with specific 
definitions for encapsulating IOAM data into protocols – per the above 
mentioned drafts.

Regards, Frank

ippm mailing list

Int-area mailing list

Reply via email to