Re: [ippm] [SUSPICIOUS] Re: [nvo3] Comments on draft-ietf-nvo3-vxlan-gpe

["Carlos Pignataro (cpignata)" <[e-mail]>]

Dear Greg,

As an innocent bystander, I have no dog in this fight (i.e., no personal stake in the issue you keep raising), but you seem to be making a rather strong accusation: “the updates the editors have been making without the WG agreeing to that”. You talk about plural “updates”, and you use a continued tense of “have been making” (implying more than once, or repeatedly).

Looking at the diffs from draft-ietf-nvo3-vxlan-gpe-00 to draft-ietf-nvo3-vxlan-gpe-07:
https://www6.ietf.org/rfcdiff/?url1=draft-ietf-nvo3-vxlan-gpe-00&url2=draft-ietf-nvo3-vxlan-gpe-07

I see no changes in the definition of the O-bit.

I will stop replying to this thread with this final note, and let the Editors of that document answer your explicit call – however, for the benefit of clarity for the WG, what specific updates you refer to?

You mention “the last two versions” of VXLAN-GRE.
05 -> 06: https://www6.ietf.org/rfcdiff/?url1=draft-ietf-nvo3-vxlan-gpe-05&url2=draft-ietf-nvo3-vxlan-gpe-06
I see no content changes – only updating references and spaces

06 -> 07: https://www6.ietf.org/rfcdiff/?url1=draft-ietf-nvo3-vxlan-gpe-06&url2=draft-ietf-nvo3-vxlan-gpe-07
Definition of Next Protocol range for shim headers, and assignment of a Next Protocol value for the IOAM shim.

Which one is it?

Carlos.


From: Greg Mirsky <[e-mail]>
Date: Wednesday, April 17, 2019 at 8:49 PM
To: "Carlos Pignataro (cpignata)" <[e-mail]>
Cc: NVO3 <[e-mail]>, "[e-mail]" <[e-mail]>, IETF IPPM WG <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [SUSPICIOUS] Re: [nvo3] Comments on draft-ietf-nvo3-vxlan-gpe

Hi Carlos,
thank you for the discussion.
As the VXLAN-GPE is on the Informational track, there may be little point to discuss it. But as the draft has been adopted by NVO3 WG, I'm curious about the updates the editors have been making without the WG agreeing to that. I'm looking forward to hearing from any of the editors of VXLAN-GPE about the updates in the last two versions. Also, hope editors of the draft will find time to reply to my questions and consider my comments.

Regards,
Greg

On Wed, Apr 17, 2019 at 5:18 PM Carlos Pignataro (cpignata) <[e-mail]<mailto:[e-mail]>> wrote:
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 <[e-mail]<mailto:[e-mail]>> 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) <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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) <[e-mail]<mailto:[e-mail]>> wrote:
> > Greg,
> >
> > You seem to be confusing and mixing things up.
> >
> > Please see inline.
> >
> > > On Apr 12, 2019, at 2:50 AM, Greg Mirsky <[e-mail]<mailto:[e-mail]>> 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, [e-mail]<mailto:[e-mail]>
> >
> > “Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."
> >
> > > Regards,
> > > Greg
> > > _______________________________________________
> > > nvo3 mailing list
> > > [e-mail]<mailto:[e-mail]>
> > > 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
> [e-mail]<mailto:[e-mail]>
> 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