On Tue, Aug 9, 2016 at 9:07 AM, Greg Mirsky <[email protected]> wrote: > Hi Tom, > many thanks for the most informative response. I've added mu notes in-line > under tag GIM>>. > > Regards, Greg > > On Mon, Aug 8, 2016 at 5:44 PM, Tom Herbert <[email protected]> wrote: >> >> On Sun, Aug 7, 2016 at 7:02 PM, Greg Mirsky <[email protected]> wrote: >> > Dear Authors of the VxLAN-GPE, GUE, and GENEVE, >> > all protocols under consideration use a bit flag rather than explicit >> > protocol type to indicate that payload is a test packet, i.e. active >> > OAM. >> > I'm trying to understand the rationale of such decision. Does use of the >> > bit >> > flag rather than protocol type produce more efficient implementation, is >> > more HW friendly? In GUE, the the field to indicate type of the payload >> > even >> > tagged Proto/ctype as its interpretation depends upon value of the C >> > bit. >> >> The C-bit in GUE distinguishes data messages from control >> messages.Data messages are considered to be the payload of >> encapsulation, whereas control messages are about the encapsulation >> itself. OAM might be one type of control message in GUE, however there >> could be others. For instance if we wanted some sort of negotiation >> between two endpoints to exchange capabilities or supported features >> this would fit well into a control message. > > GIM>> Yes, what I've proposed is clearly more than just OAM channel. In > fact, it is Associated Channel (ACh) that may be used by control, management > and OAM. And as I've used term "Associated Channel" you'll easily recognize > that I have MPLS background and draw on MPLS/MPLS-TP OAM experience. And as > Generic ACh (G-ACh) is used to advertise capabilities of an LSR in RFC 7212, > AC-h in NVO3 can support similar functionalities as well. >> >> >> > But wouldn't it be simpler if all proposals used protocol type to >> > identify >> > OAM payload? And if the protocol type is OAM, then after the protocol >> > header >> > have OOAM Header, e.g. as proposed in . Then >> >> Each of the three protocols has a protocol next header field, however >> the field is defined differently among them. The next header in GUE is >> an IP protocol number, in Geneve it is an Ethertype, and VXLAN-GPE >> uses a new number space. In GUE we could probably use ICMP protocol >> for OAM by defining the appropriate types (that might have the >> advantage of allow OAM to be generic instead of restricted to only >> encapsulation). Presumably, VXLAN-GPE could define some value in the >> number space for for OAM. For Geneve maybe there is an appropriate >> Ethertype? >> >> > NVO3 protocols would be able to have common Active OAM (Fault Management >> > and >> > Performance Measurement) that can be used in BIER and SFC. And the bit, >> > the >> > bit I'd propose to redefine to be used for passive performance >> > measurement >> > as described in draft-ietf-bier-pmmm-oam. (Allocating two bits-long >> > field >> > would enable more accurate measurements using the Alternate Marking >> > method). >> > And these steps will enable us to develop common Active OAM and use >> > passive >> > performance measurement regardless, almost, of the data plane protocol >> > used >> > in NVO layer. >> >> The problem I see with trying to constrain the solution to only one or >> two bits of information is that this substantially limits the >> functionality. With an extensible protocol we should be able more >> information to get more accurate measurement. For instance, I might >> want to measure the latency of individual packets to get feedback on >> path selection, correlate performance to packet loss, etc. Has the OAM >> DT considered the requirements and solutions for passive performance >> measurement? > > GIM>> Indeed, the OAM DT had considered the requirements to enable use of > performance measurement methods as passive OAM. Should note that we use term > "passive method" somewhat differently from the definition in RFC 7799. Such > interpretation was discussed in the IPPM WG and we've agreed that if a > measurement method does not change treatment of a data packet by the network > (e.g. doesn't change its CoS, length or else), then the method behaves as > close as passive and may be characterized as such. Measurements for a single > packet are possible using the Alternate Marking method with two bits-long > marker. The draft in BIER WG has such example. I've attached the > presentation slides. Will be glad to answer any further questions.
Yes, but number of specific packets I could measure is still limited in some time quantum with the two bit method. Alternatively, if every packet contained a timestamp for instance, then we can measure every packet and filter or aggregate the measurements with arbitrary granularity of our choosing. BIER may have been defined with as a fixed length header so that a couple of bits are all that could feasibly be allocated to OAM, but this is not necessarily true for other encapsulation protocols that are purposely extensible to support a richer set of features. Tom >> >> >> Thanks, >> Tom >> >> > >> > Regards, Greg >> > >> > On Fri, Jul 29, 2016 at 8:13 AM, Alia Atlas <[email protected]> wrote: >> >> >> >> I'd like to have people focus on the key point of this thread. >> >> >> >> Are there serious technical objections (and specifically what are they) >> >> to >> >> moving forward with VXLAN-GPE as the standards-track protocol? >> >> >> >> Are there serious technical objections (and specifically what are they) >> >> to >> >> moving forward with GENEVE as the standards-track protocol? >> >> >> >> Are there serious technical objections (and specifically what are they) >> >> to >> >> moving forward with GUE as the standards-track protocol? >> >> >> >> We need to capture any relevant objections. So far, there's been some >> >> discussion on extensibility - with Tom Herbert providing concrete >> >> concerns. >> >> >> >> I have concluded that almost all the authors would prefer to have no >> >> standards track solution if they can't guarantee that theirs is that >> >> standard. >> >> >> >> I do hear concerns about whether a decision will be too late. I think >> >> that a decision can only be helpful. It goes back to when is the best >> >> time >> >> to plant a tree - with the answer of 20 years ago or now. >> >> >> >> Regards, >> >> Alia >> >> >> >> >> >> On Fri, Jul 29, 2016 at 4:34 AM, Naoki Matsuhira >> >> <[email protected]> wrote: >> >>> >> >>> >> >>> >> >>> On 2016/07/21 23:56, Bocci, Matthew (Nokia - GB) wrote: >> >>>> >> >>>> WG >> >>>> >> >>>> There was a discussion in the NVO3 WG meeting in Berlin following >> >>>> strong >> >>>> advice from our Area Director that we need to come to a consensus on >> >>>> converging on a common encapsulation. Two sets of questions were >> >>>> asked: >> >>>> (1) Should the WG move forward with one standards track encap? >> >>>> (2) For a given encap, do you have significant technical objections? >> >>> >> >>> >> >>> I want to inform to this mailing list that I proposed ME6E-FP and >> >>> ME6E-PR >> >>> at the yokohama meeting. I also have proposal M46E-FP and M46E-PR >> >>> (past >> >>> called SA46T). >> >>> >> >>> These encapsulation technologies are based on address mapping. ME6E >> >>> use >> >>> IPv6 address which mapping MAC address, and M46E use IPv6 address >> >>> which >> >>> mapping IPv4 address. >> >>> >> >>> I understand too many encapsulation technologies, however these my >> >>> proposal are simple, and may contribute to the Internet. >> >>> >> >>> I believe address mapping approach is unique, so I want to propose >> >>> again. >> >>> >> >>> sorry not the answer to the question. >> >>> >> >>> Naoki Matsuhira >> >>> >> >>> >> >>> _______________________________________________ >> >>> nvo3 mailing list >> >>> [email protected] >> >>> https://www.ietf.org/mailman/listinfo/nvo3 >> >> >> >> >> >> >> >> _______________________________________________ >> >> nvo3 mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> >> > >> > >> > _______________________________________________ >> > nvo3 mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/nvo3 >> > > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
