Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

Lucy yong <lucy.yong@huawei.com> Wed, 11 July 2012 15:00 UTC

Return-Path: <lucy.yong@huawei.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08F321F877E for <nvo3@ietfa.amsl.com>; Wed, 11 Jul 2012 08:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.254
X-Spam-Level:
X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[AWL=-1.008, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1hGFiZlHzDo for <nvo3@ietfa.amsl.com>; Wed, 11 Jul 2012 08:00:23 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6874721F8776 for <nvo3@ietf.org>; Wed, 11 Jul 2012 08:00:23 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHX92662; Wed, 11 Jul 2012 11:00:54 -0400 (EDT)
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 08:00:04 -0700
Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Wed, 11 Jul 2012 08:00:02 -0700
From: Lucy yong <lucy.yong@huawei.com>
To: Thomas Narten <narten@us.ibm.com>, "Luyuan Fang (lufang)" <lufang@cisco.com>
Thread-Topic: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)
Thread-Index: AQHNX2zkDL+EKdF/90eY4bvHB0FXSpckHwgw
Date: Wed, 11 Jul 2012 15:00:01 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3BA9EE88@dfweml505-mbx>
References: <8D3D17ACE214DC429325B2B98F3AE71208D3B170@MX15A.corp.emc.com> <CC223B30.188BE%kreeger@cisco.com> <0DB8F45437AB844CBB5102F807A0AD9301B093@xmb-rcd-x03.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0752ED29@szxeml525-mbs.china.huawei.com> <0DB8F45437AB844CBB5102F807A0AD9301B12F@xmb-rcd-x03.cisco.com> <201207111354.q6BDspBU027084@cichlid.raleigh.ibm.com>
In-Reply-To: <201207111354.q6BDspBU027084@cichlid.raleigh.ibm.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.141.21]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "L2 \"Network Virtualization Over L3\" overlay discussion list \(nvo3\)" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Wed, 11 Jul 2012 15:00:25 -0000

Here is my 2 cents for the L3VN case.

If an NVE is on a server and TESs are VMs on the server, TES-NVE attach/detach is configured by DC operators. When VM is power-on, the NVE populates it in the forwarding table; When VM is power-off, the NVE removes it from the table. The forwarding between the NVE and TESs is simply an internal table lookup and delivery process on the server. If an NVE is on ToR, TESs may be either non-virtualized servers or a vSwitch on virtualized servers; the routing between NVE and TESs may use Petro's proposal or run a routing protocol such as OSPF per a VN; The forwarding between two is like [RFC4364].

Lucy

-----Original Message-----
From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Thomas Narten
Sent: Wednesday, July 11, 2012 8:55 AM
To: Luyuan Fang (lufang)
Cc: nvo3@ietf.org
Subject: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

"Luyuan Fang (lufang)" <lufang@cisco.com> writes:

> My understanding VDP is a discovery protocol for bridging�

Note: VDP stands for VSI Discovery and Configuration Protocol (though the "configuration" part is often dropped).

It does more than just "discover". E.g., see http://blog.ioshints.info/2011/05/edge-virtual-bridging-evb-8021qbg-eases.html

> One of the most interesting parts of EVB is the VSI Discovery and 
> Configuration Protocol (VDP). Using VDP, the EVB station (host) can 
> inform the adjacent EVB Bridge (access switch) before a VM is deployed 
> (started or moved). The host can also tell the switch which VLAN the 
> VM needs and which MAC address (or set of MAC addresses) the VM uses. 
> Blasting through the VLAN limits (4K VLANs allowed by 802.1Q), the VDP 
> supports 4-byte long Group ID, which can be mapped dynamically into 
> different access VLANs on as-needed basis (this is a recent addendum 
> to 802.1Qbg and probably allows nice interworking with I-SID field in 
> PBB/SPB).

Also, see draft-gu-nvo3-overlay-cp-arch-00.txt  and draft-gu-nvo3-tes-nve-mechanism-00.txt which has text on VDP.

If anyone can point the WG to a good overview/summary of what VDP does, that would be helpful.

> If you are using pure l3 end-system to end-system, there is no 
> bridging, there is no need for VDP.

I'm not sure about that.

When you say L3 TES, what is the interface between the NVE and TES? My assumption is that it is still L2, even if the service provided is L3. You'd ignore the L2 stuff (mostly), but most VMs are already set up to send L2 packets on their interfaces. 

Also VDP is between the Hypervisor and NVE. Thus, it may still be needed, even if the service provided to the TES is L3 only.

Thomas