Subject: [mpls] Comments/Questions about "p2mp shared protection" draft

From: Yaacov Weingarten <[email-masked]>
Date: Thu, 15 Mar 2012 15:34:50 +0200

Hi, authors

I have read your draft and find that I have quite a few questions and
comments about the proposals in the draft and the presentation:

1.  You present two different scenarios for protection of p2mp MPLS-TP
traffic, but you do not really define what the architecture of your
protection domain is.
Taking the first solution, where you propose using a 1:n protection scheme
- normally, and as presented in the Survivability Framework a 1:n
protection domain consists of several working paths and a single protection
path that all have the same set of root and leaves.  Yet in your figure 3
you show a 1:2 domain that the working paths have different roots and
different sets of leafs!  It would be helpful, IMO, if you could define
what protection domain you are referencing.

2. In the scenario that you present in figure 3, your protection path
starts at a different root than either working path (for which I commented
above) but what worries me more is that its destination leafs seem to be
the union of the leafs of all of the working paths.  Doesn't this raise
some security and congestion problems?  For example, let's take the simple
case of a single failure on one of the working paths - by switching over to
the protection path the traffic from this service will be delivered to some
destinations that it was not intended to receive the packets?  In addition,
the sections to this destination are suddenly carrying packets that are
unnecessary and just causing additional traffic on the links!

3. Both of your solutions are greatly dependent upon the RDI functionality,
and you state that the root will be able to identify the relevant working
transport path based on this information.  However, the RDI for MPLS-TP is
defined as part of the Extension to BFD and only within the CC messages (it
is ignored in the CV message) that do not include a LSP/PW identifier TLV.
 And considering that p2mp paths in MPLS-TP are unidirectional, I think
that you need to clearly explain how the root receives the RDI and how it
correlates this RDI to a particular LSP.

4. In your solution that is based on (1:1)^n protection - you state that
the root must "compare the priority among these protection paths..." - but
I thought that in this protection scheme the protection switch is performed
within a single 1:1 domain, so there is nothing for the root to compare to!
 What I believe that you meant is that each shared segment may need (in the
case of multiple faults) to compare the priorities of the different
requests for the shared resources!

5.  Can you explain the relationship between your proposals and the drafts
that are available for 1:n protection and shared mesh protection (in
particular draft-cheung that is also based on (1:1)^n protection)?  Can you
use the same extensions that are proposed in those drafts?

Thank you,
Yaacov Weingarten

---

From: [email-masked]
Date: Fri, 16 Mar 2012 17:33:19 +0800

Yaacov，hi
thank you for providing a lot of comments and questions for this draft. 
question 1, for the architecture of protection domain. IMO, it is very 
rare senario to use one protection path to protect several working paths 
which all have the same set of root and leaves. if we consider the 
scenario in this draft, maybe it use one protection path to protect 
several working paths which needn't have the same set of root and leaves. 
i think more senarios in real network belong to the situation. so it maybe 
over the scope of the survivability framework.

 question 2, i think your understanding is right, some leaves which not 
intended to receive the packet will receive the packet. may we further 
consider the problem in the future.

 question 3, i think if there is no LSP/PW identifer TLV in RDI packet, it 
is necessary for the root node to bind RDI packet to a special LSP , for 
exmaple, it maybe correlate RDI
 to a special return path. so that the root node can know which working 
path has the failure based on the return path;

 question 4,5,this is end to end protection solution. if the failure 
happened on one of the n working path, they must notify the failure 
message to the root of protection path. so the root
will select one failure working path which is the highest priority to be 
proteced. it don't require the node of shared protection segment to 
compare the priority to select one working path to be protected. so it is 
different from the shared mesh protection.

what i said may not be right? thank you

best regards
liu

Yaacov Weingarten <[email-masked]> 
发件人:  [email-masked]
2012-03-15 21:34

收件人
[email-masked], 
[email-masked]
抄送

主题
[mpls] Comments/Questions about "p2mp shared protection" draft

Hi, authors 

1.  You present two different scenarios for protection of p2mp MPLS-TP 
traffic, but you do not really define what the architecture of your 
protection domain is.
Taking the first solution, where you propose using a 1:n protection scheme 
- normally, and as presented in the Survivability Framework a 1:n 
protection domain consists of several working paths and a single 
protection path that all have the same set of root and leaves.  Yet in 
your figure 3 you show a 1:2 domain that the working paths have different 
roots and different sets of leafs!  It would be helpful, IMO, if you could 
define what protection domain you are referencing.

2. In the scenario that you present in figure 3, your protection path 
starts at a different root than either working path (for which I commented 
above) but what worries me more is that its destination leafs seem to be 
the union of the leafs of all of the working paths.  Doesn't this raise 
some security and congestion problems?  For example, let's take the simple 
case of a single failure on one of the working paths - by switching over 
to the protection path the traffic from this service will be delivered to 
some destinations that it was not intended to receive the packets?  In 
addition, the sections to this destination are suddenly carrying packets 
that are unnecessary and just causing additional traffic on the links!

