Dear Greg, [Now adding the SFC WG Mailing list since you take us to a different WG again]
Thank you very much for fine-combing with a magnifying glass through all the documents I’m currently co-authoring :-) It is refreshing to see that the only issues you find are non-issues, and your questions easy to re-answer :-) At this point I am a bit at a loss of what your point is, or what you are trying to prove bending text. Are you coding, deploying, or testing IOAM on NSH without data packets on VXLAN-GPE over IP? NSH is data as far as VXLAN-GPE is concerned. IOAM shimmed in NSH is orthogonal to IOAM shimmed in VXLAN-GPE. I feel this discussion about the O-bit already took place once or twice. Kind Regards, — Carlos Pignataro PS: The Evil bit is defined for IPv4, should we therefore also define it here? > On Apr 17, 2019, at 5:54 PM, Greg Mirsky <[email protected]> wrote: > > Hi Carlos, > to add another quote from the draft-ietf-sfc-ioam-nsh that you've > co-authored, > Packets with IOAM data included MUST follow this > definition, i.e. the O bit MUST NOT be set for regular customer > traffic which also carries IOAM data and the O bit MUST be set for > OAM packets which carry only IOAM data without any regular data > payload. > > So, if the only iOAM message is carried in or after an NSH, it is identified > as OAM. And, by your own example in the earlier note, so should VXLAN-GPE. > > Regards, > Greg > > On Wed, Apr 17, 2019 at 12:44 PM Carlos Pignataro (cpignata) > <[email protected]> wrote: > 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://secure-web.cisco.com/1j-jr64yh2D8yO92ibcqaN-H98ZCP3lQdHmsYPsH8lkjsa4WlJ4kg3W4HL8qT25rCVittT5bFQox__OnSknV5w_wW69FvUhXkxqxKhi9MCiy5oH-JTucXN_7FK85q7jD-qEwRM5IXY68_Vfeb_XI2rKxyzwVsG_06KTGF09Bw9oHAOXUNFcdCw_oon_eruUhRPtdwLc9UQNz2ThYP8ysf2pr64VU04VjMKmGwqYvzzyAsLTEbHrs7GVCqphT58T0st78_968rM5MKFLk7EiWBj7gZPm_rDeBf63gUtxkcj-w8XybJiiO2tcFaeoAL_8m-ZT5L9-1VK4wZkHmR5C_Ldg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnvo3 > > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://secure-web.cisco.com/1j-jr64yh2D8yO92ibcqaN-H98ZCP3lQdHmsYPsH8lkjsa4WlJ4kg3W4HL8qT25rCVittT5bFQox__OnSknV5w_wW69FvUhXkxqxKhi9MCiy5oH-JTucXN_7FK85q7jD-qEwRM5IXY68_Vfeb_XI2rKxyzwVsG_06KTGF09Bw9oHAOXUNFcdCw_oon_eruUhRPtdwLc9UQNz2ThYP8ysf2pr64VU04VjMKmGwqYvzzyAsLTEbHrs7GVCqphT58T0st78_968rM5MKFLk7EiWBj7gZPm_rDeBf63gUtxkcj-w8XybJiiO2tcFaeoAL_8m-ZT5L9-1VK4wZkHmR5C_Ldg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
