Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

Shahram Davari <shahram.davari@broadcom.com> Mon, 08 August 2016 03:27 UTC

Return-Path: <shahram.davari@broadcom.com>
X-Original-To: rtg-ooam-dt@ietfa.amsl.com
Delivered-To: rtg-ooam-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4CC12D7CB for <rtg-ooam-dt@ietfa.amsl.com>; Sun, 7 Aug 2016 20:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 vPyqg-O57oCt for <rtg-ooam-dt@ietfa.amsl.com>; Sun, 7 Aug 2016 20:27:29 -0700 (PDT)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 5B22412D7C9 for <rtg-ooam-dt@ietf.org>; Sun, 7 Aug 2016 20:27:29 -0700 (PDT)
Received: by mail-pf0-x231.google.com with SMTP id x72so114504269pfd.2 for <rtg-ooam-dt@ietf.org>; Sun, 07 Aug 2016 20:27:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wmZ02VWYsfXuuUA/tto2Dl91eoxc/pm7LI+0mMjmo4M=; b=EL4xt/3kdLsiDeDQqb9uIwvhaZCTK0PDOaRsCl74JkfzsAYGy9ArWsvU5Cdqj5DZAJ g1REk5zrEd5OK+J4QMvIivcJ8EUPn6Cj7YpO607CDzPTYurZzdNBDOC6e7PBBS6X/TSQ i+7qeq/02P0+5iKX1Ee1fXowq9hAEAkZIqOhI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wmZ02VWYsfXuuUA/tto2Dl91eoxc/pm7LI+0mMjmo4M=; b=CMcCETnrI3u214Hd9EX2xPwl2htsH6a8FHTO+lq2V2iblga3+t/DRvMPgmgcRoKKOZ DVd/5ukkLGgT+Pn8nbNHS1Ol3FnW5oQfKurbmIdVnuXZVWHf2vOcWuW/qVFmNnAFaQ9/ Sh+x3Nrzxw1GVuQIMKFByiQsSUUEgix62VKy/rEWcICoqQlSQp6NQRU3DYRWIxqBY0fA rJ534j87Zx7/AToqySR86cnJbwAYZ2uTQFtJ0runqcA+3FJZPGCedi/EMEgs9Cf6iRKl EqRcnYUThzte2raoqDmlRuX1r+7nTw/vpJsIvXqKaPP0+hE/an6mhoasTEQ9/6r0YG+k lp1g==
X-Gm-Message-State: AEkoout1rYAmJrhbMYJOMC+tnSCHkYrgctuk/hpZQM2Z4JysHPKFGqjisdg8pZ33N36OCVFI
X-Received: by 10.98.135.13 with SMTP id i13mr158966778pfe.44.1470626848436; Sun, 07 Aug 2016 20:27:28 -0700 (PDT)
Received: from [192.168.0.49] (c-73-231-5-190.hsd1.ca.comcast.net. [73.231.5.190]) by smtp.gmail.com with ESMTPSA id b90sm43456976pfc.29.2016.08.07.20.27.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 07 Aug 2016 20:27:27 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-2E122C2B-D9D8-462E-B26F-38E0D175E402"
Mime-Version: 1.0 (1.0)
From: Shahram Davari <shahram.davari@broadcom.com>
X-Mailer: iPhone Mail (13F69)
In-Reply-To: <CA+RyBmVzweMMTK3=ystVBMgWt3pxfCQ35qWgWH8ewhB=JO5nvQ@mail.gmail.com>
Date: Sun, 07 Aug 2016 20:27:26 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <C7C984CC-3178-4389-BB94-3545B2A163BD@broadcom.com>
References: <CA+RyBmVzweMMTK3=ystVBMgWt3pxfCQ35qWgWH8ewhB=JO5nvQ@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-ooam-dt/pRd2P8LNXOIjQrRT6Dpzv2XT2KI>
Cc: "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>, rtg-ooam-dt@ietf.org, NVO3 <nvo3@ietf.org>, Alia Atlas <akatlas@gmail.com>
Subject: Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)
X-BeenThere: rtg-ooam-dt@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: List is used by the Routing Area Overlay OAM Design team for internal coordination and discussion <rtg-ooam-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-ooam-dt>, <mailto:rtg-ooam-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-ooam-dt/>
List-Post: <mailto:rtg-ooam-dt@ietf.org>
List-Help: <mailto:rtg-ooam-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-ooam-dt>, <mailto:rtg-ooam-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2016 03:27:33 -0000