3. Both of your solutions are greatly dependent upon the RDI 
functionality, and you state that the root will be able to identify the 
relevant working transport path based on this information.  However, the 
RDI for MPLS-TP is defined as part of the Extension to BFD and only within 
the CC messages (it is ignored in the CV message) that do not include a 
LSP/PW identifier TLV.  And considering that p2mp paths in MPLS-TP are 
unidirectional, I think that you need to clearly explain how the root 
receives the RDI and how it correlates this RDI to a particular LSP.

4. In your solution that is based on (1:1)^n protection - you state that 
the root must "compare the priority among these protection paths..." - but 
I thought that in this protection scheme the protection switch is 
performed within a single 1:1 domain, so there is nothing for the root to 
compare to!  What I believe that you meant is that each shared segment may 
need (in the case of multiple faults) to compare the priorities of the 
different requests for the shared resources!

5.  Can you explain the relationship between your proposals and the drafts 
that are available for 1:n protection and shared mesh protection (in 
particular draft-cheung that is also based on (1:1)^n protection)?  Can 
you use the same extensions that are proposed in those drafts?

Thank you,
Yaacov Weingarten_______________________________________________
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.

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 20 Mar 2012 11:24:34 +0100

Hi,

See my comments inline below

BR,

yaacov

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Friday, March 16, 2012 11:33 AM
To: Yaacov Weingarten
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Comments/Questions about "p2mp shared protection" draft

Yaacov，hi 
thank you for providing a lot of comments and questions for this draft. 
question 1, for the architecture of protection domain. IMO, it is very rare senario to use one protection path to protect several working paths which all have the same set of root and leaves. if we consider the scenario in this draft, maybe it use one protection path to protect several working paths which needn't have the same set of root and leaves. i think more senarios in real network belong to the situation. so it maybe over the scope of the survivability framework. 

[yw>] I think that I can agree with you that there will not be many situations where a single protection path will be used for a number of p2mp working paths that all have the same root and leafs. However, that means that calling this 1:n is unrealistic and therefore I am not sure that this scenario is very useful.  However, this makes it even more important for you to clearly define what the domain that you are addressing is and what are the requirements. 

I certainly believe that 1:n protection for p2p bidirectional paths is useful and important and that we should not be causing any confusion by using the terms without a clear definition.

 question 2, i think your understanding is right, some leaves which not intended to receive the packet will receive the packet. may we further consider the problem in the future. 

[yw>] I think it is important to consider the implications of this before advancing this proposal, both the security and congestion aspects!

 question 3, i think if there is no LSP/PW identifer TLV in RDI packet, it is necessary for the root node to bind RDI packet to a special LSP , for exmaple, it maybe correlate RDI 
 to a special return path. so that the root node can know which working path has the failure based on the return path;

[yw>] This is very confusing – since there is no "natural" return path for a p2mp path, since by definition they are unidirectional paths and any return path would need to be dependent on some other forwarding method, e.g. IP forwarding, or some other LSP that is not directly correlated with all of the p2mp LSPs that emanate from the root node.

 question 4,5,this is end to end protection solution. if the failure happened on one of the n working path, they must notify the failure message to the root of protection path. so the root 
will select one failure working path which is the highest priority to be proteced. it don't require the node of shared protection segment to compare the priority to select one working path to be protected. so it is different from the shared mesh protection. 

[yw>] So again I think that it is very important for you to clearly define what the protection domain is!

best regards 
liu 

2012-03-15 21:34 

收件人

[email-masked], [email-masked] 

抄送

主题

		

Hi, authors  

I have read your draft and find that I have quite a few questions and comments about the proposals in the draft and the presentation: 

1.  You present two different scenarios for protection of p2mp MPLS-TP traffic, but you do not really define what the architecture of your protection domain is. 
Taking the first solution, where you propose using a 1:n protection scheme - normally, and as presented in the Survivability Framework a 1:n protection domain consists of several working paths and a single protection path that all have the same set of root and leaves.  Yet in your figure 3 you show a 1:2 domain that the working paths have different roots and different sets of leafs!  It would be helpful, IMO, if you could define what protection domain you are referencing. 

2. In the scenario that you present in figure 3, your protection path starts at a different root than either working path (for which I commented above) but what worries me more is that its destination leafs seem to be the union of the leafs of all of the working paths.  Doesn't this raise some security and congestion problems?  For example, let's take the simple case of a single failure on one of the working paths - by switching over to the protection path the traffic from this service will be delivered to some destinations that it was not intended to receive the packets?  In addition, the sections to this destination are suddenly carrying packets that are unnecessary and just causing additional traffic on the links! 

