From: "Jim Jones" To: "'Adrian Farrel'" ; "'Brungard, Deborah A, ALABS'" Cc: "'Ong, Lyndon'" Sent: Friday, June 02, 2006 7:47 PM Subject: Draft response to OIF on 1:n protection Dear Adrian and Deborah, In observing some of the e-mails on the CCAMP list and the draft response to the OIF Liaison to IETF CCAMP WG on 1:N Protection, it was apparent that some clarification of our questions was in order. This revised input was drafted by OIF members that composed the outgoing liaison and contributions on the topic. The OIF is still interested in a response from the experts participating in CCAMP. 1) OIF would appreciate CCAMP's guidance as to whether CCAMP has defined standards for any similar form of restoration, i.e., one that protects a group of LSPs at once over a local span, by shifting these LSPs from their original link within the span over to a backup link. It should be noted that - the backup link may be a different type than the original (e.g., OC192 rather than OC48), so that GMPLS signaling rather than underlying SONET/SDH link protection is used to perform the switchover; and - it is intended that the affected LSPs be shifted using a single signaling interaction rather than separate interactions per individual LSP in order to reduce the signaling overhead required. We believe that some of the existing work, especially for segment recovery, may be helpful, but may not meet the exact requirements of the service that has been proposed within OIF. Any pointers to existing drafts or RFCs, however, would be greatly appreciated. 2) Reviewing some of the existing RFC text, we note that RFC 4426 section 2.5.2 states "it MAY be possible for the LSPs on the working link to be mapped to the protection link without re-signaling each individual LSP" and "it MAY be possible to change the component links without needing to re-signal each individual LSP". This text appears to refer to the use of SONET/SDH link protection in such a way that the labels for each LSP remain the same. Does this imply, however, that an action that changes the local labels for the affected LSPs then requires re-signaling of each individual LSP, or is there a "bulk" mechanism to change labels for a group of LSPs simultaneously? 3) RFC 4426 describes the sending of the Failure Indication Message upon detection of failure by a slave device. It is our belief that the same mechanism could also be used when the slave device is triggered to send an indication due to management system intervention (cases are mentioned in RFC 4427 but not in 4426), and we would like to know if CCAMP concurs with this. An example of where this might occur is where the master and slave devices are in different management domains. 4) RFC 4427, section 4.15 discusses bulk recovery for a failed span, and suggests that the recovery switching message to recovered LSP ratio may be 1 or greater. OIF would like to know if it is possible to define procedures such that the ratio is much less than 1, i.e., a message that causes bulk recovery actions on a number of LSPs. 5) RFC 4426 defines a "master" and "slave" role for dedicated 1+1 and 1:1 span protection and a "source" and "destination" role for control of end-to-end restoration and for reversion. We believe that "source" and "destination" mean the initiator and receiver of the LSP (as opposed to the source and destination of data in-band). We are not clear on the rationale for when control plane roles are based on master/slave vs. source/destination: it appears that local span actions are controlled using master/slave while remote actions are controlled using source/destination, however the reasoning for control of reversion is less clear to us. Any clarification of the rationale for using master/slave vs. source/destination control would be appreciated. 6) We believe that it may be useful in some cases of reversion to allow a "slave" device to request reversion using an abstract message similar to the Failure Indication Message. An example case is (again) when the "master" and "slave" devices are in different management domains, such that reversion is initiated from the management domain of the "slave" device. We request CCAMP comment on this suggestion. The OIF would appreciate the review and feedback of the experts in the CCAMP working group on these items. Best regards, Jim Jones OIF Technical Committee Chair