Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)
"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Tue, 09 August 2016 22:07 UTC
Return-Path: <cpignata@cisco.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 7643F12D108; Tue, 9 Aug 2016 15:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.767
X-Spam-Level:
X-Spam-Status: No, score=-15.767 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 PbVgt3K86NCu; Tue, 9 Aug 2016 15:07:49 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0777D12B037; Tue, 9 Aug 2016 15:07:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43252; q=dns/txt; s=iport; t=1470780468; x=1471990068; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0GTGwtYTB0H6lYq7Ikwwzmel9815gSyoroYzU89frJ4=; b=VuvAc30uNd8Nn3XC9006/MvBQa2piyU+wMfF+n10h8fCMSNsUtJ65NX+ 9woVqpwDLpIqqjiHzYXfZUJDS91pj1Y7A+4rb2QDsPBQqFgYoImhfp1Fg 8UEo7bergv42yClP6Ef3Kz8YZuKWzjwPBWkPGtozDraExzKDnNy90aYiA 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BHAgCXU6pX/40NJK1TCoJ3TlZ8B6x1jCiBfSaFdwIcgTI4FAEBAQEBAQFdJ4RfAQUBASFLCxACAQg4AQYDAgICHwYLFBECBA4FG4d8AxcOsR2Lag2EMgEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhiqBeAiCTYJDgU4HBDsVglUrgi8Fk3WFEDQBhhxxhUGCO4FrjViILYQHg3cBHjaCRYE1boVnRn8BAQE
X-IronPort-AV: E=Sophos;i="5.28,496,1464652800"; d="scan'208,217";a="136088456"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Aug 2016 22:07:47 +0000
Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u79M7lh9014620 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Aug 2016 22:07:47 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 9 Aug 2016 18:07:44 -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.1210.000; Tue, 9 Aug 2016 18:07:44 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Tom Herbert <tom@herbertland.com>
Thread-Topic: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)
Thread-Index: AQHR8dc+vjqdm4diEEmKbNt0PpwCX6BBD5CAgAAGEQCAACr5AIAAAyeAgAAwiIA=
Date: Tue, 09 Aug 2016 22:07:44 +0000
Message-ID: <80ABDBE3-BC90-4741-9230-F32B7FC06558@cisco.com>
References: <CA+RyBmVzweMMTK3=ystVBMgWt3pxfCQ35qWgWH8ewhB=JO5nvQ@mail.gmail.com> <CALx6S35_E+hwFPYvdYWLUm2rVGKpNMObD_cPy-ooEhDoUks4hQ@mail.gmail.com> <CA+RyBmXMQ_DWTSWcpHta34P2zMU96AzcRWUs6Pn5Vva6r9Y=Xw@mail.gmail.com> <CALx6S34WUnTEZ8H770eFvO+5wZ9XSfNRbuSYWDBtNKOBTeKVRA@mail.gmail.com> <6959298E-B4E9-4593-9F0C-A384CF730A74@cisco.com> <CALx6S36KPOcfnsjELHZ5pf2NVqbEihni_+1=PnzHX_d2Fc7JUw@mail.gmail.com>
In-Reply-To: <CALx6S36KPOcfnsjELHZ5pf2NVqbEihni_+1=PnzHX_d2Fc7JUw@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.150.49.8]
Content-Type: multipart/alternative; boundary="_000_80ABDBE3BC9047419230F32B7FC06558ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-ooam-dt/jCkn4R0C7o5abgxiu_Mvjui389E>
Cc: "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>, Greg Mirsky <gregimirsky@gmail.com>, NVO3 <nvo3@ietf.org>, Alia Atlas <akatlas@gmail.com>, "rtg-ooam-dt@ietf.org" <rtg-ooam-dt@ietf.org>
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: Tue, 09 Aug 2016 22:07:51 -0000
Hi, Tom, On Aug 9, 2016, at 3:14 PM, Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>> wrote: On Tue, Aug 9, 2016 at 12:02 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com<mailto:cpignata@cisco.com>> wrote: On Aug 9, 2016, at 12:28 PM, Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>> wrote: On Tue, Aug 9, 2016 at 9:07 AM, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote: Hi Tom, many thanks for the most informative response. I've added mu notes in-line under tag GIM>>. Regards, Greg On Mon, Aug 8, 2016 at 5:44 PM, Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>> wrote: On Sun, Aug 7, 2016 at 7:02 PM, Greg Mirsky <gregimirsky@gmail.com<mailto: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. The C-bit in GUE distinguishes data messages from control messages.Data messages are considered to be the payload of encapsulation, whereas control messages are about the encapsulation itself. OAM might be one type of control message in GUE, however there could be others. For instance if we wanted some sort of negotiation between two endpoints to exchange capabilities or supported features this would fit well into a control message. GIM>> Yes, what I've proposed is clearly more than just OAM channel. In fact, it is Associated Channel (ACh) that may be used by control, management and OAM. And as I've used term "Associated Channel" you'll easily recognize that I have MPLS background and draw on MPLS/MPLS-TP OAM experience. And as Generic ACh (G-ACh) is used to advertise capabilities of an LSR in RFC 7212, AC-h in NVO3 can support similar functionalities as well. 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 . Then Each of the three protocols has a protocol next header field, however the field is defined differently among them. The next header in GUE is an IP protocol number, in Geneve it is an Ethertype, and VXLAN-GPE uses a new number space. In GUE we could probably use ICMP protocol for OAM by defining the appropriate types (that might have the advantage of allow OAM to be generic instead of restricted to only encapsulation). Presumably, VXLAN-GPE could define some value in the number space for for OAM. For Geneve maybe there is an appropriate Ethertype? 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. The problem I see with trying to constrain the solution to only one or two bits of information is that this substantially limits the functionality. With an extensible protocol we should be able more information to get more accurate measurement. For instance, I might want to measure the latency of individual packets to get feedback on path selection, correlate performance to packet loss, etc. Has the OAM DT considered the requirements and solutions for passive performance measurement? GIM>> Indeed, the OAM DT had considered the requirements to enable use of performance measurement methods as passive OAM. Should note that we use term "passive method" somewhat differently from the definition in RFC 7799. Such interpretation was discussed in the IPPM WG and we've agreed that if a measurement method does not change treatment of a data packet by the network (e.g. doesn't change its CoS, length or else), then the method behaves as close as passive and may be characterized as such. Measurements for a single packet are possible using the Alternate Marking method with two bits-long marker. The draft in BIER WG has such example. I've attached the presentation slides. Will be glad to answer any further questions. Yes, but number of specific packets I could measure is still limited in some time quantum with the two bit method. Alternatively, if every packet contained a timestamp for instance, then we can measure every packet and filter or aggregate the measurements with arbitrary granularity of our choosing. Indeed, as for example at draft-brockners-inband-oam-data-01. This is a measurement that is neither “active” nor “passive” based on the IETF definitions (where active means a probe, and passive means no change whatsoever to a packet). Carlos, Thanks for the pointer, that looks like a good basis for an extensible and generic OAM inband measurement mechanism. I assume for IPv6 this would be appropriate as options in HBH extension headers, have you defined the formats for that? Thanks — and you are exactly right: https://tools.ietf.org/html/draft-brockners-inband-oam-transport-01#section-3 This was demoed as IPv6 edge to edge in Bits-n-Bites in Berlin. Thanks, — Carlos. Thanks, Tom BIER may have been defined with as a fixed length header so that a couple of bits are all that could feasibly be allocated to OAM, but this is not necessarily true for other encapsulation protocols that are purposely extensible to support a richer set of features. Agreed as well. Thanks, — Carlos. Tom Thanks, Tom Regards, Greg On Fri, Jul 29, 2016 at 8:13 AM, Alia Atlas <akatlas@gmail.com<mailto: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<mailto: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<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 _______________________________________________ nvo3 mailing list nvo3@ietf.org<mailto:nvo3@ietf.org> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ Rtg-ooam-dt mailing list Rtg-ooam-dt@ietf.org<mailto:Rtg-ooam-dt@ietf.org> https://www.ietf.org/mailman/listinfo/rtg-ooam-dt
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Deepak Kumar (dekumar)
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Greg Mirsky
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Tom Herbert
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Deepak Kumar (dekumar)
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Greg Mirsky
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Deepak Kumar (dekumar)
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Greg Mirsky
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Carlos Pignataro (cpignata)
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Tom Herbert
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Carlos Pignataro (cpignata)
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Carlos Pignataro (cpignata)
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Greg Mirsky
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Tom Herbert
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Greg Mirsky
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Greg Mirsky
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Greg Mirsky
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Tom Herbert
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Greg Mirsky
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Joe Touch
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Larry Kreeger (kreeger)
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Tom Herbert
- Re: [Rtg-ooam-dt] O-bit vs. OAM as Next Protocol … Carlos Pignataro (cpignata)
- [Rtg-ooam-dt] O-bit vs. OAM as Next Protocol (Re:… Greg Mirsky
- Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Pr… Shahram Davari