Hi Tom, I'll let Frank answer your question as it is on iOAM, not OOAM. Regards, Greg
On Thu, Apr 12, 2018 at 11:53 PM, Tom Herbert <[email protected]> wrote: > On Thu, Apr 12, 2018 at 2:50 PM, Greg Mirsky <[email protected]> > wrote: > > Hi Tom, > > could you please mention which drafts, iOAM or OOAM, you refer to. Please > > note, that OOAM supports both active and hybrid OAM methods, while iOAM > only > > the latter. > > Section 3 of draft-brockners-ippm-ioam-geneve-00 for instance. > > > > > Regards, > > Greg > > > > On Thu, Apr 12, 2018 at 11:46 PM, Tom Herbert <[email protected]> > wrote: > >> > >> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky <[email protected]> > >> 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) > >> > <[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. > >> 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. > >> > >> Tom > >> > >> > > >> > GIM>> The difference in four octets is because OOAM Header: > >> > > >> > provides more flexibility, e.g. Flags field and Reserved fields; > >> > supports larger OAM packets than iOAM header; > >> > is future proof by supporting versioning (Version field). > >> >> > >> >> * 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 > >> >> [email protected] > >> >> https://www.ietf.org/mailman/listinfo/ippm > >> >> > >> > > >> > > >> > _______________________________________________ > >> > Int-area mailing list > >> > [email protected] > >> > https://www.ietf.org/mailman/listinfo/int-area > >> > > > > > >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
