Re: [mpls] a question about draft-cheung-mpls-tp-mesh-protection-01
liu.guoman@zte.com.cn Mon, 02 August 2010 02:14 UTC
Return-Path: <liu.guoman@zte.com.cn>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3C593A67BD; Sun, 1 Aug 2010 19:14:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.335
X-Spam-Level:
X-Spam-Status: No, score=-96.335 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id milUbnjrzVpM; Sun, 1 Aug 2010 19:14:51 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 7A0C63A67B8; Sun, 1 Aug 2010 19:14:48 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 35102548420933; Mon, 2 Aug 2010 10:13:50 +0800 (CST)
Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 68453.4478639226; Mon, 2 Aug 2010 09:38:27 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o721huVq052991; Mon, 2 Aug 2010 09:43:59 +0800 (CST) (envelope-from liu.guoman@zte.com.cn)
In-Reply-To: <742CD2DC7F484A38A3B68F9A859DF5BA@etri.info>
To: "Ryoo, Jeong-dong" <ryoo@etri.re.kr>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OF5AA90E65.2D050F41-ON48257773.00076C7A-48257773.0009B0C1@zte.com.cn>
From: liu.guoman@zte.com.cn
Date: Mon, 02 Aug 2010 09:43:55 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-08-02 09:43:56, Serialize complete at 2010-08-02 09:43:56
Content-Type: multipart/alternative; boundary="=_alternative 0009B0BC48257773_="
X-MAIL: mse2.zte.com.cn o721huVq052991
Cc: mpls@ietf.org, mpls-bounces@ietf.org, mpls-tp@ietf.org
Subject: Re: [mpls] a question about draft-cheung-mpls-tp-mesh-protection-01
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Aug 2010 02:14:54 -0000
Jeong-dong, I don't completely understand your describles. in former part, you think the protection locking message is not a reply message ,but is a originator of request message. while in your last sentence. the Message is not originated by a SEN. so I can't see this locking message is originator of Locking request message or only a reply to protection switching Request message arrived at the SEN? if it is the former, SEN as MIP of a path, it can't actively initiate a request messgae. else if it is only the reply to protection switching request message. IMO, for the following example: A------B------C D------E------F \ LPD1 / \ LPD3 / \ / \ / P-----Q----------R-----S / \ / LPD2 \ / \ G--------------H---------------J when a path G-H-J have failure, end node G firstly initiate a protection switching event message to SEN node P, R. if SEN node P,R would relpy to the protection switching event, the Reply message(locking message) should be sent to the end nodes G or J of LPD2, can't be sent to the end nodes D,F of LPD3; my understanding to your opinions may be wrong? best regards liu "Ryoo, Jeong-dong" <ryoo@etri.re.kr> 2010-07-30 18:22 请答复 给 "Ryoo, Jeong-dong" <ryoo@etri.re.kr> 收件人 <liu.guoman@zte.com.cn>, "Taesik Cheung" <cts@etri.re.kr> 抄送 <mpls@ietf.org>, <mpls-bounces@ietf.org>, <mpls-tp@ietf.org> 主题 RE: Re: [mpls] a question about draft-cheung-mpls-tp-mesh-protection-01 Liu, What you described in your email is aligned with the operations stated in the MPLS-TP mesh protection draft. The protection locking message is not exactly a reply message, which goes to the originator of the request message. It is certainly destined to other nodes, which share the common facility, This is an additional function of SEN to provide the shared mesh protection. What I would like to emphasize is that this message is not originated by a SEN (a MIP of the path for linear protection) if there is no protection switching event message arrived at the SEN, Best regards, Jeong-dong ============================================== Jeong-dong Ryoo, Ph.D. Principal Member of Research Staff Network Research Department Electronics and Telecommunications Research Institute (ETRI) Phone: +82-42-860-5384, Fax: +82-42-860-6342 Email: ryoo@etri.re.kr ============================================== -----Original Message----- From: "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> From Date: 2010-07-30 PM 6:21:08 To: "Taesik Cheung" <cts@etri.re.kr> Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf.org" <mpls-bounces@ietf.org>, "mpls-tp@ietf.org" <mpls-tp@ietf.org>, "ryoo@etri.re.kr" <ryoo@etri.re.kr> Subject: Re: [mpls] a question about draft-cheung-mpls-tp-mesh-protection-01 Taesik thank you for replying .but I don't agree your opinions According to your describles in the draft. I think the protection locking message isn't a response to the protection state change notification message sent from a MEP. and it is activley generate a Locking Request message for the SEN node. for example. the following figure : A------B------C D------E------F \ LPD1 / \ LPD3 / \ / \ / P-----Q----------R-----S / \ / LPD2 \ / \ G--------------H---------------J a. Node G detects the failure, and initiates the linear protection switching for the failed working path G-H-J; b. At the same time, node G generates the protection switching event message saying that a protection switching event happened to node P and R, which are SENs for J->H->G. c. The SEN P compares the protection switching priority of LPD2 with that of LPD1. In this example, as the priority of LPD1 is higher than LPD2, SEN P does not take an action to node A. The SEN R compares the protection switching priority of LPD2 with that of LPD3. In this example, as the priority of LPD3 is lower than LPD2, SEN R sends the protection locking message requesting LoP to node D.(if the Locking message is a response to the protection state change , I think the Locking message should send to Node G , not node D. because at the time there is no protection state change for LPD2 . Node D can't send any state change request to SEN node R firstly. do you think so? ) d. Node D takes the protection locking message as an input to the linear protection switching, and follows the linear protection switching procedure to process the end-to-end LoP command maybe my understanding be wrong? best regards liu "Taesik Cheung" <cts@etri.re.kr> ?件人: mpls-bounces@ietf.org 2010-07-30 16:45 ?答? ? Taesik Cheung <cts@etri.re.kr> 收件人 <liu.guoman@zte.com.cn>, <ryoo@etri.re.kr> 抄送 mpls@ietf.org, mpls-tp@ietf.org 主? Re: [mpls] a question about draft-cheung-mpls-tp-mesh-protection-01 Hi Liu, Thank you for the comments. Please see in-line. Regards, Taesik -----Original Message----- From: "liu.guoman@zte.com.cn" <liu.guoman@zte.com.cn> From Date: 2010-07-30 PM 5:06:30 To: "ryoo@etri.re.kr" <ryoo@etri.re.kr>, "cts@etri.re.kr" <cts@etri.re.kr> Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-tp@ietf.org" <mpls-tp@ietf.org> Subject: a question about draft-cheung-mpls-tp-mesh-protection-01 hi, today I reviewed your this draft, I have a few questions for mesh protection 1 in section 3, In my mind, there is a sentence : In both cases, 1:1 or 1+1 protection may be used. if there use 1+1 protection for each working path. it is no necessary to apply mesh protection. beacause the bandwidth resource of protection is equal to the sum of bandwidth resource of all protected path. so I think 1+1 protection should not be used in the mesh protection. do you think so? [Taesik] Yes, if 1+1 protection is used, shared mesh protection is not necessary. The sentence is just generic one. Right after the sentence, we described that if 1:1 protection is used, the segment PQR can be shared by two protection paths. 2 about the Shared node SEN will send the protection locking message requesting LoP to the end node of protected LSP. IMO, as SEN node is MIP of the protected LSP , it can't generate unsolicit OAM packet to send other node. so how to generate the protection locking message requesting LOP in the SEN node ? [Taesik] The protection locking message is a response to the protection state change notification message sent from a MEP. It is similar to LTM/LTR or Lock Intruct / Lock Report relationship. Maybe i miss something important? thank you best regards liu -------------------------------------------------------- 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. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls -------------------------------------------------------- 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. -------------------------------------------------------- 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.
- Re: [mpls] a question about draft-cheung-mpls-tp-… Ryoo, Jeong-dong
- [mpls] a question about draft-cheung-mpls-tp-mesh… liu.guoman
- Re: [mpls] a question about draft-cheung-mpls-tp-… Taesik Cheung
- Re: [mpls] a question about draft-cheung-mpls-tp-… liu.guoman
- Re: [mpls] a question about draft-cheung-mpls-tp-… liu.guoman
- Re: [mpls] a question about draft-cheung-mpls-tp-… Ryoo, Jeong-dong
- Re: [mpls] a question about draft-cheung-mpls-tp-… Ryoo, Jeong-dong
- Re: [mpls] a question about draft-cheung-mpls-tp-… Ryoo, Jeong-dong
- Re: [mpls] a question about draft-cheung-mpls-tp-… liu.guoman
- Re: [mpls] a question about draft-cheung-mpls-tp-… liu.guoman