On Thu, Apr 12, 2018 at 3:31 PM, Mickey Spiegel <mspie...@barefootnetworks.com> wrote: > Tom, > > On Thu, Apr 12, 2018 at 2:46 PM, Tom Herbert <t...@herbertland.com> wrote: >> >> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky <gregimir...@gmail.com> >> wrote: >> > Hi Frank, >> > thank you for sharing your points. Please find my notes in-line and >> > tagged >> > GIM>>. I believe that this is very much relevant to work of other >> > working >> > groups that directly work on the overlay encapsulations in the center of >> > the >> > discussion and hence I've added them to the list. Hope we'll have more >> > opinions to reach the conclusion that is acceptable to all. >> > >> > Regards, >> > Greg >> > >> > On Wed, Apr 11, 2018 at 12:02 PM, Frank Brockners (fbrockne) >> > <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. >> Greg, >> >> I'm missing something here. I looked at the drafts you referenced and >> each of them looks like the overhead for OAM is greater that four >> bytes. In each there is some overhead equivalent to type/length, for >> instance in Geneve four bytes are needed for option class, type, and >> length. Unless the the OAM data is zero length, I don't see how this >> adds up to only four bytes of overhead. > > > The four versus eight bytes just refers to the fields in the four bytes of > IOAM > info, that is common to all IOAM options. Beyond that, there are IOAM option > specific fields. For example if doing one of the IOAM trace options, there > are > four bytes of trace option header, including the IOAM-trace-type, NodeLen, > Flags, and RemainingLen fields. These are followed by the node data list > containing the per hop IOAM information. > All of that and people are worried about having four extra bytes of overhead? :-)
How big are these encapsulation headers in data packets going to be? Tom > In looking at the OOAM header content, it has nothing to do with any of the > IOAM information after the first four bytes. It contains another variant of > the > information in the first four bytes of IOAM info, spread out over eight > bytes. > >> >> Tom >> >> > >> > GIM>> The difference in four octets is because OOAM Header: >> > >> > provides more flexibility, e.g. Flags field and Reserved fields; > > > The flags field only has one defined flag at the moment, for a timestamp > block. For IOAM trace we need per hop timestamps, which the timestamp > block cannot address, i.e. the timestamp block is redundant for IOAM. > >> >> > supports larger OAM packets than iOAM header; > > > For IOAM purposes, 1020 octets is more than enough. > >> >> > is future proof by supporting versioning (Version field). > > > IMO, taking the first two bits of the IOAM-Type to define a Version field > would be a good thing. This does not require adding four more bytes of > overhead. 64 IOAM-Types is more than enough. > >> >> >> >> >> * 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. >> > >> > GIM>> May I ask which encapsulations supported by the implementations >> > you >> > refer to. Until very recently all iOAM proposals were to use meta-data >> > TLV >> > in, e.g. Geneve and NSH. And if these or some of these implementations >> > already updated to the newly proposed iOAM shim, I don't see problem in >> > making them use OOAM Header. Would you agree? >> > >> >> >> >> * 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. >> > >> > GIM>> The first paragraph of the Introduction section states: >> > New protocols that support overlay networks like VxLAN-GPE >> > [I-D.ietf-nvo3-vxlan-gpe], GUE [I-D.ietf-nvo3-gue], Geneve >> > [I-D.ietf-nvo3-geneve], BIER [I-D.ietf-bier-mpls-encapsulation], and >> > NSH [I-D.ietf-sfc-nsh] support multi-protocol payload, e.g. >> > Ethernet, IPv4/IPv6, and recognize Operations, Administration, and >> > Maintenance (OAM) as one of distinct types. That ensures that >> > Overlay OAM (OOAM)packets are sharing fate with Overlay data packet >> > traversing the underlay. >> > I'm updating the OOAM Header draft and along with cleaning nits will >> > update >> > reference to GUE. I think that the list and the statemnt are quite clear >> > in >> > identifying the scope of networks that may benefit from using not only >> > common OOAM Header but common OOAM mechanisms, e.g. Echo Request/Reply. >> > >> >> 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 >> >> i...@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ippm >> >> >> > >> > >> > _______________________________________________ >> > Int-area mailing list >> > int-a...@ietf.org >> > https://www.ietf.org/mailman/listinfo/int-area >> > >> >> _______________________________________________ >> ippm mailing list >> i...@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm > > _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