3. Both of your solutions are greatly dependent upon the RDI functionality, and you state that the root will be able to identify the relevant working transport path based on this information.  However, the RDI for MPLS-TP is defined as part of the Extension to BFD and only within the CC messages (it is ignored in the CV message) that do not include a LSP/PW identifier TLV.  And considering that p2mp paths in MPLS-TP are unidirectional, I think that you need to clearly explain how the root receives the RDI and how it correlates this RDI to a particular LSP. 

4. In your solution that is based on (1:1)^n protection - you state that the root must "compare the priority among these protection paths..." - but I thought that in this protection scheme the protection switch is performed within a single 1:1 domain, so there is nothing for the root to compare to!  What I believe that you meant is that each shared segment may need (in the case of multiple faults) to compare the priorities of the different requests for the shared resources! 

5.  Can you explain the relationship between your proposals and the drafts that are available for 1:n protection and shared mesh protection (in particular draft-cheung that is also based on (1:1)^n protection)?  Can you use the same extensions that are proposed in those drafts? 

Thank you,

---

From: [email-masked]
Date: Wed, 21 Mar 2012 09:42:41 +0800

Yaacov, hi
i think your advice is very good, we will update the context of the draft 
in the next version according to your comments and suggestions.
for protection domain, i think it is necessary to clearly define the 
domain. IMO, I think it mainly recovery the failure of segment between
the root node and all leaf nodes. but it can't include the protection of 
end nodes.
for security of the protection solution, maybe the protected service only 
be transported between the root node and all leaf nodes on the protection 
path.
and some leaf nodes which needn't to receive the service packet will 
directly abandon it and can't propagate the service packet to other 
customer network, so
the protection solution will have no too much affect on security of the 
p2mp service. it is my personal opinions, do you think so?
for the failure notification, should  the leaf node notify the failure by 
PSC packet replace of RDI? is it more reasonable ?

thank you, 
B.R.
liu

"Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]> 
2012-03-20 18:24

收件人
<[email-masked]>, "Yaacov Weingarten" <[email-masked]>
抄送
<[email-masked]>, 
<[email-masked]>
主题
RE: [mpls] Comments/Questions about "p2mp shared protection" draft

Hi,

BR,
yaacov
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
ext [email-masked]
Sent: Friday, March 16, 2012 11:33 AM
To: Yaacov Weingarten
Cc: [email-masked]; 
[email-masked]
Subject: Re: [mpls] Comments/Questions about "p2mp shared protection" 
draft

Yaacov，hi 
thank you for providing a lot of comments and questions for this draft. 
question 1, for the architecture of protection domain. IMO, it is very 
rare senario to use one protection path to protect several working paths 
which all have the same set of root and leaves. if we consider the 
scenario in this draft, maybe it use one protection path to protect 
several working paths which needn't have the same set of root and leaves. 
i think more senarios in real network belong to the situation. so it maybe 
over the scope of the survivability framework. 
[yw>] I think that I can agree with you that there will not be many 
situations where a single protection path will be used for a number of 
p2mp working paths that all have the same root and leafs. However, that 
means that calling this 1:n is unrealistic and therefore I am not sure 
that this scenario is very useful.  However, this makes it even more 
important for you to clearly define what the domain that you are 
addressing is and what are the requirements. 
I certainly believe that 1:n protection for p2p bidirectional paths is 
useful and important and that we should not be causing any confusion by 
using the terms without a clear definition.

 question 2, i think your understanding is right, some leaves which not 
intended to receive the packet will receive the packet. may we further 
consider the problem in the future. 
[yw>] I think it is important to consider the implications of this before 
advancing this proposal, both the security and congestion aspects!

 question 3, i think if there is no LSP/PW identifer TLV in RDI packet, it 
is necessary for the root node to bind RDI packet to a special LSP , for 
exmaple, it maybe correlate RDI 
 to a special return path. so that the root node can know which working 
path has the failure based on the return path;
[yw>] This is very confusing – since there is no "natural" return path 
for a p2mp path, since by definition they are unidirectional paths and any 
return path would need to be dependent on some other forwarding method, 
e.g. IP forwarding, or some other LSP that is not directly correlated with 
all of the p2mp LSPs that emanate from the root node.

 question 4,5,this is end to end protection solution. if the failure 
happened on one of the n working path, they must notify the failure 
message to the root of protection path. so the root 
will select one failure working path which is the highest priority to be 
proteced. it don't require the node of shared protection segment to 
compare the priority to select one working path to be protected. so it is 
different from the shared mesh protection. 
[yw>] So again I think that it is very important for you to clearly define 
what the protection domain is!

best regards 
liu 

收件人
[email-masked], 

主题

Hi, authors 

Thank you, 

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