Subject: Re: [mpls-tp] a few comments aboutdraft-sprecher-mpls-tp-survive-fwk-01

From: [email-masked]
Date: Sat, 21 Mar 2009 14:24:14 +0800

Jiang:
 your understand may be true. if both directions of associated 
bidirectional path are setup,monitored and protected independently. what 
meaning will both individual path be put together as associated 
bidirectional path? we may select any two of forward and backward 
directions path to make up associated bidirectional path. why not claim 
mpls-tp must support assicated bidirectional path?

thank you for your interpret for a long time.
regards
liu

Jiang Yuan-long <[email-masked]> 
2009-03-20 19:52

收件人
[email-masked]
抄送
Adrian Farrel <[email-masked]>, [email-masked]
主题
Re: [mpls-tp] a few comments aboutdraft-sprecher-mpls-tp-survive-fwk-01

Liu:
Please refer to the definition in draft-ietf-mpls-tp-requirements-05:
   "Associated bidirectional path: A path that supports traffic flow in
   both directions but which is constructed from a pair of
   unidirectional paths (one for each direction) which are associated
   with one another at the path's ingress/egress points. The forward
   and backward directions are setup, monitored and protected
   independently.  As a consequence they may or may not follow the same
   route (links and nodes) across the network."
So your understanding is totally against this rule.
How to implement the associated bidirectional LSP is another topic, it may
be configured statically in the management plane, or set up dynamically by 

a control plane. But the bindings between LSP1 and RLSP1 should not be so 
tightly fixed as you think.As LSP1, LSP2, RLSP1 and RLSP2 are all known in 

your case, for sure reconfiguration is not a prerequisite to switch 
any of them.
 
Regards
Yuanlong
 
----- Original Message ----- 
From: [email-masked] 
To: Jiang Yuan-long 
Cc: Adrian Farrel ; [email-masked] 
Sent: Friday, March 20, 2009 11:19 AM
Subject: Re: [mpls-tp] a few comments 
aboutdraft-sprecher-mpls-tp-survive-fwk-01

jiang: 
  your understand may be wrong. this relation of associated bidirectional 
LSP is pre-configured , it can't change the relation during the period of 
have fault in LSP . IMO. when LSP1 have a fault or error. LSP2 can't know 
RLSP1 ,only know RLSP2. so LSP2 and RLSP1 can't become a new associated 
bidirectional LSP until we re-configure the relation between LSP2 and 
RLSP1. it isn't possibility. 
you consider that is my understanding true? 
thank you 

Jiang Yuan-long <[email-masked]> 
2009-03-20 11:01 

收件人
[email-masked] 
抄送
Adrian Farrel <[email-masked]>, [email-masked] 
主题
Re: [mpls-tp] a few comments aboutdraft-sprecher-mpls-tp-survive-fwk-01

Liu， 
As 1+1 protection is not covered in your example, I see no difference 
in them as service are sent on both working and protection path, only 
the sink needs to receive from a good path. 
  
In the 1:1 protection scenario presented by you, the services of RLSP1 
should not be switched into RLSP2 as long as RLSP1 is good.  LSP2 and 
RLSP1 become a new associated bidirectional LSP. In my opinion, 
for the associated bidirectional P2P LSP, only the failed LSP should be 
switched, thus services in the other direction are least influenced. 
  
Just as the protection switching mechanism in ITU-T Recs shows, 
bidirectional switching is used to guarantee that the new path is also 
a co-routed bidirectional path.  Otherwise, complexity is introduced 
with no benefit. 
  
Regards 
Yuanlong 
 
----- Original Message ----- 
From: [email-masked] 
To: Jiang Yuan-long 
Cc: Adrian Farrel ; [email-masked] 
Sent: Friday, March 20, 2009 9:19 AM 
Subject: Re: [mpls-tp] a few comments 
aboutdraft-sprecher-mpls-tp-survive-fwk-01 

hi,jiang: 
you may not completely understand my meaning. IMO, 1+1 and 1:1 protection 
switching for associated bidirectional path will be different from two 
individual unidirectional path protection switching.the following figure : 

in the figure, there are two pair of associated path, a pair of them is 
work associated path pair, another is protection associated path pair. if 
ther is a fault in LSP1 in work associated path pair. all service of LSP1 
will switch into LSP2 in protection associated path pair. now the key 
problem is whether all services of RLSP1 on which have not fault, need to 
switch into RLSP2 in protection associated path pair? if we only regard 
the two pair path as two individual unidirectional path pair. maybe the 
services of RLSP1 will not swtich into RLSP2. 
do you understand my meaning? 
thank you. 
liu 

