Re: [nvo3] Role of control plane in draft-dt-nvo3-encap-01
Tom Herbert <tom@herbertland.com> Fri, 19 May 2017 14:19 UTC
Return-Path: <tom@herbertland.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 163F71276AF for <nvo3@ietfa.amsl.com>; Fri, 19 May 2017 07:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 fuD5Vd5j-laS for <nvo3@ietfa.amsl.com>; Fri, 19 May 2017 07:19:09 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 586351275AB for <nvo3@ietf.org>; Fri, 19 May 2017 07:19:09 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id y201so62072387qka.0 for <nvo3@ietf.org>; Fri, 19 May 2017 07:19:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k+6u3npPEQV8e5MEuWr8pwX5cb0i6mWw/L2CRyi65lw=; b=qTVBztaEIEq+3sQQFXF1Tn5uRyX5S+DLDSuArauBT9P+nYAD+N73LZ4I+71742k6Mr ZiGzmVHTqHj4S7zuV3UetFHK3VYGih8YVBVzAAh4DzFI5dJV7D2lsc+pPnfUjy0I3tGl cM5BwHjaor6L5MGkzvlePLnc3kGtHAlBSA+eylsaH+AG8lQVI0OYzZSiALrXdNkYjuuO ehEnzpivYkriedix4FKw9H+E76EvTaIVdiDfa0S77B1gVKPrHuAsw5/9Yayf9nNvIkiA xzUU7ksTF+2Z8SoVMydCJmtp3etkFXeb4dVx8ufy+4Y8CGRVTW7Q1pE7desW5TYnr4D4 oHQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k+6u3npPEQV8e5MEuWr8pwX5cb0i6mWw/L2CRyi65lw=; b=qXIPnUnba1NraChzWmZd1jFpPF9uubroCbUClYnAjy1BpAzvKvRdX5wENIDYUzOC0b JlA4bIGCiI9gVgGrCKAKyCXqgCt9X2ReELjk4c+qdL/YcD2YEt9Th2cH3rcmHTzgy4jP 0h30tyMYVyJh3EbOggMLn/f3wVjKkvbnKt4pyhl6OWahz//JsnOwg+IZKCHdlpf04qCI ePFmV+9yweocL9CS1G35NWFnCR8F0IPYGiDese1QoT6jBluo3PIRCAkQUsYMu18Jxu1D hHP7RJHKXKrOl0yepYuOATUxFNRwLR1vaWu7uKyVGlthJvcw7sz9nrWiUcWcPQZASnRb uOWQ==
X-Gm-Message-State: AODbwcDgquK2kafacKxoDXs/96+lL7rg/kH6c3nVG9s9PJL4RnHUv6aD vLNb9R70/4X77PPz+E3rweTnOm8QDpbb
X-Received: by 10.55.197.92 with SMTP id p89mr8534719qki.34.1495203548487; Fri, 19 May 2017 07:19:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Fri, 19 May 2017 07:19:07 -0700 (PDT)
In-Reply-To: <17e069b7-0ac8-5e64-f1c3-a45ff6a99f78@sonic.net>
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>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 19 May 2017 07:19:07 -0700
Message-ID: <CALx6S35q7guNUeWQCw4Azys9fB2SJds_ObTHS_8a0OtR02Gv4Q@mail.gmail.com>
To: Erik Nordmark <nordmark@sonic.net>
Cc: Erik Nordmark <nordmark@acm.org>, "nvo3@ietf.org" <nvo3@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/AJ7WAKHuynM-f3CmO9FBPpy9BjQ>
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:19:11 -0000
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. > >>> >> 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] 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