Subject: [mpls-tp] FW: I-D Action:draft-sprecher-mpls-tp-oam-analysis-04.txt

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 7 May 2009 15:46:32 +0200

Hi,

We have just submitted a new version of the MPLS-TP OAM analysis
document. The updated version can be found in the following link:

http://www.ietf.org/internet-drafts/draft-sprecher-mpls-tp-oam-analysis-
04.txt 

This version has been updated to be aligned with the latest available
version of the OAM requirements document (we will probably need to
update it again once the OAM requirement is revised to include the
latest discussions). 

In this version we addressed comments we received (e.g. on LSP ping,
etc.). This version includes also an introduction of Y.1731 (in addition
to the OAM existing tools) and some considerations with regards to the
requirements. 

We will appreciate if you can review the document and provide your
comments. 

We believe it is important to discuss this document before we get into
the solutions. This is the right context to see the entire picture.

Best regards,

Nurit

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext
[email-masked]
Sent: Thursday, May 07, 2009 3:15 PM
To: [email-masked]
Subject: I-D Action:draft-sprecher-mpls-tp-oam-analysis-04.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

      Title           : MPLS-TP OAM Analysis

      Author(s)       : N. Sprecher, et al.

      Filename        : draft-sprecher-mpls-tp-oam-analysis-04.txt

      Pages           : 22

      Date            : 2009-05-07

The intention of this document is to analyze the set of requirements

for Operations, Administration, and Maintenance (OAM) for the

Transport Profile of MPLS(MPLS-TP) as defined in [MPLS-TP OAM Reqs],

to evaluate whether existing OAM tools (either from the current MPLS

toolset or from the ITU-T documents) can be applied to these

requirements.  Eventually, the purpose of the document is to

recommend which of the existing tools should be extended and what new

tools should be defined to support the set of OAM requirements for

MPLS-TP.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-sprecher-mpls-tp-oam-analysis-
04.txt

Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader

implementation to automatically retrieve the ASCII version of the

Internet-Draft.

---

From: [email-masked]
Date: Fri, 8 May 2009 14:08:02 +0800

hi,all
  I review this draft. there is a problem and doubt to need to discuss 
them to you. the following:
    about section 1.1 LSP Ping
    "The return message of the LSP Ping could be sent either on the return 
LSP of a corouted bidirectional LSP, or
   for associated bidirectional LSPs or unidirectional LSPs may be sent 
using IP forwarding to the IP address of the LSP ingress node."
  here I don't understand why associated bidirectional LSP can't like 
co-routed bidirectional LSP to send return message of LSP Ping on its 
corelational return LSP ,maybe using IP Forwarding mechanism is not very 
suitable for co-ps network. 
do you think so?
 
 regards
 liu

"Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]> 
发件人:  [email-masked]
2009-05-07 21:46

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

主题
[mpls-tp] FW: I-D Action:draft-sprecher-mpls-tp-oam-analysis-04.txt

Hi,
We have just submitted a new version of the MPLS-TP OAM analysis document. 
The updated version can be found in the following link:
http://www.ietf.org/internet-drafts/draft-sprecher-mpls-tp-oam-analysis-04.txt 

This version has been updated to be aligned with the latest available 
version of the OAM requirements document (we will probably need to update 
it again once the OAM requirement is revised to include the latest 
discussions). 
In this version we addressed comments we received (e.g. on LSP ping, 
etc.). This version includes also an introduction of Y.1731 (in addition 
to the OAM existing tools) and some considerations with regards to the 
requirements. 
We will appreciate if you can review the document and provide your 
comments. 
We believe it is important to discuss this document before we get into the 
solutions. This is the right context to see the entire picture.
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On Behalf Of ext [email-masked]
Sent: Thursday, May 07, 2009 3:15 PM
To: [email-masked]
Subject: I-D Action:draft-sprecher-mpls-tp-oam-analysis-04.txt 

 
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sprecher-mpls-tp-oam-analysis-04.txt

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft._______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Fri, 8 May 2009 10:50:02 +0200

Hi Liu,

Thanks for your review. I really appreciate it.

*         Regarding co-routed LSPs the assumption is that the network elements, the endpoints and the intermediate nodes, are aware of the pairing relationship where the forward and the backward directions belong to the same bidirectional transport path. Therefore, at any point, the return message of the LPS can be sent in the return path of the LSP. 

