Update: Draft response to OIF on 1:n protection

["Adrian Farrel" <[e-mail]>]

Hi,

Jim Jones has been in touch to ask that we hold off responding for a while. 
it appears that having read this draft response, some OIF folk would like to 
spend some time clarifying the questions.

Thanks,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Monday, May 22, 2006 8:50 PM
Subject: Draft response to OIF on 1:n protection


> Hi,
>
> Thanks to those who have sent me off-list comments.
>
> Here is a draft response to the OIF on 1:n protection. Please send me (or
> the list) your comments.
>
> Thanks,
> Adrian
>
> ===
> Dear Jim,
>
> Thank you for your communication to CCAMP on the use of GMPLS to provide
> 1:n protection at the OIF UNI and the OIF E-NNI.
>
> We are grateful for this opportunity to comment, but we note that this
> type of communication requesting clarifications is better suited to a
> mailing list discussion than to official communications that, by their
> nature, have a slow turn-around. The appropriate place for
> discussions of GMPLS protocols is the CCAMP working group
> mailing list. Details of how to subscribe to the mailing list can be found 
> at http://www.ietf.org/html.charters/ccamp-charter.html
>
>> Future updates to OIF UNI and E-NNI signaling may include a feature
>> for 1:N connection protection. The attached document presents
>> requirements for these features. Recently a review was completed
>> of RFCs 4426, 4427 and 4428 and IETF drafts that may be able to
>> implement this function (including draft-ietf-ccamp-gmpls-recovery-
>> e2e-signaling-03 and draft-ietf-ccamp-gmpls-segment-recovery-02).
>> It appears that the abstract messages from RFC 4426 provide much
>> of this functionality, however several questions resulted from this
>> review. OIF would appreciate review and comments from IETF
>>CCAMP on the following items.
>>
>> 1.) OIF would appreciate knowing if there are protocol features in
>> other IETF documents relevant to 1:N protection .
>
> We would like to suggest that, in order to utilize advanced features of
> the GMPLS control plane protocol, engineers should be familiar with
> the full set of GMPLS RFCs and Internet-Drafts. These are listed on
> the CCAMP charter page and can be downloaded free of charge by
> clicking on the links.
>
> Although not all of this work is directly related to protection and
> restoration, it should be noted that any protocol aspect present for a
> working path may also be required for a protection path. Protocol
> engineers must, therefore, be familiar with the details of the protocol
> before attempting to provide advanced functions like protection.
>
>> 2.) RFC 4426 section 2.5.2 says "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".
>> OIF would like to know what signaling messages and objects can be
>> used to accomplish this.
>
> Your question is confusing in the light of the referenced section.
> The section describes the messages required to achieve span protection.
> Clearly, if a span is protected, then all LSPs carried over that span
> may be transparently protected. This is how normal link protection
> operates and there is nothing clever going on.
>
> Recall that section 2.5.2 is a subsection of section 2, and this is
> entirely dedicated to span protection.
>
> Further, if the bundling example is followed, the referenced RFC
> (RFC4201) explains the signaling necessary to achieve bundling.
>
> You may find it easier to consider this as a layering architecture. The
> span (link) that is protected is a lower layer commodity and its
> protection may be, therefore, transparent to the higher layer.
>
> If you have a specific question we would be happy to answer.
>
>> 3.) It is suggested that the Failure Indication Message (or
>> equivalent) from RFC 4426 can be triggered not only from a
>> failure but also a command from a management system.
>
> You have not asked a specific question here so it is hard to give any
> answer except for "yes".
>
> Management systems are usually regarded as supreme. A management
> system can instruct an implementation to do anything, and this may be
> useful for forced or controlled switch-over. You may want to refer to
> RFC4427 section 4.13.
>
>> 4.) A goal of the 1:N protection is to use a bulk notification and
>> recovery procedure, based on RFC 4427 section 4.15. However, that RFC
>> states the corresponding recovery switching actions are performed at
>> the LSP level. It would be useful to know if bulk processing could be
>> applied to recovery of individual connection segments on the failed span,
>> not entire LSPs.
>
> We do not understand your question. Each LSP has its own entry in the
> switching matrix. Any switching recovery action that is required can
> only be applied to this individual entry. Implementations may have some
> optimisations (such as back-up, pre-programmed matrices, or magic matrix
> re-program commands), but this is clearly out of scope of a control
> plane specification.
>
> Please note that recovery switching actions are not signaling actions.
>
> We are also confused as to the meaning of "It would be useful to know if
> bulk processing could be applied to recovery of individual connection
> segments on the failed span, not entire LSPs." To process it further, we
> probably need to deconstruct the term Connection Segment. As you may be
> aware, the term 'connection segment' is not widely used in the ASON
> Recommendations and does not find a definition there. The reference from
> G.8081 is to an ATM forum document.
>
> We assume that you are concerned to provide end-to-end data transfer.
> Presumably you are interested in a variety of symmetrical cases such as
> client-layer connectivity, UNI-C to UNI-C connectivity, UNI-N to UNI-N
> connectivity, or UNI-N/E-NNI to E-NNI/UNI-N connectivity. The path
> between these points is an LSP (it may be a hierarchical LSP through which
> other LSPs are tunneled) and it is this path that you wish to protect.
> Whether you perform span, segment, or end-to-end protection, you are still
> protecting the LSP.
>
>> 5.) RFC 4426 refers to three abstract messages involved in the
>> reversion sequence:
>>
>> - A Bridge and Switch Request message from the source node after it
>> has bridged traffic back to both working and protection links.
>>
>> - A Bridge and Switch Response message from the destination node after
>> it has bridged traffic back to both working and protection links and
>> changed its selector to the working link.
>>
>> - A Bridge and Switch Completed message from the source node after it
>> has changed its selector to the working link and stopped sending traffic
>> on the protection link (so the destination can stop transmitting on
>> protection).
>>
>> Since RFC 4426 covers these Bridge and Switch messages briefly, more
>> details should be specified on the operation and behavior in this
>> reversion process.
>
> If you have specific questions, we would be happy to answer them. If you
> believe that additional documentation is required, we would welcome your
> contributions as an Internet-Draft.
>
>> Further, it would be helpful to understand why the actions are
>> performed by source and destination nodes rather than master and
>> slave nodes. It may be appropriate to reuse the master/slave roles
>> in the reversion process just as is done in the switchover process.
>
> There is a distinction between the node that invokes a switchover
> process (the master) and a node that performs the process. For
> example, a Bridge and Switch Request message is sent by the source
> node after it has bridged traffic back to both working and protection
> links simply because the source node has performed the bridging and
> is the only node that can know this fact.
>
>> In addition, RFC 4426 does not include an abstract message similar to
>> the Failure Indication Message to request the beginning of the reversion
>> procedure. It may be beneficial to include a message from the slave
>> device to initiate reversion, just as there is a Failure Indication
>> Message
>> to initiate switchover. (RFC 4426 states that the Failure Indication
>> Message may not be needed when the transport plane technology
>> itself provides such a notification. The same may apply when a failure
>> is cleared; however, there should still be an optional message to
>> trigger the reversion process.)
>
> Reversion is described as an administrative procedure quite
> deliberately. In our view it should not be a rapid response to a
> specific situation triggered through the control plane by the 'master',
> but should be a considered operation under the control of administrative
> policy. The trigger is, therefore, outside the scope of the control plane.
> This is in section 4.13 of RFC4427.
>
> We hope this answers your questions, and we would be happy to enter into
> further dialog on these topics.
>
> Best regards,
> Adrian Farrel and Deborah Brungard
> CCAMP co-chairs
>
>
>
>
>
>