Hi John, I don't argue with the importance of interoperable implementations (though early implementations accept the risk of non-compliance with the final specification, for example, SFC NSH). At the same time, I don't think that mere fact of existing implementation should cancel discussion of technical characteristics of the proposed approaches to hybrid OAM.
Regards, Greg On Thu, Apr 19, 2018 at 9:09 AM, John Lemon <[email protected]> wrote: > I never saw a response to the request for a pointer to an OOAM > implementation, so I assume none exist. > > I've seen several good arguments for why the existing IOAM implementation, > for which several implementations exist, meets the needs for IOAM. > > I think it is time to put to bed the request to examine merging OOAM and > IOAM. Let's move forward with IOAM and not hold it up. > > Respectfully, John > > > On Thu, Apr 12, 2018 at 11:06 AM, Frank Brockners (fbrockne) < > [email protected]> wrote: > >> Hi Greg, >> >> >> >> thanks – and it seems that we’re on the same page with regards to >> efficiency (4 bytes of non-required overhead) and maturity (or lack of) of >> OOAM. >> >> >> >> On the IOAM implementation: There are several implementations of IOAM. >> Some of which have recently been worked on and shown at an IETF hackathon, >> see https://datatracker.ietf.org/meeting/100/materials/slides-10 >> 0-hackathon-sessa-in-situ-oam-ioam - where we’ve shown IPv6 and >> VXLAN-GPE with IOAM – on FD.io/VPP as well as on Barefoot Tofino.. You >> probably also remember the Netronome/Broadcom demo - >> https://www.youtube.com/watch?v=j9FbD4a3F4E . >> >> Below you seem to be specifically referring to the IOAM open source >> implementation in FD.io/VPP: There are protocol encapsulations for >> VXLAN-GPE, NSH, and IPv6 implemented in FD.io/VPP. The current code uses >> the “next header approach” for VXLAN-GPE and it leverages MD-Type 2 for >> NSH. As you’re well aware, there the discussion in SFC whether to use >> MD-Type 2 or next header encapsulating IOAM data in NSH isn’t yet settled, >> hence we’ll refrain from updating the code until SFC WG has come to a >> conclusion. >> >> >> >> Could you provide a pointer to an OOAM implementation? >> >> >> >> Thanks, >> >> Frank >> >> >> >> *From:* Greg Mirsky <[email protected]> >> *Sent:* Donnerstag, 12. April 2018 18:54 >> *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 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. >> >> 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 >> <https://tools.ietf.org/html/draft-ooamdt-rtgwg-demand-cc-cv-03>. >> >> >> >> 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 >> >> >> >> _______________________________________________ >> 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
