Updated communication from the OIF on 1: protection

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

As promissed, we have received an update to the 20th May communication from 
the OIF on 1:n protection. Hopefully this clarifies the questions so that we 
can provide suitable answers. As usual, all incoming communications can be 
found at http://www.olddog.co.uk/ccamp.htm

We will see how we can adapt our draft response to respond ASAP. All input 
is welcome.

Cheers,
Adrian
==
From: "Jim Jones" <jim.d.jones@alcatel.com>
To: "'Adrian Farrel'" <adrian@olddog.co.uk>;
   "'Brungard, Deborah A, ALABS'" <dbrungard@att.com>
Cc: "'Ong, Lyndon'" <Lyong@Ciena.com>
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