Hi, Greg, Adding the IPPM mailing list, since you reference it below, and point to RFC 7799.
Please see inline. > On Apr 17, 2019, at 3:00 PM, Greg Mirsky <[email protected]> wrote: > > Hi Carlos, > thank you for sharing your view on the design of the VXLAN-GPE protocol. > Please find my comments in-line tagged GIM>>. > > Regards, > Greg > > On Fri, Apr 12, 2019 at 5:23 AM Carlos Pignataro (cpignata) > <[email protected]> wrote: > 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. > GIM>> It is a very unexpected statement from you, I would tell you ‘expect the unexpected’, but that is not the case here... :-) If you actually read my statement, you will see "IAOM is not an OAM *packet*.” New emphasis added — it is _not_ *an OAM packet*. I stand by it. It’s an augmented data packet of interest. > one of the co-authors of draft-ietf-ippm-ioam-data where the first paragraph > of the Introduction section defines iOAM as Hybrid Type 1 OAM, according to > RFC 7799 classification: This is still quite consistent with that definition, which I recommend you re-read: RFC 7799 is about metrics and methods, not packet definitions. You will see that Active methods include a “dedicated measurement packet stream”. “Active Methods generate packet streams.” However, Hybrid Type I leverages “Augmentation or modification of the stream of interest" Following your logic, if you change a packet field such as TTL/HL to provide packet coloring, do you need to set the O-bit? > IOAM is to complement > mechanisms such as Ping or Traceroute, or more recent active probing > mechanisms as described in [I-D.lapukhov-dataplane-probe]. In terms > of "active" or "passive" OAM, "in-situ" OAM can be considered a > hybrid OAM type. While no extra packets are sent, IOAM adds > information to the packets therefore cannot be considered passive. > In terms of the classification given in [RFC7799] IOAM could be > portrayed as Hybrid Type 1. > > > • 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. > GIM>> Of course, use of the well-known port number, usually it is UDP > destination port, is one of the methods to demultiplex protocols. This method > is broadly used, for example, in MPLS OAM. But this method has some > disadvantages that were pointed out in the discussion of BFD over GENEVE in > Prague by David Black (the last presentation in the minutes): > David: I want the BFD header to be as close to the thing whose liveness I'm > testing. The more headers you add in the middle, the more ways there are to > break BFD without breaking the forwarding engine. The further away I move BFD > from the chunk of hardware's liveness I care about, the more opportunities > are for BFD and the hardware to not to tell me the same thing. > Theory and practice match in theory, less so in practice — unless you are planning to update RFC 5881. This can be argued both ways (e.g., better to have common handlers, etc.), but I take no position. I do say that in presence of deployed OAM encapsulations, there’s no basis for your your comment about defining a protocol type for “Performance Monitoring” as a protocol... > > > • 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. > GIM>> Should that, i.e., OAM in NSH or immediately following NSH be signaled > using SFC NSH methods that are already defined in > draft-ietf-sfc-multi-layer-oam? Non sequitur — I do not follow what signaling has to do with the conversation, nor how that draft might be relevant. > Using the server layer, as you've suggested, seems as layer violation. > This is a funny statement — NVO3 is a layer violation :-) So are Pseudowires. Please do not take this statement too seriously, it is not inviting discussion. > > • 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. > GIM>> When IP/UDP encapsulation is used for OAM, there's no, in my opinion, > any need to use the O-bit. The destination IP address must be as described in > RFC 8029 or RFC 5884 and the demultiplexing is done based on the destination > UDP port number. Clearly, O-bit is unnecessary if IP/UDP encapsulation for > OAM being used. > Fortunately, bit usage is a matter of definition and not opinion :-) Kind regards, Carlos. > > 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
