Greg, You seem to be confusing and mixing things up.
Please see inline. > On Apr 12, 2019, at 2:50 AM, Greg Mirsky <[email protected]> wrote: > > Dear Editors, et al., > I've read the latest -07 version and would like to share my comments and > questions with you: > • in the earlier version of the draft, the O-bit was introduced and > defined as: > OAM Flag Bit (O bit): The O bit is set to indicate that the packet is an OAM > packet. > At the same time, in the latest version, the new Next Protocol value (0x81) > to identify iOAM Data was introduced. Hence are my questions: > • What must be the value of the O-bit when the value of the Next > Protocol field is iOAM? The O bit “is set to indicate that the packet is an OAM packet”. IAOM is not an OAM packet. Hence, O bit clear if VXLAN-GPE encapsulates a non-OAM packet and adds an IOAM shim. > • Do you plan to define the Next Protocol values for active OAM > protocols, e.g., Echo Request/Reply, BFD, Performance Monitoring? I cannot speak to “plans” (replying as “et al.”, not as “editor”), but I expect OAM documents ought to have those requested, and you do not need necessarily all of those — the nex protocol IPv4 / IPv6 can encapsulate ICMP, UDP/BFD, etc., etc., etc., etc. > • How to interpret the situation when the O-bit value is 1 but the > value of the Next Protocol field is, for example, NSH, i.e.., not any of OAM > protocols? I expect it means there’s OAM within that NSH (sometimes there’s no such things as “OAM Protocols”), or an unhandled OAM protocol. > • I believe that the use of the dedicated OAM flag and the Next > Protocol field for a fixed-size header that cannot include meta-data is > unwarranted and adds unnecessary complexity. Disagree. See example where protocol is IP carrying an OAM packet. > I suggest not to use O-bit in the VXLAN-GPE header and release it into the > Reserved field. I don't see the apparent benefit of using the flag, as the > VXLA-GPE uses the fixed size header and the header cannot carry OAM data in > it. The only role the VXLAN-GPE header must perform, in my opinion, is to > unambiguously identify the payload type that immediately follows the header > as OAM (demultiplexing OAM protocols may be done in OAM Header shim). > Much appreciate your consideration. > Best, — Carlos Pignataro, [email protected] “Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis." > Regards, > Greg > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
