Re: [mpls] [mpls-tp] I-D Action:draft-ietf-mpls-tp-survive-fwk-04.txt

[Maarten Vissers <[e-mail]>]

Liu,
 
We have had this discussion about 15 years ago when multi-layer protection
switching became alive in SDH networks. Many investigation reports and
contributions have been written in that time analyzing the options
available. At the end the conclusion was that hold-off timers are the only
solution, and those have been implemented and deployed since then. 
 
Furthermore, it was concluded that one should limit the stacking of
protection switching to a protection switching level as close to the fiber
as possible and as close to the service as possible. The latter protection
switching process will then work with a hold-off timer set to 100 ms (refer
to 14/G.808.1 and Appendix I/G.808.1, 8/G.841, 8.12/G.873.1, 11.2/G.8031).
 
The lower protection switching level could be a:
1) section layer protection (between adjacent nodes), which protects against
fiber and NNI port faults and can be implemented as:
    - a STM-N multiplex section (OC-N line) protection.
    - a ring protection
    - a transport path layer compound link protection (CL-SNCG/I)
2) transport service layer group protection (between adjacent PE nodes),
which protects against fiber and P node faults in the domain bounded by the
PE nodes and against PE node NNI port faults
 
The higher protection switching level is an individual transport service
instance protection, implemented as transport service SNC/S protection.
 
----------
 
With respect to the p2mp protection case I am wondering if you refer to 
1) unidirectional p2mp connections with one root and N leaves in which each
packet is delivered to all leaves, or 
2) bidirectional rooted-multipoint (rmp) connections with one or more roots
and N leaves in which each frames is delivered to one or a subset of the
leaves, or
3) two unidirectional p2mp connections, each with one root (connected to a
content service head end node) and a shared set of N leaves in which each
packet is delivered to all leaves
4) p2mp PWs carrying multicast traffic in a VPLS?
 
For case 4, you do not protect the p2mp PW; instead the VPLS is protected.
 
For case 3, 1+1 protection is the best alternative. Note that in this case
we need to use an additional client signal based trigger condition to
protect against a fault in a head end node or against a fault on the fiber
connecting a head end node with the network.
 
For case 2, 1:1 protection is the best alternative.
 
For case 1, 1+1 or 1:1 protection could be used depending on the
application. 1+1 protection allows that each leaf switches independently; i.
e. some leaves may read from working, others may read from protection.
 
Regards,
Maarten

  _____  

From: [e-mail] [mailto:[e-mail]] 
Sent: donderdag 11 maart 2010 3:04
To: Maarten Vissers
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [mpls] [mpls-tp] I-D
Action:draft-ietf-mpls-tp-survive-fwk-04.txt



Maarten 
thank you for reply my question. 
1 IMO, Hold off timers is not good solution. 
what value is suitable for Hold off timer for upper layer protection swith? 
if the value is too long, it must affect recoverying service within 50ms; 
if the value is too short, protection switch in the upper layer is earlier
or 
equal than that in the below layer. how to set the value of hold off timer
for 
the upper layer? i don't know it very clearly. 

2 if we don't consider 1:n protection for p2mp path, 
  according to your solution , only use 1+1 protection solution, 
  it must cost most bandwidth and equipments in the linear protection, 
  and it is hard and difficult for network operater to configurate dedicate
protection path 
  for each p2mp path. 
  in addition, more and more p2mp service will exist and apply in the 
  current time, 
  if only use 1+1 and 1:1 protection solution , the cost of configuration 
  is the larest and most. 

there is missing something important, but I wish to have a finer and better
solution 
to solve the problem of p2mp protection ; 

best regards 
liu 
    








Maarten Vissers <[e-mail]> 
发件人:  [e-mail] 


2010-03-10 18:30 


收件人
[e-mail], [e-mail] 

抄送
[e-mail] 

主题
Re: [mpls] [mpls-tp]        I-D
Action:draft-ietf-mpls-tp-survive-fwk-04.txt

	




Liu, 
  
You need to use Hold Off timers at the upper layer protection switch
selectors in this case. 
Additional OAM packets don't help. E.g. a cable break is detected at all
layers at pproximately 
the same time, and without hold off timer set at upper layer protection
switching endpoints those 
upper layer protection endpoints may switch at the same time, or possibly
even a little bit earlier. 
  
P2MP connections are used for distribution services. For such case you want
1+1 protection and 
unidirectional switching (per endpoint). No need for 1:n. 
  
Regards, 
Maarten 


  _____  

From: [e-mail] [mailto:[e-mail]] On Behalf
Of [e-mail]
Sent: woensdag 10 maart 2010 10:09
To: [e-mail]
Cc: [e-mail]
Subject: Re: [mpls-tp] [mpls] I-D
Action:draft-ietf-mpls-tp-survive-fwk-04.txt


hi, all experts 
I review this draft this afternoon, I have a few questions of part section
of this draft. 
1 section 4.4.1 
 " As with recovery in layered networks, a protecion mechanism at the lower
layer needs 
to be coordinated with protection actions at the upper layer in order to
avoid race conditions" 
i don't know how to coordinate state of protection switching between the
lower layer and 
the upper layer. do we need a new type of state packet to coordinate
protection switching 
between the lower and upper layer? 

2 I review all context of this draft. I don't notice the 1:n protection
framework for P2MP. 
 is it necessary to consider the 1:n protection solution for P2MP in the
following Draft 
 version？ my answer is yes. do you think so? 

best regards 
liu 
  
	



	





[e-mail] 
发件人:  [e-mail] 


2010-03-09 06:30 




收件人
[e-mail] 

抄送
[e-mail] 

主题
[mpls] I-D Action:draft-ietf-mpls-tp-survive-fwk-04.txt


	





A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Multiprotocol Label Switching Working Group
of the IETF.


               Title           : Multiprotocol Label Switching Transport
Profile Survivability Framework
               Author(s)       : N. Sprecher, A. Farrel
               Filename        : draft-ietf-mpls-tp-survive-fwk-04.txt
               Pages           : 57
               Date            : 2010-03-08

Network survivability is the ability of a network to restore traffic
delivery following disruption or failure or degradation of network
resources.  Survivability is critical to the delivery of guaranteed
network services such as those subject to strict Service Level
Agreements (SLAs) that place maximum bounds on the length of time the
service may be degraded or unavailable.

The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a
packet transport technology based on the MPLS data plane and re-using
many aspects of the MPLS management and control planes.

This document provides a framework for the provision of survivability
in an MPLS-TP network, describing recovery elements, types, methods
and topological considerations.  Survivability may be supported by
control plane, management plane, and by Operations, Administration
and Maintenance (OAM) functions to achieve data plane recovery.  This
document describes mechanisms for protecting MPLS-TP Label Switched
Paths (LSPs).  Detailed consideration for the protection of
pseudowires in MPLS-TP networks is out of scope.

This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as
defined by the ITU-T.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-survive-fwk-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://[e-mail]/internet-drafts/draft-ietf-mpls-tp-survive-fwk-
04.txt_______________________________________________
mpls mailing list
[e-mail]
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.
_______________________________________________
mpls mailing list
[e-mail]
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.