Re: [nvo3] 回复: Application of a time slot in this ietf meeting//Re: New draft: Path Detection in VXLAN Overlay Network
Tom Herbert <tom@herbertland.com> Mon, 06 July 2015 14:50 UTC
Return-Path: <tom@herbertland.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 024A61B2A4C for <nvo3@ietfa.amsl.com>; Mon, 6 Jul 2015 07:50:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 Mgd3m9-YnwVv for <nvo3@ietfa.amsl.com>; Mon, 6 Jul 2015 07:50:53 -0700 (PDT)
Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06BA1B2A83 for <nvo3@ietf.org>; Mon, 6 Jul 2015 07:50:52 -0700 (PDT)
Received: by iecuq6 with SMTP id uq6so114742387iec.2 for <nvo3@ietf.org>; Mon, 06 Jul 2015 07:50:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/LM480MBm9YLyEDyZdj5J1shDeUnN+dQO7SRo0FxJzc=; b=jWWiwB735DHFHWgNtxI0eXkabhC4JLfH/TVBYYB29YjcXopxIdr5ERkfzPPu61J/zK lcbUjthHVtbogSw3QJCMG3nXKiwJOc2hd/hc+D1JgWY3fUMG/nIA46tFQivlY/FHzcaz ZEvggIJ0u7+EiWt+t0E/jgBa8E/a1jeURQHWfd7vVckffqaFA8Sq1UuIs7qIJilMxd2m T+tlX16/EH3YrkZNXbK0rkGmLaFYYHNeBcxiJ4NAgP9W5MDakuy4sAdQZFExMBQf+sCy MizPOATLsXFVG150qThGB8yiQMdtgowZUrPukCFC7vBjwWhSKef3IrIxdFxslcaAu1/e NkWg==
X-Gm-Message-State: ALoCoQlojmUaoPNCUuGhiWJAyu2jke01oKnpz1sCr3ixLVdPLaN0ThpdxriGUCx84p+TPZlp77oa
MIME-Version: 1.0
X-Received: by 10.107.41.146 with SMTP id p140mr70840807iop.58.1436194252231; Mon, 06 Jul 2015 07:50:52 -0700 (PDT)
Received: by 10.107.142.86 with HTTP; Mon, 6 Jul 2015 07:50:52 -0700 (PDT)
In-Reply-To: <7C36E43F45EE4213BABE1C40B76B4DCE@gmail.com>
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>
Date: Mon, 06 Jul 2015 07:50:52 -0700
Message-ID: <CALx6S36GYytQdxcpTq4CW=_c=WtDwOAnDpEK3YkbpKOpLObZbg@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
To: Dapeng Liu <maxpassion@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/nvo3/NZO7wVNmT2Ghzy1ATaKA7AhIS4U>
Cc: Shahram Davari <davari@broadcom.com>, "nvo3@ietf.org" <nvo3@ietf.org>, Dacheng Zhang <dacheng.zdc@alibaba-inc.com>
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 14:50:55 -0000
On Sun, Jul 5, 2015 at 11:35 PM, Dapeng Liu <maxpassion@gmail.com> 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? 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 <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 > >
- [nvo3] Application of a time slot in this ietf me… Dacheng Zhang
- Re: [nvo3] Application of a time slot in this iet… Shahram Davari
- Re: [nvo3] Application of a time slot in this iet… Dacheng Zhang
- Re: [nvo3] Application of a time slot in this iet… Shahram Davari
- Re: [nvo3] Application of a time slot in this iet… Dacheng Zhang
- [nvo3] 回复: Application of a time slot in this iet… Dapeng Liu
- Re: [nvo3] 回复: Application of a time slot in this… Tom Herbert
- [nvo3] 回复: =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_… Dapeng Liu
- Re: [nvo3] 回复: 回复: Application of a time slot in … Dacheng Zhang
- Re: [nvo3] 回复: Application of a time slot in this… Tom Herbert
- Re: [nvo3] 回复: Application of a time slot in this… Dacheng Zhang