Subject: Re: [Time] MEP and maintenance domain boundary

From: Qin Wu <[email-masked]>
Date: Tue, 1 Jul 2014 07:05:43 +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:[email-masked]] 代表 Huub van Helvoort
发送时间: 2014年6月30日 20:58
收件人: [email-masked]
主题: 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.

--

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

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

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 01 Jul 2014 10:38:42 +0200

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:[email-masked]]
代
表
Huub van Helvoort

发
送时间: 2014年6月30日 20:58

收件人: [email-masked]

主题: Re: [Time] MEP and maintenance domain
boundary

Hello Qin,

You wrote:

Hi, Greg:

Thanks for your review
to problem statement draft.

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:

MEPs
and MIPs that belong to the same Maintenance Entity (ME) are
not

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

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

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

packets.

packets.

NEW TEXT:

“

”

[Huub] OK, this is better.

“

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.

---

From: Yuji Tochio <[email-masked]>
Date: Tue, 01 Jul 2014 17:59:21 +0900

Hi Huub,

Very very minor and common correction....

>> MIP = Maintenance entity Intermediate Point.

If you are refering to ITU-T G.8013/Y.1731 (or RFC 6371), they are MEG (Maintenance Entity Group) End Point and Intermediate Point :-)

Thanks, Yuji

---

From: Qin Wu <[email-masked]>
Date: Tue, 1 Jul 2014 11:42:36 +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:[email-masked]] 代表 Huub van Helvoort
发送时间: 2014年7月1日 16:39
收件人: Qin Wu; [email-masked]
主题: Re: [Time] MEP and maintenance domain boundary

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

>I would recommend not to introduce yet another terminology, but stick

>Best regards, Huub.

发件人: Time [mailto:[email-masked]] 代 表 Huub van Helvoort
发 送时间: 2014年6月30日 20:58
收件人: [email-masked]<mailto:[email-masked]>
主题: Re: [Time] MEP and maintenance domain boundary

Hello Qin,

You wrote:
Hi, Greg:

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

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

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.

The third question is:

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

   packets.

   packets.

NEW TEXT:

“

”

“

”

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.

--

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

---

From: Yuji Tochio <[email-masked]>
Date: Wed, 02 Jul 2014 09:26:04 +0900

Hi Qin,

> Or the layer the OAM is applied has nothing to do with MEL?

The reason of single MEL per ME (LSP) can be found in RFC 5317 and RFC 5860.
The slidew 33 - 38 as attached to RFC 5317 will help you.
Note that MEL is considered for Ethernet OAM but not for MPLS(-TP).

And I recommend you should read draft-ietf-mpls-tp-temporal-hitless-psm for your concern.

Regards, Yuji

---

From: Qin Wu <[email-masked]>
Date: Wed, 2 Jul 2014 03:19:40 +0000

Hi, Yuji:
Thanks for pointing me to the relevant references. I will read.
I see how MEL is used in slide 36 associated with RFC5317.
It looks MEL is used to identify which part of network the fault happens, e.g.,
MEL x: Carrier1;
MEL y: Carrier1, Region 1;
MEL z: Carrier1, Region 2;
Regarding you are saying “MEL is considered for Ethernet OAM but not for MPLS(-TP)”
I am a little bit consumed, Isn’t Ethernet OAM has already been integrated into MPLS-TP?
What am I missing?

Regards!
-Qin
发件人: Yuji Tochio [mailto:[email-masked]]
发送时间: 2014年7月2日 8:26
收件人: Qin Wu
抄送: [email-masked]
主题: Re: [Time] MEP and maintenance domain boundary

Hi Qin,

Regards, Yuji

---

From: Yuji Tochio <[email-masked]>
Date: Wed, 02 Jul 2014 13:02:26 +0900

Hi Qin,

> MEL z: Carrier1, Region 2;

To consider the slide, SPME, section 3.2 of RFC 6371, is adapted to MPLS-TP OAM architecure.
So far, MPLS-TP has only one MEL as Huub pointed out.

Regards, Yuji

---

From: Qin Wu <[email-masked]>
Date: Wed, 2 Jul 2014 04:28:56 +0000

I see, thanks for clarification.

-Qin
发送时间: 2014年7月2日 12:02

Hi Qin,

Regards, Yuji