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

From: [email-masked]
Date: Mon, 12 Jul 2010 16:29:18 +0800

Hi Kannan

Yeah, that's my suggestion, but I do not know whether it is on the right 
way or not...

Best Regards

Fei :)

Kannan KV Sampath <[email-masked]> 
2010-07-12 15:16

收件人
"[email-masked]" <[email-masked]>
抄送

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

Hi Zhang,
If you can explicitly show how to identify the MEP_ID for SPME based on 
MS-PW, it would be good for everyone.
 
Will the following interpretation help?
MEP_ID for LSP at the original ingress is represented as “
Src-Global_ID::Src-Node_ID::Src-Tunnel_Num::LSP_Num”
If we add the NodeId of the SPME, it becomes “
Src-Global_ID::Src-Node_ID::Src-Tunnel_Num::LSP_Num::SPME-Global_ID::SPME-Node_ID
”
 
Thanks & Regards,
Kannan.
From: [email-masked] [mailto:[email-masked]] On Behalf 
Of [email-masked]
Sent: Monday, July 12, 2010 12:07 PM
To: Alexander Vainshtein
Cc: [email-masked]; MPLS TP
Subject: Re: [mpls-tp] 答复: Re: Problems with SPME as the path segment 
monitoring tool in MPLS-TP

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 

Alexander Vainshtein <[email-masked]> 
发件人:  [email-masked] 
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 

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

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

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
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp