Re: [Lime-oam-model] Design Team report

Gregory Mirsky <gregory.mirsky@ericsson.com> Thu, 19 March 2015 15:23 UTC

Return-Path: <gregory.mirsky@ericsson.com>
X-Original-To: lime-oam-model@ietfa.amsl.com
Delivered-To: lime-oam-model@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929C61A0390 for <lime-oam-model@ietfa.amsl.com>; Thu, 19 Mar 2015 08:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.75
X-Spam-Level:
X-Spam-Status: No, score=-101.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 X5f1t3E-8GrI for <lime-oam-model@ietfa.amsl.com>; Thu, 19 Mar 2015 08:23:00 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52C41A1A60 for <lime-oam-model@ietf.org>; Thu, 19 Mar 2015 08:22:55 -0700 (PDT)
X-AuditID: c618062d-f79686d0000030a8-3c-550a945402cd
Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 09.B4.12456.4549A055; Thu, 19 Mar 2015 10:18:13 +0100 (CET)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Thu, 19 Mar 2015 11:22:53 -0400
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Qin Wu <bill.wu@huawei.com>, Ronald Bonica <rbonica@juniper.net>, "lime-oam-model@ietf.org" <lime-oam-model@ietf.org>
Thread-Topic: Design Team report
Thread-Index: AQHQXjCGEz3Ksri7EUWS2NdU6r1BOJ0fxJnQgAB4KYD//+VX8IAAU2iAgACGCqCAANmWAIAAmPXAgAEjn4CAAA6TAP//v2vg
Date: Thu, 19 Mar 2015 15:22:53 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1121B9349F7@eusaamb103.ericsson.se>
References: <CO1PR05MB4422C6491A3B7179F229574AE130@CO1PR05MB442.namprd05.prod.outlook.com> <B8F9A780D330094D99AF023C5877DABA846DDFE9@nkgeml501-mbs.china.huawei.com> <CO1PR05MB4423E80AE097618FB4BED8CAE1C0@CO1PR05MB442.namprd05.prod.outlook.com> <B8F9A780D330094D99AF023C5877DABA846DF59E@nkgeml501-mbs.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B91C5EC@eusaamb103.ericsson.se> <CO1PR05MB442C0431388DF4DB33E1EF1AE180@CO1PR05MB442.namprd05.prod.outlook.com> <B8F9A780D330094D99AF023C5877DABA846E020F@nkgeml501-mbs.china.huawei.com> <CO1PR05MB4420B81383D0952B2BB3D27AE180@CO1PR05MB442.namprd05.prod.outlook.com> <B8F9A780D330094D99AF023C5877DABA846E1E86@nkgeml501-mbs.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B92F482@eusaamb103.ericsson.se> <B8F9A780D330094D99AF023C5877DABA84702B17@nkgeml501-mbs.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B92F643@eusaamb103.ericsson.se> <B8F9A780D330094D99AF023C5877DABA84704C4C@nkgeml501-mbs.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B92FA5F@eusaamb103.ericsson.se> <B8F9A780D330094D99AF023C5877DABA847066E3@nkgeml501-mbs.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B930603@eusaamb103.ericsson.se> <BLUPR05MB433DD2E1CBEDF363CB13884AE010@BLUPR05MB433.namprd05.prod.outlook.com> <B8F9A780D330094D99AF023C5877DABA8470BE79@nkgeml501-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA8470BE79@nkgeml501-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.9]
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B9349F7eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZXLonSjd0CleoQeN0EYvHcxewWvxc9Ynd omd1M7PFge8ODiweU35vZPVoOfKW1WPJkp9MHtebrrIHsERx2aSk5mSWpRbp2yVwZVzc3chS MHMfc8WVL7/ZGxh/zmPuYuTkkBAwkeiaeYYFwhaTuHBvPRuILSRwhFFi8VeJLkYuIHs5o8Tp YyuYQBJsAkYSLzb2sIPYIgLVEr9b94PZzAIGEn0HZoM1CwsoSHQ/OsYIUaMoMf3EVCYIO0/i 1/OtYItZBFQlLk1eAWbzCvhKzDy3ix1i2SUuieN3V4IlOAXCJM5uWskKYjMCXff91BomiGXi EreezGeCuFpAYsme81DfiEq8fPyPFcJWlNjXPx3quHyJPQfvsUIsE5Q4OfMJywRG0VlIRs1C UjYLSRlEXEtiXsNvqBpFiSndD9khbE2JK5MPQdnaEssWvmZewMi+ipGjtDi1LDfdyGATIzAC j0mw6e5g3PPS8hCjAAejEg9vATNXqBBrYllxZe4hRmkOFiVx3kUPDoYICaQnlqRmp6YWpBbF F5XmpBYfYmTi4JRqYKxK1/Jg96r5xFwmGzhXJ2CbcVBy9O9UB+FTIl5MWxsqpRb0GE0Vaf2j 3NPzc8GDj5O/pif6MYvfqXrzKy9Fw7BlkdZ3O95D73LswpknB5bzL4otXymWt6VtZvjB0uYd L7vNTG7e4MnTsS9lNC21mL0h/DxvQ8hEZfXQwOeN1xRsM85WT41UYinOSDTUYi4qTgQAvLjS qaECAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/lime-oam-model/grdKraKhHJ7g0p2eHi91RPTRsvE>
Cc: "Deepak Kumar (dekumar)" <dekumar@cisco.com>
Subject: Re: [Lime-oam-model] Design Team report
X-BeenThere: lime-oam-model@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LIME WG OAM Model Design Team <lime-oam-model.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lime-oam-model>, <mailto:lime-oam-model-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lime-oam-model/>
List-Post: <mailto:lime-oam-model@ietf.org>
List-Help: <mailto:lime-oam-model-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lime-oam-model>, <mailto:lime-oam-model-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2015 15:23:09 -0000

