Subject: Re: [mpls] I-D ACTION:draft-pan-shared-mesh-protection-01.txt

From: [email-masked]
Date: Tue, 7 Jun 2011 17:27:58 +0800

Hi Ping

I just read the draft, some confusions listed below:

1)You give the definiton of warm standy, see below:

        Warm Standby: The nodes will negotiate and reserve protecting path 

        prior to network failure. However, data forwarding path will not 
be 
        programmed. Upon the detection of network failure, the nodes will 
        send explicit messages to relevant nodes to "wake up" the 
protecting 
        path. 

Since the data forwarding path is not programmed, which means that the 
data traffic and OAM traffic can not be tranported before the activation?
But according to the describtion of section 7.2

        As a part of the clean-up procedure, each DISABLE message must 
        traverse through and be processed on all the nodes of the 
        corresponding path. When the DISABLE message reaches to the 
tailend 
        node, the tailend is required to reply with a STATUS message to 
the
        headend.

Which means that the STATUS message can be sent to the headend, but the 
swithing fabric has been deprogramed at that time...

If I catch the idea clearly, a reply message is necessary, but it SHOULD 
be sent by other message along the working path.

2) You said that "Shared mesh protection is a common protection and 
recovery mechanism", but recovery includes protection and restoration 
(RFC4427), this sentence Maybe need to be revised.

Thanks and best regards

Fei

Ping Pan <[email-masked]> 
发件人:  [email-masked]
2011-03-11 03:18

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

主题
Re: [mpls] I-D ACTION:draft-pan-shared-mesh-protection-00.txt

Correction: the goal is to recover in milliseconds. 

Did not mean to use US Postal Service or Pony Express for protecting path 
activation. ;-)

Ping

On Thu, Mar 10, 2011 at 8:19 AM, Ping Pan <[email-masked]> wrote:
Hi,

Shared Mesh Protection has the benefit of optimizing network resources in 
transport networks. However, activating the protection has always been a 
challenge.

MPLS-TP has outlined the requirements and framework. Here is a proposal 
that we have put together to solve the performance issue in shared meshed 
networks.

Given its simplicity (actually it's designed for embedded data-plane), 
this can achieve rapid traffic recovery and switch-over. The performance 
goal is to recover traffic in million seconds for end-to-end transport 
tunnels.

We are still working on details. Look forward to hear your feedback.

Best regards,

Ping

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Mar 7, 2011 at 6:00 PM
Subject: I-D ACTION:draft-pan-shared-mesh-protection-00.txt
To: [email-masked]

A new Internet-Draft is available from the on-line Internet-Drafts 
directories.

   Title         : Supporting Shared Mesh Protection in MPLS-TP Networks
   Author(s)     : R. Rao, et al
   Filename      : draft-pan-shared-mesh-protection-00.txt
   Pages         : 15
   Date          : 2011-03-07

Shared mesh protection is a common protection and recovery mechanism
       in transport networks, where multiple paths can share the same set
       of network resources for protection purposes.

       In the context of MPLS-TP, it has been explicitly requested as a
       part of the overall solution (Req. 67, 68 and 69 in RFC5654 [1]).

       It's important to note that each MPLS-TP LSP may be associated with
       transport network resources. In event of network failure, it may
       require explicit activation on the protecting paths before 
switching
       user traffic over.

       In this memo, we define a lightweight signaling mechanism for
       protecting path activation in shared mesh protection-enabled 
MPLS-TP
       networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pan-shared-mesh-protection-00.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.

_______________________________________________
I-D-Announce mailing list
[email-masked]

https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls