在 2015年7月2日 星期四，上午12:04，Dacheng Zhang 写道： > HI, Shahram: > > Thanks for the comments. > > See my reply inline please.. > > Cheers > > Dacheng > > 发件人: Shahram Davari <[email protected] (mailto:[email protected])> > 日期: 2015年6月30日 星期二 上午2:12 > 至: 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 > > > > > 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] > (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
