Subject: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 6 Jul 2010 19:39:58 +0300

Dear Mr. Koike,
I've read your draft on path segment monitoring (http://www.ietf.org/id/draft-koike-mpls-tp-temporal-hitless-psm-00.txt) and I think that there is one more potentially fatal issue with the SPME mechanism if it is used for on-demand OAM. (My reading of the draft is that you see on-demand as the primary mode for path segment monitoring as it will be used to localize an observed fault.)

To the best of my understanding, setting up a temporal SPME will result in the LSRs within the monitoring segment only looking at the added (stacked) labels and not on the labels of the original LSP. (Actually, the label immediately below the SPME one will have to be set to one expected on the tail end node of the segment for the original LSP).

This means that problems stemming from incorrect (or unexpected) treatment of labels of the original LSP by the nodes within the monitored segment may disappear when you set up SPME. This includes HW problems during label look-up, mis-configuration etc. Of course, the inversion of this situation is also possible, .e.g., incorrect or unexpected treatment of SPME labels can result in false detection of a fault where none originally existed.

Does this make sense to you? Do you think that I've missed something important?

Regards,
     Sasha

---

From: Yoshinori KOIKE <[email-masked]>
Date: Fri, 09 Jul 2010 20:22:17 +0900

Dear Sasha,

Sorry for the belated reply. I appreciate your interest
in my I-D and also the additional comments.

See in line, please.

[snipped]

> I’ve read your draft on path segment monitoring 
> (http://www.ietf.org/id/draft-koike-mpls-tp-temporal-hitless-psm-00.txt) 
> and I think that there is one more potentially fatal issue with the SPME 
> mechanism if it is used for on-demand OAM. (My reading of the draft is 
> that you see on-demand as the primary mode for path segment monitoring 
> as it will be used to localize an observed fault.)

[YK]
One of the reasons that I took up just on-demand OAM functions at this 
point is because the characteristic of "on-demand" is generally temporal 
for maintenance operation and those operations shouldn't be based on 
pre-configuration.

Pre-design and pre-configuration of PST(label stacking) for on-demand 
(temporal) usage will be difficult for operators to accept, because 
these tasks will additionally increase operator's burden, although 
pre-configuration of PST for pro-active usage might be accepted 
considering the agreement thus far.) Therefore, the solution for 
temporal and hitless segment monitoring does not need to be limited to 
label stacking mechanism like PST which can cause the issue (P-1) and 
(P-2) described in section 4 of my I-D.

However, as I requested to add the two network objectives in section 3,
I would like to pay attention to the discussion about SPME
issue which has been thus far related to both on-demand and proactive
OAM functions.

As you may know, the issue of SPME is now under discussion. Although
the term "SPME" is not used in OAM framewrok-06 draft yet, this is
related to PST which was questioned from item #4 of the following
ITU-T liaison. (#1, 2 & 3 are also related)
https://datatracker.ietf.org/documents/LIAISON/file1028.pdf
I guess that most operators who are familiar with transport network
systems are of much concern to this issue.

> To the best of my understanding, setting up a temporal SPME will result 
> in the LSRs within the monitoring segment only looking at the added 
> (stacked) labels and not on the labels of the original LSP. (Actually, 
> the label immediately below the SPME one will have to be set to one 
> expected on the tail end node of the segment for the original LSP).

[YK]
Regarding the new SPME mechanism, I think there is no consensus
at this moment, however I think the following figure
reflects the point which people are now concerned about and what
you explained based on PST mechanism. (X means the one label
expected on the tail end node D. "210" and "220" are label
allocated for PST/TCM). Correct me, if I'm wrong.

A--100--B--110--C--120--D--130--E
MEP                             MEP

A--100--B-------X-------D--130--E
MEP     \-210--C--220--/        MEP
         MEP'          MEP'<=PST/TCM

The label values of the original path are modified as well as
the values of stacked label. This is not the monitoring of the
original path but the monitoring of a different
path. In other words, the monitoring function can be meaningless.

> This means that problems stemming from incorrect (or unexpected) 
> treatment of labels of the original LSP by the nodes within the 
> monitored segment may disappear when you set up SPME. This includes HW 
> problems during label look-up, mis-configuration etc. Of course, the 
> inversion of this situation is also possible, .e.g., incorrect or 
> unexpected treatment of SPME labels can result in false detection of a 
> fault where none originally existed.

[YK] Thank you very much for the complementary comments.
IMO, operators in transport networks are usually quite sensitive to the
unnecessary modifications or configurations to minimize the possible
issues and managed objects. They prefer the simple configuration and
stable condition.

Best regards,

Yoshinori

> Does this make sense to you? Do you think that I’ve missed something 
> important?
> 
>  
> 
> Regards,
> 
>      Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 10 Jul 2010 22:26:39 +0300

Dear Mr. Koike,
Lots of thanks for a very detailed and informative response.

My reading of your message is that there is nothing new in my observation regardless SPME since other peole have raised similar concerns about this technique.

I wonder if there is a valid solution for segment monitoring that do not require configuring new labels.
E.g., did you (or other people) consider injecting OAM packets at the segment head-end with TTL that would terminate these packets at the segment tail-end? 

Regards,
     Sasha

________________________________________
From: Yoshinori KOIKE [[email-masked]]
Sent: Friday, July 09, 2010 2:22 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: Re: Problems with SPME as the path segment monitoring tool in MPLS-TP

Dear Sasha,

See in line, please.

[snipped]

[YK]

[YK]

Best regards,

Yoshinori

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sat, 10 Jul 2010 22:05:02 +0200

Hi,
It is all about a MIP that cannot initiate an OAM message.
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Alexander Vainshtein
Sent: Saturday, July 10, 2010 10:27 PM
To: Yoshinori KOIKE
Cc: [email-masked]
Subject: Re: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Dear Mr. Koike,

My reading of your message is that there is nothing new in my
observation regardless SPME since other peole have raised similar
concerns about this technique.

I wonder if there is a valid solution for segment monitoring that do not
require configuring new labels.
E.g., did you (or other people) consider injecting OAM packets at the
segment head-end with TTL that would terminate these packets at the
segment tail-end? 

Regards,
     Sasha

Subject: Re: Problems with SPME as the path segment monitoring tool in
MPLS-TP

Dear Sasha,

See in line, please.

[snipped]

> I've read your draft on path segment monitoring
>

[YK]

[YK]

Best regards,

Yoshinori

> Does this make sense to you? Do you think that I've missed something
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Huub van Helvoort <[email-masked]>
Date: Sun, 11 Jul 2010 00:39:54 +0200

Hello Sasha,

You replied:

> observation regardless SPME since other peole have raised
> similar concerns about this technique.
>
> I wonder if there is a valid solution for segment monitoring
> that do not require configuring new labels.
> E.g., did you (or other people) consider injecting OAM packets
> at the segment head-end with TTL that would terminate these
> packets at the segment tail-end?

We have considered using a MEP at a different Maintenance
Entity Group Level. This means that OAM inserted by the source
MEP B and extracted by the sink MEP D will have a lower MEL
than the MEL inserted at MEP A and extracted at MEP E.

MEP B and MEP D (and possible MIP C) will pass through client
traffic and MEP A/E OAM unchanged.

However, we were told that this construct (sub-layering by
using MEL in an MEG) is not possible in MPLS.

Regards, Huub.

> ITU-T liaison. (#1, 2&  3 are also related)

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 11 Jul 2010 08:52:04 +0300

Huub hi!
Lots of thanks for a clarification. 

My first non-technical impression is that we need a draft that discusses various issues with MPLS-TP OAM. The words "we have been told that..." seem to appear all too often on this mailing list. 

Further I think that there is a serous language problem stemming (among other things) from an attempt to use the language originally defined for Ethernet to MPLS while ignoring the fundamental differences in their data planes.
MPLS (sub)layering that is associated with the label stack is not, IMHO, similar to ME levels used in 802.1ag/Y.1731. 

E.g., MIPs at a certain level in Ethernet are reachable via level-associated "All MEPs and MIPs" well-known multicast addresses. Alternatively, one can use a specific globally unique MIP MAC address. Neither of these two methods is available in MPLS, you have to use TTL expiration in order for a MIP to handle an OAM packet. On the other hand, TTL expiration in the top label stack entry does not depend on "levels".

And so we come up with artificial constructs like SPME: the data plane behavior is OK, and ME levels are properly mapped to data plane constructs... The only disadvantage is that you do not monitor the original LSP any more, making the entire construct meaningless. 

Did I miss something?

My 2c,
     Sasha

________________________________________
From: Huub van Helvoort [[email-masked]]
Sent: Sunday, July 11, 2010 1:39 AM
To: Alexander Vainshtein
Cc: Yoshinori KOIKE; [email-masked]
Subject: Re: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

Hello Sasha,

Regards, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Sun, 11 Jul 2010 11:34:08 +0200

Hello Sacha,

You replied:

> My first non-technical impression is that we need a draft that
 > discusses various issues with MPLS-TP OAM. The words "we have
 > been told that..." seem to appear all too often on this mailing list.

There is indeed no draft anymore, the discussion and results
can be found in RFC5317, the result of the JWT.
(the pdf version contains the slides which contain the discussion).

> Further I think that there is a serous language problem stemming
 > (among other things) from an attempt to use the language originally
 > defined for Ethernet to MPLS while ignoring the fundamental
 > differences in their data planes.

Because ITU is using the, what you call "Ethernet language", it may
be good to document the differences that you see i the rosetta stone
draft.

> MPLS (sub)layering that is associated with the label stack is not,
 > IMHO, similar to ME levels used in 802.1ag/Y.1731.

This maybe in the dataplane, but viewed from the management plane there
is no difference.

> E.g., MIPs at a certain level in Ethernet are reachable via
 > level-associated "All MEPs and MIPs" well-known multicast addresses.

If you want to reach a particular MIP or MEP a unicast MAC is used.
Also TTL is used.

> Alternatively, one can use a specific globally unique MIP MAC address.
 > Neither of these two methods is available in MPLS, you have to use
 > TTL expiration in order for a MIP to handle an OAM packet.

The MEL and the TTL can be used to address a specific MIP/MEP.

> On the other hand, TTL expiration in the top label stack entry does
 > not depend on "levels".

But the additional use of the MEL does give you the dependency.

> And so we come up with artificial constructs like SPME: the data
 > plane behavior is OK, and ME levels are properly mapped to data
 > plane constructs... The only disadvantage is that you do not monitor
 > the original LSP any more, making the entire construct meaningless.

I am still trying to understand the SPME construct as well.

Best regards, Huub.

---

From: [email-masked]
Date: Mon, 12 Jul 2010 10:22:21 +0800

Hi Sasha，

draft-zhang-mpls-tp-path-segment-monitoring-00 proposes a SPME mechanism 
which do not require configuring new labels, ie, with TTL. 

please find more detailed contents in the above draft, document link is: 
http://tools.ietf.org/html/draft-zhang-mpls-tp-path-segment-monitoring-00
 
and wish your comments.

Best Regards,

-xuehui

Alexander Vainshtein <[email-masked]> 
发件人:  [email-masked]
2010-07-11 03:26

收件人
Yoshinori KOIKE <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [mpls-tp] Problems with SPME as the path segment monitoring tool in 
MPLS-TP

Dear Mr. Koike,

My reading of your message is that there is nothing new in my observation 
regardless SPME since other peole have raised similar concerns about this 
technique.

Regards,
     Sasha

Dear Sasha,

See in line, please.

[snipped]

[YK]

[YK]

Best regards,

Yoshinori

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 12 Jul 2010 07:06:16 +0200

Hi,

So you propose to use TTL TLV – does it really scale? NO! This requires DPIs for each packet in the network! 

Also, what is the entity that initiates the message? Is it a MEP – of course it cannot be a MEP, as only LERs can  only LERs can implement MEPs? Is it a MIP – of course it is not as a MIP cannot initiate an OAM message! So what kind of entity it is?

Best regards,

Nurit

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Monday, July 12, 2010 5:22 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: [mpls-tp] 答复: Re: Problems with SPME as the path segment monitoring tool in MPLS-TP

Hi Sasha， 

draft-zhang-mpls-tp-path-segment-monitoring-00 proposes a SPME mechanism which do not require configuring new labels, ie, with TTL. 

please find more detailed contents in the above draft, document link is: http://tools.ietf.org/html/draft-zhang-mpls-tp-path-segment-monitoring-00 
  
and wish your comments. 

Best Regards, 

-xuehui 

2010-07-11 03:26 

收件人

抄送

主题

Re: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

Dear Mr. Koike,

Regards,
    Sasha

Dear Sasha,

See in line, please.

[snipped]

[YK]

[YK]

Best regards,

Yoshinori

---

From: [email-masked]
Date: Mon, 12 Jul 2010 14:03:48 +0800

Hi, Nurit, all

IMHO, it does not require DPIs for each packet, the reason as follow:
(1)If TTL does not equals to 1, the middle nodes just pass it to next hop, 
apparently no DPIs
(2)If TTL=1, then check the ach TLV (including TTL TLV) and OAM packets, I 
think it is the normal processing of each packet. 

Of course, MIP nodes cannot initaite an OAM message, so we suggest to add 
the SPM MEP configuration in [tp-identifiers], similary to the segment-PW 
MEP definition of MS-PW.

Maybe I am wrong. 

Best regards.

Fei :)

"Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]> 
发件人:  [email-masked]
2010-07-12 13:06

收件人
<[email-masked]>, "Alexander Vainshtein" 
<[email-masked]>
抄送
[email-masked], [email-masked]
主题
Re: [mpls-tp]   答复: Re:  Problems with SPME as the path segment 
monitoring tool in MPLS-TP

Hi,
So you propose to use TTL TLV – does it really scale? NO! This requires 
DPIs for each packet in the network! 
Also, what is the entity that initiates the message? Is it a MEP – of 
course it cannot be a MEP, as only LERs can  only LERs can implement MEPs? 
Is it a MIP – of course it is not as a MIP cannot initiate an OAM 
message! So what kind of entity it is?
Best regards,
Nurit

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of ext [email-masked]
Sent: Monday, July 12, 2010 5:22 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: [mpls-tp] 答复: Re: Problems with SPME as the path segment 
monitoring tool in MPLS-TP

Hi Sasha， 

  
and wish your comments. 

Best Regards, 

-xuehui 

收件人

Dear Mr. Koike,

Regards,
    Sasha

Dear Sasha,

See in line, please.

[snipped]

[YK]

[YK]

Best regards,

Yoshinori

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 12 Jul 2010 09:12:13 +0300

Xuehui, Nurit,
I've looked up the draft and I am not sure I can follow the TTL TLV solution.
The ACH header will not be looked unless the label immediately above GAL is not popped or until TTL (in the label stack entry, not in the TTL TLV!) expires. The TTL TLV per se does not add any forwarding functionality.

There are IMO two different problems:

 1.  The data plane problem: how to force termination of the segment OAM packets at the segment tail-end?
 2.  The OAM architecture problem: how to introduce MEPs (which, in the current OAM architecture are the only entities that can insert OAM messages) at the segment boundaries if segment is not represented by an LSP?

The first problem is easily solved by TTL expiration IMO, but I must admit that I do not see a solution for the 2nd problem. IMHO and FWIW is points to a deficiency in the MPLS-TP OAM framework/architecture: if the desired behavior can be implemented, but it does not match the concept, something is probably wrong with the concept.

What do you think?

My 2c,

     Sasha

________________________________
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [[email-masked]]
Sent: Monday, July 12, 2010 8:06 AM
To: [email-masked]; Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] 答复: Re: Problems with SPME as the path segment monitoring tool in MPLS-TP

