Hi Please see my reply inline.
Thx SD From: Dacheng Zhang [mailto:[email protected]] Sent: Monday, June 29, 2015 9:01 AM To: Shahram Davari Cc: [email protected]; [email protected]; [email protected]; Dapeng Liu Subject: Re: [nvo3] Application of a time slot in this ietf meeting//Re: New draft: Path Detection in VXLAN Overlay Network Hi, Shahram: Please see my reply inline please.. Cheers Dacheng 发件人: Shahram Davari <[email protected]<mailto:[email protected]>> 日期: 2015年6月27日 星期六 下午9:45 至: dacheng de <[email protected]<mailto:[email protected]>> 抄送: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Dapeng Liu <[email protected]<mailto:[email protected]>> 主题: Re: [nvo3] Application of a time slot in this ietf meeting//Re: New draft: Path Detection in VXLAN Overlay Network Hi Dacheng I read your draft and I don't think it can get the information that you claim it does. For example you have ingress interface TLV to record the ingress port of the ingress PE. First of all this interface is already communicated by the controller to the Ingress PE. Ingress/egress interface are refer to the interfaces on the data path. The controller will use another interface to communicate with the PE SD> What I mean is that the controller is asking the PE to inject this test packet to a tunnel via a specific PE interface. So the controller already knows which PE interfaces the packet is going to use. Secondly if you want to test the Correct IP forwarding you can just use BFD for the outer IP. If you like to use UDP, you could do BFD over UDP over IP. BFD works at layer 2. It’s mainly used to test whether the layer 2 data path is connected. In contrast, our method is focusing on the tracing function. (Our solution can help find out which switch on the path is broken.) SD> The way you have defined it does not test anything in L2, since your packet is not exercising any L2 forwarding. Your packet is L3 forwarded all the way. Thirdly, your draft can't get the egress interface information of the egress PE, since there is nothing (No MAC or IP address) in your VXLAN payload that can be forwarded by the egress PE to the egress interface. Two TLV (IIID/EIID) could be used to record the ingress/egress interfaces ID of current router the OAM packet is flowing through. For the ingress PE, EIID is mandatory while for the egress PE IIID is mandatory. For the intermediate router, both IIID and EIID are mandatory. So, for the egress, EIID does not have to be transported to the controller. SD> I know you have TLV. But what I mean is that there is nothing in your draft that makes your packets to be L2 forwarded. For example you are not doing any (VXLAN/VNI forwarding) of your packet. As an example assume you packet arrives at the Final Egress PE. The Egress PE can’t forward this packet based on the IP destination address since it is 127/8. Fourthly the path trace that you describe does not work. How does an intermediate router know it has to send a copy of this packet to CPU? The only method is to use TTL expiry, which already exists in IP trace route. In our method, o bit in VxLAN is used to indicate it’s a OAM packet, which should be copy to CPU. One OAM packet is able to trace n devices on the path, while TTL expire method needs n OAM packets to trace. Of course if you assume that the intermediate devices do not support our solution, our mechanism will not work properly then. SD> Are you suggesting that the intermediate routers need to do deep packet inspection and after finding this magical bit copy it to CPU? This is a layer violation and should NOT be done. You should not make decision on any layer when layers above it are not terminated. Basically you are expecting intermediate routers to look in to the packet, skip outer Ethernet, Skip IP, check IP payload is UDP, check UDP-Dest port is VXLAN, then check a specific bit in VXLAN header in order to decide to copy to CPU or not. This is architecturally wrong by any means. Lastly this packet format (having a 128 byte dummy header) is not practical at all. Any header field deeper than 128 byte is not accessible by almost any HW parser. 128 bytes pseudo header are supposed to be phrased by CPU, no need for any HW parser. Regards, Shahram On Jun 26, 2015, at 10:15 PM, Dacheng Zhang <[email protected]<mailto:[email protected]>> wrote: Dear chairs: Can we get a time slot during the nvo3 session in Prague to discuss this draft? Dapeng Liu from Alibaba will be the presenter. 15 minutes would be good enough. Cheers Dacheng 发件人: Dapeng Liu <[email protected]<mailto:[email protected]>> 日期: 2015年6月21日 星期日 上午1:04 至: <[email protected]<mailto:[email protected]>> 主题: [nvo3] New draft: Path Detection in VXLAN Overlay Network Hello all, We have submitted a draft for path detection in VXLAN overlay network. http://datatracker.ietf.org/doc/draft-pang-nvo3-vxlan-path-detection/ The draft proposes a method for path detection in VXLAN network and it defines the path detection packet format by using one reserve bit in the VXLAN header. Comments & suggestions are welcomed. -- Dapeng Liu _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ 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
