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

Gregory Mirsky <gregory.mirsky@ericsson.com> Tue, 17 March 2015 05:13 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 E52141A0024 for <lime-oam-model@ietfa.amsl.com>; Mon, 16 Mar 2015 22:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.211
X-Spam-Level:
X-Spam-Status: No, score=-100.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_65=0.6, 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 kSXL92RZDjxV for <lime-oam-model@ietfa.amsl.com>; Mon, 16 Mar 2015 22:13:41 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43EB41A0019 for <lime-oam-model@ietf.org>; Mon, 16 Mar 2015 22:13:41 -0700 (PDT)
X-AuditID: c6180641-f790b6d000004359-b5-550756771dad
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 2B.DF.17241.77657055; Mon, 16 Mar 2015 23:17:28 +0100 (CET)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0210.002; Tue, 17 Mar 2015 01:13:30 -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//+VX8A==
Date: Tue, 17 Mar 2015 05:13:30 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1121B92F643@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>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA84702B17@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.11]
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B92F643eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZXLonXLcijD3U4NRxCYvHcxewWvxc9Ynd omd1M7PFge8ODiweU35vZPVoOfKW1WPJkp9MHtebrrIHsERx2aSk5mSWpRbp2yVwZbReLClo uMxa0b/sHWsDY/sC1i5GTg4JAROJ8xua2SBsMYkL99YD2VwcQgJHGCW2bW2HcpYzSizunAxW xSZgJPFiYw87iC0iUC3xu3U/mM0sYCDRd2A2WI2wgIJE96NjjBA1ihLTT0xlgrCdJI6cfQwW ZxFQlXhzehpYL6+Ar8SDnceYIJZdZJNY/GMPC0iCUyBMYueXg2A2I9B530+tYYJYJi5x68l8 JoizBSSW7DnPDGGLSrx8/A/qNSWJj7/nQx2XL9Hw9DkLxDJBiZMzn7BMYBSdhWTULCRls5CU QcS1JOY1/IaqUZSY0v2QHcLWlLgy+RCUrS2xbOFr5gWM7KsYOUqLU8ty040MNzECI/CYBJvj DsYFnywPMQpwMCrx8BposIcKsSaWFVfmHmKU5mBREuctu3IwREggPbEkNTs1tSC1KL6oNCe1 +BAjEwenVAOjhejaJmaHJ5tjhZ8nBqn25BSdf+8cz7zH96v4+nvTn3t9XPVDwqA90/p4wMUb WbM33g56HmVaIizcwrKX245761r/ZQVOH5VF+z4f+tg8e+q2XUuq5/w4Vd9Uc5RR90bmhNcM XqqnXX/vP15zV2m6rl+IQcK0r6r6v3K4uVInrXsc5nF0YsM7JZbijERDLeai4kQANGQ0T6EC AAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/lime-oam-model/7EWUoHxzkVPezZ_RSzlLP90SqrA>
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: Tue, 17 Mar 2015 05:13:47 -0000

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
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.


¡¤         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.

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.


o   not clear what role OWAMP/TWAMP control protocols play as Continuity Check OAM mechanism. Is it because they use TCP connection between Server and Control Client? But Server and Control Client could be network elements outside of Sender and Receiver/Reflector. By the same logic, should any application, e.g. BGP, that uses TCP connection be considered as Continuity Check OAM mechanism? I don¡¯t think that is the case.

                          [Qin]: First, RFC7276 table 4 said Continuity Check is supported by OWAMP/TWAMP control protocols. I believe there was consensus to add this support in the RFC7276. Why should we be skeptical about this?
                           Second, whether server and client is the network element outside of sender and receiver is implementation specific.


o   does TRILL OAM support Alarm suppression, Automatic Protection Switchover coordination like Y.1731?

                         [Qin]: We are looking for commonality among various OAM technologies, not commonality between any two OAM technologies, if a feature is only supported by one OAM          technologies, we should define this feature in the technology-specific data model extensions.


o   MPLS-TP OAM includes Protection Switchover Coordination protocol RFC 6378;

                        [Qin]: Same as above.


o   I¡¯m not familiar with Diagnostic Test or Client Failure Notification is MPLS ¨CTP OAM function or mechanism, could you please help with the reference;

                       [Qin]: We can make them as optional feature if we need to include them in the generic model for all the OAM technologies.