Hi,

Hi Sasha，

and wish your comments.

Best Regards,

-xuehui

2010-07-11 03:26

收件人

抄送

主题

Dear Mr. Koike,

Regards,
    Sasha

Dear Sasha,

See in line, please.

[snipped]

[YK]

[YK]

Best regards,

Yoshinori

---

From: [email-masked]
Date: Mon, 12 Jul 2010 14:37:28 +0800

Hi Sasha,

Thanks for your reading, wish not waste you too much time.  :)

See below:

 The TTL TLV per se does not add any forwarding functionality.
ZF->Yeah, agree, the ttl value is adding in the label of the new oam 
meassage sent by the SPME initiating nodes, and at the end of SPME, the 
TTL value will be decreased to 1.
The TTL TLV is just used to make sure that the response message will be 
sent to the correct sending node of this SPME.

2. The OAM architecture problem: how to introduce MEPs (which, in the 
current OAM architecture are the only entities that can insert OAM 
messages) at the segment boundaries if segment is not represented by an 
LSP?
ZF-> Yeah, but I think it is esay to define the MEPs of SPME (maybe I make 
a big mistake),  just like the segment-PW MEP definition. So, we suggest 
to add the MEP definition of SPME in the document [tp-identifiers]. 

Best Regards.

Fei 

2010-07-12 14:12

收件人
"Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>, 
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
Re: [mpls-tp] 答复: Re:  Problems with SPME as the path segment monitoring 
tool in MPLS-TP

Xuehui, Nurit,
I've looked up the draft and I am not sure I can follow the TTL TLV 
solution. 
The ACH header will not be looked unless the label immediately above GAL 
is not popped or until TTL (in the label stack entry, not in the TTL TLV!) 
expires. The TTL TLV per se does not add any forwarding functionality.
 
There are IMO two different problems:
1.      The data plane problem: how to force termination of the segment 
OAM packets at the segment tail-end? 
2.      The OAM architecture problem: how to introduce MEPs (which, in the 
current OAM architecture are the only entities that can insert OAM 
messages) at the segment boundaries if segment is not represented by an 
LSP?
The first problem is easily solved by TTL expiration IMO, but I must admit 
that I do not see a solution for the 2nd problem. IMHO and FWIW is points 
to a deficiency in the MPLS-TP OAM framework/architecture: if the desired 
behavior can be implemented, but it does not match the concept, something 
is probably wrong with the concept.
 
What do you think?
 
My 2c,
     Sasha 

Subject: RE: [mpls-tp] 答复: Re: Problems with SPME as the path segment 

Hi,

Hi Sasha， 

  
and wish your comments. 

Best Regards, 

-xuehui 

收件人

Dear Mr. Koike,

Regards,
    Sasha

Dear Sasha,

See in line, please.

[snipped]

[YK]

[YK]

Best regards,

Yoshinori

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 12 Jul 2010 11:17:12 +0300

Fei hi,
Lots of thanks for the clarification.

Using TTL TLV for providing to the tail end of a segment the information about its distance from the head-end will surely work for a co-routed bi-directional LSP.
I am not sure if the situation when the segment looks like an associated bidirectional LSP (it is not an LSP without SPME) could be covered in such a way.
On the other hand, I am not sure what are the expectations regarding segment monitoring for an associated bi-directional LSP. Has this ever been considered?

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, July 12, 2010 9:37 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Subject: Re: [mpls-tp] 答复: Re: Problems with SPME as the path segment monitoring tool in MPLS-TP

Hi Sasha,

See below:

 The TTL TLV per se does not add any forwarding functionality.
ZF->Yeah, agree, the ttl value is adding in the label of the new oam meassage sent by the SPME initiating nodes, and at the end of SPME, the TTL value will be decreased to 1.
The TTL TLV is just used to make sure that the response message will be sent to the correct sending node of this SPME.

2. The OAM architecture problem: how to introduce MEPs (which, in the current OAM architecture are the only entities that can insert OAM messages) at the segment boundaries if segment is not represented by an LSP?
ZF-> Yeah, but I think it is esay to define the MEPs of SPME (maybe I make a big mistake),  just like the segment-PW MEP definition. So, we suggest to add the MEP definition of SPME in the document [tp-identifiers].

Best Regards.

Fei

2010-07-12 14:12

收件人

"Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>, "[email-masked]" <[email-masked]>

抄送

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

主题

Re: [mpls-tp] 答复: Re:  Problems with SPME as the path segment monitoring tool in MPLS-TP

Xuehui, Nurit,

What do you think?

My 2c,

     Sasha

Hi,

Hi Sasha，

and wish your comments.

Best Regards,

-xuehui

2010-07-11 03:26

收件人

抄送

主题

Dear Mr. Koike,

Regards,
   Sasha

Dear Sasha,

See in line, please.

[snipped]

[YK]

[YK]

Best regards,

Yoshinori

---

From: Dan Frost <[email-masked]>
Date: Mon, 12 Jul 2010 09:31:07 +0100

On Mon, Jul 12, 2010 at 09:12:13AM +0300, Alexander Vainshtein wrote:
> [...]
> messages) at the segment boundaries if segment is not represented by
> an LSP?
>
> The first problem is easily solved by TTL expiration IMO, but I must
> admit that I do not see a solution for the 2nd problem. IMHO and FWIW
> is points to a deficiency in the MPLS-TP OAM framework/architecture:
> if the desired behavior can be implemented, but it does not match the
> concept, something is probably wrong with the concept.

That is why it has been suggested that the MEP/MIP distinction in its
current form is too rigid for MPLS-TP, and that what one actually has
are MPs.

-d

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 12 Jul 2010 11:37:06 +0300

Dan,
Lots of thanks for an interesting input.

Has this proposal ever been captured in a draft? 

Regards,
     Sasha

-----Original Message-----
From: Dan Frost [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 11:31 AM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

-d

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 12 Jul 2010 13:17:37 +0300

Reverting to plain text and resending - too large as HTML.

Regards,
     Sasha

From: Alexander Vainshtein 
Sent: Monday, July 12, 2010 12:33 PM
To: [email-masked]'
Cc: [email-masked]; [email-masked]; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Subject: RE: RE: [mpls-tp] 答复: Re: Problems with SPME as the path segment monitoring tool in MPLS-TP

Hi Fei,
I am not sure you can use traceroute in the case of an “associated bi-directional segment”. In order for the originator of echo-request to receive echo-reply, the replier must be already aware of the required TTL.  Looks like an egg and chicken problem to me.
Co-routed bi-directional can, of course, be solved using the ACH TTL TLV.

Did I miss something?

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 11:46 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Subject: RE: RE: [mpls-tp] 答复: Re: Problems with SPME as the path segment monitoring tool in MPLS-TP

Hi Sasha 

I think it is suitable for associated bidirectional LSP also, the reason is below: 

A<----------->B-------->C------->D<------------>E 
             \                  / 
              \<----G---F-----</ 

See the figure above: 
B--C---D and D--F--G---B constitute the SPME of associated bidirectional LSP. 

When node B sends the new OAM message for SPME, the TTL in label is 2, but the TTL TLV value in the Ach header is set to 3. 

The TTL value of the forward and backward direction can be got by traceroute. 

Wish you like my explanation. 

Fei  :) 

Alexander Vainshtein <[email-masked]> 
2010-07-12 16:17 
收件人
"[email-masked]" <[email-masked]> 
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]> 
主题
RE: [mpls-tp]  答复: Re:  Problems with SPME as the path segment monitoring tool in MPLS-TP

Fei hi, 

Regards, 
     Sasha 

Hi Sasha, 

See below: 

Best Regards. 

Fei 

收件人

Xuehui, Nurit, 

What do you think? 
  
My 2c, 
     Sasha 

Hi, 

Hi Sasha， 

and wish your comments. 

Best Regards, 

-xuehui 

收件人

Dear Mr. Koike,

Regards,
  Sasha

Dear Sasha,

See in line, please.

[snipped]

[YK]

[YK]

Best regards,

Yoshinori

---

From: Loa Andersson <[email-masked]>
Date: Mon, 12 Jul 2010 15:07:09 +0200

Dan,

yes this problem has been understood for a while, the down side
of changing the terminology that we after that would have
three sets of maintenance points

IEEE:
   Maintenance End Point (MEP)
   Maintenance Intermediate Point (MIP)
ITU-T:
   Maintenance Entity Group End Point (MEP)
   Maintenance Entity Group Intermediate Point (MEP)
IETF:
   Maintenance Point (MP)

I think that there is something fundamentally flawed in the
definitions as they both specify the location (end or intermediate)
and what these maintenance points can do or not (originate or
not originate).

It might be that there is not such a 1 to 1 relationship between
where you are and what you can do.

/Loa

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Dan Frost <[email-masked]>
Date: Mon, 12 Jul 2010 14:59:26 +0100

>   Maintenance Entity Group Intermediate Point (MEP)

Indeed, but the first two sets didn't arise from MPLS.  It may come down
to a choice between consistency with (some version of) Ethernet
terminology and correctness with respect to how MPLS actually works.

> where you are and what you can do.

Right.  I can see at least three ways out:

  - loosen the MIP/MEP definitions and functional restrictions 
  - generalise the notion of ME to include path segments
  - decide that what we really have are MPs

-d

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 12 Jul 2010 17:05:18 +0300

Dan, Loa,
I concur with Dan. 

IEEE has coined the terms for Ethernet, and ITU-T has adopted it as if they were generic. 
I assume that this was correct for traditional transport networks, and in any case the OAM mechanisms for these networks have been already defined.

MPLS-TP which, as a data plane, is quite different from Ethernet, proves IMHO that these terms (and their underlying mechanisms) are not so generic as it seems. 

Regards,
     Sasha

-----Original Message-----
From: Dan Frost [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 4:59 PM
To: Loa Andersson
Cc: Alexander Vainshtein; [email-masked]
Subject: Re: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

-d

---

From: Loa Andersson <[email-masked]>
Date: Mon, 12 Jul 2010 16:42:59 +0200

Sasha, inline please

> I concur with Dan.
you and me, both! :)
>
> IEEE has coined the terms for Ethernet,
sure and that is still correct
> and ITU-T has adopted it as if they were generic.
this is possibly where it started to slip and bit

> I assume that this was correct for traditional transport
 > networks, and in any case the OAM mechanisms for these
 > networks have been already defined.
>
> MPLS-TP which, as a data plane, is quite different
 > from Ethernet,
I'm quite happy that this is starting to be recognized

> proves IMHO that these terms (and theirunderlying mechanisms)
 > are not so generic as it seems.

that was the point I tried to make by my statement

"I think that there is something fundamentally flawed in the
  definitions as they both specify the location (end or intermediate)
  and what these maintenance points can do or not (originate or
  not originate).

  It might be that there is not such a 1 to 1 relationship between
  where you are and what you can do."

An awkward way of saying "not so generic"!

The second point I tried to make was that, if we at all at this
point in developing the standard, want to rename MIPs/MEPs, we should
do that - give them a really different name, and MPs does not fill
that criteria.

I'm not done thinking about this, but since the cat is out ...

/Loa

--

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 12 Jul 2010 16:49:26 +0200

Hej Loa,

> Maintenance Intermediate Point (MIP)

In IEEE 802.1ag you will find the definition of Maintenance Domain
(MD) which is the same as the ITU-T Maintenance Entity Group (MEG).
It also defines the Maintenance Association (MA) which is the same
as the ITU-T Maintenace Entity (ME).

> Maintenance Entity Group Intermediate Point (MIP)

The description and use of MEP and MIP is the same between IEEE
and ITU-T.
So the IEEE and ITU-T sets are the same.

> and what these maintenance points can do or not (originate or

There are differences:
- MEPs have strong interaction with NMS for fault handling and
   performance monitoring, they terminate their OAM.
- MIPs have no interaction with NMS, they respond only to MEP
   messages. They are used as monitors.

> where you are and what you can do.

If you look at them from a management point of view, they are
certainly different.

Regards, Huub.

---

From: Loa Andersson <[email-masked]>
Date: Mon, 12 Jul 2010 16:52:21 +0200

Huub,

you do understand that the acronym don't expand the same?

/Loa

--

---

From: David Allan I <[email-masked]>
Date: Mon, 12 Jul 2010 10:56:43 -0400

Problem is we have 3 things, MEPs, MIPs and intermediate nodes. 

The definition of MIP is artificially constrained on the premise that the existence of MIPs is both sparse, configured, and divorced from the necessity of intermediate nodes originating messages (e.g. AIS). So we have two definitions for a common point in the network (maintenance points on a transit node), one that answers messages and one that originates them.

IMO every transit node in IETF-land hosts a MIP and as such MIPs should be allowed to originate unsolicited messages and we can collapse to a single definition for the entity that performs transit node OAM functions. That would eliminate a confusing and artificial distinction.

my 2 cents
D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Monday, July 12, 2010 10:43 AM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

Sasha, inline please

you and me, both! :)

 > networks, and in any case the OAM mechanisms for these  > networks have been already defined.
>

The second point I tried to make was that, if we at all at this point in developing the standard, want to rename MIPs/MEPs, we should do that - give them a really different name, and MPs does not fill that criteria.

/Loa
>> yes this problem has been understood for a while, the down side of 
>> changing the terminology that we after that would have three sets of 
>> maintenance points
>>
>> IEEE:
> Indeed, but the first two sets didn't arise from MPLS.  It may come 
> down to a choice between consistency with (some version of) Ethernet 
>> and what these maintenance points can do or not (originate or not 
>> originate).
>>
>>>> 2.  The OAM architecture problem: how to introduce MEPs (which, in 
>>>> the current OAM architecture are the only entities that can insert 
>>>> OAM
>>>> messages) at the segment boundaries if segment is not represented 
>>>> by an LSP?
>>>>
>>>> The first problem is easily solved by TTL expiration IMO, but I 
>>>> must admit that I do not see a solution for the 2nd problem. IMHO 
>>>> and FWIW is points to a deficiency in the MPLS-TP OAM framework/architecture:
>>>> if the desired behavior can be implemented, but it does not match 
>>>> the concept, something is probably wrong with the concept.
>>>
>>> That is why it has been suggested that the MEP/MIP distinction in 
>>> its current form is too rigid for MPLS-TP, and that what one 
>>> actually has are MPs.
>>>
>>> -d
>>>
>>>> What do you think?
>>>>
>>>> My 2c,
>>>>
>>>>       Sasha
>>>

