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 <[email protected]> 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 <[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
