Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

[Greg Mirsky <[e-mail]>]

Hi Jesse,
I appreciate the work you've put into responding to my comments, but I
don't feel that the new proposed text regarding the O-bit addresses them.
Looking forward to the discussion in Bangkok.

Regards,
Greg

On Fri, Oct 26, 2018 at 11:59 AM Jesse Gross <[e-mail]> wrote:

> Hi Greg,
>
> I believe that the rewording of the text previously sent out addresses
> the bulk of your concerns in a balanced way. It both clarifies the
> role of the payload and leaves flexibility for specifying OAM to
> additional drafts to flesh out. As far as going further and actually
> removing the bit from the base specification, I'm not comfortable
> making that change at this point in time. This bit has existed in the
> protocol for quite some time and I personally don't see that there is
> consensus within the working group for making the change that you are
> proposing. I think we need to table this discussion for now unless
> there is further support for modifying it.
>
> Jesse
>
> On Thu, Oct 25, 2018 at 8:35 PM Greg Mirsky <[e-mail]> wrote:
> >
> > Hi Jesse,
> > I think that directing the O-bit to identify the presence of "a control
> message" would require the definition of the control message or, at least,
> some examples. Another question may arise to the interpretation of "packet
> contains a control message". Can other, non-control messages, be present in
> the packet with O-bit set? I can only re-state my proposal I've shared
> earlier:
> >
> > release O-bit to Reserved pool
> > defer discussion of OAM in Geneve to the future work.
> >
> > Regards,
> > Greg
> >
> > On Thu, Oct 25, 2018 at 3:24 PM Jesse Gross <[e-mail]> wrote:
> >>
> >> Hi Matthew,
> >>
> >> Thank you for the suggestion. We've been thinking about it and believe
> >> that this can address everyone's concerns. The description of this bit
> >> already references control messages rather than OAM, so that name
> >> seems like a more accurate reflection of its purpose. It also allows
> >> the flexibility for OAM to be specified separately by not commingling
> >> the two concepts, as Greg mentioned.
> >>
> >> We will edit the text to read:
> >>
> >>    O (1 bit):  Control packet.  This packet contains a control message.
> >>       Control messages are sent between
> >>       Geneve endpoints.  Endpoints MUST NOT forward the payload and
> >>       transit devices MUST NOT attempt to interpret or process it.
> >>       Since these are infrequent control messages, it is RECOMMENDED
> >>       that endpoints direct these packets to a high priority control
> >>       queue (for example, to direct the packet to a general purpose CPU
> >>       from a forwarding ASIC or to separate out control traffic on a
> >>       NIC).  Transit devices MUST NOT alter forwarding behavior on the
> >>       basis of this bit, such as ECMP link selection.
> >>
> >> Jesse
> >>
> >> On Fri, Oct 19, 2018 at 3:26 AM Bocci, Matthew (Nokia - GB)
> >> <[e-mail]> wrote:
> >> >
> >> > Greg, Jesse
> >> >
> >> >
> >> >
> >> > Is there any value in renaming the O bit to something more generic to
> indicate that it is really acting as an exception mechanism to tell the
> terminating NVE to process the packet in its control plane, rather than
> forward it or imply something about the protocol. It seems that its
> function is more aligned with the GAL or ‘0001b’ nibble in the PW-ACH.
> >> >
> >> >
> >> >
> >> > Matthew
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > From: Greg Mirsky <[e-mail]>
> >> > Date: Thursday, 18 October 2018 at 16:21
> >> > To: "[e-mail]" <[e-mail]>
> >> > Cc: "Bocci, Matthew (Nokia - GB)" <[e-mail]>, NVO3 <
> [e-mail]>, "[e-mail]" <
> [e-mail]>
> >> > Subject: Re: [nvo3] Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt
> >> >
> >> >
> >> >
> >> > Hi Jesse,
> >> >
> >> > thank you for kind consideration of my comments and I'm looking
> forward to the updated definition of the O-bit flag. In the meantime, I'll
> note that using the flag to indicate that the payload, e.g., Ethernet frame
> of IP packet, contains OAM message, e.g., CCM or BFD, seems unnecessary to
> me. Consider that Ethernet uses EtherTypeand IP uses port number to
> demultiplex OAM. I imagine that the egress Geneve node will terminate a
> packet and realize that the payload, the frame or the packet, is addressed
> to it. Then the type will be properly identified and acted upon. In MPLS we
> use IP/UDP encapsulation for BFD and Ping, and over VXLAN have to add
> Ethernet header to IP/UDP encapsulated BFD control message. At the same
> time, MPLS label stack may include GAL special label that indicates that
> the label stack is followed by the Generic Associated Channel header, which
> includes the Channel Type field to demultiplex the payload. In this case,
> IP/UDP encapsulation is not used.
> >> >
> >> > Apologies if my example came out too wordy. My point is that if
> Geneve identifies the payload as OAM, there's no an apparent benefit in
> having the payload encapsulated in one of the network layers.
> >> >
> >> >
> >> >
> >> > Regards,
> >> >
> >> > Greg
> >> >
> >> >
> >> >
> >> > On Wed, Oct 17, 2018 at 2:14 PM Jesse Gross <[e-mail]> wrote:
> >> >
> >> > On Wed, Oct 17, 2018 at 1:32 PM Greg Mirsky <[e-mail]>
> wrote:
> >> > > On Wed, Oct 17, 2018 at 11:31 AM Jesse Gross <[e-mail]>
> wrote:
> >> > >>
> >> > >> Greg,
> >> > >>
> >> > >> The 'O' bit does not override or interact with the Protocol Type
> >> > >> field, so there is no issue with precedence. It is possible to
> >> > >> implement OAM on Geneve using options, in which case the payload
> could
> >> > >> be a stub of a packet to ensure consistent behavior between OAM and
> >> > >> data packets as has been done with other protocols. In this
> situation,
> >> > >> the Protocol Type would still indicate the type of the stub packet
> as
> >> > >> usual. It is also possible to implement OAM using the payload of
> the
> >> > >> packet as you describe and the Protocol Type would indicate that
> using
> >> > >> an EtherType assigned for this purpose.
> >> > >
> >> > > GIM>> If understand you correctly, O-bit indicates presence of OAM
> TLV(s) not the type of the payload. But, in my opinion, that is not how the
> O-bit is currently defined:
> >> > >  O (1 bit):  OAM packet.  This packet contains a control message
> instead of a data payload.
> >> > > The definition is the definition of a packet in active OAM per RFC
> 7799 but your description suggests that the O-bit only characterizes the
> content of TLVs, not of the payload of the Geneve packet. Would you agree?
> >> >
> >> > No, I am not saying that the bit indicates the presence of OAM TLVs.
> >> > TLVs are always processed in the usual way by looking at the Opt Len
> >> > field and the individual TLV header fields. The 'O' bit does not
> >> > change this, similar to how it does not change the Protocol Type
> >> > field.
> >> >
> >> > I think we can rework the first sentence to simply say something like
> >> > "This packet is a control message." As you point out, the text about
> >> > "instead of a data payload" is confusing because the bit does not
> >> > impact the processing of the payload.
> >> >
> >> > > GIM>> In addition, yes, TLV may be used to implement OAM but, as I
> believe, it would not support all requirements usually set for OAM. For
> example, because the length of the Value field is limited TLV could not
> support testing with synthetic packets of large size. You can find more
> details in draft-mirsky-rtgwg-oam-identify.
> >> >
> >> > This is a good example of a use for a stub of packet that I mentioned
> >> > earlier. However, that does not mean that the OAM instructions also
> >> > need to be in the payload. They can still be in a TLV and then a
> >> > synthetic payload is present. I believe that this is the cleanest
> >> > implementation because it keeps everything consistent between OAM and
> >> > non-OAM packets and active and passive OAM.
> >> >
> >> > Although I prefer the use of TLVs for OAM, it is possible to implement
> >> > OAM using a shim layer in the payload as well - Geneve has the
> >> > flexibility to do it both ways and the behavior of the 'O' bit remains
> >> > the same.
> >> >
> >> > >> In either case, the meaning of the 'O' bit is the same and it only
> >> > >> affects the behavior of endpoint devices processing OAM. Most
> devices
> >> > >> are oblivious to this and will simply use the Protocol Type field
> to
> >> > >> process the payload as usual. The appropriate behavior for 'O' bit
> >> > >> flagged packets is described in the draft:
> >> > >>
> >> > >>       Endpoints MUST NOT forward the payload and
> >> > >>       transit devices MUST NOT attempt to interpret or process it.
> >> > >>       Since these are infrequent control messages, it is
> RECOMMENDED
> >> > >>       that endpoints direct these packets to a high priority
> control
> >> > >>       queue (for example, to direct the packet to a general
> purpose CPU
> >> > >>       from a forwarding ASIC or to separate out control traffic on
> a
> >> > >>       NIC).  Transit devices MUST NOT alter forwarding behavior on
> the
> >> > >>       basis of this bit, such as ECMP link selection.
> >> > >
> >> > > GIM>> Could you please clarify what is considered as "transit
> devices"? Is it node in Geneve layer or is it a node in the underlay
> network. If it is the latter, then the requirement is just re-stating layer
> preservation. If it is the former, then it appears to prohibit tracing OAM
> operation on multi-segment Geneve tunnel.
> >> >
> >> > The draft defines a transit device as:
> >> >
> >> > Transit device.  A forwarding element along the path of the tunnel
> >> >    making up part of the Underlay Network.  A transit device MAY be
> >> >    capable of understanding the Geneve packet format but does not
> >> >    originate or terminate Geneve packets.
> >> >
> >> > i.e. it is a node in the underlay.
> >> >
> >> > >> The 'O' bit does not otherwise change the interpretation of the
> packet.
> >> > >
> >> > > GIMM> I disagree. At least as the curreent definition of the O-bit
> states - O-bit defines the payload of the Geneve packet.
> >> >
> >> > I think by changing the first sentence as I suggested above, we can
> >> > correct this. The intention is that the 'O' bit only has the effects
> >> > quoted above.
>