Dear Qin,
“we have justified to Greg”
I think it would be fair and appropriate that the WG decides that. In the meantime the authors of the draft-tissa-lime-yang-oam-model<http://tools.ietf.org/id/draft-tissa-lime-yang-oam-model-03.txt> may choose to work on filling the gap. I’ll be glad to review and provide my comments.

                Regards,
                                Greg

From: Qin Wu [mailto:bill.wu@huawei.com]
Sent: Wednesday, March 18, 2015 11:21 PM
To: Ronald Bonica; Gregory Mirsky; lime-oam-model@ietf.org
Cc: Deepak Kumar (dekumar)
Subject: RE: Design Team report

Hi, Ron:
If there is any point of disagreement, it has been documented in the page 6 of the slides with
“
current model is applicable in IP for VPN technologies but not sure about non VPN scenarios which require more discussion.
”
I don’t think this is a big issue since we have justified to Greg and we can fill the gap if anything missing piece coming up.
we can move this to the conclusion page if you think necessary.

-Qin
发件人: Ronald Bonica [mailto:rbonica@juniper.net]<mailto:[mailto:rbonica@juniper.net]>
发送时间: 2015年3月19日 13:28
收件人: Gregory Mirsky; Qin Wu; lime-oam-model@ietf.org<mailto:lime-oam-model@ietf.org>
抄送: Deepak Kumar (dekumar)
主题: RE: Design Team report

Folks,

If the DT isn’t converging, please document the points of disagreement. The meeting is just five days away!

                            Ron


From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Wednesday, March 18, 2015 5:07 PM
To: Qin Wu; Ronald Bonica; lime-oam-model@ietf.org<mailto:lime-oam-model@ietf.org>
Cc: Deepak Kumar (dekumar)
Subject: RE: Design Team report

Hi Qin,
I think we clearly agree to disagree on some fundamental issues. Perhaps the DT report is the right place to reflect that and continue discussion with the participation from WG experts.

                Regards,
                                Greg

From: Qin Wu [mailto:bill.wu@huawei.com]
Sent: Tuesday, March 17, 2015 7:57 PM
To: Gregory Mirsky; Ronald Bonica; lime-oam-model@ietf.org<mailto:lime-oam-model@ietf.org>
Cc: Deepak Kumar (dekumar)
Subject: RE: Design Team report

Hi, Greg:

发件人: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]<mailto:[mailto:gregory.mirsky@ericsson.com]>
发送时间: 2015年3月18日 2:11
收件人: Qin Wu; Ronald Bonica; lime-oam-model@ietf.org<mailto:lime-oam-model@ietf.org>
抄送: Deepak Kumar (dekumar)
主题: RE: Design Team report

Hi Qin,
as I’ve explained my position last week, I see two options:

*         limit scope of draft-tissa-lime-yang-oam-model-03;

*         extend existing OAM models first to create sufficient common set of OAM elements to be described by OAM Generic Data Model.
Because not only OAM of IP and LDP-based IP/MPLS networks lacks in definition of elements to be modeled,

[Qin]: LIME model proposed in draft-tissa-lime-yang-oam-model-03 has added such definitions. We already have a good basis for generic model to start with.
In the last IETF meeting, tissa have given a good presentation on how LIME model supports IP OAM, e.g., LIME model supports various addressing including IP addressing.

but MPLS-TP OAM is only applicable to bi-directional p2p LSPs and not to uni-directional p2p and p2mp LSPs,

[Qin]: Do you proposed to add p2p and p2mp,bi-directional, uni-direcational as part of LIME generic model, or add them as part of technology-specific data model extensions?

current scope of common elements is even less the ping and traceroute.

[Qin]: ping is corresponding to cc and traceroute is corresponding to path discovery in the table of RFC7276, we can make these rpc more generic.

Unless you propose to refer to a data model as generic even though many elements are yet undefined and may not fit into that model.

[Qin]: Elements common to various OAM technologies, have been identified based on a lot of our discussion, I believe you are talking a lot about piece belonging to technology-specific data model extensions. Also you might consider to add some pieces you identified during the analysis into LIME generic model or LIME base draft, That’s good, but that  can be used to improve base draft.
                Regards,
                                Greg

