Subject: [mpls] Comments to draft-pan-shared-mesh-protection-03

From: Gregory Mirsky <[email-masked]>
Date: Sun, 13 Nov 2011 17:57:55 -0500

Dear Authors, et al.,
Please kindly consider my comemnts to the draft-pan-shared-mesh-protection-03:
*       Introduction. I don't have other examples of Shared Mesh Protection in transport networks even though it's been referred as common mechanism.
*       Section 3 "All paths are established via MPLS-TP control plane prior to network failure." Can paths be statically configured?
*       Section 3 "All paths are assumed to be bi-directional." Is it important whether LSP is co-routed or associated?
*       Section 3.1 "Upon the detection of network failure, the headend nodes will transmit activation messages along the MPLS LSP's." I assume that activation messages being sent along protecting MPLS-TP LSP.
*       Section 3.1 Since labels are per platform all line modules must perform activation in coordinated manner to avoid possible inconsistency in the data plane.
*       Section 4.1 It is unlikely that Signal Degrade is applicable to Packet Transport Networks
*       Section 5.1 What is MPLS label stack when activating protecting LSP?
*       Section 5 Is Seq(uence) signed or unsigned integer and what are valid numbers, i.e. is 0 a valid number?
*       Section 5.2 Is sending a message blocking event or there's a window of unack'ed messages allowed?
*       Section 5.2 Is number of re-tries (default 3) negotiable or configurable parameter?
*       Section 5.2 Failure to activate reported as alarm. How other failures reported?
*       Section 5.2 All operations use reliable transport? Is that necessary?
*       Section 6.1 "...a next-hop node will locate the corresponding path and activate the path" what information carried in the activation message refers to a path intended to be activated? I think that there's "chicken-egg" problem in activation procedure as described in the document.
*       Section 6.2 How deactivation of bidirectional section handled in regard to sending ACK?

        Regards,
                Greg