*         In LSP Ping, in case of fault or misconnection the LSP Ping error echo reply is sent by intermediate node. In associated LSPs, the LSPs in both directions do NOT share the same path! Otherwise it was co-routed LSPs. Therefore an intermediate node that needs to send an error reply because of a fault or misconnection will not have OR will not be aware of a LSP return path………..

*         Note also that today there is no standard way even to indicate the endpoints of the association relationship, this of course may be added, but this may be provided only at the endpoint and not at the intermediate points that respond in case of failures and errors. 

Please note that in the introduction of the document we gave an overview of the existing mechanisms, and in the analysis part we tried to evaluate whether the existing mechanisms can be apply to the requirements specified in the OAM requirement draft. 

I hope that I managed to clarify it. Please let me know if you have further comments. 

I'll appreciate the review of the team and their comments. 

Best regards,

Nurit

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Friday, May 08, 2009 9:08 AM
To: [email-masked]
Subject: Re: [mpls-tp] FW: I-DAction:draft-sprecher-mpls-tp-oam-analysis-04.txt

  hi,all 
  I review this draft. there is a problem and doubt to need to discuss them to you. the following: 
    about section 1.1 LSP Ping 
    "The return message of the LSP Ping could be sent either on the return LSP of a corouted bidirectional LSP, or 
   for associated bidirectional LSPs or unidirectional LSPs may be sent using IP forwarding to the IP address of the LSP ingress node." 
  here I don't understand why associated bidirectional LSP can't like co-routed bidirectional LSP to send return message of LSP Ping on its corelational return LSP ,maybe using IP Forwarding mechanism is not very suitable for co-ps network. 
do you think so? 
  
 regards 
 liu

2009-05-07 21:46 

收件人

<[email-masked]> 

抄送

主题

 

Hi, 
We have just submitted a new version of the MPLS-TP OAM analysis document. The updated version can be found in the following link: 
http://www.ietf.org/internet-drafts/draft-sprecher-mpls-tp-oam-analysis-04.txt <http://www.ietf.org/internet-drafts/draft-sprecher-mpls-tp-oam-analysis-04.txt>  
This version has been updated to be aligned with the latest available version of the OAM requirements document (we will probably need to update it again once the OAM requirement is revised to include the latest discussions). 
In this version we addressed comments we received (e.g. on LSP ping, etc.). This version includes also an introduction of Y.1731 (in addition to the OAM existing tools) and some considerations with regards to the requirements. 
We will appreciate if you can review the document and provide your comments. 
We believe it is important to discuss this document before we get into the solutions. This is the right context to see the entire picture. 
Best regards, 
Nurit 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Thursday, May 07, 2009 3:15 PM
To: [email-masked]
Subject: I-D Action:draft-sprecher-mpls-tp-oam-analysis-04.txt 
  
A New Internet-Draft is available from the on-line Internet-Drafts directories.

---

From: [email-masked]
Date: Sat, 9 May 2009 10:18:49 +0800

Nurit:
  thank you for quickly reply. but I have a little problem about LSP Ping 
functions. IMO, in mpls network, LSP Ping fuction only check and diagnose 
the fault of end to end path. it says that it is not necessary for 
intermediate node or MIP to send echo reply message to source node or MEP.
  according to your answer, for mpls-tp network. may we extend the 
function of MPLS LSP Ping to require intermediate node or MIP to reply to 
LSP Ping request message?

  is my understanding true?

regards
liu 

2009-05-08 16:50

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

主题
RE: [mpls-tp] FW: I-DAction:draft-sprecher-mpls-tp-oam-analysis-04.txt

