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]> 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] > https://www.ietf.org/mailman/listinfo/ippm > >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
