Re: [Time] MEP and maintenance domain boundary

Qin Wu <bill.wu@huawei.com> Tue, 01 July 2014 07:05 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: time@ietfa.amsl.com
Delivered-To: time@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C9F1B27CA for <time@ietfa.amsl.com>; Tue, 1 Jul 2014 00:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level:
X-Spam-Status: No, score=-2.401 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, RP_MATCHES_RCVD=-0.651, 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 KPG9tVx31ZTQ for <time@ietfa.amsl.com>; Tue, 1 Jul 2014 00:05:53 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55FE21A017F for <time@ietf.org>; Tue, 1 Jul 2014 00:05:52 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJL16862; Tue, 01 Jul 2014 07:05:51 +0000 (GMT)
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Jul 2014 08:05:49 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 1 Jul 2014 15:05:43 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "huubatwork@gmail.com" <huubatwork@gmail.com>, "time@ietf.org" <time@ietf.org>
Thread-Topic: [Time] MEP and maintenance domain boundary
Thread-Index: AQHPlGMAPmdm9niSIEyuCBB+f0TZxZuKuO5Q
Date: Tue, 01 Jul 2014 07:05:43 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA8457BDB8@nkgeml501-mbs.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABA8457B6A4@nkgeml501-mbs.china.huawei.com> <53B15EED.2020701@gmail.com>
In-Reply-To: <53B15EED.2020701@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.180]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8457BDB8nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/time/i5z7b8rMBZwdN-I_ufADyO9rEj4
Subject: Re: [Time] MEP and maintenance domain boundary
X-BeenThere: time@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Transport Independent OAM in Multi-Layer network Entity \(TIME\) discussion list." <time.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/time>, <mailto:time-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/time/>
List-Post: <mailto:time@ietf.org>
List-Help: <mailto:time-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/time>, <mailto:time-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Jul 2014 07:05:55 -0000

Hi, Hubb:
What we like to see is transport independent multi-layer OAM can adopt IEEE802.1ag CFM model and make CFM terminologies being used
not specific to a given transport technology, just like MPLS-TP.
Therefore I am not sure we should reuse these CFM terminologies used in IEEE802.1ag and MPLS-TP or we should define TIME specific terminologies, e.g., T-MEP, T-MIP.
For your comments, please see my reply inline.

Regards!
-Qin
发件人: Time [mailto:time-bounces@ietf.org] 代表 Huub van Helvoort
发送时间: 2014年6月30日 20:58
收件人: time@ietf.org
主题: Re: [Time] MEP and maintenance domain boundary

Hello Qin,

You wrote:
Hi, Greg:
Thanks for your review to problem statement draft.

http://tools.ietf.org/html/draft-ww-opsawg-multi-layer-oam-01
Section 4 gives an architecture overview of management plane OAM,
You comment on the following quoted sentence
“MEP is a maintenance functional entity that is implemented into
   network entity at the maintenance domain boundary
”

as “Not necessarily, e.g. MEP at Level < 7 in Ethernet Service OAM as CFM or Y.1731”.
Unfortunately MPLS-TP has only one MEL, fixed at "7".

[Qin]: I thought in MPLS-TP or IEEE 802.1ag, there are customer level(e.g.,MD7,6,5), service provider level(e.g.,MD4,3), operator level(e.g.MD2,1,0)
What am I missing?


Are you saying MEP can be placed either at the maintenance domain boundary or within maintenance domain?
First of all you have to correct the expansion of MEP and MIP:
MEP = Maintenance entity End Point
MIP = Maintenance entity Intermediate Point.

MEPs and MIPs that belong to the same Maintenance Entity (ME) are not
aware of any MEPs or MIPs outside the ME they belong to.

[Qin]: We are not sure we should reuse CFM terms or redefine CFM terms that are specific to TIME usage.
So one question I like to ask here is:
Is ME a MPLS-TP specific term? Or Is Maintenance entity End Point a MPLS-TP specific term?
In the current draft, we haven’t defined Maintenance Entity yet, it looks a little confusing when we use Maintenance Entity
Since Maintenance Entity is not network entity or functional entity but a relationship between two Maintenance endpoints.

So the second question is
Is MIP part of ME if ME is defined as the relationship between two MEPs?

The third question is:
How Maintenance entity is different from Maintenance Association?

A Maintenance Entity can be any path, tunnel or section in the
network. So it can exist between domain boundaries (NNIs) but also inside
a domain, or across multiple domains (end-to-end ME).

[Qin]: You seems to answer my question above. Let me repeat what you said.
Are you saying MEP should still be located at the edge of domain however ME can exist either at the edge of domain or
Inside domain?

In section 4 I notice:

   MEP is a maintenance functional entity that is implemented

   into a Network Element either at the maintenance domain boundary or

   in the maintenance domain and can generate, send and receive OAM

   packets.



What is the difference between generate and send OAM packets?



[Qin]: I think we can remove “generate” from the above sentence to avoid confusion.



   MIP is a maintenance functional entity that is implemented

   into a Network Element in the maintenance domain and can forward OAM

   packets.



A MIP can also respond to OAM messages sent by the source MEP.



[Qin]: Thanks for correction. Howe about the following change:

NEW TEXT:

“

   MIP is a maintenance functional entity that is implemented

   into a Network Element in the maintenance domain and can forward OAM

   packets or respond only when triggered by a specific OAM function

(e.g., Path Discovery or Connectivity Verification).

”

   Either MEP or MIP may be at different layer and use various

   different encapsulating protocols.



This is confusing, as I explained above.

MEPs and MIPs can exist in different layers/technologies.

However in the same layer ME MIPs cannot exist without MEPs.

MEPs and MIPs in the same ME in a layer are not aware of

MEPs and MIPs other ME in the same layer, nor in other layers.



[Qin]: Agree. I think we can simply remove this confusing sentence or rephrase the above sentence as follows:

“
MEPs or MIPs in the same domain but belong to different ME may be at different layer and use various
   different encapsulating protocols.

”

Dos this make sense?



Best regards, Huub.



--

*****************************************************************

              请记住,你是独一无二的,就像其他每一个人一样