Hi Greg, it depends on the individual encapsulation, i.e. the parent protocol used. IOAM data encapsulation depends on what the parent protocol offers as encapsulation mechanism. As such, you’d depend on the procedures used by the parent protocol. Let’s consider two examples Geneve and NSH: For Geneve (draft-brockners-ippm-ioam-geneve-00) we use the “option class” mechanism to carry IOAM data, i.e. Geneve’s mechanism to carry meta data. Getting to the payload in a setup with IOAM data within the Geneve header is no different than a Geneve setup without IOAM, assuming that the Geneve implementation supports Geneve option classes. Check out draft-ietf-nvo3-geneve for the Geneve header. For NSH the suggestion in draft-brockners-sfc-ioam-nsh-01 is to use the “NSH Next Protocol” mechanism in NSH (see e.g. RFC 8300, section 9.1.6). Re-specifying the encap mechanism of the base protocol in a specification which only leverages the base protocol will do more harm than good. It should be avoided because it could only lead to confusion. All the IOAM encap drafts clearly reference the parent protocol encap mechanism – so an implementer will naturally refer to the base specification.
All that said: What are you trying to point out? It seems that you’re pickup up the discussion about the pros and cons on whether to use protocol meta-data or the “next header” approach. The SFC WG discussed this at length in the last meeting in London and you actively participated in it. The “next header” approach allows for a more efficient implementation in hardware (fewer nested structures/lookups) at the expense of requiring the each node to have a basic understanding of IOAM (at least the type and length fields – so that you could skip past it), whereas the “leverage meta-data type-2” approach leads to more complicated lookup operations (the location of MD Type 2 isn’t fixed) as well as constrain the amount of data to be carried to 256 octets. See also section 4.1 in draft-brockners-sfc-ioam-nsh-01. You remember that from the “hum” in the room that the chairs initiated (which still needs confirmation on the list – which we do right now), there seems to be a preference to either go with the “next header approach” (as per draft-brockners-sfc-ioam-nsh-01) or to document the next header approach and the MD-Type2 approach. We do care about efficient implementation – this is what we learned from several IOAM implementations by now, and which is why we have quite a few authors from companies which drive silicon implementations on the IOAM drafts – see also John Lemon’s email yesterday. We’d greatly appreciate thoughts from other SFC WG members on their preference of using either the “NSH next protocol” approach or the “MD Type2” meta-data based approach. Thanks, Frank From: Greg Mirsky <[email protected]> Sent: Donnerstag, 19. April 2018 19:27 To: Frank Brockners (fbrockne) <[email protected]> Cc: IETF IPPM WG <[email protected]>; NVO3 <[email protected]>; Service Function Chaining IETF list <[email protected]>; [email protected] Subject: Re: [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London Hi Frank, thank you for your expedient response. Yes, clarification and consistent terminology, of course as different encapsulations allow that, will help. What I'm looking through the iOAM encapsulation drafts is the answer to this question How a system that is not using iOAM can get to the data payload that follows the iOAM message? Is there the field in the iOAM shim that allows the system to skip over the iOAM message (by iOAM message I mean iOAM shim and iOAM data)? Would such system be required to parse other than iOAM shim constructs? I couldn't find this scenario being discussed in any of iOAM encapsulation drafts. Have I missed it? Regards, Greg On Thu, Apr 19, 2018 at 9:54 AM, Frank Brockners (fbrockne) <[email protected]<mailto:[email protected]>> wrote: 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”. Frank From: Greg Mirsky <[email protected]<mailto:[email protected]>> Sent: Donnerstag, 19. April 2018 18:15 To: Frank Brockners (fbrockne) <[email protected]<mailto:[email protected]>> Cc: IETF IPPM WG <[email protected]<mailto:[email protected]>>; NVO3 <[email protected]<mailto:[email protected]>>; Service Function Chaining IETF list <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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? Regards, Greg On Wed, Apr 11, 2018 at 3:02 AM, Frank Brockners (fbrockne) <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ippm
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
