Hi I agree with Greg. Flag bit is useful if there was no protocol type field. From HW perspective there no advantage of using flag rather than protocol field.
Regards, Shahram > On 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. 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 draft-ooamdt-rtgwg-ooam-header. Then 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. > > 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