-- 

                                              +46 767 72 92 13 _______________________________________________

---

From: Loa Andersson <[email-masked]>
Date: Mon, 12 Jul 2010 17:05:07 +0200

Dave, et.al

how about ingress LSR (i-LSR) - LSR  - egress LSR (e-LSR)?

or is that searching under the street lamp? :)

/Loa

On 2010-07-12 16:56, David Allan I wrote:
>   >  networks, and in any case the OAM mechanisms for these>  networks have been already defined.
>>

--

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 12 Jul 2010 17:10:25 +0200

Hej  Loa,

> you do understand that the acronym don't expand the same?

Yes, but we have seen that on the OAM soap as well.
Howver, as I wrote, the use and behaviour is the same.

Rgeards, Huub.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 12 Jul 2010 17:50:03 +0100

Sasha,

On 12 Jul 2010, at 07:12, Alexander Vainshtein wrote:
> 	• The data plane problem: how to force termination of the segment OAM packets at the segment tail-end?
> 	• The OAM architecture problem: how to introduce MEPs (which, in the current OAM architecture are the onlyentities that can insert OAM messages) at the segment boundaries if segment is not represented by an LSP?

I have probably missed something as I have not thought about MPLS-TP for a while but if we have a case such as below:

A===B===C

Where there is an LSP between A & C (via B) and we want to monitor the segment B-C can B not insert a packet into the LSP with the correct label for B-C, or is the issue that doing so would be breaking the MPLS forwarding architecture?

Thanks
Ben

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 12 Jul 2010 21:45:37 +0300

Ben,
Lots of thanks for a nice question.
My understanding of MPLS forwarding architecture (data plane) is that the insertion you ask about is perfectly valid.
In fact, this is the normal behavior for LSPs that are created by LDP; and, of course forwarding architecture does not depend on the protocol that has been used to set up an LSP. E.g., you can LSP-Ping an IPv4 prefix from every node on an LSP that carries a FEC represented by this prefix.

I believe that Section 3.26 "Label Merging" discusses the problem in detail.

Hopefully this note addresses your concerns.

Regards,
     Sasha

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 7:50 PM
To: Alexander Vainshtein
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] 答复: Re: Problems with SPME as the path segment monitoring tool in MPLS-TP

Sasha,

A===B===C

Thanks
Ben

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 12 Jul 2010 12:43:54 -0700

Dear Sasha,
you've brought very interesting point.If a transit node of a
bidirectional (not sure that co-routedness required as for associated
case node SHOULD be aware of directions of the LSP) can inject an OAM
packet what Unique MEP-ID it will use then? Perhaps, along discussion
of terminology, it would be Unique MP-ID?

Regards,
Greg

On Mon, Jul 12, 2010 at 11:45 AM, Alexander Vainshtein
<[email-masked]> wrote:
>>       * The data plane problem: how to force termination of the segment OAM packets at the segment tail-end?
>>       * The OAM architecture problem: how to introduce MEPs (which, in the current OAM architecture are the onlyentities that can insert OAM messages) at the segment boundaries if segment is not represented by an LSP?

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 12 Jul 2010 20:58:55 +0100

Sasha,

> I believe that Section 3.26 "Label Merging" discusses the problem in detail.

If an intermediate MPLS node can insert a packet into an LSP then I don't see how the architectural issue of how to perform segment monitoring is restricted to MPLS, it must surely also apply to Ethernet.

Perhaps someone more expert than I in IEEE/ITU-T Ethernet OAM can explain how such a scenario is handled within the Ethernet OAM architecture?

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 13 Jul 2010 17:59:37 +0200

Sasha,

See inline.. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Vainshtein
Sent: zondag 11 juli 2010 7:52
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Huub hi!

My first non-technical impression is that we need a draft that discusses
various issues with MPLS-TP OAM. The words "we have been told that..." seem
to appear all too often on this mailing list. 

Further I think that there is a serous language problem stemming (among
other things) from an attempt to use the language originally defined for
Ethernet to MPLS while ignoring the fundamental differences in their data
planes.
MPLS (sub)layering that is associated with the label stack is not, IMHO,
similar to ME levels used in 802.1ag/Y.1731. 

E.g., MIPs at a certain level in Ethernet are reachable via level-associated
"All MEPs and MIPs" well-known multicast addresses. A

[maarten] If you read G.8021 then you will notice that MIPs and MEPs do not
use these multicast addresses. MIPs and MEPs in G.8021 use the TYPE field
(value 89-02), the MEL field, the OpCode field and for loopback also the DA
field (value must match local EUI-48 value).

lternatively, one can use a specific globally unique MIP MAC address.
Neither of these two methods is available in MPLS, you have to use TTL
expiration in order for a MIP to handle an OAM packet. On the other hand,
TTL expiration in the top label stack entry does not depend on "levels".

[maarten] MPLS-TP MIPs and MEPs could be specified and build very similarly
to Ethernet MIPs and MEPs and use the GAL (label 13), MEL field (e.g. in TC
bits of GAL or in reserved bits of (G)ACh), Channel Type (in (G)ACh),
Message Type/OpCode and for loopback an Identifier in a TLV (looked at after
e.g. TTL expiry).
Comparison MPLS-TP and Ethernet OAM encodings:
GAL label 13 <-> TYPE 89-02
GAL/(G)ACh "MEL" <-> MEL
ACh ChType/MessageType <-> OpCode
TLV ID <-> DA.

And so we come up with artificial constructs like SPME: the data plane
behavior is OK, and ME levels are properly mapped to data plane
constructs... The only disadvantage is that you do not monitor the original
LSP any more, making the entire construct meaningless. 

[maarten] The label stacking method is indeed an inappropriate encoding
method for tandem connection monitoring. But it was pushed very hard as the
only available method... But as we now notice this doesn't make it a
suitable encoding method.

Regards,
Maarten

Did I miss something?

My 2c,
     Sasha

Hello Sasha,

> segment head-end with TTL that would terminate these packets at the 

We have considered using a MEP at a different Maintenance Entity Group
Level. This means that OAM inserted by the source MEP B and extracted by the
sink MEP D will have a lower MEL than the MEL inserted at MEP A and
extracted at MEP E.

MEP B and MEP D (and possible MIP C) will pass through client traffic and
MEP A/E OAM unchanged.

However, we were told that this construct (sub-layering by using MEL in an
MEG) is not possible in MPLS.

Regards, Huub.

> Sorry for the belated reply. I appreciate your interest in my I-D and 
> also the additional comments.
>
> See in line, please.
>
> [snipped]
>
>> (http://www.ietf.org/id/draft-koike-mpls-tp-temporal-hitless-psm-00.t
>> xt) and I think that there is one more potentially fatal issue with 
>> the SPME mechanism if it is used for on-demand OAM. (My reading of 
>> the draft is that you see on-demand as the primary mode for path 
>> segment monitoring as it will be used to localize an observed fault.)
>
> [YK]
> point is because the characteristic of "on-demand" is generally 
> temporal for maintenance operation and those operations shouldn't be 
> based on pre-configuration.
>
> However, as I requested to add the two network objectives in section 
> 3, I would like to pay attention to the discussion about SPME issue 
> which has been thus far related to both on-demand and proactive OAM 
> functions.
>
>> To the best of my understanding, setting up a temporal SPME will 
>> result in the LSRs within the monitoring segment only looking at the 
>> added
>> (stacked) labels and not on the labels of the original LSP. 
>> (Actually, the label immediately below the SPME one will have to be 
>> set to one expected on the tail end node of the segment for the original
LSP).
>
> [YK]
> Regarding the new SPME mechanism, I think there is no consensus at 
> this moment, however I think the following figure reflects the point 
> which people are now concerned about and what you explained based on 
> PST mechanism. (X means the one label expected on the tail end node D. 
> "210" and "220" are label allocated for PST/TCM). Correct me, if I'm 
> wrong.
>
> The label values of the original path are modified as well as the 
> values of stacked label. This is not the monitoring of the original 
> path but the monitoring of a different path. In other words, the 
> monitoring function can be meaningless.
>
>> monitored segment may disappear when you set up SPME. This includes 
>> HW problems during label look-up, mis-configuration etc. Of course, 
>> the inversion of this situation is also possible, .e.g., incorrect or 
>> unexpected treatment of SPME labels can result in false detection of 
>> a fault where none originally existed.
>
> IMO, operators in transport networks are usually quite sensitive to 
> the unnecessary modifications or configurations to minimize the 
> possible issues and managed objects. They prefer the simple 
> configuration and stable condition.
>
> Best regards,
>
> Yoshinori
>

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 13 Jul 2010 17:59:38 +0200

Yoshinori,

In some previous emails to mpls-tp mailinglists of IETF and ITU-T I have
sugggested to introduce a special reserved TCM label (e.g. with value 12) to
resolve the issue that the connection configuration get changed when an
additional MEG level is activated or deactivated.

In your example the use of such TCM label value (e.g. 12) would results in
the following label allocation:

A--100--B------12-------D--130--E
MEP     \-110--C--120--/        MEP
         MEP'          MEP'<=PST/TCM 

The connection label values (A-B: 100, B-C: 110, C-D: 120, D-E: 130) of the
transport service or transport path layer connection are not changed in this
case; there is just an additional TCM label with value e.g. 12 added on the
links B-C and C-D. 

In the functional model the additional TCM label stack entry header is
inserted in the adaptation source function (MT/MT_A_So) of the TCM MEP' and
removed by the adaptation sink function (MT/MT_A_Sk) of the TCM MEP'.

The regular connection labels 110 and 120 are in both cases inserted and
extracted by the adaptation source and sink functions (MT/MT-m_A_So,
MT/MT-m_A_Sk) of the NCM MEP.

In node B this implies that the signal received from A is processed
functionally as follows:
0) assume that node B is a transport service layer switching node in which
the transport path layer connections terminate
1) transport path layer NCM MEP terminates the transport path NCM OAM 
2) transport path to transport service layer adaptation sink function
extracts from the Adapted information
   a) the transport path S-bit and
   b) the transport service label (100) and
   c) the transport service TC-bits
and outputs the transport service Characteristic Information (associated
with label 100) on the appropriate MT_CP (connection point) connected to the
MT Connection function.
3) the transport service CI on this MT_CP will be switched to the output of
the MT Connection function and will then be applied at the MT_CP of the
MT/MT_A_So function in the TCM MEP'.
4) this MT/MT_A_So function will then insert 
   a) the TC-bits and 
   b) the TCM label value (e.g. 12) in the label field and 
   c) the S-bit
5) the reset of the TCM MEP' function will then insert the TCM OAM and TCM
TTL 
6) the resulting TCM CI is then applied at the transport path layer NCM
MEP's adaptation source function (MT/MT-m_A_So) which inserts 
   a) the transport service TC-bits and 
   b) the label value (110) in the transport service label field and 
   c) the transport path S-bit.

When the TCM MEP' function is not active, the functional processing in node
B will be 
1) transport path layer NCM MEP terminates the transport path NCM OAM 
2) transport path to transport service layer adaptation sink function
extracts from the Adapted information
   a) the transport path S-bit and
   b) the transport service label (100) and
   c) the transport service TC-bits
and outputs the transport service Characteristic Information (associated
with label 100) on the appropriate MT_CP (connection point) connected to the
MT Connection function.
3) the transport service CI on this MT_CP will be switched to the output of
the MT Connection function and will then be applied at the MT_CP of the
transport path layer NCM MEP's adaptation source function (MT/MT-m_A_So)
which inserts 
   a) the transport service TC-bits and 
   b) the label value (110) in the transport service label field and 
   c) the transport path S-bit.

In order to activate/deactive a TCM MEP function hitless it is necessary to
run a simple hitless activation/deactivation protocol between the TCM MEP'
functions. This protocol must check if both TCM MEP'functions are configured
to be activated/deactivated, and once confirmation is received the TCM MEP'
Source function can activate the additional TCM label stack entry header
insertion after it has inserted a final activation-after-this-OAM frame
message. I.e. a sequence of Ready-to-Active?, Acknowlegde, Activate!
Messages... And for deactivation: Ready-to-Deactivate?, Acknowledge,
Deactivate! message sequence.

In the functional model each adaptation source function inserts a label
field at the top of stack of the incoming MT-CI. In equipment there is a
slightly different processing performed as the MT_CI of multiple connection
points are not physically separated stream, but instead are one multiplexed
stream. 

The external 20-bit label field is replaced by an equipment specific
internal label, which can be any number of bits (e.g. 10, 16, 17, 20, ..).
The TCM label stack entry header with its label value of e.g. 12 has to be
inserted below the equipment specific label. 

The above presents just an option to allow for hitless
activation/deactivation of a TCM MEP function in a transport service,
transport path or section layer connection reusing the label stacking
method.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yoshinori KOIKE
Sent: vrijdag 9 juli 2010 13:22
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Dear Sasha,

Sorry for the belated reply. I appreciate your interest in my I-D and also
the additional comments.

See in line, please.

[snipped]

> (http://www.ietf.org/id/draft-koike-mpls-tp-temporal-hitless-psm-00.tx
> t) and I think that there is one more potentially fatal issue with the 
> SPME mechanism if it is used for on-demand OAM. (My reading of the 
> draft is that you see on-demand as the primary mode for path segment 
> monitoring as it will be used to localize an observed fault.)

[YK]
One of the reasons that I took up just on-demand OAM functions at this point
is because the characteristic of "on-demand" is generally temporal for
maintenance operation and those operations shouldn't be based on
pre-configuration.

Pre-design and pre-configuration of PST(label stacking) for on-demand
(temporal) usage will be difficult for operators to accept, because these
tasks will additionally increase operator's burden, although
pre-configuration of PST for pro-active usage might be accepted considering
the agreement thus far.) Therefore, the solution for temporal and hitless
segment monitoring does not need to be limited to label stacking mechanism
like PST which can cause the issue (P-1) and
(P-2) described in section 4 of my I-D.

However, as I requested to add the two network objectives in section 3, I
would like to pay attention to the discussion about SPME issue which has
been thus far related to both on-demand and proactive OAM functions.

