Hi Pankaj, In this draft, NVGRE encapsulation is clearly defined for east-west direction intra-subnet layer 2 traffic forwarding. And in section 4.6, Cross-subnet, Cross-premise Communication procedures between internal DC and external DC is described, it is for north-south direction traffic forwarding. For complete solution purpose, I think east-west direction cross-subnet traffic forwarding process had better be discribed also. Two candidate encapsulations can be used for inter-subnet traffic forwarding: 1. Ethernet in GRE. Destination MAC can be used to distinguish layer 2 or layer 3 traffic. In layer 3 traffic forwarding case, destination MAC is the gateway interface MAC of destination NVE. 2. IP in GRE. Ethernet in GRE encapsulation is only used for intra-subnet layer 2 traffic forwarding. For layer 3 traffic forwarding, IP in GRE encapsulation is used. In distributed layer 3 gateway scenario, when ingress NVE receives inter-subnet traffic from local TS, if the MAC equals to local gateway interface's MAC, IP forwarding table is looked up. Then IP in GRE encapsulation is used to transmit the traffic to destination NVE. Destination NVE decapsulates the traffic and looks up local IP forwarding table, then it forwards the traffic to dest TS.
The draft should determine which encapsulation is used to forward inter-subnet layer 3 traffic to faciliate interoperbility among multi vendors. Thanks weiguo ________________________________ 发件人: Pankaj Garg [[email protected]] 发送时间: 2014年8月4日 13:20 收件人: Pankaj Garg; [email protected] 抄送: [email protected] 主题: 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
