On 9/24/15, 8:14 AM, "Lucy yong" <[email protected]> wrote:
> > >See inline below. > >-----Original Message----- >From: Tom Herbert [mailto:[email protected]] >Sent: Thursday, September 24, 2015 10:08 AM >To: Lucy yong >Cc: Anoop Ghanwani; Larry Kreeger (kreeger); Sandeep Kumar (Sandeep) >Relan; [email protected]; Shahram Davari >Subject: Re: [nvo3] destination UDP port : draft-ietf-nvo3-vxlan-gpe-00 > >> What we may want to say, then, is that if a P bit of 0 is used then >> none of the other flags must be set. This would prevent someone from >> generating a packet with a P bit of 0 and trying to use new GPE >>features. >> >> [Lucy] The P bit is used for version purpose too. The rule is if the >> GPE need support new features to Ethernet payload, it has to set P bit >> and use the protocol field to indicate Ethernet payload. >> >> The rule is: GPE accepts a special case of P=0 mode as valid for >> Ethernet Payload., and P =1 (mode) & Protocol = Ethernet (0x03). When >> a P bit of 0 is used, none of the other flags must be set. >> >> >> >> This works under condition/rule that VXLAN protocol enhancement MUST >> be stopped. >> >Lucy, > >I'm not sure why the constraint needs to be so stringent. The P bit can >be used to discriminate between VXLAN and VXLAN-GPE received on the same >port. i.e if P bit is set, it is a VXLAN-GPE packet. If it is not set it >is VXLAN packet and the rest of the fields are processed accordingly. New >features can be added to either protocol in this way using the other >reserved bits independently. This allows backwards compatibility to >receive VXLAN on a VXLAN-GPE port (doesn't help with the forward >compatibility problem though). >[Lucy] What you say is the draft intention. My comment is to say, if we >add this rule as Anoop suggested "When >a P bit of 0 is used, none of the other flags must be set.", it will only >work if no more VXLAN enhancement in future, e.g. using a new bit for >something. If there will be, it will cause an issue for interworking >between two. I just want to point out for caution. If I can restate what I think you two agree on, it is: If VXLAN evolves independently from VXLAN GPE, then a VXLAN GPE endpoint that understands only how to be backward compatible with RFC7348 VXLAN will not be able to be compatible with the unknown evolution of RFC748. For this reason, I would discourage anyone from taking RFC7348 VXLAN on a separate evolutionary path from VXLAN than what VXLAN GPE is. I would encourage any IETF work on evolving VXLAN to instead evolve VXLAN GPE which has an actual version field to prevent unknown forwarding behavior from occurring if a VXLAN GPE version 0 endpoint receives an evolved (next version) of VXLAN GPE. - Larry > >Lucy > >Tom _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
