Re: [mpls] a question about draft-cheung-mpls-tp-mesh-protection-01
liu.guoman@zte.com.cn Fri, 30 July 2010 09:28 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 0D7263A6891; Fri, 30 Jul 2010 02:28:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.635
X-Spam-Level:
X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 HM0N-kIOE2M2; Fri, 30 Jul 2010 02:28:02 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id D689A3A6874; Fri, 30 Jul 2010 02:27:56 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 35102548420933; Fri, 30 Jul 2010 17:27:33 +0800 (CST)
Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 79973.4478639226; Fri, 30 Jul 2010 17:28:06 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6U9KeSv069445; Fri, 30 Jul 2010 17:21:24 +0800 (CST) (envelope-from liu.guoman@zte.com.cn)
In-Reply-To: <CEC8C88293A04D06A95E6FA87537804F@etri.info>
To: Taesik Cheung <cts@etri.re.kr>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OF918CBF71.8789D3B2-ON48257770.00306227-48257770.00338D2B@zte.com.cn>
From: liu.guoman@zte.com.cn
Date: Fri, 30 Jul 2010 17:21:08 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-30 17:21:10, Serialize complete at 2010-07-30 17:21:10
Content-Type: multipart/alternative; boundary="=_alternative 00338D2848257770_="
X-MAIL: mse2.zte.com.cn o6U9KeSv069445
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: Fri, 30 Jul 2010 09:28:07 -0000
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.
- 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