Re: [nvo3-dt-encap] [nvo3] Encap draft published by design team

Greg Mirsky <> Tue, 14 February 2017 02:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC9A6129437; Mon, 13 Feb 2017 18:40:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jv4QA3aeMA79; Mon, 13 Feb 2017 18:40:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB046129434; Mon, 13 Feb 2017 18:40:00 -0800 (PST)
Received: by with SMTP id 32so83010245oth.3; Mon, 13 Feb 2017 18:40:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=68zEbLt1SnI4yk3DvoDhz9rSJCsk+4XQb190slKOZ6M=; b=ZjGi7cbZbb0oF+3Ql8cOkHoRxg1KyEhQ6eFi2kuGldX7WSIkDiWP9Zbi7Y+P2hxYcP U8htjkgpDpPJq59INhqvCRZYuS4lJPqNyCg0Fi/FAg2DtIyGfQWGGFHqe8AP3J4Yuubm hp9O2GBUWgpkG62MpUeiR0X/xL/ggWJSOt+IWpoF7JslnQwSACybEHVr1lvjggdvmgLT 9iu3je7RbP/Nsbs13Czkuj/E47JS7ZC17Oy4vvkHY8ys+0NYEsxR44gsDzxZyhFsFx3a uyMGxrYLKy7uYdN+lP84B+lskF65Z6ZVOjP2eRs3//DGUVcQ7yWMKFU8XqletZQJvqDU E3nQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=68zEbLt1SnI4yk3DvoDhz9rSJCsk+4XQb190slKOZ6M=; b=C1taLC9YecdZ9F5dqLe0DYdMqXlxvqhJPpoy5ZXoqmgzrXVq4EYMvmFKYAUtAoU8hQ SM0UUUg9LMMSmDiWapL2OJX9qPo267t1qNvJNapQEbf6UIuleyYQLlnGKvslHkTnD71e zsicr5kf4M53RfVeCsGxS48X3Gi8P1NXvQZc5iiWQa+YEXs/px/D1X8db+VP1+yruzZh bD8ui+JxtWIStssqIzkrBuRWrqjC+2v29vKqwQxIgusc1cLvMbr2qbovxB0wFgxvbevE Nu+ploa8/ak1TN6EbhWtHW63hQ7F4cuBJSMEBWndj+SHTw7EmGCGXJeQf8AWbWOyrPpu OaiQ==
X-Gm-Message-State: AMke39kULHVBJrIqAyhdnj8lYrOpF0yVyVRWoLNCEpJkmNSvPBDVH5ZKbiTgUeFk98DYaB9gdL1085ofKQIoEA==
X-Received: by with SMTP id h9mr13631934ote.40.1487040000169; Mon, 13 Feb 2017 18:40:00 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 13 Feb 2017 18:39:59 -0800 (PST)
In-Reply-To: <>
References: <>
From: Greg Mirsky <>
Date: Mon, 13 Feb 2017 18:39:59 -0800
Message-ID: <>
To: Sam Aldrin <>
Content-Type: multipart/alternative; boundary=001a11402c02fa1f230548747a0e
Archived-At: <>
X-Mailman-Approved-At: Fri, 24 Feb 2017 08:47:02 -0800
Cc: "" <>,,
Subject: Re: [nvo3-dt-encap] [nvo3] Encap draft published by design team
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Private mailing list for internal NVO3 Encapsulation Design Team discussions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Feb 2017 02:40:03 -0000

Dear Authors, WG Chairs, et. al,
firstly, many thanks to the Design Team for very good start. Please find my
notes, comments to the document below. Greatly appreciate your kind

   - Section 2 states "The chosen design should also operate well with ICMP
   and in ECMP environments." While I understand ECMP environment and possible
   ways to generate entropy value for path selection, I'm bit puzzled by role
   of ICMP can play. Is it to suggest use of particular OAM mechanism?
   - Section on Telemetry, in my opinion, overlooks value of mechanism that
   generates entropy value at the edge instead of generating it at transit
   nodes. This mechanism is known in IP/MPLS as Entropy label and being
   proposed in BIER encapsulation header as Entropy field. I think that NVO3
   header can benefit from allocating the Entropy field. Then, ensuring that
   active OAM messages share the same path as data packets would be as simple
   as using the same Entropy value. More so, by applying different values
   active OAM be able to monitor all available multipaths even if there's no
   data traffic.
   - I believe that "in band parameters" is misleading and confusing
   terminology. Active OAM can be and, in my opinion, must be in-band, i.e.
   receive the same forwarding and scheduling treatment as data flow being

   - Now I'm making assumption that the draft-ietf-nvo3-geneve should be
   used to discuss format of NVO3 header proposed by the design team.
      - If that is correct, I'm interested to discuss benefit of using O
      bit to specify that OAM message follows the NVO3 header vs. define OAM as
      one of values of Protocol Type field.
      - If the OAM message identified by value of Protocol Type field, then
      the O bit can be reused for passive performance measurement
(allocating two
      bit-long field would be ideal).


On Thu, Feb 9, 2017 at 9:03 AM, Sam Aldrin <> wrote:

> Hello NVo3 WG,
> NVo3 Design Team for encap has put in quite a bit of effort to meet,
> discuss and hashout various requirements and issues and coming up with a
> draft on proposed encap. Thanks to all who have participated and made it
> possible.
> This document could be found at
> URL:  
> encap-00.txt
> Status:
> Htmlized:
> Kindly go through the document and review thoroughly and provide your
> comments.
> This will enable DT to close any issues or pending gaps.
> cheers
> Sam & Matthew
> _______________________________________________
> nvo3 mailing list