Jiang Yuan-long <[email-masked]> 
2009-03-19 20:32 

收件人
[email-masked] 
抄送
Adrian Farrel <[email-masked]>, [email-masked] 
主题
Re: [mpls-tp] a few comments aboutdraft-sprecher-mpls-tp-survive-fwk-01

Hi, Liu, 
Maybe you misunderstood my opinion. I am not against the requirement of 
associated 
bidirectional P2P paths at all. But just as Adrain pointed out, the 
protection of 
this kind of path is not very different from the unidirectional P2P path, 
as each 
of its unidirectional path can be switched independantly. That is also why 
APS 
protocol is not needed for unidirectional switching in ITU-T Rec. G.8031 
and G.8131. 
 
Some discussions on the different recovery requirements for all these kind 
of paths 
may be rightfully needed. IMO, it is required that the new path for a 
co-routed 
bidirectional P2P path should also be co-routed and bidirectional, while 
for an 
associated bidirectional path, either of its unidirectional path can be 
switched. 
 
Regards, 
Yuanlong 
----- Original Message ----- 
From: [email-masked] 
To: Jiang Yuan-long ; Adrian Farrel 
Cc: [email-masked] 
Sent: Thursday, March 19, 2009 5:13 PM 
Subject: Re: [mpls-tp] a few comments 
aboutdraft-sprecher-mpls-tp-survive-fwk-01 

jiang and Adrian: 
I don't agree with you, it had described that mpls-tp must support 
associated bidirectional point-to-point transport paths in mpls-tp 
requirement draft. why not consider protection under the condition? why 
not delete the phase in this mpls-tp requirment draft? 
thank you 

Jiang Yuan-long <[email-masked]> 
2009-03-19 14:26 

收件人
Adrian Farrel <[email-masked]> 
抄送
[email-masked], [email-masked], [email-masked] 
主题
Re: [mpls-tp] a few comments aboutdraft-sprecher-mpls-tp-survive-fwk-01

Hi, Adrian,
I agree with you that associated bidirectional P2P path is not special,
and there is no any need for the end points to coordinate their switching.
But for a co-routed bidirectional P2P path, as I understand from your
document, the recovery mechanism MUST guarantee that the new path
is also co-routed and bidirectional. Is that understanding correct?

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 17, 2009 9:13 PM
Subject: Re: [mpls-tp] a few comments 
aboutdraft-sprecher-mpls-tp-survive-fwk-01

> Hi Liu,
>
>> I review the draft of version 01. I have a comments about the draft. 
the
>> following :
>>  1 I see require 31 in the new MPLS-TP requirement draft, it say" 31
>> MPLS-TP MUST support unidirectional, co-routed bidirectional and
>> associated bidirectional point-to-point transport paths" . if MPLS-TP 
>> MUST
>> support associated bidirectional p2p transport path, it is required to
>> consider 1+1 or 1:1 protection for the associated bidirectional p2p
>> transport path. while the 1+1 or 1:1 protection will be different from 
>> 1+1
>> or 1:1 protection of co-routed bidirectional transport path. also it 
may
>> be  wrong that 1+1 or 1:1 protection of associated bidirectionanl p2p 
>> path
>> regards simply as two 1+1 or 1:1 individual undirectional protection. 
so 
>> i
>> think it is necessary to add the protection for associated 
bidirectional
>> p2p transport path in this draft
>
> Yes, I think this will be worth discussion in the document.
>
> I do not think we need any special procedures as each direction of an 
> associated bidirecitonal LSP can be treated independently. That is, 
there 
> is no requirement that the two directions of an associated bidirecitonal 

> LSP must take disjoint paths. Rather, it is the case that they may take 
> disjoint paths.
>
>> 2 for  P2MP linear protection, the 1:1 protection scheme is not
>> practical. when  a fault condition on any of the branches of the 
network
>> is existed. the whole P2MP working path will switch the protection 
path.
>> it may affect the efficiency of network resource. here we should 
consider
>> segment protecion for P2MP linear protection. when there is fault on 
any
>> branches of the network. it only need to restore the service of the 
fault
>> branches. maybe it is more good . so I  think it is necessary to add 
the
>> segment protection for P2MP transports path in the draft
>
> A variety of P2MP protection schemes exist. We should certainly describe 

> segment protection since it is well-known and already implemented. We 
> should also add some description of different 1:1 schemes - it is 
possible 
> to consider a per-leaf 1:1 scheme.
>
> Thanks,
> Adrian
>
> _______________________________________________
> 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.

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

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