As you may know, the issue of SPME is now under discussion. Although the
term "SPME" is not used in OAM framewrok-06 draft yet, this is related to
PST which was questioned from item #4 of the following ITU-T liaison. (#1, 2
& 3 are also related)
https://datatracker.ietf.org/documents/LIAISON/file1028.pdf
I guess that most operators who are familiar with transport network systems
are of much concern to this issue.

> expected on the tail end node of the segment for the original LSP).

[YK]
Regarding the new SPME mechanism, I think there is no consensus at this
moment, however I think the following figure reflects the point which people
are now concerned about and what you explained based on PST mechanism. (X
means the one label expected on the tail end node D. "210" and "220" are
label allocated for PST/TCM). Correct me, if I'm wrong.

The label values of the original path are modified as well as the values of
stacked label. This is not the monitoring of the original path but the
monitoring of a different path. In other words, the monitoring function can
be meaningless.

[YK] Thank you very much for the complementary comments.
IMO, operators in transport networks are usually quite sensitive to the
unnecessary modifications or configurations to minimize the possible issues
and managed objects. They prefer the simple configuration and stable
condition.

Best regards,

Yoshinori

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 13 Jul 2010 19:20:31 +0300

Maarten and all,
Please see two short comments inline below.
I've snipped the parts of the text that are not relevant to these comments.
It seems that we have been over these points many times before...

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Tuesday, July 13, 2010 7:00 PM
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP
... snipped ...
E.g., MIPs at a certain level in Ethernet are reachable via level-associated
"All MEPs and MIPs" well-known multicast addresses. 

[maarten] If you read G.8021 then you will notice that MIPs and MEPs do not
use these multicast addresses. MIPs and MEPs in G.8021 use the TYPE field
(value 89-02), the MEL field, the OpCode field and for loopback also the DA
field (value must match local EUI-48 value).
[[[Sasha]]]  If you read IEEE 802.1ag you will see that CCM and LTM are transmitted
As multicast messages to appropriate Group addresses; only LBM, LBR and LTR are 
Transmitted as unicast. If this does not match the ITU-T definitions, then, IMHO,
IEEE takes precedence on all aspects of Ethernet technology.

... snipped...

[maarten] MPLS-TP MIPs and MEPs could be specified and build very similarly
to Ethernet MIPs and MEPs and use the GAL (label 13), MEL field (e.g. in TC
bits of GAL or in reserved bits of (G)ACh), Channel Type (in (G)ACh),
Message Type/OpCode and for loopback an Identifier in a TLV (looked at after
e.g. TTL expiry).
[[[Sasha]]] I think that we have agreed to drop attempts to re-define the TC bits?
And in any case, do not forget that in MPLS neither TC bits nor ACH header do not affect forwarding.
E.g., if you encode the MEL in the ACH header, blocking of higher-level OAM packets by a lower-level MEP
Will not happen etc.

Comparison MPLS-TP and Ethernet OAM encodings:
GAL label 13 <-> TYPE 89-02
GAL/(G)ACh "MEL" <-> MEL
ACh ChType/MessageType <-> OpCode
TLV ID <-> DA.
[[[Sasha]]] The difference between the DA and TLV ID is that the latter affects 
Ethernet forwarding (is part of the data plane). While the former does not affect MPLS forwarding.

Regards,
Maarten

Did I miss something?

My 2c,
     Sasha

Hello Sasha,

Regards, Huub.

LSP).

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 13 Jul 2010 19:30:29 +0300

Maarten,
Where in the label stack do you want your new label?

If it is below the label of the original LSP, it will not be looked at by D 
(because D does not pop the label of the original LSP, it uses it to forward the packet to E)
and hence it would be useless.

If it is above, its behavior has to be exactly the same as of the already defined
Router Alert label (see RFC 3032 for details) and hence there is no need to invent it again.  

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: Tuesday, July 13, 2010 7:00 PM
To: 'Yoshinori KOIKE'
Cc: [email-masked]
Subject: Re: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

Yoshinori,

Regards,
Maarten

-----Original Message-----

Dear Sasha,

See in line, please.

[snipped]

[YK]

[YK]

Best regards,

Yoshinori

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 13 Jul 2010 18:50:35 +0200

Hi Ben,

Segment (cq tandem connection) monitoring is a technology agnostic
application supported by SDH, OTN, ATM and Ethernet. It is also supported in
vendor specific "Label14 OAM" supporting equipment (based on draft G.8114
specifications).

In Ethernet it is possible to insert an Ethernet OAM frame (Y.1731, 802.1ag)
at an intermediate point along e.g. a P2P VLAN connection. This Eth OAM
frame is either inserted by a TCM MEP Source function into the VLAN
connection, or by a MIP function, or by a TCM MEP Sink or Server MEP Sink
function (AIS, LCK frames).

A TCM MEP Source function adds its Ethernet OAM frames (LCK, CCM, LBM, LBR,
LTM, LTR, LMM, LMR, DMM, DMR, 1DM, MCC, etc) without changing the incoming
frames.

A TCM MEP Sink function inspects the TYPE field of every received frame, and
if this TYPE field contains the value 89-02, then the MEL, Version and
OpCode bits are used to determine if and what processing to perform on the
OAM frame. If OpCode is LBM, then also the DA bits are used to determine if
the frame is to be processed.

A MIP function adds its Ethernet OAM frames (LBR, LTM, LTR frames) without
changing the incoming frames.

A MIP function inspects the TYPE field of every received frame, and if this
TYPE field contains the value 89-02, then the MEL, Version and OpCode bits
are used to determine if and what processing to perform on the OAM frame. If
OpCode is LBM, then also the DA bits are used to determine if the frame is
to be processed.

Regards,
Maarten
PS: VPLS capable MPLS-TP equipment has to support Ethernet MIP and MEP
functions. I.e. has to inspect the TYPE, MEL, Version, OpCode and DA fields
of Ethernet frames with VPLS specific CW+PW headers.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ben Niven-Jenkins
Sent: maandag 12 juli 2010 21:59
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] 答复: Re: Problems with SPME as the path segment
monitoring tool in MPLS-TP

Sasha,

On 12 Jul 2010, at 19:45, Alexander Vainshtein wrote:

> My understanding of MPLS forwarding architecture (data plane) is that the
insertion you ask about is perfectly valid.
> In fact, this is the normal behavior for LSPs that are created by LDP;
and, of course forwarding architecture does not depend on the protocol that
has been used to set up an LSP. E.g., you can LSP-Ping an IPv4 prefix from
every node on an LSP that carries a FEC represented by this prefix.
> I believe that Section 3.26 "Label Merging" discusses the problem in
detail.

If an intermediate MPLS node can insert a packet into an LSP then I don't
see how the architectural issue of how to perform segment monitoring is
restricted to MPLS, it must surely also apply to Ethernet.

Perhaps someone more expert than I in IEEE/ITU-T Ethernet OAM can explain
how such a scenario is handled within the Ethernet OAM architecture?

Ben

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 13 Jul 2010 19:22:30 +0200

Hi Maareten,
Please see inline>
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Maarten Vissers
Sent: Tuesday, July 13, 2010 7:51 PM
To: 'Ben Niven-Jenkins'
Cc: [email-masked]
Subject: Re: [mpls-tp]答复: Re: Problems with SPME as the path segment monitoring tool in MPLS-TP

Hi Ben,

A TCM MEP Source function adds its Ethernet OAM frames (LCK, CCM, LBM, LBR,
LTM, LTR, LMM, LMR, DMM, DMR, 1DM, MCC, etc) without changing the incoming
frames.
<Nurit> but with the additional of information that requires DPIs \<Nurit>

<Nurit> how scale it is? Keep in mind that in Ethernet you have only 4K services.......in MPLS-TP you have millions.......would we expect to look at each packet for all the required information? In the propose way today, we handles all packets the same. OAM messages that are sent over LSP/TCM/link are handles either at the MEP which is an egress LER and then the next label is inspected or at the MIP when the TTL is expired and then it is checked that this is really intended for that MIP. \<Nurit> 

Regards,
Maarten

-----Original Message-----

Sasha,

Ben

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 13 Jul 2010 19:28:42 +0200

Hi Maarten,

Please see inline.

Best regards,

Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Maarten Vissers
Sent: Tuesday, July 13, 2010 7:00 PM
To: 'Yoshinori KOIKE'
Cc: [email-masked]
Subject: Re: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Yoshinori,

sugggested to introduce a special reserved TCM label (e.g. with value
12) to

In your example the use of such TCM label value (e.g. 12) would results
in

MEP                             MEP

MEP     \-110--C--120--/        MEP

         MEP'          MEP'<=PST/TCM 

The connection label values (A-B: 100, B-C: 110, C-D: 120, D-E: 130) of
the

transport service or transport path layer connection are not changed in
this

case; there is just an additional TCM label with value e.g. 12 added on
the

links B-C and C-D. 

<Nurit> if I understand correctly (as this should not affect the
end-to-end traffic, then label 12 is proposed only for the OAM messages
over the TCM. Can we say that the OAM messages and the data traffic
share the same fate in this case? 

This was one of the fundamental requirements for OAM. \<Nurit> 

inserted in the adaptation source function (MT/MT_A_So) of the TCM MEP'
and

functionally as follows:

0) assume that node B is a transport service layer switching node in
which

with label 100) on the appropriate MT_CP (connection point) connected to
the

MT Connection function.

3) the transport service CI on this MT_CP will be switched to the output
of

   a) the TC-bits and 

   c) the S-bit

5) the reset of the TCM MEP' function will then insert the TCM OAM and
TCM

TTL 

When the TCM MEP' function is not active, the functional processing in
node

B will be 

with label 100) on the appropriate MT_CP (connection point) connected to
the

MT Connection function.

3) the transport service CI on this MT_CP will be switched to the output
of

which inserts 

In order to activate/deactive a TCM MEP function hitless it is necessary
to

run a simple hitless activation/deactivation protocol between the TCM
MEP'

functions. This protocol must check if both TCM MEP'functions are
configured

to be activated/deactivated, and once confirmation is received the TCM
MEP'

slightly different processing performed as the MT_CI of multiple
connection

points are not physically separated stream, but instead are one
multiplexed

stream. 

internal label, which can be any number of bits (e.g. 10, 16, 17, 20,
..).

The TCM label stack entry header with its label value of e.g. 12 has to
be

method.

Regards,

Maarten

-----Original Message-----

Behalf

Of Yoshinori KOIKE

To: Alexander Vainshtein

Cc: [email-masked]

tool in MPLS-TP

Dear Sasha,

also

the additional comments.

See in line, please.

[snipped]

[YK]

point

pre-configuration.

these

considering

the agreement thus far.) Therefore, the solution for temporal and
hitless

segment monitoring does not need to be limited to label stacking
mechanism

I

term "SPME" is not used in OAM framewrok-06 draft yet, this is related
to

PST which was questioned from item #4 of the following ITU-T liaison.
(#1, 2

& 3 are also related)

systems

[YK]

moment, however I think the following figure reflects the point which
people

are now concerned about and what you explained based on PST mechanism.
(X

MEP                             MEP

MEP     \-210--C--220--/        MEP

         MEP'          MEP'<=PST/TCM

The label values of the original path are modified as well as the values
of

monitoring of a different path. In other words, the monitoring function
can

be meaningless.

issues

condition.

Best regards,

Yoshinori

> Does this make sense to you? Do you think that I've missed something 

 

mpls-tp mailing list

[email-masked]

mpls-tp mailing list

[email-masked]

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 13 Jul 2010 21:04:42 +0200

Sasha,

The new label would be located below the original LSP label stack entry
header. 
MPLS-TP interface ports can be designed to inspect the first 20-bits
following the original LSP label stack entry header of each received packet
for the value 12 or 13. This is what we do in Ethernet, where the 16-bits
following the original VLAN Tag header of every received packet is inspected
for value 89-02.

Many packet processing devices today support both Ethernet and MPLS, and the
version of those devices that support Ethernet OAM are now capable to read a
subset of the bits below the 4-byte VLAN Tag header. Similarly it should be
possible to have those devices made capable to read a subset of the bits
below the 4-byte label stack entry header.

Bits located below VLAN Tag header inspected in an Ethernet frame by a MEP
are:
bits 1-16 (TYPE), 17-19 (MEL), 20-24 (Version), 25-32 (OpCode). In addition
the bits in the DA field above the VLAN Tag header are inspected and used in
case of OpCode is LBM.

Note that for case of VPLS, the VLAN Tag header is replaced by a PW label
stack entry header plus CW header. The bits to inspect with respect to the
PW label stack entry header will thus be:
bits 129-144 (TYPE), 145-147 (MEL), 148-152 (Version), 153-160 (OpCode). In
addition the bits in the DA field (bits 33-80 below PW header) are inspected
and used in case of OpCode is LBM.

Similarly, bits located below original label stack entry header to be
inspected in a MPLS-TP packet by a MEP would be:
bits 1-20 (Label), 20 (S), 33-36 (ACH nibble), 49-64 (Channel Type), and
possibly more dependent on specific encoding of OAM types.
If Bits 1-20 = 12, then extract "Label_12" header from packet; keep orginal
Label stack entry header.
If bits 1-20 = 13, then OAM processing using other inspected bits.

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: dinsdag 13 juli 2010 18:30
To: Maarten Vissers
Cc: [email-masked]; 'Yoshinori KOIKE'
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Maarten,

If it is below the label of the original LSP, it will not be looked at by D
(because D does not pop the label of the original LSP, it uses it to forward
the packet to E) and hence it would be useless.

If it is above, its behavior has to be exactly the same as of the already
defined Router Alert label (see RFC 3032 for details) and hence there is no
need to invent it again.  

Regards,
     Sasha

-----Original Message-----
Of Maarten Vissers

Yoshinori,

Regards,
Maarten

-----Original Message-----

Dear Sasha,

See in line, please.

[snipped]

[YK]

[YK]

Best regards,

Yoshinori

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 13 Jul 2010 22:05:59 +0300

Maarten,
It seems that you still prefer ignore Requirement #1 of MPLS-TP (as recorded in RFC 5654) : 
MPLS-TP data plane MUST be the same as that of MPLS.

Since MPLS ports do not look below the top label if its associated action in the ILM  does not say "Pop and loop", MPLS-TP ports will not do that either.

Regards,
     Sasha

________________________________________
From: Maarten Vissers [[email-masked]]
Sent: Tuesday, July 13, 2010 10:04 PM
To: Alexander Vainshtein
Cc: [email-masked]; 'Yoshinori KOIKE'
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring        tool in MPLS-TP

Sasha,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: dinsdag 13 juli 2010 18:30
To: Maarten Vissers
Cc: [email-masked]; 'Yoshinori KOIKE'
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Maarten,

Regards,
     Sasha

-----Original Message-----

Yoshinori,

Regards,
Maarten

-----Original Message-----

Dear Sasha,

See in line, please.

[snipped]

[YK]

[YK]

Best regards,

Yoshinori

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 13 Jul 2010 21:25:46 +0200

Sasha,

See inline marked [maarten2].. 

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, July 13, 2010 7:00 PM
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP ... snipped ...
E.g., MIPs at a certain level in Ethernet are reachable via level-associated
"All MEPs and MIPs" well-known multicast addresses. 

[maarten] If you read G.8021 then you will notice that MIPs and MEPs do not
use these multicast addresses. MIPs and MEPs in G.8021 use the TYPE field
(value 89-02), the MEL field, the OpCode field and for loopback also the DA
field (value must match local EUI-48 value).
[[[Sasha]]]  If you read IEEE 802.1ag you will see that CCM and LTM are
transmitted As multicast messages to appropriate Group addresses; only LBM,
LBR and LTR are Transmitted as unicast. If this does not match the ITU-T
definitions, then, IMHO, IEEE takes precedence on all aspects of Ethernet
technology.
[maarten2] Your response is not an apples-to-apples comparison... I have
been describing the receive side processing specifications, you describe the
values in the DA field... I have been describing that the value in the DA
field is not being used by the MIP and MEP Sink functions in G.8021, with
execption for the LBM OAM frame. E.g. CCM is using a Group address, and this
Group address is inserted by a MEP Source, and this Group address is ignored
by a MEP sink.

... snipped...

[maarten] MPLS-TP MIPs and MEPs could be specified and build very similarly
to Ethernet MIPs and MEPs and use the GAL (label 13), MEL field (e.g. in TC
bits of GAL or in reserved bits of (G)ACh), Channel Type (in (G)ACh),
Message Type/OpCode and for loopback an Identifier in a TLV (looked at after
e.g. TTL expiry).
[[[Sasha]]] I think that we have agreed to drop attempts to re-define the TC
bits?
And in any case, do not forget that in MPLS neither TC bits nor ACH header
do not affect forwarding.
E.g., if you encode the MEL in the ACH header, blocking of higher-level OAM
packets by a lower-level MEP Will not happen etc.
[maarten2] In Ethernet equipment designed prior to Y.1731/802.1ag extraction
of OAM frames and blocking of higher-level OAM frames by a lower-level MEP
would not happen either. But the Ethernet equipment designed today does
support this capability. Something similar may be possible for MPLS
equipment when it is build to support MPLS-TP OAM. I.e. there is an
identified problem and it might be that solutions to similar problems in
Ethernet could be applicable to MPLS-TP to resolve the problem.

Comparison MPLS-TP and Ethernet OAM encodings:
GAL label 13 <-> TYPE 89-02
GAL/(G)ACh "MEL" <-> MEL
ACh ChType/MessageType <-> OpCode
TLV ID <-> DA.
[[[Sasha]]] The difference between the DA and TLV ID is that the latter
affects Ethernet forwarding (is part of the data plane). While the former
does not affect MPLS forwarding.
[maarten2] For the case of p2p VLANs the DA does not affect Ethernet
forwarding. For the case of such p2p VLANs the DA only affects the port in
the network that will respond to the LBM OAM frame; i.e. the same as for TLV
ID.
Note that in PBB-TE OAM a TLV is used to carry the ID of the MIP as the DA
field is not longer available.

Regards,
Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 13 Jul 2010 21:56:55 +0200

Hi Nurit,
 
See inline...

  _____  

From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:[email-masked]] 
Sent: dinsdag 13 juli 2010 19:29
To: ext Maarten Vissers; Yoshinori KOIKE
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Hi Maarten,

