Re: [Rtg-ooam-dt] O-OAM Requirements

David Mozes <davidm@mellanox.com> Sun, 03 January 2016 08:50 UTC

Return-Path: <davidm@mellanox.com>
X-Original-To: rtg-ooam-dt@ietfa.amsl.com
Delivered-To: rtg-ooam-dt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763431A90B1 for <rtg-ooam-dt@ietfa.amsl.com>; Sun, 3 Jan 2016 00:50:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 Q_rEKwAOoiN8 for <rtg-ooam-dt@ietfa.amsl.com>; Sun, 3 Jan 2016 00:50:27 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0082.outbound.protection.outlook.com [104.47.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE1321A90B0 for <rtg-ooam-dt@ietf.org>; Sun, 3 Jan 2016 00:50:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox365.onmicrosoft.com; s=selector1-Mellanox-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mH9CK38d+Bgi8BK0TbhJT5FmShKuP+XYvKJkF/Vcm2I=; b=Cqy7JJ84MvvMmawb1PG9W4ueQ0qtieobUwZ6QH5jqupZbJ+4BsPSBGs1FDDu3vAV6BxmeKTSmEq8X0IKn6ZlBceKMmKolUwBtuyI9YZH66tXwvWXJTK368gvV8B2V8/3n4emVI0sJ5E+QlFIzFr07tMPQNTxHvPKrE7XGdbI+6w=
Received: from VI1PR05MB1456.eurprd05.prod.outlook.com (10.164.85.26) by VI1PR05MB1456.eurprd05.prod.outlook.com (10.164.85.26) with Microsoft SMTP Server (TLS) id 15.1.361.13; Sun, 3 Jan 2016 08:50:22 +0000
Received: from VI1PR05MB1456.eurprd05.prod.outlook.com ([10.164.85.26]) by VI1PR05MB1456.eurprd05.prod.outlook.com ([10.164.85.26]) with mapi id 15.01.0361.006; Sun, 3 Jan 2016 08:50:22 +0000
From: David Mozes <davidm@mellanox.com>
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
Thread-Topic: [Rtg-ooam-dt] O-OAM Requirements
Thread-Index: AQHRPkvjJ+k9zTW3h0a6gOsGVKRsAZ7fCKVwgAKcJOCAAnFSUIAAsLQggADosDCAATSJAIAACauAgAKcZ8A=
Date: Sun, 03 Jan 2016 08:50:22 +0000
Message-ID: <VI1PR05MB1456DAA8C886D9A683CF7BAFB6F10@VI1PR05MB1456.eurprd05.prod.outlook.com>
References: <D2A0E1EE.CAFD4%naikumar@cisco.com> <7347100B5761DC41A166AC17F22DF112219726E0@eusaamb103.ericsson.se> <VI1PR05MB145638029CC55E0757204178B6FC0@VI1PR05MB1456.eurprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF112219745FA@eusaamb103.ericsson.se> <VI1PR05MB1456CC55D9075138E672DE7AB6FE0@VI1PR05MB1456.eurprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF11221974B6D@eusaamb103.ericsson.se> <8B3E00BB-FE59-4745-B18E-337CDC0D9BC0@mellanox.com> <7347100B5761DC41A166AC17F22DF11221974DA7@eusaamb103.ericsson.se>
In-Reply-To: <7347100B5761DC41A166AC17F22DF11221974DA7@eusaamb103.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=davidm@mellanox.com;
x-originating-ip: [193.47.165.251]
x-microsoft-exchange-diagnostics: 1; VI1PR05MB1456; 5:SUrnC+igPyx8PcmPvFi2+Q+oUzby4glwOm0DLXlueOYldrbtCbrYY5Yfc7IjTp39QbdZvmzLGR6H0vM2aTm8MwNKSNyyXEzvJ2Bxj/lryvmcCZzivBjzb2g3Qt5PMXSDTrdAHDpO8nfccQxSZoIipg==; 24:JB2L9FU8whh+OvgzM5a9Qz/MLNHjU0Jn7jNrgqSVfXP9PWYVy5lo1qPJFIm4tn5MEbQ0PjhpKXE2LS/HbQJ5eGAZODOxz4I891Xx3aLHgvs=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR05MB1456;
x-microsoft-antispam-prvs: <VI1PR05MB14560A66F96D0C197A934E9DB6F10@VI1PR05MB1456.eurprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(34787635062028)(95692535739014)(37575265505322);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR05MB1456; BCL:0; PCL:0; RULEID:; SRVR:VI1PR05MB1456;
x-forefront-prvs: 0810818DA0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(377454003)(76104003)(199003)(51444003)(164054003)(189002)(5004730100002)(122556002)(40100003)(11100500001)(76576001)(76176999)(97736004)(19580395003)(105586002)(19617315012)(106116001)(77096005)(54356999)(19609705001)(66066001)(4326007)(5003600100002)(102836003)(93886004)(106356001)(5002640100001)(15975445007)(5001960100002)(586003)(5008740100001)(3846002)(6116002)(110136002)(81156007)(790700001)(230783001)(87936001)(19580405001)(92566002)(10400500002)(74316001)(33656002)(101416001)(1096002)(2900100001)(50986999)(19625215002)(1220700001)(16236675004)(19300405004)(189998001)(86362001)(2950100001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR05MB1456; H:VI1PR05MB1456.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR05MB1456DAA8C886D9A683CF7BAFB6F10VI1PR05MB1456eurp_"
MIME-Version: 1.0
X-OriginatorOrg: Mellanox.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2016 08:50:22.3765 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB1456
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-ooam-dt/cKwIauULy5Ap8kMT2cZJum5dkXI>
Cc: "rtg-ooam-dt@ietf.org" <rtg-ooam-dt@ietf.org>, "Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com>, "Alia Atlas (akatlas@gmail.com)" <akatlas@gmail.com>
Subject: Re: [Rtg-ooam-dt] O-OAM Requirements
X-BeenThere: rtg-ooam-dt@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 03 Jan 2016 08:50:36 -0000

Yes  ,sure
Do You will send  WebEx innovation for the meeting on Tuesday   ?

Thx
David


From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Friday, January 01, 2016 7:03 PM
To: David Mozes <davidm@mellanox.com>
Cc: Nagendra Kumar Nainar (naikumar) <naikumar@cisco.com>; rtg-ooam-dt@ietf.org; Alia Atlas (akatlas@gmail.com) <akatlas@gmail.com>
Subject: RE: [Rtg-ooam-dt] O-OAM Requirements

Hi David,
happy New Year and thank you for your response.
For overlay network, like BIER domain, for example, Traceroute would work from BFR to BFR. I think we’ve made it work in BIER Ping and Trace<https://tools.ietf.org/html/draft-kumarzheng-bier-ping-01>
If we agree on NVO3 case, let’s look through BIER and SFC (for this one I’d propose to discuss OAM model first – is SF included in SFC OAM or SFC OAM stops at SFF and SFF to SF mapping is inter-layer OAM issue).
I’d like to keep us moving. Tuesday next week?

                Regards,
                                Greg

From: David Mozes [mailto:davidm@mellanox.com]
Sent: Friday, January 01, 2016 8:20 AM
To: Gregory Mirsky
Cc: Nagendra Kumar Nainar (naikumar); rtg-ooam-dt@ietf.org<mailto:rtg-ooam-dt@ietf.org>; Alia Atlas (akatlas@gmail.com<mailto:akatlas@gmail.com>)
Subject: Re: [Rtg-ooam-dt] O-OAM Requirements

Hi Gregory ,
Sure i agree with you regarding the Mip's and that their is no intermedia nodes on NVO3.
However , there is a problem here
Trace Rote will  not work to the virtual network users . My Q , It is not one of our  scopes to try solving this ?


Thx
David
On Jan 1, 2016, at 12:03 AM, Gregory Mirsky <gregory.mirsky@ericsson.com<mailto:gregory.mirsky@ericsson.com>> wrote:
Hi David,
yes, verification of inter-layer mappings or control plane to data plane mappings, which is  connectivity verification, is valuable and should be among the OAM requirements. But I don’t think of these as tracing the network elements at particular layer, i.e. doing the traceroute. In NVO3 reference model I don’t find intermediate or transient nodes but only edge nodes. Hence I conclude that ping and traceroute in NVO3 environment will produce the same results.

                Happy New Year!

                                Regards,
                                                Greg

From: David Mozes [mailto:davidm@mellanox.com]
Sent: Thursday, December 31, 2015 12:11 AM
To: Gregory Mirsky; Nagendra Kumar Nainar (naikumar); rtg-ooam-dt@ietf.org<mailto:rtg-ooam-dt@ietf.org>
Cc: Alia Atlas (akatlas@gmail.com<mailto:akatlas@gmail.com>)
Subject: RE: [Rtg-ooam-dt] O-OAM Requirements

Hi Gregory  ,
I thinks the MIP points  that we like to trace is actually the underlay network  path between the NVEs .
One method is to  use the same ideas as in traceroute (ttl)   Erik  has some draft on that  .
There are other methods  using the OAM bits on the  uncap header e.g.  VXLAN-GPE/GENEVE    etc ..

Happy new year to all

David

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Wednesday, December 30, 2015 11:41 PM
To: David Mozes <davidm@mellanox.com<mailto:davidm@mellanox.com>>; Nagendra Kumar Nainar (naikumar) <naikumar@cisco.com<mailto:naikumar@cisco.com>>; rtg-ooam-dt@ietf.org<mailto:rtg-ooam-dt@ietf.org>
Cc: Alia Atlas (akatlas@gmail.com<mailto:akatlas@gmail.com>) <akatlas@gmail.com<mailto:akatlas@gmail.com>>
Subject: RE: [Rtg-ooam-dt] O-OAM Requirements

Hi David,
agree, ability to trace a path is one of the most valuable troubleshooting mechanisms. I’ll make it clear in the draft.
One question regarding NVO3 environment. For example, BIER architecture is not only allows but requires that transient nodes, Bit-Forwarding Routers, used in BIER domain between Bit-Forwarding Ingress Router (BFIR) and Bit-Forwarding Egress Router (BFER). What may be viewed as transient virtual node in NVO3 reference model? If NVO3 OAM domain among NVEs, then, if I use terminology of connection-oriented networks OAM, where our MIPs to trace? I think I can see only MEPs at NVEs. Greatly appreciate you comments.

Happy New Year to All!

                Regards,
                                Greg

From: David Mozes [mailto:davidm@mellanox.com]
Sent: Tuesday, December 29, 2015 12:14 AM
To: Gregory Mirsky; Nagendra Kumar Nainar (naikumar); rtg-ooam-dt@ietf.org<mailto:rtg-ooam-dt@ietf.org>
Cc: Alia Atlas (akatlas@gmail.com<mailto:akatlas@gmail.com>)
Subject: RE: [Rtg-ooam-dt] O-OAM Requirements

Hi ,
I think we need
 need Route tracing

https://tools.ietf.org/html/rfc5860#page-11

Or the similar on NVO3   proposals

Thx
David
From: Rtg-ooam-dt [mailto:rtg-ooam-dt-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Sunday, December 27, 2015 6:35 PM
To: Nagendra Kumar Nainar (naikumar) <naikumar@cisco.com<mailto:naikumar@cisco.com>>; rtg-ooam-dt@ietf.org<mailto:rtg-ooam-dt@ietf.org>
Cc: Alia Atlas (akatlas@gmail.com<mailto:akatlas@gmail.com>) <akatlas@gmail.com<mailto:akatlas@gmail.com>>
Subject: Re: [Rtg-ooam-dt] O-OAM Requirements

Hi Nagendra,
thank you for your comments.
I agree with PMTUD. Though am not certain about the ECMP as far as pro-active monitoring if only tracing, i.e. on-demand. I think it would be great topic for us to discuss during the next call.
Would January 5th, 2016 @ 07:00 PST work? Would Tuesdays @ 07:00 PST work as regular meeting time?

                Regards,
                                Greg

From: Nagendra Kumar Nainar (naikumar) [mailto:naikumar@cisco.com]
Sent: Thursday, December 24, 2015 5:06 AM
To: Gregory Mirsky; rtg-ooam-dt@ietf.org<mailto:rtg-ooam-dt@ietf.org>
Cc: Alia Atlas (akatlas@gmail.com<mailto:akatlas@gmail.com>)
Subject: Re: [Rtg-ooam-dt] O-OAM Requirements

Hi Greg,

Merry Christmas and Happy New year!!

It is a good start. A couple of points that quickly popped up are below:

1. ECMP awareness - I think we should also include ECMP awareness as one of the requirement.  We may need a right terminology that depicts ECMP and is applicable on different overlay.
2. Path MTU – I see this as one of the topic coming up with different overlay. It is better to include this in the requirement.

Will read more and share any more comments.

Thanks,
Nagendra

From: Rtg-ooam-dt <rtg-ooam-dt-bounces@ietf.org<mailto:rtg-ooam-dt-bounces@ietf.org>> on behalf of Gregory Mirsky <gregory.mirsky@ericsson.com<mailto:gregory.mirsky@ericsson.com>>
Date: Wednesday, December 23, 2015 at 11:05 PM
To: "rtg-ooam-dt@ietf.org<mailto:rtg-ooam-dt@ietf.org>" <rtg-ooam-dt@ietf.org<mailto:rtg-ooam-dt@ietf.org>>
Cc: "Alia Atlas (akatlas@gmail.com<mailto:akatlas@gmail.com>)" <akatlas@gmail.com<mailto:akatlas@gmail.com>>
Subject: [Rtg-ooam-dt] O-OAM Requirements

Dear All,
happy holidays, Merry Christmas and Happy New Year to All!

I put down some OAM requirements. Greatly appreciate your comments. Can we put it somewhere, somehow for everyone to edit?

You’ll notice that some requirements are explicitly point to unidirectional character of OAM. I think that services provided y an overlay network are unidirectional and bi-directional Fault Monitoring and Performance Measurement are unnecessary. Though in some cases egress node may use IP network to send notification to the ingress node. What do you think?

                Regards,
                                Greg