[nvo3] 回复： =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=Application of a time slot in this ietf meeting//Re: New draft: Path Detection in VXLAN Overlay Network

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.

--  
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 <maxpassion@gmail.com (mailto:maxpassion@gmail.com)> wrote:
> >  
> >  
> > 在 2015年7月2日 星期四，上午12:04，Dacheng Zhang 写道：
> >  
> > HI, Shahram:
> >  
> > Thanks for the comments.
> >  
> > See my reply inline please..
> >  
> > Cheers
> >  
> > Dacheng
> >  
> > 发件人: Shahram Davari <davari@broadcom.com (mailto:davari@broadcom.com)>
> > 日期: 2015年6月30日 星期二 上午2:12
> > 至: dacheng de <dacheng.zdc@alibaba-inc.com (mailto:dacheng.zdc@alibaba-inc.com)>
> > 抄送: "nvo3@ietf.org (mailto:nvo3@ietf.org)" <nvo3@ietf.org (mailto:nvo3@ietf.org)>, "bensons@queuefull.net (mailto:bensons@queuefull.net)"
> > <bensons@queuefull.net (mailto:bensons@queuefull.net)>, "matthew.bocci@alcatel-lucent.com (mailto:matthew.bocci@alcatel-lucent.com)"
> > <matthew.bocci@alcatel-lucent.com (mailto:matthew.bocci@alcatel-lucent.com)>, Dapeng Liu <maxpassion@gmail.com (mailto:maxpassion@gmail.com)>
> > 主题: 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 <dacheng.zdc@alibaba-inc.com (mailto:dacheng.zdc@alibaba-inc.com)>
> > 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 <maxpassion@gmail.com (mailto:maxpassion@gmail.com)>
> > 日期: 2015年6月21日星期日上午1:04
> > 至: <nvo3@ietf.org (mailto:nvo3@ietf.org)>
> > 主题: [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
> > nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
> >  
> > _______________________________________________
> > nvo3 mailing list
> > nvo3@ietf.org (mailto:nvo3@ietf.org)
> > https://www.ietf.org/mailman/listinfo/nvo3
> >  
> >  
> >  
> > _______________________________________________
> > nvo3 mailing list
> > nvo3@ietf.org (mailto:nvo3@ietf.org)
> > https://www.ietf.org/mailman/listinfo/nvo3
> >  
>  
>  
>  