Please see inline.

Best regards,

Nurit

-----Original Message-----
Of ext Maarten Vissers

Yoshinori,

MEP                             MEP

MEP     \-110--C--120--/        MEP

         MEP'          MEP'<=PST/TCM 

links B-C and C-D. 

<Nurit> if I understand correctly (as this should not affect the end-to-end
traffic, then label 12 is proposed only for the OAM messages over the TCM.
Can we say that the OAM messages and the data traffic share the same fate in
this case? 

[maarten]  The fate sharing is guaranteed by having the same LSP label value
on both OAM and non-OAM packets. The Label_12 is described for all incoming
OAM/non-OAM packets that traverse the MPLS-TP Segment B-D. Today the label
value on OAM/non-OAM packets that traverse the MPLS-TP Segment B-D would be
'X' > 15 as illustrated below (copy from Yoshinori's email):

A--100--B------ X -------D--130--E

MEP     \ -210--C-- 220--/        MEP

         MEP'          MEP'<=PST/TCM 

[maarten] With replacement of Label_X by Label_12 it is possible to maintain
the original Label_110 and Label_120 on the B-C and C-D links and thus not
changing the connection.

[maarten] Your suggestion to attach the Label_12 only to incoming OAM frames
is an alternative possiblity. It would require however additional processing
at a Segment/TCM MEP Source function as OAM packets have to be identified
(either Label_13 or Label_12).

Regards,

Maarten

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 13 Jul 2010 22:28:30 +0200

Inline.....

From: ext Maarten Vissers [mailto:[email-masked]] 
Sent: Tuesday, July 13, 2010 10:57 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); 'Yoshinori KOIKE'
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Hi Nurit,

See inline...

Hi Maarten,

Please see inline.

Best regards,

Nurit

-----Original Message-----

Yoshinori,

MEP                             MEP

MEP     \-110--C--120--/        MEP

         MEP'          MEP'<=PST/TCM 

links B-C and C-D. 

[maarten] The fate sharing is guaranteed by having the same LSP label
value on both OAM and non-OAM packets. The Label_12 is described for all
incoming OAM/non-OAM packets that traverse the MPLS-TP Segment B-D. 

<Nurit> so I probably do not understand your proposal. Do you suggest
that if we want to set dynamically a TCM, then when end-to-end traffic
gets to the MEP of the TCM we need to stack it with label 12? Maybe it
can be helpful if you describe the process in phases. We have end-to-end
traffic, and then it is required to set up a TCM between B and D. what
is the process. It could be good if you can use MPLS standard processes
(e.g. swap, stack, push, pop, etc.) and also indicate where label 12 is
put (is it a kind of lsp hierarchy? Is it swapping? )

Today the label value on OAM/non-OAM packets that traverse the MPLS-TP
Segment B-Dwould be 'X' > 15 as illustrated below (copy from Yoshinori's
email):

A--100--B------X -------D--130--E

         MEP'          MEP'<=PST/TCM 

[maarten] With replacement of Label_X by Label_12 it is possible to
maintain the original Label_110 and Label_120 on the B-C and C-D links
and thus not changing the connection.

<Nurit> why it is not possible with the original proposal? It is based
on LSP hierarchy and the original labels are kept. 

[maarten] Your suggestion to attach the Label_12 only to incoming OAM
frames is an alternative possiblity. 

<Nurit> just to be accurate, I did not suggest, I have asked if this is
the intention. 

It would require however additional processing at a Segment/TCM MEP
Source function as OAM packets have to be identified (either Label_13 or
Label_12).

Regards,

Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 13 Jul 2010 22:47:07 +0200

Hi Nurit,

Ethernet OAM capable devices have the ability to look beyond the VLAN Tag
header, and thus support some deeper packet inspection. As described in my
response to Sasha today Ethernet devices need to look up 32 bits below the
VLAN Tag header and for the VPLS case MPLS equipment has to be able to look
up 160 bits below the PW label stack entry header.

Ethernet can have many more then 4k services... Please be aware that in
transport networks Ethernet supports 4k services per interface if there is a
single stage of muxing and up to 16M services (4k x 4k) if there is a
two-stage muxing. Per node there can be any number of Ethernet services.

These max numbers per interface port are typically not reached at all in
transport networks as 10G and 40G wavelengths can only support some hundreds
of Ethernet transport services (e.g. 5M, 10M, 50M, 100M bit rates per
service).

The same bit rates apply for MPLS-TP services, and thus the number of
services per interface port will be limited, and so also the transport
service OAM processing needs.

Regards,
Maarten

-----Original Message-----
From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:[email-masked]] 
Sent: dinsdag 13 juli 2010 19:23
To: ext Maarten Vissers; Ben Niven-Jenkins
Cc: [email-masked]
Subject: RE: [mpls-tp]答复: Re: Problems with SPME as the path segment
monitoring tool in MPLS-TP

Hi Maareten,
Please see inline>
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Maarten Vissers
Sent: Tuesday, July 13, 2010 7:51 PM
To: 'Ben Niven-Jenkins'
Cc: [email-masked]
Subject: Re: [mpls-tp]答复: Re: Problems with SPME as the path segment
monitoring tool in MPLS-TP

Hi Ben,

A MIP function inspects the TYPE field of every received frame, and if this
TYPE field contains the value 89-02, then the MEL, Version and OpCode bits
are used to determine if and what processing to perform on the OAM frame. If
OpCode is LBM, then also the DA bits are used to determine if the frame is
to be processed.
<Nurit> how scale it is? Keep in mind that in Ethernet you have only 4K
services.......in MPLS-TP you have millions.......would we expect to look at
each packet for all the required information? In the propose way today, we
handles all packets the same. OAM messages that are sent over LSP/TCM/link
are handles either at the MEP which is an egress LER and then the next label
is inspected or at the MIP when the TTL is expired and then it is checked
that this is really intended for that MIP. \<Nurit> 

Regards,
Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 13 Jul 2010 23:27:43 +0200

Dave,

MEP and MIP functions represent two sets of OAM processes. 

Interface ports on MPLS-TP equipment may support MIPs but no MEPs, MEPs but
no MIPs, MEPs and MIPs, no MEPs and no MIPs.

Interface ports supporting MEPs may support those only in a "Down"
direction, only in an "Up" direction, or in both "Down" and "Üp" directions.

Interface ports supporting MEPs in the Down direction may support just one,
or two or three Down MEPs. Interface ports supporting MEPs in the Up
direction may support just one or two Up MEPs.

MEP and MIP funcitons are compound functions and can be decomposed in sets
of atomic functions. These atomic functions have Source and Sink parts.
Source atomic functions insert OAM frames, Sink atomic functions extract OAM
frames. Adaptation sink functions can also insert AIS and LCK OAM frames.

The Source atomic functions in a MIP insert OAM frames, in response to
reception and extraction of OAM frames by a Sink atomic function in that
MIP.

The Source atomic functions in a MEP insert OAM frames, in response to
reception and extraction of OAM frames by a Sink atomic function in that
MEP. The Source atomic functions in a MEP insert OAM frames in response to
the reception of a configuration command from management.

MEP and MIP functions describe the OAM functionality supported by an
interface port. 

OAM questions that vendors will be asked to answer will include:
- how many transport service down MEP functions are supported per transport
service instance on the interface port
- how many transport service up MEP functions are supported per transport
service instance on the interface port
- how many transport service instances are supported per interface port
- how many transport service up MEP functions are supported per interface
port
- how many transport service down MEP functions are supported per interface
port
- is a MIP function supported per transport service instance on the
interface port
- is a half-MIP function supportede per transport service instance on the
interface port
- how many transport path down MEP functions are supported per transport
path instance on the interfae port
- how many trnasport path instances are supported per interface port
- is a MIP function supported per transport path instance on the interface
port
- is a half-MIP function supportede per transport path instance on the
interface port
- how many section down MEP functions are supported for the section on the
interface port
- etc.

Instead of the use of the compound MEP and MIP functions one can use the
underlying atomic functions instead to describe the OAM functionality
supported by an interface port. The above questions would then be rephrased
and include lists of atomic functions.

----

It is very clear from the MIP discussions in the past months, that initial
MPLS-TP interface ports may not be able to support MIP functions... Some may
support half-MIP funcitons on board, others may not be able to support such
functions on board but only emulate such functions in a central controller
card in the equipment. Generation of maintenance signal OAM (e.g. AIS) can
as such not be allocated to MIP functions. 

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David Allan I
Sent: maandag 12 juli 2010 16:57
To: Loa Andersson; Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

The definition of MIP is artificially constrained on the premise that the
existence of MIPs is both sparse, configured, and divorced from the
necessity of intermediate nodes originating messages (e.g. AIS). So we have
two definitions for a common point in the network (maintenance points on a
transit node), one that answers messages and one that originates them.

IMO every transit node in IETF-land hosts a MIP and as such MIPs should be
allowed to originate unsolicited messages and we can collapse to a single
definition for the entity that performs transit node OAM functions. That
would eliminate a confusing and artificial distinction.

my 2 cents
D

---

From: <[email-masked]>
Date: Wed, 14 Jul 2010 11:19:33 +0100

Hi Dave, you wrote 12 juli 2010 16:57

> The definition of MIP is artificially constrained on the 
> premise that the existence of MIPs is both sparse, 
> configured, and divorced from the necessity of intermediate 
> nodes originating messages (e.g. AIS). So we have two 
> definitions for a common point in the network (maintenance 
> points on a transit node), one that answers messages and one 
> that originates them.
> 
> IMO every transit node in IETF-land hosts a MIP and as such 
> MIPs should be allowed to originate unsolicited messages and 
> we can collapse to a single definition for the entity that 
> performs transit node OAM functions. That would eliminate a 
> confusing and artificial distinction.

In a cl-ps network you are right.....there are generally no constraints
on connectivity between nodes.  This is not the case in co-ps and co-cs
mode networks.  Here one must create a parent connection entity before
one is allowed to send any OAM or any (adapted from a client) traffic
units.  This means a connection is a constraining construct (under
defect-free conditions) for both OAM and traffic units in the co-ps
mode.  So, in a cl-ps mode layer network one can impose an arbitrary
artificial (ie it is not real) hierarchy of MEPs/MIPs between any pairs
of access points within the overall network topology, but in a co-cs or
co-ps mode layer network one is constrained to allocating MEPs/MIPs to a
specific set of nodes which are in the subset of the topology that
defines the routing of the connection.

This distinction is important for a whole raft of reasons...and it of
course explains why the nature of the labelling of traffic units in the
cl-ps mode is different to that of the co-ps mode....the latter can take
many short-cuts on labelling since the parent connection can hold the
required information (this information is 'known' in CP/MP), eg omit SA
label, omit client (PID) label, DA forwarding label only need be link
local unique.

Now given we need the ability to change the routing of a connection when
needed (eg due to failures or planned works, noting that there is also
usually a need to meet availability SLAs), then why would an operator
want to configure a priori a set of artificial nested TCM levels which
will not be valid across routing changes?

I do not buy any arguments of wanting to measure
performance/availability (esp between multiple parties...since E-NNIs
are another silly idea for a non-TOS layer network like MPLS-TP) for
these reasons:

