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

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 17 Mar 2009 13:13:02 -0000

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

---

From: Jiang Yuan-long <[email-masked]>
Date: Thu, 19 Mar 2009 14:26:50 +0800

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

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

---

From: [email-masked]
Date: Thu, 19 Mar 2009 17:13:44 +0800

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,

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

>> regards simply as two 1+1 or 1:1 individual undirectional protection. 
so 
>> i

> to consider a per-leaf 1:1 scheme.

--------------------------------------------------------
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: Jiang Yuan-long <[email-masked]>
Date: Thu, 19 Mar 2009 20:32:44 +0800

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,

---

From: [email-masked]
Date: Fri, 20 Mar 2009 09:19:06 +0800

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

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 

jiang and Adrian: 

收件人

Hi, Adrian,

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

so 

--------------------------------------------------------
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: Jiang Yuan-long <[email-masked]>
Date: Fri, 20 Mar 2009 11:01:04 +0800

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, 

  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: 

              

  Hi, Adrian,

---

From: [email-masked]
Date: Fri, 20 Mar 2009 11:19:35 +0800

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 

2009-03-20 11:01

收件人
[email-masked]
抄送

Liu，

 
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 

hi,jiang: 

收件人
[email-masked] 
抄送

Hi, Liu, 

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 

jiang and Adrian: 

收件人

Hi, Adrian,

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

so