Yes, I will look for the reference.


¡¤         I¡¯d like the Conclusion page to use two last bullets from p.6:

o   Make sure the LIME model proposed in /draft-tissa-lime-yang-oam-model-03 support IP OAM feature.

o   Or define IP OAM model first and separate it from LIME OAM model if the current model cannot support IP OAM.

                     [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.

Regards,
                Greg

From: Qin Wu [mailto:bill.wu@huawei.com]
Sent: Saturday, March 14, 2015 1:26 AM
To: Ronald Bonica; Gregory Mirsky; lime-oam-model@ietf.org<mailto:lime-oam-model@ietf.org>
Cc: Deepak Kumar (dekumar)
Subject: Design Team report

Hi, Design team members:
Based on Ron¡¯s request, Greg and I had a conference call on Friday and discussed LIME OAM model again, Deepak also joined the discussion.
Based on the discussion, I think we generally agreed commonality among various OAM technologies. The current model is applicable in IP for VPN technologies but not sure about non VPN scenarios which require more discussion.

Here is the initial version of Design team report we like to deliver and present at IETF92.
I like to ask your review and input. Thanks!

BTW: I apologize for the confusion as Tissa and nobo were left. Welcome Santosh on board.

Regards!
-Qin
·¢¼þÈË: Ronald Bonica [mailto:rbonica@juniper.net]
·¢ËÍʱ¼ä: 2015Äê3ÔÂ10ÈÕ 21:42
ÊÕ¼þÈË: Qin Wu; Gregory Mirsky; lime-oam-model@ietf.org<mailto:lime-oam-model@ietf.org>
³­ËÍ: Deepak Kumar (dekumar)
Ö÷Ìâ: RE: Status

Greg, Qin,

Why don¡¯t you two guys meet f2f. Bring up a conference bridge so that others can join you remotely.

                                                           Ron


From: Qin Wu [mailto:bill.wu@huawei.com]
Sent: Tuesday, March 10, 2015 12:35 AM
To: Ronald Bonica; Gregory Mirsky; lime-oam-model@ietf.org<mailto:lime-oam-model@ietf.org>
Cc: Deepak Kumar (dekumar)
Subject: RE: Status

Works for me.

-Qin
·¢¼þÈË: Ronald Bonica [mailto:rbonica@juniper.net]
·¢ËÍʱ¼ä: 2015Äê3ÔÂ10ÈÕ 9:30
ÊÕ¼þÈË: Gregory Mirsky; Qin Wu; lime-oam-model@ietf.org<mailto:lime-oam-model@ietf.org>
³­ËÍ: Deepak Kumar (dekumar)
Ö÷Ìâ: RE: Status

Folks,

Can I ask the design team to meet urgently this week and come to one of the following conclusions? Either:


1)      We have complete consensus and it is ¡­¡­¡­

2)      We have complete consensus on A, B and C. We don¡¯t have consensus on D, E, and F

3)      We can¡¯t even agree on the questions

If the answer is 2), please be prepared to describe A, B, C, D, E and F at IETF 92. Also, be prepared to describe the rationale between opposing positions.

                                                                         Ron



