Re: [Time] MEP and maintenance domain boundary

Qin Wu <bill.wu@huawei.com> Tue, 01 July 2014 11:42 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 91A041A006F for <time@ietfa.amsl.com>; Tue, 1 Jul 2014 04:42:54 -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 US5jrlXXjFvX for <time@ietfa.amsl.com>; Tue, 1 Jul 2014 04:42:47 -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 D13C91A008D for <time@ietf.org>; Tue, 1 Jul 2014 04:42:46 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJL47851; Tue, 01 Jul 2014 11:42:45 +0000 (GMT)
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Jul 2014 12:42:42 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 1 Jul 2014 19:42:37 +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//+n6QCAALNHcA==
Date: Tue, 01 Jul 2014 11:42:36 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA8457BFDF@nkgeml501-mbs.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABA8457B6A4@nkgeml501-mbs.china.huawei.com> <53B15EED.2020701@gmail.com> <B8F9A780D330094D99AF023C5877DABA8457BDB8@nkgeml501-mbs.china.huawei.com> <53B27392.4000700@gmail.com>
In-Reply-To: <53B27392.4000700@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_B8F9A780D330094D99AF023C5877DABA8457BFDFnkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/time/0T4vBkwamfG1t6Btpr8wDztNcF0
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 11:42:55 -0000

Hi, Huub:
Thanks for your proposed changes and help address this issue.
I agree sticking to the existing CFM terminologies will be a good choice.
Then we can apply these terms to Ethernet, IP, SDH, OTN,ATM…
And we can enhance CFM model if needed but try to reuse the existing terms defined by CFM model.

Regarding RFC6371, why the IETF insisted on using only
one maintenance level (MEL) per maintenance entity (ME) in MPLS-TP OAM?
Why multiple MELs per ME is not allowed? Do we need to relax this restriction defined by RFC6371?
If I uses both Ethernet OAM and IP OAM in the same maintenance entity, do I need to allow two MELs per ME?
Or the layer the OAM is applied has nothing to do with MEL?
Regards!
发件人: Time [mailto:time-bounces@ietf.org] 代表 Huub van Helvoort
发送时间: 2014年7月1日 16:39
收件人: Qin Wu; time@ietf.org
主题: Re: [Time] MEP and maintenance domain boundary

>Hello Qin,

>You replied:
>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
>OK, good approach.

>not specific to a given transport technology, just like MPLS-TP.
>The terms I used are not MPLS-TP specific, they apply to Ethernet too.
>From a management point of view they are applicable to ATM, SDH, OTN...

>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.
>I would recommend not to introduce yet another terminology, but stick
>to the CFM terminology you mention above.

>For your comments, please see my reply inline.
>I added some responses [Huub]

>Best regards, Huub.



发件人: Time [mailto:time-bounces@ietf.org] 代 表 Huub van Helvoort
发 送时间: 2014年6月30日 20:58
收件人: time@ietf.org<mailto: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?
[Huub] During the development of MPLS-TP OAM the IETF insisted on using only
one maintenance level (MEL) per maintenance entity (ME), and use TCM
to provide the required levels. Please read RFC6371.


 Are you saying MEP can be placed either at the maintenance domain boundary or within maintenance domain?
[Huub] According to 802.1ag a Maintenance Domain (MD) consists of one or more
Maintenance Associations (MA). An MA is the connection between two MEPs.
ITU-T uses Maintenance Entity Group (MEG) for MD and  Maintenance Entity (ME)
for MA.
An MD can be (but not necessarily always is) an operator domain.
MA/ME can exist for customers (C-UNI to C-UNI), service providers (N-UNI to
N-UNI), carriers intra-domain(E-NNI to E-NNI), inter-domain (NNI to NNI).

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.
[Huub] I think you will create more confusion by introducing more terminology.

[Qin]: Okay.

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?
[Huub] No they are not. They are used for other technologies too.
There are already management models that use these terms.

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.
[Huub] It is the same as Maintenance Association, as explained above.

So the second question is
Is MIP part of ME if ME is defined as the relationship between two MEPs?
[Huub] Yes.

The third question is:
How Maintenance entity is different from Maintenance Association?
[Huub] It is the same  ;-)

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?
[Huub] A MEP is at the end of an ME/MA. A MEG/MD can contain one or more ME/MAs.


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

”
[Huub] OK, this is better.


   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?
[Huub] I think it does not. How about:
MEPs and MIPs can exist in the same maintenance domain and belong to different MEs.
They can also exist at different layers and use various encapsulating protocols.


--

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

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