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

[Greg Mirsky <[e-mail]>]

Hi Jesse,
thank you for the very detailed explanation of how authors understand the
role of O-bit and its relationship with an OAM packet. Please find my notes
in-line tagged GIM>>.

Regards,
Greg

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?
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
<https://tools.ietf.org/html/draft-mirsky-rtgwg-oam-identify-00>.

>
> 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 '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.

>
> Jesse
>
> On Mon, Oct 15, 2018 at 6:01 PM Greg Mirsky <[e-mail]> wrote:
> >
> > Dear All,
> > I am concerned that the current definition of O-bit contradicts the
> definition of the Protocol Type field. Consider that O-bit defined as:
> >    O (1 bit):  OAM packet.  This packet contains a control message
> >       instead of a data payload.
> > My interpretation, please correct me if it is wrong, is that the O-bit
> indicates that a message that immediately follows the Geneve header is
> > OAM command or data. But that is what the Protocol Type field is for:
> >    Protocol Type (16 bits):  The type of the protocol data unit
> >       appearing after the Geneve header.
> > What is the precedence processing O-bit and the Protocol Type values?
> Should the specification explain how to interpret the value of the Protocol
> type field when O-bit is set? If the value of the Protocol Type field is
> equivalent to None, i.e., no message following the Geneve header, can O-bit
> be set to indicate that one of TLVs includes OAM? If that is the valid
> case, then the current definition of O-bit is not complete as it does not
> mention OAM in TLV case.
> >
> > And I have to point to an overall lack of discussion of OAM in the
> specification.
> >
> > Regards,
> > Greg
> >
> > On Tue, Oct 9, 2018 at 2:08 AM Bocci, Matthew (Nokia - GB) <
> [e-mail]> wrote:
> >>
> >> This email begins a two-week working group last call for
> draft-ietf-nvo3-geneve-08.txt.
> >>
> >> Please review the draft and post any comments to the NVO3 working group
> list. If you have read the latest version of the draft but have no comments
> and believe it is ready for publication as a standards track RFC, please
> also indicate so to the WG email list.
> >>
> >>
> >>
> >> We are also polling for knowledge of any undisclosed IPR that applies
> to this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
> >>
> >> If you are listed as an Author or a Contributor of this document,
> please respond to this email and indicate whether or not you are aware of
> any relevant undisclosed IPR. The Document won't progress without answers
> from all the Authors and Contributors.
> >>
> >> Currently there are two IPR disclosures against this document.
> >>
> >> If you are not listed as an Author or a Contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
> >>
> >>
> >>
> >> This poll will run until Friday 26th October.
> >>
> >>
> >>
> >> Regards
> >>
> >>
> >>
> >> Matthew and Sam
> >>
> >> _______________________________________________
> >> nvo3 mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/nvo3
>