4)      We have consensus and it is {{From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Monday, March 09, 2015 12:12 PM
To: Qin Wu; Ronald Bonica; lime-oam-model@ietf.org<mailto:lime-oam-model@ietf.org>
Cc: Deepak Kumar (dekumar)
Subject: RE: Status

Hi Qin, Ron, et. al,
apologies for the extended absence from the discussion.
I believe that the statement that:
> CFM like model as management plane model is orthogonal to data plane
> OAM protocol and meet all these requirements.
Does not entirely reflect state of discussion within the DT, especially that "CFM like model ¡­ meets all the requirements".

And I cannot agree with the conclusion here either:
> Also MP (assume that 'MP' stands for 'Maintenance Point') terminologies are widely used in the most of OAM technologies,
> it is not a good idea to define new terminologies to represent common
> elements for the OAM model.
It is not about luck of terminology but luck of terminology likely indicates that respective objects not being identified or used. Hence, if we to build common OAM model, objects should be identified and defined, including through terminology. Alternatively, we have OAM technologies that share sufficient commonality to work with.

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:lime-oam-model-bounces@ietf.org] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; lime-oam-model@ietf.org<mailto:lime-oam-model@ietf.org>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----ÓʼþÔ­¼þ-----
·¢¼þÈË: Ronald Bonica [mailto:rbonica@juniper.net]
·¢ËÍʱ¼ä: 2015Äê3ÔÂ7ÈÕ 5:28
ÊÕ¼þÈË: Qin Wu; lime-oam-model@ietf.org<mailto:lime-oam-model@ietf.org>
³­ËÍ: Deepak Kumar (dekumar)
Ö÷Ìâ: RE: Status

Qin,

Thanks for this summary. Unless I hear otherwise, I will assume that this is the group's consensus.

[Qin]: It has been a few days and no-one has disagreed.

IMHO, the design team has three tasks standing between itself and completion:

- craft a slide deck documenting findings

[Qin]: I will write the first draft and we can discuss on this list.

- present that slide deck at IETF 92

[Qin]: I am happy to do this if no one has objection.

- produce an ID recording findings

[Qin]: I can also start this task. I think I can make a first draft before Dallas, but I am not allowed to post it until Monday morning of IETF week in Dallas.

Is that OK?

Thanks.

Do we have volunteers for any of those tasks?

                                                                 Ron


> -----Original Message-----
> From: Lime-oam-model [mailto:lime-oam-model-bounces@ietf.org] On
> Behalf Of Qin Wu
> Sent: Thursday, March 05, 2015 10:38 PM
> To: Ronald Bonica; lime-oam-model@ietf.org<mailto:lime-oam-model@ietf.org>
> Cc: Deepak Kumar (dekumar)
> Subject: Re: [Lime-oam-model] Status
>
> Ron:
> If my understanding is correct, here is the status of group discussion.
> Based on first design team discussion ,people agreed to sort out
> common OAM requirements first, Greg provides OAM (Data) Model Analysis
> table from his perspective which compares IP OAM, IP/MPLS OAM, MPLS-TP
> OAM, TRILL OAM from several criteria and lists several common
> requirements.
>
> Based on OAM Model Analysis, common elements used for OAM model are
> agreed, e.g., testing point, connection oriented vs
> connectionless,loss of continuity defect,fault domain,technology type,
> addressing, ECMP, common OAM functions(e.g., cc,cv, path discovery, performance measurement).
>
> CFM like model as management plane model is orthogonal to data plane
> OAM protocol and meet all these requirements.
> Also MP terminologies are widely used in the most of OAM technologies,
> it is not a good idea to define new terminologies to represent common
> elements for the OAM model.
>
> Therefore my understanding is that the choice of an OAM model seems to
> have no impact on the LIME work.
> LIME model focuses on common part of various OAM technologies,
> therefore LIME's work can be made "model agnostic".
>
> Regards!
> -Qin
> -----ÓʼþÔ­¼þ-----
> ·¢¼þÈË: Lime-oam-model [mailto:lime-oam-model-bounces@ietf.org] ´ú±í
> Ronald Bonica
> ·¢ËÍʱ¼ä: 2015Äê3ÔÂ2ÈÕ 6:40
> ÊÕ¼þÈË: lime-oam-model@ietf.org<mailto:lime-oam-model@ietf.org>
> Ö÷Ìâ: [Lime-oam-model] Status
>
> Folks,
>
> Since the group's formation, we have lost two members (Nobo and Tissa).
> Santosh PK will replace Nobo.
>
> Could Qin or Greg summarize that group's status for Santosh?
>
> Also, Qin and Greg, do you think that the design team will have
> anything to report at IETF 92?
>
>                                                 Ron Bonica
>
> _______________________________________________
> Lime-oam-model mailing list
> Lime-oam-model@ietf.org<mailto:Lime-oam-model@ietf.org>
> https://www.ietf.org/mailman/listinfo/lime-oam-model
> _______________________________________________
> Lime-oam-model mailing list
> Lime-oam-model@ietf.org<mailto:Lime-oam-model@ietf.org>
> https://www.ietf.org/mailman/listinfo/lime-oam-model
_______________________________________________
Lime-oam-model mailing list
Lime-oam-model@ietf.org<mailto:Lime-oam-model@ietf.org>
https://www.ietf.org/mailman/listinfo/lime-oam-model