Re: [Time] MEP and maintenance domain boundary

Huub van Helvoort <huubatwork@gmail.com> Tue, 01 July 2014 08:38 UTC

Return-Path: <huubatwork@gmail.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 7BD651A005E for <time@ietfa.amsl.com>; Tue, 1 Jul 2014 01:38:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.174
X-Spam-Level: *
X-Spam-Status: No, score=1.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=no
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 JDOWfzqiWXhc for <time@ietfa.amsl.com>; Tue, 1 Jul 2014 01:38:46 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9874E1A001D for <time@ietf.org>; Tue, 1 Jul 2014 01:38:45 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id cc10so7354156wib.0 for <time@ietf.org>; Tue, 01 Jul 2014 01:38:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=tiyV7CXEd7RGvCYJnmXhQYy+GFOhbFlCpNKljXs0MBM=; b=CSrQZ1H6ekIxLvjbftu7LCiaaA709YPprHG4z+RXFxmJJwJUX4+vZg/RN4MY4wpwc9 FUQSlCY/k6wei1PLTw9UdlVEkRGuRAP/35M6OVAMird2XM9oHpWmDat7uYJJCHq1zGBU umS/1szD+vdoa3dnwNZmEXAWh0N3cffPrQleGAslHxbR/y0zF6hZhQhxg9+b488CP2eZ wuHjfMR0ySfo1GdMNNZBN8hicgYMSETWzakzPcE4zX5xlArFvjX6Rk7Te1yCYZfJup2M 3KeD51cBv+MDfU8/WUb7GU+tVFCAEuej1nEyOt1q8eW2n3SQ+sSV5lUxlPdr2LXl8/jT vBbw==
X-Received: by 10.194.63.196 with SMTP id i4mr51311577wjs.50.1404203924086; Tue, 01 Jul 2014 01:38:44 -0700 (PDT)
Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id o12sm40811874wiw.5.2014.07.01.01.38.42 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Jul 2014 01:38:43 -0700 (PDT)
Message-ID: <53B27392.4000700@gmail.com>
Date: Tue, 01 Jul 2014 10:38:42 +0200
From: Huub van Helvoort <huubatwork@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Qin Wu <bill.wu@huawei.com>, "time@ietf.org" <time@ietf.org>
References: <B8F9A780D330094D99AF023C5877DABA8457B6A4@nkgeml501-mbs.china.huawei.com> <53B15EED.2020701@gmail.com> <B8F9A780D330094D99AF023C5877DABA8457BDB8@nkgeml501-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA8457BDB8@nkgeml501-mbs.china.huawei.com>
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/time/4kAGNo11SJ0SYbbMsz5H7tZwyKE
Subject: Re: [Time] MEP and maintenance domain boundary
X-BeenThere: time@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: huubatwork@gmail.com
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 08:38:47 -0000

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 ATRM, 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
发 送时间: 2014630 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" rel="nofollow">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.

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.
 

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