在 15-7-6 下午10:50， "Tom Herbert" <[email protected]> 写入:
>On Sun, Jul 5, 2015 at 11:35 PM, Dapeng Liu <[email protected]> wrote: >> Hi Tom, >> >> Thanks for the comments. >> The scenario discussed in the draft is: all the host traffic is >>encapsulated >> in VXLAN tunnel. So there will be no problem if the host traffic uses >>VXLAN >> port number. >> >I don't understand. You're assuming that *all* traffic generated by >hosts in a network is in VXLAN? In our scenario, yes. For instance, in a DC, vxlan is used to generate a overlay network. All the traffic generated by hosts will be transferred in vxlan. The traffic from internet will be encapsulated into a vxlan tunnel and forwarded to its target host….. > >Tom > >> -- >> Dapeng Liu >> >> 在 2015年7月4日 星期六，上午8:06，Tom Herbert 写道： >> >> "The Extendable TLV field contains two TLVs. Both of them are set by >> the network devices along the transport path."-- this might be >> problematic. From draft-ietf-tsvwg-port-use-11.txt: "Ultimately, port >> numbers numbers indicate services only to the endpoints, and any >> intermediate device that assigns meaning to a value can be >> incorrect.". A host may legitimately send UDP packets to the VXLAN >> port number that aren't actually VXLAN, so if intermediate devices are >> modifying these packets based just on destination couldn't this result >> in data corruption? Magic numbers like those defined in SPUD or >> https://tools.ietf.org/html/draft-herbert-udp-magic-numbers-00 could >> mitigate such an issue. >> >> Tom >> >> >> >> >> >> On Fri, Jul 3, 2015 at 10:23 AM, Dapeng Liu <[email protected]> >>wrote: >> >> >> >> 在 2015年7月2日 星期四，上午12:04，Dacheng Zhang 写道： >> >> HI, Shahram: >> >> Thanks for the comments. >> >> See my reply inline please.. >> >> Cheers >> >> Dacheng >> >> 发件人: Shahram Davari <[email protected]> >> 日期: 2015年6月30日 星期二 上午2:12 >> 至: dacheng de <[email protected]> >> 抄送: "[email protected]" <[email protected]>, "[email protected]" >> <[email protected]>, "[email protected]" >> <[email protected]>, Dapeng Liu <[email protected]> >> 主题: RE: [nvo3] Application of a time slot in this ietf meeting//Re: New >> draft: Path Detection in VXLAN Overlay Network >> >> >> >> >> >> 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. >> >> >> Dacheng\ That is why For the ingress PE, only EIID is mandatory. >> >> >> >> 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. >> >> >> Dacheng\ I am trying to understand your point and please correct me if >>I am >> wrong. The purpose of this work is to check the error of paths over a l3 >> network. (Pleas see figure 1.) >> >> >> >> 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. >> >> >> Dacheng\ Ok, our objective is to check the paths between vteps. So, the >> egress PE does not have to forward this packet to the tenant. Note we >> mentioned that for the egress PE only IIID is mandatory. >> >> >> >> 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. >> >> >> Dacheng\ Yes, we expect the intermediate routers can look into the >>packet. >> Our experiments have shown that this solution works very well and >> significantly reduce the complexity of detecting errors in complex >>networks. >> Hope other people can give us some comments on this argument. >> >> >> [Dapeng Liu] Yes. The deployment assumption in the draft is all the >> forwarding equipment should support VXLAN and this draft proposes a >>VXLAN >> function extension to support the OAM mechanism described in the draft. >> >> ---- >> Dapeng Liu >> >> >> >> >> >> >> Regards, >> >> Shahram >> >> >> >> >> On Jun 26, 2015, at 10:15 PM, Dacheng Zhang >><[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]> >> 日期: 2015年6月21日星期日上午1:04 >> 至: <[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] https://www.ietf.org/mailman/listinfo/nvo3 >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
