While at it,
Can the Broadcom (specifically) coauthor on the NVGRE draft explain why
this is different from other GRE derivatives (SoftGRE) promoted by them where
they explicitly mandate VLAN Tags and disallow the use of keys to distinguish
between different virtual networks.
Rationale? If any?
A.
On 06/08/14 09:02, Lizhong Jin wrote:
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]<mailto:[email protected]>
Cc:
[email protected]<mailto:[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]<mailto:[email protected]>
Cc:
[email protected]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