Hi Liu,
Thanks for your review. I really appreciate it.
・         Regarding co-routed LSPs the assumption is that the network 
elements, the endpoints and the intermediate nodes, are aware of the 
pairing relationship where the forward and the backward directions belong 
to the same bidirectional transport path. Therefore, at any point, the 
return message of the LPS can be sent in the return path of the LSP. 
・         In LSP Ping, in case of fault or misconnection the LSP Ping 
error echo reply is sent by intermediate node. In associated LSPs, the 
LSPs in both directions do NOT share the same path! Otherwise it was 
co-routed LSPs. Therefore an intermediate node that needs to send an error 
reply because of a fault or misconnection will not have OR will not be 
aware of a LSP return path………..
・         Note also that today there is no standard way even to indicate 
the endpoints of the association relationship, this of course may be 
added, but this may be provided only at the endpoint and not at the 
intermediate points that respond in case of failures and errors. 
Please note that in the introduction of the document we gave an overview 
of the existing mechanisms, and in the analysis part we tried to evaluate 
whether the existing mechanisms can be apply to the requirements specified 
in the OAM requirement draft. 
I hope that I managed to clarify it. Please let me know if you have 
further comments. 
I'll appreciate the review of the team and their comments. 
Best regards,
Nurit

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of ext [email-masked]
Sent: Friday, May 08, 2009 9:08 AM
To: [email-masked]
Subject: Re: [mpls-tp] FW: 
I-DAction:draft-sprecher-mpls-tp-oam-analysis-04.txt

  hi,all 
  
 regards 
 liu

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

  
Hi, 

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

  

  

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 09 May 2009 09:42:53 +0100

Hi Liu

RFC 4379 says:

"This document specifies a "ping" mode and a "traceroute"
mode for testing MPLS LSPs."

Although the IETF usually uses the nickname "LSP Ping" it is
really called "Detecting Multi-Protocol Label Switched (MPLS)
Data Plane Failures" and includes both end to end and
midpoint testing.

- Stewart

[email-masked] wrote:
>
> Nurit:
> thank you for quickly reply. but I have a little problem about LSP
> Ping functions. IMO, in mpls network, LSP Ping fuction only check and
> diagnose the fault of end to end path. it says that it is not
> necessary for intermediate node or MIP to send echo reply message to
> source node or MEP.
> function of MPLS LSP Ping to require intermediate node or MIP to reply
> to LSP Ping request message?
>

---

From: [email-masked]
Date: Mon, 11 May 2009 18:05:01 +0800

stewart:
  maybe your understanding is true. but I think that we should choose the 
method of sending reply message to another MEP on a return path of 
associated bidirectional path when LSP Ping is used to detect the fault of 
end to end path. not use IP forwarding mechanism.

for the midpoint test. I completely your advice.

thank you
liu

Stewart Bryant <[email-masked]> 
2009-05-09 16:42
请答复 给
[email-masked]

收件人
[email-masked]
抄送
"Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>, 
[email-masked]
主题
Re: [mpls-tp] FW: I-DAction:draft-sprecher-mpls-tp-oam-analysis-04.txt

Hi Liu

RFC 4379 says:

- Stewart

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 12 May 2009 08:11:37 +0200

Liu, hi

First off, I think that you may be right – if we want to use LSP Ping for MPLS-TP that a draft should be written that describes how this can be applied and amongst other things should define how this would work for an associated bidirectional or unidirectional path.

However, I would remind you that the OAM Analysis draft intention is not to offer solutions but rather to raise awareness of what is available and possibly point to issues that would need to be addressed in order to make different tools compliant to the MPLS-TP requirements.  As the document states – it is an analysis of the available tools based on the OAM requirements and not a solution document.

Hope this helps,

yaacov

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Monday, May 11, 2009 13:05
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] FW:I-DAction:draft-sprecher-mpls-tp-oam-analysis-04.txt

stewart: 
  maybe your understanding is true. but I think that we should choose the method of sending reply message to another MEP on a return path of associated bidirectional path when LSP Ping is used to detect the fault of end to end path. not use IP forwarding mechanism. 

thank you 
liu 

2009-05-09 16:42 

请答复 给
[email-masked]

收件人

[email-masked] 

抄送

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

主题

 

Hi Liu

RFC 4379 says:

- Stewart

---

From: Mach Chen <[email-masked]>
Date: Thu, 14 May 2009 11:42:56 +0800

Hi,

I have to agree Yaacov here, the sprecher draft is just a analysis draft.

The text Liu picked from sprecher's draft just decribes the fact of the 
existing LSP Ping mechanisms. That is the return path of the echo reply 
message is determined randomly and freely by the egress and is highly 
relevant to different implements. There is no such a mechanism that could be 
used to notify the egress which path to send along.

