Re: [nvo3] IETF101 NVO3 draft minutes posted

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Thu, 29 March 2018 12:21 UTC

Return-Path: <cpignata@cisco.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 3050F126DFF for <nvo3@ietfa.amsl.com>; Thu, 29 Mar 2018 05:21:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.819
X-Spam-Level:
X-Spam-Status: No, score=-6.819 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: DNS error: SERVFAIL)" header.d=cisco.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 2Y2U_OJ4qTKq for <nvo3@ietfa.amsl.com>; Thu, 29 Mar 2018 05:21:19 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86251200B9 for <nvo3@ietf.org>; Thu, 29 Mar 2018 05:21:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13800; q=dns/txt; s=iport; t=1522326078; x=1523535678; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=guSyGWVMuycWcZrvyLH6wUHcpPiQ/PEsLGSV2XIFkHU=; b=BhqGXUHW34aYvXW3Sdu9slZGkmHbReZVhq3HUv7mK5ik6L3LsoeNiOud jigYt2TFmAsPXVN0GNXqtkUl2vjI5w8CwzeXMIhkoIyYGNbKNVyxyorY/ +pHMr0ecDr6tliFuksMJAIgppQ4whwZGVuqDtb8KsZtLoWgQp1uM6Qmz/ 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DfAADw2Lxa/5NdJa1dGQEBAQEBAQEBAQEBAQcBAQEBAYMXK2FvKAqDUogAjQCBU4EwhmCHDYRkFIFmCxgBCoRhAhqDfSE0GAECAQEBAQEBAmsohSYCAQMBASFEBwsQAgEIPwMCAgIfBgsUEQIEDgWEKUwDFQ+sHoIchFWCMg2BLIIkBYdegVQ/gQwiDIJWgUGBDkIBAQMBgSUBDwMBgx8wgiQCkEKGRSwIAoVPhV+CfAqBJYNWhy2JFDuGBAIREwGBJAEcOGFxcBU6KgGCGIFwPIEFAQiNE2+ME4EggRcBAQ
X-IronPort-AV: E=Sophos; i="5.48,376,1517875200"; d="scan'208,217"; a="90617660"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Mar 2018 12:21:18 +0000
Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w2TCLHbr002187 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Mar 2018 12:21:18 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 29 Mar 2018 08:21:17 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1320.000; Thu, 29 Mar 2018 08:21:17 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: Ignas Bagdonas <ibagdona.ietf@gmail.com>, NVO3 <nvo3@ietf.org>
Thread-Topic: [nvo3] IETF101 NVO3 draft minutes posted
Thread-Index: AQHTxv6y4SdT+oWNgESnVjhEtPBbmaPm87wAgABrUoCAAAUBAIAAAeAA
Date: Thu, 29 Mar 2018 12:21:16 +0000
Message-ID: <E194C339-3632-4206-B2F1-6B7E2EE3ABFF@cisco.com>
References: <97aa0d9f-1b18-8689-a8e7-6f0fc9503433@gmail.com> <CA+RyBmWzV_DNn9VvKyX136bYc6XtTjZYps8MeXUxxxdwOyV0NA@mail.gmail.com> <973AA532-A23B-449F-ADB4-E95B15545ACF@cisco.com> <CA+RyBmUm3PHYpAiz5+O2xbe9z3ZCj9T-6ve_b4UYHA66brxoyg@mail.gmail.com>
In-Reply-To: <CA+RyBmUm3PHYpAiz5+O2xbe9z3ZCj9T-6ve_b4UYHA66brxoyg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.116.133]
Content-Type: multipart/alternative; boundary="_000_E194C33936324206B2F16B7E2EE3ABFFciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/eNRV-7GLWO_lLeeXwI97HhTrtBo>
Subject: Re: [nvo3] IETF101 NVO3 draft minutes posted
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, 29 Mar 2018 12:21:24 -0000

Hi Greg,

Thank you for the quick response!

On Mar 29, 2018, at 8:14 AM, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:

Hi Carlos,
I believe that introduction of the OAM Header with demultiplexing OAM functions through use of Msg Type will enable use of non-IP encapsulation, including for BFD and Echo Request/Reply (more on options to demultiplex active OAM functions could be found in draft-wang-sfc-multi-layer-oam<https://datatracker.ietf.org/doc/draft-wang-sfc-multi-layer-oam/>).

non-IP BFD works well already without this additional overhead. Each tunneling/encap has appropriate demos capabilities already.

Still, a header for demultiplexing (a protocol ID) for encapsulations that already have a protocol ID seems unnecessary. Further, it carries timestamps and flags for “capabilities”. So it is an OAM in its own to carry OAM.

The complete proposition sounds triply duplicative.

And I see ability to use non-IP encapsulation as more significant improvement even with relative cost of introducing OAM Header.
Thank you for your reference to RFC 7942. I will discuss your suggestion with co-authors and we'll consider adding such section.


Thank you. Look forward to seeing the Implementation Status.

Carlos.

Regards,
Greg

On Thu, Mar 29, 2018 at 2:56 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com<mailto:cpignata@cisco.com>> wrote:
Hi, Greg,

I was not in London, but if you do not mind, I will piggy back on this email to ask a couple of key questions that I still cannot figure out:

  1.  What is the objective of an OOAM, or what is purpose for adding an indirection, a shim, a nested header and additional lookup, to a bunch of encapsulations? The Abstract in draft-ooamdt-rtgwg-ooam-header says “to ensure that OOAM control packets are in-band with user traffic and de-multiplex OOAM protocols.” But frankly I cannot make sense of that sentence. The same holds equally true without OOAM and this will not change the behavior of active OAM methods. Imagine the performance of BFD buried under redundant fields to parse.
  2.  Could you add an Implementation Status section [RFC 7942] to this document?

Thanks,

Carlos.

On Mar 29, 2018, at 1:32 AM, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:

Hi Ignas,
another well-captured discussion, thank you. Few notes:

  *   I believe that in discussion of OOAM Header "?/Cisco" should be Frank Brockners
  *   would you consider splitting comments and responses with <CR><LF> to ease readability?

Kind regards,
Greg

On Thu, Mar 29, 2018 at 4:38 AM, Ignas Bagdonas <ibagdona.ietf@gmail.com<mailto:ibagdona.ietf@gmail.com>> wrote:
Working group,

Draft minutes for IETF101 NVO3 WG meeting have been posted at the meeting materials page.

https://datatracker.ietf.org/doc/minutes-101-nvo3/

Please take a look and provide any corrections if needed.

Thank you.

Ignas


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

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