-	the end-end view between trail termination points is the
critical one (esp for client SLAs)....this will always pick-up any
problems and alert one to the *rare* need to possibly look further
within the connection;

-	since we want the network and its OAM to super reliable then (i)
OAM messages must be as a simple/sparse as possible (BTW there should
also be no AIS in the co-ps mode because of this requirement since it
adds no useful information and is just another source of unreliability
and 'AIS storms') and (ii) there must be minimal a priori config
(ideally none) across failure/restore events;

-	we should not even think about TCM unless we are clear how old
config is deleted and new config is created such that there is *seamless
and accurate* continuation of performance data collection (ie
avail/delay/loss/errors) in the counters held in nodes at TCM points
across failure/restore events.  This must also include 'on-demand'
restoration behaviour (ie where new routing is not known until needed,
ie on failure) and not just prot-sw cases.  I personally think this
requirement cannot be met.....but I also think it should not even be a
problem as we should not be doing TCM at all.

A far superior method of looking inside an end-end connection on the
*rare* occasions one needs to is to ensure that we can tap-off/mirror a
CV/PM end-end OAM flow at intermediate nodes on-demand.  This has none
of the problems noted above and I do wish vendors would look at this
more seriously.  I am indeed rather amazed that no other operators seem
to have thought about this topic much and are asking for the same.
Indeed, I would like to invite other operators who are tracking this
list to comment on this point please.....noting carefully that these
observations on OAM are NOT specific to MPLS-TP but apply to all co-ps
and co-cs mode technologies.

regards, Neil

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Jul 2010 12:40:28 -0400

Huub,

This kind of reminds me of the OSI advocates a long time ago insisting
that a device could be a ES or an IS but could never be both and the
IETF insistance that a host could also be a router and that a router
was always also a host.  That argument was never concluded, unless you
consider that the OSI ES is extinct and ISIS exists only for IP/MPLS.

IMO ITU-T has taken a framework with too many arbitrary restrictions
and made it worse by doing little more than redefining the acronyms
and declaring it generic, when it is in fact too restrictive.  ITU-T's
value added may be negative in this case.

OTOH - If we acknowledge that it would be useful to have capabilities
such as a MIP notifying a MEP of an underlying unprotected fault, then
we are reinventing (more) parts of RSVP-TE signaling in OAM.  We
should also do capability negotition to determine if the MEP is
soft-preempt capable and add soft-preempt to OAM.  ... etc.

For now maybe its best to just drop the MIP restriction on originating
a packet to a MEP.  No need to change the terminology, just drop the
restriction.

Curtis

In message <[email-masked]>
Huub van Helvoort writes:

Hej Loa,

There are differences:

Regards, Huub.

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 14 Jul 2010 19:48:09 +0200

Just some history of the OAM architecture...

OAM architecture that we are working with in transport networks has been
developed since 1990. The basic OAM atomic functions in a MEP have been
defined in the period 1990-1993 (EN 300417-1-1, G.806). This initial OAM
architecture has been extended in the 2nd half of the 90's as part of the
ATM OAM development. The MEP function has been extended with an atomic
function supporting on-demand OAM functionality and these latter atomic
functions have also been combined to create what we know today as MIP
functions. Refer to I.732.

So by the end of the 90's ATM MEP and MIP functions have been in place.

Ethernet OAM architecture is a copy of the ATM OAM architecture. The same
types of pro-active and on-demand atomic functions are defined in Ethernet,
and those functions have been combined into Ethernet MEP and MIP functions
in the similar way as in ATM (I.732).

The main difference between on-demand OAM in ATM and Ethernet is the number
of on-demand OAM functions in Ethernet; it is larger than in ATM. 

OAM architecture in PDH, SDH, ATM, OTN and Ethernet is a common OAM
architecture. The MPLS-TP OAM architecture must align with this common OAM
architecture.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Curtis Villamizar
Sent: woensdag 14 juli 2010 18:40
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Huub,

This kind of reminds me of the OSI advocates a long time ago insisting that
a device could be a ES or an IS but could never be both and the IETF
insistance that a host could also be a router and that a router was always
also a host.  That argument was never concluded, unless you consider that
the OSI ES is extinct and ISIS exists only for IP/MPLS.

IMO ITU-T has taken a framework with too many arbitrary restrictions and
made it worse by doing little more than redefining the acronyms and
declaring it generic, when it is in fact too restrictive.  ITU-T's value
added may be negative in this case.

OTOH - If we acknowledge that it would be useful to have capabilities such
as a MIP notifying a MEP of an underlying unprotected fault, then we are
reinventing (more) parts of RSVP-TE signaling in OAM.  We should also do
capability negotition to determine if the MEP is soft-preempt capable and
add soft-preempt to OAM.  ... etc.

For now maybe its best to just drop the MIP restriction on originating a
packet to a MEP.  No need to change the terminology, just drop the
restriction.

Curtis

Hej Loa,

In IEEE 802.1ag you will find the definition of Maintenance Domain
(MD) which is the same as the ITU-T Maintenance Entity Group (MEG).
It also defines the Maintenance Association (MA) which is the same as the
ITU-T Maintenace Entity (ME).

> ITU-T:
> Maintenance Entity Group End Point (MEP) Maintenance Entity Group 
> Intermediate Point (MIP)

The description and use of MEP and MIP is the same between IEEE and ITU-T.
So the IEEE and ITU-T sets are the same.

There are differences:

> It might be that there is not such a 1 to 1 relationship between where 
> you are and what you can do.

If you look at them from a management point of view, they are certainly
different.

Regards, Huub.

---

From: David Allan I <[email-masked]>
Date: Fri, 16 Jul 2010 15:26:21 -0400

Hi Maarten:

Apologies for the delay in replying. 

>From the below I get the feeling that the term MIP is both hoplessly overloaded and too precisely proscribed. And I am unsure why we are continuing to be pedantic on this issue.

First off, where or how many MIPs reside in a node IMO is orthogonal to the discussion of what it is or does.

If we refer to the generic class of maintenance functions performed by an intermediate node in a path, currently the term MIP does not go far enough as it is contrained to only those that can be interrogated by a source MEP. IMO origination of AIS, LDI and LKR falls in the class of maintenance functions an intermediate node in a path could and should perform, hence having to have a distinction between MIP functionlaity and those functions at least at a high level does not seem useful. At least not in a network where the correspondence between existence of a MIP and nodes is 1:1. Esp. when you suggest there is a set of atomic functions that a MIP can be decomposed into not all of which are implemented in all MIPs. E.g. what is a half-MIP, and are there other fractional MIPs we should be considering?

So to restate, I see no reason not to slightly grow the definition of MIP in an IETF context, and eliminate a source of confusion. It is function that both terminates and generates OAM flows at an intemediate node in a path. For the purposes of equipment recs etc. it can be decomposed further at a later date.

Does that make sense to you?
Best
D

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Tuesday, July 13, 2010 5:28 PM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

Dave,

Interface ports on MPLS-TP equipment may support MIPs but no MEPs, MEPs but no MIPs, MEPs and MIPs, no MEPs and no MIPs.

Interface ports supporting MEPs in the Down direction may support just one, or two or three Down MEPs. Interface ports supporting MEPs in the Up direction may support just one or two Up MEPs.

MEP and MIP funcitons are compound functions and can be decomposed in sets of atomic functions. These atomic functions have Source and Sink parts.
Source atomic functions insert OAM frames, Sink atomic functions extract OAM frames. Adaptation sink functions can also insert AIS and LCK OAM frames.

The Source atomic functions in a MIP insert OAM frames, in response to reception and extraction of OAM frames by a Sink atomic function in that MIP.

The Source atomic functions in a MEP insert OAM frames, in response to reception and extraction of OAM frames by a Sink atomic function in that MEP. The Source atomic functions in a MEP insert OAM frames in response to the reception of a configuration command from management.

MEP and MIP functions describe the OAM functionality supported by an interface port. 

OAM questions that vendors will be asked to answer will include:
- how many transport service down MEP functions are supported per transport service instance on the interface port
- how many transport service up MEP functions are supported per transport service instance on the interface port
- how many transport service instances are supported per interface port
- how many transport service up MEP functions are supported per interface port
- how many transport service down MEP functions are supported per interface port
- is a MIP function supported per transport service instance on the interface port
- is a half-MIP function supportede per transport service instance on the interface port
- how many transport path down MEP functions are supported per transport path instance on the interfae port
- how many trnasport path instances are supported per interface port
- is a MIP function supported per transport path instance on the interface port
- is a half-MIP function supportede per transport path instance on the interface port
- how many section down MEP functions are supported for the section on the interface port
- etc.

Instead of the use of the compound MEP and MIP functions one can use the underlying atomic functions instead to describe the OAM functionality supported by an interface port. The above questions would then be rephrased and include lists of atomic functions.

----

It is very clear from the MIP discussions in the past months, that initial MPLS-TP interface ports may not be able to support MIP functions... Some may support half-MIP funcitons on board, others may not be able to support such functions on board but only emulate such functions in a central controller card in the equipment. Generation of maintenance signal OAM (e.g. AIS) can as such not be allocated to MIP functions. 

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: maandag 12 juli 2010 16:57
To: Loa Andersson; Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

my 2 cents
D

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 19 Jul 2010 12:50:07 +0200

Dave,

>From your words below I get the impression that you do not have a complete
understanding of the functionality represented by MEP and MIP and half-MIP
functions. Before you continue to make further statements, it is better that
you get such understanding. Let me try to educate you in this matter.

We have the following four items:
- OAM messages
- OAM processes generating those messages and processing those messages
- atomic functions containing a specific set of processes
- compound functions containing a specific set of atomic functions

There is a 1:1 mapping of OAM processes into atomic functions.
There is a 1:1 mapping of atomic functions into compound functions.

Note that "POINTS" do not have the capability to generate and insert or
extract and process any OAM message or any other element of the frame/packet
stream. All processing is performed in processes inside atomic functions.

Termination Source (XXX_TT_So, XXX_FT_So) functions generate a specific
subset of OAM messages; i.e. the pro-active OAM messages like CC/CV, LM, DM,
RDI.
Termination Sink (XXX_TT_Sk, XXX_FT_Sk) functions terminate and process a
specific subset of OAM messages; i.e. the pro-active OAM messages like
CC/CV, LM, DM, RDI, LCK, AIS.

Diagnostic Termination Source (XXXDe_TT_So, XXXDi_TT_So, XXXDe_FT_So,
XXXDi_FT_So) functions generate a specific subsets of OAM messages; i.e. the
on-demand OAM messages like LBM, LBR, LTM, LTR, LMM, LMR, DMM, DMR, 1DM,
TST.
Diagnostic Termination Sink (XXXDe_TT_Sk, XXXDi_TT_Sk, XXXDe_FT_Sk,
XXXDi_FT_S) functions terminate and process a specific subsets of OAM
messages; i.e. the on-demand OAM messages like LBM, LBR, LTM, LTR, LMM, LMR,
DMM, DMR, 1DM, TST.

Adaptation Source (YYY/XXX_A_So, XXX/ZZZ_A_So) functions generate a specific
subset of OAM messages; i.e. the pro-active maintenance signal LCK and the
communication channel signals like MCC, SCC, APS, SSM.
Adaptation Sink (YYY/XXX_A_Sk, XXX/ZZZ_A_Sk) functions terminate and process
a specific subset of OAM messages and generate a specific subset of OAM
messages; i.e. generate the pro-active maintenance signals LCK and AIS and
terminate the communication channel signals like MCC, SCC, APS, SSM.

Tandem connection Adaptation Source (XXX/XXX_A_So) functions generate a
specific subset of OAM messages; i.e. the pro-active maintenance signal LCK
and the communication channel signals like MCC, SCC and APS.
Tandem connection Adaptation Sink (XXX/XXX_A_Sk) functions terminate and
process a specific subset of OAM messages and generate a specific subset of
OAM messages; i.e. generate the pro-active maintenance signals LCK and AIS
and terminate the communication channel signals like MCC, SCC and APS.

A MEP Source function contains the following atomic functions:
XXX/ZZZ_A_So + XXX_(T/F)T_So + XXX/XXX_A_So + XXXDe_(T/F)_A_So
A MEP Sink function contains the following atomic functions:
XXX/ZZZ_A_Sk + XXX_(T/F)T_Sk + XXX/XXX_A_Sk + XXXDe_(T/F)_A_Sk

A half-MIP source function contains the following atomic functions:
XXX/XXX_A_So + XXXDi_(T/F)_A_So
A half-MIP sink function contains the following atomic functions:
XXX/XXX_A_Sk + XXXDi_(T/F)_A_Sk

A MIP function contains two back-to-back half-MIP functions. This implies
that a MIP function consists of
XXXDi_(T/F)_A_Sk + XXX/XXX_A_Sk + XXX/XXX_A_So + XXXDi_(T/F)_A_So 
in one direction and in the other direction
XXXDi_(T/F)_A_So + XXX/XXX_A_So + XXX/XXX_A_Sk + XXXDi_(T/F)_A_Sk

A Server MEP Source function (server layer YYY) contains the following
atomic functions:
YYY/XXX_A_So + YYY_(T/F)T_So + YYY/YYY_A_So + YYYDe_(T/F)_A_So
A MEP Sink function contains the following atomic functions:
YYY/XXX_A_Sk + YYY_(T/F)T_Sk + YYY/YYY_A_Sk + YYYDe_(T/F)_A_Sk

Please use the terms MIP and MEP in the above context of compound functions
representing well defined set of atomic functions and OAM processes.

Regards,
Maarten

-----Original Message-----
From: David Allan I [mailto:[email-masked]] 
Sent: vrijdag 16 juli 2010 21:26
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Hi Maarten:

>From the below I get the feeling that the term MIP is both hoplessly
overloaded and too precisely proscribed. And I am unsure why we are
continuing to be pedantic on this issue.

First off, where or how many MIPs reside in a node IMO is orthogonal to the
discussion of what it is or does.

If we refer to the generic class of maintenance functions performed by an
intermediate node in a path, currently the term MIP does not go far enough
as it is contrained to only those that can be interrogated by a source MEP.
IMO origination of AIS, LDI and LKR falls in the class of maintenance
functions an intermediate node in a path could and should perform, hence
having to have a distinction between MIP functionlaity and those functions
at least at a high level does not seem useful. At least not in a network
where the correspondence between existence of a MIP and nodes is 1:1. Esp.
when you suggest there is a set of atomic functions that a MIP can be
decomposed into not all of which are implemented in all MIPs. E.g. what is a
half-MIP, and are there other fractional MIPs we should be considering?

So to restate, I see no reason not to slightly grow the definition of MIP in
an IETF context, and eliminate a source of confusion. It is function that
both terminates and generates OAM flows at an intemediate node in a path.
For the purposes of equipment recs etc. it can be decomposed further at a
later date.

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, July 13, 2010 5:28 PM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Dave,

