Re: [nvo3] 回复: 回复: Application of a time slot in this ietf meeting//Re: New draft: Path Detection in VXLAN Overlay Network

"Dacheng Zhang" <dacheng.zdc@alibaba-inc.com> Mon, 06 July 2015 06:39 UTC

Return-Path: <dacheng.zdc@alibaba-inc.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324381A8A61 for <nvo3@ietfa.amsl.com>; Sun, 5 Jul 2015 23:39:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.952
X-Spam-Level: ***
X-Spam-Status: No, score=3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LaVO9pa2t3x for <nvo3@ietfa.amsl.com>; Sun, 5 Jul 2015 23:39:26 -0700 (PDT)
Received: from out4133-50.mail.aliyun.com (out4133-50.mail.aliyun.com [42.120.133.50]) by ietfa.amsl.com (Postfix) with ESMTP id 39AA81A8A52 for <nvo3@ietf.org>; Sun, 5 Jul 2015 23:39:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1436164765; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=2NbV49gUUXAZSXDBSdZiyBPVAwpIDyR9dsEM5KXVN2Q=; b=PEadTjgXJAUulRZs2UNca0macQ0jfoCMHtUYXCVExGHJdkNhAG+HueAd0COrhf/7NTdUC3/VNeQKmk0r4/rhPKzJbAmwHIqSmjIXKUAhvgI4EQ0nHtpe5Z4up9XnhFcX+bTxZH0v1gK5g00PjotalaR/NJ3ElnhuY2kG072GnCg=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R451e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03267; MF=dacheng.zdc@alibaba-inc.com; PH=DS; RN=4; SR=0;
Received: from 10.1.52.114(mailfrom:dacheng.zdc@alibaba-inc.com ip:42.120.74.158) by smtp.aliyun-inc.com(127.0.0.1); Mon, 06 Jul 2015 14:39:18 +0800
User-Agent: Microsoft-MacOutlook/14.5.2.150604
Date: Mon, 06 Jul 2015 14:39:14 +0800
From: Dacheng Zhang <dacheng.zdc@alibaba-inc.com>
To: Dapeng Liu <maxpassion@gmail.com>, Tom Herbert <tom@herbertland.com>
Message-ID: <D1C04327.1EEB1%dacheng.zdc@alibaba-inc.com>
Thread-Topic: 回复: [nvo3] 回复: Application of a time slot in this ietf meeting//Re: New draft: Path Detection in VXLAN Overlay Network
References: <D1B4510C.1CFBC%dacheng.zdc@alibaba-inc.com> <2989C9FC-6A1F-4CCC-83C5-67716B0DB8D5@broadcom.com> <D1B78882.1DBA1%dacheng.zdc@alibaba-inc.com> <4A6CE49E6084B141B15C0713B8993F2831F4484A@SJEXCHMB12.corp.ad.broadcom.com> <D1BA2782.1E491%dacheng.zdc@alibaba-inc.com> <183366D25E3048B3B55AFF109AD4EEE8@gmail.com> <CALx6S35bMdzcpxVjT2pg4xmzfFSh+TXJhdmyrDKtx4L0=FqoJA@mail.gmail.com> <7C36E43F45EE4213BABE1C40B76B4DCE@gmail.com>
In-Reply-To: <7C36E43F45EE4213BABE1C40B76B4DCE@gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3519038358_5488967"
Archived-At: <http://mailarchive.ietf.org/arch/msg/nvo3/dx9u-blF0b0WbrYYG4tiRZ4F0FU>
Cc: Shahram Davari <davari@broadcom.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] 回复: 回复: Application of a time slot in this ietf meeting//Re: New draft: Path Detection in VXLAN Overlay Network
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jul 2015 06:39:32 -0000

Agree!In our scenario, it is assumed all the traffics that a  intermediate
router has to process are encapsulated within vxlan payloads.



发件人:  Dapeng Liu <maxpassion@gmail.com>
日期:  2015年7月6日 星期一 下午2:35
至:  Tom Herbert <tom@herbertland.com>
抄送:  Shahram Davari <davari@broadcom.com>, "nvo3@ietf.org"
<nvo3@ietf.org>, dacheng de <dacheng.zdc@alibaba-inc.com>
主题:  回复: [nvo3] 回复: 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> 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>
>> 日期: 2015年6月30日 星期二 上午2:12
>> 至: dacheng de <dacheng.zdc@alibaba-inc.com>
>> 抄送: "nvo3@ietf.org" <nvo3@ietf.org>, "bensons@queuefull.net"
>> <bensons@queuefull.net>, "matthew.bocci@alcatel-lucent.com"
>> <matthew.bocci@alcatel-lucent.com>, Dapeng Liu <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>
>> 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>
>> 日期: 2015年6月21日星期日上午1:04
>> 至: <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
>> https://www.ietf.org/mailman/listinfo/nvo3
>> 
>> 
>> 
>> _______________________________________________
>> nvo3 mailing list
>> nvo3@ietf.org
>> https://www.ietf.org/mailman/listinfo/nvo3
>