From: Qin Wu [mailto:bill.wu@huawei.com]
Sent: Monday, March 16, 2015 10:59 PM
To: Gregory Mirsky; Ronald Bonica; lime-oam-model@ietf.org<mailto:lime-oam-model@ietf.org>
Cc: Deepak Kumar (dekumar)
Subject: RE: Design Team report

Hi, Greg:

发件人: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
发送时间: 2015年3月17日 13:14
收件人: Qin Wu; Ronald Bonica; lime-oam-model@ietf.org<mailto:lime-oam-model@ietf.org>
抄送: Deepak Kumar (dekumar)
主题: RE: Design Team report

Hi Qin,
yes, we’re looking for commonality among several OAM and for that, I believe, we need to describe them as detailed as possible. Then we, as a group, can see what is common and whether that common area is substantial or not.
Couple more notes in-line and tagged with GIM>>.

                Regards,
                                Greg

From: Qin Wu [mailto:bill.wu@huawei.com]
Sent: Monday, March 16, 2015 7:36 PM
To: Gregory Mirsky; Ronald Bonica; lime-oam-model@ietf.org<mailto:lime-oam-model@ietf.org>
Cc: Deepak Kumar (dekumar)
Subject: RE: Design Team report

Hi, Greg:
We are looking commonality pieces among various OAM technologies, not intending to include all the features define by each OAM technologies.
See my reply inline below.

-Qin
发件人: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
发送时间: 2015年3月17日 7:50
收件人: Qin Wu; Ronald Bonica; lime-oam-model@ietf.org<mailto:lime-oam-model@ietf.org>
抄送: Deepak Kumar (dekumar)
主题: RE: Design Team report

Dear Qin,
many thanks for building very informative presentation on behalf of the DT.

[Qin]:My pleasure.
Couple notes:

*         When talking about IP OAM I mean OAM for IP and LDP-based IP/MPLS networks. Perhaps p.6 may be good place to make such clarification;

[Qin]:It seems you are talking about technology-specific data model extensions, e.g., mis-connection defect defined in MPLS-TP, alarm suppression, automatic protection switchover coordination defined in Y.1731. These model extension can be worked on in specific protocol Working group.
GIM>> The definition of mis-connection defect is not MPLS-TP specific but common for transport networks, e.g. TDM, OTN. Again, we are trying to identify the common set and thus, I believe, need to be as detailed as possible.

[Qin]: Based on your analysis table which compared IP OAM, IP/MPLS OAM, MPLS-TP, TRILL OAM, it looks apparent that mis-connection defect metric and mis-merge defect are both not common to various OAM technologies and only applied to MPLS-TP and TRILL and not applied to IP OAM and IP/MPLS OAM.


*         to table on p.11:

o   connectivity verification assumes that there exists definition of miss-connection defect along with definitions of in-defect and out-defect conditions. I believe that neither IP, nor IP/MPLS had so far defined miss-connection defect and it only exists for MPLS-TP in RFC 6428.

                           [Qin]: I think this is a piece belonging to technology-specific data model extensions, if you propose to make it common to all the OAM technologies, we can add “mis-connection
  defect”  As optional data node in the schema tree.
GIM>> It very well could become technology-specific but I think it would be result of the analysis, unless you already have the answer.

[Qin]: Yes, this is from analysis table. The analysis table was initially provided by you. :)

I think that table should be updated to reflect that only MPLS Echo Request/Reply, a.k.a. LSP Ping does support connectivity verification while other OAM mechanisms listed in the Connectivity Verification column (BFD, ICMP Ping, OWAMP/TWAMP Control protocols) do not support it;

                           [Qin] RFC7276 is the product of opsawg Working Group and summarize a lot of commonality among various OAM technologies. We should stick to use it. LIME WG should use
RFC7276 as basis to build generic model.
                           Your above statement is not consistent with RFC7276, table 4 since Table 4 indicates that connectivity verification are supported by BFD, OWAMP/TWAMP.
                           Also in page 7 of this slides, comparison table, on demand cv are supported by IP OAM.
GIM>> I find RFC 7276 to have inconsistent with transport network OAM as per G.800, Y.1710, and Y.1711. Personally, I don’t recall it was reviewed by MPLS or BFD WGs.

[Qin]: If you don’t believe RFC7276 or consensus building from OPSAWG, I think you should ask chairs of OPSAWG.

……..
                     [Qin]: It looks to me not necessary since we talk a lot about commonality among various OAM technologies. Also I think IP OAM feature should be supported by LIME generic OAM              model,  Otherwise it defeats the goal to building generic model. I would suggest author of tissa’s draft to give a presentation  and clarify how IP OAM is supported by LIME model proposed
                     In the tissa’s draft. I think this will address your comment.
                     Deepak, what do you think of this?
GIM>> I don’t put forth what should and what should not be the result of an investigation before I collect all the data available. Apparently you already have the answer.

[Qin]: It was discussed on last Friday, it looks what you suggested is to separate OAM model analysis discussion from draft discussion(i.e., how draft-tissa-lime-yang-oam-model<http://tools.ietf.org/id/draft-tissa-lime-yang-oam-model-03.txt> support IP OAM feature). What am I missing?

Regards,
                Greg