Subject: Re: [mpls-tp] [mpls] I-DAction:draft-ietf-mpls-tp-linear-protection-03.txt

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 26 Oct 2010 09:58:26 +0200

Liu, hi

Not sure that I understand your reply – 

In the case of a p2p co-routed bidirectional LSP (the "normal" MPLS-TP situation), there is a need for both end-points of the protection domain to be coordinated regarding the current status of the domain.  Therefore, if there is an uni-directional fault on the protection path that is detected by one end-point (e.g. LER-A) then the far-end (e.g. LER-Z)  needs to be informed of the current state.  

If the notification is not sent – what would prevent LER-Z from accepting a MS command?  It is unaware that the protection path is unavailable – it is not reporting a fault.

Regarding your second point – I was not referring to the protection of a unidirectional LSP, whose protection (based on 1:n architecture) would require a return path – which is why it is preferable to base the protection of these paths on 1+1 protection.

Hope this helps,

yaacov

________________________________

From: ext [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, October 26, 2010 09:31
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: Greg Mirsky; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [mpls] I-DAction:draft-ietf-mpls-tp-linear-protection-03.txt

hi, yaacov 
IMO, for a case of unidirectional signal Fail situation, even the peer node which detected the SF inform the other end-point of the Unavailable state. another node will not change switch state and continue to transport service on the protection path under the failure condition on the working path. so it is unnecessary to transmit SF message to the far-end point. 

in addition, for unidirectional p2p or p2mp path. if it need to transmit SF message to the peer node, it must have a return path for p2p or more one return path for p2mp. 
do it mean that it must have the requirement of haveing a return path for unidirectional p2p or p2mp path for mpls-tp? thank you   

do i miss something important? 

B.R. 
Liu

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

2010-10-26 14:50 

收件人

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

抄送

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

主题

RE: [mpls-tp] [mpls] I-DAction:draft-ietf-mpls-tp-linear-protection-03.txt

Liu & Greg hi 
  
I agree with Greg's analysis.  But have one note on Liu's observation – consider a case of a unidirectional Signal Fail situation, where the end-point that detects the SF needs to inform the other end-point of the Unavailable state, and the protection path is transmitting in that direction. 
  
BR, 
yaacov 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Tuesday, October 26, 2010 07:51
To: Greg Mirsky
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [mpls] I-DAction:draft-ietf-mpls-tp-linear-protection-03.txt 

Greg 
I agree with you. if the failure detected on the protection path. PSC is not applicable. so some context of this draft should be changed. 
for example, in section 4.3.3.1 ,there is a paragraph of describles" 
      A local Signal Fail indication on the protection path SHALL cause 
     the LER to go into Unavailable state and begin transmission of a 
     SF(0,0) message to the far-end LER (LER-Z)." 
it is impossible to transmit SF(0,0) message to the far-end LER. 
so it is necessary to update it in the next version. 

2 for m:n(1:n) linear protection, maybe it not include them in this draft? 
 or is it  possible to add 1:n(M:N) linear protection for p2p and p2mp 
 in the next version? 
 i wish the editors of this draft can explain the problem. thank you 

B.R. 
liu 

Greg Mirsky <[email-masked]> 

2010-10-25 23:51 

收件人

[email-masked] 

抄送

[email-masked], [email-masked] 

主题

Re: [mpls] I-D Action:draft-ietf-mpls-tp-linear-protection-03.txt

Dear Liu,
my understanding is that if the failure detected on the protection path when 1:1 protection is used, then the working path is no longer protected and PSC is not applicable until its protected state restored. On the related note, I think it would be interesting to explore m:n linear protection (1:n case is mentioned in the document already). If m:n linear protection is in the scope of the document I'm interested in opinions on: 

*	how end-points select which protection path to use for transmission of the control packets 
*	should control packets that belong to the same working path use the same protection path or can traverse different path in each direction

Regards,
Greg

---

From: [email-masked]
Date: Tue, 26 Oct 2010 17:01:12 +0800

hi, yaacov
I can't completely agree your explaining. for co-routed bidirectional LSP, 
it's relative protection path should be co-routed bidirectional LSP.
it can't exist a fault on a directional path of protection path. if it 
have fault on the protection path, it must have fault on the 
two-directional path.
the node which detected the fault will not inform the far-end of the 
current state by back

considering the protection of uni-directional p2p or p2mp, I think that it 
is necessary to apply 1:n(m:n) protection . and 1+1 protection will add 
the cost of 
network resource, it may not be a effective solution for uni-directional 
p2p or p2mp path. for the detail cause , you can see the following draft:
http://datatracker.ietf.org/doc/draft-liu-mpls-tp-p2mp-shared-protection/

here this draft provide linear protection of unidirectional p2mp. I wish 
this draft can explain the cause clearly to you.

B.R.
liu

"Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]> 
发件人:  [email-masked]
2010-10-26 15:58

收件人
<[email-masked]>
抄送
[email-masked], [email-masked]
主题
Re: [mpls] [mpls-tp] I-DAction:draft-ietf-mpls-tp-linear-protection-03.txt

Liu, hi
 
Not sure that I understand your reply – 
In the case of a p2p co-routed bidirectional LSP (the "normal" MPLS-TP 
situation), there is a need for both end-points of the protection domain 
to be coordinated regarding the current status of the domain.  Therefore, 
if there is an uni-directional fault on the protection path that is 
detected by one end-point (e.g. LER-A) then the far-end (e.g. LER-Z) needs 
to be informed of the current state. 
 
If the notification is not sent – what would prevent LER-Z from accepting 
a MS command?  It is unaware that the protection path is unavailable – it 
is not reporting a fault.
 
Regarding your second point – I was not referring to the protection of a 
unidirectional LSP, whose protection (based on 1:n architecture) would 
require a return path – which is why it is preferable to base the 
protection of these paths on 1+1 protection.
 
Hope this helps,
yaacov

From: ext [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, October 26, 2010 09:31
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: Greg Mirsky; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [mpls] 
I-DAction:draft-ietf-mpls-tp-linear-protection-03.txt

hi, yaacov 
IMO, for a case of unidirectional signal Fail situation, even the peer 
node which detected the SF inform the other end-point of the Unavailable 
state. another node will not change switch state and continue to transport 
service on the protection path under the failure condition on the working 
path. so it is unnecessary to transmit SF message to the far-end point. 

in addition, for unidirectional p2p or p2mp path. if it need to transmit 
SF message to the peer node, it must have a return path for p2p or more 
one return path for p2mp. 
do it mean that it must have the requirement of haveing a return path for 
unidirectional p2p or p2mp path for mpls-tp? thank you   

B.R. 
Liu

收件人

Liu & Greg hi 
  
I agree with Greg's analysis.  But have one note on Liu's observation – 
consider a case of a unidirectional Signal Fail situation, where the 
end-point that detects the SF needs to inform the other end-point of the 
Unavailable state, and the protection path is transmitting in that 
direction. 
  
BR, 
yaacov 

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of ext [email-masked]
Sent: Tuesday, October 26, 2010 07:51
To: Greg Mirsky
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [mpls] 
I-DAction:draft-ietf-mpls-tp-linear-protection-03.txt 

Greg 
I agree with you. if the failure detected on the protection path. PSC is 
not applicable. so some context of this draft should be changed. 
for example, in section 4.3.3.1 ,there is a paragraph of describles" 
      A local Signal Fail indication on the protection path SHALL cause 
     the LER to go into Unavailable state and begin transmission of a 
     SF(0,0) message to the far-end LER (LER-Z)." 
it is impossible to transmit SF(0,0) message to the far-end LER. 
so it is necessary to update it in the next version. 

B.R. 
liu 

收件人
[email-masked] 
抄送

Dear Liu,
my understanding is that if the failure detected on the protection path 
when 1:1 protection is used, then the working path is no longer protected 
and PSC is not applicable until its protected state restored. On the 
related note, I think it would be interesting to explore m:n linear 
protection (1:n case is mentioned in the document already). If m:n linear 
protection is in the scope of the document I'm interested in opinions on: 
how end-points select which protection path to use for transmission of the 
control packets 
should control packets that belong to the same working path use the same 
protection path or can traverse different path in each direction
Regards,
Greg_______________________________________________
mpls mailing list
[email-masked]
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.