[nvo3] Role of control plane in draft-dt-nvo3-encap-01

Erik Nordmark <nordmark@acm.org> Thu, 18 May 2017 19:47 UTC

Return-Path: <nordmark@acm.org>
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 3B7AD129B0E for <nvo3@ietfa.amsl.com>; Thu, 18 May 2017 12:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.765
X-Spam-Level:
X-Spam-Status: No, score=0.765 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 aS4UfImf5KkW for <nvo3@ietfa.amsl.com>; Thu, 18 May 2017 12:47:16 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 817DF12E042 for <nvo3@ietf.org>; Thu, 18 May 2017 12:41:44 -0700 (PDT)
Received: from [192.168.1.125] (107-128-215-68.lightspeed.sntcca.sbcglobal.net [107.128.215.68]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v4IJfc00031167 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 May 2017 12:41:41 -0700
To: Tom Herbert <tom@herbertland.com>, "nvo3@ietf.org" <nvo3@ietf.org>
References: <CALx6S35GXTSx=eiBrVqbDDYrkaE1syQhStLBgRGyAVKGPzzfUg@mail.gmail.com>
From: Erik Nordmark <nordmark@acm.org>
Message-ID: <7662c052-0bae-d409-c7bd-58f33797567d@acm.org>
Date: Thu, 18 May 2017 13:03:23 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CALx6S35GXTSx=eiBrVqbDDYrkaE1syQhStLBgRGyAVKGPzzfUg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVZhGf5peJzgbP9NNcd0bI2aiVDhqhI0RpMQyb6guzmXhaVVmDPCBFPTa8ydHoj4bUMbsmnrc0VYOCeoKZ13lnmAGRMTHG1sEJo=
X-Sonic-ID: C;ZqAWAgI85xGvfSzL7bdh1w== M;pDK4AwI85xGvfSzL7bdh1w==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/Q5mF8gGOYYa-7arMDngS4y56BU0>
Subject: [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: Thu, 18 May 2017 19:47:17 -0000

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?

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.

    Erik