IETF Logo Mail Archive

Re: [nvo3] Last Call: <draft-ietf-nvo3-framework-06.txt> (Framework for DC Network Virtualization) to Informational RFC

Linda Dunbar <linda.dunbar@huawei.com> Fri, 30 May 2014 15:02 UTC

Return-Path: <linda.dunbar@huawei.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 A64BD1A0938; Fri, 30 May 2014 08:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level:
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
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 NRsiinMT9lMH; Fri, 30 May 2014 08:01:59 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6AF1A08F1; Fri, 30 May 2014 08:01:58 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHL20439; Fri, 30 May 2014 15:01:53 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 30 May 2014 16:01:15 +0100
Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 30 May 2014 16:01:52 +0100
Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml705-chm.china.huawei.com ([169.254.7.11]) with mapi id 14.03.0158.001; Fri, 30 May 2014 08:01:49 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "LASSERRE, MARC (MARC)" <marc.lasserre@alcatel-lucent.com>, "Larry Kreeger (kreeger)" <kreeger@cisco.com>, "Ken Gray (kegray)" <kegray@cisco.com>
Thread-Topic: [nvo3] Last Call: <draft-ietf-nvo3-framework-06.txt> (Framework for DC Network Virtualization) to Informational RFC
Thread-Index: AQHPdQHI1MgaSDHiC0yhyNgweqVM7ZtM7G4ggACPSYD//4tXgIABieqA///HcNCAAhVmgIAGlzUA//+fO2AAVzbLgAADSPHQ
Date: Fri, 30 May 2014 15:01:48 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D2975D@dfweml701-chm.china.huawei.com>
References: <20140521143310.22736.34790.idtracker@ietfa.amsl.com> <4A95BA014132FF49AE685FAB4B9F17F645D23B76@dfweml701-chm.china.huawei.com> <CFA3BF05.2C990%kegray@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645D23D42@dfweml701-chm.china.huawei.com> <74FD38F4-0824-45A0-8B56-40A02B903430@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645D254E4@dfweml701-chm.china.huawei.com> <CFA4FAC6.2D25F%kegray@cisco.com> <CFABA416.FE778%kreeger@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F645D27721@dfweml701-chm.china.huawei.com> <B30152B129674240ADF67727A967301408C6F7@FR711WXCHMBA03.zeu.alcatel-lucent.com>
In-Reply-To: <B30152B129674240ADF67727A967301408C6F7@FR711WXCHMBA03.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.178]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D2975Ddfweml701chmchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/hN1lQDGb9Hq0QQGJ3bT3XNuKBLw
Cc: "nvo3@ietf.org" <nvo3@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, IETF-Announce <ietf-announce@ietf.org>
Subject: Re: [nvo3] Last Call: <draft-ietf-nvo3-framework-06.txt> (Framework for DC Network Virtualization) to Informational RFC
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: <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: Fri, 30 May 2014 15:02:01 -0000

Marc,

Questions inserted below:

From: LASSERRE, MARC (MARC) [mailto:marc.lasserre@alcatel-lucent.com]


-       Page 13 Second bullet: the text says that each VNI is automatically generated by the egress NVE. Isn't each VNI supposed to match a local virtual network (e.g. represented by VLAN)? When the same NVE acts as Ingress NVE for the attached VMs, aren't the VNI for ingress direction statically provisioned? Why need automatic egress VNI generation?

The value of the VN context identifier is a value locally significant to an NVE and does not have to match a local virtual network. It is simply used as a demultiplexer. This value can be automaticaly computed or provisioned.

[Linda]If the NVE's VAPS (VNI) are connected to VMs via Ethernet where VLAN is used, it is much easier to use locally significant VLAN. Why require egress to automatically generate local VNI value?  It would be better to change the text to:

"Each VNI value on egress NVE is either mapped to locally significant Virtual Network identifier (e.g. VLAN for Ethernet), or generated by NVA or Control Plane".

Linda

nvo3 mailing list
nvo3@ietf.org<mailto:nvo3@ietf.org>
https://www.ietf.org/mailman/listinfo/nvo3

v2.23.0 | Report a Bug | By Email