Hi 

I agree with Greg. Flag bit is useful if there was no protocol type field. From HW perspective there no advantage of using flag rather than protocol field.

Regards,
Shahram


> On Aug 7, 2016, at 7:02 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
> 
> Dear Authors of the VxLAN-GPE, GUE, and GENEVE,
> all protocols under consideration use a bit flag rather than explicit protocol type to indicate that payload is a test packet, i.e. active OAM. I'm trying to understand the rationale of such decision. Does use of the bit flag rather than protocol type produce more efficient implementation, is more HW friendly? In GUE, the the field to indicate type of the payload even tagged Proto/ctype as its interpretation depends upon value of the C bit. But wouldn't it be simpler if all proposals used protocol type to identify OAM payload? And if the protocol type is OAM, then after the protocol header have OOAM Header, e.g. as proposed in draft-ooamdt-rtgwg-ooam-header. Then NVO3 protocols would be able to have common Active OAM (Fault Management and Performance Measurement) that can be used in BIER and SFC. And the bit, the bit I'd propose to redefine to be used for passive performance measurement as described in draft-ietf-bier-pmmm-oam. (Allocating two bits-long field would enable more accurate measurements using the Alternate Marking method).
> And these steps will enable us to develop common Active OAM and use passive performance measurement regardless, almost, of the data plane protocol used in NVO layer.
> 
> Regards, Greg
> 
>> On Fri, Jul 29, 2016 at 8:13 AM, Alia Atlas <akatlas@gmail.com> wrote:
>> I'd like to have people focus on the key point of this thread.
>> 
>> Are there serious technical objections (and specifically what are they) to moving forward with VXLAN-GPE as the standards-track protocol?
>> 
>> Are there serious technical objections (and specifically what are they) to moving forward with GENEVE as the standards-track protocol?
>> 
>> Are there serious technical objections (and specifically what are they) to moving forward with GUE as the standards-track protocol?
>> 
>> We need to capture any relevant objections.  So far, there's been some discussion on extensibility - with Tom Herbert providing concrete concerns.
>> 
>> I have concluded that almost all the authors would prefer to have no standards track solution if they can't guarantee that theirs is that standard.
>> 
>> I do hear concerns about whether a decision will be too late.   I think that a decision can only be helpful.   It goes back to when is the best time to plant a tree - with the answer of 20 years ago or now.
>> 
>> Regards,
>> Alia
>> 
>> 
>>> On Fri, Jul 29, 2016 at 4:34 AM, Naoki Matsuhira <matsuhira@jp.fujitsu.com> wrote:
>>> 
>>> 
>>>> On 2016/07/21 23:56, Bocci, Matthew (Nokia - GB) wrote:
>>>> WG
>>>> 
>>>> There was a discussion in the NVO3 WG meeting in Berlin following strong advice from our Area Director that we need to come to a consensus on converging on a common encapsulation. Two sets of questions were asked:
>>>> (1) Should the WG move forward with one standards track encap?
>>>> (2) For a given encap, do you have significant technical objections?
>>> 
>>> I want to inform to this mailing list that I proposed ME6E-FP and ME6E-PR at the yokohama meeting. I also have proposal M46E-FP and M46E-PR (past called SA46T).
>>> 
>>> These encapsulation technologies are based on address mapping. ME6E use IPv6 address which mapping MAC address, and M46E use IPv6 address which mapping IPv4 address.
>>> 
>>> I understand too many encapsulation technologies, however these my proposal are simple, and may contribute to the Internet.
>>> 
>>> I believe address mapping approach is unique, so I want to propose again.
>>> 
>>> sorry not the answer to the question.
>>> 
>>> Naoki Matsuhira
>>> 
>>> 
>>> _______________________________________________
>>> nvo3 mailing list
>>> nvo3@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nvo3
>> 
>> 
>> _______________________________________________
>> nvo3 mailing list
>> nvo3@ietf.org
>> https://www.ietf.org/mailman/listinfo/nvo3
> 
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3