Re: [nvo3] Role of control plane in draft-dt-nvo3-encap-01
Sami Boutros <sboutros@vmware.com> Fri, 19 May 2017 14:34 UTC
Return-Path: <sboutros@vmware.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 D42BF12869B for <nvo3@ietfa.amsl.com>; Fri, 19 May 2017 07:34:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level:
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onevmw.onmicrosoft.com
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 Ij-hdoKFPcF9 for <nvo3@ietfa.amsl.com>; Fri, 19 May 2017 07:34:42 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0063.outbound.protection.outlook.com [104.47.32.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65480127B52 for <nvo3@ietf.org>; Fri, 19 May 2017 07:34:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bjDJgJiOZ+RUFS7thwB8uO1kAWwYVaXsFGOGlY7M7rU=; b=Hk4BQO6mQ6kbBS8ZmM2OOcladlS8dOoni6Cv89sfPqntigOIzLApXvjJmhsulOm30OIIrzRhH02zzdZd+TnZNuwnuP0AvDUn4zoKtkOBXfTXmeyYqYPYorE2YLBONkt8i+yjbRChzCMHlX6sgrYjVimg02WZt5292p9EFIQrASY=
Received: from BN6PR05MB3009.namprd05.prod.outlook.com (10.173.19.15) by BN6PR05MB3009.namprd05.prod.outlook.com (10.173.19.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.5; Fri, 19 May 2017 14:34:40 +0000
Received: from BN6PR05MB3009.namprd05.prod.outlook.com ([10.173.19.15]) by BN6PR05MB3009.namprd05.prod.outlook.com ([10.173.19.15]) with mapi id 15.01.1124.007; Fri, 19 May 2017 14:34:40 +0000
From: Sami Boutros <sboutros@vmware.com>
To: Tom Herbert <tom@herbertland.com>, Erik Nordmark <nordmark@sonic.net>
CC: Erik Nordmark <nordmark@acm.org>, "nvo3@ietf.org" <nvo3@ietf.org>
Thread-Topic: [nvo3] Role of control plane in draft-dt-nvo3-encap-01
Thread-Index: AQHS0A+RqUTKGmjfU0eu9tFlZdm12aH6jtUAgACYvwCAAI4NgP//jv6A
Date: Fri, 19 May 2017 14:34:40 +0000
Message-ID: <EABBD98B-89CA-41DD-A86D-FB3C3EFEECEB@vmware.com>
References: <CALx6S35GXTSx=eiBrVqbDDYrkaE1syQhStLBgRGyAVKGPzzfUg@mail.gmail.com> <7662c052-0bae-d409-c7bd-58f33797567d@acm.org> <CALx6S37QiGuDUnKsiJwani9oYm-5vGLTwP8jRnJ8ZFb1jHzQ-g@mail.gmail.com> <17e069b7-0ac8-5e64-f1c3-a45ff6a99f78@sonic.net> <CALx6S35q7guNUeWQCw4Azys9fB2SJds_ObTHS_8a0OtR02Gv4Q@mail.gmail.com>
In-Reply-To: <CALx6S35q7guNUeWQCw4Azys9fB2SJds_ObTHS_8a0OtR02Gv4Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: herbertland.com; dkim=none (message not signed) header.d=none; herbertland.com; dmarc=none action=none header.from=vmware.com;
x-originating-ip: [24.7.2.81]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR05MB3009; 7:1e3woy0wZX+/iMgvrcpnyI3KWEVrb1RuMAmejE7ZGXU9tHkiRqmSzMo9wsVZ3nBVimXKWbUuJm+vPL+Jehr0W2ldpT9bXNIXHuOcQkbuJkDDWqifVvWYE8ZuMnSoS4FPF7WgBB9CSyG3tpFrRZvGy8rsUsHDbaq1rV38gpa7HylxNd8gD5OHkyw0TJz/i1KisBniavJVtFns95G8WaglRmItBoXYNRzJ7pUGYSDQn0s37q8KtgdYgGrlgbU81FOk24Rsy8xpZRwRkPrQmyzflVDUdBd1x3PGN+kU/pU1Pi13pf5ByJwZpcB/vgjY5/IEfbhv1UbevFZcxxXFOQUq0A==; 20:X7S3dMXsw296+vHLr0p9jTpfXftztjozKgtSqBmOuFbs7P4M1nhaHiIulHS3H1EBuuxjBY8GFpKEHxQXlUYE0Ed96kMncQlpmnsF81H4r3ncH7oH01SFd86LvibXD+uzAqy0m/0Myd9yb16L1REKqPL52FmzwqjLlC8niavgZWc=
x-ms-traffictypediagnostic: BN6PR05MB3009:
x-ms-office365-filtering-correlation-id: 918d415b-145c-4b40-dae3-08d49ec42ebc
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN6PR05MB3009;
x-microsoft-antispam-prvs: <BN6PR05MB30098E276E304ED4CE6AAB5CBEE50@BN6PR05MB3009.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(10436049006162)(213716511872227);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(100000703036)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123564025)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:BN6PR05MB3009; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:BN6PR05MB3009;
x-forefront-prvs: 031257FE13
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39450400003)(39410400002)(39840400002)(39850400002)(24454002)(377454003)(189998001)(6246003)(53936002)(77096006)(6486002)(6512007)(3660700001)(122556002)(3280700002)(8656002)(54906002)(99286003)(6306002)(93886004)(6506006)(230783001)(38730400002)(33656002)(6436002)(2900100001)(83716003)(82746002)(5660300001)(305945005)(7736002)(76176999)(50986999)(53546009)(54356999)(478600001)(8936002)(8676002)(81166006)(4326008)(86362001)(575784001)(2950100002)(25786009)(229853002)(66066001)(102836003)(2906002)(3846002)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR05MB3009; H:BN6PR05MB3009.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <C4DFC8E0DCCFD947B1C8BB91B44DD8A1@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: vmware.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2017 14:34:40.0364 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3009
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/FXmr0nc8HVPP2iUNkCQRPEC5T2Y>
Subject: Re: [nvo3] Role of control plane in draft-dt-nvo3-encap-01
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 19 May 2017 14:34:45 -0000
On 5/19/17, 7:19 AM, "nvo3 on behalf of Tom Herbert" <nvo3-bounces@ietf.org on behalf of tom@herbertland.com> wrote: >On Thu, May 18, 2017 at 10:50 PM, Erik Nordmark <nordmark@sonic.net> wrote: >> On 05/18/2017 01:44 PM, Tom Herbert wrote: >>> >>> On Thu, May 18, 2017 at 10:03 AM, Erik Nordmark <nordmark@acm.org> wrote: >>>> >>>> >>>> Tom, >>>> >>>> I'm trying to make sure we capture the discussion about the control plane >>>> accurately. >>>> >>>> On 04/15/2017 03:19 PM, Tom Herbert wrote: >>>>> >>>>> >>>>> - I do not believe this is at all plausible. 1) This could only help >>>>> the endpoints and not intermediate devices. As point out two sentences >>>>> below transit nodes may need to process extensions. 2) This creates an >>>>> a dependency between data plane and control plane that is at odds with >>>>> the requirement for control plane independence (section 2.1 of Geneve >>>>> draft) 3) This would entail a serious design and implementation effort >>>>> that would likely only be ready long after the dataplane has been >>>>> deployed. 4) This creates new problems for interoperability, for >>>>> instance two devices could support same set of options but can't >>>>> interoperate because they need different orderings. >>>> >>>> >>>> >>>> First of all, the intermediate devices would always have a harder time, >>>> especially as they might be of an older vintage than the NVEs; the >>>> classical >>>> ossification problem caused by things in the middle. >>>> >>>> The draft suggests >>>> The Geneve draft could specify that the subset and order of option >>>> TLVs should be configurable for each remote NVE in the absence of a >>>> protocol control plane. >>>> thus there is a way to get this off the ground. >>>> >>>> I don't think it would be hard to specify how this is carried in an IETF >>>> standard control plane such as EVPN. >>>> >>>> Note that there are two places where the control plane can help. >>>> 1. The egress NVE only needing to deal with the subset of the defined >>>> extensions that it implements. >>>> 2. The egress NVE being able to control the order of the extensions in >>>> the >>>> packet. >>>> >>>> Are your concerns only about the second? >> >> >> Repeating the above question since you didn't answer: Do you have any >> concerns about #1 i.e. the ability for the egress NVE to specify the set of >> extensions it supports? >> >I'm sorry, I thought I answered the question below. No to that. Not sure, I get that, why wouldn’t an NVE be capable to specify the set of Extensions it support? Thanks, Sami > >> >>>> >>> It's not clear to me how negotiated ordering helps, nor how to resolve >>> conflicting ordering constraints between to nodes: e.g. for options >>> A,B,C I might want to send them in order ABC, but maybe you can only >>> receive them as CBA. Who wins? >> >> >> For the ordering part (i.e., #2 above) just as the set (#1) it is the egress >> NVE which makes a statement in the control plane. >> Hence no conflicts. >> But an ingress NVE would need to be capable of including different subsets >> (#1) and different order (#2) when encapsulating to different egress NVEs. >> >Sounds like a lot of complexity to me without a well defined benefit. >I'd suggest investigating some specific examples and implementation to >evaluate whether a negotiated ordering can be helpful and to whom. > >Tom > >> Erik >> >> >> >>> >>>> I think for concerns about the amount of headers the hardware can parse, >>>> the >>>> first one is the key one. And it also handles the somewhat esoteric case >>>> of >>>> an egress NVE only supporting one extension. >>>> >>>> Thus if the WG thinks the ordering (for egress NVEs which support two or >>>> more extensions) is not important then WG can remove the ordering part >>>> while >>>> keeping the subset part. >>>> >>> It always makes sense to send the minimal amount of information and no >>> more, but endpoint negotiation doesn't take intermediate nodes into >>> account and they might drop packets if their parsing buffer is >>> exceeded. This is a generic problem that is not specific to >>> encapsulation, for instance extension headers can push things over the >>> limit. To that end I proposed a "Headers too long" ICMP error in 6man >>> to provide a feedback signal. >>> >>> Tom >>> >>>> Erik >>>> >>>> >>>> >>>> >>> >> > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_nvo3&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=o-PlsWullzzWQ-0KCJSX46anwVXVyMF9dg80UDgScZA&s=1qGNWNtbytQZXrTSRn6Gm49QmBEParIlBAVi-eVZTVM&e=
- [nvo3] Review of draft-dt-nvo3-encap-01 Tom Herbert
- Re: [nvo3] Review of draft-dt-nvo3-encap-01 Sami Boutros
- Re: [nvo3] Review of draft-dt-nvo3-encap-01 Tom Herbert
- Re: [nvo3] Review of draft-dt-nvo3-encap-01 Tom Herbert
- [nvo3] Role of control plane in draft-dt-nvo3-enc… Erik Nordmark
- Re: [nvo3] Role of control plane in draft-dt-nvo3… Tom Herbert
- Re: [nvo3] Role of control plane in draft-dt-nvo3… Erik Nordmark
- Re: [nvo3] Role of control plane in draft-dt-nvo3… Tom Herbert
- Re: [nvo3] Role of control plane in draft-dt-nvo3… Sami Boutros
- Re: [nvo3] Role of control plane in draft-dt-nvo3… Tom Herbert
- Re: [nvo3] Role of control plane in draft-dt-nvo3… Erik Nordmark