----

Regards,
Maarten

---

From: David Allan I <[email-masked]>
Date: Mon, 19 Jul 2010 09:56:07 -0400

HI Maarten:

I think you were missing my point, which is a source of frustration to me as a document editor. There is a set of OAM functions that for MPLS universally exist at each transit node in an MPLS-TP transport path, but there is no one term to describe that set. It is already decomposed into MIPs, half MIPs, source MEP adaptation functions etc. which collectively implement the required functionality at a given sub-layer. That I have to decompose the functions at an intermediate node has been a source of confusion, and has resulted in comments posted against the draft seeking clarification on things that are obvious to you given how you've carved the world up below but not so to others.

I hope that is clearer
Dave

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Monday, July 19, 2010 6:50 AM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

Dave,

>From your words below I get the impression that you do not have a complete understanding of the functionality represented by MEP and MIP and half-MIP functions. Before you continue to make further statements, it is better that you get such understanding. Let me try to educate you in this matter.

Note that "POINTS" do not have the capability to generate and insert or extract and process any OAM message or any other element of the frame/packet stream. All processing is performed in processes inside atomic functions.

Termination Source (XXX_TT_So, XXX_FT_So) functions generate a specific subset of OAM messages; i.e. the pro-active OAM messages like CC/CV, LM, DM, RDI.
Termination Sink (XXX_TT_Sk, XXX_FT_Sk) functions terminate and process a specific subset of OAM messages; i.e. the pro-active OAM messages like CC/CV, LM, DM, RDI, LCK, AIS.

Diagnostic Termination Source (XXXDe_TT_So, XXXDi_TT_So, XXXDe_FT_So,
XXXDi_FT_So) functions generate a specific subsets of OAM messages; i.e. the on-demand OAM messages like LBM, LBR, LTM, LTR, LMM, LMR, DMM, DMR, 1DM, TST.
Diagnostic Termination Sink (XXXDe_TT_Sk, XXXDi_TT_Sk, XXXDe_FT_Sk,
XXXDi_FT_S) functions terminate and process a specific subsets of OAM messages; i.e. the on-demand OAM messages like LBM, LBR, LTM, LTR, LMM, LMR, DMM, DMR, 1DM, TST.

Adaptation Source (YYY/XXX_A_So, XXX/ZZZ_A_So) functions generate a specific subset of OAM messages; i.e. the pro-active maintenance signal LCK and the communication channel signals like MCC, SCC, APS, SSM.
Adaptation Sink (YYY/XXX_A_Sk, XXX/ZZZ_A_Sk) functions terminate and process a specific subset of OAM messages and generate a specific subset of OAM messages; i.e. generate the pro-active maintenance signals LCK and AIS and terminate the communication channel signals like MCC, SCC, APS, SSM.

Tandem connection Adaptation Source (XXX/XXX_A_So) functions generate a specific subset of OAM messages; i.e. the pro-active maintenance signal LCK and the communication channel signals like MCC, SCC and APS.
Tandem connection Adaptation Sink (XXX/XXX_A_Sk) functions terminate and process a specific subset of OAM messages and generate a specific subset of OAM messages; i.e. generate the pro-active maintenance signals LCK and AIS and terminate the communication channel signals like MCC, SCC and APS.

A MEP Source function contains the following atomic functions:
XXX/ZZZ_A_So + XXX_(T/F)T_So + XXX/XXX_A_So + XXXDe_(T/F)_A_So A MEP Sink function contains the following atomic functions:
XXX/ZZZ_A_Sk + XXX_(T/F)T_Sk + XXX/XXX_A_Sk + XXXDe_(T/F)_A_Sk

A MIP function contains two back-to-back half-MIP functions. This implies that a MIP function consists of XXXDi_(T/F)_A_Sk + XXX/XXX_A_Sk + XXX/XXX_A_So + XXXDi_(T/F)_A_So in one direction and in the other direction XXXDi_(T/F)_A_So + XXX/XXX_A_So + XXX/XXX_A_Sk + XXXDi_(T/F)_A_Sk

A Server MEP Source function (server layer YYY) contains the following atomic functions:
YYY/XXX_A_So + YYY_(T/F)T_So + YYY/YYY_A_So + YYYDe_(T/F)_A_So A MEP Sink function contains the following atomic functions:
YYY/XXX_A_Sk + YYY_(T/F)T_Sk + YYY/YYY_A_Sk + YYYDe_(T/F)_A_Sk

Please use the terms MIP and MEP in the above context of compound functions representing well defined set of atomic functions and OAM processes.

Regards,
Maarten

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: vrijdag 16 juli 2010 21:26
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

Hi Maarten:

If we refer to the generic class of maintenance functions performed by an intermediate node in a path, currently the term MIP does not go far enough as it is contrained to only those that can be interrogated by a source MEP.
IMO origination of AIS, LDI and LKR falls in the class of maintenance functions an intermediate node in a path could and should perform, hence having to have a distinction between MIP functionlaity and those functions at least at a high level does not seem useful. At least not in a network where the correspondence between existence of a MIP and nodes is 1:1. Esp.
when you suggest there is a set of atomic functions that a MIP can be decomposed into not all of which are implemented in all MIPs. E.g. what is a half-MIP, and are there other fractional MIPs we should be considering?

So to restate, I see no reason not to slightly grow the definition of MIP in an IETF context, and eliminate a source of confusion. It is function that both terminates and generates OAM flows at an intemediate node in a path.
For the purposes of equipment recs etc. it can be decomposed further at a later date.

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, July 13, 2010 5:28 PM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

Dave,

----

Regards,
Maarten

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 19 Jul 2010 17:39:37 +0300

Dave, Maarten and all,
I think that, if anything, this thread has demonstrated (again) lack of compatibility between the generic OAM model
defined in the ITU-T documents and the MPLS (also MPLS-TP) data plane defined in the IETF documents.

Multiple references to "future MPLS switches that will do" all kinds of things LSRs do not do today in Maarten's postings to this list indicate, IMHO, that we can all agree on that.

How can we resolve such incompatibility? There are, obviously, two basic techniques:
- Modify the MPLS data plane to match the ITU-T OAM model
OR
- Modify the OAM model to reflect correctly the existing MPLS data plane.

>From my point of view, both RFC 5654 and recently approved for publication MPLS Transport Profile Data Plane Architecture draft indicate that the IETF consensus supports the 2nd option. But, of course, I can be wrong here.

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Monday, July 19, 2010 4:56 PM
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

HI Maarten:

I hope that is clearer
Dave

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Monday, July 19, 2010 6:50 AM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

Dave,

Regards,
Maarten

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: vrijdag 16 juli 2010 21:26
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

Hi Maarten:

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, July 13, 2010 5:28 PM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

Dave,

----

Regards,
Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 21 Jul 2010 08:27:56 +0200

Hi Dave,

The rationale for the allocation of OAM functions to atomic functions and
atomic functions is to describe the OAM functions that come always together
and those that may be together or may be separate.

Operators can express the required OAM functions in their nodes by means of
expression the required set of atomic functions in a node. And vendors can
express the provided set of OAM functions in a node by presenting the
functional model of their nodes in terms of atomic functions supported. 

A Transport Service Switching node has different sets of atomic functions
(and thus OAM) then a Transport Path Switching node, and both nodes have
again a different set of atomic functions (and thus OAM) then a Network
Termination node.

As the set of OAM functions required in e.g. a Transport Service Switching
node will differ between nodes with only intra-domain  NNIs and nodes with
intra- and inter-domain NNIs, the OAM requirements (expressed in sets of
atomic functions) are typically expressed in the functioanl model of NNI and
UNI-N interface ports.

Also nodes supporting Transport Service layer protection switching will have
different set of OAM requirements than nodes not supporting Transport
Service layer protection switching. Similarly for nodes supporting Transport
Path layer protection switching and nodes not supporting such protection
switching.

It is possible to specify some reference nodes and then describe the OAM
requirements of those reference nodes. Reference nodes could be a Transport
Service Switching node, a Transport Path Switching node, a Transport Service
and Transport Path Switching node and a Network Termination node. Assume
that the Switching nodes are able to support intra- and inter-domain NNI
ports and that the intra-domain NNI ports are able to support protection
switching. Also assume that the Transport Service Switching nodes and
Network Termination nodes are able to support p2p, p2mp, rmp and mp2mp
services. Also support that the Switching nodes can be at the edge of a
domain and be connected to a next domain in which the Transport Path
connection is continued as a Transport Service connection, or in which the
Section connection is continued as a Transport Service connection.

It is possible to present the OAM requirements for those reference nodes,
and indicate which OAM functions will be associated with the optional
protection switching, inter-domain NNI and TP->TS interconnect and
Section->TS interconnect.

The only way to express the OAM function requirements unambiguously is per
NNI and UNI-N port on those reference nodes, not per node.

ITU-T has now about 20 year experience with expressing the OAM function
requirements per node/interface port, and it might be smart that MPLS-TP
uses this experience and associated documentation instead of trying to
reinvent the wheel.

Regards,
Maarten

-----Original Message-----
From: David Allan I [mailto:[email-masked]] 
Sent: maandag 19 juli 2010 15:56
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

HI Maarten:

I think you were missing my point, which is a source of frustration to me as
a document editor. There is a set of OAM functions that for MPLS universally
exist at each transit node in an MPLS-TP transport path, but there is no one
term to describe that set. It is already decomposed into MIPs, half MIPs,
source MEP adaptation functions etc. which collectively implement the
required functionality at a given sub-layer. That I have to decompose the
functions at an intermediate node has been a source of confusion, and has
resulted in comments posted against the draft seeking clarification on
things that are obvious to you given how you've carved the world up below
but not so to others.

I hope that is clearer
Dave

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, July 19, 2010 6:50 AM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Dave,

A MEP Source function contains the following atomic functions:
XXX/ZZZ_A_So + XXX_(T/F)T_So + XXX/XXX_A_So + XXXDe_(T/F)_A_So A MEP Sink
function contains the following atomic functions:
XXX/ZZZ_A_Sk + XXX_(T/F)T_Sk + XXX/XXX_A_Sk + XXXDe_(T/F)_A_Sk

A MIP function contains two back-to-back half-MIP functions. This implies
that a MIP function consists of XXXDi_(T/F)_A_Sk + XXX/XXX_A_Sk +
XXX/XXX_A_So + XXXDi_(T/F)_A_So in one direction and in the other direction
XXXDi_(T/F)_A_So + XXX/XXX_A_So + XXX/XXX_A_Sk + XXXDi_(T/F)_A_Sk

A Server MEP Source function (server layer YYY) contains the following
atomic functions:
YYY/XXX_A_So + YYY_(T/F)T_So + YYY/YYY_A_So + YYYDe_(T/F)_A_So A MEP Sink
function contains the following atomic functions:
YYY/XXX_A_Sk + YYY_(T/F)T_Sk + YYY/YYY_A_Sk + YYYDe_(T/F)_A_Sk

Regards,
Maarten

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: vrijdag 16 juli 2010 21:26
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Hi Maarten:

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, July 13, 2010 5:28 PM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Dave,

----

Regards,
Maarten

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 21 Jul 2010 09:56:56 +0100

> uses this experience and associated documentation instead of trying to

The IETF is not entirely new to the game when it comes to it's OAM model:

http://tools.ietf.org/html/rfc792

- Stewart

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 21 Jul 2010 12:56:30 +0200

Sasha,

If you expect that the additional of OAM to MPLS-TP can be done without
changes to the NNI and UNI-N interface ports on MPLS equipment then you will
be disappointed; lots of changes will be needed... If ASICs are used in
those interface ports then those ASICs have to be redesigned. If network
processors and/or FPGAs are sued then those devices have to be reprogrammed
with support of MPLS-TP OAM functions.

Does this change the MPLS data plane? Some would say yes, others would say
no. The latter ones would say that the forwarding is still following the
same rules, so no change of the basic processing in the data plane. The
former will look at their devices and conclude that those have to support
instead of 1 or 2 label inserting operations in future e.g. 7 label
inserting operations and counting of packets and inserting of CC/CV frames
at 3.3 ms periods, etc.

Both groups are right however...

The OAM architecture that I describe does not change the MPLS data plane as
it is based on label based forwarding and label stacking... And at the same
time it changes the NNI and UNI-N port devices as it adds more label
stacking and new OAM processing...

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: maandag 19 juli 2010 16:40
To: David Allan I; Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Dave, Maarten and all,
I think that, if anything, this thread has demonstrated (again) lack of
compatibility between the generic OAM model defined in the ITU-T documents
and the MPLS (also MPLS-TP) data plane defined in the IETF documents.

Multiple references to "future MPLS switches that will do" all kinds of
things LSRs do not do today in Maarten's postings to this list indicate,
IMHO, that we can all agree on that.

How can we resolve such incompatibility? There are, obviously, two basic
techniques:
- Modify the MPLS data plane to match the ITU-T OAM model OR
- Modify the OAM model to reflect correctly the existing MPLS data plane.

>From my point of view, both RFC 5654 and recently approved for publication
MPLS Transport Profile Data Plane Architecture draft indicate that the IETF
consensus supports the 2nd option. But, of course, I can be wrong here.

Regards,
     Sasha

-----Original Message-----

HI Maarten:

I hope that is clearer
Dave

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, July 19, 2010 6:50 AM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Dave,

Regards,
Maarten

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: vrijdag 16 juli 2010 21:26
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Hi Maarten:

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, July 13, 2010 5:28 PM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Dave,

----

Regards,
Maarten

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 21 Jul 2010 14:58:21 +0300

Maarten,
Glad to see that we have reached at least some sort of agreement.
This is, you acknowledge that there are two points of view regarding what constitutes MPLS data plane and whether it is - or is not - compatible with the OAM functionality as defined by ITU-T.

This said, I identify myself with the group that thinks that the MPLS data plane is not an abstract notion "based on label based forwarding and stacking" that can be freely interpreted. Rather, the MPLS data plane has been defined in RFC 3031 and extended in a series of related IETF standards.
IMHO and FWIW, this group represents rough consensus which is one of the two foundation stones of the IETF process. But, of course, I can be wrong about that.

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Wednesday, July 21, 2010 1:57 PM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

Sasha,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: maandag 19 juli 2010 16:40
To: David Allan I; Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Dave, Maarten and all,

Regards,
     Sasha

-----Original Message-----

HI Maarten:

I hope that is clearer
Dave

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, July 19, 2010 6:50 AM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Dave,

Regards,
Maarten

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: vrijdag 16 juli 2010 21:26
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Hi Maarten:

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, July 13, 2010 5:28 PM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Dave,

----

Regards,
Maarten

---