But, anyway, I think Liu has pointed out a valuable question, we have 
thought of this issue for several months and talked to several SPs. The 
issue is
not only relevant to MPLS-TP, but to MPLS. We are now working on such a 
draft (it is almost finished and will be submitted soon) to enhance the MPLS 
LSP Ping mechanism to enable that the return path of the echo reply message 
could be specified as needed. IMO, our solution could reslove/satisfy the 
issue/requirement in question :-)

Best regards,
Mach Chen

--------------------------------------------------
From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)"
<[email-masked]>
Sent: Tuesday, May 12, 2009 2:11 PM
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Subject: Re: 
[mpls-tp]FW:I-DAction:draft-sprecher-mpls-tp-oam-analysis-04.txt> Liu, hi
>
>
>
> First off, I think that you may be right – if we want to use LSP Ping for
> MPLS-TP that a draft should be written that describes how this can be
> applied and amongst other things should define how this would work for an
> associated bidirectional or unidirectional path.
>
> However, I would remind you that the OAM Analysis draft intention is not
> to offer solutions but rather to raise awareness of what is available and
> possibly point to issues that would need to be addressed in order to make
> different tools compliant to the MPLS-TP requirements.  As the document
> states – it is an analysis of the available tools based on the OAM
> requirements and not a solution document.
>
>
>
> Hope this helps,
>
> yaacov
>
>
>
> Subject: Re: [mpls-tp]
> FW:I-DAction:draft-sprecher-mpls-tp-oam-analysis-04.txt
>
>
>
>
> stewart:
> Re: [mpls-tp] FW:

> _______________________________________________
> mpls-tp mailing list
> [email-masked]

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 25 May 2009 12:10:08 +0200

Hi all,
In the latest version, we included a section on Y.1713 for the considerations, in addition to the MPLS existing tools (LSP ping, MPLS BFD, VCCV, etc.).
This has caused a lot of debate, and we would like to get feedback if we have correctly captured the function.
Your feedback will be much appreciated.
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Mach Chen
Sent: Thursday, May 14, 2009 6:43 AM
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); [email-masked]; [email-masked]
Cc: So Ning; [email-masked]
Subject: [mpls-tp] MPLS LSP Ping Enhancement//Re:FW:I-DAction:draft-sprecher-mpls-tp-oam-analysis-04.txt

Hi,

Best regards,
Mach Chen

---

From: Yuji Tochio <[email-masked]>
Date: Mon, 25 May 2009 19:23:44 +0900

Hi Nurit

Just a minor correlation...

> we included a section on Y.1713 for the considerations,

I guess it is not Y.1713, but Y.1731 :-)
# Y.1713 also exists as another recommendation of MPLS.

Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
> ------------------------------------------------------------------------
>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 25 May 2009 13:22:32 +0200

Right. Thanks for the correction.
It is Ethernet OAM, Y.1731.

-----Original Message-----
From: ext Yuji Tochio [mailto:[email-masked]] 
Sent: Monday, May 25, 2009 1:24 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: Re: [mpls-tp] MPLS LSP Ping Enhancement//Re:FW:I-DAction:draft-sprecher-mpls-tp-oam-analysis-04.txt

Hi Nurit

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Tue, 26 May 2009 13:14:09 +0200

Hi Nurit,

I've read the draft. I think it is a very usefull analysis document and I agree it should be discussed before we get into the solutions.

Just one very minor comment.
In the document you refer to [MPLS BFD] that in section 8 is "draft-katz-ward-bfd-multipoin-01.txt". That is right is some context but in the Introduction it should  point to draft-ietf-bfd-base-09.txt ; in section 1.2. it should  point to draft-ietf-bfd-base-09.txt in second paragraph,  while it should point to draft-ietf-bfd-mpls-07 in third paragraph.

Regards, 
Annamaria

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: giovedì 7 maggio 2009 15.47
To: [email-masked]
Subject: [mpls-tp] FW: I-D Action:draft-sprecher-mpls-tp-oam-analysis-04.txt

Hi,

Best regards,

Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Thursday, May 07, 2009 3:15 PM
To: [email-masked]
Subject: I-D Action:draft-sprecher-mpls-tp-oam-analysis-04.txt 

      Pages           : 22

      Date            : 2009-05-07

MPLS-TP.

Internet-Draft.