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 <[email protected]> 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 <[email protected]> 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) >> <[email protected]> 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 <[email protected]> >> > Date: Thursday, 18 October 2018 at 16:21 >> > To: "[email protected]" <[email protected]> >> > Cc: "Bocci, Matthew (Nokia - GB)" <[email protected]>, NVO3 >> > <[email protected]>, "[email protected]" >> > <[email protected]> >> > 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 <[email protected]> wrote: >> > >> > On Wed, Oct 17, 2018 at 1:32 PM Greg Mirsky <[email protected]> wrote: >> > > On Wed, Oct 17, 2018 at 11:31 AM Jesse Gross <[email protected]> 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. _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