From: David Allan I <[email-masked]>
Date: Wed, 21 Jul 2010 17:43:56 -0400

Hi Maarten:

There are several things that nag me in this answer, bear with me here...

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Wednesday, July 21, 2010 2:28 AM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

Hi Dave,

The rationale for the allocation of OAM functions to atomic functions and atomic functions is to describe the OAM functions that come always together and those that may be together or may be separate.

Operators can express the required OAM functions in their nodes by means of expression the required set of atomic functions in a node. And vendors can express the provided set of OAM functions in a node by presenting the functional model of their nodes in terms of atomic functions supported.

A Transport Service Switching node has different sets of atomic functions (and thus OAM) then a Transport Path Switching node, and both nodes have again a different set of atomic functions (and thus OAM) then a Network Termination node.

Actually I'd challenge that. What we have in MPLS-TP is literal recursion of sub-layers, or label levels, or whatever (choose your term), with the requisite functionality for a given relative point in a given LSP path being common and independent of the specific sub-layer the LSP is associated with. Further the LSP hierarchy will be arbitrary from LSP to LSP, some may have SPMEs, some may not all switched from a common LFIB, the LFIB being independent of the sub-layering.(unlike for example ethernet which required the concept of MEL, or OTN which has a switching hierarchy of it's own).

For legacy reasons we have multiple OAM encapsulations, and we have perhaps additional functionalities (e.g. CFI) that are unique to specific sub-layers typically the layering bookends of service layer and section. IMO those are outliers of the common OAM set.

otherwise the only potential distinction is "is this an internal interface or a business interface?"

>From the POV of modelling the instrumentation of an individual LSP, the placement of certain functions likely matters IMO with the ideal being that all intermediate functions are effectively a singluarity such that there is no aspect "uncovered"or uninstrumented. But that is modelling, not implementation and only examining a fraction of the overall requirements of an MPLS node in isolation.

But from my point of view every MPLS node (in an object oriented sense) implements the full set of ALL atomic functions that can be associated with the maintenance of an LSP, as the node may assume any role (termination, transit etc, for any of the sub-layers associated the MPLS-TP architecture.

My reason for saying that is that my experience is that the degree of nodal specialization you are discussing below does not actually exist. The majority of nodes in a network will host a UNI and all will be required to have that capability, to avoid the need to deploy a second box to meet a customer request.  Ergo, it will be expected to do everything. At least that is how the RFPs will read.

So to summarize,

1) OAM functionality will largely be common/identical across the set of MPLS-TP sub-layers as we are discussing simple and arbitrary recursion in the label stack.
2) The set of functions required for a given LSP at an intermediate node will typically be the complete set of functions required at an intermediate node.
3) The existence of SPMEs (the TP version of carrier supporting carrier) simply means that a business interface is one where only specific sub-layers are exposed, with little ramification on the implementation of instrumentation of the sub-layers in general.
4) All nodes will implement the complete set of OAM functionality as all nodes can assume any role in any sub-layer.

I appreciate that the modelling background of what you present is path/fixed-hierarchy based, it is one of several views required and necessary to both conceptualize and eventually manage this stuff. I'd assert it is not the only view and perhaps is limited by the fixed and structured hierarchical nature of TDM/SDH/OTN networks that does not exist in the packet world.

my 2 cents

cheers
D

As the set of OAM functions required in e.g. a Transport Service Switching node will differ between nodes with only intra-domain  NNIs and nodes with
intra- and inter-domain NNIs, the OAM requirements (expressed in sets of atomic functions) are typically expressed in the functioanl model of NNI and UNI-N interface ports.

Also nodes supporting Transport Service layer protection switching will have different set of OAM requirements than nodes not supporting Transport Service layer protection switching. Similarly for nodes supporting Transport Path layer protection switching and nodes not supporting such protection switching.

It is possible to specify some reference nodes and then describe the OAM requirements of those reference nodes. Reference nodes could be a Transport Service Switching node, a Transport Path Switching node, a Transport Service and Transport Path Switching node and a Network Termination node. Assume that the Switching nodes are able to support intra- and inter-domain NNI ports and that the intra-domain NNI ports are able to support protection switching. Also assume that the Transport Service Switching nodes and Network Termination nodes are able to support p2p, p2mp, rmp and mp2mp services. Also support that the Switching nodes can be at the edge of a domain and be connected to a next domain in which the Transport Path connection is continued as a Transport Service connection, or in which the Section connection is continued as a Transport Service connection.

It is possible to present the OAM requirements for those reference nodes, and indicate which OAM functions will be associated with the optional protection switching, inter-domain NNI and TP->TS interconnect and
Section->TS interconnect.

The only way to express the OAM function requirements unambiguously is per NNI and UNI-N port on those reference nodes, not per node.

ITU-T has now about 20 year experience with expressing the OAM function requirements per node/interface port, and it might be smart that MPLS-TP uses this experience and associated documentation instead of trying to reinvent the wheel.

Regards,
Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 26 Jul 2010 11:00:31 +0200

Retry... Original email 43k...
________________________________

From: Maarten Vissers [mailto:[email-masked]] 
Sent: maandag 26 juli 2010 10:40
To: 'David Allan I'
Cc: [email-masked]'
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Hi Dave,
 
I completely agree with you in the sense that there will be MPLS-TP
equipment that will have all functions supported. I am also very much aware
that we will have small Network Termination equipment that will only have a
subset of functions. Then I expect that there will be MPLS-TP equipment that
has installed a subset of line and trib card types, and consequentially also
has only another subset of functions.
 
But if we would describe the maximum functionality that may be required on
trib and line cards (ignoring FRR at the moment), then we can do so. In my
opinion the following would be part of such maximum functionality (but not
the maximum functionality as more multiplexing may have to be supported):
 
Line Cards, Ingress port
=================
1) PHY Termination Sink
2) PHY to MPLS-TP Section Adaptation Sink
3) MPLS-TP Section TCM MEP Sink (Section SPME MEP Sink)
4) MPLS-TP Section NCM MEP Sink (Section MEP Sink)
5) MPLS-TP Section to Transport Path Adaptation Sink (demuxing)
6) MPLS-TP Transport Path TCM MEP Sink (TP SPME MEP Sink)
7) MPLS-TP Transport Path NCM MEP Sink (TP MEP Sink)
8) MPLS-TP Transport Path to Transport Section Adaptation Sink (demuxing)
9) MPLS-TP Transport Service TCM MEP Sink (SPME MEP Sink) and Ethernet TCM
MEP Sink (SPME MEP Sink)
10) MPLS-TP Transport Service TCM MEP Sink (SPME MEP Sink) and Ethernet TCM
MEP Sink (SPME MEP Sink)
11) MPLS-TP Transport Service TCM MEP Sink (SPME MEP Sink) and Ethernet TCM
MEP Sink (SPME MEP Sink)
12) - 
13) MPLS-TP Transport Service MIP (PW, service-LSP MIPs) and Ethernet MIP
14) MPLS-TP Transport Service TCM MEP Source (SPME MEP Source) and Ethernet
TCM MEP Source (SPME MEP Source)
15) MPLS-TP Transport Path or Service TCM MEP Source (SPME MEP Source) and
Ethernet TCM MEP Source (SPME MEP Source)
 
Line Cards, Egress port
=================
1) PHY Termination Source
2) PHY to MPLS-TP Section Adaptation Source
3) MPLS-TP Section TCM MEP Source (Section SPME MEP Source)
4) MPLS-TP Section NCM MEP Source (Section MEP Source)
5) MPLS-TP Section to Transport Path Adaptation Source (muxing)
6) MPLS-TP Transport Path TCM MEP Source (TP SPME MEP Source)
7) MPLS-TP Transport Path NCM MEP Source (TP MEP Source)
8) MPLS-TP Transport Path to Transport Section Adaptation Source (muxing)
9) MPLS-TP Transport Service TCM MEP Source (SPME MEP Source) and Ethernet
TCM MEP Sink (SPME MEP Source)
10) MPLS-TP Transport Service TCM MEP Source (SPME MEP Source) and Ethernet
TCM MEP Sink (SPME MEP Source)
11) MPLS-TP Transport Service TCM MEP Source (SPME MEP Source) and Ethernet
TCM MEP Sink (SPME MEP Source)
12) Ethernet Traffic Conditioning function
13) MPLS-TP Transport Path or Transport Service MIP (PW, service-LSP,
transport-LSP, PSME-LSP MIPs) and Ethernet MIP
14) MPLS-TP Transport Service TCM MEP Sink (SPME MEP Sink) and Ethernet TCM
MEP Sink (SPME MEP Sink)
15) MPLS-TP Transport Path or Service TCM MEP Sink (SPME MEP Sink) and
Ethernet TCM MEP Sink (SPME MEP Sink)

Trib Cards, Ingress port
=================
0) client native ingress processing 
1) MPLS-TP Transport Service to client Adaptation Source (mapping) and
Ethernet to Ethernet client Adaptation Souce (mapping)
2) MPLS-TP Transport Service NCM MEP Source (PW, service-LSP MEP Source) and
Ethernet NCM or TCM MEP Source
3) MPLS-TP Transport Service TCM MEP Source (SPME MEP Source) and Ethernet
TCM MEP Source
4) MPLS-TP Transport Service TCM MEP Source (SPME MEP Source) and Ethernet
TCM MEP Source
 
Trib Cards, Egress port
=================
0) client native egress processing 
1) MPLS-TP Transport Service to client Adaptation Sink (demapping) and
Ethernet to Ethernet client Adaptation Sink (demapping)
2) MPLS-TP Transport Service NCM MEP Sink (PW, service-LSP MEP Sink ) and
Ethernet NCM or TCM MEP Sink 
3) MPLS-TP Transport Service TCM MEP Sink (SPME MEP Sink ) and Ethernet TCM
MEP Sink 
4) MPLS-TP Transport Service TCM MEP Sink (SPME MEP Sink ) and Ethernet TCM
MEP Sink
 
If you look athe the required label processing required in those cards, then
this can be summarized as follows (if I am not miscounting):
- Line Cards, Ingress port: pop up to 7 labels, swap 1 label, push up to 2
labels
- Line Cards, Egress port: push up to 7 labels, swap 1 label, pop up to 2
labels
- Trib Cards, Ingress port: push up to 3 labels
- Trib Cards, Egress port: pop up to 3 labels.
 
If you look athe the required OAM processing required in those cards, then
this can be summarized as follows (if I am not miscounting):
- Line Cards, Ingress port: terminate up to 7 MPLS-TP OAM MEP sets and 3 Eth
OAM MEP sets, reply to 1 MPLS-TP and Ethernet OAM MIP set, insert up to 2
MPLS-TP and Eth OAM MEP sets
- Line Cards, Egress port: insert up to 7 MPLS-TP OAM MEP sets and 3 Eth OAM
MEP sets, reply to 1 MPLS-TP and Ethernet OAM MIP set, terminate up to 2
MPLS-TP and Eth OAM MEP sets
- Trib Cards, Ingress port: insert up to 3 MPLS-TP and Eth OAM MEP sets
- Trib Cards, Egress port: terminate up to 3 MPLS-TP and Eth OAM MEP sets.
 
I seriously doubt if initial MPLS-TP line and trib cards will be able to
support the above label stacking and OAM numbers. In many cases those
numbers do not have to be supported. E.g. a line card on a node used to
interconnect Transport Path layer transport paths could already perform its
basic function when supporting only a subset of the listed functions.
 
Note that the described line cards support two-stage
multiplexing/demultiplexing. With FRR three-stage multiplexing may be
required and large networks may deploy additional muxing stages to reduce
number of LSPs in core domains further.
 
Regards,
Maarten
PS. Note that OTN is having a flexible ODU hierarchy as well today. Many OTN
networks will just need two ODU layers, large OTN networks may use more. For
1st (2.5G timeslots) to 2nd (1.25G timeslots) Generation OTN interworking an
additional, intermediate ODU level will be used as well. Discussions in
CCAMP this week will be addressing the control of this flexible ODU
hierarchy.

From: David Allan I [mailto:[email-masked]] 
Sent: woensdag 21 juli 2010 23:44
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Hi Maarten:

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Wednesday, July 21, 2010 2:28 AM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Hi Dave,

Actually I'd challenge that. What we have in MPLS-TP is literal recursion of
sub-layers, or label levels, or whatever (choose your term), with the
requisite functionality for a given relative point in a given LSP path being
common and independent of the specific sub-layer the LSP is associated with.
Further the LSP hierarchy will be arbitrary from LSP to LSP, some may have
SPMEs, some may not all switched from a common LFIB, the LFIB being
independent of the sub-layering.(unlike for example ethernet which required
the concept of MEL, or OTN which has a switching hierarchy of it's own).
 
For legacy reasons we have multiple OAM encapsulations, and we have perhaps
additional functionalities (e.g. CFI) that are unique to specific sub-layers
typically the layering bookends of service layer and section. IMO those are
outliers of the common OAM set.
 
otherwise the only potential distinction is "is this an internal interface
or a business interface?"

>From the POV of modelling the instrumentation of an individual LSP, the
placement of certain functions likely matters IMO with the ideal being that
all intermediate functions are effectively a singluarity such that there is
no aspect "uncovered"or uninstrumented. But that is modelling, not
implementation and only examining a fraction of the overall requirements of
an MPLS node in isolation. 

But from my point of view every MPLS node (in an object oriented sense)
implements the full set of ALL atomic functions that can be associated with
the maintenance of an LSP, as the node may assume any role (termination,
transit etc, for any of the sub-layers associated the MPLS-TP architecture.
 
My reason for saying that is that my experience is that the degree of nodal
specialization you are discussing below does not actually exist. The
majority of nodes in a network will host a UNI and all will be required to
have that capability, to avoid the need to deploy a second box to meet a
customer request.  Ergo, it will be expected to do everything. At least that
is how the RFPs will read. 
 
So to summarize, 
 
1) OAM functionality will largely be common/identical across the set of
MPLS-TP sub-layers as we are discussing simple and arbitrary recursion in
the label stack.
2) The set of functions required for a given LSP at an intermediate node
will typically be the complete set of functions required at an intermediate
node.
3) The existence of SPMEs (the TP version of carrier supporting carrier)
simply means that a business interface is one where only specific sub-layers
are exposed, with little ramification on the implementation of
instrumentation of the sub-layers in general.
4) All nodes will implement the complete set of OAM functionality as all
nodes can assume any role in any sub-layer.
 
I appreciate that the modelling background of what you present is
path/fixed-hierarchy based, it is one of several views required and
necessary to both conceptualize and eventually manage this stuff. I'd assert
it is not the only view and perhaps is limited by the fixed and structured
hierarchical nature of TDM/SDH/OTN networks that does not exist in the
packet world.
 
my 2 cents
 
cheers
D