Hi Pankaj, Authors, The processing of inner VLAN tag for NVGRE and VXLAN is different.
In NVGRE: o Inner 802.1Q tag: The inner Ethernet header of NVGRE MUST NOT contain 802.1Q Tag. The encapsulating NVE MUST remove any existing 802.1Q Tag before encapsulation of the frame in NVGRE. A decapsulating NVE MUST drop the frame if the inner Ethernet frame contains an 802.1Q tag. In VXLAN: Decapsulated VXLAN frames with the inner VLAN tag SHOULD be discarded unless configured otherwise. On the encapsulation side, a VTEP SHOULD NOT include an inner VLAN tag on tunnel packets unless configured otherwise. When a VLAN-tagged packet is a candidate for VXLAN tunneling, the encapsulating VTEP SHOULD strip the VLAN tag unless configured otherwise. 1. The description in NVGRE draft does not align with that shown in figure 1. Since inner tag is not allowed, why there is a tag in the figure? 2. The different mechanism for VXLAN and NVGRE makes confusion to the implementation for us. IMO, the mechanism in VXLAN is more acceptable. Could you give some reason why the NVGRE is different with VXLAN? I would appreciate if the two could have the same tag processing mechanism. Regards Lizhong From: Pankaj Garg [mailto:[email protected]] Sent: 2014年8月4日 13:20 To: Pankaj Garg; [email protected] Cc: [email protected] Subject: Re: [nvo3] Taking NVGRE draft to Informational RFC Sorry for double post, the latest NVGRE draft is at: http://www.ietf.org/id/draft-sridharan-virtualization-nvgre-05.txt Thanks Pankaj From: nvo3 [mailto:[email protected]] On Behalf Of Pankaj Garg Sent: Monday, August 4, 2014 10:46 AM To: [email protected] Cc: [email protected] Subject: [nvo3] Taking NVGRE draft to Informational RFC Hi All, As discussed in the NVO3 forum in the past, we intend to take NVGRE to informational RFC status. This would ensure that there is a stable way to build compliant and interoperable NVGRE implementation. It would also allow extensions to NVGRE to be able to refer to a stable document version as opposed to rolling revisions, thus removing the risk of introducing incompatibilities and interoperability issues later on. We are seeking (and would highly appreciate) editorial feedback from NVO3 fellows. Could you please review the latest draft of NVGRE (below) and provide us any editorial feedback on the latest NVGRE draft by 11th August? Thanks Pankaj (on behalf of NVGRE co-authors)
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
